Cisco 7600 Series Router Software Configuration Guide, Cisco IOS Release 15S

Benefits

The IP Subscriber Awareness over Ethernet feature provides the following benefits:

• IP session termination and IP session aggregation on the Cisco 7600 router.
• Support for up to 32000 IP subscribers on a router (with a maximum of 8000 subscribers on a single Cisco 7600 SIP-400).
• Interface scalability to support up to 32000 interfaces on the router.

– Support for up to 1000 subinterfaces on each physical port.

– Support for up to 8000 subinterfaces on each Cisco 7600 SIP-400.

• DHCP and Radius accounting for IP subscribers. Support for 256 DHCP pools, and DHCP can handle up to 150 calls per second for IP subscriber sessions.
• QoS support for individual IP subscribers (up to 32000 subscribers), including: classification (IP prec and DSCP), policing, shaping, marking, priority queues, and weighted random early detection (WRED).
• Per-subscriber statistics and accounting information.
• Support for up to 96000 ARP entries.
• RPR, RPR+, stateful switchover (SSO), and non-stop forwarding (NSF) are provided for the IP subscribers.
• Control plane protection (CoPP) protects against denial of service (DOS) and other attacks.

IP Subscriber Interfaces

Cisco IOS Release 12.2SRB introduces a new type of interface to represent IP subscribers:

• Access—A subinterface that represents an individual IP subscriber. The access subinterface can be configured for.1Q or Q-in-Q encapsulation.

You apply traffic shaping and policing policies (including HQoS) to the access interface to define the amount of bandwidth to allocate for different types of subscriber traffic (for example, voice and data).

Note You configure the access interface as a subinterface of the physical interface that the IP subscriber is connected to.

Example

The following example shows an access subinterface on the interface :

• On a ES+ line card, this feature is supported on the access interfaces and non-access interfaces (limited to 500 subinterfaces).

IP Subscriber Session

An IP subscriber session exists while an IP subscriber is using its shared VLAN to access the network. To begin an IP subscriber session, the router must assign an IP address to the subscriber’s access subinterface. You can either assign a static IP address to the subinterface, or you can allow DHCP to assign an address. Following are some notes about both methods of assigning an IP address:

• Static IP address—If you assign a static IP address to the access subinterface, the IP subscriber session is considered to always be Up. We recommend that you do not configure many IP subscribers with static IP addresses.
• DHCP-assigned IP address—You can allow DHCP to assign an IP address for the subscriber session. An IP subscriber session begins when the router receives a DHCP discover packet for the subscriber and an IP address is assigned for the subscriber. The session is terminated when the subscriber receives a DHCP release message and its IP address is released. If the subscriber session is VRF aware (that is, if the subscriber belongs to a VRF), the VRF-aware DHCP pool must be used.

Note ● The router can be operating as a DHCP server or DHCP relay device.

• To configure an IP subscriber as part of a VRF (that is, to make the subscriber session VRF aware), configure the VRF under the access subinterface.

This feature supports the following sessions in a ES+ line card:

• IP sessions (routed and L2-connected)
• DHCP integration with IP sessions
• Static IP subnet sessions
• Source IP address and MAC address sessions (IP sessions)
• PPPoE supported in the PPP Termination and Aggregation (PTA) mode
• PPPoEoVLAN supported in the PTA mode
• PPPoEoQinQ supported in the PTA mode
• PPPoEoDot1Q supported in the PTA mode

IP Address Assignment

• DHCP Based IP address assignment: 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.
• Static IP address assignment: If a subscriber’s static IP address is configured correctly for the service domain, ISG is not involved in the assignment of an IP address for the subscriber.
• IP subnet: For IP subnet sessions, the IP subnet is specified in the user profile.

IP interface: ISG is not involved in the assignment of subscriber IP addresses.

IP Subnet (IP Range) Sessions

A client subnet identifies a IP Subnet session and applies uniform edge processing to packets associated with a particular IP subnet. IP Subnet sessions are hosted for clients directly connected or over multiple hops. The following functionalities are not supported on IP Subnet Sessions, but are supported on IP Sessions:

• DHCP session initiation not supported
• No Source MAC address session support
• No Dynamic VPN selection support

IP Interface Sessions

In an IP Interface session, all the traffic received on a particular physical or logical interface is collated. However, dynamic VRF transfer is not supported in an IP interface session and, VRF transfer can only be used with static VRF configuration. Irrespective of the subsriber logged in, a session is created by default.

PPPoE and IPoE Session Support on Port Channel (1:1 Redundancy)

The 1:1 redundancy on a port channel coupled with Link Aggregation Control Protocol (LACP) dynamically handles the member links in a port channel bundle. A port channel has two members, of which one member is active and the other is in standby or redundant mode. The member ports can be across line cards, but must originate from Ethernet Services Plus (ES+) line card. At any given point of time, one link is on the physical mode.

The following sessions support 1:1 redundancy in a ES+ line card:

• IP Subnet sessions
• IP Interface sessions
• PPPoEoX sessions.

PPPoE and IPoE Session Support on QinQ Subinterfaces with IEEE 802.1AH Customer Ethertype

This feature enables you to implement PPPoE and IPoE session (ISG functions) on QinQ subinterfaces that are configured with custom ethertype. The custom ethertype implemented on the main interface is inherited by all the subinterfaces. To implement this feature, use dot1q tunnel ethertype command on main interface for the respective QinQ subinterfaces.

If the outer VLAN tag on a PPPoE or IPoE session packet matches the custom ethertype VLAN settings on the QinQ subinterface, the packets are accepted otherwise the packets are dropped. You can set the outer VLAN tag to the following values:

• 0x9100
• 0x9200
• ox8100
• 0x88a8

The PPPoE or IPoE session will not come up if tthere is mismatch i the ether type between ISG and the client. For example, if the outer VLAN tag on a packet is set to 0x9100 and the interface is configured using custom ethertype to accept only packets with 0x88a8 VLAN tag, the packet will be dropped in the QinQ subinterface. Figure x-x shows an ethernet frame format for QinQ (need the figure)

You can create a QinQ subinterface using the access keyword while defining an interface. The following code shows how to define an interface with access keyword, create a VLAN QinQ subinterface, and enable PPPoE session:

Restictions and Usage Guidelines

Follow these restrictions and usage guidelines when you configure an IP or a PPPoE sessions on an ES+ linecard:

• IP Sessions are not supported on ambiguous VLANs.
• Radius proxy is not supported for the IP Sessions.
• IP and MAC address spoof Prevention is not supported on subinterfaces on a ES+ linecard unlike on a SIP400 line card.
• IP sessions are supported on Link Aggregation (Ether-Channel) interfaces. LAG etherchannel interfaces are supported for links on the same and across line cards.
• PPPoE sessions are supported on ambiguous VLAN interfaces and VLAN ranges.
• There are no drop counters to identify the number of packets dropped due to custom ethertype mismatch.
• VLANs, Source MAC Address, and Ports are matched against session ids to extend security for PPPoE sessions.

Follow these restrictions and usage guidelines when you configure 1:1 redundancy on a ES+ linecard:

• Subscriber redundancy is available only on a 1:1 access standby model.
• Supports access interfaces in port channels to scale the number of port channel subinterfaces to greater than 4k.
• Link Aggregation Control Protocol (LACP) allows dynamic handling of member links in a GEC bundle.
• Supports a maximum of 64 GEC bundles with 8 links.
• Member links in a single GEC bundle reside across NPs or the linecard.
• LAG is supported with members across linecards.
• Supports LAG across linecards and membership of the LAG does not change after new sessions are initiated.
• Feature supports 32000 access subinterfaces and 8K access interfaces.
• Supports per session load balancing across member links where all the traffic for a session is relayed over a single port.
• To reduce the downtime during member link addition or deletion, QOS queues are allocated for all member links belonging to the port channel. Though the ingress and egress traffic could be on different member links, the peer relays all the traffic for a session through a single member link.
• LAG supports sessions on non access subinterfaces to support coexistence of multicast streams.

Verification

This section lists the commands to display configuration information.

• Use the following commands to configure the PPPoE:

• Use the following commands to configure IP session:

QoS Recommendations

When you configure QoS features on the Cisco 7600 SIP-400 for use with the IP Subscriber Awareness over Ethernet feature, note the following configuration guidelines and recommendations:

• The Cisco 7600 SIP-400 is capable of throughput of 5.1 to 5.6 gigabits per second (Gbps). We recommend that you do not oversubscribe the card beyond 8 Gbps. Beyond this limit, the card’s behavior is unpredictable. [CSCsg67629]
• Oversubscription is supported only on the 5-Port Gigabit Ethernet SPA (SPA-5X1GE-V2).

Egress Oversubscription

• High-priority traffic (typically voice and video) must have an IP precedence value of 5, 6, or 7.
• IP precedence values of 0, 1, 2, 3, or 4 will result in drops if oversubscription occurs, even if the traffic is classified as priority traffic in a QoS policy. [CSCsg67721]

Note We strongly recommend that the IP precedence value and VLAN user priority values of packets match. If ingress oversubscription occurs, priority traffic with non-matching IP precedence and VLAN user priority values might be dropped at the SPA level. [CSCsg97434]

Ingress Oversubscription

• High-priority traffic (typically voice) must have VLAN user priority values of 5, 6, or 7. Priority values of 0, 1, 2, 3, or 4 will result in drops if oversubscription occurs, even if the traffic is classified as priority traffic by a QoS policy. [CSCsg97434, CSCsg67721]

QoS Counter Updates

• To obtain statistics for an individual IP subscriber session, issue the show policy-map interface command two or three times. This is necessary because the counters retain their existing values the first time you issue the command.
• If you issue the show policy-map interface command and do not specify an interface, the router must update all of the session counters. With 32000 subscribers, this can take up to 30 minutes.

Bandwidth-Remaining Ratio Recommendations

The Bandwidth-Remaining Ratio (BRR) feature (also called Distribution of Remaining Bandwidth Using Ratio) allows service providers to prioritize subscriber traffic during periods of congestion. You can use the feature to specify the relative weight of a subinterface or class queue with respect to other subinterfaces or queues. During congestion, the router uses the bandwidth-remaining ratio to optimize the scheduling of uncommitted bandwidth on subinterfaces and class queues. Without BRR, the unassigned bandwidth on a physical interface is equally distributed among all queues. For an overview of this feature, see its feature description at:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122sb/newft/122sb31/bwratio.htm

This section provides recommendations and guidelines for configuring BRR on the Cisco 7600 SIP-400 to support IP Subscriber Awareness over Ethernet. It contains the following sections:

• BRR Configuration Guidelines
• BRR Configuration Instructions

BRR Configuration Guidelines

Observe the following Cisco 7600 specific guidelines and considerations as you configure this feature:

• Supported only on the Cisco 7600 SIP-400 with 2-port and 5-port Gigabit Ethernet (GE) SPAs.
• Available only on GE interfaces (because the feature is only supported on GE SPAs).
• Requires RSP720, Sup720, or Sup32.
• If two subinterfaces have bandwidth remaining ratios that vary greatly (for example, 1000 to 1), you must configure a low queue limit (between 2 and 50) for the child default class of the subinterface with the lower ratio. Without a low queue limit, the packets that are buffered due to the default queue-limit value are allowed to pass after traffic is stopped, which affects bandwidth remaining ratios significantly. Configuring a low queue limit ensures that the ratios are maintained even after the traffic is stopped.

Note We recommend that you use BRR with priority-rate propagation. See the “Priority-Rate Propagation Recommendations” section for more information.

BRR Configuration Instructions

Following is a summary of the steps required to configure configure a QoS policy that defines BRR for a subscriber (access) interface on the Cisco 7600 SIP-400. The following table provides detailed instructions.

Note The command lines include only those arguments and keywords required to configure BRR.

1. enable

2. configure terminal

3. qos scheduler priority-rate-propagation platform sip-400 (optional but recommended)

4. policy-map child-policy-name

5. class class-map-name

6. priority level level (optional but recommended)

7. police bps

8. exit

9. exit

10. policy-map parent-policy-name

11. class class-default

12. bandwidth remaining ratio ratio

13. shape average cir [bc] [be]

14. service-policy child-policy-name

15. exit

16. exit

17. interface type slot / module / port.subinterface access

18. service-policy output parent-policy-name

DETAILED STEPS

Priority-Rate Propagation Recommendations

Priority-rate propagation applies (propagates) a priority level and traffic rate from a lower-level queue to all of the upper-layer queues in the queue hierarchy, even if the upper-layer queues are not specifically configured for minimum rates or priority. For example, if you configure a priority level and traffic rate for a traffic class (such as video) in a child policy, you can use priority-rate propagation to apply that rate to video traffic at all queue levels (parent queue, subinterface queue, and interface queue).

Dual-priority queues enable you to define two classes of high-priority traffic in a single policy map. You can also use the priority level command to assign a priority (high or low) to each priority queue. The priority level command specifies that a class of traffic has latency requirements with respect to other classes. Currently, the router supports two priority levels: level 1 (high) and level 2 (low). The router places traffic with a high priority level on the outbound link ahead of traffic with a low priority level. High priority packets, therefore, are not delayed behind low priority packets.

The router associates a single priority queue with each priority level and services the high level priority queues until empty before servicing the next level priority queues and non-priority queues. While the router services a queue, the service rate is as fast as possible and is constrained only by the rate of the underlying link or parent node in a hierarchy. If a rate is configured and the router determines that a traffic stream has exceeded the configured rate, the router drops the exceeding packets during periods of congestion. If the link is currently not congested, the router places the exceeding packets onto the outbound link.

If bandwidth remaining ratio (BRR) has also been configured, the router services priority traffic first. After servicing the priority traffic bandwidth, the router allocates unused bandwidth to the logical queues based on the configured bandwidth-remaining ratio. In this default case, the three-level scheduler allocates an equal share of the unused bandwidth to each logical queue.

If high priority traffic is not policed appropriately, bandwidth starvation of low priority traffic can occur. Therefore, though not required, we recommend that you use the police command to configure a policer for high priority traffic. If you configure the police command for priority queues, the traffic rate is policed to the police rate for each of the priority queues.

Priority-Rate Propagation Configuration Guidelines

As you configure priority-rate propagation for use with BRR, consider the following guidelines:

• Use the [ no ] qos scheduler priority-rate-propagation platform sip400 command in global configuration mode to enable and disable the priority-rate propagation feature.
• The [ no ] qos scheduler priority-rate-propagation platform sip400 command has no effect on QoS policies that are already attached to interfaces. Therefore, we recommend that you issue the command before attaching QoS policies.

Note If you issue the [no] qos scheduler priority-rate-propagation platform sip400 command after attaching QoS policies to Cisco 7600 SIP-400 interfaces, you must save the configuration and reload the router for the command to take effect.

• Priority-rate propagation and BRR work together as follows:

– When priority-rate propagation is enabled, the router services the priority bandwidth for all subinterface policies. The remaining bandwidth is then distributed according to the bandwidth remaining ratios. In this scenario, the priority rate was propagated from the child level to the interface queue.

– When priority-rate propagation is disabled, the aggregate subinterface bandwidth (priority and best effort) is shared according to the bandwidth remaining ratios. In this scenario, the priority bandwidth is not propagated from the child queue to the interface queue.

Priority-Rate Propagation and BRR Configuration Example

Here is an example of a priority level (2) being assigned to video traffic in a child policy map and used with BRR, which is configured in the parent policy map:

Unsupported IP Subscriber Session Features

Due to the way that internal VLANs are allocated for sharing among IP subscribers, the following features are not available for individual subscribers:

• Policy-based routing (PBR), Network Address Translation (NAT), or unicast Reverse Path Forwarding (uRPF)
• IPv4 and IPv6 multicast
• Encoded address resolution logic (EARL) features, such as reflexive ACL, Generic Route Encapsulation (GRE) tunneling, Context-Based Access Control (CBAC), and server load balancing (SLB)

Interaction with Other Features

The following list describes the interaction between IP Subscriber Awareness over Ethernet and other features that are configured on the router:

• Multicast traffic is not affected by the feature. The router can participate in IGMP functions and replication without being affected by IP Subscriber Awareness over Ethernet. In addition, the router supports multicast traffic without the authentication of data service. This allows basic video service to be provided without data service.

The DSLAM (not the router) is responsible for replicating multicast traffic and delivering it to IP subscribers. Therefore, it is not necessary for the IP Subscriber Awareness over Ethernet feature to support multicast traffic on IP subscriber interfaces (access interfaces).

Configuration Summary

Following is a summary of the steps required to configure IP Subscriber Awareness over Ethernet on Cisco 7600 routers. Detailed configuration instructions are provided in the next section.

Before Starting

• Determine which VPN routing and forwarding (VRF) table each IP subscriber should be part of. All of the subscribers in a VRF share a single internal VLAN for data services. Use the ip vrf and rd commands to create each of the VRF tables that you need.

To use the same VRF, subscribers must all belong to the same network service provider (NSP), Internet service provider (ISP), or access service provider (ASP). If you do not assign a subscriber to a VRF, the subscriber is added to the default VRF, which the router creates during system bootup.

• Make sure that the router is configured as a DHCP server or a DHCP relay device in order to allow IP addresses to be dynamically assigned for IP subscriber sessions. Otherwise, you would have to assign a static IP address to each IP subscriber access subinterface (which is not recommended).

For information about configuring DHCP, see "Configuring DHCP" in the Cisco IOS IP Configuration Guide at:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcprt1/1cfdhcp.htm

• Determine which physical interfaces are used by IP subscribers. For each IP subscriber, you configure an access subinterface on the physical interface that the subscriber is connected to.

Configure QoS and HQoS Policies for IP Subscribers

• Define QoS policies (class maps and policy maps) to define traffic bandwidth and shaping policies for subscriber traffic. You can use a hierarchical QoS (HQoS) policy to shape traffic at different levels. For example, the parent policy could define the total bandwidth for the subscriber, and the child policy could define the bandwidth for different types of subscriber traffic (such as video). On a subinterface, the child policy can be attached only at the default class of the parent.
• (Optional) You can create dual-priority queues to handle the subscriber’s voice and video traffic.
• You can also define a class-based weighted fair queue (CBWFQ) or priority queue (PQ) for different types of subscriber traffic.

Configure Access Lists and Security ACLs

• Determine the security policies that are needed for IP subscribers. Create access lists and security ACLs to define these policies.

Here is an example of two access lists (2 and 3) that will be applied to IP subscribers:

The following example configures an input and output security ACL for the IP subscriber session that is represented by the access subinterface gig0/1/1.100:

Configure IP Subscriber Interfaces

• Create an access interface for each IP subscriber. Create the access interface as a subinterface of the subscriber’s physical interface. For example, if the subscriber is connected to Gig1/0/0, you could configure the access interface as Gig1/0/0.100.
• Configure the access interface as follows:

– If necessary, assign an IP address to the interface (this is a static IP address). We recommend that you do not configure many access interfaces with a static IP address. Instead, you should allow DHCP to dynamically assign IP addresses for IP subscriber sessions.

– If the IP subscriber belongs to a particular VRF table, include the ip vrf forwarding vrf-name command in the configuration to associate the interface with the table. If you do not specify a VRF table, the subscriber is added to the default VRF.

– Set the encapsulation type (.1Q or Q-in-Q) and specify which VLAN the interface is part of.

– Attach QoS policies to the interface to define traffic bandwidth and shaping policies for the subscriber traffic.

This example shows two IP subscriber access interfaces (gig1/0/0.100 and gig1/0/0.300). Since the subscribers connect through Gig1/0/0, the access interfaces are created as subinterfaces of Gig1/0/0. Notice that gig1/0/0.100 is assigned a static IP address and gig1/0/0.300 uses DHCP to obtain an IP address. In addition, notice that gig1/0/0.300 is VRF aware.

Verify the IP Subscriber Awareness over Ethernet Feature

Use the following commands to verify the status of each access interface that represents an IP subscriber. An access subinterface should exist for each subscriber and the interfaces should be in the Up state.

• Issue the show running-config interface interface . subinterface command to verify the configuration of each access subinterface (where interface is the physical interface and . subinterface is the access subinterface). For example, show running-config interface Gig1/0/2.1 displays the access subinterface (.1) that exists on the physical interface Gig1/0/2.

Configuration Examples

The following example shows a configuration with three subscribers (Gig3/2/0.10, Gig3/2/0.11, and Gig3/2/0.12), each receiving a different type of service: gold (30 Mbps), silver (15 Mbps), and bronze (5 Mbps). Each subscriber has per-subscriber accounting and per-subscriber ACL configured.

The QoS policy maps are configured so that video traffic is never dropped, and default traffic is shared in the ratio of 30:15:5 (which results in a bandwidth remaining ratio of 6:3:1).

 

Syntax Description

 

Defaults

This command has no default settings.

 

Command History

 

Usage Guidelines

This command creates an access interface for an IP subscriber. Create the access interface as a subinterface of the physical interface that the subscriber is connected to. For example, if the subscriber is connected to Gig1/0/0, you could configure the access interface as Gig1/0/0.1, Gig1/0/0.2, Gig1/0/0.3, and so on.

Include the ip vrf forwarding vrf-name command in the configuration to associate the IP subscriber with the specified VRF table. If you do not specify a VRF table, the subscriber is added to the default VRF table (which is created during router bootup).

Examples

The following command example creates an access interface for an IP subscriber and assigns the subscriber to the VRF table named vrf1. The access interface is created as subinterface.300 on the physical interface Gig2/0/1. You would issue additional commands to complete the configuration (for example, to specify encapsulation type, and to assign QoS policies).