Configuring ISG Control Policies
Information About ISG Control Policies
3
3. Apply the control policy map.
A control policy map is activated by applying it to a context. A control policy map can be applied
to one or more of the following types of contexts. In the following list, the context types are listed
in order of precedence. For example, a control policy map that is applied to a PVC takes precedence
over a control policy map that is applied to an interface.
–
Virtual template
–
Subinterface
–
Interface
–
Global
In general, control policy maps that are applied to more specific contexts take precedence over
policy maps applied to more general contexts.
Note Traffic policies are another type of policy used by ISG. Traffic policies define the handling of data
packets and are configured in service policy maps or service profiles. For more information about traffic
policies, see the “Configuring ISG Subscriber Services” module.
Differentiated Initial Policy Control
Authentication failure for a subscriber may happen for an access-reject (which means a RADIUS server
responded with a Reject) or due to an access request timeout (RADIUS server is unreachable).
Using ISG control policies, and actions configured for the 'radius-timeout' and 'access-reject' events, the
system can distinguish between the different reasons for an authentication failure. Different events are
thrown by the system (for example, a received authentication reject or an unavailable RADIUS server
event). This allows the control policy to specify different actions for each type of authentication failure.
For example, if the RADIUS server is down or unreachable, temporary access can be given to
subscribers.
This feature is available only for IP-based sessions for subscriber authentication. This feature does not
support the Point-to-Point Protocol over Ethernet (PPPoE) sessions.
Uses of Control Policies
Use control policies to configure an ISG to perform specific actions in response to specific events and
conditions. For example, control policies could be used for the following purposes:
• To activate a default service when a subscriber session is first detected
• To sequence the gathering of subscriber identity, where a control protocol exists on the access side
• To determine how the system responds to an idle timeout or to a subscriber who has run out of credit
• To enable transparent auto logon, which enables authorization on the basis of an IP address or MAC
address
• To configure the maximum amount of time a session can remain unauthenticated
• To send periodic session state information to other devices