Accounting multicast + unacknowledge mode and conflicting packet

Alan DeKok aland at deployingradius.com
Mon Apr 22 15:08:18 CEST 2019


On Apr 22, 2019, at 9:00 AM, Fran├žois RAGUIN <fraguin at 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.




More information about the Freeradius-Users mailing list