Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

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

    SIC Editing Rules (SRC CLI)

    Before the SIC sends the request to the specified accounting or authentication target, the request can optionally be edited according to the editing rules associated with the selected routing rule. Editing rules are similar to routing rules, in that the request is examined for matching conditions, and if one is found, the request is edited and then sent to the accounting target.

    In addition to editing RADIUS attributes, the SIC can edit transactional variables and literals. Editing rules can define new transactional variables, in addition to certain built-in variables such as the result of username parsing, network access server (NAS) client lookup, and so on. Transactional variables are also referenced in the columns of the subscriber sessions table in the SSR database, thus allowing you to store the results of request processing and editing in the subscriber sessions table.

    Note: You can control the number of transactional variables the SIC supports. The default value is 255. When you change this limit, you need to restart the SIC.

    Figure 1 depicts the SIC editing rule process.

    Figure 1: SIC Editing Rule Process

    SIC Editing Rule Process

    You configure editing rules by defining the source and its associated match conditions, the editing conditions applied to the source value, and the target in which the edited result is placed. First, the SIC examines the specified source in the request for the defined match conditions. If all conditions are found to be true, the SIC edits the source value based on the defined editing conditions. The result is then placed in the defined target. The edited request, including both the original source and the new target value, is sent to the target.

    Each editing rule is a simple assignment of a source (RValue) and a target (LValue). In any assignment the target can be one of the following:

    • Transactional variable
    • RADIUS attribute in the request
    • RADIUS attribute in the response

    The source can be one of the following:

    • Literal
    • Transactional variable
    • RADIUS attribute in the request

    The match conditions that you can test for in the source include whether a specific realm, user identity, or request attribute is:

    • Present
    • Not present
    • Equals
    • Does not equal
    • Has suffix
    • Has prefix
    • Within range

    If a match condition is found on the source, you can append or replace the value of the source and place it in the target.

    Additionally, if the source is a request attribute, you can edit the value of the source by removing the suffix or prefix, or removing what is before or after the @ and place the result in the target. The remove before @ and remove after @ options can contain wildcards.

    For example, if the request contains

    • Removing the prefix john results in:
    • Removing the suffix .net results in: johnsmith@abcd
    • Remove the attribute before the @ results in:
    • Remove the attribute after the @ results in: johnsmith

    The SIC supports binary-level editing as follows:

    • When a source attribute is of an octets type in the dictionary, the value of the attribute is encoded in hexadecimal format with a {hex} prefix. Operations including remove-before, remove-after, remove-prefix, and remove-suffix for such attributes work on their hexadecimal format. The search pattern used by the preceding operations must also use the hexadecimal format. For example, if the source string contains “@” and you want to remove everything after “@”, the search pattern is 40, which is the ASCII number of @.
    • A remove-before operation on an octets type attribute puts the {hex} prefix after the operation. A remove-prefix operation on an octets type attribute must include {hex} in the search pattern and the {hex} prefix is not added back after the operation. If you want to keep the {hex} prefix, use the remove-before operation.
    • When converting an octets type attribute to another type, the SIC first tries to convert the attribute by using the binary representation of the target type. For example, the ip-address type attribute uses four octets. If the source attribute also uses four octets, the conversion is successful.
    • If the binary conversion is not successful, the SIC tries the conversion using a printable string representation. For example, the printable format for the ip-address type attribute is "x.x.x.x". The conversion fails if the octets attribute value does not follow the printable format of the target attribute.

    Figure 2 depicts the editing rule process and the accounting route selection process. Authentication requests can also use this editing process. The target for authentication requests is always a downstream network element that includes an AAA server target.

    Figure 2: Editing and Accounting Routing Rule Conditions and Processes

    Editing and Accounting Routing
Rule Conditions and Processes

    Example of an editing rule:

    • If Unisphere-Virtual-Router is present, then the transactional variable vpn-id is the substring after “:” in Unisphere-Virtual-Router.
    • If NAS-Identifier is nas3, then the transactional variable vpn-id is the realm portion of User-Name (realm transactional variable). Otherwise, the transactional variable vpn-id is the NAS-Identifier.
    [edit shared sic group group1 editing edit1] 
    user@host# show 
    target {
    variable vpn-id;
    source {
    request-attribute Unisphere-Virtual-Router {
    condition {
    attribute Unisphere-Virtual-Router;
    remove-before *:
    	variable realm {
    condition {
    attribute nas-identifier;
    equals nas1;
    default {
    request-attribute nas-identifier ;

    Published: 2014-12-10