Accounting multicast + unacknowledge mode and conflicting packet
Our GGSN is configured to send Radius accounting in multicast to multiple servers and ignore accounting response (unacknowledge mode). In this case, GGSN (which sends several thousand requests per second) reuses emitter UDP port and Radius ID pairs rather quickly. On the FreeRadius side, we then encounter multiples cases of "Received conflicting packet" in the logs. Would it not be possible for FreeRadius to process all Accounting, in this particular case where the GGSN is configured in unacknowledge mode?
On Apr 22, 2019, at 9:00 AM, François RAGUIN <fraguin@wanadoo.fr> wrote:
Our GGSN is configured to send Radius accounting in multicast to multiple servers and ignore accounting response (unacknowledge mode).
OK.
In this case, GGSN (which sends several thousand requests per second) reuses emitter UDP port and Radius ID pairs rather quickly.
Then the GGSN is probably broken. It's not difficult to open more source ports.
On the FreeRadius side, we then encounter multiples cases of "Received conflicting packet" in the logs.
Because FreeRADIUS implements the RFCs correctly.
Would it not be possible for FreeRadius to process all Accounting, in this particular case where the GGSN is configured in unacknowledge mode?
Sure. Just make sure that it takes almost no time to process packets. i.e. dump the packets to a detail file, and do nothing else: preacct { } accounting { detail do_not_respond } Then, configure a detail file reader to post-process the detail files. But realistically, this is unfriendly behaviour on the part of the GGSN. Plus, you'e likely doing complex processing of the accounting packets, which is slow. It's not trivial to change FreeRADIUS to handle this case. It's unusual, and could break normal packet processing. Alan DeKok.
Hello, i think the solution is to ignore conflicting packets and not process them and print them to detail file, but how we can configure freeradius to ignore these conflicting packetes from GGSN ? Thanks Bassem Le lun. 22 avr. 2019 à 14:08, Alan DeKok <aland@deployingradius.com> a écrit :
On Apr 22, 2019, at 9:00 AM, François RAGUIN <fraguin@wanadoo.fr> wrote:
Our GGSN is configured to send Radius accounting in multicast to
multiple servers and ignore accounting response (unacknowledge mode).
OK.
In this case, GGSN (which sends several thousand requests per second) reuses emitter UDP port and Radius ID pairs rather quickly.
Then the GGSN is probably broken. It's not difficult to open more source ports.
On the FreeRadius side, we then encounter multiples cases of "Received conflicting packet" in the logs.
Because FreeRADIUS implements the RFCs correctly.
Would it not be possible for FreeRadius to process all Accounting, in this particular case where the GGSN is configured in unacknowledge mode?
Sure. Just make sure that it takes almost no time to process packets.
i.e. dump the packets to a detail file, and do nothing else:
preacct { }
accounting { detail do_not_respond }
Then, configure a detail file reader to post-process the detail files.
But realistically, this is unfriendly behaviour on the part of the GGSN. Plus, you'e likely doing complex processing of the accounting packets, which is slow.
It's not trivial to change FreeRADIUS to handle this case. It's unusual, and could break normal packet processing.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Apr 22, 2019, at 9:37 AM, Bassem Mettichi <mettichi@gmail.com> wrote:
i think the solution is to ignore conflicting packets and not process them and print them to detail file, but how we can configure freeradius to ignore these conflicting packetes from GGSN ?
This requires source code changes. It's a very unusual situation, and not something which is supported in the default configuration. Another option is to use a load balancer, and multiple FreeRADIUS backends. The short answer that if the GGSN is sending 5K packets/s, and the FreeRADIUS + DB back-end can only handle 1K packets/s, you've got problems. Adding more capacity is really the only solution. Alan DeKok.
participants (3)
-
Alan DeKok -
Bassem Mettichi -
François RAGUIN