-
Cisco IOS Intelligent Service Gateway Configuration Guide, Release 12.2 SB
-
ISG Features Roadmap
-
Configuring ISG Control Policies
-
Configuring ISG Access for PPP Sessions
-
Configuring ISG Access for IP Subscriber Sessions
-
Configuring ISG Port-Bundle Host Key
-
Configuring ISG as a RADIUS Proxy
-
Configuring ISG Policies for Automatic Subscriber Logon
-
Enabling ISG to Interact with External Policy Servers
-
Configuring ISG Subscriber Services
-
Configuring ISG Network Forwarding Policies
-
Configuring ISG Accounting
-
Configuring ISG Support for Prepaid Billing
-
Configuring ISG Policies for Session Maintenance
-
Redirecting Subscriber Traffic with ISG Layer 4 Redirect
-
Configuring ISG Policies for Regulating Network Access
-
Troubleshooting ISG with Session Monitoring and Distributed Conditional Debugging
-
Configuring ISG Layer 3 Access (Cisco IOS Release 12.2(28)SB)
-
Managing ISG Subscriber IP Addresses (Cisco IOS Release 12.2(28)SB)
-
Configuring ISG VRF Transfer (Cisco IOS Release 12.2(28)SB)
-
Table Of Contents
Configuring ISG Access for IP Subscriber Sessions
Prerequisites for ISG Access for IP Subscriber Sessions
Restrictions for ISG Access for IP Subscriber Sessions
Information About ISG Access for IP Subscriber Sessions
Types of IP Subscriber Sessions
Layer 2 Connected Access Networks
IP Subscriber Session Initiation
Methods of ISG Subscriber IP Address Assignment
Public and Private IP Addresses
Layer 2 Connected IP Subscriber Identity
Interface IP Subscriber Identity
VPN Connectivity and Services for IP Subscribers
Service Model for VRF Transfers
Benefits of Dynamic VPN Selection
IP Session Recovery for DHCP-Initiated IP Sessions
Default Services for IP Subscriber Sessions
How to Configure ISG for IP Subscriber Sessions
Creating ISG Sessions for IP Subscribers
Creating IP Subscriber Sessions for Routed ISG Subscribers
Creating IP Subscriber Sessions for Layer 2 Connected ISG Subscribers
Creating ISG IP Interface Sessions
Creating ISG IP Subnet Sessions
Configuring IP Session Recovery for DHCP-Initiated IP Sessions
Verifying ISG IP Subscriber Sessions
Clearing ISG IP Subscriber Sessions
Managing ISG Subscriber IP Addresses Using DHCP
ISG Subscriber IP Address Assignment Using DHCP
Configuring an ISG Interface for Dynamic DHCP Class Association
Configuring a DHCP Class in a Service Policy Map
Configuring a DHCP Class in a Service Profile or User Profile on the AAA Server
Configuring ISG Dynamic VPN Selection
Configuring a Multiservice Interface
Specifying a VRF in a Service Policy Map
Verifying VRF Transfer for IP Sessions
Troubleshooting VRF Transfer for IP Sessions
Configuration Examples for ISG Access for IP Subscriber Sessions
ISG IP Interface Subscriber: Example
ISG Routed IP Subscriber: Example
ISG Layer 2 Connected IP Subscriber: Example
DHCP-Initiated Session Recovery: Example
ISG Interface with DHCP Class-Aware Capability: Example
DHCP Address Pool Classes and Relay Actions for ISG: Examples
Dynamic VPN Selection: Example
Feature Information for ISG Access for IP Subscriber Sessions
Configuring ISG Access for IP Subscriber Sessions
First Published: December 5, 2006Last Updated: January 24, 2007Intelligent 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. ISG supports IP sessions for subscribers who connect to ISG from routed or Layer 2 access networks. This module describes how to configure ISG to bring up IP subscriber sessions, manage subscriber IP addressing, and configure dynamic virtual private network (VPN) selection.
Note
This document applies to Cisco IOS Release 12.2(31)SB2 and later releases. To configure IP subscriber sessions using Cisco IOS Release 12.2(28)SB, see the following modules:
Configuring ISG Layer 3 Access (Cisco IOS Release 12.2(28)SB)
Managing ISG Subscriber IP Addresses (Cisco IOS Release 12.2(28)SB)
Configuring ISG VRF Transfer (Cisco IOS Release 12.2(28)SB)Finding Feature Information in This Module
Your Cisco IOS software release may not support all of the features documented in this module. To reach links to specific feature documentation in this module and to see a list of the releases in which each feature is supported, use the "Feature Information for ISG Access for IP Subscriber Sessions" section.
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
•
•
•
•
•
•
Prerequisites for ISG Access for IP Subscriber Sessions
For information about release and platform requirements, see the "Feature Information for ISG Access for IP Subscriber Sessions" section.
Restrictions for ISG Access for IP Subscriber Sessions
Overlapping IP Address Restrictions
Overlapping IP addresses in the same VRF are not supported.
Overlapping IP subscribers in different virtual routing and forwarding instances (VRFs) are not supported on the same interface for static IP subscriber sessions and routed IP subscriber sessions. Overlapping IP subscribers in different VRFs are supported on the same interface for Layer 2 connected DHCP subscriber sessions.
IP Subnet Session Restrictions
IP subnet sessions are not supported on an interface configured with the ip subscriber l2-connected command. IP subnet sessions are supported only when ip subscriber routed is configured on the interface.
ISG DHCP Restrictions
ISG cannot relay DHCP requests when there is a Layer 3 DHCP relay agent between the ISG device and subscriber devices.
Dynamic VPN Selection Restrictions
Dynamic VPN selection is not supported for IP interface sessions, IP subnet sessions, and subscribers coming in on nonglobal VRF interfaces.
Dynamic VPN selection is not supported for subscribers with a static VPN configuration on the access interface.
Dynamic VPN selection with address reassignment is not supported for routed IP subscriber sessions that are initiated by DHCP. IP addresses of routed IP subscribers must be routable in the access network. Because ISP- or VRF-owned private addresses could overlap or be unroutable in the network between subscribers and the ISG device, it is not possible to assign IP addresses to those subscribers.
General IP Session Restrictions
Packet of Disconnect (PoD) is not supported for IP subscriber sessions.
IP subscriber sessions are not supported on ambiguous QinQ or Dot1Q subinterfaces.
IP subscriber sessions are not supported on interfaces that receive MPLS packets.
Modular Quality of Service CLI-based (MQC) shaping and queueing is not supported for IP subscriber sessions.
Cisco 10000 Series Internet Router Restrictions
On the Cisco 10000 series Internet router, ISG does not support IP subscriber sessions that are initiated by RADIUS packets.
IP interface sessions are not supported on ATM main interfaces and ATM multipoint subinterfaces on the Cisco 10000 series Internet router.
IP subscriber sessions and PPP over ATM or PPP over Ethenet (PPPoX) sessions are not supported on the same ATM main interface or subinterface. Either IP subscriber sessions or PPPoX sessions can be configured on ATM main interfaces or subinterfaces at one time.
IP subscriber sessions are not supported on the following interfaces:
•
•
•
•
For DHCP-initiated IP sessions, you must explicitly configure access lists to permit DHCP control packets (bootps and bootpc packets). If access lists are not configured to permit DHCP control packets, ISG features that are applied to IP sessions might drop these packets, resulting in unexpected or erroneous ISG behavior. For example, DHCP renew packets, which keep the DHCP-initiated IP session alive, might be dropped by security access lists that are applied to IP sessions.
Information About ISG Access for IP Subscriber Sessions
Before you configure ISG Layer 3 access, you should understand the following concepts:
•
•
•
•
•
Types of IP Subscriber Sessions
ISG supports three types of IP subscriber sessions:
IP Sessions
An IP session includes all the traffic that is associated with a single subscriber IP address. If the IP address is not unique to the system, other distinguishing characteristics such as VRF or MAC address form part of the identity of the session. ISG can be configured to create IP sessions upon receipt of DHCP packets, packets with unclassified IP or MAC addresses, or RADIUS packets. See the "IP Subscriber Session Initiation" section for more information.
IP sessions may be hosted for a connected subscriber device (one routing hop from the ISG) or one that is more than one hop from the gateway.
IP Interface Sessions
An IP interface session includes all IP traffic received on a specific physical or virtual interface. IP interface sessions are provisioned through the command-line interface (CLI); that is, a session is created when the IP interface session commands are entered, and the session is continuous, even when the interface is shut down. By default, IP interface sessions come up in the state "unauthenticated" with full network access.
IP interface sessions might be used in situations in which a subscriber is represented by an interface (with the exception of PPP) and communicates using more than one IP address. For example, a subscriber using routed bridge encapsulation (RBE) access might have a dedicated ATM virtual circuit (VC) to home customer premises equipment (CPE) that is hosting a number of PCs.
IP Subnet Sessions
An IP subnet session represents all the traffic that is associated with a single IP subnet. IP subnet sessions are used to apply uniform edge processing to packets associated with a particular IP subnet. When an IP subnet session is configured, ISG treats the subnet as a single subscriber, which means that ISG features and functionality are applied to the subnet traffic as an aggregate.
IP subnet sessions are supported for routed IP subscriber traffic.
IP subnet sessions are created the same way as IP sessions, except that when a subscriber is authorized or authenticated and the Framed-IP-Netmask attribute is present in the user or service profile, ISG converts the source-IP-based session into a subnet session with the subnet value in the Framed-IP-Netmask attribute.
Note
IP Subscriber Connectivity
IP subscribers connect to ISG through either Layer 2 connected access networks or routed access networks. The following sections describe these types of IP subscriber connectivity:
•
Layer 2 Connected Access Networks
Layer 2 connected subscribers are either directly attached to the physical interfaces of an ISG or connected to an ISG through a Layer 2 access network, such as a bridged or a switched network. Layer 3 forwarding is either absent or not used to direct subscriber traffic in the Layer 2 access network. IP addresses of the subscribers may or may not be on the same subnet as the Layer 2 connected physical interfaces. Figure 2 shows an example of a Layer 2 connected access network.
Figure 2 Layer 2 Connected Access Network
Routed Access Networks
Routed subscriber traffic is routed through a Layer 3 access network with at least one transit router before reaching the ISG. IP addresses of the subscribers are at least routable in the Layer 3 access network. Layer 3 access networks contain a single routing domain and therefore do not support overlapping IP addresses. Figure 3 shows an example of a routed access network.
Figure 3 Routed Access Network
IP Subscriber Session Initiation
ISG can be configured to allow one or more of the following events to signal the start of an IP session or IP subnet session on an interface:
•
If the following conditions are met, receipt of a DHCP DISCOVER packet will trigger the creation of an IP session:
–
–
–
•
For routed IP subscribers, a new IP session is triggered by the appearance of an IP packet with an unclassified source IP address (which means that an IP session does not yet exist for that IP address).
•
For Layer 2 connected IP subscribers, a new IP session is triggered by the appearance of an IP packet with an unclassified source MAC address (which means that an IP session does not yet exist for that MAC address).
•
For routed or Layer 2 connected access, a new IP session is triggered by the appearance of a RADIUS Access-Request packet when ISG is serving as a RADIUS proxy.
IP Subscriber Addressing
The following sections provide information about how ISG handles IP addressing for IP subscribers:
•
•
Methods of ISG Subscriber IP Address Assignment
IP subscribers either have IP addresses configured statically or obtain IP addresses dynamically through some network protocol that has the ability to assign IP addresses. 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 include any private domain managed by the access provider), the IP address presented to the network must change to reflect the new domain.
The following sections describe the methods of IP address assignment that ISG supports for each type of Layer 3 session:
IP Interface Sessions
For IP interface sessions, ISG is not involved in (or aware of) the assignment of subscriber IP addresses.
IP Sessions
For IP sessions, ISG supports the following methods of IP address assignment:
•
If a subscriber's static IP address is configured correctly for the service domain, ISG does not have to be involved in the assignment of an IP address for the subscriber.
•
If DHCP is being used to assign IP addresses, and the IP address that is assigned by DHCP is correct for the service domain, ISG does not have to be involved in the assignment of an IP address for the subscriber.
If the IP address that is assigned by DHCP is not correct for the service domain, or if the domain changes because of a VRF transfer, ISG can be configured to influence the DHCP IP address assignment.
The following conditions must be met in order for ISG to influence DHCP IP address assignment:
–
–
–
For deployments that support it, DHCP is the recommended method of IP address assignment.
IP Subnet Sessions
For IP subnet sessions, the IP subnet is specified in the user profile.
Public and Private IP Addresses
No matter how an IP subscriber is assigned an IP address, the IP address falls in either the public or the private IP address category. If an IP subscriber is assigned with a private IP address and the subscriber has to reach the Internet, a Layer 3 gateway, such as ISG or Firewall, between the subscriber and the Internet must perform network address translation (NAT) for the subscriber's private IP address. This document assumes that some Layer 3 gateway other than ISG would perform NAT in the case that IP subscribers have private IP addresses assigned.
When the access network is a Layer 2 connected network, a subscriber IP address can be either native or foreign to an access interface. A native subscriber IP address is one that belongs to the subnet provisioned on the access interface. A foreign subscriber IP address is one that does not belong to the subnet provisioned on the access interface. A foreign subscriber IP address could result when a retail ISP assigns an IP address to the IP subscriber from its own IP address allotment, which is different from the wholesale ISPs, or when an IP subscriber with a static IP address that is native in the home access network roams to a foreign access network. To support IP subscribers with foreign IP addresses, ISG must be able to respond to Address Resolution Protocol (ARP) requests that originate from foreign IP addresses with a MAC address of the ISG itself. Because the access network is Layer 2 connected, ISG maintains an adjacency to every subscriber.
When the access network is a routed network, a subscriber IP address must be routable in the access network; otherwise, subscriber traffic will never be able to reach ISG. ISG may not have an adjacency for each subscriber in this case, but rather an adjacency of the next hop toward a subscriber. The next hop is determined by the routing process on ISG.
Overlapping IP Addresses
When an access network is deployed without VPN capability, the IP address space in the access network is shared among all IP subscribers. When the IP addresses are assigned dynamically, care must be taken to ensure that these addresses do not overlap. In cases where overlapping IP addresses are assigned to IP subscribers intentionally, the access network should use a Layer 2 separation mechanism to differentiate the IP address spaces. For example, the access network may put each IP address space in a different VLAN.
In cases in which the access network serves both local IP subscribers and roaming users, the static private IP address of a roaming subscriber may overlap the native private IP address of another subscriber. For example, a public wireless hot spot that generally assigns dynamic IP addresses might want to provide access to occasional roaming users with statically configured IP addresses. To support this special overlapping condition, all IP subscribers must be in a Layer 2 connected access network in which overlapping MAC addresses do not exist. In this case, IP subscribers can be distinguished using MAC addresses.
IP Subscriber Identity
IP subscriber identity is closely related to IP session initiation because ISG must uniquely identify an IP subscriber at the moment that it creates the IP session. However, the need to identify an IP subscriber goes beyond the session initiation phase. The following sections describe how ISG uniquely identifies IP subscribers:
•
•
•
Routed IP Subscriber Identity
If the access network is a routed network, subscriber IP addresses can be used to uniquely identify IP subscribers because by definition subscriber IP addresses are at least routable in the access network.
When using a subscriber IP address as the identifier, ISG assumes that the subscriber IP address is unique. If the access network is deployed with Layer 3 load balancing, redundancy, or asymmetric routing, ISG also assumes that IP traffic from the same IP subscriber may arrive at different access interfaces. To support this type of deployment, ISG assumes a single IP address space for all the access interfaces connecting to the same access network.
If there is a requirement to support several IP address spaces over a single physical access network, the access network must use some Layer 2 encapsulation to create a separate logical access network for each IP address space. In this case, ISG can still have a single IP address space for all the logical access interfaces that connect to a logical access network.
When subscriber IP addresses are private IP addresses, the access network must be able to route such subscriber traffic. If the subscriber traffic is destined to the Internet, NAT must be performed. This document assumes that NAT is performed on some Layer 3 gateway other than the ISG.
For routed IP subscribers, the subscriber IP address serves as the key for an IP session. ISG associates IP traffic with an IP session as follows:
•
•
If the IP subscriber is a VPN user, the subscriber IP address must be routable in both the global routing table and the VPN routing table on the ISG.
In the case of an IP subnet subscriber, a subscriber IP address is defined as an IP prefix address instead of a /32 IP host address. This IP prefix covers a range of IP addresses used by end users but represents a single logical IP subscriber from the ISG point of view. In this deployment, all end users share the same connectivity and services provided by the ISG.
To normalize the classification of IP subscribers that have different network masks, ISG uses the network mask in conjunction with the subscriber IP address for routed IP subscribers.
Layer 2 Connected IP Subscriber Identity
A Layer 2 connected access network is capable of providing IP connectivity to IP subscribers with foreign and overlapping IP addresses, in addition to IP subscribers with native IP addresses. Because subscriber IP addresses might not be unique in such an access network, ISG uses the subscriber MAC address to identify Layer 2 connected IP subscribers, regardless of what kind of IP address a subscriber has.
Traffic that comes from IP subscribers with private or overlapping IP addresses and that is destined to the Internet is subject to NAT. This document assumes that NAT is performed on some Layer 3 gateway other than the ISG.
For Layer 2 connected IP subscribers, both the subscriber MAC address (unique within a VLAN) and the IP address serve as the keys for the IP session, but they are used in different directions:
•
•
Interface IP Subscriber Identity
When access interfaces are used to identify IP subscribers, each access interface corresponds to a single IP subscriber. As soon as the access interface becomes available, ISG creates an IP session using the interface as the key, and associates all IP traffic coming in and going out of this interface with the IP session.
To accurately associate IP traffic with an IP subscriber, ISG must be configured to use interfaces as the method of IP subscriber identification. ISG will then classify IP traffic as follows:
•
•
VPN Connectivity and Services for IP Subscribers
The following sections provide information about VPN connectivity and services for ISG IP subscribers:
•
•
Subscriber VPN Membership
Depending on deployment requirements, an IP subscriber may or may not have VPN service. If an IP subscriber does have VPN service, the subscriber may belong to only one VPN domain at any time. An IP subscriber is associated with a VPN domain in one of the following ways:
•
•
Dynamic VPN selection can be initiated through automatic service logon, where the VRF is downloaded and applied to the subscriber session at session start, or through subscriber service selection at a web portal, in which case the subscriber is transferred to the VRF that corresponds to the selected service.
VPN Addressing
When a subscriber session is transferred from one VPN domain to another, it is effectively entering a new addressing domain that may or may not overlap the subscriber's previous domain. The subscriber's network-facing address must be altered accordingly so that packets can be correctly routed back from within the service domain.
A VRF transfer is necessary when a subscriber's identity and subscribed services cannot be determined without interaction with a web portal. A local routing context is required, at least initially, so that IP packets may be routed to and from the portal server. Following portal-based service selection, the subscriber would typically have to be transferred into the VRF associated with the selected service domain. Following a VRF transfer, the subscriber must also receive an address that is routable in this new domain.
If ISG is adjacent to the subscriber device and serves as a DHCP relay or server, DHCP can be used to assign domain-specific addresses to subscribers.
In order for VRF transfers to be supported, it is strongly recommended that DHCP be configured with short initial leases. Because there is currently no provision for a forced DHCP renew function, existing subscriber addresses can only be altered once the current lease has expired. Subscribers will not have access to the selected domain before the next DHCP renew request is received. Using short initial lease times minimizes the interval between a VRF change and a DHCP renewal. If long lease times are used, an out-of-band method of initiating IP address change should be implemented.
When DHCP can be used to assign a new address at the subscriber device, subnet-based VRF selection can be used to bring about the transfer. Subnet-based VRF selection (also known as VRF autoclassify) is a feature that selects the VRF at the ingress port on the basis of the source IP subnet address.
Service providers and organizations have allocated public IP address blocks that are not overlapping by nature. Therefore, when they are assigned public IP addresses, VPN IP subscribers have no overlapping IP addresses. When VPN IP subscribers of different VPN domains have private IP addresses assigned, they are likely to have overlapping addresses in the access network.
An access network is a single IP address space when there is no Layer 2 encapsulation separating VPN IP subscribers of different VPN domains. Therefore, ISG must be able to handle overlapping IP addresses when deploying VPN IP subscribers. IP connectivity for VPN IP subscribers with overlapping IP addresses is possible only when they are connected to ISG through a Layer 2 connected access network.
VPN IP Subscriber Identity
ISG identifies VPN IP subscribers in the same way that it identifies non-VPN IP subscribers. Upstream IP traffic is defined as the subscriber IP traffic traveling from the access network to the VPN (overlaid on top of the service provider core network). Downstream IP traffic is defined as the subscriber IP traffic traveling from the VPN to the access network.
Service Model for VRF Transfers
A primary service is a service that contains a network-forwarding policy (such as a VRF) in its service definition. Only one primary service at a time can be activated for a session. A secondary service is any service that does not contain a network-forwarding policy.
When a subscriber for whom a primary service has already been activated tries to select another primary service, ISG will deactivate all current services (including the current primary service) and activate the new primary service, and hence switch the VRF.
When a subscriber for whom a primary service has already been activated tries to select a secondary service, the action taken by ISG depends on whether the secondary service is part of a service group. A service group is a grouping of services that may be simultaneously active for a given session. Typically, a service group includes one primary service and one or more secondary services. Table 5 describes the action that ISG will take when a subscriber selects a secondary service.
Benefits of Dynamic VPN Selection
The need for switching of a subscriber session between routing and forwarding domains (also called network services) occurs frequently in markets where so-called equal access networking must be supported. Equal access networking is often mandated by regulatory rules stating that an access provider should allow service providers equal access to a retail subscriber network. ISG dynamic VPN selection facilitates equal access networking by allowing subscribers to transfer between network services.
IP Session Termination
An IP session may be terminated in one of the following ways:
•
If DHCP is used to detect a new session, its departure may also be signaled by a DHCP event.
•
An application command that is used to terminate a session. The application stop command is typically used to terminate a session when a subscriber initiates an account logoff from a web portal. An application stop may also result from the actions of an administrator, such as action taken in response to rogue behavior from a subscriber.
•
Idle timeouts and session timeouts can be used to detect or impose termination of an IP session.
•
A control policy containing the "service disconnect" action can be used to terminate a session.
IP Session Recovery for DHCP-Initiated IP Sessions
When an IP session is terminated (for example, by account logoff or session timeout) or lost (for example, by router reload), the client may continue to hold an unexpired DHCP lease. When this happens, ISG perfoms a session restart to prevent the client's IP connection from being stuck until the DHCP lease expires. A control policy can be configured to define the actions that ISG will take when the session restart event occurs. If a policy is not defined, a default policy will take effect. The default policy causes ISG to disconnect the session after 60 seconds following a session restart and is the equivalent of the following configuration:
policy-map type control GLOBALclass type control always event session-restart1 service disconnect delay 60This default policy appears in the output for the show subscriber policy rules command as follows:
Rule: internal-rule-session-restartClass-map: always event session-restartAction: 1 service disconnect delay 60Executed: 0Default Services for IP Subscriber Sessions
Newly created IP sessions may require a default service to allow subsequent subscriber packets to be processed appropriately; for example, to permit or force TCP packets to a captive portal where menu-driven authentication and service selection can be performed. A default service policy map or service profile may be configured for IP sessions to redirect traffic, enable port-bundle host-key functionality for session identification, or enable transparent autologon. A default service would also likely include a network service, which allows subscribers to access a web portal for authentication and service selection.
How to Configure ISG for IP Subscriber Sessions
Perform the following tasks to configure ISG Layer 3 access:
•
•
•
Creating ISG Sessions for IP Subscribers
An ISG creates IP sessions for IP traffic on subscriber-side interfaces. The following tasks enable IP sessions on an interface and indicate how sessions will be identified:
•
•
•
•
•
•
•
Creating IP Subscriber Sessions for Routed ISG Subscribers
Routed IP subscribers are subscribers that are routed through a Layer 3 access network with at least one transit router before reaching the ISG. Perform this task to configure ISG to create IP sessions for routed IP subscribers.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Creating IP Subscriber Sessions for Layer 2 Connected ISG Subscribers
Layer 2 connected subscribers are either directly attached to the physical interfaces of an ISG or connected to an ISG through a Layer 2 access network, such as a bridged or a switched network. Perform this task to configure ISG to create IP sessions for Layer 2 connected IP subscribers.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Creating ISG IP Interface Sessions
An ISG IP interface session encompasses all IP packets that cross the specified interface or subinterface. Perform this task to create an ISG IP interface session.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Creating ISG IP Subnet Sessions
An IP subnet session represents all the traffic that is associated with a single IP subnet. IP subnet sessions are used to apply uniform edge processing to packets associated with a particular IP subnet. When an IP subnet session is configured, ISG treats the subnet as a single subscriber, which means that ISG features and functionality are applied to the subnet traffic as an aggregate. Perform this task to configure an IP subnet session.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Configuring IP Session Recovery for DHCP-Initiated IP Sessions
Perform this task to configure ISG to perform specific actions upon recovery of an IP session after ISG has terminated the session or reloaded. This task applies to DHCP-initiated IP sessions only.
If a policy for session recovery is not configured, ISG will apply the following default policy:
policy-map type control GLOBALclass type control always event session-restart1 service disconnect delay 60SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Verifying ISG IP Subscriber Sessions
Perform this task to verify IP subscriber session configuration and creation.
SUMMARY STEPS
1.
2.
DETAILED STEPS
Clearing ISG IP Subscriber Sessions
Perform this task to clear IP subscriber sessions.
SUMMARY STEPS
1.
2.
DETAILED STEPS
Troubleshooting Tips
Use the following commands to troubleshoot ISG IP subscriber sessions:
•
•
Managing ISG Subscriber IP Addresses Using DHCP
Before you perform this task, you should understand the following concepts:
•
To assign ISG subscriber IP addresses using DHCP, perform the following tasks:
•
•
•
ISG Subscriber IP Address Assignment Using DHCP
When ISG is in the path of DHCP requests (as either a DHCP server or a DHCP relay), ISG can influence the IP address pool and DHCP server that are used to assign subscriber IP addresses. To enable ISG to influence the IP addresses assigned to subscribers, you associate a DHCP address pool class with an address domain. The DHCP address pool class must also be configured in a service policy map, service profile, or user profile, which is associated with a subscriber. When a DHCP request is received from a subscriber, DHCP uses the address pool class that is associated with the subscriber to determine which DHCP address pool should be used to service the request. As a result, on a per-request basis, an IP address is provided by the local DHCP server or relayed to a remote DHCP server that is defined in the selected pool.
Prerequisites
For ISG to use DHCP to assign IP addresses, the following prerequisites must be met:
•
•
•
