Redis cluster sentinel

[Nathan Ward]

> On 24/04/2019, at 10:33 AM, Talel Krimi <talelkrimi01 at gmail.com> wrote:
> 
> Hello alan,
> 
> how the GGSN retransmits the same packet? it is a UDP protocol, there are
> now way he ll way for an some kind of response ( ACK )

RADIUS has an application layer response.
If the NAS (GGSN) doesn’t get that response it will retransmit. There is a timeout, some NASes use 5 seconds, as an example.

Would be worth understanding the protocol before trying to get in to detail with implementing it in your network.

> we did the necessary tuning on our databases ( we are using redis in memory
> database ) and there is no issues with it

The message you posted is saying:
- There is an existing request with that ID
- The previous request is waiting on the database

This means that your database is not replying fast enough - FreeRADIUS is waiting for the database. The GGSN is retransmitting as it doesn’t get a RADIUS reply.

I think your database tuning is not quite right, or, there is some other problem between FreeRADIUS and your database which is causing it to run slowly. DNS? Network latency? There are many factors.

A very common thing is for the database to lock and then queue your requests rather than run them in parallel. I don’t think that’s very common with Redis, but, I understand it can sometimes happen.

I strongly suggest you look in to your queries you’re doing on your Redis database, and if you are *certain* that your Redis database is performing well, then do some performance tests using the same queries as you’re using from FreeRADIUS, and prove that. I am certain you will find your performance problems there.


The other option, of course, is that the GGSN is re-using the same ID for multiple concurrent requests. That would be a very poor RADIUS implementation, and would be surprising. If that is the case, you should throw out the GGSN, as it is junk.

> Thank you
> 
> On Tue, 23 Apr 2019 at 23:30, Alan DeKok <aland at deployingradius.com> wrote:
> 
>> On Apr 23, 2019, at 6:26 PM, Talel Krimi <talelkrimi01 at gmail.com> wrote:
>>> the problem is that we have some error like:
>>> 
>>> Ignoring duplicate packet from client GGSN2OSN port 61470
>>> Received conflicting packet from client GGSN1OSN port 62259 - ID: 51 due
>> to
>>> unfinished request in module rediswho.  Giving up on old request
>> 
>>  This is a very common question.  The database is slow, so FreeRADIUS
>> can't reply to the request.
>> 
>>> i did some tcpdumps and clearly the freeradius for some reasons when he
>>> can't process a quer ( accounting ) he ask the GGSN for another one with
>>> the same ID but also in he sees it as a duplication which cause the
>>> conflict
>> 
>>  FreeRADIUS doesn't ask the GGSN for another packet.  The GGSN
>> retransmits the same packet, and FreeRADIUS just receives it.
>> 
>>> I don't know if my analysis is right. could you help with this issue ?
>> 
>>  Fix your database so it doesn't block the server.
>> 
>>  FreeRADIUS can do ~50K packets/s if it's doing nothing more than sending
>> a reply.  Once you add complex rules and a database, that performance drops
>> significantly.
>> 
>>  Alan DeKok.
>> 
>> 
>> -
>> List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html