Configuring ISG Access for IP Subscriber 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 a 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.

An IP interface session includes all IP traffic received on a specific physical or virtual interface. IP interface sessions are provisioned through the 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.

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

Where an ingress interface maps to a single subnet, the subnet might be accommodated with an IP interface session. However, if the ISG is more than one hop away from a subscriber, and there is the possibility that multiple subnets are accessible through the same interface, IP subnet sessions may be defined to distinguish the traffic and apply appropriate edge functionality to each subnet.

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. The figure below shows an example of a Layer 2 connected access network.

Figure 1. Layer 2 Connected Access Network

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. The figure below shows an example of a routed access network.

Figure 2. Routed Access Network

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
  
• IP Sessions
  
• IP Subnet Sessions
  

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 a firewall, between the subscriber and the Internet must perform Network Address Translation (NAT) for the subscriber’s private IP address.

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.

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.

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, 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 that 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.

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.

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:

• In the upstream direction, the source IP address of an IP packet is used to identify the IP session. The source IP address is the subscriber IP address.
• In the downstream direction, the destination IP address of an IP packet is used to identify the IP session. The destination IP address is the subscriber IP address.

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.

You must configure the collect identifier mac-address command at the start of a session. This instructs the ISG devices to store the MAC address as part of the session identifiers. For routed IP subscriber sessions, the MAC address is collected from the DHCP server using the DHCP Lease Query Protocol. For information about configuring the command, see the "Configuring ISG Control Policies" module.

The DHCP Lease Query message is a DHCP message type transmitted from a DHCP relay agent to a DHCP server. A DHCP Lease Query-aware relay agent sends the location of an IP endpoint to the DHCP Lease Query message.

The DHCP Lease Query transaction is a DHCP transaction with special message types that enable clients to query DHCP servers regarding the owner and the lease expiration time of an IP address. For information about configuring DHCP server for Lease Query, see the "Configuring a DHCP Server IP Address" section.

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.

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:

• In the upstream direction, the VLAN ID and source MAC address of an IP packet are used to identify the IP session.
• In the downstream direction, both the destination IP address and the VLAN ID of an IP packet are used to identify the IP subscriber context.

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:

• When receiving IP traffic from the access network (upstream direction), ISG uses the input interface to identify the IP session.
• When receiving IP traffic from the core network (downstream direction), ISG uses the output interface to identify the IP session.

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:

• Static VPN assignment--The VPN IP subscriber belongs to a static VPN domain. Whenever the IP subscriber connects to ISG, the IP subscriber is placed in the preassigned VPN domain.
• Dynamic VPN selection--The VPN IP subscriber can choose and switch among different VPN domains through dynamic service logon. Whenever a new VPN domain is selected, VPN services of the current VPN domain must be removed before VPN services of the new VPN domain can be applied to the IP subscriber.

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.

For a subscriber without a static VPN configuration, a multiservice interface must be configured on the ISG device to map the IP session to a VRF. The multiservice interface represents a boundary between a VPN routing domain and the default routing domain. In cases where an IP subscriber may be associated with several routing domains throughout the duration of a connection, multiservice interfaces serve as demarcation points for the IP subscriber to switch from one VPN domain to another. One multiservice interface must be configured for each VPN routing domain. The figure below illustrates the multiservice interface model.

Figure 3. Multiservice Interface Model

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 (this is because 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.

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.

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. The table below describes the action that ISG will take when a subscriber selects a secondary service.

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.

• ISG supports VRF-aware capabilities for CoA clients (RADIUS server), allowing one CoA client to accommodate subscribers in multiple VRFs. Subscriber sessions can be in a different VRF than where the CoA client is configured. To send a CoA message to ISG if the IP subscriber session is in a different VRF, the session identifier must use the vendor-specific attribute (VSA) format shown in the table below.

The following example shows the VRF configuration:

simulator radius subscriber 401
 authentication smith pap smith
 vsa cisco 250 S10.0.0.3:vrf-id=subscriber_VRF1 
 vsa cisco generic 252 binary 015042484b

1.    enable

2.    configure terminal

3.   Do one of the following:

4.    ip subscriber routed

5.    initiator {dhcp [class-aware] | radius-proxy | unclassified ip-address}

6.    end

1.    enable

2.    configure terminal

3.   Do one of the following:

4.    ip subscriber l2-connected

5.    initiator {dhcp [class-aware] | radius-proxy | unclassified mac-address}

6.    arp ignore local

7.    end

1.    enable

2.    configure terminal

3.    interface type number [. subinterface-number]

4.    ip subscriber interface

5.    end

1.    enable

2.    configure terminal

3.    ip subscriber list list-name

4.   Do one of the following:

5.    exit

6.   Do one of the following:

7.   Do one of the following:

8.    initiator static ip subscriber list list-name

9.    end

1.    enable

2.    configure terminal

3.   Do one of the following:

4.    ip subscriber routed

5.    initiator unclassified ip-address

6.    end

7.    Add the Framed-IP-Netmask attribute to the service or user profile.

policy-map type control GLOBAL
 class type control always event session-restart
  1 service disconnect delay 60

1.    enable

2.    configure terminal

3.    policy-map type control policy-map-name

4.    class type control {control-class-name | always} event session-restart

5.    action-number authorize [aaa list list-name] [password password] [upon network-service-found {continue | stop}] identifier {authenticated-domain | authenticated-username | auto-detect | circuit-id [plus remote-id] | dnis | mac-address | nas-port | remote-id [plus circuit-id] | source-ip-address | tunnel-name | unauthenticated-domain | unauthenticated-username}

6.    action-number service-policy type service [unapply] [aaa list list-name] {name service-name | identifier {authenticated-domain | authenticated-username | dnis | nas-port | tunnel-name | unauthenticated-domain | unauthenticated-username}}

7.    action-number set-timer name-of-timer minutes

8.    end

1.    enable

2.    show subscriber session [detailed] [identifier identifier | uid session-id| username name]

3.    show ip subscriber [mac mac-address | [vrf vrf-name] [[dangling seconds] [detail] | interface interface-name [detail | statistics] | ip ip-address | static list listname | statistics {arp | dangling}]]

4.    show platform isg session-count {all | slot}

5.    exit

1.    enable

2.    show ip subscriber [mac mac-address | [vrf vrf-name] [[dangling seconds] [detail] | interface interface-name [detail | statistics] | ip ip-address | static list listname | statistics {arp | dangling}]]

3.    clear ip subscriber [interface interface-name | mac mac-address | slot slot-number no-hardware | [vrf vrf-name] [dangling seconds | ip ip-address | statistics]]

4.    exit

Use the following commands to troubleshoot ISG IP subscriber sessions:

• debug ip subscriber
• debug condition

1.    enable

2.    configure terminal

3.   Do one of the following:

4.    ip address ip-address mask [secondary]

5.    ip subscriber {l2-connected | routed}

6.    initiator dhcp class-aware

7.    end

1.    enable

2.    configure terminal

3.    aaa new-model

4.    aaa authentication login list-name local

5.    ip dhcp pool pool-name

6.    network network-number mask

7.    exit

8.    interface type number

9.    ip subscriber l2-connected

10.    initiator dhcp class-aware

11.    end

• Troubleshooting Tips
  

1.    enable

2.    configure terminal

3.    policy-map type service policy-name

4.    classname class-name

5.    end

6.    show policy-map type service

• What to Do Next
  

Perform this task to add the vendor-specific attribute (VSA) for a DHCP class to a user profile or service profile. Subscribers for whom the user or service profile is activated will be assigned IP addresses from the DHCP pool or the remote server that is associated with the class.

• Prerequisites
  
• What to Do Next
  

Perform this task to specify which DHCP servers to use on your network, or to configure the IP address of one or more DHCP servers available on the network, and to specify the DHCP Lease Query for routed IP sessions.

Note	The DHCP server IP address needs to be configured for routed IP sessions, if the DHCP Lease Query is performed.

1.    enable

2.    configure terminal

3.    ip dhcp-server {ip-address | query lease {retries max-retransmissions | timeout timeout-query-seconds}}

4.    end

1.    enable

2.    configure terminal

3.    interface multiservice interface-number

4.    ip vrf forwarding vrf-name

5.    ip address ip-address mask

6.    end

1.    enable

2.    configure terminal

3.    policy-map type service policy-map-name

4.    ip vrf forwarding name-of-vrf

5.    sg-service-type primary

6.    sg-service-group service-group-name

7.    end

1.    enable

2.    show subscriber session uid session-identifier detail

3.    show ip subscriber [dangling seconds | detail | ip ip-address | mac mac-address | vrf vrf-name [dangling seconds| detail | ip ip-address]]

4.    show idmgr {memory [detailed [component [substring]]] | service key session-handle session-handle-string service-key key-value | session key {aaa-unique-id aaa-unique-id-string | domainip-vrf ip-address ip-address vrf-id vrf-id| nativeip-vrf ip-address ip-address vrf-id vrf-id | portbundle ip ip-address bundle bundle-number | session-guid session-guid | session-handle session-handle-string | session-id session-id-string} | statistics}

5.    show ip route [vrf vrf-name]

6.    show ip dhcp binding [ip-address]

7.    exit

1.    debug subscriber {event | error | packet| policy | service}

2.    debug ip subscriber {event | error | packet | fsm | all}

3.    debug subscriber policy dpm {error | event}

4.    debug ip dhcp server {events | packets | linkage | class}