Accounting multicast + unacknowledge mode and conflicting packet

[Alan DeKok]

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.