Configuring Circuits for QoS

Contents

1Overview
1.1Circuit Configuration with QoS Policies
1.2PD QoS Priority and Drop Precedence
1.3Propagation of QoS Priority Settings Across Layer 3 and Layer 2 Networks
1.4Circuit Groups
1.5802.3ad LAG Support

2

Configuration and Operations Tasks
2.1Configuration Guidelines
2.2Configure an ATM PVC for QoS
2.3Configure an Ethernet Circuit for QoS
2.4Configure a POS Circuit for QoS
2.5Configure Cross-Connected Circuits for QoS
2.6Configure a Subscriber Circuit for QoS
2.7Configure QoS Propagation (Optional)
2.8Configure L2TP for QoS
2.9Configure MPLS for QoS
2.10Attach QoS Policies to a Circuit Group and Assign Members to the Group
2.11Configuring Virtual Port Circuit Groups
2.12Configure Nested Circuit Groups
2.13Configure Ingress Port Propagation
2.14Operations Tasks

3

Configuration Examples
3.1Attaching Rate- and Class-Limiting Policies
3.2Attaching Scheduling Policies
3.3Propagating QoS
3.4Attaching QoS Policies to Circuit Groups
3.5QoS on 802.3ad LAGs
Copyright

© Ericsson AB 2010-2011. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.

Disclaimer

The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Trademark List
SmartEdge is a registered trademark of Telefonaktiebolaget LM Ericsson.

1   Overview

This document provides an overview of the quality of service (QoS) features supported on the SmartEdge router for circuits and describes the tasks used to configure, monitor, and administer these features on circuits. This document also provides examples of QoS configurations for circuits.

Note:  
In this document, the term, circuit, refers to a port, channel, permanent virtual circuit (PVC), or link group.

This document applies to both the Ericsson SmartEdge® and SM family routers. However, the software that applies to the SM family of systems is a subset of the SmartEdge OS; some of the functionality described in this document may not apply to SM family routers.

For information specific to the SM family chassis, including line cards, refer to the SM family chassis documentation.

For specific information about the differences between the SmartEdge and SM family routers, refer to the Technical Product Description SM Family of Systems (part number 5/221 02-CRA 119 1170/1) in the Product Overview folder of this Customer Product Information library.

For information about other QoS configuration tasks and commands, see the following documents:

The Internet provides only best-effort service, offering no guarantees on when or whether a packet is delivered to the receiver. However, the SmartEdge router offers QoS differentiation based on traffic type and application. QoS policies create and enforce levels of service and bandwidth rates, and prioritize how packets are scheduled through egress queues.

1.1   Circuit Configuration with QoS Policies

You can attach both a metering and a policing policy to any port or channel to ATM and 802.1Q PVCs, to subscriber sessions, and to link groups. QoS metering and policing policies are described in Configuring Rate-Limiting and Class-Limiting.

Note:  
Metering, policing, and forwarding policies do not currently support policy ACLs for classification of IPv6 traffic. When IPv6 traffic is subject to a metering, policing, or forwarding policy that was configured using an IPv4 policy ACL, IPv6 packets do not match any of the classes, but are subject to the configured policy-level enforcement.

Child circuits can inherit the QoS metering and policing policies attached to a parent circuit below which the child circuits are configured. To enable a child circuit to inherit the metering or policing policy of its parent, configure the keyword inherit or hierarchical on the policy reference of the parent circuit. If you attach a different metering or policing policy to a child circuit, that policy overrides the metering or policing policy attached to the parent circuit unless the policy reference applied to the parent is configured with the hierarchical keyword. This keyword allows a child circuit that has its own metering or policing policy to inherit the policy of its parent and still be subject to its own policy. For more information about policy inheritance, see Policy Inheritance in Configuring Rate-Limiting and Class-Limiting.

The following types of inheritance are supported:

You can attach a scheduling policy to individual circuits (that are not cross-connected); however, the type of scheduling policy depends on the type of traffic card. QoS scheduling policies are described in Configuring Queuing and Scheduling. QoS queuing policies are automatically inherited by the children of the circuit to which the policy is applied unless the child circuit has its own queuing policy binding.

Note:  
Inheritance can span multiple levels. For example, a policy configured on a port inherited by a PVC in turn is inherited by PPPoX sessions configured under the PVC unless they have a specific policy applied.

You can also attach metering, policing, and scheduling policies to subscriber circuits; the type of scheduling policy depends on the type of traffic card on which the subscriber session is initiated. Layer 2 Tunneling Protocol (L2TP) network server (LNS) subscriber sessions are limited to priority weighted fair queuing (PWFQ) policies. To attach a QoS policy of any type to a subscriber circuit, you attach it to the subscriber record or profile. The system applies the policy to the subscriber circuit (port, channel, or PVC) on which the session is initiated.

Table 1 lists the traffic cards and their circuits to which QoS scheduling policies can be attached.

Note:  
Certain restrictions apply to the attachment of a QoS scheduling policy to a port, channel, or PVC; for detailed usage guidelines for each type of circuit and policy, see the description for the qos policy queuing command (in the appropriate circuit configuration mode).

Restrictions also apply to the configuration of the circuit; for information about configuring traffic card ports, channels, and circuits, see Configuring ATM, Ethernet, and POS Ports, Configuring Circuits, and Configuring Cross-Connections.


Table 1    QoS Scheduling Policy Support for SmartEdge Traffic Cards

Type

Traffic Card or MIC

Circuit

Policy

Second-generation ATM OC

ATM OC-3c/STM-1c IR (2-port) MIC, SmartEdge 100

ATM PVC

ATMWFQ

ATM OC-3c/STM-1c (8-port)

ATM PVC

ATMWFQ

ATM OC-12c/STM-4c (2-port)

ATM PVC

ATMWFQ

Channelized OC

Channelized OC-3/STM-1 (8/4-port) or OC-12/STM-4 (2/1-port)

Port, 802.1Q tunnel

PWFQ

POS

POS OC-3c/STM-1c (8-port)

Port, Frame Relay PVC

PWFQ or MDRR

POS OC-12c/STM-4c (4-port)

Port, Frame Relay PVC

PWFQ or MDRR

POS OC-48c/STM-16c (4-port)

Port, Frame Relay PVC

PWFQ or MDRR

OC-192c/STM-64c (1-port)

Port, Frame Relay PVC

PWFQ or MDRR

 

10/100 TX (12-port) MIC, SmartEdge 100

Port, 802.1Q tunnel, 802.1Q PVC

PWFQ or MDRR

10/100 FX SFP-based (12-port) MIC, SmartEdge 100

Port, 802.1Q tunnel, 802.1Q PVC

PWFQ or MDRR

Fast Ethernet-Gigabit Ethernet

Fast Ethernet–Gigabit Ethernet (60-port FE, 2-port GE)

Port, 802.1Q tunnel, 802.1Q PVC

PWFQ or MDRR

Gigabit Ethernet with traffic management

Gigabit Ethernet 1020 (10-port) (ge-10-port)

Port, 802.1Q tunnel, 802.1Q PVC, hierarchical node

PWFQ or MDRR

Gigabit Ethernet 1020 (20-port) (ge-20-port)

Port, 802.1Q tunnel, 802.1Q PVC, hierarchical node

PWFQ or MDRR

Gigabit Ethernet (5-port) (ge-5-port)

Port, 802.1Q tunnel, 802.1Q PVC, hierarchical node

PWFQ or MDRR

Gigabit Ethernet DDR (10-port) (ge2-10-port)

Port, 802.1Q tunnel, 802.1Q PVC, hierarchical node

PWFQ or MDRR

Gigabit Ethernet 4 DDR (20-port) (ge4-20-port)

Port, 802.1Q tunnel, 802.1Q PVC, hierarchical node

PWFQ or MDRR

Gigabit Ethernet (2-port, copper) native port, SmartEdge 100

Port, 802.1Q tunnel, 802.1Q PVC, hierarchical node

PWFQ or MDRR

Gigabit Ethernet (2-port, optical) native port, SmartEdge 100

Port, 802.1Q tunnel, 802.1Q PVC, hierarchical node

PWFQ or MDRR

10-Gigabit Ethernet

10 Gigabit Ethernet Gigabit Ethernet (10GE) (1-port)

Port, 802.1Q tunnel, 802.1Q PVC

MDRR

10 Gigabit Ethernet DDR (10GE) (4-port)

Port, 802.1Q tunnel, 802.1Q PVC

PWFQ or MDRR

10 Gigabit Ethernet / POS DDR

10 Gigabit Ethernet/OC-192c DDR (1-port)

Port, Frame Relay PVC, 802.1Q tunnel, 802.1Q PVC

MDRR

1.2   PD QoS Priority and Drop Precedence

The SmartEdge router associates a six-bit internal Packet Descriptor (PD) for the QoS value that is initialized when a packet is received on ingress. The PD remains associated with the packet as it transits the router. This six-bit internal PD value is referred to as the PD QoS Codepoint. The upper three bits hold the PD QoS priority value (ppp), and the lower three bits hold the PD QoS drop precedence value (ddd):

For a diagram of the translation from QoS priority markings into PD QoS Code Point markings on ingress and back into external markings on egress, see I Figure 1.

Default initial values depend on the circuit’s binding type:

Table 2    Default Translation of IP DSCP (or TOS) Priority to PD QoS Priority Values

IP DSCP or TOS Value

PD QoS Priority Value

PD QoS Drop Precedence Value

111xxxb

0

0

110xxxb

1

0

101xxxb

2

0

100xxxb

3

0

011xxxb

4

0

010xxxb

5

0

001xxxb

6

0

000xxxb

7

0

Table 3    Default Translation of MPLS EXP Priority Bits to PD QoS Values

MPLS EXP Value

PD QoS Priority Value

PD QoS Drop Precedence Value

7

0

0

6

1

0

5

2

0

4

3

0

3

4

0

2

5

0

1

6

0

0

7

0

Table 4    Default Translation of 802.1P Priority to PD QoS Settings

802.1P Value

PD QoS Priority Value

PD QoS Drop Precedence Value

7

0

0

6

1

0

5

2

0

4

3

0

3

4

0

2

5

0

1

6

0

0

7

0

Table 5 shows how the DSCP values are translated to PD QoS priority and drop precedence values using the default settings. For example, a DSCP value of CS7 is translated to the PD-QoS priority bit as 0.

Table 5    Default Translation of DSCP Values to PD-QoS Priority and Drop Precedence Values

DSCP Value

PD-QoS Priority Value

PD-QoS Drop Precedence Value

CS7

0

0

CS6

1

0

CS5

2

0

CS4

3

0

CS3

4

0

CS2

5

0

CS1

6

0

CS0/DF

7

0

EF

2

6

AF41

3

2

AF42

3

4

AF43

3

6

AF31

4

2

AF32

4

4

AF33

4

6

AF21

5

2

AF22

5

4

AF23

5

6

AF11

6

2

AF12

6

4

AF13

6

6

You can modify the PD QoS settings with the following configurations:

The following configurations reference PD Qos priority and drop precedence values:

1.3   Propagation of QoS Priority Settings Across Layer 3 and Layer 2 Networks

You can configure how the priority and drop precedence settings in incoming Layer 2 and Layer 3 packets are translated to PD QoS settings in packets as they transit the router, and back into those settings in egress packets.

Figure 1   Propagation of QoS Across Layer 3 and Layer 2 Networks (791)

The SmartEdge router uses these PD fields to perform the following functions for an incoming Layer 2 packet:

  1. Depending on configuration for an inbound circuit protocol, the SmartEdge OS populates the PD for this packet, using one of the following functions:
    • For incoming Layer 2 packets (arriving over MPLS, 802.1Q, or L2TP protocols)—If a QoS propagate from command is configured for the Layer 2 protocol, the SmartEdge OS translates the priority bits from the Layer 2 header to the PD QoS priority.

      If no classification map is configured for the propagate from command (specifically setting the mapping), the default translation is used, depending on the Layer 2 protocol, to populate the PD QoS priority.

    • For incoming Layer 3 packets—If a QoS propagate from command is configured for a Layer 3 protocol, the SmartEdge router translates the three most-significant DSCP bits from the Layer 3 header in the incoming packet to the PD QoS priority and the drop precedence settings in that header to the PD QoS drop precedence.

      With a class map configured, the SmartEdge OS specifies a custom value mapping for propagating the Differentiated Services Code Point (DSCP) bits in the IP packet header to the packet descriptor (PD) priority bits for incoming IP packets. With no class map configured the default translation is used.

  2. If a QoS policing policy, which can include a policy access control list (ACL), that includes a mark command (of any type) is attached to the inbound circuit, the SmartEdge router modifies the bits in the priority and drop fields in the PD based on the policy.

    A decision is also made whether to forward the incoming Layer 3 packet to the outbound circuit for further QoS processing.

  1. If a QoS metering policy (which can include a policy ACL) that includes a mark command (of any type) is attached to the outbound circuit, the SmartEdge router modifies the bits in the qos and drop fields in the PD based on the policy.
  2. The SmartEdge router encapsulates the Layer 3 packet in a Layer 2 packet, using one of the following functions:
    • If a QoS propagate to command is configured for the Layer 2 protocol, the SmartEdge router copies the priority field in the PD to the priority bits in the Layer 2 header.
    • If no QoS propagate to command is configured, the SmartEdge router sets the priority bits in the Layer 2 header to the default (lowest) priority.
  3. The SmartEdge router uses the priority field in the PD to determine the egress queue for the outgoing packet, and the drop precedence field to determine the relative priority within that queue.

The following sections further describe QoS propagation:

1.3.1   Propagation of QoS from IP to ATM

The CLP bit in the ATM header of a cell provides a method of controlling the discarding of cells in a congested ATM environment. A CLP bit can be set to either 0 (default) or 1, and ATM cells with setting of 1 are discarded before cells with a setting of 0. When you use the clpbit propagate qos to atm command to propagate the QoS classification values from the internal PD to the CLP bit in cells transmitted over ATM PVCs for outgoing packets, the PD value determines when the CLP bit should be set and which ATM cells to discard in an ATM congested network. DSCP bits are mapped to the ATM CLP bit as described in Table 6.

Table 6    QoS PD Value to ATM CLP Bit Mapping

PD Priority Value

PD Drop-Precedence Value

AF Label

ATM CLP Bit

7

N/A

Network Control

0

6

N/A

Reserved

0

5

N/A

EF

0

4

0-2

AF41

0

4

3-7

AF42, AF43

1

3

0-2

AF31

0

3

3-7

AF32, AF33

1

2

0-2

AF21

0

2

3-7

AF22, AF23

1

1

0-2

AF11

0

1

3-7

AF12, AF13

1

0

N/A

DF

1

Note:  
This default mapping can be modified using the clbit propagate qos to atm command (in ATM profile configuration mode) in conjunction with an ATM egress class map.

Note:  
You can also use the mark dscp, mark priority, and mark precedence commands (in metering policy or policing policy configuration mode) to indirectly set the ATM CLP bit when using the clpbit propagate qos to atm command to propagate the DSCP bits from IP packets to the CLP bit.

1.3.2   Propagation of QoS Between IP and Ethernet

802.1p priority is carried in virtual LAN (VLAN) tags defined in IEEE 802.1p. The VLAN tag carries one of eight priority values recognizable by Layer 2 devices in a three-bit field. These three bits are called 802.1p prioritization bits, or "p bits". P-bit marking determines the service level the packet receives when crossing an 802.1p-enabled network segment. DSCP priority bits are mapped to p bits, in either or both directions, depending on whether you configure the qos propagate from ethernet and qos propagate to ethernet commands (in dot1q profile configuration mode). As shown in Figure 2, the following steps occur for an incoming 802.1Q packet:

  1. If you use the propagate qos from ethernet command (in dot1q profile configuration mode), and you do not specify a classification map, as an 802.1Q packet enters the SmartEdge router, its 802.1p bits are copied to the PD QoS priority field and DSCP bits.

    If you do specify a classification map, the 802.1p bits are mapped to the PD QoS value and the DSCP bits are not affected.

Figure 2   Propagation of QoS Between IP and Ethernet (789)

If you use the propagate qos to ethernet command (in dot1q profile configuration mode), when the SmartEdge router prepares to forward a packet on an 802.1Q virtual LAN (VLAN), the PD priority value is copied to the 802.1p field of the outgoing packet.

If you create a classification map using the qos class-map command and reference it in propagate qos to ethernet syntax, the PD priority value is mapped to the 802.1p field, rather than copied.

For outgoing Virtual Router Redundancy Protocol (VRRP) control packets, the SmartEdge router automatically writes a value of 0 into the control packet. However, the SmartEdge router supports 802.1p marking for locally-generated VRRP advertisements, making VRRP packets subject to egress QoS maps. Any configured egress Ethernet class map can be used to map the internal priority of the packet to an 802.1p bit value.

1.3.3   Propagation of QoS Between MPLS and IP

MPLS EXP bits use one of eight priority values (3 bits in length), recognizable by Layer 2 devices. This marking determines the service level the packet receives when crossing an MPLS-enabled network segment. On ingress, MPLS EXP values are mapped to PD QoS priority values, by default. You can modify the default mapping by doing one of the following:

On egress, if you use the propagate qos to mpls command (in MPLS router configuration mode), PD QoS priority bits are mapped to MPLS EXP bits if you specify a classification map; see Figure 3.

Figure 3   Propagation of QoS Between IP and MPLS (790)

1.3.4   Propagation of QoS Between IP and L2TP

With L2TP packets by default, the DSCP and the precedence bits of the original IP packet are copied. The downstream process from the network to the SmartEdge router configured as an LNS to the SmartEdge router configured as an L2TP access concentrator (LAC) to the subscriber is illustrated in Figure 4

Figure 4   Propagation of QoS Downstream from the Network (792)

The downstream propagation process follows:

  1. At the LNS, the SmartEdge router copies the DSCP bits from the inner subscriber IP packet header in the incoming IP packet to the PD QoS priority field.
  2. The SmartEdge router then copies the PD QoS priority field to the DSCP bits in the outer L2TP IP packet header, using the propagate qos to l2tp command (in L2TP peer configuration mode), if configured. If the command is not configured, it sets the DSCP bits to the default (lowest) priority.
  3. The SmartEdge router selects an egress queue for the L2TP packet, based on the PD QoS priority field.
  4. At the LAC, the SmartEdge router copies the DSCP bits in the outer L2TP IP packet header to the PD QoS priority field.
  5. The SmartEdge router then copies the DSCP bits from the inner subscriber IP packet header to the PD QoS priority field, using the propagate qos from subscriber command (in L2TP peer configuration mode) with the downstream keyword, if configured. This operation overwrites the PD QoS priority field set by step 4.
  6. The SmartEdge router selects an egress queue, based on the priority field in the PD.

The upstream process from the subscriber to the SmartEdge router configured as an LAC to the SmartEdge router configured as an LNS to the network is illustrated in Figure 5.

Figure 5   Propagation of QoS Upstream from the Subscriber (793)

The upstream propagation process follows:

  1. At the LAC, if the propagate qos from subscriber command (in L2TP peer configuration mode) with the upstream keyword is configured, the SmartEdge router copies the DSCP bits from the inner subscriber IP packet header in the incoming IP packet to the priority field in the PD. If the propagate qos from subscriber command is not configured, it sets the priority field to the default (lowest) priority.
  2. The SmartEdge router then copies the priority field to the DSCP bits in the outer L2TP IP packet header, using the propagate qos to l2tp command (in L2TP peer configuration mode), if configured. If the command is not configured, it sets the DSCP bits to the default priority.
  3. The SmartEdge router selects an egress queue for the L2TP packet based on the priority field.
  4. At the LNS, the SmartEdge router copies the DSCP bits from the outer L2TP IP packet header in the incoming IP packet to the priority field in the PD.
  5. The SmartEdge router then copies the priority field to the DSCP bits in the inner subscriber IP packet header, using the propagate qos from l2tp command (in L2TP peer configuration mode), if configured with no classification map specified. If this command is not used, the inner subscriber IP packet header is not altered.
  6. The SmartEdge router selects an egress queue for the IP packet based on the priority field.

1.3.5   Priority Propagation for Oversubscribed Traffic Cards

Ingress propagation of QoS priority is available at the port level for certain oversubscribable traffic cards. Currently, only the 4-port 10 Gigabit Ethernet (10GE) card is supported. A traffic card is considered oversubscribable if it is designed such that the sum of the nominal rate of all its ports exceeds the actual packet-forwarding capacity of the card. The nominal packet-processing capacity of the 4-port 10GE traffic card is approximately 20 Gbps. When the total aggregate line bandwidth of in-service ports is greater than the nominal capacity of a traffic card, the card is oversubscribed. Any traffic received that exceeds the actual forwarding capacity of the card (which can vary based on factors such as average packet size and enabled ingress packet-processing features) is dropped.

The following port-level configuration commands are supported:

The port-propagate commands enable the mapping of external priority markings of MPLS EXP, Ethernet 802.1p, and IP TOS/DSCP to SmartEdge router internal QoS priority values stored in the Packet Descriptor (PD QoS). The PD QoS value so assigned in turn determines each packet's ingress oversubscription treatment.

Each port has four ingress queues (numbered 0 to 3) for the incoming traffic, and the PD QoS priority value that is assigned to a packet determines to which of the four queues the packet is admitted. Each queue has a fixed mapping to a priority number or numbers as shown in Table 7.

Table 7    Ingress Queue Assignment Based on PD Priority

Incoming Packets with PD QoS Priority Value

Are Placed in Ingress Queue

0 or 1

0

2

1

3, 4, or 5

2

6 or 7

3

The PD QoS drop precedence value that is assigned to a packet determines which of the four ingress queue admittance priorities (numbered 0 to 3) is assigned to it as shown in Table 8.

Table 8    Ingress Queue Admittance Priority Based on PD QoS Drop precedence Values

Incoming Packets with PD QoS Drop Precedence Value

Are Assigned an Ingress Queue Admittance Priority Value

0 or 1

0

2 or 3

1

4 or 5

2

6 or 7

3

Ingress queue admittance priority determines how much of the overall capacity of a queue that an incoming packet is allowed to take advantage of. Packets of ingress queue admittance priority 0 (zero) are admitted to the queue up to the point at which it is completely full, but packets of other priorities are discarded rather than queued at successively lower thresholds of the total occupancy capacity of the queue.

The 4-port 10 GE traffic card enables different queuing thresholds for each PD priority value. Each of the four packet priorities can take advantage of a different portion of the total queue depth according to the following ratios. The following values are percentages of the maximum queue occupancy level:

For example, if the target queue is 82% full, an incoming packet with a priority value of 2 or 3 is dropped, while a packet with a priority value of 0 or 1 is admitted to the queue.

The queues are serviced in strict priority order on a card-wide basis; that is, packets waiting in the highest-priority queues (queue 0) of any of the ports on the card are serviced until those queues are empty, then packets waiting in the second-highest priority queue are serviced (queue 1), and so on. Under congestion, the highest-priority are the most likely to be forwarded, and the lowest-priority packets are the most likely to be discarded due to queue overflow. If the port-propagate commands are not configured, then all packets received on the port are treated as the lowest-priority traffic for ingress oversubscription purposes (they are assigned to ingress queue 3 with queue admittance priority 3).

Packets discarded because of ingress queue overflow are reported by the show port counters detail command in the “Receive Counters" section as "overflows" (total number of packets discarded) and "overflow bytes" (total number of octets discarded).

The PD QoS value assigned during ingress oversubscription processing always determines its ingress oversubscription treatment, and it can remain associated with the packet for the subsequent SmartEdge forwarding processing stages that it will be subject to (for example, to determine which transmit queue the packet is assigned to on the egress port). However, this PD QoS value can be overridden subsequent to ingress admission by any applicable qos priority or propagate qos from command that also applies to the circuit and the default DSCP-to-PD mapping applied to all Layer 3 (bind interface, bind authentication, bind subscriber) IP circuits. When more than one port-propagate command is enabled for the same port, the outermost priority field present in a packet for which a corresponding port-propagate command has been configured on the port takes precedence. For example, if both the port-propagate from ip and port-propagate from ethernet commands are configured for the same port, the outer 802.1p value determines the ingress priority for all the 802.1q-encapsulated traffic received by the port, and the IP DSCP value determines the priority for non-802.1q-encapsulated IP over Ethernet traffic.

The port-propagation ingress classifier identifies and decodes frames of different types based on the following Ethertype field values.

Table 9    Supported Ethertype Field Values

Ethertype Field Value

Indicates Which Protocol Is Encapsulated in the Frame

0x0800

IPv4

0x8100(1)

802.1q

0x8847, 0x8848

MPLS

(1)  Plus the Ethertype value specified by the dot1q tunnel ethertype command under the port, if configured.


Note:  
Frames received with EtherType field values other than ones listed in Table 10 have their PD QoS priority and drop precedence values set to 0 (zero) and receive the lowest-priority treatment for ingress oversubscription purposes (they are assigned to ingress queue 3 with queue admittance priority 3).

Table 10 lists the supported packets from which the supported PD priority values can be extracted.

Table 10    Supported Packet Types for Ingress Port QoS Priority Propagation

IPv4 Header TOS Field DSCP Values Can Be Examined for the Following Packets

Ethernet 802.1p Priority Values Can Be Examined for the Following Packets

MPLS EXP Priority Values Can Be Examined for the Following Packets

IPv4 over Ethernet

802.1q

MPLS over Ethernet

IPv4 over 802.1q

802.1q in 802.1q (1)

MPLS over 802.1q

IPv4 over 802.1q in 802.1q

MPLS over 802.1q in 802.1q

(1)  Only the outer 802.1p value is used in this case.


1.4   Circuit Groups

Circuit groups allow you to group arbitrary PVCs or other circuits, such as subscriber sessions, for collective metering, policing, and scheduling. You can group PVCs—for example, to represent a business entity—and apply class-aware or circuit-level rate limits to the group. In this case, the traffic on all of the member circuits is collectively limited to any metering, policing, and scheduling rates configured on the circuit group.

Circuit group membership is available for 802.1Q PVCs, 802.1Q PVCs within an 802.1Q tunnel, or a mix of these circuit types. Circuit group membership is also available for subscriber circuits. When hierarchical rate limiting is applied to a circuit group, traffic is first limited according to any metering or policing policy applied to the member circuit. Subsequently, traffic is limited again according to any metering or policing policy applied to the circuit group.

Circuit group members can have child circuits configured under them. The following apply to circuit group membership:

When a circuit with children is assigned circuit-group membership, those child circuits remain associated with their parent and are subject to QoS inheritance of any QoS policies applied to the circuit group or the member circuit itself. However, if the child circuit is itself assigned circuit-group membership, the QoS inheritance relationship with its parent circuit is broken and the child inherits from its own circuit group.

Counters values reported for the circuit group reflect the aggregate totals of all the members as well as their children.

Subscriber session circuits can be configured as direct members of a circuit group. You can configure the circuit-group-member command in the subscriber record, subscriber profile, or subscriber default configuration modes. In addition, a corresponding VSA (210, Circuit_Group_Member) is provided to allow configuration of circuit-group membership through RADIUS. The following apply to a subscriber session member of a circuit group:

For information about the circuit-group, circuit-group-member, and subscriber commands, see Command List. For information about VSA 210, see RADIUS Attributes.

1.4.1   Virtual Port Circuit Groups

The SmartEdge router supports virtual port circuit group (VPCGs, which allow you to partition circuits or link groups of ports that support PWFQ and have a line rate greater than 1 Gbps for collective scheduling. You can use a VPCG to divide a high-speed port's traffic into multiple, lower-bandwidth scheduling domains. You can assign a circuit to a virtual port by making the circuit a member of the VPCG.

The SmartEdge router supports the following methods of VPCG assignment for virtual ports:

Note:  
With explicit assignment of VPCG for a subscriber session, the subscriber session inherits the queuing policy and any metering and policing policies configured under the VPCG.

The following applies to auto-assignment of circuit group membership:

  • Static circuits—Statically configured circuits, such as 802.1q PVCs, have their auto-assigned virtual-port membership reflected by the automatic addition of the circuit-group-member command to the router configuration.

    Static circuit types:

    • Implicit ranges—Each PVC in implicit PVC ranges (for example, 802.1q PVC 1 to 10) may independently be auto-assigned to a different VPCG.
    • Explicit ranges—All PVCs in an explicit PVC range (for example, 802.1q PVC explicit 1 to 10) are collectively auto-assigned to a single VPCG.
    • Transport ranges—All VLAN IDs in a transport PVC range (for example, 802.1q PVC transport 1 to 10) are collectively auto-assigned to a single VPCG.
  • Dynamic circuits—Dynamically configured circuits, such as subscribers and on-demand PVCs, do not have their auto-assigned VPCG membership reflected in the router configuration.

    Dynamic circuit types:

    • On-demand ranges (also called circuit creation on demand (CCOD))—Each PVC in an on-demand PVC range (for example, 802.1q PVC on-demand 1 to 10) can be auto-assigned independently to a different VPCG when the PVC is activated.
    • Subscriber sessions—Each applicable subscriber session can be auto-assigned independently to a different VPCG when the subscriber session is established or when a PWFQ policy binding is added to the subscriber (for example, through reauthentication, change of authorization (CoA), or the use of the policy-refresh command).
    Note:  
    Implicit, explicit, and on-demand range circuits create multiple circuits; transport range circuits do not.

The following applies to VPCGs:

The following applies to a child of a VPCG:

On affected ports and link-groups, a circuit must be associated with a VPCG either directly or through inheritance before the circuit can accept any of the following PWFQ configuration commands:

A VPCG supports all of the functionality of a homed circuit group, including:

The following configuration restrictions apply to VPCGs:

  • The qos rate minimum and qos weight commands are not supported.
  • Node groups are not supported. Node groups have been replaced by circuit-group membership for subscribers.
  • Economical access link aggregation group (LAG) is not supported.
  • L2TP Network Server (LNS) and Multilink PPP (MLPPP) subscribers support PWFQ on virtual-port cards. However, these subscribers do not support explicit or auto-assignment of VPCGs. Instead, the SmartEdge OS selects an appropriate VPCG based on the existing configuration.
  • On-demand 802.1q PVCs (for example, CCoD circuits) support PWFQ queuing, but rely on automatic VPCG assignment. Explicit VPCG assignment (for example, the circuit-group-member command) is currently not supported for CCoD circuits.

1.4.2   Nested Circuit Groups

A circuit group can belong to another circuit group. Use these nested circuit groups to configure hierarchical QoS. Members of child circuit groups are subject to QoS inheritance from both the child circuit group and its parent circuit group. If a parent circuit group is homed to a port or link group, its children circuit groups are implicitly homed to the same port or link group.

No limit is enforced on the number of nested levels. However, two to four is the practical range (including VPCGs).

To configure a nested circuit group, use the circuit-group command with the circuit-group-parent keyword. For information about the circuit-group and circuit-group-member commands, see Command List.

1.4.3   Inheritance for Circuit Group Members

Natural children and grandchildren of circuit-group members are subject to inheritance of inheritable QoS policy bindings or other attributes from their natural circuit parent in the SmartEdge OS hierarchy including the following:

Note:  
A circuit-group member that has no explicit queuing policy applied inherits the queues and scheduling policy of its parent port or link group.

The following QoS policy bindings are inheritable:

L3 hierarchical node bindings are implicitly inherited by any L2 nodes below them in the hierarchy. Inherited bindings are overridden by any binding of the same type configured on the circuit itself or on an intermediate ancestor.

1.5   802.3ad LAG Support

The SmartEdge OS supports QoS for 802.3ad LAGs as follows:

Note:  
Regardless of the type of LAG and whether QoS services are configured on the individual ports or LAG, QoS is enforced on a per-link basis. For example, if a policy specifying a maximum rate of 100 kbps is configured on the port or LAG, each active port in the LAG is individually rate-limited to 100 kbps, for a possible total throughput of 100 kpbs multiplied by the number of active ports.

See 802.3ad LAG Examples for examples of how to configure QoS on 802.3ad LAGs.

2   Configuration and Operations Tasks

Note:  
In this section, the command syntax in the task tables displays only the root command; for the complete command syntax, see Command List.

To configure circuits for QoS features, perform the tasks described in the following sections:

2.1   Configuration Guidelines

This section includes configuration guidelines that affect more than one command or a combination of commands:

2.2   Configure an ATM PVC for QoS

To configure an ATM PVC for QoS, perform the tasks described in the following sections:

2.2.1   Configure a PVC on a Second-Generation ATM OC Traffic Card

To configure an ATM PVC on a second-generation ATM OC traffic card, perform the tasks described in Table 11; enter all commands in ATM PVC configuration mode, unless otherwise noted.

Table 11    Configure a PVC on a Second-Generation ATM OC Traffic Card

Task

Root Command

Notes

For packets coming into the SmartEdge router, propagate the CLP bit to PD QoS priority values in ATM cells.

clpbit propagate qos from atm

Enter this command in ATM profile configuration mode.

For packets going out of the SmartEdge router, propagate PD QoS bits to the CLP bit in ATM cells.

clpbit propagate qos to atm

Enter this command in ATM profile configuration mode.

Attach a policing policy.

qos policy policing

 

Attach a metering policy.

qos policy metering

 

Optional. Specify the circuit rate, if different from the rate specified by the attached metering and policing policies.

rate circuit

You can specify rates for both inbound and outbound traffic.

Attach a scheduling policy to a PVC.(1)

qos policy queuing

Only ATMWFQ policies are supported; you can attach them only to PVCs.

(1)  An ATMWFQ policy cannot be attached to a PVC that is shaped as UBRe.


2.3   Configure an Ethernet Circuit for QoS

To configure a circuit on any Ethernet traffic card for QoS, including any version of a Gigabit Ethernet traffic card, perform the tasks described in the following sections:

2.3.1   Configure Any Ethernet, Fast Ethernet-Gigabit Ethernet, or Gigabit Ethernet Circuit for QoS

To configure an Ethernet, Fast Ethernet-Gigabit Ethernet, or Gigabit Ethernet (any version) port, 802.1Q tunnel, or 802.1Q PVC, perform the tasks described in Table 12; enter all commands in port or dot1Q PVC configuration mode, unless otherwise noted.

Table 12    Configure Any Ethernet, Fast Ethernet-Gigabit Ethernet, or Gigabit Ethernet Circuit for QoS

Task

Root Command

Notes

For packets coming into the SmartEdge router , translate Ethernet 802.1p priority bits to PD QoS and IP DSCP priority bits.

propagate qos from ethernet

Enter this command in dot1q profile configuration mode.


If you also configure a classification map under this command, the IP DSCP bits in the internal packet are not affected.

For packets going out of the SmartEdge router, propagate PD QoS priority bits to 802.1p priority bits.

propagate qos to ethernet

Enter this command in dot1q profile configuration mode.

Assign a PD QoS priority group to the port, tunnel, or PVC.

qos priority

The QoS bit setting for packets traveling across the ingress circuit is not changed by the PD QoS priority group assignment.


Not supported for CCOD ranges of 802.1q PVCs.

Attach an overhead profile to a port or an 802.1Q PVC.

qos profile overhead

 

Attach a policing policy to the port, tunnel, or PVC.


Optional. Enable policy ACL rule counters.

qos policy policing

You can use the acl-counters keyword to enable IPv4 or IPv6 rule counters for the policy (may impact router performance; use with caution).

Set the rate for outgoing traffic for a Gigabit Ethernet port.

qos rate

 

Attach a metering policy to a port, tunnel, or PVC.


Optional. Enable policy ACL rule counters.

qos policy metering

You can use the acl-counters keyword to enable IPv4 rule counters for the policy (may impact router performance; use with caution).

Attach a scheduling policy to a port, tunnel, or PVC.

qos policy queuing

Possible policy types are MDRR and PWFQ.(1)

Optional. Specify the circuit rate, if different from the rate specified by the attached metering and policing policies.

rate circuit

You can specify rates for both inbound and outbound traffic.


Not supported for CCOD ranges of 802.1q PVCs.

(1)  MDRR policies are supported only on 10GE circuits.


2.3.2   Configure a Traffic-Managed Port for Hierarchical Scheduling

Note:  
PWFQ policies are supported only on traffic-managed ports (and the 802.1Q tunnels, 802.1Q PVCs, and hierarchical nodes configured on them). You can attach the same or different PWFQ policies to a port, its 802.1Q tunnels, its PVCs, and its hierarchical nodes.

To configure a traffic-managed port and any 802.1Q tunnels and PVCs configured on it for hierarchical scheduling with a PWFQ policy, perform the tasks described in Table 13; enter all commands in port configuration mode, unless otherwise noted. For information about the dot1q pvc command (in port configuration mode), see Configuring Circuits.

Table 13    Configure a Traffic-Managed Port for Hierarchical Scheduling

Task

Root Command

Notes

Set the maximum and minimum rates for the port.

qos rate

You must specify the maximum rate; the minimum rate is optional.

Specify the scheduling algorithm for the port.

qos hierarchical mode strict

 

Attach a PWFQ policy to the port.

qos policy queuing

You can attach a policy to any or all 802.1Q tunnels and PVCs as well as the port.

Create one or more 802.1Q tunnels or PVCs and access dot1q PVC configuration mode.

dot1q pvc

 

Set the maximum and minimum rates for the tunnel or PVC.

qos rate

Enter this command in dot1q PVC configuration mode. You must specify the maximum rate; the minimum rate is optional. You cannot set a minimum rate if you also assign a relative weight to this PVC.

Assign a relative weight to this PVC.

qos weight

Enter this command in dot1q PVC configuration mode. You cannot assign a relative weight if you also set a minimum rate for this PVC.

Specify the scheduling algorithm for the tunnel or PVC.

qos hierarchical mode strict

Enter this command in dot1q PVC configuration mode.

Attach a PWFQ policy to the tunnel or PVC.

qos policy queuing

Enter this command in dot1q PVC configuration mode. You can attach a policy to any or all tunnels and PVCs, as well as the port.

2.3.3   Configure a Traffic-Managed Port for Hierarchical Nodes

To configure a traffic-managed port for hierarchical nodes, node groups, and attach PWFQ policies to them, perform the tasks described in Table 14; enter all commands in port configuration mode, unless otherwise noted.

Table 14    Configure a Traffic-Managed Port for Hierarchical Nodes

Task

Root Command

Notes

Set the maximum and minimum rates for the port.

qos rate

You must specify the maximum rate; the minimum rate is optional.

Specify the scheduling algorithm for the port.

qos hierarchical mode strict

 

Create one or more hierarchical node groups and access hierarchical node group configuration mode.

qos node-group

 

Set the maximum and minimum rates for the node groups.

qos rate

Enter this command in hierarchical node group configuration mode. You must specify the maximum rate; the minimum rate is optional. You cannot set a minimum rate if you also assign a relative weight to this node group.

Assign a relative weight to this node group.

qos weight

Enter this command in hierarchical node group configuration mode. You cannot assign a relative weight if you also set a minimum rate for this node group.

Specify the scheduling algorithm for the node groups.

qos hierarchical mode strict

Enter this command in hierarchical node group configuration mode. The mode need not be the same as the one you specify for the port.

Create one or more hierarchical nodes and access hierarchical node configuration mode.

qos node

Enter this command in hierarchical node group configuration mode.

Set the maximum and minimum rates for these nodes.

qos rate

Enter this command in hierarchical node configuration mode. You must specify the maximum rate; the minimum rate is optional. You cannot set a minimum rate if you also assign a relative weight to this node.

Assign a relative weight for these nodes.

qos weight

Enter this command in hierarchical node configuration mode. You cannot assign a relative weight if you also set a minimum rate for this node.

Specify the scheduling algorithm for these nodes.

qos hierarchical mode strict

Enter this command in hierarchical node configuration mode. The mode need not be the same as the one you specify for the port or node group.

Attach a PWFQ policy to these nodes.

qos policy queuing

Enter this command in hierarchical node configuration mode. The policy need not be the same as the one you attach to the port, tunnel, or PVC.

2.4   Configure a POS Circuit for QoS

To configure a circuit on a Packet over SONET/SDH (POS) traffic card for QoS, perform the tasks described in Table 15; enter all commands in port configuration mode.

Table 15    Configure a POS Circuit for QoS

Task

Root Command

Notes

Assign a PD QoS priority group.

qos priority

The QoS bit setting for packets traveling across the ingress circuit is not changed by the PD QoS priority group assignment.

Attach a policing policy.

qos policy policing

 

Attach a metering policy.

qos policy metering

 

Optional. Specify the circuit rate, if different from the rate specified by the attached metering and policing policies.

rate circuit

You can specify rates for both inbound and outbound traffic.

Attach a scheduling policy.

qos policy queuing

 

2.5   Configure Cross-Connected Circuits for QoS

To configure a cross-connected circuit for QoS, perform the tasks described in Table 16 in. You cannot attach a scheduling policy to a cross-connected circuit; only metering and policing policies are supported on either or both circuits.

Note:  
You can perform the tasks in Table 16 in any order.

Table 16    Configure a Cross-Connected Circuit for QoS

Step

Task

Root Command

Notes

1.

Configure the inbound circuit for QoS with one of the following tasks:

   
 

An inbound ATM PVC.

 

Perform the tasks in Table 11, but do not attach a scheduling policy.

 

An inbound 802.1Q PVC.

 

Perform the tasks in Table 13, but do not attach a scheduling policy.

2.

Configure the outbound circuit for QoS with one of the following tasks:

   
 

An outbound ATM PVC.

 

Perform the tasks in Table 11, but do not attach a scheduling policy.

 

An outbound 802.1Q PVC.

qos priority

Perform the tasks in Table 13, but do not attach a scheduling policy.

3.

Create the cross-connection between the inbound and outbound circuits.

xc

Enter this command in global configuration mode. For information about this command, see the Configuring Cross-Connections.

2.6   Configure a Subscriber Circuit for QoS

You configure a subscriber circuit (or an LNS subscriber session) for QoS by configuring the subscriber record or profile; to configure a subscriber record or profile and thus any circuit on which the subscriber session is created, perform one or more of the tasks described in Table 17; enter all commands in subscriber configuration mode unless otherwise noted.

Table 17    Configure a Subscriber Circuit for QoS

Task

Root Command

Notes

Create a reference to a hierarchical node.

qos node-reference

 

Attach a policing policy.

qos policy policing

 

Attach a metering policy.

qos policy metering

 

Optional. Specify the circuit rate, if different from the rate specified by the attached metering and policing policies.

rate circuit

You can specify rates for both inbound and outbound traffic.

Attach a scheduling policy.

qos policy queuing

Policy types include ATMWFQ, MDRR, and PWFQ. Only PWFQ policies are supported for LNS subscriber sessions.

Attach an overhead profile to a subscriber record.

qos profile overhead

Enter this command in port configuration mode.

2.7   Configure QoS Propagation (Optional)

To create and apply customized classification mappings for QoS bits, perform the tasks described in Table 18; enter all commands in class map configuration mode, unless otherwise noted.

Table 18    Configure QoS Propagation

Task

Root Command

Notes

Create a classification map.

qos hierarchical mode strict

Enter this command in global configuration mode.

Specify a set of default values for a classification map.

mapping-schema

 

Specify an initial PD value to assign to ATM packets with the specified CLP value.

atm to qos

 

Translate outgoing PD QoS priority values to ATM CLP values.

qos to atm

 

For incoming packets with the specified CLP value, determine the initial PD QoS priority value from the user priority bits in the 802.1p VLAN TCI field of the packet header value.

atm use-ethernet

 

For incoming packets with the specified CLP value, determine the initial PD QoS priority value from the IP ToS field of the packet header.

atm use-ip

 

Translate incoming Ethernet 802.1p values to PD QoS priority values.

ethernet to qos

 

Translate outgoing PD QoS priority values to Ethernet 802.1p values.

qos to ethernet

 

For 802.1Q transport PVCs, use the 802.1p value from either the outer PVC header or the inner PVC header to propagate PD QoS priority values to 802.1p values in outgoing packets.

propagate qos transport use-vlan-header

Enter this command in dot1q profile configuration mode.

For incoming packets with the specified 802.1p value, determine the initial PD QoS value from the DSCP value in the IP header rather than the 802.1p value.

ethernet use-ip

 

Translate incoming IP header DSCP values to PD QoS values.

ip to qos

 

Translate outgoing PD QoS values to IP header DSCP values.

qos to ip

 

For outgoing packets with the specified PD QoS value, determine the final header EXP or 802.1p value based on the IP header DSCP value rather than the PD QoS value.

qos use-ip

 

Translate incoming MPLS EXP values to PD QoS values.

mpls to qos

 

Translate outgoing PD QoS values to MPLS header EXP values.

qos to mpls

 

For incoming packets with the specified MPLS EXP priority label, use the encapsulated Ethernet packet’s 802.1p priority label to determine the PD QoS priority value for the packet.

mpls use-ethernet

 

For incoming packets with the specified EXP value, determine the initial PD QoS priority value from the IP header DSCP value rather than the EXP value.

mpls use-ip

 

For incoming MPLS EXP packets with an Ethernet VLAN header, specify the 802.1q-over-MPLS packets to examine for any header enclosed by the outer VLAN header.

propagate qos use-vlan-ethertype

Enter this command in MPLS router configuration mode.

For incoming MPLS packets, use the 802.1p value from the header of either the outer PVC header or the inner PVC for propagation from Ethernet to internal PD Qos classification values.

propagate qos use-vlan-header

Enter this command in MPLS router configuration mode.

Reference the classification map when configuring propagation.

propagate qos from ethernet propagate qos from ip propagate qos from l2tp propagate qos from mpls propagate qos to ethernet propagate qos to ip propagate qos to l2tp propagate qos to mpls

Specify the class-map class-map construct for this function.

2.8   Configure L2TP for QoS

To configure L2TP for QoS to propagate subscriber DSCP bits in the downstream direction, perform the tasks described in Table 19; enter all commands in L2TP peer configuration mode for the default peer.

Table 19    Configure L2TP for QoS in the Downstream Direction

Task

Root Command

Notes

For network packets the SmartEdge router sends to the LAC when the router is configured as an LNS, propagate the PD QoS priority bits to the outer DSCP value.

propagate qos to l2tp

 

For L2TP IP packets coming into the SmartEdge router when it is configured as a LAC, propagate the subscriber DSCP bits from the inner IP packet header to the PD QoS priority bits from the LNS for the subscriber IP packet.

propagate qos from subscriber

Specify the downstream keyword for this function.


To configure L2TP for QoS to propagate DSCP bits in the upstream direction, perform the tasks described in Table 20; enter all commands in L2TP peer configuration mode for the default peer.

Table 20    Configure L2TP for QoS in the Upstream Direction

Task

Root Command

Notes

For subscriber IP packets coming into the SmartEdge router when it is configured as a LAC, propagate the subscriber DSCP bits in the IP packet header to the PD QoS priority bits for the subscriber IP packet.

propagate qos from subscriber

Specify the upstream keyword for this function.

For network packets the SmartEdge router sends to the LNS when the router is configured as a LAC, propagate the PD QoS priority bits to the outer DSCP value.

propagate qos to l2tp

 

For L2TP packets coming into the SmartEdge router when it is configured as an LNS, after the outer DSCP bits have been propagated to the PD QoS priority bits, propagate the PD bits to the subscriber’s inner DSCP bits.

propagate qos from l2tp

 

For L2TP packets coming into the SmartEdge router when it is configured as an LNS, customize the default mapping from the outer IP header DSCP value to the PD QoS priority value, leaving the inner IP header DSCP value unmodified.

propagate qos from l2tp

Specify the optional class-map parameter.


2.9   Configure MPLS for QoS

To configure MPLS for QoS, perform the tasks described in one of the following sections:

2.9.1   Propagate QoS Using DSCP Bits and MPLS EXP Bits

To propagate QoS using DSCP bits to MPLS EXP bits (instead of DSCP bits) and vice versa, perform the tasks described in Table 21; enter either or both commands in MPLS router configuration mode.

Table 21    Propagate QoS Using DSCP Bits and MPLS EXP Bits

Task

Root Command

Notes

For packets coming into the SmartEdge router, propagate MPLS EXP bits to PD QoS priority and IP DSCP bits.

propagate qos from mpls

If you also configure a classification map, a custom value mapping is used to map MPLS EXP bits to PD QoS priority values. The DSCP bits are unaffected.

For packets going out of the SmartEdge router, propagate PD QoS priority values to MPLS EXP bits.

propagate qos to mpls

 

2.9.2   Propagate QoS Using DSCP Bits Only

To propagate QoS by enabling the use of DSCP bits (instead of MPLS EXP bits) only, perform the task described in Table 22.

Table 22    Propagate QoS Using DSCP Bits Only

Task

Root Command

Notes

Enable the use of IP header DSCP bits (not MPLS EXP values) when determining the initial PD priority value of incoming MPLS packets.

egress prefer dscp-qos

Enter this command in MPLS router configuration mode.


2.10   Attach QoS Policies to a Circuit Group and Assign Members to the Group

To create a circuit group, attach a QoS metering, policing or scheduling policy to it, and then assign members to the group, perform the tasks described in Table 23.

Table 23    Attach QoS Policies to a Circuit Group and Assign Members to the Group

Step

Task

Root Command

Notes

1.

Create a circuit group and assign a specified name to it.

circuit group

Enter this command in global configuration mode. For information about this command, see Configuring Circuits.

2.

Attach a (QoS) metering, policing, or scheduling policy to the circuit group.

   
 

Attach a metering policy.

qos policy metering

Enter this command in dot1q PVC configuration mode.

 

Attach a policing policy.

qos policy policing

Enter this command in dot1q PVC configuration mode.

 

Attach a queuing policy.

qos policy queuing

Enter this command in dot1q PVC configuration mode.

3.

Select an Ethernet port in which the members of the circuit group are to reside and access port configuration mode.

port ethernet

Enter this command in global configuration mode.

4.

Specify the use of 802.1Q encapsulation for the Ethernet port.

encapsulation dot1q

Enter this command in port configuration mode.

5.

Specify the 802.1Q tunnel or one or more static 802.1Q PVCs to be assigned to the specified circuit group and access dot1q PVC configuration mode.

dot1q pvc

Enter this command in port configuration mode.

6.

Specify that the 802.1Q tunnel or PVCs being configured are members of the specified circuit group.

circuit-group-member

Enter this command in dot1q PVC configuration mode. For information about this command, see Configuring Circuits.


2.11   Configuring Virtual Port Circuit Groups

For information on how to configure VPCGs, see Configuring VPCGs.

2.12   Configure Nested Circuit Groups

To configure nested circuit groups, perform the tasks described in Table 24; enter the commands in the specified configuration modes. It is assumed you have configured the QoS policies before performing the tasks in Table 24.

Note:  
No limit on the number of nested levels is enforced. However, two to four is the practical range.

Table 24    Configure Nested Circuit Groups

Step

Task

Root Command

Notes

1.

Define a circuit group and specify a port on which all circuits in this circuit group reside. This is the parent circuit group.

circuit group

Enter this command in global configuration mode.

2.

Optional. Attach QoS policies, QoS overhead profiles, rate, or weight to the circuit group and its members.

Enter commands in circuit-group configuration mode.

3.

Define a circuit group, specify a parent circuit group, and specify a port on which all circuits in this circuit group reside.

circuit group

Enter this command in global configuration mode. Use the parent-circuit-group keyword to specify the parent circuit group from which all circuits in this group are subject to inheritance from.


2.13   Configure Ingress Port Propagation

To configure ingress port propagation for cards that support differentiated packet treatment for ingress oversubscription scenarios, perform the tasks described in Table 25.

Table 25    Configure Ingress Port Propagation

Step

Task

Root Command

Notes

1.

Configure a card and access card configuration mode.

card

Enter this command in global configuration mode.

2.

Select an Ethernet port to apply ingress port propagation and access port configuration mode.

port ethernet

Enter this command in global configuration mode.

3.

For incoming packets, configure ingress port propagation. Perform the following steps:

 

Enter the port-propagate commands in port configuration mode.

 

Propagate Ethernet 802.1p user priority bits to PD QoS priority bits and use the 802.1p bits to determine ingress oversubscription treatment for incoming packets.

port-propagate qos from ethernet

 
 

Propagate IP DSCP bits to the PD QoS priority bits and use DSCP bits to determine ingress oversubscription treatment for incoming packets.

port-propagate qos from ip

 
 

Propagate MPLS EXP bits to PD QoS bits and use EXP bits to determine ingress oversubscription treatment for incoming packets.

port-propagate qos from mpls

 

2.14   Operations Tasks

To monitor and administer QoS features, perform the appropriate tasks described in Table 26. Enter the debug command in exec mode; enter the show commands in any mode.

You can enable policy ACL rule counters using the acl-counters keyword with the qos policy policing, qos policy metering, and qos policy queueing commands.


 Warning! 
Enabling IP filtering and policy ACL counters can impact router performance. Use them carefully.
Table 26    Monitor and Administer QoS Features

Task

Command

 

Enable the generation of QoS debug messages.

debug qos

 

Display information about ACLs attached to QoS policies.

show access-group

If you have enabled counters for a subscriber, use the show access group ipv6 qos cct-handle in count construct to view traffic flow. Enter the command twice, two to three minutes apart to view incremented counters.


The cct-handle (in the format slot/port:ch:sub:[subsub]) is the subscriber circuit where the counters where enabled.

Display cell and SAR packet-level counters for configured ATM PVCs.

show atm counters

 

Display general counters and counters specific to the circuit type for one or more circuits in the system.

show circuit counters

 

Display the current QoS configuration.

show configuration qos

 

Display the information for a particular circuit that matches the specified circuit agent ID.

show qos agent-circuit-id

 

Display the information for all circuits or a particular circuit in the system.

show qos circuit

 

Display QoS PPA client information.

show qos client

 

Display QoS hierarchical node information.

show qos h-node

 

Display QoS daemon memory usage information.

show qos memory

 

Display information for all QoS policies.

show qos policy

 

Display the circuit information for a specific subscriber on the system.

show qos username

 

Display information about one or more QoS metering policies.

show qos policy metering

 

Display information about one or more QoS policing policies.

show qos policy policing

 

Display active QoS port bindings for ports on one or more traffic cards.

show qos port-map bind

 

3   Configuration Examples

This section provides examples of QoS configurations for attaching rate- and class-limiting policies, attaching scheduling policies, and propagating QoS.

3.1   Attaching Rate- and Class-Limiting Policies

Examples of configuring PVCs and subscriber records for QoS policies are provided in the following sections:

3.1.1   PVC Configuration

The following example attaches a metering policy, meter, to an 802.1Q PVC on an Ethernet port:

[local]Redback(config)#port ethernet 4/2
[local]Redback(config-port)#encapsulation dot1q
[local]Redback(config-port)#dot1q pvc 200
[local]Redback(config-dot1q-pvc)#bind interface if-200 local
[local]Redback(config-dot1q-pvc)#qos policy metering meter

3.1.2   Cross-Connected Circuit Configuration

The following example attaches a metering policy, output, to the inbound circuits of cross-connected 802.1Q PVCs on Ethernet ports:

[local]Redback(config)#port ethernet 4/1
[local]Redback(config-port)#encapsulation dot1q
[local]Redback(config-port)#dot1q pvc 2001
[local]Redback(config-dot1q-pvc)#qos policy metering output
[local]Redback(config-dot1q-pvc)#exit
[local]Redback(config-port)#dot1q pvc 2051
[local]Redback(config-dot1q-pvc)#qos policy metering output
[local]Redback(config-dot1q-pvc)#exit
[local]Redback(config-port)#dot1q pvc 2101
[local]Redback(config-dot1q-pvc)#qos policy metering output
[local]Redback(config-dot1q-pvc)#exit
!
[local]Redback(config)#port ethernet 4/1
[local]Redback(config-port)#encapsulation dot1q
[local]Redback(config-port)#dot1q pvc 2001
[local]Redback(config-dot1q-pvc)#exit
[local]Redback(config-port)#dot1q pvc 2051
[local]Redback(config-dot1q-pvc)#exit
[local]Redback(config-port)#dot1q pvc 2101
!
[local]Redback(config)#xc 4/1 vlan-id 2001 to 4/3 vlan-id 2001
[local]Redback(config)#xc 4/1 vlan-id 2051 to 4/3 vlan-id 2051
[local]Redback(config)#xc 4/1 vlan-id 2101 to 4/3 vlan-id 2101

3.1.3   Subscriber Configuration

The following example attaches a metering policy, meter, to a subscriber record:

[local]Redback(config)#subscriber name redback
[local]Redback(config-sub)#password redback
[local]Redback(config-sub)#qos policy metering meter

3.2   Attaching Scheduling Policies

Examples of configuring ports and PVCs for QoS features using scheduling policies are provided in the following sections:

3.2.1   Port Configuration

The following example attaches a queuing policy to a POS port:

[local]Redback(config)#port pos 2/1
[local]Redback(config-port)#qos policy queuing pos-qos

3.2.2   PVC Configuration

The following example attaches a scheduling policy to each of three 802.1Q PVCs:

[local]Redback(config)#port ethernet 4/1
[local]Redback(config-port)#encapsulation dot1q
[local]Redback(config-port)#dot1q pvc 100
[local]Redback(config-dot1q-pvc)#bind interface if-100 local
[local]Redback(config-dot1q-pvc)#qos policy queuing PerVcQueuing
[local]Redback(config-dot1q-pvc)#dot1q pvc 101
[local]Redback(config-dot1q-pvc)#bind interface if-101 local
[local]Redback(config-dot1q-pvc)#qos policy queuing PerVcQueuing
[local]Redback(config-dot1q-pvc)#dot1q pvc 102
[local]Redback(config-dot1q-pvc)#bind interface if-102 local
[local]Redback(config-dot1q-pvc)#qos policy queuing PerVcQueuing

3.2.3   Overhead Profile Configuration

The following example allows the child circuits of 802.1Q PVC 100 to inherit the example1 overhead profile:

[local]Redback(config)#port ethernet 2/1
[local]Redback(config-port)#dot1q pvc 100 encapsulation 1qtunnel
[local]Redback(config-port)#qos profile overhead example1 inherit

3.2.4   PWFQ Policy and Hierarchical Shaping

The following example configures a GE3 port with the home node group with 5 dslam nodes and attaches a PWFQ policy to each node:

[local]Redback(config)#port ethernet 5/2
[local]Redback(config-port)#qos rate maximum 100000000
[local]Redback(config-port)#qos rate minimum 100000
[local]Redback(config-port)#qos hierarchical mode strict
[local]Redback(config-port)#qos node-group home 1
[local]Redback(config-h-node)#qos node dslam 1 through 5
[local]Redback(config-h-node)#qos policy queuing pwfq4

3.2.5   PWFQ Policy and Hierarchical Scheduling

The following example configures a GE3 port and its 802.1Q PVC for hierarchical scheduling and attaches a PWFQ policy to both the port (pwfq-port) and its PVC (pwfq-pvc):

[local]Redback(config)#port ethernet 5/1
[local]Redback(config-port)#encapsulation dot1q
[local]Redback(config-port)#qos rate maximum 100000000
[local]Redback(config-port)#qos rate minimum 100000
[local]Redback(config-port)#qos hierarchical mode strict
[local]Redback(config-port)#qos policy queuing pwfq-port
[local]Redback(config-port)#dot1q pvc 200
[local]Redback(config-dot1q-pvc)#qos rate maximum 10000000
[local]Redback(config-dot1q-pvc)#qos rate minimum 10000
[local]Redback(config-dot1q-pvc)#qos policy queuing pwfq-pvc

3.3   Propagating QoS

The following example configures 802.1q profile, 8021q-on, to propagate QoS information from incoming packets to outgoing packets in any 802.1Q tunnel or PVC that has that profile assigned to it:

[local]Redback(config)#dot1q profile 8201p-on
[local]Redback(config-dot1q-profile)#propagate qos from ethernet
[local]Redback(config-dot1q-profile)#propagate qos to ethernet
[local]Redback(config-dot1q-profile)#exit

The following example propagates QoS priority markings on an 802.1Q PVC by configuring it with the 8021p-on profile:

[local]Redback(config)#port ethernet 3/1
[local]Redback(config-port)#encapsulation dot1q
[local]Redback(config-port)#dot1q pvc 20 profile 8021p-on
[local]Redback(config-dot1q-pvc)#exit

The following example maps control protocols, including VRRP advertisements, to an 802.1p priority value of 3. Control packets are always assigned an internal ToS priority of 6 (that is, CS6), so this example maps priority CS6 to a p bit of 3:

[local]Redback(config)#qos class-map pd-to-8021p ethernet out
[local]Redback(config-class-map)#qos cs6 to ethernet 3
[local]Redback(config-class-map)#exit
[local]Redback(config)#dot1q profile 8201p-on
[local]Redback(config-dot1q-profile)#propagate qos to ethernet class-map pd-to-8021p
[local]Redback(config-dot1q-profile)#exit
[local]Redback(config)#port ethernet 1/1
[local]Redback(config-port)#no shutdown
[local]Redback(config-port)#encapsulation dot1q
[local]Redback(config-port)#dot1q pvc 100 profile 8021p-on
[local]Redback(config-dot1q-pvc)#bind interface test local
[local]Redback(config-dot1q-pvc)#exit

The following example enables IP QoS information to be propagated to ATM on any ATM PVC or virtual path (VP) that has the profile, clp-on, assigned to it:

[local]Redback(config)#atm profile clp-on
[local]Redback(config-atm-profile)#clpbit propagate qos to atm
[local]Redback(config-atm-profile)#exit

The following example configures MPLS to propagate QoS priority markings in both directions:

[local]Redback(config)#context local
[local]Redback(config-ctx)#router mpls
[local]Redback(config-mpls)#propagate qos from mpls
[local]Redback(config-mpls)#propagate qos to mpls
[local]Redback(config-mpls)#exit

The following example creates a classification map exp-to-pd that maps MPLS experimental EXP values to QoS PD values on ingress, then applies the classification map to the propagate qos from mpls command:

[local]Redback(config)#qos class-map exp-to-pd mpls in
[local]Redback(config-class-map)#mapping-schema 7P1D
[local]Redback(config-class-map)#mpls 1 to qos 0x24
[local]Redback(config-class-map)#exit
[local]Redback(config)#context mycontext
[local]Redback(config-ctx)#router mpls
[local]Redback(config-mpls)#propagate qos from mpls class-map exp-to-dscp
[local]Redback(config-mpls)#exit

The following example shows how to propagate Ethernet 802.1p user priority bits, IP DSCP bits, and MPLS EXP bits to PD QoS priority bits for incoming packets arriving in slot 10, port 1 of an Ethernet port and to use these bits to determine ingress oversubscription treatment. This configuration is applied to a 4-port 10GE card that is in slot 10 of the chassis:

[local]Redback(config)#card 10ge-4-port 10
[local]Redback(config)#port ethernet 10/1
[local]Redback(config-port)#port-propagate qos from ip
[local]Redback(config-port)#port-propagate qos from ethernet
[local]Redback(config-port)#port-propagate qos from mpls

3.4   Attaching QoS Policies to Circuit Groups

The following example shows how to create a circuit group salesgroup and attach previously configured policing and metering policies (group_policing_policy and group_metering_policy ) to this circuit group. This example also shows how to assign the 802.1Q PVC tunnels (50 through 60, 30, and 40) as members of the circuit group. The individual PVCs (or VLANs), 1 to 100, configured under the 802.1Q tunnel 30cvlan_individual_policy. With the hierarchical keyword configured for the policing policy ( each have their own individual policing policy specified as group_metering_policy ), the traffic on the individual PVCs are subject to both the child circuit policy (cvlan_individual_policy ) and the parent circuit policy (group_metering_policy ):

[local]Redback(config)#circuit-group salesgroup
[local]Redback(config-circuit-group)#qos policy policing group_policing_policy hierarchical
[local]Redback(config-circuit-group)#qos policy metering group_metering_policy inherit
[local]Redback(config)#port ethernet 12/1
[local]Redback(config-port)#encapsulation dot1q
[local]Redback(config-port)#dot1q pvc 50 through 60
[local]Redback(config-dot1q-pvc)#circuit-group-member salesgroup
[local]Redback(config)#port ethernet 12/2
[local]Redback(config-port)#encapsulation dot1q
[local]Redback(config-port)#dot1q pvc 30 encapsulation 1qtunnel
[local]Redback(config-dot1q-pvc)#dot1q pvc 30:1 through 100
[local]Redback(config-dot1q-pvc)#circuit-group-member salesgroup
! Specify that each 802.1Q PVC configured under the 802.1Q tunnel also
! has its own individual policing policy (specified as
! cvlan_individual_policy).
[local]Redback(config-dot1q-pvc)#qos policy policing cvlan_individual_policy
[local]Redback(config-dot1q-pvc)#dot1q pvc 40
[local]Redback(config-dot1q-pvc)#circuit-group-member salesgroup

3.5   QoS on 802.3ad LAGs

This section provides examples for configuring QoS on Ethernet, dot1q, and access LAGs.

3.5.1   Example: Provision QoS on an Ethernet LAG

The following example shows how to provision QoS policies on an Ethernet LAG. Note that for an Ethernet LAG, QoS service is configured on each independent constituent port within the LAG (in this example, there are two ports in the LAG called ETHER_EXAMPLE).

! Create the LAG and bind it to an interface:
[local]rock1200#configure
[local]rock1200(config)#link-group ETHER_EXAMPLE ether
[local]rock1200(config-link-group)#bind interface LINKG_GROUP local
[local]rock1200(config-link-group)#end


! Add the first port to the LAG and configure QoS policies on that port:
[local]rock1200#configure
[local]rock1200(config)#port ethernet 1/1
[local]rock1200(config-port)#link-group ETHER_EXAMPLE
[local]rock1200(config-port)#qos policy metering meter_policy
[local]rock1200(config-port)#qos policy policing policing_policy
[local]rock1200(config-port)#qos policy queuing queuing_policy
[local]rock1200(config-port)#end


! Add the second port to the LAG and configure QoS policies on that port:
[local]rock1200#configure
[local]rock1200(config)#port ethernet 2/1
[local]rock1200(config-port)#link-group ETHER_EXAMPLE
[local]rock1200(config-port)#qos policy metering meter_policy
[local]rock1200(config-port)#qos policy policing policing_policy
[local]rock1200(config-port)#qos policy queuing queuing_policy
[local]rock1200(config-port)#end

3.5.2   Example: Provision QoS on a Dot1q LAG

The following example shows how to provision QoS policies on a dot1q LAG. For dot1q LAGS, QoS service is configured on each independent constituent port within the dot1q LAG. All dot1q PVCs within the LAG automatically inherit the queuing policy, while metering and policing policies are applied to the PVCs only if the inherit keyword is included in the qos policy command syntax.

!Create a LAG that has two PVCs, and bind each PVC to an interface:
[local]rock1200#configure
[local]rock1200(config)#link-group DOT1Q_EXAMPLE dot1q
[local]rock1200(config-link-group)#dot1q pvc 1
[local]rock1200(config-link-pvc)#bind interface PVC_1 local
[local]rock1200(config-link-pvc)#exit
[local]rock1200(config-link-group)#dot1q pvc 2
[local]rock1200(config-link-pvc)#bind interface PVC_2 local
[local]rock1200(config-link-pvc)#end


! Add the first port to the LAG and configure QoS policies on that port:
[local]rock1200#configure
[local]rock1200(config)#port ethernet 1/2
[local]rock1200(config-port)#link-group DOT1Q_EXAMPLE
[local]rock1200(config-port)#qos policy metering meter_policy inherit
[local]rock1200(config-port)#qos policy policing policing_policy inherit
[local]rock1200(config-port)#qos policy queuing queuing_policy
[local]rock1200(config-port)#end

! Add the second  port to the LAG and configure QoS policies on that port:
[local]rock1200#configure
[local]rock1200(config)#port ethernet 2/2
[local]rock1200(config-port)#link-group DOT1Q_EXAMPLE
[local]rock1200(config-port)#qos policy metering meter_policy inherit
[local]rock1200(config-port)#qos policy policing policing_policy inherit
[local]rock1200(config-port)#qos policy queuing queuing_policy
[local]rock1200(config-port)#end

3.5.3   Example: Provision QoS on an Access LAG

The following example shows how to provision QoS policies on an access LAG. For access LAGs, QoS policies are applied to the LAG itself or to the individual PVCs or subscribers configured under the LAG.

! Create a LAG that has three PVCs. Configure QoS policies on each PVC, and bind each PVC to an interface. 
[local]rock1200#configure
[local]rock1200(config)#link-group ACCESS_EXAMPLE access
[local]rock1200(config-link-group)#encapsulation dot1q
[local]rock1200(config-link-group)#qos policy queuing queuing_policy
[local]rock1200(config-link-group)#dot1q pvc 1
[local]rock1200(config-dot1q-pvc)#qos policy metering meter_policy
[local]rock1200(config-dot1q-pvc)#bind interface PVC_1 local
[local]rock1200(config-dot1q-pvc)#exit
[local]rock1200(config-link-group)#dot1q pvc 2 encapsulation 1qtunnel
[local]rock1200(config-dot1q-pvc)#qos policy policing policing_policy inherit
[local]rock1200(config-dot1q-pvc)#exit
[local]rock1200(config-link-group)#dot1q pvc 2:1
[local]rock1200(config-dot1q-pvc)#qos policy metering meter_policy
[local]rock1200(config-link-pvc)#bind interface PVC_2 local
[local]rock1200(config-dot1q-pvc)#exit
[local]rock1200(config-link-group)#dot1q pvc 2:2
[local]rock1200(config-dot1q-pvc)#qos policy metering meter_policy inherit
[local]rock1200(config-link-pvc)#bind authentication pap chap local
[local]rock1200(config-link-pvc)#end

! Configure the first port with dot1q encapsulation and add it to the LAG:
[local]rock1200#configure
[local]rock1200(config)#port ethernet 1/3
[local]rock1200(config-port)#encapsulation dot1q
[local]rock1200(config-port)#link-group ACCESS_EXAMPLE
[local]rock1200(config-port)#end  
  
! Configure the second port with dot1q encapsulation and add it to the LAG:
[local]rock1200#configure
[local]rock1200(config)#port ethernet 2/3
[local]rock1200(config-port)#encapsulation dot1q
[local]rock1200(config-port)#link-group ACCESS_EXAMPLE
[local]rock1200(config-port)#end