Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 
  
[+] Expand All
[-] Collapse All

How Steel-Belted Radius Carrier Processes CoA/DM Messages

To process CoA/DM requests, you need to:

  • Identify the session you want to modify, delete, or disconnect
  • Format the CoA/DM request with the correct attributes and send the request to the NAS

Current Sessions Table

Steel-Belted Radius Carrier dynamically maintains a list of all active sessions in the Current Sessions Table (CST). The CST contains one record (row) for each session created or updated by the server. Each record contains fields that uniquely identify the session. These fields generally include identification information such as the NAS device (NAS-Port-Type), port number (NAS-Port), or session identifier (Acct-Session-Id).

The information stored in the CST is customizable. To ensure that you can identify sessions accurately and format CoA/DM requests with the appropriate attributes for the services you are supporting in your network, we recommend that you customize the information stored in the CST for your particular network environment. For example, before you retrieve a value from the CST for use in an attribute in a CoA message, you must first map the CST field to a RADIUS attribute in the dbc_mapping.xml file. In the following example, the FunkOuterUserName field is mapped to the Original-User-Name attribute using the attribute element to enable retrieving the value in the FunkOuterUserName field as a result of a session control request. The queryAttribute child element is used for indexing the CST while querying sessions using the SessionControl.sh script or Web GUI. If you want to query sessions using the attribute, then you need to specify the attribute in the queryAttribute child element.

<attributeMapping field="FunkOuterUserName" attribute="Original-User-Name">
<queryAttribute name="Original-User-Name"/>
</attributeMapping>

This guide assumes that your site’s CST is configured properly, and that it contains all relevant key information required to identify sessions and issue CoA/DM requests properly. For details about customizing the CST, see the SBR Carrier Installation Guide.

Formatting and Sending CoA/DM Requests with the Correct Attributes

Each NAS sending Access-Request messages to SBR Carrier must be defined as a client in SBR Carrier. When configuring client devices in SBR Carrier, you must define the model of the client device. Device model selections are defined by specifying the vendor-product parameter in the [Vendor-Product Identification] Section of the vendor.ini file. For each product listed in the vendor.ini file, SBR Carrier provides .dct (text) and .dic (xml) dictionary files. The dictionary files define the attributes SBR Carrier requires in messages it receives from a specific type of device, and the attributes to include in responses to that device.

To support CoA/DM, you need to configure a similar file that defines what attributes are included in CoA/DM requests and responses. The deviceModels.xml file defines the CoA/DM actions supported by the client devices in your network. CoA/DM actions are different packing lists of attribute value pairs (AVPs) that cause a particular effect, such as disconnecting a user (DM request) or reconfiguring a user bandwidth (CoA request). The deviceModels.xml file comes preconfigured with CoA/DM action templates for certain devices. However, you need to define CoA/DM actions in the deviceModels.xml file for each client device in your network that you want to support CoA/DM requests. The supported CoA/DM actions may vary depending on the NAS type.

When you configure the model for the client device (network access server), the CoA/DM subsystem in Steel-Belted Radius Carrier searches the deviceModels.xml file for a corresponding controlledDeviceModel entry matching the Vendor-Product (defined in the vendor.ini file). If a matching definition is found, a controlled device object is created and configured, with the CoA/DM actions defined in the deviceModels.xml file. If no matching controlledDeviceModel entry is found, then no controlled device object is created, and no CoA/DM actions are supported for that client device. Figure 249 shows the structural overview of the CoA/DM process within Steel-Belted Radius Carrier.

Figure 249: CoA/DM Structural Overview

CoA/DM Structural Overview

CoA/DM requests can be issued to Steel-Belted Radius Carrier from several management clients including Web GUI and command line utility, or using a custom developed management application designed to connect with the Steel-Belted Radius Carrier XML interface. All CoA/DM client requests must be issued in the proper XML format as specified by this API. Refer to XML over HTTPS Interface for complete details of the API.

For each targeted session you want to dynamically change, the relevant NAS (controlled device object) is determined. Based on the device model information defined for the client device, the required packing list of attributes for the current CoA/DM request type is calculated. The packing list may vary based on the CoA/DM action requested, and the make/model of the device. Packing lists are configured in XML files similar to SBR Carrier dictionary files.

Note: A controlled device object is associated with a controlled device (network access device), only when the device supports RFC 3576 Change of Authorization (CoA), Disconnect Message (DM), or the Cisco proprietary Packet of Disconnect (PoD).

Converting .dct Files to .dic Files

The .dic dictionary files are the XML format of the .dct dictionary files. The .dic dictionary files identify the attributes SBR Carrier expects when receiving Diameter requests from a specific type of device or while sending a Diameter or COA/DM requests to a specific type of device. You can convert the customized .dct files to .dic files using the dct_to_dic_converter.sh script.

While converting .dct files to .dic files, make sure that all attribute values are defined immediately after the specific attribute definition in the .dct file. For example:

ATTRIBUTE Annex-System-Disc-Reason          Bay-VSA(44, integer)	
VALUE     Annex-System-Disc-Reason          Unknown             0
VALUE     Annex-System-Disc-Reason          Line-disconnected   1	
VALUE     Annex-System-Disc-Reason          Dial-failed         2

For more information about the .dic dictionary files, see SBR Carrier Reference Guide. To convert .dct files to .dic files:

  1. Execute the dct_to_dic_converter.sh script.
    ./dct_to_dic_converter.sh
  2. Enter the name of the .dct file to be converted to the .dic format.
    Enter the name of the .dct file which has to be converted to .dic format:
  3. Enter a name for the converted .dic file. By default, the .dic file is saved in the current directory. If you want to save the .dic file in a different directory, you can add the directory path along with the filename—for example, /tmp/radius.dic.
    Enter the filename to be used for naming the converted .dic file:

Controlled Devices and Actions

The controlled device object can support any number of actions such as disconnect. You must define each action you want to support in the deviceModels.xml file. We recommend you name each supported action generically so that different device models can all use the same name for the equivalent action. An action request includes some number of attributes, which can be key attributes used to find the session, or action attributes needed to instruct the device what to do.

For example, you can define the action disconnect with different attribute packing lists and different message types for various types of client devices. A Cisco Systems device might use a PoD message containing the attribute User-Name for the disconnect action. A Juniper Networks ERX device might use an RFC 3576 DM-request containing the attribute Acct-Session-Id for the disconnect action. However, by configuring the deviceModels.xml file with an entry for both the Cisco Systems device and the Juniper Networks ERX device, and defining an action called disconnect for each of these devices, you can simply invoke the action disconnect with the argument User-Name='bob', and the user session for bob is terminated regardless of whether it is found on the Juniper Networks device or Cisco Systems device.

In this example, the Juniper Networks ERX device requires the Acct-Session-Id for the DM-Request. The Acct-Session-Id attribute is looked up in the Current Session Table (CST). Therefore, we recommend you also configure the CST so that the required attributes are available from the session query to satisfy the packing list of each action supported by the device.

Note: The Acct-Session-Id attribute is commonly used in CoA/DM packing lists for router requirements. Packing lists represent the router’s requirements for a valid DM or CoA request. Attributes that are not in the CST must come from the actual query to fulfill the request. To have data available for queries, you must configure this attribute in the packing list. If the AcctSessionId does not exist in the CST or is not found by the query itself, the request fails.

Caution: Only edit the attribute packing lists (actions) in the deviceModels.xml file with the assistance of Juniper Networks Sales Engineering or Professional Services.

Modified: 2018-01-11