Summary of Allowed Elements in the deviceModels.xml File
Table 112 describes the elements allowed in the deviceModels.xml file.
Table 112: Allowed Elements in the deviceModels.xml File
This release of Steel-Belted Radius Carrier only supports actions that can be expressed as a RADIUS CoA, DM, or PoD requests. It also supports the special action of querying the current sessions table (CST), and returning its contents. All actions must be of type radiusRequest or localSessionQuery. An action request includes some number of attributes, which can be key attributes used to find the session, or action attributes that instruct the device what to do (disconnect, change, and so forth). You can invoke an action through Web GUI, command line utility, or through an XML request sent over the HTTPS port. Any XML application used to issue CoA/DM must conform to the XML interface described in XML over HTTPS Interface.
Contains the list of actions that can be performed against this device model. Different packing lists of AVPs (attribute-value pairs) that cause a particular effect, such as reconfiguring a user's bandwidth or disconnecting a user.
Note: Actions should be named carefully so that equivalent actions defined against different device models have the same name.
Contains the actual attribute packing list for the RADIUS request. Each required attribute listed here must be populated from either the client request or the contents of the CST for each session. There are also default and override attributes that can be defined, which are explained in the respective sections.
Note: Subattributes are not supported in CoA/DM actions.
Defines the model for a controlled device object. The controlledDeviceModel is used only if a NAS is configured that has a vendor-product matching the id attribute of this element.
The dictionary attribute must be set to the name of one of the dictionaries in the radius directory.
The vendor attribute is used only in logging; you must set the attribute with a descriptive value.
As shown in the schema in Element: controlledDeviceModel, the controlledDeviceModel is defined in terms of a set of RADIUS ports and a set of actions. The attributes for the controlledDeviceModel are:
Defines models for a controlled device object.
May be populated either by finding it in the CST or in the client request (action). If it cannot be found, the attribute is populated from the default value specified here.
A special action type that uses the attributes specified in the client request, such as User-Name="bo*", to query the current session table (CST). Any matching sessions, up to the currently active safety limit, are returned as the response to the request. No change is made to the session records and no RADIUS request is sent.
Session times out.
Always set to the value specified in this element, even if it was found in the CST, or in the (action) client request. It can be used to specify constant values that need to be present in the CoA or DM request. For example, an action for a lawful intercept might require that a VSA always be present in the request with the value enable intercept.
Defines a named RADIUS port on which the device receives CoA/DM or PoD requests. The names of these ports are then referenced in the action declarations, so that different actions can be routed to different port numbers.
Note: The implementation of this element is limited in that each RADIUS port must be named either "RFC3576" or "CiscoPOD" so that at most these two ports exist for each device model.
Defines named RADIUS ports where the device receives CoA/DM or PoD requests.
An action type used to define CoA, DM, and PoD requests. When such an action is executed, the attributes specified in the request, such as User-Name="bo*", are used to query the current session table (CST). Any matching sessions, up to the currently active safety limit, are processed by the CoA/DM engine. Using the attributes present in the request, plus any attributes found in the session record for each session, the CoA/DM engine tries to satisfy the attribute packing list for this request. If it can do so, then the RADIUS request is formatted and sent to the device.
As shown in the schema in Element: radiusRequest, the radiusRequest is defined in terms of an attributes section, which is required, plus three optional sections, which define the behavior of the server in the event that the request fails, times out, or succeeds. The attributes section is the actual attribute packing list for the request.
Must be populated either by finding it in the CST or in the (action) client request. If it cannot be found, the action fails.