Table Of Contents
Cisco SSG-to-ISG DSL Broadband Migration Guide
Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images
ISG-SESM Broadband Migration Concepts
Next Hop Gateway and Tunnel Service Profiles
RADIUS Service and User Profile Attributes
SESM Requirements for RADIUS Service Profile Attributes
Basic ISG-SESM DSL Broadband and SSG-to-ISG Conversion Tasks
Configuring a Traffic Drop Policy
Verifying the Traffic Drop Policy
Testing the Traffic Drop Policy
Configuring ISG and SESM Interoperability
Verifying ISG and SESM Interaction
Configuring Pass-Through and Proxy Services in a RADIUS Profile
Configuring Pass-Through Service
Adjusting the Policy Control Map
Configuring Sequential Service Functionality
Configuring a Policy Map and Traffic Classifications
Configuring Advertisement and Initial Redirection
Configuring L2 Service Selection
Verifying L2 Service Selection
Special Note about Configuring a PTA-MD Exclusion List
SSG and ISG Accounting and RADIUS Update Examples
SSG Accounting Configuration Alternatives
SSG-to-ISG Migration of Prepaid and Postpaid Services Examples
SSG Basic Prepaid and Postpaid Time- and Volume-Based Services
ISG Basic Prepaid and Postpaid Time- and Volume-Based Services
SSG Dual Quota Prepaid Service
ISG Dual Quota Prepaid Service
SSG Tariff Switching: Postpaid Services
ISG Tariff Switching: Postpaid Services
SSG Tariff Switching: Prepaid Services
ISG Tariff Switching: Prepaid Services
SSG-to-ISG Migration Caveats and Workarounds
CSCuk56681—ISG Sending Locally Defined Service to Portal Breaks Status Page
CSCeg56118—ISG Sends Different Error Code than SSG for Proxy Service Activation Failure
CSCeh03451—Periodic Accounting on Flows Behaves Inconsistently in the ISG
CSCeh35036—Two Traffic Classes with L4 Redirect Do Not Work
CSCsa86854—Log Function on ACL Breaks Traffic Classification
ISG Network Configuration Example
Cisco SSG-to-ISG DSL Broadband Migration Guide
First Published: April 27, 2005Last Updated: January 21, 2009Intelligent Service Gateway (ISG) is a Cisco IOS software feature set that provides a structured framework in which edge devices can deliver flexible and scalable services to subscribers. This document provides information and procedures to migrate broadband components from the
Cisco Service Selection Gateway (SSG)—a Cisco IOS software feature set that works with the
Cisco Subscriber Edge Services Manager (SESM) and other components to provide a subscriber edge services solution—to the Cisco Intelligent Service Selection Gateway (ISG) and updated SESM feature software.This document is intended for network engineers migrating an SSG-based deployment to an ISG-based one. It is expected that the user of this document is knowledgeable about Cisco IOS and SSG software.
For this phase of SSG-to-ISG migration, only digital subscriber line (DSL) network migration has been tested and is supported. Migrating deployments such as wireless LAN (WLAN) and general packet radio service (GPRS) will be described at a later time in separate documents.
Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•ISG-SESM Broadband Migration Concepts
•Basic ISG-SESM DSL Broadband and SSG-to-ISG Conversion Tasks
•SSG and ISG Accounting and RADIUS Update Examples
•SSG-to-ISG Migration of Prepaid and Postpaid Services Examples
Prerequisites
Cisco IOS ISG Feature Set
Cisco IOS software is packaged in feature sets that are supported on specific platforms. The Cisco ISG software is supported on Cisco 7200, 7300, and 10000 series routers. To get updated information regarding platform support and ISG feature sets, access Cisco Feature Navigator at http://www.cisco.com/go/fn.
To access Cisco Feature Navigator, you must have an account on Cisco.com. Qualified users can establish an account on Cisco.com by following the directions at http://www.cisco.com/register. If you have an account but have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you.
Backup Cisco IOS SSG Image
To be able to revert to your current SSG image, you must store your latest SSG configuration on a server. Once you load the ISG software and save a configuration, you will lose all SSG commands and all SSG references in the startup configuration file. To go back to an SSG image, reboot the router with the saved SSG image and load the stored SSG configuration from the server into the router again.
ISG Overview
Figure 1 shows the SSG software architecture, where services are essentially a dynamic route that is installed for a subscriber when a given service is activated by combining a list of IP subnets with an uplink interface binding. Connections are destination-based only and do not take full advantage of routing capability available from the Cisco IOS software. Packets destined to and from the destination zone, as defined by a particular SSG service, are considered to flow through a service connection, and features associated with a particular service, that is, specified in the service profile, are applied only to those packets.
Figure 1 Cisco SSG Architecture
The ISG software provides a structured framework in which access edge devices can deliver flexible and scalable services to subscribers. Figure 2 shows the architecture that represents the new model for offering subscriber services from access edge devices. For the ISG, a service is a collection of features that are applicable to a subscriber session. The service is not necessarily associated with a destination zone or a particular uplink interface.
Figure 2 Cisco ISG Architecture
The traffic classification component of the ISG model is a set of criteria by which a traffic stream can be refined. A traffic class is specified by means of an access control list (ACL), and would be defined for, as an example, all User Datagram Protocol (UDP) packets or all packets destined to a particular subnetwork.
The network service is a forwarding mechanism that defines how packets are forwarded or received for a given session. Flow in the ISG software refers to a session's data stream as it has been identified by a classifier. The classifier categorizes data packets based on attributes of that packet, and classifiers are evaluated in a deterministic manner that ensures that a packet is assigned to exactly one category.
The result of configuring an ISG is a collection of powerful and dynamic policies that can be applied to the subscriber session. The new policies are a superset of the SSG concept of a service. With the ISG software, new subscriber rules allow you to build policies based on conditional events and by triggering service actions. Services can be implemented within virtual routing contexts.
The dynamic policy enforcement inherent in the ISG software allows consistent, tailored, and secure user services to be deployed in the network, triggered by a service or by a user—concepts referred to in the ISG as push and pull.
The ISG has the ability to initiate and manage sessions consistently, regardless of the access protocol type, network service, or session traffic policies configured. The ISG software provides seamless integration with existing Cisco IOS IP services such as Domain Name System (DNS), quality of service (QoS), ACLs, Dynamic Host Configuration Protocol (DHCP), VPN routing and forwarding (VRF) instances , and Multiprotocol Label Switching (MPLS).
The ISG software also provides better accounting of services for both use and application, and for advanced accounting for services such as prepaid. You will also find enhanced distributed conditional debugging that provides the ability to monitor and debug sessions and services based on identity.
ISG-SESM Broadband Migration Concepts
When migrating a network from SSG to ISG, the process is not a one-to-one mapping of commands but, rather, involves implementing the right policies to emulate the behavior on the Cisco SSG.
The following sections are provided to compare SSG-to-ISG functionality, identify similarities and differences, and introduce new concepts and commands that will help you move to the ISG architecture.
ISG Features
An ISG feature is a functional component that performs a specific operation on a session's data stream. A feature may or may not be associated with a classifier. However, once associated with a classifier, a feature can be applied only to the packets that match that classifier. Otherwise, the feature is applied to all packets for that session. Features are divided into data-path and nondatapath-related functionality. Datapath-related features include Port-Bundle Host Key (PBHK), Layer 4 (L4) Redirect, Subscriber ACLs, Idle Timer, Session Timer, QoS, Session and Service Accounting, and Prepaid. Nondatapath-related features include IP configurations (address pool, VRF, IP address), and network service types or groups.
Dynamic Feature Updates
The ISG software supports dynamic updating of features for an existing ISG session. This update can be triggered by the actions of either a subscriber or an administrator. Once a session has been updated in this way, any existing configuration for the given feature is overridden, and the updated configuration can be altered only by another dynamic feature update.
SSG and ISG Services
A service on the SSG is a dynamic destination route that is installed for a subscriber when a given service is activated. Uplink commands are required to bind a service to an interface, and to indicate to the SSG where to find the destination route.
A service on the ISG is a collection of features that are applied to a subscriber session, with a session defined as a set of states associated with traffic for a single subject such as a user, client, subscriber, router, or interface. Unlike the SSG, there is no concept of binding a service to an interface on the ISG. An ISG service is not necessarily associated with a destination zone or a particular uplink interface and, therefore, makes no attempt to override the routing functionality provided by the Cisco IOS software. Because ISG services use Cisco IOS routing software, the services inherit routing capability like uplink redundancy, load-balancing across uplink interfaces, and MPLS integration. In this way, ISG services become value-added bundles that are more intuitive than SSG services.
The ISG software introduces the concept of network services, of which there are two types: packet forwarding and packet routing. A network service can be specified in a user profile and on an interface. For each subscriber session, only one instance of a network service can be specified at any point in time. The type of network service that is selected depends upon the presence of either a VRF-related or virtual private dialup network (VPDN) attribute in what is called a primary service.
When a network policy is included in a service profile or service policy map, the service is known as a primary service. Primary services are mutually exclusive, that is, only one instance of a network policy containing a primary service can be active per subscriber. The ISG software also offers nonprimary services, which can have dependencies on primary services. Both primary and nonprimary services can be configured remotely in a profile, or locally on the router.
ISG Policies
A service profile on the ISG software includes event policy control using control policy maps. The policy maps control what actions are triggered for the subscriber using an event and class combination. The ISG software can also control traffic inside the flow and take specific measures on the traffic using service policy maps. The service policy maps make decisions about what actions to take on the traffic and are triggered by a control policy map. For example, it is a policy that associates a feature with a classifier. A service policy map combines an action and a feature. Service policies can be configured both remotely (in most cases), and locally.
A control policy map is a collection of rules that describe what action to take under what circumstances. It is declared from a set of predefined events, operands, match operators, and actions that provide precise rules of behavior. These declarations can be defined in many ways to provide powerful solutions to the needs of the service provider. A control class builds the conditions that identify particular characteristics of the subscriber session, and has an extensive list of classifications that can be used to identify session characteristics such as authentication, domain name, media, port, protocol, address, and username. A control policy map combines an event and an action. Control policies are configured locally using ISG commands.
ISG Traffic Classes
The ISG traffic class allows classification of session traffic into individual flows, and the application of other features on these flows. The traffic class creates instances for each of the traffic flows belonging to a subscriber, which allows the session-related capabilities of the ISG software to be applied on these flows.
All features configured in a traffic class service profile are applied to the flow defined by ACLs. Multiple traffic class service profiles with various features can be applied to a session. The service profile includes the direction, either inbound or outbound, to which the ACL is applied, and the priority of the traffic class. The priority is used to determine which ACL is first used for the match. Once a match is made, features defined in the traffic class service profile will be executed for that traffic class. Packets that do not match any of the ACLs are considered to be part of default traffic and are processed as if a traffic policy was not applied to the session. When a packet matches more than one traffic class, it is classified in the class with the highest priority. Features in the latest applied service profile with overlapping classification information, as in an earlier service profile, are given priority. Additionally, any traffic class you define receives the highest priority when no priority is given and, if you have overlapping destinations in several traffic classes applied to a subscriber's session, the traffic will always match the traffic class that has been applied the longest to the session.
The default behavior of traffic class services can be changed such that all default traffic is dropped. One of the first migration tasks described later in this document is to make sure that, for all PPP over Ethernet (PPPoE) sessions, you restore the default SSG behavior of dropping an unauthenticated packet by inserting a traffic drop action in a traffic class. A service policy map or service profile that contains a traffic class is called a traffic policy. Although you can specify the events that trigger an ISG control policy, the trigger for a traffic policy is the arrival of a data packet.
Besides local traffic class policies, traffic classification can be configured remotely in a RADIUS profile using Cisco attribute-value (AV) pairs and in ACLs that have been configured on the ISG.
SSG-to-ISG Feature Map
Once you load the ISG software, you will remove all SSG commands and configurations. No automatic conversion is done to restore SSG functionality with ISG commands. Use Table 1 to help you map SSG-to-ISG features. Find the Cisco IOS documentation section listed in Table 1 in either the ISG Configuration Guide or in this document. If you are viewing an electronic version of this document, click the highlighted titles to display information about a feature.
Table 1 SSG-to-ISG Feature Map
ISG Feature Cisco IOS Documentation Section Related SSG Feature Accounting•Per Session, Service, and Flow
•Postpaid
•Configuring ISG Accounting chapter
•"ISG Tariff Switching: Postpaid Services" section in this document
•SSG Accounting
•RADIUS Accounting Records Used by SSG
•Postpaid Tariff Switching
•Prepaid
•Tariff Switching
•Configuring ISG Support for Prepaid Billing chapter
•"Configuring Prepaid Service" section in this document
•"SSG-to-ISG Migration of Prepaid and Postpaid Services Examples" section in this document
•SSG Prepaid
•Prepaid Tariff Switching
Flow Control•Flow Redirect
•Redirecting Subscriber Traffic Using ISG Layer 4 Redirect chapter
•"Configuring Layer 4 Redirect" section in this document
•"Configuring Advertisement and Initial Redirection" section in this document
•Redirection for Unauthenticated Users
•Redirection for Unauthorized Services
•Initial Captivation
•TCP Redirect Access Control Lists
•Permanent TCP Redirection
•DNS Redirection
•Dynamic Rate Limiting
•Configuring ISG Policies for Regulating Network Access chapter
•Hierarchical Policing
Policy Control•Service Profiles
•Configuring ISG Subscriber Services chapter
•Services and Service Profiles
•DHCP Proxy
•—
•Cisco Policy Language
•Multidimensional Identity per Session
•Domain Based (Auto-domain, Proxy)
•Triggers (Time, Volume, Duration)
•Configuring ISG Control Policies chapter
•"Configuring Pass-Through and Proxy Services in a RADIUS Profile" section in this document
•—
•CoA
•Enabling ISG to Interact with External Policy Servers chapter
•—
Sessions•Port-Bundle Host Key
•Configuring ISG Port-Bundle Host Key chapter
•"Configuring ISG and SESM Interoperability" section in this document
•SSG Port-Bundle Host Key
•SSG Port-Bundle Host Key Functionality and Local Forwarding
•Transparent Autologon
•"Uses of Control Policies" section of the Configuring ISG Control Policies chapter
•SSG Transparent Autologon
•Per-Service Idle Timeout
•SSG Session Timeout and Idle Timeout
•L2/L3 Interface IP Session
•Protocol Event (DHCP)
•Configuring ISG Layer 3 Access chapter
•Configuring SSG Interface Direction
•VRF Transfer
•Configuring ISG VRF Transfer chapter
•—
•Single Sign-On
•Overview of ISG chapter
•"Single Sign-On in the ISG" section in this document
•Configuring SSG to Authenticate PPP Subscribers
Network Interface•IP Routed
•VRF-Aware MPLS
•L2TP
•—
Monitoring and Debugging•Advanced Conditional Debugging
•Session and Flow Monitoring
•Troubleshooting ISG with Session Monitoring and Distributed Conditional Debugging chapter
•—
RADIUS Profile Migration
One change for RADIUS profiles used by the ISG is that a more verbose style for defining attributes than was accepted in the SSG has been developed. The verbose style was adapted because it is self-documenting and more easily extended than the one- or two-letter cryptic formats used for RADIUS profiles on the SSG. Remember, however, that this change pertains only to those attributes used to define ISG-specific profiles. The ISG will continue to interpret SSG-equivalent user profile-related attributes, attributes that are interpreted by the SESM service selection web page, and vendor-specific attributes (VSAs) in accounting messages and prepaid authorization requests.
The following sections provide more specific details about the RADIUS profiles used by the SSG and the ISG:
•Next Hop Gateway and Tunnel Service Profiles
•RADIUS Service and User Profile Attributes
Service Profiles
Service profiles continue to be used by the ISG to define the services that subscribers can select from SESM service selection web page, as is the case for the SSG. Existing SSG service profiles can be reused on the ISG, although it may be necessary to add ISG attributes to the existing set of SSG service profiles. The SESM service selection web page and the SSG will read the legacy attributes and ignore the new attributes and, conversely, the ISG will read only the new attributes and ignore the legacy attributes. There are a couple of exceptions to this; see the notes about attributes that must remain in service profiles for ISG-SESM interoperability in the "SESM Requirements for RADIUS Service Profile Attributes" section. Also, on the SSG the number of services a subscriber can have is limited with the ssg maxservice command, and this command is not available on the ISG.
Service Group Profiles
Service group profiles are used only by the SESM service selection web page to identify a list of services belonging to a specific service group. That service group is, therefore, used only by the SESM service selection web page; the attributes to define the service group do not need to be converted in any way to allow the attributes to be interpreted by the ISG. No migration effort is required to adapt these specific profiles in a network topology with ISGs.
Subscriber and User Profiles
Subscriber and user profiles defined for the SSG remain the same for the ISG, and continue to define logon names and passwords, ACLs associated with each logon, and subscribed services for each logon.
Next Hop Gateway and Tunnel Service Profiles
Next hop gateway profiles are not used on the ISG. These profiles associate next hop gateway keys with IP addresses, and this service binding concept is not used on the ISG.
It is not possible for the ISG to convert tunnel service profiles used under SSG.
RADIUS Service and User Profile Attributes
Table 2, Table 3, and Table 4 list the SSG RADIUS and VSA attributes that are interpreted by the ISG and that are new for the ISG. If the attribute is still interpreted by the ISG, it is used in the same manner as on the SSG, as indicated in the "SSG Uses?" and "SSG Sends?" columns of Table 2. See configuration examples in this document and the ISG Configuration Guide, to learn more about the new attributes used to define ISG-specific profiles.
Table 2 RADIUS Service and User Profile Attributes
Attribute Type Attribute Code Function, or ISG Equivalent if Not Interpreted Interpreted by ISG? In User Profiles? In Service Profiles? In Service GroupProfiles? Accounting Required? Prepaid Service Authorizationand Reauthorization SESM Uses? SESM Sends? SSG Uses? SSG Sends?Account-Info
Aactivate-
service-nameAutomatically activates the named service.
Yes
Yes
No
No
No
No
No
No
Yes
No
Account-Info
Nservice-name
Makes service name available to subscriber.
Yes
Yes
No
Yes
No
No
Yes
No
No
No
Account-Info
Q[U|D]
QoS parameters for the session in both the Upstream and Downstream direction (feature push capabilities).
Yes
Yes
No
No
No
No
No
No
Yes
No
Account-Info
Vcookie
Specifies a cookie string for a service.
Yes
Yes
No
No
Yes
No
No
No
No
No
Account-Info
Hurl
Used only by SESM. Subscriber home page URL requested when the service is activated using the service selection web page.
No
Yes
No
No
No
No
Yes
No
No
No
Account-Info
$AA
Used only by SESM.
No
Yes
No
No
No
No
Yes
No
No
No
Account-Info
$FA
Used only by SESM.
No
Yes
No
No
No
No
Yes
No
No
No
Account-Info
$GA
Used only by SESM.
No
Yes
No
No
No
No
Yes
No
No
No
Account-Info
$GA
Used only by SESM.
No
Yes
No
No
No
No
Yes
No
No
No
Account-Info
$GB
Used only by SESM.
No
Yes
No
No
No
No
Yes
No
No
No
Account-Info
$PE
Used only by SESM.
No
Yes
No
No
No
No
Yes
No
No
No
Account-Info
$SA
Used only by SESM.
No
Yes
No
No
No
No
Yes
No
No
No
Account-Info
$SB
Used only by SESM.
No
Yes
No
No
No
No
Yes
No
No
No
Account-Info
$SL
Used only by SESM.
No
Yes
No
No
No
No
Yes
No
No
No
Account-Info
$UG
Used only by SESM.
No
Yes
No
No
No
No
Yes
No
No
No
Account-Info
Ggroup-name
Used only by SESM. Specifies that subscriber can make use of this service group.
No
Yes
No
No
No
No
Yes
No
No
No
Account-Info
Igroup-name
Used only by SESM. Specifies name of service group to SESM.
No
No
No
Yes
No
No
Yes
No
No
No
Account-Info
TE
Used only by SESM. Specifies whether services in a service group are mutually exclusive.
No
No
No
Yes
No
No
Yes
No
No
No
Account-Info
R[I|S|A]
In SSG, specifies TCP redirection for SMTP, initial captivation, or advertisement.
See the "Configuring Advertisement and Initial Redirection" section for more information.
No
Yes
Yes
No
No
No
No
No
Yes
No
Account-Info
S[IP-address | PBHK]
Subscriber identifier attribute.
Yes
Yes
No
No
No
No
Yes
Yes
Yes
Yes
Service-Info
Q[U|D]
Uplink and downlink subscriber policing (feature push capabilities).
Yes
No
Yes
No
No
No
No
No
Yes
No
Service-Info
B
MTU for SSG L2TP service.
No
No
Yes
No
No
No
No
No
Yes
No
Service-Info
E
Maximum service connections.
No
No
Yes
No
No
No
No
No
Yes
No
Service-Info
H
Used only by SESM.
No
No
Yes
No
No
No
Yes
No
No
No
Service-Info
N
Used only by SESM.
No
No
Yes
No
Yes
Yes
Yes
No
No
No
Service-Info
D
DNS server name.
No
No
Yes
No
No
No
No
No
Yes
No
Service-Info
G
Next hop gateway (service route); this SSG service concept is obsolete on ISG.
No
No
Yes
No
No
No
No
No
Yes
No
Service-Info
I
Used only by SESM. Service name to be displayed on SESM.
No
No
Yes
No
No
No
Yes
No
No
No
Service-Info
M[C|S]
Sequential service can be done using class control in a policy map where one service-start function causes another to stop.
No
No
Yes
No
No
No
Yes
No
Yes
No
Service-Info
O
Service domain.
No
No
Yes
No
No
No
No
No
Yes
No
Service-Info
PPW:tariff time:days
Postpaid tariff switch parameters.
Yes
No
Yes
No
No
No
No
No
Yes
No
Service-Info
PZSprepaid- server-definition
PZIvalue
SSG prepaid subattributes.
PZS defines prepaid server details to use for authorization.
PZI is used for interim accounting.
On the ISG, replace PZS with VSA `prepaid-config= prepaid-config- name'.
PZI is not supported on ISG.
No
No
Yes
No
No
No
No
No
Yes
No
Service-Info
R
Use traffic class. ACLs for traffic class must be defined on ISG and match the R value.
No
No
Yes
No
No
No
Yes
No
Yes
No
Service-Info
S
Service-info code for RADIUS server used for remote authentication.
Replace with Cisco AV pair "subscriber:policy-directive"
No
No
Yes
No
No
No
No
No
Yes
No
Service-Info
T[X|T|P]
Type of service: proxy (X), tunnel (T), or pass-through (P).
The SSG service concept is obsolete on the ISG.
No
No
Yes
No
Yes
No
Yes
No
Yes
No
Service-Info
Z
Prepaid service on SSG. On ISG, this attribute is replaced with the Cisco AV pair "prepaid-config= name" where name is the prepaid configuration named on the ISG. By default, there is always a default configuration name present on the ISG named default.
No
No
Yes
No
No
No
No
No
Yes
No
Service-Info
Vcookie
Service cookie.
Yes
No
Yes
No
No
No
No
No
Yes
No
Service-Info
Linterval
Accounting update interval.
See the "SSG and ISG Accounting and RADIUS Update Examples" section for more information.
No
No
Yes
No
No
No
No
No
Yes
No
Service-Info
Uname
Service user name included in accounting requests.
Yes
No
Yes
No
Yes
No
No
No
Yes
No
Service-InfoX
Appends the service name to the username during authentication as username@
servicename.No
No
Yes
No
No
No
No
No
Yes
No
Control-Info
QTvalue
QVvalue
QRnumber
QBbytes-used since-switch
QXseconds;
bytes;bytesQT defines TimeQuota.
QV defines Volume-based
Quota.QR defines Prepaid ReauthReason.
QB defines VolumeQuota (new allocation).
QX defines QuotaPostSwitch.
Function and use of these attributes remain the same for ISG as on SSG.
Yes
No
Yes
No
Yes
Yes
No
No
Yes
Yes
Control-Info
Ivalue-overflow;
valueIndicates the overflow value and value of I (input) bytes in accounting packets. The formula to calculate the exact byte count is value-overflow*4294967296 + value.
Yes
No
No
No
Yes
No
No
No
No
Yes
Control-Info
Ovalue-overflow;
valueIndicates the overflow value and value of O (output) bytes in accounting packets. The formula to calculate the exact byte count is value-overflow*4294967296 + value.
Yes
No
No
No
Yes
No
No
No
No
Yes
Control-InfoXPdomain
Only present in Access-Accept when SSG queries the RADIUS server for the list of domains to exclude with the PTA-MD exclusion feature.
No
No
No
No
No
No
No
No
Yes
No
Control-Info
Gname;
IP-addressDefines a table of keys and IP addresses that will be used as next hop gateway routers.
No
No
Yes
No
No
No
No
No
Yes
No
ISG-SESM Interoperability
The client-server relationship between the SESM service selection web page as RADIUS client and the Cisco gateway (both the SSG and ISG) as RADIUS server remains the same. Additionally, changes to SESM configuration are not required when migrating to ISG. Read through the following sections, however, to understand other changes that you may need to make to establish ISG-SESM interoperability.
•SESM Requirements for RADIUS Service Profile Attributes
Restoring ISG-SESM interoperability is described in the "Configuring ISG and SESM Interoperability" section.
Supported SESM Version
Version 3.2(2) of SESM software has been verified to work in the ISG.
SESM Requirements for RADIUS Service Profile Attributes
SESM activates only those subscriber services that include the R attribute in the authentication, authorization, and accounting (AAA) RADIUS profiles. The R attribute is required in service profiles on both the SSG and ISG that define subscriber services that will be exposed in the SESM service selection web page However, nonsubscriber services that are defined only on the ISG itself and will not be exposed in the SESM service selection web page, such as PBHK and L4 redirection, are defined in a service profile without the R attribute.
The TX attribute is also required in proxy service profile definitions on the ISG; otherwise SESM will not manipulate the proxy service definitions correctly and the service login page will not be presented.
No Default Network
The concept of a default network does not exist in the ISG, and SESM is not installed in a default network on the ISG.
RPC Messaging Principles
There are no changes to the remote procedure call (RPC) messaging principles between the ISG and SESM; that is, service logon, logoff, user logon, user logoff, and account-query all remain RADIUS-based.
Although a new Change of Authorization (CoA) RFC3576-based policy and portal server communication model is introduced in the ISG software, for backward compatibility, the ISG can also operate in traditional SSG-SESM RPC mode. Describing the new CoA model is beyond of the scope of this document. See the "Overview of ISG" chapter in the Cisco IOS Intelligent Service Gateway Configuration Guide for more information.
Single Sign-On in the ISG
Single Sign-On (SSO) functionality also remains the same for the ISG. As with the SSG, the SSO feature in the ISG eliminates the need to authenticate a session more than once, and allows subscribers to close the SESM service selection web page or navigate away from selection web pages and return later without the need to reauthenticate.
The ISG SSO feature can be configured on ATM ports implementing RFC1483 bridging. When ports are configured for RFC1483 bridging, the initial state is set to unauthenticated and no subscriber data except authentication traffic is allowed through the port. The router authenticates the end user using RADIUS by taking the username and password from the Account Logon request. Once the end user is authenticated, the port state transitions into the authenticated state and no further authentication is required for subsequent connections.
One of the key elements of SSO using RFC1483 bridging is the query sent by SESM to obtain the authenticated state of the session from the ISG device. This query is done using a RADIUS request with the appropriate attributes added to the Access-Request. The ISG software contains a limited-feature RADIUS server to answer this query by sending an appropriate Access-Response containing attributes indicating the state of the session. The "Configuring ISG and SESM Interoperability" section shows how to enable a limited-feature RADIUS server to allow the ISG to answer the Account Logon request from SESM.
ISG Session Disconnect
The initial steps in the "Configuring ISG and SESM Interoperability" section describe the configuration that allows the exchange of RADIUS protocol messages between the SESM and the ISG, and restores the RPC channel and SSO functionality between the ISG and SESM.
The exchange of RADIUS protocol messages between SESM and the SSG and ISG remains unchanged. But there are differences in how SESM handles session disconnects: In the SSG environment, when the log out button is pressed on the SESM web page, the SSG host object is terminated but the PPPoE session remains connected. In the ISG-SESM environment, pushing the log out button on the SESM web page disconnects the user's PPPoE session, and the session will need to be brought up again when the user next wants to log in.
Basic ISG-SESM DSL Broadband and SSG-to-ISG Conversion Tasks
This section provides the following configuration tasks that establish basic ISG functionality and, in some cases, restore SSG functionality:
•Configuring a Traffic Drop Policy
•Configuring ISG and SESM Interoperability
•Configuring Pass-Through and Proxy Services in a RADIUS Profile
•Configuring Sequential Service Functionality
•Configuring a Policy Map and Traffic Classifications
•Configuring Advertisement and Initial Redirection
•Configuring L2 Service Selection
•Special Note about Configuring a PTA-MD Exclusion List
Cisco ISG Sample Topology
The conversion tasks in this section were defined for the network depicted in Figure 3. See the "ISG Network Configuration Example" section for the running configuration of this network.
Figure 3 ISG Sample Topology
Configuring a Traffic Drop Policy
For this task, it is assumed that the SSG has an implicit drop policy for all traffic that does not match the IP address configured by either an R attribute statement in a service profile or in the ssg default-network command. Perform the steps in this section to make certain that for all PPPoE sessions the default traffic behavior of the SSG is restored.
Step 1 Use the policy-map type control command to associate the PPPoE session with a policy control map (named example-map1 in the sample running configuration):
Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# policy-map type control example-map1Router(config-control-policymap)# exitRouter(config)# interface Virtual-Template1Router(config-if)# service-policy type control example-map1Step 2 Define specific actions that need to be triggered when the session starts on the policy control map configured in Step 1. One of these actions must be to configure the traffic class that will allow traffic sent from the customer premises equipment (CPE) side of the network to pass when the IP destination of the traffic is targeted for the default network. Start by adding an action on the policy control map, under the session-start event in class control configuration mode. The action for the configuration executes a service named example_network_service.
Router(config)# policy-map type control example-map1Router(config-control-policymap)# class type control always event session-startRouter(config-control-policymap-class-control)# 1 service-policy type service name example_network_serviceStep 3 Configure a service policy map to reconstruct the default network behavior found in the SSG so it will drop all traffic sourced from the CPE side with IP destinations something other than the default network. Use the class-map type traffic command to configure the traffic class map that will be used in the service policy:
Router(config)# class-map type traffic match-any traffic_class_example_network_serviceRouter(config-traffic-classmap)# match access-group in 110Router(config-traffic-classmap)# match access-group out 111Router(config-traffic-classmap)# exitRouter(config)# access-list 110 permit ip any 10.0.0.0 0.0.0.255Router(config)# access-list 111 permit ip 10.0.0.0 0.0.0.255 anyRouter(config)# policy-map type service example_networkRouter(config-service-policymap)# class type traffic traffic_class_example_network_serviceRouter(config-service-policymap-class-traffic)#
Note The traffic class map must exist before being applied in a service policy map; otherwise, you will receive the message: %Warning: class-map "name" does not exist.
At this point, a traffic classification map has been configured on the service. The configuration prompt has changed to indicate that additional actions are possible on the traffic flow matching the traffic class map named traffic_class_example_network. You can use the ? command to see additional actions that are possible.
Router(config-service-policymap-class-traffic)# ?traffic-policy-map-classmap commands:accounting Configure accounting parametersdefault Set a command to its defaultsexit Exit from policymap-classmap service configuration modeno Negate a command or set its defaultspolice Police QoS Inforedirect Redirect rulestimeout Timeout parametersStep 4 Enter the exit command to return to the config-service-policymap mode:
Router(config-service-policymap-class-traffic)# exitStep 5 Define a policy that drops all other traffic not matching the traffic class named traffic_class_example_network. Each service policy map has a predefined default traffic class where the drop action is enabled. Use the class type traffic default in-out command to begin this definition, and set drop as a default action.
Router(config-service-policymap)# class type traffic default in-outRouter(config-service-policymap-class-traffic)# ?traffic-policy-map-classmap default commands:default Set a command to its defaultsdrop action dropexit Exit from policymap-classmap-def service configuration modeno Negate a command or set its defaultsRouter(config-service-policymap-class-traffic)# dropRouter(config-service-policymap-class-traffic)# exitRouter(config-service-policymap)# exitStep 6 The service policy map defined in Step 3 can be configured either locally or on a RADIUS server. This step defines a new AAA method list on the ISG to indicate whether the service policy map resides locally or remotely. Use the aaa new-model and aaa authorization global configuration commands to make the definition. For this configuration, the AAA method list is found locally.
Router(config)# aaa new-modelRouter(config)# aaa authorization subscriber-service default local
Verifying the Traffic Drop Policy
Perform the steps in this section to verify the traffic drop policy.
Step 1 With a PPPoE session up and running, use the show subscriber session command to verify the actions and events that were defined under the policy control map, as follows:
Router# show subscriber session username user-group3
Subscriber session handle: 9F00007C, state: connected, service: Local TermUnique Session ID: 238Identifier: user-group3SIP subscriber access type(s): PPPoE/PPPRoot SIP Handle: FA00007B, PID: 187Child SIP Handle: 6E000012, PID: 189Current SIP options: Req Fwding/Req FwdedSession Up-time: 00:24:00, Last Changed: 00:24:00AAA unique ID: 226Switch handle: CA0EDInterface: Virtual-Access4
Policy information:Authentication status: authenUser profile, excluding services:service-type 2 [Framed]Active services associated with session:name "example_network_service"Prepaid context: not present
Rules, actions and conditions executed:subscriber rule-map example-map1condition always event session-startaction 1 apply service example_network_service...For every action that was triggered in the service policy map, there will be a similar report that describes the subscriber session output.
Tip Before this information can be displayed, the default recording function must be enabled. The recording function has a history limit of 64 rules, and can be disabled with the no subscriber policy recording rule global configuration command.
Step 2 To determine which policy control map is associated with a session when recording is disabled, enter the show caller command to determine the line number, and the show interfaces virtual-access command to display the configuration, as follows:
Router# show caller
Active IdleLine User Service Time Timecon 0 - TTY 00:00:10 00:00:00Vi2.1 user-group3 PPPoE 06:47:58 02:22:33Router# show interfaces virtual-access 2.1 configuration
Virtual-Access2.1 is a PPP over Ethernet link (sub)interfaceDerived configuration : 318 bytes!interface Virtual-Access2.1ip unnumbered Loopback0ip mtu 1492service-policy type control example-map1ppp authentication chapend
Testing the Traffic Drop Policy
The steps in this section describe how you can test the traffic drop policy.
Step 1 If the policy control map was applied successfully, test it by repeating a ping test from the CPE client to the web server. Also use the ping command to test a connection to an IP address in the default network, either the SESM service selection web page or the RADIUS server.
Step 2 The show subscriber session command provides several options for displaying specific session details. Use of a traffic class on the ISG initiates the creation of a unique identifier (uid) that can be displayed by entering the show subscriber session command. Enter the show subscriber session command again with the uid to see session details.
To verify that the drop policy has been configured correctly and to see if packets have been dropped, enter the show subscriber session command with the username. The following examples show the type of information displayed by these commands:
Router# show subscriber sessionCurrent Subscriber Information: Total sessions 1Uniq ID Interface State Service Identifier Up-time42 Vi2.1 authen Local Term user-group3 00:00:1043 Traffic-Cl connected Ltm Internal 00:00:10Router# show subscriber session uid 43Subscriber session handle: 6B0000A0, state: connected, service: Ltm InternalUnique Session ID: 43Identifier:SIP subscriber access type(s): Traffic-ClassRoot SIP Handle: CF00001E, PID: 98Current SIP options: Req Fwding/Req FwdedSession Up-time: 00:00:17, Last Changed: 00:00:17AAA unique ID: 0Switch handle: 402AConfiguration sources associated with this session:Service: example_network_service, Active Time = 00:00:17Because traffic class flows are no longer modeled as separate sessions, they do not show up that way in the output of this command. The traffic class flow features appear in the output of the parent session, rather than under a separate traffic class session. In the following example, key packet and drop policy information is indicated in bold text for purpose of example:
Router# show subscriber session username user-group3
Unique Session ID: 220Identifier: user-group3SIP subscriber access type(s): PPPoA/PPPCurrent SIP options: Req Fwding/Req FwdedSession Up-time: 00:59:59, Last Changed: 00:17:45AAA unique ID: 211Interface: Virtual-Access4
Policy information:Context 2078F3B0: Handle 6C000041Authentication status: authenActive services associated with session:name "DEFAULT"name "PBHK"Rules, actions and conditions executed:subscriber rule-map DEFAULT_RULE_MAPcondition always event session-start1 authenticate aaa list CAR2 service-policy type service name PBHK3 service-policy type service name DEFAULTSession inbound features:Traffic classes:Traffic class session ID: 221ACL Name: DEFAULT_IACL, Packets = 126, Bytes = 12392Default traffic is dropped
Unmatched Packets (dropped) = 0, Re-classified packets (redirected) = 0
Feature: Portbundle HostkeyPortbundle IP = 10.10.100.7 Bundle Number = 70Session outbound features:Traffic classes:Traffic class session ID: 221ACL Name: DEFAULT_OACL, Packets = 206, Bytes = 184863Default traffic is dropped
Unmatched Packets (dropped) = 0, Re-classified packets (redirected) = 0
Configuration sources associated with this session:Service: DEFAULT, Active Time = 01:00:22Service: PBHK, Active Time = 01:00:22Interface: Virtual-Template1, Active Time = 01:00:22
Note Portbundle Hostkey and Traffic class cannot be configured under the same policy group.
Step 3 Enter the show subscriber service command to find specific information about services on the ISG:
Router# show subscriber service example_network_serviceService "example_network_service":Version 1:SVM ID : F1000057Child ID : 54000058Locked by : SVM-Printer [1]Locked by : PM-Service [1]Locked by : PM-Info [1]Locked by : FM-Bind [1]Locked by : TC-Child [1]Profile : 65A79818Profile name: example_network_service, 3 referencesusername "example_network_service"password apasswdtraffic-class "input default drop"traffic-class "output default drop"traffic-class "output access-group 111 priority 10"traffic-class "input access-group 110 priority 10"Feature : TCFeature IDB type : Sub-if or not requiredFeature Data : 32 bytes:: 000000 00 00 54 00 00 58 00 00 ..t..x..: 000008 00 00 00 00 00 0A 01 00 ........: 000010 00 00 63 B7 6F 08 00 00 ..c.o...: 000018 00 0A 01 00 00 00 63 B7 ......c.Version 1:SVM ID : 54000058Parent ID : F1000057Locked by : SVM-Printer [1]Locked by : FM-Bind [1]Locked by : TC-Parent [1]
Configuring ISG and SESM Interoperability
The SESM in SSG topologies is configured to use SSO to verify that a subscriber has already been authenticated, and to use PBHK as a session identifier between the SESM and the SSG. Therefore, connecting to the SESM service selection web page from the CPE side will no longer be possible because the ISG has not yet been configured with PBHK. Additionally, the SESM parameters (shared key, ports, IP address of the SESM service selection web page, and so on) need to be added to the ISG. The following steps will restore SESM interoperability with the ISG.
Step 1 Use the aaa server radius sesm command to enable a limited-feature RADIUS server and begin adding the SESM parameters to the ISG configuration. This command starts config-locsvr-sesm-radius mode, which accepts parameter settings for the SESM. The following configuration allows the exchange of RADIUS protocol messages between the SESM and the ISG, and restores the RPC channel between the ISG and SESM, together with the SSO functionality.
Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# aaa server radius sesmRouter(config-locsvr-sesm-radius)# client 10.0.0.1 /* can also use client nameRouter(config-locsvr-sesm-radius)# key ciscoRouter(config-locsvr-sesm-radius)# port 1812 /* default is port 1645Router(config-locsvr-sesm-radius)# message-authenticator ignoreStep 2 Configure the PBHK in a new service policy map. The following configuration shows the commands to do this.
Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# policy-map type service ip_portbundle_serviceRouter(config-service-policymap)# ip portbundleRouter(config-service-policymap)# exit
Tip Although it is possible to do so, do not configure the PBHK feature within a previously configured service policy map. Use a separate service, for these reasons: Placing a feature under an existing service policy map will trigger that feature only on the flow defined in that traffic class, and not on all traffic of the session. Also, if a feature may need to be disconnected, grouping features makes it necessary to disconnect all the features configured in the service policy map. It is not possible to disconnect just one service.
Step 3 The new service policy map gets inserted into the policy control map you associated with the PPPoE session. Enter the following commands to trigger the PBHK feature service directly when the session is started.
Tip Do not overwrite any previous action set in the policy control map. Be sure to increment the action number by 1.
Router(config)# policy-map type control example-map2Router(config-control-policymap)# class type control always event session-start
Router(config-control-policymap-class-control)# 2 service-policy type service name ip_portbundle_serviceRouter(config-control-policymap-class-control)# exitRouter(config-control-policymap)# exitStep 4 Configure the PBHK feature to match the settings applied on the SESM by entering the match command in config-portbundle mode. In the following configuration commands, the ISG uses its loopback IP address for the PBHK feature (so that whenever a web browser is opened on the client side, the ISG will translate this TCP stream using its loopback IP address as the source IP address rather than the source IP address of the client CPE), and the PBHK feature is used only when the destination of the packet is destined for the default network.
Router(config)# ip portbundleRouter(config-portbundle)# source loopback 0Router(config-portbundle)# ?IP Portbundle configuration commands:default Set a command to its defaultsexit Exit from portbundle configuration modelength Portbundle length configurationmatch Portbundle match configurationno Negate a command or set its defaultssource Portbundle source configurationRouter(config-portbundle)# match access-list 110Router(config-portbundle)# exitStep 5 Configure the egress (or outside, toward SESM) interface to install the PBHK feature using the following configuration commands. Once this has been done, the interface will do the translation of the source IP address from its origin to the interface configured in config-portbundle configuration mode.
Router(config)# interface fa 0/0Router(config-if)# ip portbundle outsideRouter(config-if)# exit
Tip Use the show ip route command with the IP address of the SESM service selection web page if you need to verify this interface.
See the "CSCuk56681—ISG Sending Locally Defined Service to Portal Breaks Status Page" section for additional information about restoring ISG and SESM interoperability.
Verifying ISG and SESM Interaction
Verify that SESM can interact correctly with the ISG after the configuration changes by performing the steps in this section.
Step 1 Bring up a web browser on a PC, then bring up the PPPoE session after reconnecting to the PPPoE session again to register the changes.
Step 2 Direct the web browser to the IP address of the SESM service selection web page and verify that the page displays.
Step 3 Enable the debug radius command on the ISG to verify that SSO works correctly. Use reports in the debug output to verify the RADIUS packets exchanged between the SESM and the ISG, as follows:
•The SESM sends access request messages, which contain subattribute 252 ssg-command-info.
•The ISG sends access accept messages with answers to the command request embedded in the ssg-command-info value.
The packet exchange-call flow for communication between ISG and SESM is the same as the communication path between the SSG and the SESM.
Step 4 Enter the show ip portbundle command to verify that the PBHK was successfully installed on the session by determining that a bundle was assigned for the session, as follows:
Router# show ip portbundle status inuseBundle-group 10.10.10.3 has the following in-use port-bundles:-Port-bundle VRF Name64 Default TableRouter# show ip portbundle ip 10.10.10.3 bundle 64Portbundle IP address: 10.10.10.3 Bundlenumber: 64Subscriber Portmappings:Subscriber IP: 10.10.3.1 Subscriber Port: 33487 Mapped Port: 1216Subscriber IP: 10.10.3.1 Subscriber Port: 33488 Mapped Port: 1217
Tip If the show command output is empty initially, reload or open the web browser to the SESM service selection web page again.
Configuring Layer 4 Redirect
The SSG is configured to redirect all TCP traffic on port 8090 in SESM, because traffic was classified as having access to an unauthorized service. By completing the steps in this section, the L4 redirection functionality seen on the SSG will be restored on the ISG.
Additional information about redirection can be found in the "Configuring Advertisement and Initial Redirection" section.
Step 1 Define a new service for the redirection feature and establish when you want to redirect traffic in the policy manager using the following commands. As with the SSG, you want to start redirecting traffic as soon as the PPPoE session is started. This action is defined under the policy control map, as shown in the following commands.
Tip Do not overwrite any previous action set in the policy control map. Be sure to increment the action number by 1.
Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# policy-map type control example-map2Router(config-control-policymap)# class type control always event session-startRouter(config-control-policymap-class-control)# 3 service-policy type service name l4_redirect_serviceRouter(config-control-policymap-class-control)# exitRouter(config-control-policymap)# exitStep 2 Once you have configured the policy control map, you must implement the service policy map using the following commands. It is here that you will identify which traffic belonging to the session must be redirected using the traffic classification feature.
Router(config)# class-map type traffic match-any l4-redirect-tc-mapRouter(config-traffic-classmap)# match access-group in name redirect-aclRouter(config-traffic-classmap)# match access-group out name redirect-aclRouter(config-traffic-classmap)# exitRouter(config)# ip access-list extended redirect-aclRouter(config-ext-nacl)# permit tcp any any eq wwwRouter(config-ext-nacl)# exitRouter(config)# access-list 199 deny tcp any host 10.0.0.1 eq wwwRouter(config)# access-list 199 deny tcp any host 10.0.0.1 eq 8080Router(config)# access-list 199 deny tcp host 10.0.0.1 anyRouter(config)# access-list 199 permit tcp any any eq wwwRouter(config)# policy-map type service l4_redirect_serviceRouter(config-service-policymap)# 10 class type traffic l4-redirect-tc-mapRouter(config-service-policymap-class-traffic)# redirect list 199 to group redirect-group-defaultRouter(config-service-policymap-class-traffic)# exitRouter(config-service-policymap)# exitThe number 10 in the class type traffic command sets a priority on the traffic classification feature.
Step 3 To complete the configuration, configure the redirection group by entering the following commands:
Router(config)# redirect server-group redirect-group-defaultRouter(config-sg-l4redirect-group)# server ip 10.0.0.1 port 8090Router(config-sg-l4redirect-group)# exitVerifying L4 Redirect
Verify that the ISG is correctly configured to redirect all TCP traffic again using L4 Redirect by performing the steps in this section.
Step 1 Bring up a web browser on a PC, then bring up the PPPoE session after reconnecting to the PPPoE session again to register the changes.
Step 2 Direct the web browser to the IP address for the web service. The TCP stream should be redirected to the SESM service selection web page, and the redirection URL should resemble the following pattern:
http://10.0.0.1:8080/home?CPURL=http%3A%2F%2F10.0.0.11%2F&t=e42tvk85Step 3 On the ISG router, verify the TCP streams that have been redirected by using the show redirect translations command, as follows:
Router# show redirect translationsDestination IP/port Server IP/port Prot In Flags Out Flags Timestamp10.0.0.11 80 10.0.0.1 8090 TCP FIN FIN Jan 18 2005 10:33:2410.0.0.11 80 10.0.0.1 8090 TCP FIN FIN Jan 18 2005 10:33:28The translation data is available only for a short time. You will need to collect this information immediately after entering the IP address in the web browser. Following is an example of the message you receive if you wait too long:
Router# show redirect translationsNo translations currently existStep 4 Verify the server group by using the show redirect group command, as follows:
Router# show redirect group redirect-group-defaultShowing all servers of the group redirect-group-defaultServer created : using cliServer Port10.30.81.22 8090Step 5 Use the show subscriber session all command to check the profile configuration:
Router# show subscriber session allCurrent Subscriber Information: Total sessions 1--------------------------------------------------Unique Session ID: 171Identifier:SIP subscriber access type(s): Traffic-ClassCurrent SIP options: NoneSession Up-time: 00:01:21, Last Changed: 00:01:21AAA unique ID: 0Session inbound features:Feature: Layer 4 RedirectRule Cfg Definition#1 ....Configuration sources associated with this session:Service: l4redirect, Active Time = 00:01:21...Policy information:Context 6551F5A4: Handle 3E00022DAuthentication status: authenUser profile, excluding services:ssg-account-info "NSR0600"ssg-account-info "NSR0601"service-name "SR0600"service-name "SR0601"Active services associated with session:name "service_default_network"name "l4redirect"name "ip_portbundle"Prepaid context: not present...
Configuring Pass-Through and Proxy Services in a RADIUS Profile
The procedures in this section show you how to configure pass-through and proxy services. For the ISG, a service is defined as a feature, and features can be stored in a RADIUS profile using Cisco AV pairs. However, there is a format change for service profile definitions for the ISG: It no longer interprets the cryptic style used in Cisco's VSA value 251 (Service-Info) profile definitions. Therefore, part of the migration effort for service profiles is to construct similar functionality for a particular SSG service using new Cisco AV pairs defined for the ISG.
The new attributes will be inserted into the existing SSG service profile on the RADIUS server, and the resulting profile will have a mix of old SSG and new ISG attributes. The presence of an attribute that neither the SSG nor the ISG can interpret will not impair functionality, however, because they both routers ignore attributes they do not use and just interpret those they do understand.
Note An exception to this is the R attribute: In an SSG service profile, the R attribute defines the service network destination and is essential for the SSG to populate its own routing tables. If there is no match for the destination IP address, the service is dropped. Additionally, absence of the R attribute in a service profile is interpreted by SESM as meaning that the service is not applicable to the gateway (shows up as highlighted or blue on the SESM service selection web page). Therefore, you need to keep the R attribute statements in the service profiles and add statements that provide functionality required by ISG features.
Configuring Pass-Through Service
The SSG functionality of the R string in the Service-Info attribute is closely related to the traffic classification feature with the drop command for default traffic. The procedure in the "Configuring a Traffic Drop Policy" section inserted a traffic drop in the service named example_network_service. The procedure in this section shows you how to configure a traffic class on the pass-through service and define a traffic class ACL to match whatever IP destination was present in the original R string in the RADIUS profile.
Step 1 The following SSG profile attributes configure the pass-through service named groupA-service1 and specify the service address using the R attribute. (The syntax for these commands depends upon the RADIUS server used.)
...service outboundauthentication groupA-service1 password apasswdvsa cisco generic 251 string "MC"vsa cisco generic 251 string "TP"vsa cisco generic 251 string "IgroupA-service1"vsa cisco generic 251 string "R10.0.0.11;255.255.255.255"Configure the equivalent functionality in the ISG by adding traffic classes to the profile, as follows:
vsa cisco generic 1 string "ip:traffic-class=in access-group 155 priority 1"vsa cisco generic 1 string "ip:traffic-class=out access-group 156 priority 1"Step 2 On the ISG, you must manually insert the ACL that is referenced in both traffic class statements (the ACL cannot be downloaded dynamically). The ACL must have equivalent functionality to the RADIUS R string attribute. In the input direction, the destination in the R attribute can be re-created using an ACL where the destination IP route is equivalent to the destination IP route in the R attribute. In the output direction, the R attribute is simulated by using an ACL and configuring the source IP address and network mask to be similar to the destination IP route in the R attribute. The following commands accomplish this equivalency:
Router(config)# access-list 155 permit any host 10.0.0.11Router(config)# access-list 156 permit ip host 10.0.0.11 anyThis completes the required steps for configuring pass-through service.
Configuring Proxy Service
The following SSG profile attributes configure the proxy service named groupA-service2 and specify the service address using the R attribute:
...description proxy serviceservice outboundauthentication groupA-service2 password apasswdvsa cisco generic 251 string "TX"vsa cisco generic 251 string "IgroupA-service2"vsa cisco generic 251 string "S10.0.0.10;1812;1813;ww"vsa cisco generic 251 string "R10.0.0.12;255.255.255.255"vsa cisco generic 251 string "MC"
Note To preserve proxy service functionality in SESM, the service profile must contain the TX attribute.
The proxy service requires not only a traffic class to construct equivalent functionality to the RADIUS R string attribute, but also requires a policy-directive-authenticate statement be inserted to make certain the username and password on the login page of the SESM service selection web page are authenticated using the method list referenced in the statement. The following steps accomplish this functionality.
Step 1 Insert the following attributes in the service profile:
vsa cisco generic 1 string "ip:traffic-class=in access-group 156 priority 11"vsa cisco generic 1 string "ip:traffic-class=out access-group 56 priority 11"vsa cisco generic 1 string "subscriber:policy-directive=authenticate aaa list proxy-list"Step 2 Because the name proxy-list refers to a method list name, the ISG configuration needs a new authentication method list for login using this name and pointing to a RADIUS server group. The configuration of the RADIUS server group and the RADIUS server must match the SSG settings within the S string present in the ssg-service-info attribute. For the ISG, the commands to do this are as follows:
Router(config)# aaa group server radius proxy-listRouter(config-sg-radius)# server 10.0.0.10 auth-port 1812 acct-port 1813Router(config-sg-radius)# exitRouter(config)# radius-server host 10.0.0.10 auth-port 1812 acct-port 1813 key wwRouter(config)# aaa authentication login proxy-list group proxy-listStep 3 Configure the ACL referenced in the traffic class string. The ACL should include the destination IP address list found in the ssg-service-info R string subattribute.
Router(config)# access-list 56 permit host 10.0.0.12Router(config)# access-list 156 permit ip any host 10.0.0.12This completes the required steps for configuring proxy service.
Adjusting the Policy Control Map
Once you have adjusted the service profiles on the ISG to contain feature functionality that mimics attributes in the SSG RADIUS service profiles, you may want to adjust the policy control map on the ISG so that it can direct the actions the ISG takes when an event for a service start or stop is triggered.
When a service subscriber clicks a service in the SESM service selection web page, that action sends a RADIUS service logon request to the ISG, which is the same way it works on the SSG. But on the ISG, this action is a service-start event in the policy manager. You must, therefore, implement a service-start event in the service policy map associated with the subscriber. Although not required, to demonstrate advantages made possible by the granularity of the policy manager, you could define a class map control policy for every service.
Step 1 The following commands show how to configure a granular control class map:
Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# class-map type control match-any service1-checkRouter(config-control-classmap)# match service-name groupA-service1Router(config-control-classmap)# exitRouter(config)# class-map type control match-all service2-checkRouter(config-control-classmap)# match service-name groupA-service2Router(config-control-classmap)# exitStep 2 Once you have defined the control class map for service1-check and service2-check, insert the condition trigger in the control policy map for the service logon requests on the ISG by using the following commands:
Router(config)# policy-map type control example-map2Router(config-control-policymap)# class type control service1-check event service-startRouter(config-control-policymap-class-control)# 1 service-policy type service identifier service-nameRouter(config-control-policymap-class-control)# exitRouter(config-control-policymap)# class type control service2-check event service-startRouter(config-control-policymap-class-control)# 1 service-policy type service identifier service-nameRouter(config-control-policymap-class-control)# exitThis configuration implies that a control class map is required for each service that you define, but by default, the ISG uses the defined service name to identify a service. If you need to overwrite the default behavior, the ISG offers a list of commands to do so. Consider the following:
Router(config)# policy-map type control example-map2
Router(config-control-policymap)# class type control always event service-start
Router(config-control-policymap-class-control)# class type always event service-start service identifier ?
authenticated-domain Authenticated domain nameauthenticated-username Authenticated usernamednis Dial Number Information Service (called partynumber)nas-port NAS Port Identifiertunnel-name VPDN Tunnel-Nameunauthenticated-domain Unauthenticated domain nameunauthenticated-username Unauthenticated usernameStep 3 Also as an optional step, you can update the policy manager to perform specific actions when a service is being stopped. Consider the following configuration:
Router(config)# policy-map type control example-map2Router(config-control-policymap)# class type control always event service-stopRouter(config-control-policymap-class-control)#1 service-policy type service unapply identifier service-nameRouter(config-control-policymap-class-control)# exit
Tip A sequence order must be followed when actions are applied under a service-start policy: Whenever there is a combination of applying and unapplying services, you must enter all unapply commands first, then enter the apply commands. To do otherwise results in the following message: "action unapply cannot be followed by apply in service-start event."
Action 1 for a service-stop must be an unapply; otherwise, you will receive the following message: "action 1 supports only unapply identifier service-name in service-stop event."
Verifying Services
Verify that the ISG services are correctly configured by performing the steps in this section.
Step 1 Bring up a web browser on a PC, then bring up the PPPoE session after reconnecting to the PPPoE session again to register the changes.
Step 2 Direct the web browser to the SESM service selection web page.
Step 3 Click the first service (groupA-service1). This should once again allow you access to the web service page. Refresh the web page to see that content is changed.
Tip You can also test services by sending ping commands from the MS-DOS prompt to the web server IP address.
Step 4 Stop the service again using the SESM service selection web page.
Step 5 Click the second service (groupA-service2). After submitting login information, you should once again see the web service page. However, if you enter IP address 10.0.0.12 in the URL field of the web browser, the traffic will be redirected to the SESM service selection web page.
You can also verify connectivity by sending ping commands from the MS-DOS prompt to the web server IP address.
Configuring Sequential Service Functionality
In an SSG, it is possible to configure services as either concurrent or sequential. In an ISG, you configure similar functionality. You configure the ISG's policy manager so that when one service starts, all other services are disconnected. These actions use a concept of unapply.
Configure the policy manager to perform the correct unapply actions, as follows:
Router(config)# policy-map type control SEQUENTIAL_RULE_MAP
Router(config-control-policymap)# class type control CONTROL_CLASS_01 event service-start
Router(config-control-policymap-class-control)# 1 service-policy type service unapply name 02
Router(config-control-policymap-class-control)# 2 service-policy type service identifier service-name
...Router(config-control-policymap)# class type control CONTROL_CLASS_02 event service-start
Router(config-control-policymap-class-control)# 1 service-policy type service unapply name 01
Router(config-control-policymap-class-control)# 2 service-policy type service identifier service-name
...Router(config-control-policymap)# class type control always event session-start
Router(config-control-policymap-class-control)# 1 authenticate aaa list CAR
Router(config-control-policymap-class-control)# 2 service-policy type service name PBHK
Router(config-control-policymap-class-control)# 3 service-policy type service name DEFAULT
...When you activate service 02 with this configuration, the ISG deactivates service 01, and the other way around.
Configuring Prepaid Service
The following SSG attributes configure the prepaid service named groupA-service3 and specify the service address using the R attribute:
...description SSG to ISG migration exampleservice outboundauthentication groupA-service3 password apasswdvsa cisco generic 251 string "MC"vsa cisco generic 251 string "TP"vsa cisco generic 251 string "Z"vsa cisco generic 251 string "IgroupA-service3"vsa cisco generic 251 string "R10.0.0.13;255.255.255.255"Perform the following steps to configure prepaid service on the ISG:
Step 1 In the ISG, configure functionality equivalence to the RADIUS R string attribute provided in the SSG profile by using traffic classes. See the following example:
vsa cisco generic 1 string "ip:traffic-class=in access-group 157 priority 1"vsa cisco generic 1 string "ip:traffic-class=out access-group 57 priority 1"Step 2 The ACL numbers in the Cisco AV pair must be redefined on the ISG and must match the values configured in the SSG R attribute. Use the access-list command, as follows::
Router(config)# access-list 57 permit host 10.0.0.13Router(config)# access-list 157 permit ip any host 10.10.0.13Step 3 The following command shows how to configure the prepaid feature in the RADIUS profile. You must insert a new attribute in the service profile, because the prepaid Z attribute in the SSG is not being interpreted by the ISG anymore.
vsa cisco generic 1 string "prepaid-config=default"The name "default" refers to a prepaid server configuration present on the ISG itself, but you will need to insert additional configurations on the ISG to complete the prepaid functionality. These settings are needed to reauthorize packets exchanged between the billing server and the ISG. Compared to the SSG, the ISG offers more specific configurations for prepaid service such as different thresholds, a different billing server group for reauthorization, and so on.
Step 4 Use the ? command to display the prepaid subcommands:
Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# subscriber feature prepaid defaultRouter(config-prepaid)# ?Prepaid subcommandsdefault Set a command to its defaultsexit Exit from subcommandinterim-interval Interim interval configmethod-list Method list configno Negate a command or set its defaultspassword Password configthreshold Threshold configStep 5 In your configuration, you could implement an authorization and accounting method list and password to use for RADIUS reauthorization access requests that are sent to the billing server using the following commands:
Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# subscriber feature prepaid defaultRouter(config-prepaid)# method-list authorization defaultRouter(config-prepaid)# method-list accounting defaultRouter(config-prepaid)# password apasswd
Note Remember that default settings are not listed in the configuration. When you look at the configuration of the ISG after implementing the previous commands, you will not see any of them in the configuration if they are default settings.
Step 6 The following commands are always mandatory in the configuration of both the ISG or SSG, whenever the prepaid feature is deployed. Attribute 55 is a UNIX time stamp and attribute 44 is acct-session-id.
Router(config)# radius-server attribute 55 include-in-acct-reqRouter(config)# radius-server attribute 44 include-in-access-reqStep 7 To complete the configuration, match a specific class control condition when the prepaid service is started or stopped. The following commands extend the control class map created previously with the current service name:
Router# configure terminalEnter configuration commands, one per line. End with CNTL/Z.Router(config)# class-map type control match-any service1-checkRouter(config-control-classmap)# match service-name groupA-service3Router(config-control-classmap)# exit
Verifying Prepaid Service
Verify that the ISG prepaid feature functions correctly by performing the steps in this section.
Step 1 Bring up a web browser on a PC, then bring up the PPPoE session after reconnecting to the PPPoE session again to register the changes.
Step 2 Direct your browser to the SESM service selection web page.
Step 3 Click the first service (groupA-service3). The prepaid service should be triggered again.
Step 4 To verify that the service was activated, open a web browser and direct it to the IP address defined in Step 2 of the "Configuring Prepaid Service" procedure:
http://10.0.0.13
Tip Alternatively, you can source pings from an MS-DOS prompt on the PC to IP address 10.0.0.13.
Step 5 The service can be verified by obtaining the identifier created for the traffic class, and by verifying the service itself by using the show subscriber service and show subscriber session commands, as follows:
Router# show subscriber service groupA-service3Service "groupA-service3":Version 1:SVM ID : A4000068Child ID : 32000069Locked by : SVM-SIP-Info [1]Locked by : SVM-Printer [1]Locked by : PM-Service [1]Locked by : PM-Info [1]Locked by : FM-Bind [1]Locked by : TC-Child [1]Profile : 65AC5FE8Profile name: group3-service3, 4 referencesservice-type 5 [Outbound]ssg-service-info "MC"ssg-service-info "TP"ssg-service-info "Z"ssg-service-info "IgroupA-service3"ssg-service-info "R10.0.0.13;255.255.255.255"traffic-class "in access-group 157 priority 1"traffic-class "out access-group 57 priority 1"policy-handle 1795162340 (0x6B0000E4)Feature : TCFeature IDB type : Sub-if or not requiredFeature Data : 32 bytes:: 000000 00 00 32 00 00 69 6B 00 ..2..ik.: 000008 00 E4 00 00 00 01 00 00 ........: 000010 00 00 63 BC 46 EC 00 00 ..c.f...: 000018 00 01 00 00 00 00 63 BC ......c.SIP : Info 6475A690 access: PPP info: PPPVersion 1:SVM ID : 32000069Parent ID : A4000068Locked by : SVM-Printer [1]Locked by : FM-Bind [1]Locked by : TC-Parent [1]Router# show subscriber sessionCurrent Subscriber Information: Total sessions 1Uniq ID Interface State Service Identifier Up-time56 Traffic-Cl unauthen Ltm Internal user-group3 00:00:3454 Traffic-Cl connected Ltm Internal 00:00:5655 Traffic-Cl connected Ltm Internal 00:00:5653 Vi2.1 authen Local Term user-group3 00:00:56Router# show subscriber session uid 56Subscriber session handle: 6E0000E6, state: connected, service: LtmInternalUnique Session ID: 56Identifier: user-group3SIP subscriber access type(s): Traffic-ClassRoot SIP Handle: 23000026, PID: 98Current SIP options: Req Fwding/Req FwdedSession Up-time: 00:01:04, Last Changed: 00:01:04AAA unique ID: 0Switch handle: 1037Policy information:Context 65A89EE8: Handle 6B0000E4Authentication status: unauthenPrepaid context: defaultthreshold time 0 secondsthreshold volume 0 bytesmethod-list author defaultmethod-list accounting defaultpassword apasswdInterim accounting disabledState PREPAID_FEATURE_RUNNINGFlow idle ? NOAcct start sent ? YESSession inbound features:Feature: Prepaid Volume MonitorThreshold:4294967295 - Quota:4294967295Usage(since last update):0 - Total:0Current states: StartSession outbound features:Feature: Prepaid Volume MonitorThreshold:4294967295 - Quota:4294967295Usage(since last update):0 - Total:0Current states: StartNon-datapath features:Feature: Time MonitorThreshold: 100 (seconds) - Quota: 100 (seconds)Session time: 66 (seconds)Configuration sources associated with this session:Service: groupA-service3, Active Time = 00:01:06
Configuring a Policy Map and Traffic Classifications
The task in this section shows how to configure prioritization based on an ACL, use of the traffic classification feature, L4 redirection, and a prepaid-based service. This section describes:
•How the policy manager works.
•Differences between a policy control map and a service policy.
•Why a feature like Prepaid needs to be configured in a remote service profile.
•How prioritization works in the traffic classification feature.
Policy control is that part in the policy manager that makes certain that specific actions are triggered for specific events. The action itself is most often linked to a policy service. The policy service is responsible for inserting into the subscriber flow features such as PBHK, L4 redirection, prepaid functionality, drop packets, or traffic classification. Therefore, a policy service provides the ISG with the ability to insert policies on the traffic flow.
For the task described in this section, a policy map is implemented on the ISG that:
•Redirects all TCP traffic to IP addresses 10.40.96.4 and 10.40.96.5, as long as the prepaid service has not been activated by an event session-start command in a control policy map.
•Allows all IP traffic to address 10.40.96.4 to pass through as soon as the prepaid service named pp-quota-refill-time has been activated by an event service-start command in a control policy map.
Step 1 Use the following commands to configure the control policy map such that any subscriber session that is associated with this policy map will have two actions to perform at the time that the session is started on the ISG: Action 1 is to authenticate the session using the AAA method list named ML-1. Action 2 defines a policy service that must be inserted.
Router(config)# policy-map type control prepaid-user
Router(config-control-policymap)# class type control always event session-start
Router(config-control-policymap-class-control)# 1 authenticate aaa list ML-1
Router(config-control-policymap-class-control)# 2 service-policy type service name prepaid-redirect
Router(config-control-policymap-class-control)# exit
Router(config-control-policymap)# class type control always event service-start
Router(config-control-policymap-class-control)# 1 service-policy type service aaa list ML-1 identifier service-name
Router(config-control-policymap-class-control)# exit
Router(config-control-policymap)# class type control always event quota-depleted
Router(config-control-policymap-class-control)# exit
Router(config-control-policymap)# class type control always event credit-exhausted
Router(config-control-policymap-class-control)# exit
Step 2 Once you have configured the policy control map, you must implement the service policy map. The following service policy map combines two features, traffic classification and redirection. Traffic classification ensures that only a specific part of the traffic is redirected, and that the remaining flow is left unchanged. The remaining traffic is filtered out when you define a traffic class map that links the traffic class feature with an extended ACL named prepaid-redirect-acl. The policy service will redirect all TCP traffic at IP addresses 10.40.96.4 and 10.40.96.5 to the SESM service selection web page.
The policy that will be inserted on the traffic flow is the service policy map named prepaid-redirect-tc as defined in the action rule, and is configured as follows:
Router(config)# policy-map type service prepaid-redirectRouter(config-service-policymap)# 10 class type traffic prepaid-redirect-tcRouter(config-service-policymap-class-traffic)# redirect to ip 10.30.81.22 port 8090
...Router(config)# class-map type traffic match-any prepaid-redirect-tc
Router(config-traffic-classmap)# match access-group output name prepaid-redirect-acl
Router(config-traffic-classmap)# match access-group input name prepaid-redirect-acl
Router(config-traffic-classmap)# exitRouter(config)# ip access-list extended prepaid-redirect-acl
Router(config-ext-nacl)# permit tcp any host 10.40.96.5
Router(config-ext-nacl)# permit tcp any host 10.40.96.4
The ISG is forced to redirect all the TCP traffic destined to IP addresses 10.40.96.4 and 10.40.96.5 as soon as the subscriber session comes up. The control policy map links the action with an event, and the service policy map indicates to the ISG what type of policy to apply to the traffic flow.
Step 3 Let us say that the subscriber can start a prepaid service named pp-quota-refill-time as a subsequent event. This event is linked with a service logon request sent from the SESM to the ISG. Again, the control policy map indicates to the ISG what actions to take when a service logon happens on the SESM service selection web page.
To set up this action, insert the following commands in the policy map:
Router(config-control-policymap)# class type control always event service-start
Router(config-control-policymap-class-control)# 1 service-policy type service aaa list ML-1 identifier service-name
These commands initiate a search via the AAA method list named ML-1 to determine if there is a RADIUS service profile available on a remote RADIUS server with username service-name (taken from the service logon sent by SESM).
Step 4 The following attributes configure the service that the subscriber selects on the RADIUS server. The attributes that are interpreted only by the ISG are shown in bold text for purpose of example.
...service outboundauthentication prepaid-volume password serviceciscovsa cisco generic 251 string "MC"vsa cisco generic 251 string "TP"vsa cisco generic 251 string "Ipp-quota-refill-time"vsa cisco generic 251 string "Z"vsa cisco generic 1 string "prepaid-config=default"vsa cisco generic 251 string "R10.40.96.4;255.255.255.255"vsa cisco generic 1 string "ip:traffic-class=in access-group name pp-quota-refill-time priority 5"vsa cisco generic 1 string "ip:traffic-class=out access-group name pp-quota-refill-time priority 5"Step 5 A prepaid service is always defined in combination with a traffic class. In this configuration, the policy service is not configured locally but remotely on the RADIUS server. The traffic flow on which this policy service will work is based on the extended ACL group named pp-quota-refill-time, which is configured as follows:
Router(config)# ip access-list extended pp-quota-refill-time
Router(config-ext-nacl)# permit ip any host 10.40.96.4
Router(config-ext-nacl)# permit ip host 10.40.96.4 any
Notice that the redirection service that is triggered first at session start was not unapplied, and that there is an ACL that overlaps with the redirection list. When a TCP connection to IP address 10.40.96.4 is opened, the connection will work because of the prioritization possible in the traffic class feature. The presence of the number 10 in the 10 class type traffic prepaid-redirect-tc command on the service policy for redirection, and priority 5 in the vsa cisco generic 1 string "ip:traffic-class=in access-group name pp-quota-refill-time priority 5" command, make certain that the ISG tries first to match any traffic in the flow against the ACL for the service, and then other ACLs with a lower priority. As such, TCP traffic for IP address 10.40.96.5 will match on the ACL defined in the prepaid service and will not be redirected.
This configuration shows that a policy service need not always be configured locally. You can insert a service policy remotely on a RADIUS server. Remember that ACLs must be present on the ISG before you set policy on a RADIUS server, and that a control policy map cannot be configured remotely on a RADIUS server.
The service policy is simply a traffic class on which no special action such as L4 redirection or traffic drop are taken on the traffic. The configuration allows traffic to IP address 10.40.96.4 to pass through without any alteration.
Configuring Advertisement and Initial Redirection
Using advertisement redirection (RA) and initial redirection (RI) features (defined using the SSG RADIUS RI and RA attribute) do not work on the ISG (see CSCsa63459 for more information). The following steps will replace the functionality provided by the SSG RADIUS RI and RA attributes on the ISG. Other services will not be impacted by this configuration.
Step 1 Configure the local service on the ISG. In this example, the service is named l4redirect:
Router(config)# policy-map type service l4redirect
Router(config-service-policymap)# class type traffic CLASS-ALL
Router(config-service-policymap-class-traffic)# redirect list 160 to ip 10.40.100.3 port 80 duration 20
Router(config-service-policymap-class-traffic)# redirect list 163 to ip 10.40.101.3 port 80 duration 10 frequency 60
Router(config-service-policymap-class-traffic)# exit
Router(config)# policy-map type control control_default_network
Router(config-control-policymap)# class type control always event session-start
Router(config-control-policymap-class-control)# 1 authenticate aaa list SESM
Router(config-control-policymap-class-control)# 2 service-policy type service name ip_portbundle
Router(config-control-policymap-class-control)# 3 service-policy type service name service_default_network
Router(config-control-policymap-class-control)# 4 service-policy type service name l4redirect
Router(config-control-policymap-class-control)# exit
Router(config-control-policymap)# class type control always event service-start
Router(config-control-policymap-class-control)# 1 service-policy type service identifier service-name
Router(config-control-policymap-class-control)# exit
Router(config-control-policymap)# class type control always event service-stopRouter(config-control-policymap-class-control)# 1 service-policy type service unapply identifier service-name
Step 2 Configure ACLs that match the service to be redirected. In this example, a service provides access to IP network 10.40.96.0 and another service goes to IP network 10.40.97.0:
Router(config)# access-list 160 permit ip any 10.40.96.0 0.0.0.255
Router(config)# access-list 163 permit ip any 10.40.97.0 0.0.0.255
At session start, the service named l4redirect is started and packets that match the source address for ACL 160 are redirected to IP address 10.40.100.3 (an advertisement server) for 20 seconds; see the first redirect list command in Step 1. This configuration replaces advertisement redirection.
The same configuration is specified for advertisement redirection. The redirect list function polls for packets to redirect every 60 seconds for 10 seconds. Packets that match the source address for ACL 163 are redirected to IP address 10.40.101.3; see the second redirect list command in Step 1. This configuration replaces initial redirection.
Configuring L2 Service Selection
On the SSG, a subscriber using PPP typically initiates a Layer 2 (L2) session using a desktop PPP dialer and specifying either a structured or nonstructured username and password. (On the CPE side of the network, an always-on model is often adopted, and often with a preconfigured username and password.)
A structured username contains a username and the domain or service name. An example is user1@service.net. An unstructured username contains the username without the domain and service name specified— the name user1 by itself is an example of an unstructured username. User1 in this example could access multiple services simultaneously from a single PPP session.
A structured username can serve to authenticate a subscriber and as a service selection method. As a part of the Account Logon feature, the username is used to authenticate subscriber access to the SSG. The service part of the structured username is used by the Service Logon feature to select the specified service. As long as the PPP session is terminated and not forwarded to the home gateway or Layer 2 network server (LNS), subscribers with a structured username can also connect to the SESM service selection web page and use their web browser to select services.
The nonstructured username specifies only the username, and is used by the Account Logon feature on the SSG to authenticate subscriber access. Subscribers with a nonstructured username must use their browser to connect to the SESM Dashboard Server and then log on to different services.
To implement the same structured username functionality on the ISG as on the SSG, you need to add an action in a policy map that downloads the service profile from a AAA server (which is specified by the aaa method-list command) based on the unauthenticated domain name.
To add this action to a policy map, define a policy map and enter the following commands to implement L2 service selection on the ISG:
Router(config)# policy-map type control DEFAULT_RULE_MAP
Router(config-control-policymap)# class type control always event session-start
Router(config-control-policymap-class-control)# 1 authenticate aaa list CAR
Router(config-control-policymap-class-control)# 2 service-policy type service name PBHK
Router(config-control-policymap-class-control)# 3 service-policy type service name DEFAULT
Router(config-control-policymap-class-control)# 4 service-policy type service aaa list CAR identifier unauthenticated-domain
The action must be applied after the action that authenticates the subscriber. In the previous commands, this action would occur after action 1.
Verifying L2 Service Selection
Verify that the ISG is correctly configured to implement L2 service selection by performing the steps in this section.
Step 1 Configure a PPP user with username U0019@SR0013.
Step 2 Use the show subscriber session username command to verify that the service is activated when the user logs in, as follows:
Router# show subscriber session username U0019@SR0013
Unique Session ID: 521Identifier: U0019@SR0013SIP subscriber access type(s): PPPoA/PPPCurrent SIP options: Req Fwding/Req FwdedSession Up-time: 00:00:13, Last Changed: 00:00:13AAA unique ID: 336Interface: Virtual-Access4Policy information:Context 2078F3B0: Handle A50003C7Authentication status: authenActive services associated with session:name "SR0013"name "DEFAULT"name "PBHK"Rules, actions and conditions executed:subscriber rule-map DEFAULT_RULE_MAPcondition always event session-start1 authenticate aaa list CAR2 service-policy type service name PBHK3 service-policy type service name DEFAULT4 service-policy type service aaa list CAR identifier unauthenticated-domainSession inbound features:Traffic classes:Traffic class session ID: 522ACL Name: DEFAULT_IACL, Packets = 0, Bytes = 0Traffic class session ID: 523ACL Name: SR0013_IACL, Packets = 0, Bytes = 0Default traffic is droppedUnmatched Packets (dropped) = 0, Re-classified packets (redirected) = 0Feature: Portbundle HostkeyPortbundle IP = 10.10.100.7 Bundle Number = 162Session outbound features:Traffic classes:Traffic class session ID: 522ACL Name: DEFAULT_OACL, Packets = 0, Bytes = 0Traffic class session ID: 523ACL Name: SR0013_OACL, Packets = 0, Bytes = 0Default traffic is droppedUnmatched Packets (dropped) = 0, Re-classified packets (redirected) = 0Configuration sources associated with this session:Service: SR0013, Active Time = 00:00:14Service: DEFAULT, Active Time = 00:00:14Service: PBHK, Active Time = 00:00:14Interface: Virtual-Template1, Active Time = 00:00:14Step 3 Use the show subscriber service command to display specific information about services on the ISG, as follows:
Router# show subscriber service SR0013
Service "SR0013":Version 1:SVM ID : 54000151Child ID : D8000152Locked by : SVM-Printer [1]Locked by : PM-Service [1]Locked by : PM-Info [1]Locked by : FM-Bind [1]Locked by : TC-Child [1]Profile : 64B2F0B0Profile name: SR0013, 3 referencestraffic-class "in access-group name SR0013_IACL priority 1"traffic-class "out access-group name SR0013_OACL priority 1"ssg-service-info "ISR0013 (L2 service selection)"ssg-service-info "R10.40.96.32;255.255.255.255"ssg-service-info "TP"ssg-service-info "MC"Feature : TCFeature IDB type : Sub-if or not requiredFeature Data : 28 bytes:: 000000 00 00 D8 00 01 52 00 00 .....r..: 000008 00 01 00 00 00 00 64 B8 ......d.: 000010 B0 E8 00 00 00 01 00 00 ........: 000018 00 00 20 AE .. .Version 1:SVM ID : D8000152Parent ID : 54000151Locked by : SVM-Printer [1]Locked by : FM-Bind [1]Locked by : TC-Parent [1]
Special Note about Configuring a PTA-MD Exclusion List
On the SSG, L2 service selection is the default behavior. If you want to override this behavior, you use the PPP Termination and Aggregation Multi-Domain (PTA-MD) exclusion feature to configure an exclusion list specifying every domain for which you want to disable L2 service selection, either remotely or locally.
The following commands are used for this configuration:
Router(config)# ssg multidomain pppRouter(config-auto-domain)# download exclude-profile profile-name passwordRouter(config-auto-domain)# download exclude-profile remote-exclude-profile passwordRouter(config-auto-domain)# exclude domain realm> local-exclude-profile
A remote exclude profile is downloaded from a AAA server and includes the Control-Info XP attribute for specifying which realm you want to exclude, as follows:
Cisco-SSG-control-info="XPrealm"Because there is no equivalent ssg multidomain ppp command on the ISG, the ISG cannot download remote exclude profiles. Therefore, the XP attribute is meaningless to the ISG.
In the case of local exclude profiles on the ISG, you cannot exclude domains on an individual basis. The configuration as described in "Configuring L2 Service Selection" section parses every structured username (user@domain or user@service) in the same manner, regardless of the domain or service name. This is because the configuration to make L2 service selection work requires use of an always condition in the control class within the event session-start. The following commands show this configuration:
Router(config)# policy-map type control DEFAULT_RULE_MAP
Router(config-control-policymap)# class type control always event session-start
Router(config-control-policymap-class-control)# 1 authenticate aaa list CAR
Router(config-control-policymap-class-control)# 2 service-policy type service name PBHK
Router(config-control-policymap-class-control)# 3 service-policy type service name DEFAULT
Router(config-control-policymap-class-control)# 4 service-policy type service aaa list CAR identifier unauthenticated-domain
No other event on the ISG, apart from session start, can be selected to make it possible to include a control condition on an event to only allow certain service names to trigger a RADIUS request, as is done by the PTA-MD exclusion feature on SSG.
SSG and ISG Accounting and RADIUS Update Examples
RADIUS accounting packets are counted differently on the ISG than they are on the SSG. Also, ISG input packets are seen on the SSG as output packets. Use the information in the following sections to understand and correct these differences:
•SSG Accounting Configuration Alternatives
SSG AAA Accounting
In the SSG, the following command enables AAA accounting of services for billing with a RADIUS server:
aaa accounting network SESM start-stop group SESMThe following attributes are defined in the SSG RADIUS profile:
Acct-Interim-Interval = 60Cisco-AVpair = subscriber:accounting-list=SESM
Note These commands and attributes enable accounting updates for the user in PPP sessions only, and not for the services.
The following example shows a log of accounting activity on the SSG, including session start (see bold text):
Apr 5 08:36:31.838: RADIUS/ENCODE(0000000D):Orig. component type = PPoAApr 5 08:36:31.838: RADIUS(0000000D): Storing nasport 0 in rad_dbApr 5 08:36:31.838: RADIUS(0000000D): Config NAS IP: 0.0.0.0Apr 5 08:36:31.838: RADIUS(0000000D): sendingApr 5 08:36:31.838: RADIUS/ENCODE: Best Local IP-Address 10.10.67.2 for Radius-Server 10.30.81.30Apr 5 08:36:31.838: RADIUS(0000000D): Send Accounting-Request to 10.30.81.30:1813 id 1646/166, len 141Apr 5 08:36:31.838: RADIUS: authenticator E2 FC 2D BB FC 1F C8 B7 - D3 7F F4 E0 CF 77 58 E2Apr 5 08:36:31.838: RADIUS: Acct-Session-Id [44] 10 "00000139"Apr 5 08:36:31.838: RADIUS: Vendor, Cisco [26] 32Apr 5 08:36:31.838: RADIUS: Cisco AVpair [1] 26 "connect-progress=Call Up"Apr 5 08:36:31.838: RADIUS: Vendor, Cisco [26] 24Apr 5 08:36:31.838: RADIUS: ssg-account-info [250] 18 "S10.10.100.11:64"Apr 5 08:36:31.838: RADIUS: Acct-Authentic [45] 6 RADIUS [1]Apr 5 08:36:31.838: RADIUS: Acct-Status-Type [40] 6 Start [1]
Apr 5 08:36:31.838: RADIUS: NAS-Port-Type [61] 6 Virtual [5]Apr 5 08:36:31.838: RADIUS: NAS-Port [5] 6 0Apr 5 08:36:31.838: RADIUS: NAS-Port-Id [87] 13 "5/0/0/1.300"Apr 5 08:36:31.838: RADIUS: Service-Type [6] 6 Framed [2]Apr 5 08:36:31.838: RADIUS: NAS-IP-Address [4] 6 10.10.67.2Apr 5 08:36:31.838: RADIUS: Acct-Delay-Time [41] 6 0Apr 5 08:36:31.930: RADIUS: Received from id 1646/166 10.30.81.30:1813, Accounting-response, len 20Apr 5 08:36:31.930: RADIUS: authenticator 99 7F C3 F4 B3 39 39 C7 - 02 0A EE 6A A5 61 B7 0EThe following example shows a log of accounting activity on the SSG, including watchdog activity (see bold text):
Apr 5 08:41:02.210: RADIUS/ENCODE(0000001C):Orig. component type = SSGApr 5 08:41:02.210: RADIUS(0000001C): Using existing nas_port 0Apr 5 08:41:02.210: RADIUS(0000001C): Config NAS IP: 0.0.0.0Apr 5 08:41:02.210: RADIUS(0000001C): sendingApr 5 08:41:02.210: RADIUS/ENCODE: Best Local IP-Address 10.10.67.2 for Radius-Server 10.30.81.30Apr 5 08:41:02.210: RADIUS(0000001C): Send Accounting-Request to 10.30.81.30:1813 id 1646/170, len 222Apr 5 08:41:02.210: RADIUS: authenticator 7B 3F FE 09 FC 91 B6 E6 - 16 A5 74 BE DA 77 03 44Apr 5 08:41:02.210: RADIUS: Acct-Session-Id [44] 10 "000001C2"Apr 5 08:41:02.210: RADIUS: Framed-IP-Address [8] 6 10.20.81.1Apr 5 08:41:02.210: RADIUS: Framed-Protocol [7] 6 PPP [1]Apr 5 08:41:02.210: RADIUS: User-Name [1] 7 "U0509"Apr 5 08:41:02.210: RADIUS: Vendor, Cisco [26] 32Apr 5 08:41:02.210: RADIUS: Cisco AVpair [1] 26 "connect-progress=Call Up"Apr 5 08:41:02.210: RADIUS: Vendor, Cisco [26] 24Apr 5 08:41:02.210: RADIUS: ssg-account-info [250] 18 "S10.10.100.11:64"Apr 5 08:41:02.210: RADIUS: Vendor, Cisco [26] 16Apr 5 08:41:02.210: RADIUS: ssg-control-info [253] 10 "I0;15699"Apr 5 08:41:02.210: RADIUS: Vendor, Cisco [26] 16Apr 5 08:41:02.210: RADIUS: ssg-control-info [253] 10 "O0;19471"Apr 5 08:41:02.210: RADIUS: Acct-Session-Time [46] 6 116Apr 5 08:41:02.210: RADIUS: Acct-Input-Octets [42] 6 0Apr 5 08:41:02.210: RADIUS: Acct-Output-Octets [43] 6 0Apr 5 08:41:02.210: RADIUS: Acct-Input-Packets [47] 6 0Apr 5 08:41:02.210: RADIUS: Acct-Output-Packets [48] 6 0Apr 5 08:41:02.214: RADIUS: Acct-Authentic [45] 6 RADIUS [1]Apr 5 08:41:02.214: RADIUS: Acct-Status-Type [40] 6 Watchdog [3]
Apr 5 08:41:02.214: RADIUS: NAS-Port-Type [61] 6 Virtual [5]Apr 5 08:41:02.214: RADIUS: NAS-Port [5] 6 0Apr 5 08:41:02.214: RADIUS: NAS-Port-Id [87] 13 "5/0/0/1.300"Apr 5 08:41:02.214: RADIUS: Service-Type [6] 6 Framed [2]Apr 5 08:41:02.214: RADIUS: NAS-IP-Address [4] 6 10.10.67.2Apr 5 08:41:02.214: RADIUS: Acct-Delay-Time [41] 6 0Apr 5 08:41:02.274: RADIUS: Received from id 1646/170 10.30.81.30:1813, Accounting-response, len 20Apr 5 08:41:02.274: RADIUS: authenticator B9 9A 96 29 2D AB EF 0D - 33 61 3D E4 26 95 F7 A0The following example shows a log of accounting activity on the SSG, including session stop (see bold text):
Apr 5 08:42:02.198: RADIUS/ENCODE(0000001C):Orig. component type = SSGApr 5 08:42:02.198: RADIUS(0000001C): Using existing nas_port 0Apr 5 08:42:02.198: RADIUS(0000001C): Config NAS IP: 0.0.0.0Apr 5 08:42:02.198: RADIUS(0000001C): sendingApr 5 08:42:02.198: RADIUS/ENCODE: Best Local IP-Address 10.10.67.2 for Radius-Server 10.30.81.30Apr 5 08:42:02.198: RADIUS(0000001C): Send Accounting-Request to 10.30.81.30:1813 id 1646/171, len 264Apr 5 08:42:02.198: RADIUS: authenticator 55 B7 F7 DE F1 63 5C DA - 00 CE 69 ED 22 76 7D 55Apr 5 08:42:02.198: RADIUS: Acct-Session-Id [44] 10 "000001C2"Apr 5 08:42:02.198: RADIUS: Framed-IP-Address [8] 6 10.20.81.1Apr 5 08:42:02.198: RADIUS: Framed-Protocol [7] 6 PPP [1]Apr 5 08:42:02.198: RADIUS: User-Name [1] 7 "U0509"Apr 5 08:42:02.198: RADIUS: Acct-Authentic [45] 6 RADIUS [1]Apr 5 08:42:02.198: RADIUS: Vendor, Cisco [26] 32Apr 5 08:42:02.202: RADIUS: Cisco AVpair [1] 26 "connect-progress=Call Up"Apr 5 08:42:02.202: RADIUS: Vendor, Cisco [26] 24Apr 5 08:42:02.202: RADIUS: ssg-account-info [250] 18 "S10.10.100.11:64"Apr 5 08:42:02.202: RADIUS: Vendor, Cisco [26] 16Apr 5 08:42:02.202: RADIUS: ssg-control-info [253] 10 "I0;15699"Apr 5 08:42:02.202: RADIUS: Vendor, Cisco [26] 16Apr 5 08:42:02.202: RADIUS: ssg-control-info [253] 10 "O0;19471"Apr 5 08:42:02.202: RADIUS: Acct-Session-Time [46] 6 176Apr 5 08:42:02.202: RADIUS: Acct-Input-Octets [42] 6 0Apr 5 08:42:02.202: RADIUS: Acct-Output-Octets [43] 6 0Apr 5 08:42:02.202: RADIUS: Acct-Input-Packets [47] 6 0Apr 5 08:42:02.202: RADIUS: Acct-Output-Packets [48] 6 0Apr 5 08:42:02.202: RADIUS: Acct-Terminate-Cause[49] 6 user-request [1]Apr 5 08:42:02.202: RADIUS: Vendor, Cisco [26] 36Apr 5 08:42:02.202: RADIUS: Cisco AVpair [1] 30 "disc-cause-ext=No Disconnect"Apr 5 08:42:02.202: RADIUS: Acct-Status-Type [40] 6 Stop [2]
Apr 5 08:42:02.202: RADIUS: NAS-Port-Type [61] 6 Virtual [5]Apr 5 08:42:02.202: RADIUS: NAS-Port [5] 6 0Apr 5 08:42:02.202: RADIUS: NAS-Port-Id [87] 13 "5/0/0/1.300"Apr 5 08:42:02.202: RADIUS: Service-Type [6] 6 Framed [2]Apr 5 08:42:02.202: RADIUS: NAS-IP-Address [4] 6 10.10.67.2Apr 5 08:42:02.202: RADIUS: Acct-Delay-Time [41] 6 0Apr 5 08:42:02.254: RADIUS: Received from id 1646/171 10.30.81.30:1813, Accounting-response, len 20Apr 5 08:42:02.254: RADIUS: authenticator 3B ED BC B8 52 E3 36 3F - 52 CC 4E 44 0F C7 AD 0CSSG Accounting Configuration Alternatives
You can also enable accounting without using the aaa accounting network SESM start-stop group SESM command, and instead use the ssg accounting per-host command. This command provides start and stop updates for user login and logout, but not for the services. To enable accounting start and stop updates for the services you would use the ssg accounting per-service command. No updates are sent for user login and logout with this command.
Note Only one of the ssg accounting commands, either ssg accounting per-host or ssg accounting per-service, can be configured at one time. Configuring one command disables the other.
Another way to enable accounting on the SSG is by using the ssg accounting interval 60 command, which causes updates for user login and logout, service enable and disable, and regular updates every 60 seconds.
You can fine-tune the ssg accounting interval 60 command by configuring specific services using the Service-Info L attribute. The L attribute overwrites the local configuration and provides a way to disable accounting updates for a specific service. The following attribute:
cisco-SSG-service-info = L0;disabledisables the accounting updates for a service. There is no way to configure the accounting update rate for the user using RADIUS attributes.
The following example shows a log of accounting activity on the SSG, including session start (see bold text):
Apr 5 08:43:14.867: RADIUS: authenticator 59 7C F3 B8 F4 B2 6A F3 - 29 97 FA E4 CE D5 8B AFApr 5 08:43:14.867: RADIUS: NAS-IP-Address [4] 6 10.10.67.2Apr 5 08:43:14.867: RADIUS: NAS-Port [5] 6 0Apr 5 08:43:14.867: RADIUS: Vendor, Cisco [26] 35Apr 5 08:43:14.867: RADIUS: cisco-nas-port [2] 29 "5/0/0/1.300*Virtual-Access1"Apr 5 08:43:14.867: RADIUS: NAS-Port-Type [61] 6 Virtual [5]Apr 5 08:43:14.867: RADIUS: User-Name [1] 7 "U0509"Apr 5 08:43:14.867: RADIUS: Calling-Station-Id [31] 7 "U0509"Apr 5 08:43:14.867: RADIUS: Acct-Status-Type [40] 6 Start [1]
Apr 5 08:43:14.867: RADIUS: Acct-Authentic [45] 6 RADIUS [1]Apr 5 08:43:14.867: RADIUS: Service-Type [6] 6 Framed [2]Apr 5 08:43:14.867: RADIUS: Acct-Session-Id [44] 10 "000001A6"Apr 5 08:43:14.867: RADIUS: Framed-Protocol [7] 6 PPP [1]Apr 5 08:43:14.867: RADIUS: Framed-IP-Address [8] 6 10.20.81.1Apr 5 08:43:14.867: RADIUS: Vendor, Cisco [26] 24Apr 5 08:43:14.867: RADIUS: ssg-account-info [250] 18 "S10.10.100.11:64"Apr 5 08:43:14.867: RADIUS: Vendor, Cisco [26] 15Apr 5 08:43:14.867: RADIUS: ssg-service-info [251] 9 "NSR0501"Apr 5 08:43:14.867: RADIUS: Vendor, Cisco [26] 14Apr 5 08:43:14.867: RADIUS: ssg-service-info [251] 8 "UU0509"Apr 5 08:43:14.867: RADIUS: Vendor, Cisco [26] 10Apr 5 08:43:14.867: RADIUS: ssg-service-info [251] 4 "TP"Apr 5 08:43:14.867: RADIUS: Acct-Delay-Time [41] 6 0Apr 5 08:43:14.907: RADIUS: Received from id 1646/173 10.30.81.30:1813, Accounting-response, len 20Apr 5 08:43:14.907: RADIUS: authenticator 53 BD 96 56 B1 39 78 54 - 63 D2 68 C5 0B 99 5F 9AThe following example shows a log of accounting activity on the SSG, including watchdog activity (see bold text):
Apr 5 08:44:14.895: RADIUS(00000000): Send Accounting-Request to 10.30.81.30:1813 id 1646/175, len 254Apr 5 08:44:14.895: RADIUS: authenticator 7A F9 3B F8 16 6F 6C BF - C1 C4 15 AA 9F A2 38 1EApr 5 08:44:14.895: RADIUS: NAS-IP-Address [4] 6 10.10.67.2Apr 5 08:44:14.895: RADIUS: NAS-Port [5] 6 0Apr 5 08:44:14.895: RADIUS: Vendor, Cisco [26] 35Apr 5 08:44:14.895: RADIUS: cisco-nas-port [2] 29 "5/0/0/1.300*Virtual-Access1"Apr 5 08:44:14.895: RADIUS: NAS-Port-Type [61] 6 Virtual [5]Apr 5 08:44:14.895: RADIUS: User-Name [1] 7 "U0509"Apr 5 08:44:14.895: RADIUS: Calling-Station-Id [31] 7 "U0509"Apr 5 08:44:14.895: RADIUS: Acct-Status-Type [40] 6 Watchdog [3]
Apr 5 08:44:14.895: RADIUS: Acct-Authentic [45] 6 RADIUS [1]Apr 5 08:44:14.895: RADIUS: Service-Type [6] 6 Framed [2]Apr 5 08:44:14.895: RADIUS: Acct-Session-Id [44] 10 "000001A6"Apr 5 08:44:14.899: RADIUS: Acct-Session-Time [46] 6 60Apr 5 08:44:14.899: RADIUS: Acct-Input-Octets [42] 6 492Apr 5 08:44:14.899: RADIUS: Acct-Output-Octets [43] 6 597Apr 5 08:44:14.899: RADIUS: Acct-Input-Packets [47] 6 5Apr 5 08:44:14.899: RADIUS: Acct-Output-Packets [48] 6 6Apr 5 08:44:14.899: RADIUS: Framed-Protocol [7] 6 PPP [1]Apr 5 08:44:14.899: RADIUS: Framed-IP-Address [8] 6 10.20.81.1Apr 5 08:44:14.899: RADIUS: Vendor, Cisco [26] 14Apr 5 08:44:14.899: RADIUS: ssg-control-info [253] 8 "I0;492"Apr 5 08:44:14.899: RADIUS: Vendor, Cisco [26] 14Apr 5 08:44:14.899: RADIUS: ssg-control-info [253] 8 "O0;597"Apr 5 08:44:14.899: RADIUS: Vendor, Cisco [26] 24Apr 5 08:44:14.899: RADIUS: ssg-account-info [250] 18 "S10.10.100.11:64"Apr 5 08:44:14.899: RADIUS: Vendor, Cisco [26] 15Apr 5 08:44:14.899: RADIUS: ssg-service-info [251] 9 "NSR0501"Apr 5 08:44:14.899: RADIUS: Vendor, Cisco [26] 14Apr 5 08:44:14.899: RADIUS: ssg-service-info [251] 8 "UU0509"Apr 5 08:44:14.899: RADIUS: Vendor, Cisco [26] 10Apr 5 08:44:14.899: RADIUS: ssg-service-info [251] 4 "TP"The following example shows a log of accounting activity on the SSG, including session stop (see bold text):
Apr 5 08:44:42.051: RADIUS/ENCODE: Best Local IP-Address 10.10.67.2 for Radius-Server 10.30.81.30Apr 5 08:44:42.051: RADIUS(00000000): Send Accounting-Request to 10.30.81.30:1813 id 1646/176, len 260Apr 5 08:44:42.051: RADIUS: authenticator AB 80 09 6A E0 C2 FB 3E - B2 75 67 DD 0A FD A3 FAApr 5 08:44:42.051: RADIUS: NAS-IP-Address [4] 6 10.10.67.2Apr 5 08:44:42.051: RADIUS: NAS-Port [5] 6 0Apr 5 08:44:42.051: RADIUS: Vendor, Cisco [26] 35Apr 5 08:44:42.051: RADIUS: cisco-nas-port [2] 29 "5/0/0/1.300*Virtual-Access1"Apr 5 08:44:42.051: RADIUS: NAS-Port-Type [61] 6 Virtual [5]Apr 5 08:44:42.051: RADIUS: User-Name [1] 7 "U0509"Apr 5 08:44:42.051: RADIUS: Calling-Station-Id [31] 7 "U0509"Apr 5 08:44:42.051: RADIUS: Acct-Status-Type [40] 6 Stop [2]
Apr 5 08:44:42.051: RADIUS: Acct-Authentic [45] 6 RADIUS [1]Apr 5 08:44:42.051: RADIUS: Service-Type [6] 6 Framed [2]Apr 5 08:44:42.051: RADIUS: Acct-Session-Id [44] 10 "000001A6"Apr 5 08:44:42.055: RADIUS: Acct-Terminate-Cause[49] 6 user-request [1]Apr 5 08:44:42.055: RADIUS: Acct-Session-Time [46] 6 87Apr 5 08:44:42.055: RADIUS: Acct-Input-Octets [42] 6 492Apr 5 08:44:42.055: RADIUS: Acct-Output-Octets [43] 6 597Apr 5 08:44:42.055: RADIUS: Acct-Input-Packets [47] 6 5Apr 5 08:44:42.055: RADIUS: Acct-Output-Packets [48] 6 6Apr 5 08:44:42.055: RADIUS: Framed-Protocol [7] 6 PPP [1]Apr 5 08:44:42.055: RADIUS: Framed-IP-Address [8] 6 10.20.81.1Apr 5 08:44:42.055: RADIUS: Vendor, Cisco [26] 14Apr 5 08:44:42.055: RADIUS: ssg-control-info [253] 8 "I0;492"Apr 5 08:44:42.055: RADIUS: Vendor, Cisco [26] 14Apr 5 08:44:42.055: RADIUS: ssg-control-info [253] 8 "O0;597"Apr 5 08:44:42.055: RADIUS: Vendor, Cisco [26] 24Apr 5 08:44:42.055: RADIUS: ssg-account-info [250] 18 "S10.10.100.11:64"Apr 5 08:44:42.055: RADIUS: Vendor, Cisco [26] 15Apr 5 08:44:42.055: RADIUS: ssg-service-info [251] 9 "NSR0501"Apr 5 08:44:42.055: RADIUS: Vendor, Cisco [26] 14Apr 5 08:44:42.055: RADIUS: ssg-service-info [251] 8 "UU0509"Apr 5 08:44:42.055: RADIUS: Vendor, Cisco [26] 10Apr 5 08:44:42.055: RADIUS: ssg-service-info [251] 4 "TP"Apr 5 08:44:42.055: RADIUS: Acct-Delay-Time [41] 6 0Apr 5 08:44:42.151: RADIUS: Received from id 1646/176 10.30.81.30:1813, Accounting-response, len 20Apr 5 08:44:42.151: RADIUS: authenticator B0 F3 CC 18 67 D5 D2 FD - D5 1C D2 9C EA 3C D4 9DISG Accounting
There are two methods available to configure accounting update packets for user login and logout, and service start and stop.
1. The first method inserts RADIUS attribute 85 in the subscriber profile, as shown in the following example:
Acct-Interim-Interval = 2Cisco-AVpair = subscriber:accounting-list=SESMThe following ISG configuration command enables AAA accounting of services for billing with a RADIUS server—this is the same command used on the SSG:
aaa accounting network SESM start-stop group SESM2. The second method for configuring interim accounting works for both PPP and non-PPP sessions. The following RADIUS attribute could be inserted in both a service and subscriber profile:
Cisco-AVpair = subscriber:accounting-list=SESMYou would configure the following commands on the ISG:
aaa accounting update periodic 1aaa accounting network SESM start-stop group SESMThe following examples show logs of accounting activity on the ISG using the debug aaa accounting command.
The following example shows activity for session start:
Apr 5 09:39:37.148: AAA/ACCT/HC(00007245): PPoA/DE000244 [pre-sess] (rx/tx) adjusted, pre 46/7 call 0/0Apr 5 09:39:37.148: AAA/ACCT/NET(00007245): Queueing record is STARTApr 5 09:39:37.148: AAA/ACCT(00007245): Accounting method=SESM (RADIUS)Apr 5 09:39:37.184: AAA/ACCT/NET(00007245): START protocol reply PASSApr 5 09:39:37.184: AAA/ACCT(00007245): Send START accounting notification to EM successfullyApr 5 09:39:37.184: AAA/ACCT(00007245): Resetting Periodic timerApr 5 09:39:37.248: AAA/ACCT/EVENT/(00007245): IPCP_PASSThe following example shows watchdog activity:
Apr 5 09:40:36.656: AAA/ACCT/CLIENT(00007245): recv 33920000bps xmit 33920000bpsApr 5 09:40:36.656: AAA/ACCT/HC(00007245): Update PPoA/DE000244Apr 5 09:40:36.656: AAA/ACCT/HC(00007245): PPoA/DE000244 [sess] (rx/tx) base 0/0 pre 46/7 call 348/183Apr 5 09:40:36.656: AAA/ACCT/HC(00007245): PPoA/DE000244 [sess] (rx/tx) adjusted, pre 46/7 call 302/176Apr 5 09:40:36.656: AAA/ACCT/NET(00007245): Queueing record is UPDATEApr 5 09:40:36.656: AAA/ACCT(00007245): Sending periodic record type=NET user=U0509Apr 5 09:40:36.656: AAA/ACCT(00007245): Accounting method=SESM (RADIUS)Apr 5 09:40:36.728: AAA/ACCT/NET(00007245): UPDATE protocol reply PASSApr 5 09:40:36.728: AAA/ACCT(00007245): Send UPDATE accounting notification to EM successfullyApr 5 09:40:36.728: AAA/ACCT(00007245): Resetting Periodic timerThe following example shows session stop:
Apr 5 09:41:14.272: AAA/ACCT/EVENT/(00007249): NET DOWNApr 5 09:41:14.272: AAA/ACCT/NET(00007249): Method list not foundApr 5 09:41:14.272: AAA/ACCT(00007249): del node, session 29377Apr 5 09:41:14.272: AAA/ACCT/NET(00007249): free_rec, count 0Apr 5 09:41:14.272: AAA/ACCT/NET(00007249) reccnt 0, csr FALSE, osr 0Apr 5 09:41:14.272: AAA/ACCT/CLIENT(00007249): recv 33920000bps xmit 33920000bpsApr 5 09:41:14.272: AAA/ACCT/HC(00007249): Update PPoA/7D000247Apr 5 09:41:14.272: AAA/ACCT/HC(00007249): PPoA/7D000247 [pre-sess] (rx/tx) base 0/0 pre 0/0 call 0/0Apr 5 09:41:14.272: AAA/ACCT/HC(00007249): PPoA/7D000247 [pre-sess] (rx/tx) adjusted, pre 0/0 call 0/0Apr 5 09:41:14.272: AAA/ACCT/CLIENT(00007249): recv 33920000bps xmit 33920000bpsApr 5 09:41:14.272: AAA/ACCT/HC(00007249): Update PPoA/7D000247Apr 5 09:41:14.272: AAA/ACCT/HC(00007249): PPoA/7D000247 [sess] (rx/tx) base 0/0 pre 0/0 call 0/0Apr 5 09:41:14.272: AAA/ACCT/HC(00007249): PPoA/7D000247 [sess] (rx/tx) adjusted, pre 0/0 call 0/0Apr 5 09:41:14.272: AAA/ACCT/HC(00007249): Deregister PPoA/7D000247Apr 5 09:41:14.272: AAA/ACCT/EVENT/(00007249): CALL STOPApr 5 09:41:14.272: AAA/ACCT(00007249) reccnt 0, osr 0The following examples show a log of accounting activity on the SSG using the debug aaa accounting and radius accounting commands.
The following log shows activity for session start:
Apr 5 12:37:52.561: AAA/ACCT/NET(00007245): Flow id 1 createdApr 5 12:37:52.561: AAA/ACCT/NET(00007245): add, count 2Apr 5 12:37:52.561: AAA/ACCT/NET(00007245): Pick method list 'SESM'Apr 5 12:37:52.561: AAA/ACCT(00007245): Type NET: Periodic timer initializedApr 5 12:37:52.561: AAA/ACCT/EVENT/(00007245): NET UPApr 5 12:37:52.561: AAA/ACCT/NET(00007245): Queueing record is STARTApr 5 12:37:52.561: AAA/ACCT(00007245): Accounting method=SESM (RADIUS)Apr 5 12:37:52.561: RADIUS/ENCODE(00007245):Orig. component type = PPoAApr 5 12:37:52.561: RADIUS(00007245): Config NAS IP: 10.10.67.6Apr 5 12:37:52.561: RADIUS(00007245): sendingApr 5 12:37:52.561: RADIUS(00007245): Send Accounting-Request to 10.30.81.30:1813 id 1646/4, len 113Apr 5 12:37:52.561: RADIUS: authenticator A9 47 BE D1 D7 2F FF 5A - 0E 86 C4 2F FF DF 76 D8Apr 5 12:37:52.561: RADIUS: Acct-Session-Id [44] 10 "000074C3"Apr 5 12:37:52.561: RADIUS: Framed-Protocol [7] 6 PPP [1]Apr 5 12:37:52.561: RADIUS: Vendor, Cisco [26] 15Apr 5 12:37:52.561: RADIUS: ssg-service-info [251] 9 "NSR0501"Apr 5 12:37:52.561: RADIUS: User-Name [1] 7 "U0509"Apr 5 12:37:52.565: RADIUS: Acct-Status-Type [40] 6 Start [1]Apr 5 12:37:52.565: RADIUS: NAS-Port-Type [61] 6 Virtual [5]Apr 5 12:37:52.565: RADIUS: NAS-Port [5] 6 0Apr 5 12:37:52.565: RADIUS: NAS-Port-Id [87] 13 "5/0/0/1.301"Apr 5 12:37:52.565: RADIUS: Service-Type [6] 6 Framed [2]Apr 5 12:37:52.565: RADIUS: NAS-IP-Address [4] 6 10.10.67.6Apr 5 12:37:52.565: RADIUS: Event-Timestamp [55] 6 1112704672Apr 5 12:37:52.565: RADIUS: Acct-Delay-Time [41] 6 0Apr 5 12:37:52.565: RADIUS/ENCODE(00007245):Orig. component type = PPoAApr 5 12:37:52.649: RADIUS: Received from id 1646/4 10.30.81.30:1813, Accounting-response, len 20Apr 5 12:37:52.649: RADIUS: authenticator 9E 40 FA ED 45 D3 81 06 - 85 9E 1D EE E4 FF 58 1BApr 5 12:37:52.649: AAA/ACCT/NET(00007245): START protocol reply PASSApr 5 12:37:52.649: AAA/ACCT(00007245): Send START accounting notification to EM successfullyApr 5 12:37:52.649: AAA/ACCT(00007245): Resetting Periodic timerThe following example shows watchdog activity (text in bold for purpose of example):
Apr 5 12:36:42.857: AAA/ACCT/NET(00007245): Queueing record is UPDATEApr 5 12:36:42.857: AAA/ACCT(00007245): Sending periodic record type=NET user=U0509Apr 5 12:36:42.857: AAA/ACCT(00007245): Accounting method=SESM (RADIUS)Apr 5 12:36:42.857: RADIUS/ENCODE(00007245):Orig. component type = PPoAApr 5 12:36:42.857: RADIUS(00007245): Config NAS IP: 10.10.67.6Apr 5 12:36:42.857: RADIUS(00007245): sendingApr 5 12:36:42.857: RADIUS(00007245): Send Accounting-Request to 10.30.81.30:1813 id 1646/1, len 143Apr 5 12:36:42.857: RADIUS: authenticator 28 6F 88 46 F9 ED 8C 85 - 1F FB 4F 36 14 D0 D2 BCApr 5 12:36:42.857: RADIUS: Acct-Session-Id [44] 10 "000072E4"Apr 5 12:36:42.857: RADIUS: Framed-Protocol [7] 6 PPP [1]Apr 5 12:36:42.857: RADIUS: Vendor, Cisco [26] 15Apr 5 12:36:42.857: RADIUS: ssg-service-info [251] 9 "NSR0501"Apr 5 12:36:42.857: RADIUS: User-Name [1] 7 "U0509"Apr 5 12:36:42.857: RADIUS: Acct-Input-Packets [47] 6 0Apr 5 12:36:42.857: RADIUS: Acct-Output-Packets [48] 6 0Apr 5 12:36:42.857: RADIUS: Acct-Input-Octets [42] 6 0Apr 5 12:36:42.857: RADIUS: Acct-Output-Octets [43] 6 0Apr 5 12:36:42.857: RADIUS: Acct-Session-Time [46] 6 9999Apr 5 12:36:42.857: RADIUS: Acct-Status-Type [40] 6 Watchdog [3]
Apr 5 12:36:42.857: RADIUS: NAS-Port-Type [61] 6 Virtual [5]Apr 5 12:36:42.857: RADIUS: NAS-Port [5] 6 0Apr 5 12:36:42.857: RADIUS: NAS-Port-Id [87] 13 "5/0/0/1.301"Apr 5 12:36:42.857: RADIUS: Service-Type [6] 6 Framed [2]Apr 5 12:36:42.857: RADIUS: NAS-IP-Address [4] 6 10.10.67.6Apr 5 12:36:42.861: RADIUS: Event-Timestamp [55] 6 1112704602Apr 5 12:36:42.861: RADIUS: Acct-Delay-Time [41] 6 0Apr 5 12:36:42.893: RADIUS: Received from id 1646/1 10.30.81.30:1813, Accounting-response, len 20Apr 5 12:36:42.893: RADIUS: authenticator 6C 7A 02 67 04 0F CB 73 - 21 C8 06 D6 54 FB C8 1FApr 5 12:36:42.893: AAA/ACCT/NET(00007245): UPDATE protocol reply PASSApr 5 12:36:42.893: AAA/ACCT(00007245): Send UPDATE accounting notification to EM successfullyApr 5 12:36:42.893: AAA/ACCT(00007245): Resetting Periodic timerThe following example shows service stop:
Apr 5 12:37:17.937: AAA/ACCT(00007245): Accounting method=SESM (RADIUS)Apr 5 12:37:17.937: RADIUS/ENCODE(00007245):Orig. component type = PPoAApr 5 12:37:17.937: RADIUS(00007245): Config NAS IP: 10.10.67.6Apr 5 12:37:17.937: RADIUS(00007245): sendingApr 5 12:37:17.937: RADIUS(00007245): Send Accounting-Request to 10.30.81.30:1813 id 1646/2, len 181Apr 5 12:37:17.937: RADIUS: authenticator 3B 11 0F 7B 92 57 83 15 - B8 6C 2C B2 86 90 D2 31Apr 5 12:37:17.937: RADIUS: Acct-Session-Id [44] 10 "000072E4"Apr 5 12:37:17.937: RADIUS: Framed-Protocol [7] 6 PPP [1]Apr 5 12:37:17.937: RADIUS: Vendor, Cisco [26] 15Apr 5 12:37:17.937: RADIUS: ssg-service-info [251] 9 "NSR0501"Apr 5 12:37:17.937: RADIUS: User-Name [1] 7 "U0509"Apr 5 12:37:17.937: RADIUS: Acct-Input-Packets [47] 6 0Apr 5 12:37:17.937: RADIUS: Acct-Output-Packets [48] 6 0Apr 5 12:37:17.937: RADIUS: Acct-Input-Octets [42] 6 0Apr 5 12:37:17.937: RADIUS: Acct-Output-Octets [43] 6 0Apr 5 12:37:17.937: RADIUS: Acct-Session-Time [46] 6 10034Apr 5 12:37:17.937: RADIUS: Acct-Terminate-Cause[49] 6 none [0]Apr 5 12:37:17.937: RADIUS: Vendor, Cisco [26] 32Apr 5 12:37:17.937: RADIUS: Cisco AVpair [1] 26 "disc-cause-ext=No Reason"Apr 5 12:37:17.937: RADIUS: Acct-Status-Type [40] 6 Stop [2]Apr 5 12:37:17.937: RADIUS: NAS-Port-Type [61] 6 Virtual [5]Apr 5 12:37:17.937: RADIUS: NAS-Port [5] 6 0Apr 5 12:37:17.937: RADIUS: NAS-Port-Id [87] 13 "5/0/0/1.301"Apr 5 12:37:17.937: RADIUS: Service-Type [6] 6 Framed [2]Apr 5 12:37:17.941: RADIUS: NAS-IP-Address [4] 6 10.10.67.6Apr 5 12:37:17.941: RADIUS: Event-Timestamp [55] 6 1112704637Apr 5 12:37:17.941: RADIUS: Acct-Delay-Time [41] 6 0Apr 5 12:37:17.941: RADIUS/ENCODE(00007245):Orig. component type = PPoAApr 5 12:37:17.977: RADIUS: Received from id 1646/2 10.30.81.30:1813, Accounting-response, len 20Apr 5 12:37:17.977: RADIUS: authenticator 28 DF AA 20 78 0E AA A7 - 43 72 FD 3B C6 04 5B E5Apr 5 12:37:17.977: AAA/ACCT/NET(00007245): STOP protocol reply PASSApr 5 12:37:17.977: AAA/ACCT(00007245): Send STOP accounting notification to EM successfullyApr 5 12:37:17.977: AAA/ACCT/NET(00007245): Cleaning up from Callback osr 0Apr 5 12:37:17.977: AAA/ACCT/NET(00007245) Record not presentApr 5 12:37:17.977: AAA/ACCT/NET(00007245) reccnt 1, csr FALSE, osr 0SSG-to-ISG Migration of Prepaid and Postpaid Services Examples
The following sections compare SSG and ISG prepaid and postpaid services, and provide information that will help you migrate these services:
•SSG Basic Prepaid and Postpaid Time- and Volume-Based Services
•ISG Basic Prepaid and Postpaid Time- and Volume-Based Services
•SSG Dual Quota Prepaid Service
•ISG Dual Quota Prepaid Service
•SSG Tariff Switching: Postpaid Services
•ISG Tariff Switching: Postpaid Services
•SSG Tariff Switching: Prepaid Services
•ISG Tariff Switching: Prepaid Services
SSG Basic Prepaid and Postpaid Time- and Volume-Based Services
The SSG Prepaid feature allows SSG to immediately check a subscriber's available credit, to allow or disallow access to certain services. The subscriber's credit is administered by the billing server as a series of quotas representing either a duration of use (in seconds) or an allowable data volume (in bytes). A quota is an allotment of available credit.
To obtain the first quota for a connection, SSG submits an authorization request to the AAA server. The AAA server contacts the prepaid billing server, which forwards the quota values to SSG. SSG then monitors the connection to track the quota usage. When the quota runs out, SSG performs reauthorization. During reauthorization, the billing server may provide SSG with an additional quota if there is available credit. If no further quota is provided, SSG logs the user off.
Prepaid service is defined in a service profile by the Service-Info Z attribute (see bold text in the following example):
prepaid-time Password = "servicecisco", Service-Type = Outbound
SSG-Service-Info [26,9,251]= "Iprepaid-time",
SSG-Service-Info [26,9,251]= "R192.168.10.0;255.255.255.0",
SSG-Service-Info [26,9,251]= "MC",
SSG-Service-Info [26,9,251]= "TP",
SSG-Service-Info [26,9,251]= "Z"
prepaid-volume Password = "servicecisco", Service-Type = Outbound
SSG-Service-Info [26,9,251]= "Iprepaid-volume",
SSG-Service-Info [26,9,251]= "R192.168.11.0;255.255.255.0",
SSG-Service-Info [26,9,251]= "MC",
SSG-Service-Info [26,9,251]= "TP",
SSG-Service-Info [26,9,251]= "Z"
The prepaid service type is determined by a RADIUS Access-Accept answer from the billing server in reply to the prepaid Authorization-Request sent from the SSG. Time-based prepaid services are defined by the Control-Info QT attribute, and volume-based prepaid services are defined by the Control-Info QV attribute.
When a subscriber logs in to a prepaid service, the SSG sends an authorization Access-Request to the billing server before activating the service, to verify that the subscriber has quota left to use the service. The following example shows a log of the RADIUS Access-Request activity for quota from the SSG to the billing server, for a user named pp-tc71-user1 (key text in bold for purpose of example):
RADIUS(00000000): Send Access-Request to 10.30.81.45:1812 id 1645/16, len 142
RADIUS: authenticator 78 99 C4 5A 5E E7 9E 6D - 01 E0 3D 58 98 F1 76 B6
RADIUS: User-Name [1] 15 "pp-tc71-user1"
RADIUS: User-Password [2] 18 *
RADIUS: Calling-Station-Id [31] 15 "pp-tc71-user1"
RADIUS: Vendor, Cisco [26] 23
RADIUS: ssg-account-info [250] 17 "S10.10.100.6:64"
RADIUS: Vendor, Cisco [26] 23
RADIUS: ssg-service-info [251] 17 "Nprepaid-volume"
RADIUS: Acct-Session-Id [44] 10 "00000011"
RADIUS: Service-Type [6] 6 Framed [2]
RADIUS: NAS-IP-Address [4] 6 10.10.100.6
RADIUS: Event-Timestamp [55] 6 1112173975
The following log is an example of the RADIUS Access-Accept answer from the billing server in response to the billing request from the SSG. The The QV attribute value listed in the following example (in bold text for purpose of example) indicates the user has quota remaining.
RADIUS: Received from id 1645/16 10.30.81.45:1812, Access-Accept, len 78RADIUS: authenticator C6 41 68 41 1D 95 FD 22 - ED 03 53 ED 91 AF DA 53RADIUS: Service-Type [6] 6 Framed [2]RADIUS: Class [25] 14RADIUS: 70 72 65 70 61 69 64 2D 74 63 37 31 [prepaid-tc71]RADIUS: Vendor, Cisco [26] 23RADIUS: ssg-service-info [251] 17 "Nprepaid-volume"
RADIUS: Vendor, Cisco [26] 15RADIUS: ssg-control-info [253] 9 "QV10000"l
If the Control-Info QV or QT attribute is set to 0, the service will not be activated on the SSG. A new authorization request will be sent out from the SSG to the billing server as soon as the subscriber has consumed all of the quota received from the billing server.
Note The following RADIUS-specific configuration commands are applied on the SSG so that some attributes can be inserted in the Access-Request. The following commands insert Cisco AV pairs for attribute 44 (acct-session-id), attribute 55 (UNIX time stamp format), and attribute 25 (class attribute):
radius-server attribute 44 include-in-access-reqradius-server attribute 55 access-request includeradius-server attribute 25 access-request includeradius-server vsa send authentication
There are several ways to indicate which method list to use for authorization, so the authorization request from the SSG is sent to the correct billing server.
One way is on a virtual template interface using the following configuration commands:
interface virtual-template 1ppp authorization <method-list name>aaa authorization network <method-list name> group <radius server-group>aaa group server radius <radius server-group>server <ip address> auth-port [author-port #] acct-port [acct-port #]radius-server host <ip add> auth-port [author-port #] acct-port [acct-port #] key <shared key>A second way is to configure the SSG to use a certain RADIUS server group for prepaid authorization using the following commands:
ssg aaa group prepaid <radius server-group>aaa group server radius <radius server-group>server <ip address> auth-port [author-port #] acct-port [acct-port #]radius-server host <ip add> auth-port [author-port #] acct-port [acct-port #] key <shared key>When you add the ssg aaa group prepaid command to the configuration, the SSG automatically inserts the following command and an internally created and used method list name:
aaa authorization network ssg_sg_prepaid_author_internal group <radius server-group>If neither of the two previous methods was used, a default authorization method, such as the following default authorization list configuration, is used:
aaa authorization network default group <radius server-group>aaa group server radius <radius server-group>server <ip address> auth-port [author-port #] acct-port [acct-port #]radius-server host <ip add> auth-port [author-port #] acct-port [acct-port #] key <shared key>ISG Basic Prepaid and Postpaid Time- and Volume-Based Services
Prepaid service on the ISG is no longer defined by the Service-Info Z attribute, but instead by a Cisco AV pair [26,9,1] with the string "prepaid-config=prepaid-subscriber-feature-name." The prepaid-subscriber-feature-name supplied in the RADIUS profile is a user-defined name that refers to the same name defined in a local configuration of the prepaid subscriber feature on the ISG. Following are the ISG commands that are entered to configure this feature:
subscriber feature prepaid <prepaid subscriber feature name>threshold time 0 secondsthreshold volume 0 bytesmethod-list author <author method-list to use for prepaid author>method-list accounting <acct method-list to use for prepaid acct>password <password in access-request for prepaid author>There is also a subscriber feature prepaid default configuration command available on the ISG that supplies the name "default" for the prepaid subscriber feature. Be aware that this default profile for the subscriber prepaid feature will not appear in the output of the show running-config command if none of the default parameters underneath the feature configuration were changed. By default, the prepaid feature configuration is configured as follows:
subscriber feature prepaid defaultthreshold time 0 secondsthreshold volume 0 bytesmethod-list authorization defaultmethod-list accounting defaultpassword ciscoUnless one of the parameters underneath this configuration is changed, you will not see this configuration when looking at the configuration of the router using the show running-config command. The following altered default configuration will be visible in the configuration of the router because the method list names were changed:
subscriber feature prepaid defaultthreshold time 0 secondsthreshold volume 0 bytesmethod-list authorization rsim-mlmethod-list accounting default rsim-mlpassword serviceciscoThe method lists created on the ISG for the subscriber prepaid feature profile define which method list to use when a prepaid authorization (such as retrieving quota on the billing server) must be done. The method list indicates to the ISG which RADIUS server group to use, and the server group contains details about the billing server. The ISG works the same way as the SSG in this respect; no changes are required in the AAA part of the configuration.
Following is a partial example of the ISG subscriber prepaid configuration showing new ISG commands (highlighted in bold for purpose of example) to define the method list and the existing AAA commands:
...subscriber feature prepaid defaultthreshold time 0 secondsthreshold volume 0 bytesmethod-list author rsim-ml-author
method-list accounting rsim-ml-acct
password serviceciscoaaa authorization network rsim-ml-author group billing-rsimaaa accounting network rsim-ml-acct start-stop group billing-rsimaaa group server radius billing-rsim
server 10.30.81.45 auth-port 1812 acct-port 1813ip radius source-interface Loopback0radius-server host 10.30.81.45 auth-port 1812 acct-port 1812 key ww...For the prepaid functionality to work on the ISG, you must insert a traffic class into the service profile when defining prepaid service. The traffic class configurations are mandatory and replace the Service-Info R attribute in the SSG prepaid service profile, because the ISG does not interpret this attribute. The following example shows a completely migrated prepaid service profile. Bold text indicates attributes that are added for configuration on the ISG.
prepaid-time Password = "servicecisco", Service-Type = OutboundSSG-Service-Info [26,9,251]= "Iprepaid-time",SSG-Service-Info [26,9,251]= "R192.168.10.0;255.255.255.0",SSG-Service-Info [26,9,251]= "MC",SSG-Service-Info [26,9,251]= "TP",SSG-Service-Info [26,9,251]= "Z",Cisco AV-pair [26,9,1] = "prepaid-config=default",
Cisco AV-pair [26,9,1] = "ip:traffic-class=in access-group name prepaid-time-acl priority 1",
Cisco AV-pair [26,9,1] = "ip:traffic-class=out access-group name prepaid-time-acl priority 1"
prepaid-volume Password = "servicecisco", Service-Type = OutboundSSG-Service-Info [26,9,251]= "Iprepaid-volume",SSG-Service-Info [26,9,251]= "R192.168.11.0;255.255.255.0",SSG-Service-Info [26,9,251]= "MC",SSG-Service-Info [26,9,251]= "TP",SSG-Service-Info [26,9,251]= "Z",Cisco AV-pair [26,9,1] = "prepaid-config=default",
Cisco AV-pair [26,9,1] = "ip:traffic-class=in access-group name prepaid-vol-acl priority 1",
Cisco AV-pair [26,9,1] = "ip:traffic-class=out access-group name prepaid-vol-acl priority 1"
To complete the migration, you must insert extended IP ACLs that are used in the traffic class AV pairs on the ISG. The ACLs replace the Service-Info R attribute value, and are configured as follows:
ip access-list extended prepaid-time-aclpermit ip any 192.168.10.0 255.255.255.0permit ip 192.168.10.0 255.255.255.0 anyip access-list extended prepaid-vol-aclpermit ip any 192.168.11.0 255.255.255.0permit ip 192.168.11.0 255.255.255.0 anyThe authorization process between the router and the billing server remain the same for both the SSG and ISG. Like the SSG, the ISG sends an authorization request to the billing server before activating the prepaid service for the subscriber, to verify that the subscriber has enough quota remaining to use the service. The Control-Info QV and QT attributes used by the billing server are interpreted the same way by the ISG as they are for the SSG. If the RADIUS Access-Accept answer from the billing server contains a QV value, it is a volume-based prepaid service; if the RADIUS Access-Accept answer from the billing server contains a QT value, it is a time-based prepaid service. If the Control-Info Q attribute value sent by the billing server is zero, the service will be deactivated on the ISG for the corresponding subscriber.
The following log is an example of the RADIUS Access-Request for quota sent from the ISG to the billing server (text highlighted for purpose of example):
RADIUS(000000EE): Send Access-Request to 10.30.81.45:1812 id 1645/126, len 149RADIUS: authenticator 86 06 D6 96 7F 90 5C 21 - 8D FA D2 F2 8A F2 F1 A6RADIUS: User-Name [1] 15 "pp-tc71-user1"
RADIUS: User-Password [2] 18 *RADIUS: Vendor, Cisco [26] 23RADIUS: ssg-service-info [251] 17 "Nprepaid-volume"
RADIUS: Framed-Protocol [7] 6 PPP [1]RADIUS: NAS-Port-Type [61] 6 Virtual [5]RADIUS: NAS-Port [5] 6 0RADIUS: NAS-Port-Id [87] 13 "3/0/0/0.201"RADIUS: Class [25] 14RADIUS: 70 72 65 70 61 69 64 2D 74 63 37 31 [prepaid-tc71]RADIUS: Service-Type [6] 6 Framed [2]RADIUS: NAS-IP-Address [4] 6 10.10.100.7RADIUS: Acct-Session-Id [44] 10 "00000122"RADIUS: Event-Timestamp [55] 6 1112183844The following example shows a log of the RADIUS Access-Accept answer sent from the billing server to authorize the request sent from the ISG:
RADIUS: Received from id 1645/126 10.30.81.45:1812, Access-Accept, len 78RADIUS: authenticator 22 7F 0F 01 8A 6E 50 50 - 4B 05 E2 C3 08 0A D8 83RADIUS: Service-Type [6] 6 Framed [2]RADIUS: Class [25] 14RADIUS: 70 72 65 70 61 69 64 2D 74 63 37 31 [prepaid-tc71]RADIUS: Vendor, Cisco [26] 23RADIUS: ssg-service-info [251] 17 "Nprepaid-volume"
RADIUS: Vendor, Cisco [26] 15RADIUS: ssg-control-info [253] 9 "QV10000"
As with the SSG, if the Control-Info QV or QT attribute is set to 0, the service will not be activated on the ISG. A new authorization request will be sent out from the ISG to the billing server as soon as the subscriber has consumed all of the quota received from the billing server.
Note The following RADIUS-specific configuration commands are applied on both the SSG and ISG so that required attributes—attribute 44 (acct-session-id), attribute 55 (UNIX time stamp format), and attribute 25 (class attribute)—are inserted in the Access-Request:
radius-server attribute 44 include-in-access-reqradius-server attribute 55 access-request includeradius-server attribute 25 access-request includeradius-server vsa send authentication
To verify that a service is activated for a user on the ISG, you must determine whether a unique session ID (uid) was created for the traffic class feature. The uid is associated with the traffic class interface name and the subscriber authenticated name. In the following example, uid 294 identifies the subscriber session, and uid 296 identifies the traffic class created for the prepaid service:
Router# show subscriber session
Current Subscriber Information: Total sessions 1Uniq ID Interface State Service Identifier Up-time296 Traffic-Cl unauthen Ltm Internal pp-tc71-user1 00:13:09295 Traffic-Cl unauthen Ltm Internal 00:18:00294 Vi4 authen Local Term pp-tc71-user1 00:18:00Router# show subscriber session uid 294
Unique Session ID: 294
Identifier: pp-tc71-user1
SIP subscriber access type(s): PPPoE/PPP
Current SIP options: Req Fwding/Req FwdedSession Up-time: 00:18:42, Last Changed: 00:13:52AAA unique ID: 238Interface: Virtual-Access4Policy information:Context 208C2864: Handle 9400011FAuthentication status: authenActive services associated with session:name "prepaid-volume"name "prepaid-redirect"name "PBHK"Rules, actions and conditions executed:subscriber rule-map prepaid-usercondition always event session-start1 authenticate aaa list rsim-ml2 service-policy type service name PBHK3 service-policy type service name prepaid-redirectsubscriber rule-map prepaid-usercondition always event service-start1 service-policy type service aaa list rsim-ml identifier service-nameSession inbound features:Feature: Layer 4 RedirectRule table is emptyTraffic classes:Traffic class session ID: 295ACL Name: prepaid-redirect-acl, Packets = 0, Bytes = 0Traffic class session ID: 296
ACL Name: prepaid-vol-acl, Packets = 0, Bytes = 0
Unmatched Packets (dropped) = 0, Re-classified packets (redirected) = 0Feature: Portbundle HostkeyPortbundle IP = 10.10.100.7 Bundle Number = 82Session outbound features:Traffic classes:Traffic class session ID: 295ACL Name: prepaid-redirect-acl, Packets = 0, Bytes = 0Traffic class session ID: 296
ACL Name: prepaid-vol-acl, Packets = 0, Bytes = 0
Unmatched Packets (dropped) = 0, Re-classified packets (redirected) = 0Configuration sources associated with this session:Service: prepaid-volume, Active Time = 00:13:53Service: prepaid-redirect, Active Time = 00:18:43Service: PBHK, Active Time = 00:18:43Interface: Virtual-Template2, Active Time = 00:18:43A volume-based service is recognized in the traffic class by the presence of the prepaid volume monitor feature in the show subscriber session command details. These features are highlighted in bold in the following example:
Router# show subscriber session uid 296
Unique Session ID: 296
Identifier: pp-tc71-user1
SIP subscriber access type(s): Traffic-Class
Current SIP options: NoneSession Up-time: 00:14:15, Last Changed: 00:14:15AAA unique ID: 0Policy information:Context 208C308C: Handle 9B000124Authentication status: unauthenPrepaid context: defaultthreshold time 0 secondsthreshold volume 0 bytesmethod-list author rsim-mlmethod-list accounting rsim-mlpassword serviceciscoInterim accounting disabledState PREPAID_FEATURE_RUNNING
Flow idle ? NOTotal idle time 0 secondsAre we accounting for time consumed ? YESAcct start sent ? YESSession inbound features:Feature: Prepaid Volume Monitor
Threshold:10000 - Quota:10000Usage(since last update):0 - Total:0
Current states: StartSession outbound features:Feature: Prepaid Volume Monitor
Threshold:10000 - Quota:10000Usage(since last update):0 - Total:0
Current states: StartConfiguration sources associated with this session:Service: prepaid-volume, Active Time = 00:14:17The counters for usage will be updated periodically when traffic is forwarded to an IP destination matching the ACL configured for the traffic class. As soon as the current usage counter is higher than the threshold, a reauthorization request will be sent to the billing server to retrieve more quota for the service the subscriber is using.
Note The frequency to refresh the usage counters on the traffic class for the prepaid service is not configurable.
A time-based service can be recognized in the traffic class by the presence of the time monitor feature in the show subscriber session command details. These features are highlighted in bold in the following example:
Router# show subscriber session uid 479
Unique Session ID: 479Identifier: pp-tc71-user1
SIP subscriber access type(s): Traffic-Class
Current SIP options: NoneSession Up-time: 00:00:04, Last Changed: 00:00:04AAA unique ID: 0Policy information:Context 2078F50C: Handle 80000347Authentication status: unauthenPrepaid context: defaultthreshold time 0 secondsthreshold volume 0 bytesmethod-list author rsim-mlmethod-list accounting rsim-mlpassword serviceciscoInterim accounting disabledState PREPAID_FEATURE_RUNNINGFlow idle ? NOTotal idle time 0 secondsAre we accounting for time consumed ? YESAcct start sent ? YESSession inbound features:Feature: Prepaid Volume MonitorThreshold:4294967295 - Quota:4294967295Usage(since last update):0 - Total:0Current states: StartSession outbound features:Feature: Prepaid Volume MonitorThreshold:4294967295 - Quota:4294967295Usage(since last update):0 - Total:0Current states: StartNon-datapath features:Feature: Time MonitorThreshold: 60 (seconds) - Quota: 60 (seconds)Session time: 5 (seconds)Configuration sources associated with this session:Service: prepaid-time, Active Time = 00:00:05The next authorization request will be sent as soon as the monitor timer (not visible in the show command display) exceeds the threshold time. If you want to see all authorized service for the subscribers and subscriber details, use the show subscriber session command with the username, as shown in the following example:
Router# show subscriber session username pp-tc71-user1
Unique Session ID: 479Identifier: pp-tc71-user1
SIP subscriber access type(s): Traffic-Class
Current SIP options: NoneSession Up-time: 00:00:04, Last Changed: 00:00:04AAA unique ID: 0Policy information:Context 2078F50C: Handle 80000347Authentication status: unauthenPrepaid context: defaultthreshold time 0 secondsthreshold volume 0 bytesmethod-list author rsim-mlmethod-list accounting rsim-mlpassword serviceciscoInterim accounting disabledState PREPAID_FEATURE_RUNNINGFlow idle ? NOTotal idle time 0 secondsAre we accounting for time consumed ? YESAcct start sent ? YESSession inbound features:Feature: Prepaid Volume MonitorThreshold:4294967295 - Quota:4294967295Usage(since last update):0 - Total:0Current states: StartSession outbound features:Feature: Prepaid Volume MonitorThreshold:4294967295 - Quota:4294967295Usage(since last update):0 - Total:0Current states: StartNon-datapath features:Feature: Time MonitorThreshold: 60 (seconds) - Quota: 60 (seconds)Session time: 5 (seconds)Configuration sources associated with this session:Service: prepaid-time, Active Time = 00:00:05Unique Session ID: 473
Identifier: pp-tc71-user1SIP subscriber access type(s): PPPoE/PPP
Current SIP options: Req Fwding/Req FwdedSession Up-time: 00:44:03, Last Changed: 00:00:05AAA unique ID: 316Interface: Virtual-Access3Policy information:Context 2078EF9C: Handle E1000336Authentication status: authenActive services associated with session:name "prepaid-time"name "prepaid-redirect"name "PBHK"Rules, actions and conditions executed:subscriber rule-map prepaid-usercondition always event session-start1 authenticate aaa list rsim-ml2 service-policy type service name PBHK3 service-policy type service name prepaid-redirectsubscriber rule-map prepaid-usercondition always event service-start1 service-policy type service aaa list rsim-ml identifier service-nameSession inbound features:Feature: Layer 4 RedirectRule table is emptyTraffic classes:Traffic class session ID: 474ACL Name: prepaid-redirect-acl, Packets = 0, Bytes = 0Traffic class session ID: 479ACL Name: 103, Packets = 19, Bytes = 760Unmatched Packets (dropped) = 0, Re-classified packets (redirected) = 0Feature: Portbundle HostkeyPortbundle IP = 10.10.100.7 Bundle Number = 147Session outbound features:Traffic classes:Traffic class session ID: 474ACL Name: prepaid-redirect-acl, Packets = 0, Bytes = 0Traffic class session ID: 479ACL Name: 103, Packets = 38, Bytes = 30996Unmatched Packets (dropped) = 0, Re-classified packets (redirected) = 0Configuration sources associated with this session:Service: prepaid-time, Active Time = 00:00:07Service: prepaid-redirect, Active Time = 00:44:05Service: PBHK, Active Time = 00:44:05Interface: Virtual-Template2, Active Time = 00:44:05The Service-Info PZS attribute defines prepaid server details to use for authorization and can include the IP address, authentication port, accounting port, and the shared key. Following is a sample profile with the Service-Info PZS attributes defined (in bold text for purpose of example):
prepaid-remote-ps Password = "servicecisco", Service-Type = OutboundSSG-Service-Info [26,9,251]= "Iprepaid-remote-ps",SSG-Service-Info [26,9,251]= "R10.40.96.12;255.255.255.255",SSG-Service-Info [26,9,251]= "MC",SSG-Service-Info [26,9,251]= "TP",SSG-Service-Info [26,9,251]= "Z",SSG-Service-Info [26,9,251]= "PZS10.30.81.46;1812;1813;"
Note With the SSG, it is possible to insert the details of a different billing server into the prepaid service profile so that the SSG could send the authorization request to this billing server instead of the one configured using the method lists in previous examples.
The Service-Info PZS attributes are not interpreted on the ISG. The functionality must be replaced by defining a new subscriber feature group for the ISG that refers to the method list where the RADIUS server group is configured. This definition will include the same information that is in the PZS Service-Info attribute string, which includes an IP address, authentication port, accounting port, and a shared key.
Bold text in the following example indicates the Cisco AV pair prepaid-config attribute that is added to the profile on the ISG:
prepaid-remote-ps Password = "servicecisco", Service-Type = OutboundSSG-Service-Info [26,9,251]= "Iprepaid-remote-ps",SSG-Service-Info [26,9,251]= "R10.40.96.12;255.255.255.255",SSG-Service-Info [26,9,251]= "MC",SSG-Service-Info [26,9,251]= "TP",SSG-Service-Info [26,9,251]= "Z",SSG-Service-Info [26,9,251]= "PZS10.30.81.46;1812;1813;"Cisco AV-Pair [26,9,1] = "ip:traffic-class=in access-group name prepaid-remote-ps-acl priority 5"Cisco AV-Pair [26,9,1] = "ip:traffic-class=out access-group name prepaid-remote-ps-acl priority 5"Cisco AV-Pair [26,9,1] = "prepaid-config=feat-name-remote-ps-example"
The following ISG commands are also added to the configuration to replace the PZS parameters. Notice how these commands use names and addresses defined in the profile.
subscriber feature prepaid feat-name-remote-ps-example
threshold time 0 secondsthreshold volume 0 bytesmethod-list author prepaid-remote-ps
method-list accounting prepaid-remote-ps
password serviceciscoaaa authorization network prepaid-remote-ps group prepaid-remote-ps-sgaaa accounting network prepaid-remote-ps start-stop group prepaid-remote-ps-sg
aaa group server radius prepaid-remote-ps-sg
server-private 10.30.81.46 auth-port 1812 acct-port 1813 key ciscoip radius source-interface Loopback0SSG Prepaid Threshold
On the SSG, a new authorization request can be sent out to the billing server before the user consumes all of the received quota from the billing server. This type of authorization is done by configuring threshold values using the following commands:
Router(config)# ssg prepaid threshold time ?
<0-6565656> Threshold time (in seconds)Router(config)# ssg prepaid threshold volume ?
<0-65535566> Threshold volume (in bytes)The values entered in these commands trigger the reauthorization request on the SSG so that if the subscriber receives a time quota value (QT) of 200 seconds and a threshold time of 30 seconds, the reauthorization request is not sent when QT is consumed, but when more than QT minus the threshold value is consumed (200-30=170 seconds). If the threshold value is higher than QT, the reauthorization happens at QT.
ISG Prepaid Threshold
Threshold values are applied on the ISG using threshold commands under the subscriber feature prepaid configuration, as shown in the following example (bold text used for purpose of example):
subscriber feature prepaid defaultthreshold time 0 secondsthreshold volume 1000 bytes
method-list author rsim-mlmethod-list accounting rsim-mlpassword serviceciscoThe ISG show subscriber session command with the uid displays the traffic class created for the prepaid service and the calculated threshold value.
Router# show subscriber session uid 297
Unique Session ID: 297Identifier: pp-tc71-user1SIP subscriber access type(s): Traffic-ClassCurrent SIP options: NoneSession Up-time: 00:00:14, Last Changed: 00:00:14AAA unique ID: 0Policy information:Context 208C308C: Handle 83000127Authentication status: unauthenPrepaid context: defaultthreshold time 0 secondsthreshold volume 1000 bytesmethod-list author rsim-mlmethod-list accounting rsim-mlpassword serviceciscoInterim accounting disabledState PREPAID_FEATURE_RUNNINGFlow idle ? NOTotal idle time 0 secondsAre we accounting for time consumed ? YESAcct start sent ? YESSession inbound features:Feature: Prepaid Volume MonitorThreshold:9000 - Quota:10000
Usage(since last update):0 - Total:0Current states: StartSession outbound features:Feature: Prepaid Volume MonitorThreshold:9000 - Quota:10000
Usage(since last update):0 - Total:0Current states: StartConfiguration sources associated with this session:Service: prepaid-volume, Active Time = 00:00:15SSG Prepaid Idle Timeout
No additional configuration is needed to apply the Prepaid Idle Timeout feature on an SSG. Prepaid idle timeout is triggered automatically whenever the billing server sends its authorization Access-Accept answer, which contains the quota value given to the subscriber for the prepaid service and the idle timeout attribute (RADIUS attribute 28).
The following log is an example of the Access-Request for quota from the SSG to the billing server (with key information highlighted in bold text):
RADIUS(00000000): Send Access-Request to 10.30.81.45:1812 id 1645/27, len 148RADIUS: authenticator CE E3 2B 78 3F CB 0E 4A - AB 1E 78 0C 57 49 C3 3ARADIUS: User-Name [1] 15 "pp-tc71-user1"
RADIUS: User-Password [2] 18 *RADIUS: Calling-Station-Id [31] 15 "pp-tc71-user1"RADIUS: Vendor, Cisco [26] 23RADIUS: ssg-account-info [250] 17 "S10.10.100.6:64"RADIUS: Vendor, Cisco [26] 29RADIUS: ssg-service-info [251] 23 "Nprepaid-vol-idletime"
RADIUS: Acct-Session-Id [44] 10 "00000032"RADIUS: Service-Type [6] 6 Framed [2]RADIUS: NAS-IP-Address [4] 6 10.10.100.6RADIUS: Event-Timestamp [55] 6 1112199077The following log is an example of the Access-Accept answer from the billing server to the authorization request sent from the SSG (key information is in bold text):
RADIUS: Received from id 1645/27 10.30.81.45:1812, Access-Accept, len 90RADIUS: authenticator C3 5D 58 AC BE BF 6C 7D - C2 1E 7A 2B AF 57 9A EERADIUS: Service-Type [6] 6 Framed [2]RADIUS: Class [25] 14RADIUS: 70 72 65 70 61 69 64 2D 74 63 37 31 [prepaid-tc71]RADIUS: Vendor, Cisco [26] 29RADIUS: ssg-service-info [251] 23 "Nprepaid-vol-idletime"
RADIUS: Vendor, Cisco [26] 15RADIUS: ssg-control-info [253] 9 "QV10000"RADIUS: Idle-Timeout [28] 6 300
The presence of the idle timer in an authorization Access-Accept answer from the billing server triggers two behaviors on the SSG:
•First is the ability to return allocated quota for the subscriber on the SSG to the billing server whenever the subscriber is idle for a time period equal to the number of seconds set in the Idle-Timeout attribute (attribute 28). In this example, if the subscriber session has not seen traffic for the prepaid service for more than 300 seconds, the SSG will signal via the Control-Info QR1 attribute that the router would like to return the quota because the service has been idle. The QV value in the Access-Request sent from the SSG to the billing server contains the amount of quota already consumed. The SSG will send out a request for quota for this service as soon as the traffic for this prepaid service is resumed.
The following log is an example of the Access-Request returning quota via QR1 from the SSG to the billing server:
RADIUS(00000000): Send Access-Request to 10.30.81.45:1812 id 1645/28, len 170RADIUS: authenticator F8 BA 2A 50 19 C4 EC 0F - 58 B6 0C DA E7 C0 A8 65RADIUS: User-Name [1] 15 "pp-tc71-user1"RADIUS: User-Password [2] 18 *RADIUS: Calling-Station-Id [31] 15 "pp-tc71-user1"RADIUS: Vendor, Cisco [26] 23RADIUS: ssg-account-info [250] 17 "S10.10.100.6:64"RADIUS: Vendor, Cisco [26] 29RADIUS: ssg-service-info [251] 23 "Nprepaid-vol-idletime"RADIUS: Vendor, Cisco [26] 11RADIUS: ssg-control-info [253] 5 "QV325"RADIUS: Vendor, Cisco [26] 11RADIUS: ssg-control-info [253] 5 "QR1"RADIUS: Acct-Session-Id [44] 10 "00000032"RADIUS: Service-Type [6] 6 Framed [2]RADIUS: NAS-IP-Address [4] 6 10.10.100.6RADIUS: Event-Timestamp [55] 6 1112199377The following log is an example of the Access-Accept answer from the billing server in response to the Access-Request to return quota from the SSG:
RADIUS: Received from id 1645/28 10.30.81.45:1812, Access-Accept, len 86RADIUS: authenticator 18 60 18 5A 20 2A 76 25 - D8 28 F4 B7 82 E4 4D 8BRADIUS: Service-Type [6] 6 Framed [2]RADIUS: Class [25] 14RADIUS: 70 72 65 70 61 69 64 2D 74 63 37 31 [prepaid-tc71]RADIUS: Vendor, Cisco [26] 29RADIUS: ssg-service-info [251] 23 "Nprepaid-vol-idletime"RADIUS: Vendor, Cisco [26] 11RADIUS: ssg-control-info [253] 5 "QV0"RADIUS: Idle-Timeout [28] 6 0
Note In the SSG, the ability to return quota via the QR1 attribute when no traffic is sent for a period longer than the idle timeout value is possible only for volume-based prepaid service, and not for time-based prepaid service.
•The second behavior for idle timeout allows subscribers to replenish their quota within a specific period of time so that service is continued; otherwise, service is disconnected. The SSG sends a reauthorization request to the billing server after a period of time equal to the idle-timeout value present in the authorization request from the billing server.
The following log is an example of the Access-Request for quota from the SSG to the billing server (with key information highlighted in bold text):
Mar 30 17:13:45.421: RADIUS(00000000): Send Access-Request to 10.30.81.45:1812 id 1645/33, len 163RADIUS: authenticator EA 52 C5 C5 20 62 E1 D8 - 63 97 51 FA 39 28 9B F8RADIUS: User-Name [1] 15 "pp-tc71-user1"
RADIUS: User-Password [2] 18 *RADIUS: Calling-Station-Id [31] 15 "pp-tc71-user1"RADIUS: Vendor, Cisco [26] 23RADIUS: ssg-account-info [250] 17 "S10.10.100.6:64"RADIUS: Vendor, Cisco [26] 29RADIUS: ssg-service-info [251] 23 "Nprepaid-vol-idletime"
RADIUS: Vendor, Cisco [26] 15RADIUS: ssg-control-info [253] 9 "QV20421"
RADIUS: Acct-Session-Id [44] 10 "00000043"RADIUS: Service-Type [6] 6 Framed [2]RADIUS: NAS-IP-Address [4] 6 10.10.100.6RADIUS: Event-Timestamp [55] 6 1112202825The following log is an example of the Access-Accept answer from the billing server that indicates to the SSG that the subscriber has no quota remaining (QV is set to 0). Because of the presence of the Idle-Timeout attribute, the SSG is prevented from disconnecting the prepaid service, and will wait to do so until a period of time equal to the idle-timeout value (300 seconds). (Key information is highlighted in bold text for purpose of example.)
Mar 30 17:13:45.429: RADIUS: Received from id 1645/33 10.30.81.45:1812, Access-Accept, len 86
RADIUS: authenticator 2B 20 34 7B 77 70 4A AA - DC 90 A4 02 35 31 48 F0RADIUS: Service-Type [6] 6 Framed [2]RADIUS: Class [25] 14RADIUS: 70 72 65 70 61 69 64 2D 74 63 37 31 [prepaid-tc71]RADIUS: Vendor, Cisco [26] 29RADIUS: ssg-service-info [251] 23 "Nprepaid-vol-idletime"
RADIUS: Vendor, Cisco [26] 11RADIUS: ssg-control-info [253] 5 "QV0"
RADIUS: Idle-Timeout [28] 6 300
Exactly 300 seconds after the billing server informed the SSG that there is no quota left for the subscriber, the SSG will check the billing server again to determine whether the quota was replenished by the subscriber. If QV is still set to 0, the prepaid service will be disconnected. The time stamp in the following example (in bold text) indicates 300 seconds have passed:
Mar 30 17:18:45.439: RADIUS(00000000): Send Access-Request to 10.30.81.45:1812 id 1645/34, len 163
RADIUS: authenticator 6A 86 7E AD BE DA DE E3 - BF 45 32 25 47 D8 AE 17RADIUS: User-Name [1] 15 "pp-tc71-user1"RADIUS: User-Password [2] 18 *RADIUS: Calling-Station-Id [31] 15 "pp-tc71-user1"RADIUS: Vendor, Cisco [26] 23RADIUS: ssg-account-info [250] 17 "S10.10.100.6:64"RADIUS: Vendor, Cisco [26] 29RADIUS: ssg-service-info [251] 23 "Nprepaid-vol-idletime"RADIUS: Vendor, Cisco [26] 15RADIUS: ssg-control-info [253] 9 "QV20461"RADIUS: Acct-Session-Id [44] 10 "00000043"RADIUS: Service-Type [6] 6 Framed [2]RADIUS: NAS-IP-Address [4] 6 10.10.100.6RADIUS: Event-Timestamp [55] 6 1112203125The following example shows that the subscriber did not replenish quota within the specified idle-timeout period, because the billing server still responds with QV set to 0. The SSG will, therefore, disconnect prepaid service.
Mar 30 17:18:45.447: RADIUS: Received from id 1645/34 10.30.81.45:1812, Access-Accept, len 86RADIUS: authenticator 5D C9 C3 AB 44 3E 19 26 - 3A 7C 1A 24 67 04 A5 4ARADIUS: Service-Type [6] 6 Framed [2]RADIUS: Class [25] 14RADIUS: 70 72 65 70 61 69 64 2D 74 63 37 31 [prepaid-tc71]RADIUS: Vendor, Cisco [26] 29RADIUS: ssg-service-info [251] 23 "Nprepaid-vol-idletime"RADIUS: Vendor, Cisco [26] 11RADIUS: ssg-control-info [253] 5 "QV0"
Note The second behavior of SSG—where an Idle-Timeout attribute is sent from the billing server in the authorization accept—applies to both time- and volume-based prepaid services.
ISG Prepaid Idle Timeout
The use of the Idle-Timeout attribute in the authorization accept request from the billing server works the same on the ISG as on the SSG. No additional configuration is needed to enable (trigger) the idle-timeout functionality. The idle timeout is controlled from the billing server itself, whether or not this functionality is triggered on the ISG. This control is enforced when the RADIUS Idle-Timeout attribute (attribute 28) is sent in the RADIUS response message for the remaining quota. The following log is an example of the Access-Request for quota from the ISG to the billing server:
RADIUS(00000109): Send Access-Request to 10.30.81.45:1812 id 1645/178, len 155RADIUS: authenticator 6C 3A 69 DF 30 F7 9C 4F - FB 7F 02 17 B1 3A 9F 4ARADIUS: User-Name [1] 15 "pp-tc71-user1"RADIUS: User-Password [2] 18 *RADIUS: Vendor, Cisco [26] 29RADIUS: ssg-service-info [251] 23 "Nprepaid-vol-idletime"RADIUS: Framed-Protocol [7] 6 PPP [1]RADIUS: NAS-Port-Type [61] 6 Virtual [5]RADIUS: NAS-Port [5] 6 0RADIUS: NAS-Port-Id [87] 13 "3/0/0/0.201"RADIUS: Class [25] 14RADIUS: 70 72 65 70 61 69 64 2D 74 63 37 31 [prepaid-tc71]RADIUS: Service-Type [6] 6 Framed [2]RADIUS: NAS-IP-Address [4] 6 10.10.100.7RADIUS: Acct-Session-Id [44] 10 "00000163"RADIUS: Event-Timestamp [55] 6 1112243253The following log is an example of the Access-Accept answer from the billing server to the authorization request sent from the ISG (see bold text for key information):
RADIUS: Received from id 1645/178 10.30.81.45:1812, Access-Accept, len 90RADIUS: authenticator 6A 6B 0A E7 2C FE B4 B0 - B2 D0 44 ED 4B 5F 53 69RADIUS: Service-Type [6] 6 Framed [2]RADIUS: Class [25] 14RADIUS: 70 72 65 70 61 69 64 2D 74 63 37 31 [prepaid-tc71]RADIUS: Vendor, Cisco [26] 29RADIUS: ssg-service-info [251] 23 "Nprepaid-vol-idletime"RADIUS: Vendor, Cisco [26] 15RADIUS: ssg-control-info [253] 9 "QV10000"
RADIUS: Idle-Timeout [28] 6 300
To display the traffic class created for the prepaid service and the calculated threshold value, use the ISG show subscriber session command with the session uid. Following is sample output with prepaid feature information indicated in bold text:
Router# show subscriber session uid 361
Unique Session ID: 361
Identifier: pp-tc71-user1
SIP subscriber access type(s): Traffic-Class
Current SIP options: NoneSession Up-time: 00:01:48, Last Changed: 00:01:48AAA unique ID: 0Policy information:Context 208C2C78: Handle A30001EBAuthentication status: unauthenPrepaid context: defaultthreshold time 0 secondsthreshold volume 1000 bytesmethod-list author rsim-mlmethod-list accounting rsim-mlpassword serviceciscoInterim accounting disabledState PREPAID_FEATURE_RUNNING
Flow idle ? NO
Total idle time 0 secondsAre we accounting for time consumed ? YESAcct start sent ? YESSession inbound features:Feature: Prepaid Idle Timeout
Timeout configuration: 300 (seconds)
Feature: Prepaid Volume MonitorThreshold:9000 - Quota:10000Usage(since last update):4198 - Total:4198Current states: StartSession outbound features:Feature: Prepaid Idle Timeout
Timeout configuration: 300 (seconds)
Feature: Prepaid Volume MonitorThreshold:9000 - Quota:10000Usage(since last update):4198 - Total:4198Current states: StartConfiguration sources associated with this session:Service: prepaid-vol-idletime, Active Time = 00:01:49
Both behaviors on the SSG for the idle-timeout function (returning and replenishing quota) are also present on the ISG.
The ISG will return the received quota to the billing server if the session was idle for a period longer than the value of the Idle-Timeout attribute (attribute 28), and when the subscriber is not sending IP traffic over the flow of the prepaid service. To signal to the billing server that the ISG wants to return quota, the ISG uses the Control-Info QR1 attribute, the same as for the SSG. Whenever the traffic over the prepaid service flows, the ISG will ask the billing server for quota again.
The following log is an example of the Access-Request returning quota via attribute QR1 from the ISG to the billing server. The prepaid service flow has been idle for more than 300 seconds.
RADIUS(00000109): Send Access-Request to 10.30.81.45:1812 id 1645/179, len 180RADIUS: authenticator 71 6C C1 2C 32 13 CC 1D - 44 D0 83 B0 5D 9A 5E 9FRADIUS: User-Name [1] 15 "pp-tc71-user1"RADIUS: User-Password [2] 18 *RADIUS: Vendor, Cisco [26] 29RADIUS: ssg-service-info [251] 23 "Nprepaid-vol-idletime"RADIUS: Framed-Protocol [7] 6 PPP [1]RADIUS: Vendor, Cisco [26] 14RADIUS: ssg-control-info [253] 8 "QV4198"RADIUS: Vendor, Cisco [26] 11RADIUS: ssg-control-info [253] 5 "QR1"RADIUS: NAS-Port-Type [61] 6 Virtual [5]RADIUS: NAS-Port [5] 6 0RADIUS: NAS-Port-Id [87] 13 "3/0/0/0.201"RADIUS: Class [25] 14RADIUS: 70 72 65 70 61 69 64 2D 74 63 37 31 [prepaid-tc71]RADIUS: Service-Type [6] 6 Framed [2]RADIUS: NAS-IP-Address [4] 6 10.10.100.7RADIUS: Acct-Session-Id [44] 10 "00000163"RADIUS: Event-Timestamp [55] 6 1112243633The following log is an example of the Access-Accept answer from the billing server in response to the Access-Request to return quota sent by the ISG:
RADIUS: Received from id 1645/179 10.30.81.45:1812, Access-Accept, len 86RADIUS: authenticator 41 91 09 8B 9E E5 8B A1 - 0B AB 92 B2 F7 83 E3 A1RADIUS: Service-Type [6] 6 Framed [2]RADIUS: Class [25] 14RADIUS: 70 72 65 70 61 69 64 2D 74 63 37 31 [prepaid-tc71]RADIUS: Vendor, Cisco [26] 29RADIUS: ssg-service-info [251] 23 "Nprepaid-vol-idletime"RADIUS: Vendor, Cisco [26] 11RADIUS: ssg-control-info [253] 5 "QV0"RADIUS: Idle-Timeout [28] 6 0To verify that the flow is idle, use the ISG show subscriber session command with the session uid. Following is sample output with key prepaid feature information indicated by bold text:
Router# show subscriber session uid 361
Unique Session ID: 361
Identifier: pp-tc71-user1
SIP subscriber access type(s): Traffic-Class
Current SIP options: NoneSession Up-time: 00:06:46, Last Changed: 00:00:26AAA unique ID: 0Policy information:Context 208C2C78: Handle A30001EBAuthentication status: unauthenPrepaid context: defaultthreshold time 0 secondsthreshold volume 1000 bytesmethod-list author rsim-mlmethod-list accounting rsim-mlpassword serviceciscoInterim accounting disabledState PREPAID_FEATURE_RUNNING
Flow idle ? YES
Total idle time 300 secondsAre we accounting for time consumed ? NOAcct start sent ? YESSession inbound features:Feature: Prepaid Idle TimeoutTimeout configuration: 300 (seconds)Idle Timer is not runningFeature: Prepaid Volume MonitorThreshold:0 - Quota:0
Usage(since last update):0 - Total:4198
Current states: StartSession outbound features:Feature: Prepaid Idle TimeoutTimeout configuration: 300 (seconds)Idle Timer is not runningFeature: Prepaid Volume MonitorThreshold:0 - Quota:0
Usage(since last update):0 - Total:4198
Current states: StartConfiguration sources associated with this session:Service: prepaid-vol-idletime, Active Time = 00:06:48
Note The ISG does not differ between time- and quota-based services. For both services, the ISG will return quotas if the service is idle for a period longer than the value set for the Idle-Timeout attribute (attribute 28). The SSG does not allow this behavior for time-based services.
The same Idle-Timeout attribute is used for both the SSG and ISG to allow the subscriber to replenish quota within a period of time equal to the idle-timeout value set, assuming all quota has been consumed and the prepaid service has not been disconnected. When the ISG receives an authorization response with an Idle-Timeout attribute from the billing server stating that the subscriber has consumed all available quota, the ISG will start to drop all traffic belonging to the service (or redirect the traffic if configured; see the "ISG Quota Refill Redirection" section for more information), but will not clear the subscriber from the connected prepaid service. After a period of time equal to the idle-timeout value, the ISG will send a new authorization request to the billing server, to verify whether the subscriber replenished his quota during this time period.
The following log is an example of the Access-Request for quota sent from the ISG to the billing server. Bold text is used for purpose of example.
Mar 31 04:36:24.787: RADIUS(00000109): Send Access-Request to 10.30.81.45:1812 id 1645/182, len 170
RADIUS: authenticator DC 82 92 A8 2A A6 EB 4E - 0C 55 31 7A 30 28 6E 69RADIUS: User-Name [1] 15 "pp-tc71-user1"
RADIUS: User-Password [2] 18 *RADIUS: Vendor, Cisco [26] 29RADIUS: ssg-service-info [251] 23 "Nprepaid-vol-idletime"
RADIUS: Framed-Protocol [7] 6 PPP [1]RADIUS: Vendor, Cisco [26] 15RADIUS: ssg-control-info [253] 9 "QV21094"
RADIUS: NAS-Port-Type [61] 6 Virtual [5]RADIUS: NAS-Port [5] 6 0RADIUS: NAS-Port-Id [87] 13 "3/0/0/0.201"RADIUS: Class [25] 14RADIUS: 70 72 65 70 61 69 64 2D 74 63 37 31 [prepaid-tc71]RADIUS: Service-Type [6] 6 Framed [2]RADIUS: NAS-IP-Address [4] 6 10.10.100.7RADIUS: Acct-Session-Id [44] 10 "00000163"RADIUS: Event-Timestamp [55] 6 1112243784The following log is an example of the Access-Accept answer from the billing server indicating to the ISG that the subscriber has no quota remaining (QV is set to 0). Because the Idle-Timeout attribute is present, the ISG will not disconnect the prepaid service until a period of time equal to the configured timeout value (300 seconds) has passed. Bold text is used for purpose of example.
Mar 31 04:36:24.795: RADIUS: Received from id 1645/182 10.30.81.45:1812, Access-Accept, len 86
RADIUS: authenticator F3 93 6A 8B 18 63 D1 46 - 73 07 DE 7F 46 12 79 B5RADIUS: Service-Type [6] 6 Framed [2]RADIUS: Class [25] 14RADIUS: 70 72 65 70 61 69 64 2D 74 63 37 31 [prepaid-tc71]RADIUS: Vendor, Cisco [26] 29RADIUS: ssg-service-info [251] 23 "Nprepaid-vol-idletime"RADIUS: Vendor, Cisco [26] 11RADIUS: ssg-control-info [253] 5 "QV0"
RADIUS: Idle-Timeout [28] 6 300
To verify that the state has changed, use the ISG show subscriber session command with the session uid. Following is sample output with the prepaid service traffic class information indicated by bold text:
Router# show subscriber session uid 361
Unique Session ID: 361Identifier: pp-tc71-user1
SIP subscriber access type(s): Traffic-Class
Current SIP options: NoneSession Up-time: 00:09:20, Last Changed: 00:00:29AAA unique ID: 0Policy information:Context 208C2C78: Handle A30001EBAuthentication status: unauthenPrepaid context: defaultthreshold time 0 secondsthreshold volume 1000 bytesmethod-list author rsim-mlmethod-list accounting rsim-mlpassword serviceciscoInterim accounting disabledState CREDIT_EXHAUST_TIMER_RUNNING
Flow idle ? NOTotal idle time 300 secondsAre we accounting for time consumed ? NOAcct start sent ? YESSession inbound features:Feature: Prepaid Idle Timeout
Timeout configuration: 300 (seconds)
Feature: Prepaid Volume Monitor
Threshold:4294967295 - Quota:4294967295
Usage(since last update):0 - Total:21094
Current states: StartSession outbound features:Feature: Prepaid Idle Timeout
Timeout configuration: 300 (seconds)
Feature: Prepaid Volume Monitor
Threshold:4294967295 - Quota:4294967295
Usage(since last update):0 - Total:21094
Current states: StartConfiguration sources associated with this session:Service: prepaid-vol-idletime, Active Time = 00:09:22Exactly 300 seconds after the billing server informed the ISG that there is no quota left for the subscriber, the ISG will check the billing server again to determine whether the quota was replenished by the subscriber. If QV is still set to 0, the prepaid service will be disconnected. The time stamp in the following example (in bold text for purposes of example) indicates 300 seconds have passed:
Mar 31 04:41:24.819: RADIUS(00000109): Send Access-Request to 10.30.81.45:1812 id 1645/183, len 170
RADIUS: authenticator 1D D7 77 5F FE 41 84 5B - 4F 78 F0 67 FC 8F A1 20Mar 31 04:41:24.819: RADIUS: User-Name [1] 15 "pp-tc71-user1"Mar 31 04:41:24.819: RADIUS: User-Password [2] 18 *Mar 31 04:41:24.819: RADIUS: Vendor, Cisco [26] 29Mar 31 04:41:24.819: RADIUS: ssg-service-info [251] 23 "Nprepaid-vol-idletime"Mar 31 04:41:24.819: RADIUS: Framed-Protocol [7] 6 PPP [1]Mar 31 04:41:24.819: RADIUS: Vendor, Cisco [26] 15Mar 31 04:41:24.819: RADIUS: ssg-control-info [253] 9 "QV21094"Mar 31 04:41:24.819: RADIUS: NAS-Port-Type [61] 6 Virtual [5]Mar 31 04:41:24.819: RADIUS: NAS-Port [5] 6 0Mar 31 04:41:24.819: RADIUS: NAS-Port-Id [87] 13 "3/0/0/0.201"Mar 31 04:41:24.819: RADIUS: Class [25] 14Mar 31 04:41:24.819: RADIUS: 70 72 65 70 61 69 64 2D 74 63 37 31 [prepaid-tc71]Mar 31 04:41:24.819: RADIUS: Service-Type [6] 6 Framed [2]Mar 31 04:41:24.819: RADIUS: NAS-IP-Address [4] 6 10.10.100.7Mar 31 04:41:24.819: RADIUS: Acct-Session-Id [44] 10 "00000163"Mar 31 04:41:24.819: RADIUS: Event-Timestamp [55] 6 1112244084The following example shows that the subscriber did not replenish quota within the specified idle-timeout period, because the billing server still responds with QV set to 0. The ISG will, therefore, disconnect prepaid service.
Mar 31 04:41:24.831: RADIUS: Received from id 1645/183 10.30.81.45:1812, Access-Accept, len 86Mar 31 04:41:24.831: RADIUS: authenticator 85 13 E2 91 17 41 5C 21 - 2C BE 41 4E 78 9B 37 82Mar 31 04:41:24.831: RADIUS: Service-Type [6] 6 Framed [2]Mar 31 04:41:24.831: RADIUS: Class [25] 14Mar 31 04:41:24.831: RADIUS: 70 72 65 70 61 69 64 2D 74 63 37 31 [prepaid-tc71]Mar 31 04:41:24.831: RADIUS: Vendor, Cisco [26] 29Mar 31 04:41:24.831: RADIUS: ssg-service-info [251] 23 "Nprepaid-vol-idletime"Mar 31 04:41:24.831: RADIUS: Vendor, Cisco [26] 11Mar 31 04:41:24.831: RADIUS: ssg-control-info [253] 5 "QV0"SSG Dual Quota Prepaid Service
The service authorization response can contain both time and volume quota types. That is, the authorization response can contain both QT and QV attributes. When the SSG receives a service authorization response, it starts both a quota timer and keeps monitoring the connection based on the volume. When either the volume or quota values run out, SSG does a reauthorization. The subsequent authorization request will contain the usage of both quota types in its response. Note that both volume and time quota parameters must be nonzero. The functionality can interwork with the prepaid idle-timeout functionality and volume threshold.
Table 5 shows the different set of actions that the SSG takes when the billing server sends a specific set of values in its authorization response.
ISG Dual Quota Prepaid Service
No special configuration is required on the ISG to convert an SSG prepaid service with dual quota, apart from the conversion of the prepaid service profile on the RADIUS server as described in the "ISG Basic Prepaid and Postpaid Time- and Volume-Based Services" section. The dual quota behavior is automatically triggered as soon as the billing server sends an authorization to the ISG containing a QT and QV value within a Control-Info attribute. Following is an example of an authorization request for quota sent from the ISG to the billing server. The billing server sends the time and volume quota values in its authorization response; see bold text in the following example:
RADIUS(0000013C): Send Access-Request to 10.30.81.45:1812 id 1645/114, len 139RADIUS: authenticator 11 15 06 AC F2 9A 8F 6D - AE 27 E9 61 02 C7 10 D3RADIUS: User-Name [1] 15 "pp-tc71-user1"
RADIUS: User-Password [2] 18 *RADIUS: Vendor, Cisco [26] 27RADIUS: ssg-service-info [251] 21 "Nprepaid-dual-quota"
RADIUS: Framed-Protocol [7] 6 PPP [1]RADIUS: NAS-Port-Type [61] 6 Virtual [5]RADIUS: NAS-Port [5] 6 0RADIUS: NAS-Port-Id [87] 13 "3/0/0/0.201"RADIUS: Service-Type [6] 6 Framed [2]RADIUS: NAS-IP-Address [4] 6 10.10.100.7RADIUS: Acct-Session-Id [44] 10 "000002BD"RADIUS: Event-Timestamp [55] 6 1113401864RADIUS: Received from id 1645/114 10.30.81.45:1812, Access-Accept, len 87RADIUS: authenticator 1D E7 13 57 7F 55 E3 57 - D5 44 92 B6 5E 94 2E EERADIUS: Framed-Protocol [7] 6 PPP [1]RADIUS: Vendor, Cisco [26] 27RADIUS: ssg-service-info [251] 21 "Nprepaid-dual-quota"RADIUS: Vendor, Cisco [26] 13RADIUS: ssg-control-info [253] 7 "QT180"
RADIUS: Vendor, Cisco [26] 15RADIUS: ssg-control-info [253] 9 "QV10000"
RADIUS: Idle-Timeout [28] 6 120The presence of both quotas in the authorization response from the billing server will trigger the time and volume monitor features on the traffic class created on the ISG for the prepaid service.
Use the unique session ID created for the traffic class of the prepaid service with the show subscriber session command to verify the presence of both the time monitor and volume monitor feature on the traffic class. The following example reveals that both quotas were received from the billing server for this prepaid service (see bold text):
Router# show subscriber session uid 486
Unique Session ID: 486
Identifier: pp-tc71-user1
SIP subscriber access type(s): Traffic-Class
Current SIP options: NoneSession Up-time: 00:00:17, Last Changed: 00:00:17AAA unique ID: 0Policy information:Context 2078EB88: Handle D000035BAuthentication status: unauthenPrepaid context: defaultthreshold time 0 secondsthreshold volume 0 bytesmethod-list author rsim-mlmethod-list accounting rsim-mlpassword serviceciscoInterim accounting disabledState PREPAID_FEATURE_RUNNINGFlow idle ? NOTotal idle time 0 secondsAre we accounting for time consumed ? YESAcct start sent ? YESSession inbound features:Feature: Prepaid Idle TimeoutTimeout configuration: 120 (seconds)Feature: Prepaid Volume Monitor
Threshold:10000 - Quota:10000
Usage(since last update):0 - Total:0Current states: StartSession outbound features:Feature: Prepaid Idle TimeoutTimeout configuration: 120 (seconds)Feature: Prepaid Volume Monitor
Threshold:10000 - Quota:10000
Usage(since last update):0 - Total:0Current states: StartNon-datapath features:
Feature: Time Monitor
Threshold: 180 (seconds) - Quota: 180 (seconds)
Session time: 17 (seconds)Configuration sources associated with this session:Service: prepaid-dual-quota, Active Time = 00:00:18The QT value does not work in the same way on the ISG as on the SSG. On the ISG, the value of the QT attribute can be interpreted one of two ways depending upon the presence of the QV attribute, as follows:
•If the QV attribute value is not present in the authorization response and only the QT attribute value is received, the QT value is considered to be a form of quota on the ISG. If the subscriber runs out of this quota, the ISG disconnects the service or blocks and redirects traffic if the idle-timeout value is also present.
•In the dual quota format, the QT attribute value can become a monitor timer: The ISG will check the billing server for quota for the period of time since the last authorization response was received. This period of time is equal to the QT value. If the billing server sends back a QT value equal to 0 and a QV value greater than 0, the monitor timer is turned off on the ISG. The ISG will no longer contact the billing server at the time indicated by the QT value, but rather on other events such as when the idle-timeout value is reached or when the volume is consumed.
The following log shows that the billing server is sending a QT value equal to 0 and a QV value greater than 0 to the ISG in its authorization response (see bold text). In this example, the ISG will not disconnect service (the policy information in the previous show subscriber session command output of the traffic class for the prepaid service indicated that the prepaid function was still running). The time monitor will be stopped, and reauthorization at the time specified by the value of the QT attribute will not occur on the ISG. Entering the show subscriber session command with the uid of the traffic class for the prepaid service again indicates that the time monitor feature is no longer running (see bold text).
RADIUS: Received from id 1645/124 10.30.81.45:1812, Access-Accept, len 85RADIUS: authenticator EA DC 81 8D 41 A7 F1 56 - AE 29 AA 51 D8 61 9A 0ARADIUS: Framed-Protocol [7] 6 PPP [1]RADIUS: Vendor, Cisco [26] 27RADIUS: ssg-service-info [251] 21 "Nprepaid-dual-quota"RADIUS: Vendor, Cisco [26] 11RADIUS: ssg-control-info [253] 5 "QT0"
RADIUS: Vendor, Cisco [26] 15RADIUS: ssg-control-info [253] 9 "QV10000"
RADIUS: Idle-Timeout [28] 6 120RADIUS(0000013F): Received from id 1645/124Router# show subscriber session uid 489
Unique Session ID: 489
Identifier: pp-tc71-user1
SIP subscriber access type(s): Traffic-Class
Current SIP options: NoneSession Up-time: 00:09:45, Last Changed: 00:00:04AAA unique ID: 0Policy information:Context 2078EB88: Handle 3A000364Authentication status: unauthenPrepaid context: defaultthreshold time 0 secondsthreshold volume 0 bytesmethod-list author rsim-mlmethod-list accounting rsim-mlpassword serviceciscoInterim accounting disabledState PREPAID_FEATURE_RUNNING
Flow idle ? NOTotal idle time 0 secondsAre we accounting for time consumed ? YESAcct start sent ? YESSession inbound features:Feature: Prepaid Idle TimeoutTimeout configuration: 120 (seconds)Feature: Prepaid Volume MonitorThreshold:10000 - Quota:10000Usage(since last update):0 - Total:5610Current states: StartSession outbound features:Feature: Prepaid Idle TimeoutTimeout configuration: 120 (seconds)Feature: Prepaid Volume MonitorThreshold:10000 - Quota:10000Usage(since last update):0 - Total:5610Current states: StartNon-datapath features:
Feature: Time Monitor
Threshold: 40 (seconds) - Quota: 40 (seconds)Session time: 586 (seconds)Monitor Timer is not running
Configuration sources associated with this session:Service: prepaid-dual-quota, Active Time = 00:09:46Because the QT value behaves differently on the ISG, the actions that the ISG takes upon receiving the authorization answer is slightly different on the ISG compared to the SSG. But as on the SSG, the dual quota functionality on the ISG can still be deployed with other specific prepaid functionality such as prepaid idle timeout and volume threshold.
Table 6 shows the different set of actions that the ISG can take when the billing server sends a specific set of values in its authorization response together with an idle-timeout value.
Table 6 ISG Dual Quota Prepaid Service Attribute Values and Actions
QT QV Idle Timeout ISG Action0
0
0
ISG opens the traffic class session. Reauthorization occurs when user traffic starts. This all-zero combination should also be noted as the response from the billing server to a quota return authorization request from the ISG using the QR1 attribute. See the "SSG Prepaid Idle Timeout" section for more information.
>0
>0
0
ISG opens the traffic class session. Reauthorization occurs when QT or QV is consumed.
>0
0
0
ISG opens the traffic class session. Reauthorization occurs when QT is consumed or when user traffic starts.
—
>0
>0
ISG opens the traffic class session. Reauthorization occurs when QV is consumed, or no user traffic starts for a time interval equal to that set for the idle timeout.
>0
>0
>0
ISG opens the traffic class session. Reauthorization occurs when QT is consumed, or QV is consumed, or no user traffic comes in for a time interval equal to that set for the idle timeout.
—
0
>0
ISG opens the traffic class session, but blocks user traffic (drops or redirects it). Reauthorization occurs after a time interval equal to that set for the idle timeout.
0
—
>0
ISG opens the traffic class session, but blocks user traffic (drops or redirects it). Reauthorization occurs after a time interval equal to that set for the idle timeout.
0
0
>0
ISG opens the traffic class session, but blocks user traffic (drops or redirects it). Reauthorization occurs after a time interval equal to that set for the idle timeout.
>0
0
>0
ISG opens the traffic class session, but blocks user traffic (drops or redirects it). Reauthorization occurs when QT is consumed, or after a time interval equal to that set for the idle timeout.
SSG Quota Refill Redirection
Quota refill redirection is applied with prepaid idle timeout functionality on both the SSG and ISG. The idle timer is used to send the reauthorization request to the billing server for a time equal to the value of the idle timeout attribute after the entire quota for the subscriber on the billing server is consumed.
On the SSG, it is possible to redirect all the traffic for a certain prepaid service as soon as the subscriber consumes the entire quota available for the account on the billing server (an event where the QV or QT attribute is set to 0). The service remains up but all subscriber traffic destined for this prepaid service is redirected to a portal server group. This redirection is set up on the SSG using the following commands:
ssg tcp-redirectserver-group prepaid-redirectserver 10.30.81.22 8097redirect prepaid-user to prepaid-redirectOn the SSG service profile, there were no additional settings to be inserted; the following example shows the complete profile:
pp-quota-refill-vol Password = "servicecisco", Service-Type = OutboundSSG-Service-Info [26,9,251]= "Ipp-quota-refill-vol",SSG-Service-Info [26,9,251]= "R10.40.96.5;255.255.255.255",SSG-Service-Info [26,9,251]= "MC",SSG-Service-Info [26,9,251]= "TP",SSG-Service-Info [26,9,251]= "Z",ISG Quota Refill Redirection
To enable quota refill redirection functionality on the ISG, you configure a specific event called credit-exhausted under the policy manager, and apply this event under the L4 Redirect feature.
You must first convert the SSG service profile so it is interpreted on the ISG as a prepaid service. A traffic class is also configured to replace the Service-Info R attribute and complete the prepaid functionality on the ISG.
Note Prioritization must be inserted into the traffic class, indicated by an asterisk (*) in the following example profile, to make the redirection work. Prioritization must be configured such that the traffic class used by the L4 redirection service will have a higher priority than the traffic class created for the prepaid service.
The following example converts the previous SSG service pp-quota-refill-vol profile to an ISG profile. Bold text indicates the prepaid and traffic class Cisco AV pair attributes added for the ISG:
pp-quota-refill-vol Password = "servicecisco", Service-Type = OutboundSSG-Service-Info [26,9,251]= "Iprepaid-time",SSG-Service-Info [26,9,251]= "R10.40.96.5;255.255.255.255",SSG-Service-Info [26,9,251]= "MC",SSG-Service-Info [26,9,251]= "TP",SSG-Service-Info [26,9,251]= "Z",Cisco AV-Pair [26,9,1] = "prepaid-config=default",
Cisco AV-Pair [26,9,1] = "ip:traffic-class=in access-group name pp-quota-refill-vol priority 5", (*)
Cisco AV-Pair [26,9,1] = "ip:traffic-class=out access-group name pp-quota-refill-vol priority 5 "(*)
On the ISG, the extended ACL named pp-quota-refill-vol must be inserted into the subscriber prepaid feature configuration. (For the subscriber prepaid feature configuration, see the previous example). The ACL needs to match the value of the Service-Info R attribute. The following example shows the commands used for this configuration:
ip access-list extended pp-quota-refill-volpermit ip any host 10.40.96.5permit ip host 10.40.96.5 anyThis completes migration of the prepaid service only. The redirection capability now must be introduced into the ISG configuration. The following example shows the commands to configure redirection. Notice how these commands use names and addresses defined in the profile.
policy-map type control <control policy-map used by subscriber>class type control prepaid-vol-redirect event credit-exhausted
1 service-policy type service name pp-redict-refill-vol /*name of service policy map
policy-map type service pp-redict-refill-vol /*name of service policy map
class type traffic pp-redirect-refill-vol-tc /*name of service policy map
redirect to ip 10.30.81.22 port 8097
class-map type traffic match-any pp-redirect-refill-vol-tc /*name of service policy map
match access-group input name pp-redirect-refill-vol /*name of ACL for traffic class
match access-group output name pp-redirect-refill-vol
class-map type control match-all prepaid-vol-redirect
match service-name pp-quota-refill-vol
ip access-list extended pp-redirect-refill-vol /*name of ACL for traffic class
permit ip any host 10.40.96.5permit ip host 10.40.96.5 any
Note The presence of a conditional control statement in the credit-exhaust event under the control policy map used by the subscriber indicates the extended functionality available in the ISG compared to SSG. In the SSG, it is not possible to control what prepaid service is redirected. The ISG allows more control by building a conditional statement into the policy map that defines that actions under which the credit-exhaust event should be executed when this event is triggered from the service named pp-quota-refill-vol. The credit-exhaust event corresponds to when a prepaid authorization accept request from the billing server is set to zero for one of the available time or volume quotas. The condition is created using a control class map named prepaid-vol-redirect.
Under the credit-exhaust event, an action will trigger a service policy map named pp-redirect-refill-vol. This service is a traffic class that will insert a redirection rule into all the traffic matching the ACL named pp-redirect-refill-vol. The traffic class itself has a priority of 1, which is the highest. No number specified with a class type traffic command by default sets priority to 1. In this example, the priority will therefore be preferred over the traffic class for the prepaid service, which has priority set to 5.
Note Do not reuse the ACL used for the prepaid service traffic class. Applying different traffic classes with the same ACL name is not allowed in the policy manager. You will see the following message if you try this:
Mar 30 15:08:49.883: TC[uid:343]: Another service installed with same ACL, aborting feature installationIf you need to use the same ACL, create a new IP access list name with the same ACL configuration parameters that you used in the ACL for the prepaid service (see the previous example).
To verify your redirection configuration, check the subscriber session uid when the ACL counters are increased, and as soon as the credit-exhaust event has happened and the redirection is applied. Following are examples that display activity before and after the credit-exhaust event, with key information in bold text.
Before the credit-exhaust event, pp-quota-refill-vol class captures all traffic, and the credit-exhaust event occurs because the total quota is consumed. The total quota for the subscriber in this example was set to 20000 bytes. As soon as the usage counter is updated in the prepaid service, the credit-exhaust event will be triggered.
Router# show sss session uid 349 | i ACL
ACL Name: pp-quota-refill-vol, Packets = 102, Bytes = 13761
ACL Name: pp-quota-refill-vol, Packets = 85, Bytes = 10149
After the credit-exhaust event, the L4 redirection traffic class is applied. If the quota refill redirection class is configured correctly, the counters on the ACL for the L4 redirection traffic class should increase. The counters on the traffic class for the prepaid service should remain the same.
Router# show sss session uid 349 | i ACL
ACL Name: pp-quota-refill-vol, Packets = 102, Bytes = 13761ACL Name: pp-redirect-refill-vol, Packets = 4, Bytes = 184
ACL Name: pp-quota-refill-vol, Packets = 85, Bytes = 10149ACL Name: pp-redirect-refill-vol, Packets = 8, Bytes = 257
The following example shows how to verify what state the prepaid feature is in by checking the session uid for the traffic class created for the prepaid service:
Router# show subscriber session uid 353
Unique Session ID: 353
Identifier: pp-tc71-user1SIP subscriber access type(s): Traffic-ClassCurrent SIP options: NoneSession Up-time: 00:18:03, Last Changed: 00:01:48AAA unique ID: 0Policy information:Context 208C2C78: Handle 900001CFAuthentication status: unauthenPrepaid context: defaultthreshold time 0 secondsthreshold volume 1000 bytesmethod-list author rsim-mlmethod-list accounting rsim-mlpassword serviceciscoInterim accounting disabledState CREDIT_EXHAUST_TIMER_RUNNING
Flow idle ? NOTotal idle time 0 secondsAre we accounting for time consumed ? NOAcct start sent ? YESSession inbound features:Feature: Prepaid Idle TimeoutTimeout configuration: 300 (seconds)
Feature: Prepaid Volume MonitorThreshold:4294967295 - Quota:4294967295Usage(since last update):0 - Total:23910Current states: StartSession outbound features:Feature: Prepaid Idle TimeoutTimeout configuration: 300 (seconds)
Feature: Prepaid Volume MonitorThreshold:4294967295 - Quota:4294967295Usage(since last update):0 - Total:23910Current states: StartConfiguration sources associated with this session:Service: pp-quota-refill-vol, Active Time = 00:18:20
Note The combination of L4 redirection and traffic classification is currently affected by limitations described in the "CSCeh35036—Two Traffic Classes with L4 Redirect Do Not Work" section: Two traffic classes on which prioritization and L4 redirection are applied, and for which the ACLs used to do the traffic classification overlap, cannot be used at the same time. Return traffic will fail to get translated when it is translated using the traffic class service that was last applied.
Note The L4 redirection service applied at the credit-exhaust event is unapplied on the ISG, regardless of the authorization request received by the billing server upon expiration idle-timeout value. This redirection is triggered by an internal event in the policy manager (shown in debugging messages as "internal-event-cre-t-exp"), and this internal event will unapply all the actions applied to the subscriber during the credit-exhaust event.
SSG Tariff Switching: Postpaid Services
A postpaid service is different from a prepaid service in that there is no authorization request for quota sent to the billing server. The service profile for a postpaid service contains a weekly tariff switch plan containing the various tariff switch points within the week, configured using the Service-Info PPW attribute. The SSG monitors the usage at every tariff switch point and records this information in the interim accounting records, configured using the Control-Info QB attribute. The billing server monitors all accounting interim updates and obtains the information about the volume of traffic sent during the various tariff switching periods. Following is a sample service profile with the Service-Info PPW attribute highlighted for purpose of example:
postpaid-tariff-sw Password = "servicecisco", Service-Type = OutboundSSG-Service-Info [26,9,251]= "Ipostpaid-tariff-sw",SSG-Service-Info [26,9,251]= "R10.40.96.10;255.255.255.255",SSG-Service-Info [26,9,251]= "MC",SSG-Service-Info [26,9,251]= "TP",SSG-Service-Info [26,9,251]= "PPW12:00:00:31"
To enable interim accounting on the SSG for services, configure the ssg accounting per-service interval command. The interval value is set in minutes.
ssg accounting per-service interval 2
Note It is also possible to activate interim accounting for the service by including the Service-Info L attribute in the service profile (for example, SSG-Service-Info [26, 9, 251] = "L120,enable").
ISG Tariff Switching: Postpaid Services
To indicate the weekly tariff switch plan for a postpaid service on the ISG, use the same Service-Info PPW attribute as used on the SSG. The ISG interim accounting and stop records will also contain the same Control-Info QB attribute to signal the time when the last tariff switch occurred, together with the total amount of bytes sent since the last tariff switch time.
To force the ISG to send out RADIUS start and stop accounting packets for the postpaid service, you must insert the accounting-list subscriber Cisco AV pair in the service profile (shown in bold text for purpose of example):
postpaid-tariff-sw Password = "servicecisco", Service-Type = OutboundSSG-Service-Info [26,9,251]= "Ipostpaid-tariff-sw",SSG-Service-Info [26,9,251]= "R10.40.96.10;255.255.255.255",SSG-Service-Info [26,9,251]= "MC",SSG-Service-Info [26,9,251]= "TP",SSG-Service-Info [26,9,251]= "PPW12:00:00:31",Cisco AV-Pair [26,9,1] = "subscriber:accounting-list=<acct method-list>"To make certain that the Control-Info QB attribute values are present in the interim accounting start and stop packets, you must enable interim accounting. The SSG attributes that triggered interim accounting are not interpreted on the ISG. There are two methods available to enable interim accounting on the ISG.
1. Insert RADIUS attribute 85 value (acct-interim-interval; value in seconds) on the subscriber profile. Do not insert this attribute on the service profile because this action will not enable the interim accounting behavior on the service. This problem is addressed in the "CSCeh03451—Periodic Accounting on Flows Behaves Inconsistently in the ISG" section.
Note RADIUS attribute 85 works only on PPP sessions, not IP sessions.
2. Enable periodic accounting using the aaa accounting update periodic command. The update period value is set in minutes.
aaa accounting update periodic 2This command enables periodic accounting on each session and flow that has the VSA accounting pair in its profile.
The following log is an example of interim accounting packet activity before tariff switching is enabled—that is, the tariff switch time is set to 0, the service has started, but no tariff switching has occurred on the service.
RADIUS(000000CD): Send Accounting-Request to 10.30.81.45:1813 id 1646/57, len 194RADIUS: authenticator 7F 25 BA DE 57 67 17 FF - 2E DC A7 D8 B2 DC 90 A8RADIUS: Acct-Session-Id [44] 10 "000000D1"RADIUS: Framed-Protocol [7] 6 PPP [1]RADIUS: Vendor, Cisco [26] 27RADIUS: ssg-service-info [251] 21 "Npostpaid-tariff-sw"
RADIUS: Vendor, Cisco [26] 17RADIUS: ssg-control-info [253] 11 "QB11246;0"
RADIUS: User-Name [1] 15 "pp-tc71-user1"
RADIUS: Acct-Input-Packets [47] 6 48RADIUS: Acct-Output-Packets [48] 6 40RADIUS: Acct-Input-Octets [42] 6 6470RADIUS: Acct-Output-Octets [43] 6 4776RADIUS: Acct-Session-Time [46] 6 2971RADIUS: Acct-Status-Type [40] 6 Watchdog [3]
RADIUS: NAS-Port-Type [61] 6 Virtual [5]RADIUS: NAS-Port [5] 6 0RADIUS: NAS-Port-Id [87] 13 "3/0/0/0.201"RADIUS: Class [25] 14RADIUS: 70 72 65 70 61 69 64 2D 74 63 37 31 [prepaid-tc71]RADIUS: Service-Type [6] 6 Framed [2]RADIUS: NAS-IP-Address [4] 6 10.10.100.7RADIUS: Event-Timestamp [55] 6 1112706015RADIUS: Acct-Delay-Time [41] 6 0Once tariff switching occurs, the QB attribute will indicate the amount of bytes sent after the last tariff switch and the time when tariff switching occurred in UNIX time stamp format.
Use the show subscriber session command to display the uid created for the traffic class used for the tariff switching service, as follows (shown in bold text for purpose of example):
Router# show subscriber session uid 209
Unique Session ID: 209
Identifier:SIP subscriber access type(s): Traffic-Class
Current SIP options: NoneSession Up-time: 00:56:14, Last Changed: 00:56:14AAA unique ID: 0Policy information:Context 2078EB88: Handle 6700001BAuthentication status: unauthenSession inbound features:Feature: Service accounting
Service: postpaid-tariff-sw
Method List: rsim-ml
Weekly tariff plan: 14:00:00:31
Packets = 48, Bytes = 6470Session outbound features:Feature: Service accountingService: postpaid-tariff-swMethod List: rsim-mlWeekly tariff plan: 14:00:00:31Packets = 40, Bytes = 4776Configuration sources associated with this session:Service: postpaid-tariff-sw, Active Time = 00:56:14The following log is an example of the accounting interim update after tariff switch time occurs (key fields are highlighted in bold text for purpose of example):
RADIUS(000000CD): Send Accounting-Request to 10.30.81.45:1813 id 1646/68, len 202RADIUS: authenticator 47 65 47 03 96 DB 4B 3B - A8 83 0A E6 55 5C 08 A8RADIUS: Acct-Session-Id [44] 10 "000000D1"RADIUS: Framed-Protocol [7] 6 PPP [1]RADIUS: Vendor, Cisco [26] 27RADIUS: ssg-service-info [251] 21 "Npostpaid-tariff-sw"
RADIUS: Vendor, Cisco [26] 25RADIUS: ssg-control-info [253] 19 "QB2818;1112706000"
RADIUS: User-Name [1] 15 "pp-tc71-user1"
RADIUS: Acct-Input-Packets [47] 6 60RADIUS: Acct-Output-Packets [48] 6 50RADIUS: Acct-Input-Octets [42] 6 8094RADIUS: Acct-Output-Octets [43] 6 5970RADIUS: Acct-Session-Time [46] 6 3536RADIUS: Acct-Status-Type [40] 6 Watchdog [3]
RADIUS: NAS-Port-Type [61] 6 Virtual [5]RADIUS: NAS-Port [5] 6 0RADIUS: NAS-Port-Id [87] 13 "3/0/0/0.201"RADIUS: Class [25] 14RADIUS: 70 72 65 70 61 69 64 2D 74 63 37 31 [prepaid-tc71]RADIUS: Service-Type [6] 6 Framed [2]RADIUS: NAS-IP-Address [4] 6 10.10.100.7RADIUS: Event-Timestamp [55] 6 1112706580RADIUS: Acct-Delay-Time [41] 6 0The following log is an example of the accounting stop record. The QB attribute is present and its value equals the amount of bytes sent since the last tariff switch (key fields are highlighted in bold text for purpose of example):
RADIUS: Send Accounting-Request to 10.30.81.45:1813 id 1646/104, len 243RADIUS: authenticator 31 D9 2F 21 47 D1 87 AE - 44 2E 1E A5 77 C5 41 8CRADIUS: Acct-Session-Id [44] 10 "000000D1"RADIUS: Framed-Protocol [7] 6 PPP [1]RADIUS: Vendor, Cisco [26] 27RADIUS: ssg-service-info [251] 21 "Npostpaid-tariff-sw"
RADIUS: Vendor, Cisco [26] 25RADIUS: ssg-control-info [253] 19 "QB2818;1112706000"
RADIUS: User-Name [1] 15 "pp-tc71-user1"
RADIUS: Acct-Input-Packets [47] 6 60RADIUS: Acct-Output-Packets [48] 6 50RADIUS: Acct-Input-Octets [42] 6 8094RADIUS: Acct-Output-Octets [43] 6 5970RADIUS: Acct-Session-Time [46] 6 5594RADIUS: Acct-Terminate-Cause[49] 6 user-request [1]RADIUS: Vendor, Cisco [26] 35RADIUS: Cisco AVpair [1] 29 "disc-cause-ext=TS User Exit"RADIUS: Acct-Status-Type [40] 6 Stop [2]
RADIUS: NAS-Port-Type [61] 6 Virtual [5]RADIUS: NAS-Port [5] 6 0RADIUS: NAS-Port-Id [87] 13 "3/0/0/0.201"RADIUS: Class [25] 14RADIUS: 70 72 65 70 61 69 64 2D 74 63 37 31 [prepaid-tc71]RADIUS: Service-Type [6] 6 Framed [2]RADIUS: NAS-IP-Address [4] 6 10.10.100.7RADIUS: Event-Timestamp [55] 6 1112708638RADIUS: Acct-Delay-Time [41] 6 0lSSG Tariff Switching: Prepaid Services
The prepaid tariff switching feature enhances the SSG prepaid capability by bringing in the flexibility of supporting changes in tariffs during the lifetime of a connection. This feature applies to the volume-based prepaid connections wherein the rate of charging would vary depending upon the time of service access. With this feature, SSG will be able to monitor the prepaid connection based on volume and, at tariff switching time, will be able to switch to the new tariff scheme. On the SSG, no additional configuration is done to insert the tariff switching functionality on the prepaid service in question. This functionality is signaled by the prepaid billing server in its authorization response to the SSG. The response includes the tariff change time and the tokens for postswitch and preswitch periods. The values for these different parameters are inserted into a string with the following format in the Control-Info attribute [26,9,253]:
"QX<seconds before switch>;<preswitch volume in bytes>;<postswitch volume in bytes>"To indicate to the billing server how much volume quota was consumed in the period before and after the tariff switch, the SSG uses the following string format in Control-Info attribute [26,9,253]:
"QB<total amount of volume consumed after last tariff switch>;<tariff switch time in UNIX time-stamp>"The previous VSA can be present in reauthorization requests, accounting interim updates, and accounting stop packets. Note that this will be in addition to the usual quota volume attribute that indicates the total volume usage in that connection.
As for the postpaid functionality, this service type requires the usage of interim accounting on the SSG to make it possible on the ISG to retrieve the information of usage in the various intervals because of the tariff switch. To have an accounting interim update in every tariff switch interval, the accounting interim update interval must be less than the tariff switch interval.
The prepaid tariff switching functionality can interwork with the prepaid idle-timeout functionality and volume threshold.
Table 7 shows the different set of actions that the SSG takes when the billing server sends a specific set of values in its authorization response.
ISG Tariff Switching: Prepaid Services
As with the SSG, it is possible to trigger the prepaid tariff switch method on a prepaid service on the ISG. The ISG interprets or uses the same VSA attributes and string formats for this purpose as those used on the SSG. No additional commands or migration steps are required to migrate from the SSG to the ISG, apart from adjusting the prepaid service profile as described in the "ISG Basic Prepaid and Postpaid Time- and Volume-Based Services" section). As soon as the billing server indicates a tariff switch interval coming up by inserting the QX attribute in an authorization response, the prepaid tariff switching functionality will be triggered on the ISG.
The following log shows how the billing server indicates to the ISG that there is a tariff switch period coming up for the prepaid service by using the QX attribute. The show subscriber session uid 498 command reports that the traffic class of this prepaid service contains information about an upcoming tariff switch period (key fields are highlighted in bold text for purpose of example).
RADIUS(00000143): Send Access-Request to 10.30.81.45:1812 id 1645/138, len 165
RADIUS: authenticator EC 3D 59 91 82 29 32 E5 - AE 27 E9 61 8F 5C F2 66RADIUS: User-Name [1] 15 "pp-tc71-user1"
RADIUS: User-Password [2] 18 *RADIUS: Vendor, Cisco [26] 26RADIUS: ssg-service-info [251] 20 "Npp-tariff-sw-time"
RADIUS: Framed-Protocol [7] 6 PPP [1]RADIUS: Vendor, Cisco [26] 12RADIUS: ssg-control-info [253] 6 "QT45"RADIUS: Vendor, Cisco [26] 15RADIUS: ssg-control-info [253] 9 "QV10605"RADIUS: NAS-Port-Type [61] 6 Virtual [5]RADIUS: NAS-Port [5] 6 0RADIUS: NAS-Port-Id [87] 13 "3/0/0/0.201"RADIUS: Service-Type [6] 6 Framed [2]RADIUS: NAS-IP-Address [4] 6 10.10.100.7RADIUS: Acct-Session-Id [44] 10 "000002D2"RADIUS: Event-Timestamp [55] 6 1113489476RADIUS: Received from id 1645/138 10.30.81.45:1812, Access-Accept, len 91
RADIUS: authenticator 53 1F 61 87 C9 AD 8E 0E - EF C4 8A 65 98 D4 43 E5RADIUS: Framed-Protocol [7] 6 PPP [1]RADIUS: Vendor, Cisco [26] 26RADIUS: ssg-service-info [251] 20 "Npp-tariff-sw-time"
RADIUS: Vendor, Cisco [26] 14RADIUS: ssg-control-info [253] 8 "QT3600"
RADIUS: Vendor, Cisco [26] 25RADIUS: ssg-control-info [253] 19 "QX399;10000;18790"
RADIUS(00000143): Received from id 1645/138Router# show subscriber session uid 498
Unique Session ID: 498
Identifier: pp-tc71-user1
SIP subscriber access type(s): Traffic-Class
Current SIP options: NoneSession Up-time: 00:01:01, Last Changed: 00:00:16AAA unique ID: 0Policy information:Context 2078EB88: Handle 4C000381Authentication status: unauthenPrepaid context: defaultthreshold time 0 secondsthreshold volume 0 bytesmethod-list author rsim-mlmethod-list accounting rsim-mlpassword serviceciscoInterim accounting disabledState PREPAID_FEATURE_RUNNING
Flow idle ? NOTotal idle time 0 secondsAre we accounting for time consumed ? YESAcct start sent ? YESSession inbound features:Feature: Service accountingService: pp-tariff-sw-timeMethod List: rsim-mlPackets = 54, Bytes = 7273Feature: Prepaid Volume Monitor
Threshold:10000 - Quota:10000
Post Tariff Threshold:18790 - Quota:18790
Usage(since last update):2041 - Total:12646Current states: StartSession outbound features:Feature: Service accountingService: pp-tariff-sw-timeMethod List: rsim-mlPackets = 45, Bytes = 5373Feature: Prepaid Volume Monitor
Threshold:10000 - Quota:10000
Post Tariff Threshold:18790 - Quota:18790
Usage(since last update):2041 - Total:12646Current states: StartNon-datapath features:Feature: Time MonitorThreshold: 3600 (seconds) - Quota: 3600 (seconds)Session time: 62 (seconds)Configuration sources associated with this session:Service: pp-tariff-sw-time, Active Time = 00:01:03The previous example indicates that the tariff switch must take place after 399 seconds.
The following show subscriber session command output indicates that tariff switching happened, because the traffic class for the prepaid service is now starting to use the posttariff switch quota on the ISG (key fields are highlighted in bold text for purpose of example):
Router# show subscriber session uid 498
Unique Session ID: 498
Identifier: pp-tc71-user1
SIP subscriber access type(s): Traffic-Class
Current SIP options: NoneSession Up-time: 00:08:07, Last Changed: 00:07:22AAA unique ID: 0Policy information:Context 2078EB88: Handle 4C000381Authentication status: unauthenPrepaid context: defaultthreshold time 0 secondsthreshold volume 0 bytesmethod-list author rsim-mlmethod-list accounting rsim-mlpassword serviceciscoInterim accounting disabledState PREPAID_FEATURE_RUNNINGFlow idle ? NOTotal idle time 0 secondsAre we accounting for time consumed ? YESAcct start sent ? YESSession inbound features:Feature: Service accountingService: pp-tariff-sw-timeMethod List: rsim-mlPackets = 60, Bytes = 8084Feature: Prepaid Volume MonitorThreshold:10000 - Quota:10000Post Tariff Threshold:18790 - Quota:18790Usage(since last update):0 - Total:14054Current states: Start Tariff-switched
Session outbound features:Feature: Service accountingService: pp-tariff-sw-timeMethod List: rsim-mlPackets = 50, Bytes = 5970Feature: Prepaid Volume MonitorThreshold:10000 - Quota:10000Post Tariff Threshold:18790 - Quota:18790
Usage(since last update):0 - Total:14054Current states: Start Tariff-switched
Non-datapath features:Feature: Time MonitorThreshold: 3600 (seconds) - Quota: 3600 (seconds)Session time: 488 (seconds)Configuration sources associated with this session:Service: pp-tariff-sw-time, Active Time = 00:08:09To send out a new authorization to the billing server, the threshold for the volume quota usage must exceed the Post Tariff Threshold value when the tariff switch happened.
Just as on the SSG, the accounting interim updates must contain the QB parameter to indicate to the billing server how much quota of the total consumed quota (QV) was consumed after the tariff switch time. See the bold text in the following example:
RADIUS(00000143): Send Accounting-Request to 10.30.81.45:1813 id 1646/68, len 212RADIUS: authenticator CE 19 23 2C 0B 35 2E 63 - 45 59 1E 96 75 78 39 6ERADIUS: Acct-Session-Id [44] 10 "000002D2"RADIUS: Vendor, Cisco [26] 26RADIUS: ssg-service-info [251] 20 "Npp-tariff-sw-time"RADIUS: Framed-Protocol [7] 6 PPP [1]RADIUS: Framed-IP-Address [8] 6 10.20.72.10RADIUS: User-Name [1] 15 "pp-tc71-user1"RADIUS: Vendor, Cisco [26] 25RADIUS: ssg-control-info [253] 19 "QB8448;1113489875"
RADIUS: Vendor, Cisco [26] 16RADIUS: ssg-control-info [253] 10 "I0;12950"RADIUS: Vendor, Cisco [26] 15RADIUS: ssg-control-info [253] 9 "O0;9552"RADIUS: Acct-Input-Octets [42] 6 12950RADIUS: Acct-Output-Octets [43] 6 9552RADIUS: Acct-Session-Time [46] 6 552RADIUS: Acct-Status-Type [40] 6 Watchdog [3]RADIUS: NAS-Port-Type [61] 6 Virtual [5]RADIUS: NAS-Port [5] 6 0RADIUS: NAS-Port-Id [87] 13 "3/0/0/0.201"RADIUS: Service-Type [6] 6 Framed [2]RADIUS: NAS-IP-Address [4] 6 10.10.100.7RADIUS: Event-Timestamp [55] 6 1113489983RADIUS: Acct-Delay-Time [41] 6 0To understand how to trigger interim accounting updates, see the "ISG Basic Prepaid and Postpaid Time- and Volume-Based Services" section.
The QB value can also be inserted in the authorization request sent by the ISG to the billing server, as highlighted text in the following example indicates:
RADIUS(00000143): Send Access-Request to 10.30.81.45:1812 id 1645/139, len 192RADIUS: authenticator EC 3D 59 91 82 29 32 E5 - AE 27 E9 61 8F 5C F2 66RADIUS: User-Name [1] 15 "pp-tc71-user1"
RADIUS: User-Password [2] 18 *RADIUS: Vendor, Cisco [26] 26RADIUS: ssg-service-info [251] 20 "Npp-tariff-sw-time"
RADIUS: Framed-Protocol [7] 6 PPP [1]RADIUS: Vendor, Cisco [26] 13RADIUS: ssg-control-info [253] 7 "QT679"RADIUS: Vendor, Cisco [26] 15RADIUS: ssg-control-info [253] 9 "QV33766"RADIUS: Vendor, Cisco [26] 26RADIUS: ssg-control-info [253] 20 "QB19712;1113489875"
RADIUS: NAS-Port-Type [61] 6 Virtual [5]RADIUS: NAS-Port [5] 6 0RADIUS: NAS-Port-Id [87] 13 "3/0/0/0.201"RADIUS: Service-Type [6] 6 Framed [2]RADIUS: NAS-IP-Address [4] 6 10.10.100.7RADIUS: Acct-Session-Id [44] 10 "000002D2"RADIUS: Event-Timestamp [55] 6 1113490110The dual quota functionality on the ISG can be deployed in combination with other specific prepaid functionality such as prepaid idle-timeout functionality and the volume threshold functionality. But as described in the "ISG Dual Quota Prepaid Service" section, the QT attribute is interpreted in combination with volume quota as a monitor timer and not a type of quota. The set of actions that the ISG takes when the billing server sends a specific set of values in its authorization response together with an idle timer are slightly different than on the SSG.
The most noticeable conditions are:
QT = 0
QX>0;>0 or 0;>0 or 0 - IT>0 or 0
On the SSG, the prepaid service would be disconnected on these conditions. On the ISG, the service will not be disconnected under these conditions because the QT parameter used in a dual quota service is a timer on the ISG to poll the billing server again for quota. Attributing the value 0 to the QT in an authorization response indicates to the ISG that it needs to turn off the time monitor functionality (see "ISG Dual Quota Prepaid Service" section for more information).
Table 8 shows the different set of actions that the ISG can take when the billing server sends a specific set of values in its authorization response, together with an idle-timeout value.
Additional References
This section provides the following additional reference information:
Related Documents
Technical Assistance
Appendix
This appendix contains the following supplementary information:
•SSG-to-ISG Migration Caveats and Workarounds
•ISG Network Configuration Example
SSG-to-ISG Migration Caveats and Workarounds
This section provides the following problem reports and workarounds from the team at Cisco Systems testing the SSG-to-ISG migration:
•CSCuk56681—ISG Sending Locally Defined Service to Portal Breaks Status Page
•CSCeg56118—ISG Sends Different Error Code than SSG for Proxy Service Activation Failure
•CSCeh03451—Periodic Accounting on Flows Behaves Inconsistently in the ISG
•CSCeh35036—Two Traffic Classes with L4 Redirect Do Not Work
•CSCsa86854—Log Function on ACL Breaks Traffic Classification
CSCuk56681—ISG Sending Locally Defined Service to Portal Breaks Status Page
When the ISG has locally defined services in the configuration, and these local services are applied to a user session, the ISG sends the Account-Info N attribute to the SESM service selection web page, to indicate that the named service is active. The locally defined services on the ISG are also sent over to the SESM service selection web page when SESM is doing an account query, to verify the status of the services the subscriber is currently using. SESM will poll the RADIUS server to know more about these active services, but because they only exist on the ISG, SESM will not receive any information from the RADIUS server about these services.
This is not a problem unless you need to verify the status of all active services. Figure 4 shows a sample SESM service selection web page with a link status that reflects the status of all active services. However, clicking the status link displays an error message.
Figure 4 SESM Service Selection Web Page with Status Error Message
Because the service is defined locally on the ISG, and because the ISG sent the service selection web page the Account-Info N attribute, the portal will attempt to download the service profile from AAA each time you click the status page, and fail.
This failure occurs because SESM did not receive any answer from the RADIUS server about these services. To overcome this problem, you could insert the names of these local services on your RADIUS server, taking care not to define any Service-Info attributes for these services that would become selectable on your SESM service selection web page. A simple RADIUS profile containing the name of the local services—for example, ip_portbundle_service and l4_redirect_service, and a password for the profile—is all that is needed.
Figure 5 shows the status page once this fix is implemented.
Figure 5 SESM Service Selection Web Page with Simple Profile Fix
If the information in this display could be confusing for subscribers, use the Service-Info I attribute to inform subscribers that they need not be concerned with this display.
CSCeg56118—ISG Sends Different Error Code than SSG for Proxy Service Activation Failure
In a situation where proxy service activation fails because a subscriber submitted an incorrect username or password while using an SSG, an error message is displayed and the subscriber is required to enter the username and password again. In the same situation, however, the ISG sends a different error code than the SSG.
CSCeh03451—Periodic Accounting on Flows Behaves Inconsistently in the ISG
Periodic accounting in AAA can be enabled using the aaa accounting update interval 500 command (the interval value is entered in seconds). This command enables periodic accounting on every session and flow that has accounting enabled. If you want to avoid this activity and enable periodic accounting on only individual sessions, use the no aaa accounting update interval 500 command to disable periodic accounting on every session and flow, and configure RADIUS attribute 85 for per-user periodic accounting. However, the following notes apply to use of RADIUS attribute 85:
•Attribute 85 works only for PPP sessions in the user profile. If the attribute is present in a user profile for IP sessions, it will not be processed.
•Attribute 85 can be present in a service profile to signify that periodic accounting needs to be enabled only for the flow, but this is not currently the way it works.
•In the policy-map service command configured on the ISG, there is no keyword to configure periodic accounting in the service profile. This missing functionality is inconsistent. Because it is possible to configure periodic accounting inside RADIUS profiles, it should also be possible to configure it in local service profiles.
CSCeh35036—Two Traffic Classes with L4 Redirect Do Not Work
Two traffic classes on which prioritization and L4 redirection are applied, and for which the ACLs used to do the traffic classification overlap, cannot be used at the same time by the same subscriber. If there is an attempt to use these features at the same time, return traffic will fail to get translated again when it is translated using the traffic class service that was last applied.
CSCsa86854—Log Function on ACL Breaks Traffic Classification
When logging is enabled on an extended ACL, and the ACL is used to classify packets on an ISG, all traffic matching the ACL is incorrectly dropped. When the log keyword is removed from the extended access-list command, everything works as expected.
ISG Network Configuration Example
The following partial example shows a typical configuration for an ISG:
...aaa new-model!!aaa group server radius SERVER_GROUPserver 10.0.0.3 auth-port 1645 acct-port 1646!aaa group server radius proxy-rsimserver 10.0.0.10 auth-port 1812 acct-port 1813!aaa authentication login default noneaaa authentication login WEB-LOGIN group SERVER_GROUPaaa authentication login proxy-rsim group proxy-rsimaaa authentication ppp default group SERVER_GROUPaaa authorization network default group SERVER_GROUPaaa authorization subscriber-service default local group SERVER_GROUPaaa accounting network default start-stop group SERVER_GROUPaaa server radius sesmclient 10.0.0.1key ciscoport 1812message-authenticator ignore!!aaa session-id commonip subnet-zero!!ip ftp username rootip ftp password apasswdno ip dhcp use vrf connected!!ip vrf VPN301rd 1000:301route-target export 1000:301route-target import 1000:301!ip cef!subscriber feature prepaid defaultthreshold time 0 secondsthreshold volume 1000 bytesmethod-list author defaultmethod-list accounting defaultpassword apasswd!subscriber policy recording rules limit 64redirect server-group redirect-groupserver ip 10.0.0.1 port 8090!no mpls traffic-eng auto-bw timers frequency 0 call rsvp-sync!!!!!class-map type traffic match-any traffic_class_default_networkmatch access-group input 110match access-group output 111!class-map type traffic match-any L4redirect-tc-examplematch access-group output name redirect-aclmatch access-group input name redirect-acl!class-map type control match-any service2-checkmatch service-name group3-service2!class-map type control match-any service1-checkmatch service-name group3-service1match service-name group3-service3match service-name group3-service4!class-map type control match-any test!policy-map type service example_networkclass type traffic traffic_class_default_networkclass type traffic default in-outdroppolicy-map type service ip_portbundleip portbundlepolicy-map type service l4_redirect10 class type traffic L4redirect-tc-exampleredirect list 199 to group redirect-group!policy-map type control example-map1class type control service1-check event service-start1 service-policy type service identifier service-name!class type control service2-check event service-start1 service-policy type service identifier service-name2 service-policy type service aaa list default name group3-service2!class type control always event session-start1 service-policy type service name example_network_service2 service-policy type service name ip_portbundle3 service-policy type service name l4_redirect!class type control always event service-stop1 service-policy type service unapply identifier service-name!!!bba-group pppoe GROUP3virtual-template 1!!vc-class atm VC_GROUP3protocol pppoe group GROUP3encapsulation aal5snap!interface Loopback0ip address 10.10.10.3 255.255.255.255!interface Loopback1ip address 192.168.21.1 255.255.255.0!interface Vif1no ip address!interface FastEthernet0/0ip address 192.168.3.1 255.255.255.0ip portbundle outsideduplex autospeed autompls mtu 1522!interface FastEthernet0/1ip address 10.10.20.3 255.255.255.0duplex autospeed auto!interface ATM1/0no ip addressno atm ilmi-keepaliveno atm enable-ilmi-trapbundle-enable!interface ATM1/0.301 point-to-pointip address 192.168.12.1 255.255.255.0atm route-bridged ipno atm enable-ilmi-trappvc 1/301class-vc VC_GROUP3!!interface ATM1/0.302 point-to-pointno atm enable-ilmi-trappvc 1/302class-vc VC_GROUP3!!interface Virtual-Template1ip unnumbered Loopback1no keepaliveppp authentication chapppp timeout aaaservice-policy type control example-map1!interface Virtual-TokenRing1no ip addressring-speed 16!router ospf 100router-id 10.10.10.3log-adjacency-changesredistribute connected subnets route-map connected-to-ospfredistribute static subnets network 10.10.10.3 0.0.0.0 area 300 network 192.168.3.0 0.0.0.255 area 300 distribute-list deny-ospf-external-routes in !router bgp 1000no synchronizationbgp router-id 10.10.10.3bgp log-neighbor-changesneighbor 10.10.10.101 remote-as 1000neighbor 10.10.10.101 update-source Loopback0 no auto-summary!address-family vpnv4neighbor 10.10.10.101 activateneighbor 10.10.10.101 send-community both exit-address-family!address-family ipv4 vrf VPN301redistribute connectedno auto-summaryno synchronizationexit-address-family!ip local pool POOL_GROUP3 192.168.21.100 192.168.21.200ip local pool migration-lab-group3 10.10.3.1 10.10.3.14!ip portbundlematch access-list 110source Loopback0!ip classlessip route 10.10.3.0 255.255.255.0 Null0ip route 10.10.0.0 255.255.255.0 10.10.20.104!no ip http server!!!ip access-list standard connected-to-ospf permit 192.168.0.0 0.255.255.255ip access-list standard deny-ospf-external-routes permit 10.10.10.101 permit 10.0.0.0 0.0.0.255!ip access-list extended redirect-acl permit tcp any any eq wwwip radius source-interface Loopback0access-list 55 permit 10.10.0.11access-list 56 permit 10.10.0.12access-list 57 permit 10.10.0.13access-list 58 permit 10.10.0.14access-list 110 permit ip any 10.0.0.0 0.0.0.255access-list 111 permit ip 10.0.0.0 0.0.0.255 anyaccess-list 155 permit ip any host 10.10.0.11access-list 156 permit ip any host 10.10.0.12access-list 157 permit ip any host 10.10.0.13access-list 158 permit ip any host 10.10.0.14access-list 199 deny tcp any host 10.0.0.1 eq wwwaccess-list 199 deny tcp any host 10.0.0.1 eq 8080access-list 199 deny tcp host 10.0.0.1 anyaccess-list 199 permit tcp any any eq www !route-map connected-to-ospf permit 10match ip address connected-to-ospf!!radius-server attribute 44 include-in-access-reqradius-server attribute 55 include-in-acct-reqradius-server host 10.0.0.3 auth-port 1645 acct-port 1646 key ciscoradius-server host 10.0.0.10 auth-port 1812 acct-port 1813 key wwradius-server vsa send accountingradius-server vsa send authentication!control-plane!!dial-peer cor custom!!!!gatekeepershutdown!!line con 0stopbits 1line aux 0stopbits 1line vty 0 4exec-timeout 0 0logging synchronous!!endGlossary
AAA—authentication, authorization, and accounting.
ACL—access control list.
AV pair—attribute-value pair.
CoA—Change of Authorization.
CPE—customer premises equipment.
DHCP—Dynamic Host Configuration Protocol.
DNS—Domain Name System.
ISG—Intelligent Service Selection Gateway.
L2TP—Layer 2 Tunnel Protocol
L4—Layer 4.
LNS—Layer 2 network server.
MPLS—Multiprotocol Label Switching.
MTU—maximum transmission unit.
PBHK—Port-Bundle Host Key.
ping—packet internet groper.
PPP—Point-to-Point Protocol.
PPPoE—PPP over Ethernet.
QoS—quality of service.
RPC—remote procedure call.
SESM—Subscriber Edge Services Manager.
SMTP—Simple Mail Transport Protocol.
SSG—Service Selection Gateway.
SSO—Single Sign-On.
UDP—User Datagram Protocol.
URL—uniform resource locator.
VPDN—virtual private dialup network.
VRF—VPN routing and forwarding instance.
VSA—vendor-specific attribute.
Note See Internetworking Terms and Acronyms for terms not included in this glossary.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2009 Cisco Systems, Inc. All rights reserved.