Contents

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.

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

• Configuring Rate-Limiting and Class-Limiting—Rate- and class-limiting features (metering and policing policies)
• Configuring Queuing and Scheduling—Queuing and scheduling features (queuing policies (also known as scheduling policies))

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:

• 802.1Q PVC or tunnel from a parent Ethernet port or access link group
• 802.1Q PVC from a parent 802.1Q tunnel
• PPPoE and CLIPs sessions from a parent 802.1Q PVC, port, or access link group
• PPP and PPPoE sessions from a parent ATM PVC.
• Circuit-group members and their children from a circuit-group

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.

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):

• The PD QoS priority value can be set from 0 to 7, where 0 receives the highest priority treatment by default and 7 the lowest.
• The PD QoS drop precedence value can be set from 0 to 7, where 0 receives the highest chance of being dropped by default and 7 the lowest chance.

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:

• Layer 3 (IP-routed) circuits—The upper six bits of the IP Differentiated Services Code Point (DSCP) or type of service (TOS) setting is copied to PD QoS Code Point; see Table 2.
• MPLS circuits—The EXP value from the relevant received MPLS label is translated to the upper three bits of PD QoS priority and the lower three bits of the PD QoS drop precedence bits are set to zero; see Table 3.
• Other non-IP-routed circuits—The upper three priority bits from the incoming packet are translated to the PD QoS priority (lowest priority value) and the lower three bits are translated to the PD QoS drop precedence (to zero). For example, for the default translation for 802.1Q VLAN circuits, see Table 4.

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.

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

• qos priority command
• qos propagate from ip, ethernet, mpls, atm, and l2tp commands
• Ingress class maps
• mark priority command and its conform, exceed, and violate variants
• mark dscp command and it's conform, exceed, and violate variants
• mark precedence command and its conform, exceed, and violate variants

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

• qos propagate to ip, ethernet, mpls, atm, and l2tp commands
• Egress class maps
• Class definitions
• Congestion avoidance maps
• Queue-maps (priority only)
• exceed drop command
• qos-priority and its metering or policing action (priority only)

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.

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.

3. 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.
4. 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.
5. 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.

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.

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:

• Specifying to copy the upper three EXP bits to the DSCP bits in the IP header (and clear the lower three bits) using the propagate qos from mpls command without the class-map map-name construct (in MPLS router configuration mode).
• Specifying a custom mapping using the propagate qos from mpls command with the class-map map-name construct.
• Specifying to copy the IP header DSCP value to the PD QoS priority value using the egress prefer dscp-qos command (in MPLS router configuration mode).

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.

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

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.

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:

• port-propagate qos from ethernet [class-map map-name]
• port-propagate qos from ip [class-map map-name]
• port-propagate qos from mpls [class-map map-name]

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.

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.

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:

• Ingress queue admittance priority 0 (highest)—100%
• Ingress queue admittance priority 1—90%
• Ingress queue admittance priority 2—80%
• Ingress queue admittance priority 3 (lowest)—70%

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.

(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.

(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.

1.4.1   Virtual Port Circuit Groups

• Explicit assignment using standard manual provisioning with the circuit-group-member command or with VSA 210 (Circuit_Group_Member). For more information about the circuit-group-member command, see circuit-group-member. For information about VSA 210, see RADIUS Attributes.

• Inheritance of VPCG membership. A circuit configured as an intermediate QoS scheduling node (L3 node) or with a PWFQ policy binding (L2 node) that does not have an explicit VPCG membership will inherit the virtual-port assignment and be added to the virtual port's scheduling tree under the nearest circuit above it in the QoS inheritance hierarchy (see Circuit Configuration with QoS Policies) with an existing VPCG association (explicit, inherited, or auto-assigned). If there is no such circuit with VPCG membership in the hierarchy above, auto-assignment will be performed for the circuit (see next method).
• Auto-assignment based on TM configuration. If a circuit on a port or link group that requires virtual-port scheduling is provisioned for PWFQ (using one of the supported PWFQ configuration commands), and it does not have an explicit or inherited virtual-port assignment, the circuit is automatically assigned to one of the existing VPCGs configured for that port or link group.

  Affected circuits are assigned to one of the available VPCGs based on a round robin selection of the currently available groups configured for the applicable port or access link group.

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

The following QoS policy bindings are inheritable:

• Queuing policy bindings.
• Overhead profile bindings.
• Metering and policing bindings configured with the inherit or hierarchical keyword.

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:

• Ethernet LAGs support any QoS policy (policing, metering, queuing, forward) that is supported by the constituent ports. To provision and operate a QoS policy for an Ethernet LAG, configure the QoS service on each independent constituent port.
• Dot1q LAGs support any QoS policy (policing, metering, queuing, forward) that is supported by the constituent ports. To provision and operate a QOS policy for a dot1q LAG, configure the QoS service on each independent constituent port. All dot1q PVCs configured under the LAG automatically inherit the queuing policy. Use the qos policy policing command with the inherit keyword to apply metering and policing policies to the PVCs.

  Note:  

  You cannot specify individual or customized QoS for individual dot1q PVCs. QoS policies and rates that are applied to the ports also apply to all traffic under the aggregate port. You cannot apply a forward policy to the PVCs because forward policies do not support inheritance. You cannot configure 802.1p-based QoS propagation for the PVCs because the propagate qos from ethernet and propagate qos to ethernet commands are specified in dot1q profiles that cannot be applied to the PVCs configured under the dot1q LAG.

  
  
• Inheritable QoS attributes applied to constituent ports of a link group are inherited by and applied to the aggregate PVCs defined under the link group.
• Access LAGs support any QoS policing, metering, PWFQ, MDRR, or forward policy supported by the constituent ports. You can provision and operate a QoS policy for the LAG or its subordinate PVCs and subscribers. You can apply QoS policies to the LAG configuration object itself, the individual PVCs, or subscribers configured under the LAG.

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:

• If you attach a modified deficit round-robin (MDRR) policy to a PVC, you must also attach it to the port on which you have configured the PVC.
• The following guidelines apply to cross-connected circuits:
  • When you attach a QoS metering or policing policy to a cross-connected circuit, you can attach a policy to each individual circuit before or after you make the cross-connection.
  • You can attach a different metering or policing policy to each circuit.
  • You can attach both a metering and a policing policy to each circuit.
• The following guidelines apply to Ethernet and 802.1Q link groups:
  • You attach a policy to an Ethernet port rather than the link group of which it is a member; you attach the policy using one of the QoS policy commands (qos policy metering, qos policy policing, qos policy queuing) in port configuration mode.
  • You can attach any type of QoS policy that is supported by that type of Ethernet port. These include metering, policing, MDRR, and PWFQ policies. However, to preserve the operational characteristics of a link group, attach the same set of policies (metering, policing, and scheduling) to every constituent port in the link group.

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.

(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.

(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.

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.

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.

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.

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.

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.

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.

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.

2.9   Configure MPLS for QoS

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

• Propagate QoS Using DSCP Bits and MPLS EXP Bits
• Propagate QoS Using DSCP Bits Only

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.

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.

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.

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.

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.

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.

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