Product and Software: This article applies toall Aruba controllers and ArubaOS versions.
An accounting packet is divided into two parts, Accounting-Request and Accounting-Response, and the whole process is based on UDP, because RADIUS works on UDP 1646 and 1813. Cisco ACS needs this stop packet to be delivered on the time.
Accounting-Request packets are sent from a client (typically a Network Access Server) to a RADIUS accounting server, and they convey information used to provide accounting for a service provided to a user. The client transmits a RADIUS packet with the Code field set to 4 (Accounting-Request).
Upon receipt of an Accounting-Request, the server MUST transmit an Accounting-Response reply if it successfully records the accounting packet, and the server MUST NOT transmit any reply if it fails to record the accounting packet. Note that if Acct-Delay-Time is included in the attributes of an Accounting-Request, then the Acct-Delay-Time value will be updated when the packet is retransmitted, which changes the content of the Attributes field and requires a new Identifier and Request Authenticator.
Accounting-Response packets are sent by the RADIUS accounting server to the client to acknowledge that the Accounting-Request has been received and recorded successfully. If the Accounting Request was recorded successfully, then the RADIUS accounting server MUST transmit a packet with the Code field set to 5 (Accounting-Response). When the client receives an Accounting-Response, the Identifier field is matched with a pending Accounting-Request. Invalid packets are silently discarded.
The Aruba controller sends a UDP (stop) packet, but the packet does not get to the ACS for some reason. The Aruba controller waits for an Accounting-Response from the ACS. If no Accounting-Response is received from the ACS, the Aruba controller retransmits the UDP packet after some time.