Understanding RADIUS-Initiated Disconnect

In a typical client-server RADIUS environment, the E Series router functions as the client and the RADIUS server functions as the server. However, when using the RADIUS dynamic-request server feature, the roles are reversed. For example, during a RADIUS-initiated disconnect operation, the E Series router’s RADIUS dynamic-request server functions as the server, and the RADIUS server functions as the disconnect client.

This section describes the RADIUS dynamic-request server’s RADIUS-initiated disconnect feature.

Disconnect Messages

To centrally control the disconnection of remote access users, the RADIUS dynamic-request server on the router must receive and process unsolicited messages from RADIUS servers.

The RADIUS-initiated disconnect feature uses the existing format of RADIUS disconnect request and response messages. The RADIUS-initiated disconnect feature uses the following codes in its RADIUS request and response messages:

Message Exchange

The RADIUS server and the router’s RADIUS dynamic-request server exchange messages using User Datagram Protocol (UDP). The Disconnect-Request message sent by the RADIUS server has the same format as the COA-Request packet that is sent for a change of authorization operation.

The disconnect response is either a Disconnect-ACK or a Disconnect-NAK message:

Supported Error-Cause Codes (RADIUS Attribute 101)

When a disconnect request fails, the RADIUS dynamic-request server includes an error-cause attribute (RADIUS attribute 101) in the Disconnect-NAK message that it sends back to the RADIUS server. If the detected error does not map to one of the supported error-cause attributes, the router sends the Disconnect-NAK without an error-cause attribute. Table 54 lists the supported error-cause codes.

Table 54: Error-Cause Codes (RADIUS Attribute 101)





Unsupported attribute

The request contains an attribute that is not supported (for example, a third-party attribute).


Missing attribute

A critical attribute (for example, the session identification attribute) is missing from a request.


Invalid request

Some other aspect of the request is invalid, such as if one or more attributes (for example, the packet mirroring Mirror Identifier value) are not formatted properly.


Session context not found

The session context identified in the request does not exist on the NAS.


Session context not removable

The subscriber identified by attributes in the disconnect request is owned by a component that does not support RADIUS-initiated disconnect (for example, IP LAC subscribers cannot be disconnected).


Resources unavailable

A request could not be honored due to lack of available NAS resources (such as memory).

Qualifications for Disconnect

For the server to disconnect a user, the Disconnect-Request message must contain an attribute with a session ID. The Disconnect-Request message can contain an Acct-Session-Id (44) attribute or a Acct-Multi-Session-Id (50) attribute for the session ID or both. If both the Acct-Session-Id and Acct-Multi-Session-Id attributes are present in the request, the router uses both attributes. If the User-Name (1) attribute is also present in the request, the username and session ID are used to perform the disconnection. Authentication, authorization, and accounting (AAA) services handle the actual request.

Note: The inclusion of the Acct-Multi-Session-Id (50) attribute in RADIUS Disconnect-Request messages for LAC L2TP sessions causes the disconnection of L2TP LAC user sessions to occur properly. The value of this attribute is constructed from the Acct-Session-ID (44) attribute of the first PPP link established for MLPPP bundles. If the Acct-Multi-Session-Id (50) attribute is contained in the Disconnect-Request message for MLPPP links, which are on the LAC side of an L2TP tunnel, the subscriber session is disconnected.


The RADIUS server (the disconnect client) must calculate the authenticator as specified for an Accounting-Request message in RFC 2866. The router’s RADIUS dynamic-request server verifies the request using authenticator calculation as specified for an Accounting-Request message in RFC 2866. A key (secret), as specified in RFC 2865, must be configured and used in the calculation of the authenticator. The response authenticator is calculated as specified for an Accounting-Response message in RFC 2866.

Related Documentation