Request Routing (SRC CLI)

SIC routing rules define how the SIC routes accounting and authentication requests. You configure routing rules for each server in the SIC group. There are two types of routing rules:

• Explicit routing rules
• Implicit routing rules

Explicit Routing Rules

An explicit route is a collection of criteria used to select a particular routing target. Explicit routing rules consist of a condition, or set of conditions, and an accounting or authentication target to which the request is to be routed. Routing criteria consist of a list of simple Boolean expressions on RADIUS attributes and transactional variables. The accounting target is a downstream network element that contains an AAA server. The authentication target is an AAA server in a downstream network element.

You specify explicit routing rules based on the following match conditions:

• Realm name
• User identity
• Request attribute

You can test the value of the match condition for the following conditions:

• Present
• Not present
• Equal
• Does not equal
• Has prefix
• Has suffix
• Range

The Has prefix and Has suffix condition tests work only on the string representation of the value. To test for a range condition, specify a low value and a high value. Figure 1 depicts the explicit routing rule process.

Figure 1: Explicit Routing Rule Process

When the SIC receives an accounting or authentication request, it evaluates any defined explicit routing rules in the order they were configured. When multiple routes are configured, they are evaluated in the order they are displayed by the show command. A newly created route is displayed last among the routes and has the lowest priority, so it is evaluated last. You can use the SRC CLI insert command to move a route before or after another route to change its evaluation order. The higher a route is displayed on the list, the sooner it is evaluated. For a route to be selected, all conditions of the rule must be true. If a match is not found, the next configured rule is examined, and so on. As soon as a rule with matching criteria is encountered, the iteration stops and the accounting or authentication target in that rule is selected as the destination for the request. If a match for all conditions cannot be found in the explicit routing rules, the implicit routing rules are examined.

Before the request is sent to the specified target, you can edit it by optionally specifying an editing rule for the accounting route.

An example of explicit routing rule is:

If the NAS-Identifier is nas2 then the target is accounting method method2, which is the proxy accounting method, pointing to the RADIUS network element rne1:

[edit shared sic group group1 accounting-method method2 proxy] 
user@host# show 
radius {
network-element rne1;
}
…
[edit shared sic group group1 server server1 accounting-route route2]
user@host# show
target method2;
condition {
attribute nas-identifier;
equals nas2;
}

This example is an accounting route example. Authentication routes work the same way.

Implicit Routing Rules

Implicit routes are realm based. You configure implicit routes by defining a network element that contains a remote AAA server and assigning it the proxy function. You can then either define a default route used for all requests from all realms or specify that only requests from specific realms are routed to the proxy AAA server. When you specify realms, you have the option to set a condition of either an exact match of the realm string, or a match on the prefix of the realm string.

Implicit routing rules have lower priority and are evaluated only if a match is not found for explicit routing rules. When a request is received, the SIC server evaluates the associated routing rules. First, the server evaluates any explicit routing rules. If no match is found, the server evaluates the implicit routing rules. When a match is found, the server processes the request by routing it to the specified network element that has the proxy function assigned to it.