Hello, is there any way to add redis cluster module of freeradius 4 to freeradius 3 ThanksBassemEnvoyé depuis mon smartphone Samsung Galaxy.
Hello alan, your website clearly says that redis cluster is integrated on freeradius 3.0.19 [image: alan.PNG] On Tue, 23 Apr 2019 at 17:59, Alan DeKok <aland@deployingradius.com> wrote:
On Apr 23, 2019, at 12:58 PM, mettichi <mettichi@gmail.com> wrote:
Hello, is there any way to add redis cluster module of freeradius 4 to
freeradius 3
No.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Apr 23, 2019, at 5:56 PM, Talel Krimi <talelkrimi01@gmail.com> wrote:
your website clearly says that redis cluster is integrated on freeradius 3.0.19
Well, it's not available in 3.0.19. If it was, the source code would have it, and the configuration would talk about it. The "redis" module is available in v3. The *cluster* portion is not. If this is a problem, then: (a) supply patches to make Redis cluster work in v3 (b) supply patches to fix the web site Alan DeKok.
On Tue, 2019-04-23 at 22:56 +0100, Talel Krimi wrote:
your website clearly says that redis cluster is integrated on freeradius 3.0.19
No, it doesn't specifically say it works on 3.0.19. The web site has an overview of what that module does across multiple versions of the server. The module notes on the web site are taken from the master (to be v4) branch, as they're the most up-to-date. If the web site was built using the latest v3 notes then newer modules would be missing. It's not possible to have detailed specifics there, there are too many variations between different versions of FreeRADIUS. -- Matthew
thank you Matthew, I have another question please, we are using freeradius for an implicit authentication of clients of a phone operator, so a GGSN sends traffic for the accounting of those users on our platform, 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 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 I don't know if my analysis is right. could you help with this issue ? Best regards, On Tue, 23 Apr 2019 at 23:05, Matthew Newton <mcn@freeradius.org> wrote:
On Tue, 2019-04-23 at 22:56 +0100, Talel Krimi wrote:
your website clearly says that redis cluster is integrated on freeradius 3.0.19
No, it doesn't specifically say it works on 3.0.19. The web site has an overview of what that module does across multiple versions of the server.
The module notes on the web site are taken from the master (to be v4) branch, as they're the most up-to-date. If the web site was built using the latest v3 notes then newer modules would be missing.
It's not possible to have detailed specifics there, there are too many variations between different versions of FreeRADIUS.
-- Matthew
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Apr 23, 2019, at 6:26 PM, Talel Krimi <talelkrimi01@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.
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 ) we did the necessary tuning on our databases ( we are using redis in memory database ) and there is no issues with it Thank you On Tue, 23 Apr 2019 at 23:30, Alan DeKok <aland@deployingradius.com> wrote:
On Apr 23, 2019, at 6:26 PM, Talel Krimi <talelkrimi01@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
> On 24/04/2019, at 10:33 AM, Talel Krimi <talelkrimi01@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@deployingradius.com> wrote: > >> On Apr 23, 2019, at 6:26 PM, Talel Krimi <talelkrimi01@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
On Apr 23, 2019, at 6:33 PM, Talel Krimi <talelkrimi01@gmail.com> wrote:
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 )
It's how RADIUS works. If you want to know more, read RFC 2865 and RFC 5080.
we did the necessary tuning on our databases ( we are using redis in memory database ) and there is no issues with it
<shrug> If the server is blocking in rlm_rediswho, then the database does have issues. Maybe you're using another database too, and that database is also slow. Again, this isn't complex FreeRADIUS can do 50K packets/s if it's just doing ACKs. If your system isn't doing that, it's because of local changes. We've run FR with sustained loads of 5-10K packets/s to a database. But that is a very carefully designed system. Alan DeKok.
participants (5)
-
Alan DeKok -
Matthew Newton -
mettichi -
Nathan Ward -
Talel Krimi