Downloads |
Table Of Contents
Configuring ISG Access for PPP Sessions
Prerequisites for ISG Access for PPP Sessions
Restrictions for ISG Access for PPP Sessions
Information About Configuring ISG Access for PPP Sessions
Overview of ISG Access for PPP Sessions
ISG Subscriber IP Address Management for PPP Sessions
Default Policy for ISG Access for PPP Sessions
Benefits of Using ISG Control Policies for PPP Sessions
How to Configure ISG Access for PPP Sessions Using Control Policies
Enabling ISG VRF Transfer for PPP Sessions
Specifying a VRF in a Service Policy Map
Verifying VRF Transfer for PPP Sessions
Troubleshooting ISG Access for PPP Sessions
Configuration Examples for ISG Access for PPP Sessions
Configuring ISG Access for PPP Sessions: Example
VRF Transfer for PPP Sessions Using IPCP Renegotiation: Example
Feature Information for ISG Access for PPP Sessions
Configuring ISG Access for PPP Sessions
First Published: March 20, 2006Last Updated: June 22, 2009Intelligent Services 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 about how to configure ISG access for Point-to-Point Protocol (PPP) subscribers.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for ISG Access for PPP Sessions" section.
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
•
Prerequisites for ISG Access for PPP Sessions
•
•
•
•
Prerequisites for ISG Access for PPP Sessions
For information about release and platform support, see the "Feature Information for ISG Access for PPP Sessions" section.
The specific access protocol that is being used must be provisioned on the interface.
If local PPP authentication is required, the ppp authentication command must be configured on the interface or virtual template.
The tasks and examples in this document assume that you know how to configure and use ISG control policies. See the module "Configuring ISG Control Policies" for information about how configure control policies.
Restrictions for ISG Access for PPP Sessions
Modular quality of service (QoS) command line interface (MQC) policies and ISG policies cannot be configured at the same time for PPPoX sessions on the Cisco 10000 series routers. For example, you cannot apply an MQC policy and an ISG policy (either statically or via RADIUS) to a virtual-template interface for a PPPoX session.
Information About Configuring ISG Access for PPP Sessions
Before you configure access for PPP sessions, you should understand the following concepts:
•
•
•
•
Overview of ISG Access for PPP Sessions
Layer 2 sessions are established by means of control protocols that operate between the peer entities and the ISG device. Typically, Layer 2 sessions are encapsulated to isolate them from other sessions on the same physical media.
Although the system provides default handling for Layer 2 sessions, you may want to configure policies to forward or locally terminate the protocol or to locally authenticate subscribers on the basis of identity data that is collected from the access protocol. ISG control policies can be configured to extract identity and credentials of peer entities from access protocols. This mechanism allows services to be provisioned for Layer 2 sessions on the basis of any identity pertaining to the session, whether explicitly provided via the protocol or native to the underlying media or access port.
ISG supports the following Layer 2 access protocols:
•
•
•
•
•
ISG Subscriber IP Address Management for PPP Sessions
ISG subscriber IP address management applies to IP sessions or Layer 2 (PPP) sessions that are terminated locally.
For a subscriber to be routable within a given IP service domain, the subscriber must present a domain-specific IP address to the network. If a subscriber transfers between IP service domains (which includes any private domain managed by the access provider), the IP address presented to the network must change to reflect the new domain. For locally terminated PPP sessions, ISG supports the following methods of IP address assignment:
•
•
•
•
•
When a locally terminated PPP session is transferred from one virtual routing and forwarding (VRF) instance to another VRF, the peer IP address is renegotiated using IPCP.
VRF Transfer for PPP Sessions
VRF transfer enables an ISG subscriber session to move from one VRF to another following selection of a new primary service. Once a PPP session comes up with the IP address from the network access point (NAP), the subscriber can access a web portal and choose a service provider. On VRF transfers in PPP sessions, ISG must reassign the IP address from the new domain to the PPP session. In PPP sessions, the IP address is reassigned by IP Control Protocol (IPCP) renegotiation.
Without PPP renegotiation, VRF transfer is not supported for PPP sessions.
Default Policy for ISG Access for PPP Sessions
ISG provides default handling of Layer 2 sessions in the absence of a configured control policy. If the vpdn enable command is configured and a domain name is specified in the username (for example, user@domain) or a Dialed Number Identification Service (DNIS) number has been provided, the system will perform authorization on the basis of this information. If virtual private dialup network (VPDN) tunnel information is found, the session will be forwarded for handling at an L2TP network server (LNS). If authentication is required by the remote LNS, the ppp authentication command must be configured at the PPP interface or virtual template. If the vpdn authen-before-forward command is configured, the system will attempt to authenticate the PPP session locally before forwarding it on to the LNS.
If tunnel information is not found for the domain name or DNIS or the vpdn enable command is not configured, Stack Group Bidding Protocol (SGBP) authorization will be attempted (if SGBP is configured). If no authorization information is located using SGBP, the PPP session will be terminated locally. Local termination means that the PPP session will be established between the peer and the ISG device, and the IP payload will be routed. In the latter case, authentication will occur only if the ppp authentication command is configured on the PPP interface or virtual template.
If an ISG control policy is defined for the session-start event, that policy will override the default handling.
Benefits of Using ISG Control Policies for PPP Sessions
ISG provides a flexible approach to service determination for Layer 2 sessions by providing control over the extraction of identity information and credentials from peer entities via access protocols. If a service decision can be made, for example, on the basis of the ATM permanent virtual circuit (PVC) on which a call request arrives, it may not be necessary to run the control protocol to completion before establishing the session and providing the service. This approach helps conserve local resources and improves call setup times.
How to Configure ISG Access for PPP Sessions Using Control Policies
To configure ISG Layer 2 access, perform the following steps:
1.
2.
3.
4.
This section contains the following tasks:
•
•
Enabling ISG VRF Transfer for PPP Sessions
VRF transfer enables an ISG subscriber session to move from one VRF to another following selection of a new primary service. This procedure contains the following sections:
•
•
Prerequisites
This procedure assumes that you have configured support for PPP sessions by configuring a virtual template and method of IP address allocation. Note that the original VRF, loopback interface, and IP address pool must be specified in a virtual template rather than in a user profile in order for VRF transfer to work. For information about how to configure virtual templates and support for PPP sessions, see the Cisco IOS Dial Technologies Configuration Guide.
Specifying a VRF in a Service Policy Map
VRF transfer occurs when a new primary service is activated for a session, causing the session to transfer from one VRF to another. Services can be configured in service profiles on an external authentication, authorization, and accounting (AAA) server or they can be configured on the ISG device in service policy maps. Perform this task to configure a VRF in a service policy map on the ISG device.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Verifying VRF Transfer for PPP Sessions
Perform this task to verify VRF transfer for PPP sessions. All of the show steps are optional and may be performed in any order.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Troubleshooting ISG Access for PPP Sessions
The commands in this task can be used to monitor and troubleshoot Layer 2 sessions. All of these commands are optional and do not need to be entered in a particular order.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
show subscriber session detailed
Example:Router# show subscriber session detailed
Displays information about ISG subscriber sessions.
Step 3
debug condition condition
Example:Router# debug condition username user5@example.com
Filters debug output on the basis of the specified condition.
Note
Step 4
debug subscriber packet [event | full | detail]
Example:Router# debug subscriber packet event
Displays diagnostic information about packets during Subscriber Service Switch (SSS) call setup.
Step 5
debug subscriber error
Example:Router# debug subscriber error
Displays diagnostic information about errors that can occur during SSS call setup.
Step 6
debug subscriber event
Example:Router# debug subscriber event
Displays diagnostic information about SSS call setup events.
Step 7
debug subscriber fsm
Example:Router# debug subscriber fsm
Displays diagnostic information about the SSS call setup state.
Step 8
debug pppatm {event | error | state} [interface atm interface-number[.subinterface-number]] vc {[vpi/vci]vci | virtual-circuit-name}
Example:Router# debug pppatm error
Displays diagnostic information for PPP over ATM (PPPoA) events, errors, and states, either globally or conditionally, on an interface or virtual circuit (VC).
Step 9
debug ppp {packet | negotiation | error | authentication | subscriber switch}
Example:Router# debug ppp packet
Displays information on traffic and exchanges in an internetwork that is implementing the PPP.
Examples
In the following example, the output of the debug subscriber packet detail command is filtered on the basis of the username "cpe6_1@example.com":
Router# debug condition username cpe6_1@example.comCondition 1 setRouter# show debugCondition 1: username cpe6_1@example.com (0 flags triggered)Router# debug subscriber packet detailSSS packet detail debugging is onRouter# show debugSSS:SSS packet detail debugging is onCondition 1: username cpe6_1@example.com (0 flags triggered)Router#Configuration Examples for ISG Access for PPP Sessions
This section contains the following examples:
•
•
Configuring ISG Access for PPP Sessions: Example
The following example shows the configuration of an ISG policy that provides services to PPP subscribers. This example configures ISG to perform the following actions:
•
ISG will activate the forwarding service "xconnect" for any subscriber with a VPI less than 200 and a VCI less than 100. This policy rule allows ISG to provide service to the associated subscribers without having to run the entire PPP protocol. All other subscribers get service on the basis of the domain specified in their username, which ISG must obtain from the protocol.
•
ISG will provide local termination by activating the service "ispa" for subscribers matching the domain "ispa". The system will authenticate the subscriber using method-list "list1". For local termination services, the global VRF is applied by default unless another VRF is specified in the service profile, on the interface, or in the virtual template.
•
ISG will locally authenticate subscribers matching domain "ispb" before forwarding the sessions to an LNS. (Sessions are forwarded to an LNS because service policy map "ispb" specifies a VPDN group). The system will authenticate the subscribers using method-list "list2".
•
ISG will forward sessions to an LNS without local authentication for subscribers matching domain "ispc".
•
ISG will deny service to and disconnect the session for subscribers matching domain "ispd".
•
For subscribers matching all other domains, ISG will activate a service that has the same name as the specified domain.
Configure control class maps, which define the conditions that must be met before a control policy rule will be executed.
class-map type control match-all PPP_SESSIONmatch identifier protocol pppclass-map type control match-all NAS_PORT_CONDITIONclass type control match identifier name PPP_SESSIONless-than identifier nas-port type atm vpi 200 vci 100class-map type control match-all ISPAmatch identifier unauthenticated-domain ispaclass-map type control match-all ISPBmatch identifier unauthenticated-domain ispbclass-map type control match-all ISPCmatch identifier unauthenticated-domain ispcclass-map type control match-all ISPDmatch identifier unauthenticated-domain ispdDefine the top-level control policy map.
policy-map type control L2_ACCESSDefine a control policy rule that activates a forwarding service on the basis of the ATM VPI/VCI on which the call came in.
class type control NAS_PORT_CONDITION event session-start1 service-policy type service xconnectDefine a control policy rule that collects the domain name from the protocol. The domain name is available from a structured user name (for example, user@domain).
class type control PPP_SESSION event session-start1 collect identifier unauthenticated-domain2 service-policy type control DOMAIN_BASED_ACCESSDefine the nested control policy.
policy-map type control DOMAIN_BASED_ACCESSDefine a control policy rule that provides local termination by activating the service "ispa".
class type control ISPA event session-start1 authenticate aaa list list12 service-policy type service ispaDefine a control policy rule that configures the system to authenticate the subscriber locally before activating service "ispb". The service "ispb" specifies forwarding the session to an LNS.
class type control ISPB event session-start1 authenticate aaa list list22 service-policy type service ispbDefine a control policy rule that activates service "ispc", which specifies forwarding.
class type control ISPC event session-start1 service-policy type service ispcDefine a control policy rule that results in session disconnection for subscribers that match service "ispd".
class type control ISPD event session-startservice disconnectDefine a control policy rule that defines the default for all other domains, which is to activate a service having the same name as the specified domain.
class type control always event session-startservice-policy type service identifier unauthenticated-domainConfigure the service policy maps.
policy-map type service xconnectservice vpdn group 1policy-map type service ispaservice localip vrf forwarding redpolicy-map type service ispbservice vpdn group 2policy-map type service ispcservice vpdn group 3Apply the control policy map globally.
service-policy type control L2_ACCESSVRF Transfer for PPP Sessions Using IPCP Renegotiation: Example
The following example shows a configuration that uses PPPoE to establish a session, and the RADIUS service profile that is created to associate the VRF. In this example, when a PPP session initially comes up, it belongs to the default routing table, and the IP address is assigned from the default IP address pool "DEF-POOL". When the subscriber selects the "ISP-RED" service, ISG downloads the "ISP-RED" service profile and applies it to the session. The PPP session is then transferred to VRF "RED". IPCP renegotiation occurs between the client device and the ISG device, and the subscriber is assigned a new IP address from the pool "POOL-RED".
ip vrf REDrd 1:1interface Loopback0ip address 10.0.0.1 255.255.255.0interface Loopback1ip address 10.0.1.0 255.255.255.0ip vrf forwarding RED!interface Ethernet0/0pppoe enableinterface Virtual-Template1ip unnumbered Loopback0service-policy control RULE2peer default ip address pool DEF-POOLppp authentication chapip local pool DEF-POOL 172.16.5.1 172.16.5.250ip local pool POOL-RED 172.20.5.1 172.20.5.250Service Profile for ISP RED
Cisco-AVpair = ip:vrf-id=REDCisco-AVpair = "ip:ip-unnumbered=loopback 1"Cisco-AVpair = ip:addr-pool=POOL-REDCisco-AVpair = subscriber:sg-service-type=primaryCisco-AVpair = subscriber:sg-service-group=RED-GROUPCisco-SSG-Service-Info = IPPPOE-REDCisco-SSG-Service-Info = R10.1.1.0;255.255.255.0Framed-Protocol = PPPService-Type = FramedAdditional References
The following sections provide references related to ISG access for PPP sessions.
Related Documents
ISG commands
AAA configuration tasks
The "Authentication section in the Cisco IOS Security Configuration Guide
AAA commands
The "Authentication, Authorization, and Accounting (AAA)" section in the Cisco IOS Security Command Reference
PPP configuration tasks
The "PPP Configuration" section of the Cisco IOS Dial Services Configuration Guide
PPP commands
Technical Assistance
Feature Information for ISG Access for PPP Sessions
Table 1 lists the features in this module and provides links to specific configuration information. Only features that were introduced or modified in Cisco IOS Release 12.2(28)SB or a later release appear in the table.
For information on a feature in this technology that is not documented here, see the "Intelligent Services Gateway Features Roadmap."
Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS and Catalyst OS software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
Table 1 Feature Information for ISG Layer 2 Access
ISG:Session: Creation: P2P Session (PPPoE, PPPoXoX)
12.2(28)SB
12.2(33)SRCThe ISG session is the primary context to which services and policies are associated across specific data flows. Point-to-point (P2P) sessions are established through a signaling protocol. ISG handles many variants of P2P encapsulation, such as PPP, PPPoE and PPPoA.
The following sections provide information about this feature:
•
•
In Cisco IOS Release 12.2(33)SRC, support was added for the Cisco 7600 router.
CCDE, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, Cisco IronPort, the Cisco logo, Cisco Nurse Connect, Cisco Pulse, Cisco SensorBase, Cisco StackPower, Cisco StadiumVision, Cisco TelePresence, Cisco Unified Computing System, Cisco WebEx, DCE, Flip Channels, Flip for Good, Flip Mino, Flipshare (Design), Flip Ultra, Flip Video, Flip Video (Design), Instant Broadband, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn, Cisco Capital, Cisco Capital (Design), Cisco:Financed (Stylized), Cisco Store, Flip Gift Card, and One Million Acts of Green are service marks; and Access Registrar, Aironet, AllTouch, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Lumin, Cisco Nexus, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, Continuum, EtherFast, EtherSwitch, Event Center, Explorer, Follow Me Browsing, GainMaker, iLYNX, IOS, iPhone, IronPort, the IronPort logo, Laser Link, LightStream, Linksys, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, PCNow, PIX, PowerKEY, PowerPanels, PowerTV, PowerTV (Design), PowerVu, Prisma, ProConnect, ROSA, SenderBase, SMARTnet, Spectrum Expert, StackWise, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website 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. (0910R)
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.
© 2006-2009 Cisco Systems, Inc. All rights reserved.
