Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    Device and Service Template Configuration Overview (SRC CLI)

    To configure dynamic authorization using the SIC you need to configure:

    • Device template—Specifies the router make, model and capability.
    • Service template—Specifies any services that you want to enable for your router. What services are available vary from router to router, so it is important that you understand the properties of your router to successfully implement custom services.
    • Global service template—Specifies rendering used as part of any mode of any service template. Global service templates are used to control rendering of service-independent requests, such as Abort-Session. A global service template is unique in that its modes, attributes, and variables are available to all services that you define. Global service templates are therefore a mandatory part of any SIC COA configuration.

    Device Template Configuration Overview (SRC CLI)

    Device templates specify the activation behavior of services and how the router handles multiple requests.

    To configure device templates, you specify the capability and its associated value. The associated value is dependent on the specified capability. Table 1 describes the available capabilities and associated values.

    Table 1: Device Template Capabilities and Associated Values

    Capability

    Value

    Activation—Specify service access/activation behavior.

    None (default value)—Indicates that the router is not capable of activating services during initial authorization or activation.

    Access-Accept—Indicates that the router supports activating services only in RADIUS Access-Accept messages.

    CoA—Indicates that the router supports activating services in COA only.

    Both—Enables both Access-Accept and COA requests.

    Modification—Specify service modification behavior.

    False (default value)—This attribute must be set to false.

    Bundle—Indicates whether and how the router handles multiple service activation/deactivations in one COA.

    None (default value)—Indicates no bundling.

    Single—Indicates the router accepts multiple requests.

    Service and Global Service Template Configuration Overview (SRC CLI)

    Service templates specify any services that you want to enable for your router. What services are available vary from router to router, so it is important that you understand the properties of your router to successfully implement custom services.

    Global service templates specify rendering used as part of any mode of any service template. Global service templates are used to control rendering of service-independent requests, such as Abort-Session. A global service template is unique in that its modes, attributes, and variables are available to all services that you define. Global service templates are therefore a mandatory part of any SIC COA configuration.

    You need to configure the following items for both the service and global service template:

    • Mode
    • Attributes
    • Variable

    Mode

    Service and global service templates have groups of data called mode that each service must specify. A mode contains attributes and variables, which are explained in the next sections. It is mandatory to configure the mode for each service and global temple. You must use the provided modes; you cannot create new modes.

    Table 2 lists the modes and attributes for global service templates.

    Table 2: Service Template Modes

    Mode

    Description

    Activation

    Activates services on request from the SAE.

    Deactivation

    Deactivates services on request from the SAE.

    Initial-Authorization

    Initial activation of services in the Access-Accept message.

    Service-Correlation-Id

    Assigns an ID number when any other mode is initiated. The SRC software uses this identification number internally.

    Service-Profile-Download

    Used for Cisco routers only. See Caveat (Cisco Only).

    Table 3 lists the modes and attributes for global service templates.

    Table 3: Global Service Template Modes

    Mode

    Description

    Authentication

    Use this mode for optional rendering of the request in the case of an Initial-Authorization. Usually this mode is empty, since no additional rendering is required.

    Unlike modes in service templates, this mode renders requests to the SRC software and not to the router.

    Accounting

    Use this mode to control the rendering of the accounting request sent to the SAE. Accounting is a post-authorization service, and it uses the ID numbers and names from the service activation rendering.

    Abort-Session

    Use this mode for rendering of RADIUS disconnect request (DM) upon abort session request from the SAE.

    Caveat (Cisco Only)

    Cisco routers require an additional step to complete service activation. When the SIC activates a service on a Cisco router, the router sends an extra Access-Request to the SIC to retrieve the service profile. The SIC then sends back an Access-Accept response with VSAs representing the service profile. In response to the extra Access-Request, the SIC has to send all VSAs generated by the previous rendering process. The router then activates the service. This means that the SIC has to render the activation twice. In the second rendering a special mode, Service-Profile-Download is used.

    This activation process is different from the usual scenario. Extra Access-Requests happen prior to the SIC response to an SAE request. Therefore, you can minimize the first rendering and place most of the work on the SAE download mode by doing the following:

    The Service-Profile-Download mode in the supplied Cisco router configuration template is used to render the answer to the Cisco Profile Download request. The Initial-Authorization or Activation modes are used to render the first Access-Accept or COA message in the packet. To comply with the Cisco requirement to have only the service name in the first Access-Accept or COA message, the Initial-Authorization or Activation modes should contain the attribute for the service name only, and the rest of parameters should be specified using the shared sic group identifier device-template id service-template name mode service-profile-download statement.

    • In the activation mode, specify only the service name.
    • In the service-policy-download mode, specify the rest of the needed parameters.

    See your Cisco documentation for more information.

    Attributes

    All modes have attributes. Attributes define which RADIUS attributes are generated as a result of rendering. All attributes create data that appears in the RADIUS attributes (such as VSAs) generated by the rendering process. It is important to understand that modes are the very core of the rendering process.

    Table 4 lists the attributes, explains their parameters, and describes their behavior.

    Table 4: Attributes for All Modes

    Attribute

    Description

    required

    If the renderer finds the attribute in the downstream AAA server response, it copies the value into the RADIUS message for the router. Otherwise, the rendering fails.

    Options
    • name name—Name of the attribute. The specified name must match a defined RADIUS attribute in the downstream AAA server response.
    • copy-from copy-from—(Optional) Specify the name of the attribute to copy the value from. If the copy-from option is specified, the renderer looks up the attribute specified by copy-from option in the downstream AAA Server response. In the absence of copy-from option, the renderer looks up the attribute specified by the name option.

    override

    Whether or not the renderer finds the attribute in the downstream AAA server response, it creates the attribute name with the specified value.

    Options
    • name name—Name of the attribute. The name must match a defined RADIUS attribute in the downstream AAA server response.
    • value value—Set the attribute to this value.

    default

    If the renderer finds the attribute in the downstream AAA server response, it copies the value into the RADIUS message. Otherwise, it creates the attribute name with the specified value.

    Options
    • name name—Name of the attribute. The name must match a defined RADIUS attribute in the downstream AAA server response.
    • value value—Set the attribute to this value.
    • copy-from copy-from—(Optional) Specify the name of the attribute to copy the value from. If the copy-from option is specified, the renderer looks up the attribute specified by copy-from option in the downstream AAA Server response. In the absence of copy-from option, the renderer looks up the attribute specified by the name option.

    normal

    If the renderer finds the attribute in the downstream AAA server response, it copies the value into the RADIUS message for the router. Otherwise, no action occurs. Unlike required-attribute, the rendering does not fail in this case.

    Options
    • name name—Name of the attribute. The specified name must match a defined RADIUS attribute in the downstream AAA server response.
    • copy-from copy-from—(Optional) Specify the name of the attribute to copy the value from. If the copy-from option is specified, the renderer looks up the attribute specified by copy-from option in the downstream AAA Server response. In the absence of copy-from option, the renderer looks up the attribute specified by the name option.

    parameterized

    The most powerful and flexible part of the template. It generates attribute values using a format specification, which makes it the most flexible of the attributes.

    Options
    • name name—Name of the attribute. The specified name must match a defined RADIUS attribute in the downstream AAA server response.
    • format format—In a form of "$(p1) $(p2) ... $(pn) [$p(n+1)]". Behaves much like sprintf in C; you can intersperse literal text in between parameter definitions. Unlike sprintf, format supports an optional parameter definition. If the optional parameter is absent, it, and any literal text included in the square brackets, is ignored.
      All parameters come from the SAE as input to rendering.

      If you need to use restricted characters in your strings, use the backslash convention: \$, \’, \", \[, \], \(, \).

    Variables

    Modes can also have variables, which control the rendering process. Variables are subtags under modes. You can use them to render information that is not part of RADIUS attributes. They provide inner logic for the rendering process. Nothing defined by variables appears in VSAs sent to the router.

    Variables have three configuration options, described in Table 5.

    Table 5: Variables

    Option

    Description

    name

    The variable name

    value

    The value, usually an integer

    type

    The data type, integer or string

    A rule for processing variables: while rendering, when the SIC encounters a variable with a new value, and that variable already has a different value, the rendering stops and sends the results to the SAE. The SAE generates a RADIUS message and resumes rendering with the new value. Thus, it creates two VSAs, one each for the variable values. This correlates with the Bundle capability.

    Overriding the Service Correlation ID

    You can also use variables to override the service-correlation-id mode. For example,

    variable name= "CreateServiceCorrelationId" value="0"

    overrides the service-correlation-id mode, so no identification number is created.

    Tagged Attributes

    The SIC supports tagged attributes, which are an extension of the RADIUS protocol. Refer to RFC 2868 (http://www.ietf.org/rfc/rfc2868) for a description of this feature.

    If you have bundle=single and you want to send a single COA activating two services, these activation requests must have the same RADIUS attributes, but with different values. To discriminate between attributes from two separate activation requests, you must use a unique tag for each.

    Specify tagged attributes using the shared sic group identifier device-template id service-template name mode (activation|deactivation|initial-authorization|service-correlation-id|service-profile-download) attributes tagged-group name statement.

    Note: Each service template is restricted to have only one tagged group; for attributes configured under the tagged-group, only attributes that support tags are affected. Otherwise, it has no effect if the configured attributes does not support tagging.

    The attributes described in Table 4 are also support for tagged attribute configurations.

    Published: 2014-12-10