Overview

Typically, networks operate on a best-effort delivery basis, which means that all traffic has equal priority and an equal chance of being delivered in a timely manner. When congestion occurs, all traffic has an equal chance of being dropped.

Note Cisco IOS Release 12.2SX does not support all of the MQC features (for example, Committed Access Rate (CAR)) for traffic that is Layer 3 switched or Layer 2 switched in hardware. Because queuing is implemented in the port ASICs, Cisco IOS Release 12.2SX does not support MQC-configured queuing.

–Port trust state—In PFC QoS, trust means to accept as valid and use as the basis of the initial internal DSCP value. Ports are untrusted by default, which sets the initial internal DSCP value to zero. You can configure ports to trust one of three types of received QoS values: CoS, IP precedence, or DSCP.

–Congestion avoidance—If you configure an Ethernet LAN port to trust CoS or DSCP, QoS classifies the traffic on the basis of its Layer 2 CoS value or its Layer 3 DSCP value and assigns it to an ingress queue to provide congestion avoidance. Layer 3 DSCP-based queue mapping is available only on WS-X6708-10GE, WS-X6716-10GE, WS-X6716-10T, and Supervisor Engine 720-10GE ports.

2. PFC and DFC QoS features:

–Internal DSCP—On the PFC and DFCs, QoS associates an internal DSCP value with all traffic to classify it for processing through the system. There is an initial internal DSCP based on the traffic trust state and a final internal DSCP. The final internal DSCP can be the same as the initial value or an MQC policy map can set it to a different value.

–MQC policy maps—MQC policy maps can do one or more of these operations:

—Change the trust state of the traffic (bases the internal DSCP value on a different QoS label)

Port Trust

In PFC QoS, trust means to accept as valid and use as the basis of the initial internal DSCP value. You can configure ports as untrusted or you can configure them to trust these QoS values:

•Layer 2 CoS

–A port configured to trust CoS is called a trust CoS port.

–Traffic received through a trust CoS port or configured by a policy map to trust CoS is called trust CoS traffic.

Note Not all traffic carries a CoS value. Only ISL, 802.1Q, and 802.1P traffic carries a CoS value. PFC QoS applies the port CoS value to any traffic that does not carry a CoS value. On untrusted ports, PFC QoS applies the port CoS value to all traffic, overwriting any received CoS value.

–Traffic received through a trust IP precedence port or configured by a policy map to trust IP precedence is called trust IP precedence traffic.

•DSCP

–A port configured to trust DSCP is called a trust DSCP port.

–Traffic received through a trust DSCP port or configured by a policy map to trust DSCP is called trust DSCP traffic.

Traffic received through an untrusted port is called untrusted traffic.

Ingress Congestion Avoidance

PFC QoS implements congestion avoidance on trust CoS ports. On a trust CoS port, QoS classifies the traffic on the basis of its Layer 2 CoS value and assigns it to an ingress queue to provide congestion avoidance. You can configure WS-X6708-10GE, WS-X6716-10GE, WS-X6716-10T, and Supervisor Engine 720-10GE trust DSCP ports to use received DSCP values for congestion avoidance. See the "Ingress Classification and Marking at Trust CoS LAN Ports" section for more information about ingress congestion avoidance.

Supported Policy Feature Cards

The policy feature card (PFC) is a daughter card on the supervisor engine. The PFC provides QoS in addition to other functionality. The following PFCs are supported in Cisco IOS Release 12.2SX:

•PFC3A on the Supervisor Engine 720

•PFC3B on the Supervisor Engine 720 and Supervisor Engine 32

•PFC3BXL on the Supervisor Engine 720

•PFC3C on the Cisco ME 6500 Series Ethernet switches and the Supervisor Engine 720-10GE

•PFC3CXL on the Supervisor Engine 720-10GE

Supported Distributed Forwarding Cards

The PFC sends a copy of the QoS policies to the distributed forwarding card (DFC) to provide local support for the QoS policies, which enables the DFCs to support the same QoS features that the PFC supports.

These DFCs are supported on the Catalyst 6500 series switches:

•For use on dCEF256 and CEF256 modules with a Supervisor Engine 720:

–WS-F6K-DFC3A

–WS-F6K-DFC3B

–WS-F6K-DFC3BXL

•For use on CEF720 modules with a Supervisor Engine 720:

–WS-F6700-DFC3A

–WS-F6700-DFC3B

–WS-F6700-DFC3BXL

•For use on CEF720 modules with Supervisor Engine 720 and Supervisor Engine 720-10GE:

–WS-F6700-DFC3CXL

–WS-F6700-DFC3C

PFC and DFC QoS Feature List and Flowchart

Table 43-1 lists the QoS features supported on the different versions of PFCs and DFCs.

Note For trust CoS traffic, when ignore port trust is enabled, PFC QoS does not use the received CoS value in tagged IP traffic. When ignore port trust is disabled, PFC QoS uses the received CoS value in tagged IP traffic.

Policy marking and policing on the PFC can change the initial internal DSCP value to a final internal DSCP value, which is then used for all subsequently applied QoS features.

Port-Based PFC QoS and VLAN-Based PFC QoS

You can configure each ingress LAN port for either physical port-based PFC QoS (default) or VLAN-based PFC QoS and attach a policy map to the selected interface.

On ports configured for port-based PFC QoS, you can attach a policy map to the ingress LAN port as follows:

•On a nontrunk ingress LAN port configured for port-based PFC QoS, all traffic received through the port is subject to the policy map attached to the port.

•On a trunking ingress LAN port configured for port-based PFC QoS, traffic in all VLANs received through the port is subject to the policy map attached to the port.

On a nontrunk ingress LAN port configured for VLAN-based PFC QoS, traffic received through the port is subject to the policy map attached to the port's VLAN.

On a trunking ingress LAN port configured for VLAN-based PFC QoS, traffic received through the port is subject to the policy map attached to the traffic's VLAN.

Session-Based PFC QoS

In Cisco IOS Software Release 12.2(33)SXI and later releases, you can configure the dynamic delivery of a policy map to an interface by the AAA server when a user authenticates on that interface. This feature allows per-user or per-session QoS at the interface level, so that a user who connects by different interfaces at different times will always receive the same QoS treatment.

For each user of session-based QoS, you must set these attribute-value (AV) pairs on the AAA server by using RADIUS cisco-av-pair vendor-specific attributes (VSAs):

•cisco-avpair = "ip:sub-policy-In=in_policy_name"

•cisco-avpair = "ip:sub-policy-Out=out_policy_name"

The in_policy_nameandout_policy_name arguments are the names of the ingress and egress QoS policy maps to be applied to an interface when a user authenticates on that interface. The policy maps will be removed from the interface when the user logs off and the session is terminated.

Flowchart of PFC QoS Egress LAN Port Features

Egress CoS Values

For all egress traffic, PFC QoS uses a configurable map to derive a CoS value from the final internal DSCP value associated with the traffic. PFC QoS sends the derived CoS value to the egress LAN ports for use in classification and congestion avoidance and to be written into ISL and 802.1Q frames.

Egress DSCP Mutation

You can configure 15 egress DSCP mutation maps to mutate the internal DSCP value before it is written in the egress ToS byte. You can attach egress DSCP mutation maps to any interface on which PFC QoS supports egress QoS.

Note If you configure egress DSCP mutation, PFC QoS does not derive the egress CoS value from the mutated DSCP value.

Egress ToS Byte

Except when DSCP transparency is enabled, PFC QoS creates a ToS byte for egress IP traffic from the final internal or mutated DSCP value and sends it to the egress port to be written into IP packets. For trust DSCP and untrusted IP traffic, the ToS byte includes the original two least-significant bits from the received ToS byte.

Egress PFC QoS Interfaces

You can attach an output policy map to a Layer 3 interface (either a LAN port configured as a Layer 3 interface or a VLAN interface) to apply a policy map to egress traffic.

Note•Output policies do not support microflow policing.

•You cannot apply microflow policing to ARP traffic.

•You cannot set a trust state in an output policy.

Egress ACL Support for Remarked DSCP

Note Egress ACL support for remarked DSCP is also known as packet recirculation.

The PFC3 supports egress ACL support for remarked DSCP, which enables IP precedence-based or DSCP-based egress QoS filtering to use any IP precedence or DSCP policing or marking changes made by ingress PFC QoS.

Without egress ACL support for remarked DSCP, egress QoS filtering uses received IP precedence or DSCP values; it does not use any IP precedence or DSCP changes made by ingress PFC QoS as the result of policing or marking.

On interfaces where egress ACL support for remarked DSCP is configured, the PFC3 processes each QoS-filtered IP packet twice: once to apply ingress PFC QoS and once to apply egress PFC QoS.

Caution If the switch is operating in PFC3A mode with egress ACL support for remarked DSCP configured, when the PFC3 processes traffic to apply ingress PFC QoS, it applies ingress PFC QoS filtering and ingress PFC QoS, and incorrectly applies any egress QoS filtering and egress PFC QoS configured on the ingress interface, which results in unexpected behavior if QoS filtering is configured on an interface where egress ACL support for remarked DSCP is enabled. This problem does not occur in other PFC3 modes.

After packets have been processed by ingress PFC QoS and any policing or marking changes have been made, the packets are processed again on the ingress interface by any configured Layer 2 features (for example, VACLs) before being processed by egress PFC QoS.

On an interface where egress ACL support for remarked DSCP is configured, if a Layer 2 feature matches the ingress-QoS-modified IP precedence or DSCP value, the Layer 2 feature might redirect or drop the matched packets, which prevents them from being processed by egress QoS.

After packets have been processed by ingress PFC QoS and any policing or marking changes have been made, the packets are processed on the ingress interface by any configured Layer 3 features (for example, ingress Cisco IOS ACLs, policy-based routing (PBR), etc.) before being processed by egress PFC QoS.

The Layer 3 features configured on an interface where egress ACL support for remarked DSCP is configured might redirect or drop the packets that have been processed by ingress PFC QoS, which would prevent them from being processed by egress PFC QoS.

Understanding Classification and Marking

The following sections describe where and how classification and marking occur in Cisco IOS Release 12.2SX:

Classification and Marking at Trusted and Untrusted Ingress Ports

The trust state of an ingress port determines how the port marks, schedules, and classifies received Layer 2 frames, and whether or not congestion avoidance is implemented. These are the port trust states:

Classification and Marking at Untrusted Ingress Ports

PFC QoS Layer 2 remarking marks all frames received through untrusted ports with the port CoS value (the default is zero).

To map the port CoS value that was applied to untrusted ingress traffic to the initial internal DSCP value, configure a trust CoS policy map that matches the ingress traffic.

Ingress Classification and Marking at Trusted Ports

You should configure ports to trust only if they receive traffic that carries valid QoS labels. QoS uses the received QoS labels as the basis of initial internal DSCP value. After the traffic enters the switch, you can apply a different trust state to traffic with a policy map. For example, traffic can enter the switch through a trust CoS port, and then you can use a policy map to trust IP precedence or DSCP, which uses the trusted value as the basis of the initial internal DSCP value, instead of the QoS label that was trusted at the port.

These sections describe classification and marking at trusted ingress ports:

You should configure LAN ports to trust CoS only if they receive traffic that carries valid Layer 2 CoS.

When an ISL frame enters the switch through a trusted ingress LAN port, PFC QoS accepts the three least significant bits in the User field as a CoS value. When an 802.1Q frame enters the switch through a trusted ingress LAN port, PFC QoS accepts the User Priority bits as a CoS value. PFC QoS Layer 2 remarking marks all traffic received in untagged frames with the ingress port CoS value.

You can attach one policy map to each Layer 3 interface (except FlexWAN interfaces) to apply egress PFC QoS.

Each policy map can contain multiple policy-map classes. You can configure a separate policy-map class for each type of traffic handled by the interface. There are two ways to configure filtering in policy-map classes:

•Access control lists (ACLs)

•Class-map match commands for IP precedence and DSCP values

Policy-map classes specify actions with the following optional commands:

•Policy-map class trust commands—PFC QoS applies the policy-map class trust state to matched ingress traffic, which then uses the trusted value as the basis of its initial internal DSCP value, instead of the QoS label that was trusted at the port (if any). In a policy map, you can trust CoS, IP precedence, or DSCP.

Policers

Overview of Policers

Policing allows you to rate limit incoming and outgoing traffic so that it adheres to the traffic forwarding rules defined by the QoS configuration. Sometimes these configured rules for how traffic should be forwarded through the system are referred to as a contract. If the traffic does not adhere to this contract, it is marked down to a lower DSCP value or dropped.

Policing does not buffer out-of-profile packets. As a result, policing does not affect transmission delay. In contrast, traffic shaping works by buffering out-of-profile traffic, which moderates the traffic bursts. (PFC QoS does not support shaping.)

The PFC3 supports ingress and egress PFC QoS, which includes ingress and egress policing. Traffic shaping is supported on some WAN modules.

Note Policers can act on ingress traffic per-port or per-VLAN. For egress traffic, the policers can act per-VLAN only.

You can create policers to do the following:

•Mark traffic

•Limit bandwidth utilization and mark traffic

Aggregate Policers

PFC QoS applies the bandwidth limits specified in an aggregate policer cumulatively to all flows in matched traffic. For example, if you configure an aggregate policer to allow 1 Mbps for all TFTP traffic flows on VLAN 1 and VLAN 3, it limits the TFTP traffic for all flows combined on VLAN 1 and VLAN 3 to 1 Mbps.

•You define per-interface aggregate policers in a policy map class with the police command. If you attach a per-interface aggregate policer to multiple ingress ports, it polices the matched traffic on each ingress port separately.

•You create named aggregate policers with the mls qos aggregate-policer command. If you attach a named aggregate policer to multiple ingress ports, it polices the matched traffic from all the ingress ports to which it is attached.

•Aggregate policing works independently on each DFC-equipped switching module and independently on the PFC, which supports any non-DFC-equipped switching modules. Aggregate policing does not combine flow statistics from different DFC-equipped switching modules. You can display aggregate policing statistics for each DFC-equipped switching module and for the PFC and any non-DFC-equipped switching modules supported by the PFC.

•Each PFC or DFC polices independently, which might affect QoS features being applied to traffic that is distributed across the PFC and any DFCs. Examples of these QoS feature are:

–Policers applied to a port channel interface.

–Policers applied to a switched virtual interface.

–Egress policers applied to either a Layer 3 interface or an SVI. Note that PFC QoS performs egress policing decisions at the ingress interface, on the PFC or ingress DFC.

Policers affected by this restriction deliver an aggregate rate that is the sum of all the independent policing rates.

Microflow Policers

PFC QoS applies the bandwidth limit specified in a microflow policer separately to each flow in matched traffic. For example, if you configure a microflow policer to limit the TFTP traffic to 1 Mbps on VLAN 1 and VLAN 3, then 1 Mbps is allowed for each flow in VLAN 1 and 1 Mbps for each flow in VLAN 3. In other words, if there are three flows in VLAN 1 and four flows in VLAN 3, the microflow policer allows each of these flows 1 Mbps.

You can configure PFC QoS to apply the bandwidth limits in a microflow policer as follows:

•You can create microflow policers with up to 63 different rate and burst parameter combinations.

•You can configure a microflow policer to use only source addresses, which applies the microflow policer to all traffic from a source address regardless of the destination addresses.

•You can configure a microflow policer to use only destination addresses, which applies the microflow policer to all traffic to a destination address regardless of the source addresses.

•For MAC-Layer microflow policing, PFC QoS considers MAC-Layer traffic with the same protocol and the same source and destination MAC-Layer addresses to be part of the same flow, including traffic with different EtherTypes. You can configure MAC ACLs to filter IPX traffic.

Note With Release 12.2(33)SXI4 and later releases, when appropriate for the configuration of the policer, microflow policers use the interface-full flow mask, which can reduce flowmask conflicts. Releases earlier than Release 12.2(33)SXI4 use the full flow mask.

•By default, microflow policers only affect traffic routed by the RP. To enable microflow policing of other traffic, including traffic in bridge groups, enter the mls qos bridged command.

•You cannot apply microflow policing to ARP traffic.

•You cannot apply microflow policing to IPv6 multicast traffic.

You can include both an aggregate policer and a microflow policer in each policy map class to police a flow based on both its own bandwidth utilization and on its bandwidth utilization combined with that of other flows.

Note If traffic is both aggregate and microflow policed, then the aggregate and microflow policers must both be in the same policy-map class and each must use the same conform-action and exceed-action keyword option: drop, set-dscp-transmit, set-prec-transmit, or transmit.

For example, you could create a microflow policer with a bandwidth limit suitable for individuals in a group, and you could create a named aggregate policer with bandwidth limits suitable for the group as a whole. You could include both policers in policy map classes that match the group's traffic. The combination would affect individual flows separately and the group aggregately.

For policy map classes that include both an aggregate and a microflow policer, PFC QoS responds to an out-of-profile status from either policer and, as specified by the policer, applies a new DSCP value or drops the packet. If both policers return an out-of-profile status, then if either policer specifies that the packet is to be dropped, it is dropped; otherwise, PFC QoS applies a marked-down DSCP value.

Note To avoid inconsistent results, ensure that all traffic policed by the same aggregate policer has the same trust state.

Policing uses the Layer 2 frame size. You specify the bandwidth utilization limit as a committed information rate (CIR). You can also specify a higher peak information rate (PIR). Packets that exceed a rate are "out of profile" or "nonconforming."

In each policer, you specify if out-of-profile packets are to be dropped or to have a new DSCP value applied to them (applying a new DSCP value is called "markdown"). Because out-of-profile packets do not retain their original priority, they are not counted as part of the bandwidth consumed by in-profile packets.

If you configure a PIR, the PIR out-of-profile action cannot be less severe than the CIR out-of-profile action. For example, if the CIR out-of-profile action is to mark down the traffic, then the PIR out-of-profile action cannot be to transmit the traffic.

For all policers, PFC QoS uses a configurable global table that maps the internal DSCP value to a marked-down DSCP value. When markdown occurs, PFC QoS gets the marked-down DSCP value from the table. You cannot specify marked-down DSCP values in individual policers.

Note•Policing with the conform-action transmit keywords supersedes the ingress LAN port trust state of matched traffic with trust DSCP or with the trust state defined by a trust policy-map class command.

•By default, the markdown table is configured so that no markdown occurs: the marked-down DSCP values are equal to the original DSCP values. To enable markdown, configure the table appropriately for your network.

•When you apply both ingress policing and egress policing to the same traffic, both the input policy and the output policy must either mark down traffic or drop traffic. PFC QoS does not support ingress markdown with egress drop or ingress drop with egress markdown.

Understanding Port-Based Queue Types

Port-based queue types are determined by the ASICs that control the ports. The following sections describe the queue types, drop thresholds, and buffers that are supported on the LAN switching modules:

Ingress and Egress Buffers and Layer 2 CoS-Based Queues

The Ethernet port ASICs have buffers that are divided into a fixed number of queues. When congestion avoidance is enabled, PFC QoS uses the traffic's Layer 2 CoS value to assign traffic to the queues. The buffers and queues store frames temporarily as they transit the switch. PFC QoS allocates the port ASIC memory as buffers for each queue on each port.

The Ethernet ports support the following types of queues:

•Standard queues

•Strict-priority queues

The Ethernet ports support the following types of scheduling algorithms between queues:

•Shaped round robin (SRR)—SRR allows a queue to use only the allocated bandwidth.

•Deficit weighted round robin (DWRR)—DWRR keeps track of any lower-priority queue under-transmission caused by traffic in a higher-priority queue and compensates in the next round.

•Weighted Round Robin (WRR)—WRR does not explicitly reserve bandwidth for the queues. Instead, the amount of bandwidth assigned to each queue is user configurable. The percentage or weight allocated to a queue defines the amount of bandwidth allocated to the queue.

•Strict-priority queueing—Strict priority queueing allows delay-sensitive data such as voice to be dequeued and sent before packets in other queues are dequeued, giving delay-sensitive data preferential treatment over other traffic. The switch services traffic in the strict-priority transmit queue before servicing the standard queues. After transmitting a packet from a standard queue, the switch checks for traffic in the strict-priority queue. If the switch detects traffic in the strict-priority queue, it suspends its service of the standard queue and completes service of all traffic in the strict-priority queue before returning to the standard queue.

The Ethernet ports provide congestion avoidance with these types of thresholds within a queue:

•Weighted Random Early Detection (WRED)—On ports with WRED drop thresholds, frames with a given QoS label are admitted to the queue based on a random probability designed to avoid buffer congestion. The probability of a frame with a given QoS label being admitted to the queue or discarded depends on the weight and threshold assigned to that QoS label.

For example, if CoS 2 is assigned to queue 1, threshold 2, and the threshold 2 levels are 40 percent (low) and 80 percent (high), then frames with CoS 2 will not be dropped until queue 1 is at least 40 percent full. As the queue depth approaches 80 percent, frames with CoS 2 have an increasingly higher probability of being discarded rather than being admitted to the queue. Once the queue is over 80 percent full, all CoS 2 frames are dropped until the queue is less than 80 percent full. The frames the switch discards when the queue level is between the low and high thresholds are picked out at random, rather than on a per-flow basis or in a FIFO manner. This method works well with protocols such as TCP that can adjust to periodic packet drops by backing off and adjusting their transmission window size.

•Tail-drop thresholds—On ports with tail-drop thresholds, frames with a given QoS label are admitted to the queue until the drop threshold associated with that QoS label is exceeded; subsequent frames of that QoS label are discarded until the threshold is no longer exceeded. For example, if CoS 1 is assigned to queue 1, threshold 2, and the threshold 2 watermark is 60 percent, then frames with CoS 1 will not be dropped until queue 1 is 60 percent full. All subsequent CoS 1 frames will be dropped until the queue is less than 60 percent full. With some port types, you can configure the standard receive queue to use both a tail-drop and a WRED-drop threshold by mapping a CoS value to the queue or to the queue and a threshold. The switch uses the tail-drop threshold for traffic carrying CoS values mapped only to the queue. The switch uses WRED-drop thresholds for traffic carrying CoS values mapped to the queue and a threshold. All LAN ports of the same type use the same drop-threshold configuration.

Ingress Queue Types

To see the queue structure of a LAN port, enter the show queueing interface {ethernet | fastethernet | gigabitethernet | tengigabitethernet} slot/port | include type command. The command displays one of the following architectures:

•1q2t indicates one standard queue with one configurable tail-drop threshold and one nonconfigurable tail-drop threshold.

•1q4t indicates one standard queue with four configurable tail-drop thresholds.

Note The receive queue values shown are the values in effect when the port is configured to trust CoS or DSCP. When the port is untrusted, the receive queue values are the same as when QoS is globally disabled.

1q2t Receive Queues

Feature

Default Value

Standard receive queue

Threshold 1

CoS

0, 1, 2, 3, and 4

Tail-drop

80%

WRED-drop

Not supported

Threshold 2

CoS

5, 6, and 7

Tail-drop

100% (not configurable)

WRED-drop

Not supported

1q4t Receive Queues

Feature

Default Value

Standard receive queue

Threshold 1

CoS

0 and 1

Tail-drop

50%

WRED-drop

Not supported

Threshold 2

CoS

2 and 3

Tail-drop

60%

WRED-drop

Not supported

Threshold 3

CoS

4 and 5

Tail-drop

80%

WRED-drop

Not supported

Threshold 4

CoS

6 and 7

Tail-drop

100%

WRED-drop

Not supported

1p1q4t Receive Queues

Feature

Default Value

Standard receive queue

Threshold 1

CoS

0 and 1

Tail-drop

50%

WRED-drop

Not supported

Threshold 2

CoS

2 and 3

Tail-drop

60%

WRED-drop

Not supported

Threshold 3

CoS

4 and 6

Tail-drop

80%

WRED-drop

Not supported

Threshold 4

CoS

7

Tail-drop

100%

WRED-drop

Not supported

Strict-priority receive queue

CoS

5

Tail-drop

100% (nonconfigurable)

1p1q0t Receive Queues

Feature

Default Value

Standard receive queue

CoS

0, 1, 2, 3, 4, 6, and 7

Tail-drop

100% (nonconfigurable)

WRED-drop

Not supported

Strict-priority receive queue

CoS

5

Tail-drop

100% (nonconfigurable)

1p1q8t Receive Queues

Feature

Default Value

Standard receive queue

Threshold 1

CoS

0

Tail-drop

Disabled; 70%

WRED-drop

Enabled; 40% low, 70% high

Threshold 2

CoS

1

Tail-drop

Disabled; 70%

WRED-drop

Enabled; 40% low, 70% high

Threshold 3

CoS

2

Tail-drop

Disabled; 80%

WRED-drop

Enabled; 50% low, 80% high

Threshold 4

CoS

3

Tail-drop

Disabled; 80%

WRED-drop

Enabled; 50% low, 80% high

Threshold 5

CoS

4

Tail-drop

Disabled; 90%

WRED-drop

Enabled; 60% low, 90% high

Threshold 6

CoS

6

Tail-drop

Disabled; 90%

WRED-drop

Enabled; 60% low, 90% high

Threshold 7

CoS

7

Tail-drop

Disabled; 100%

WRED-drop

Enabled;70% low, 100% high

Strict-priority receive queue

CoS

5

Tail-drop

100% (nonconfigurable)

1q8t Receive Queues

Feature

Default Value

Standard receive queue

Threshold 1

CoS

0

Tail-drop

50%

WRED-drop

Not supported

Threshold 2

CoS

None

Tail-drop

50%

WRED-drop

Not supported

Threshold 3

CoS

1, 2, 3, 4

Tail-drop

60%

WRED-drop

Not supported

Threshold 4

CoS

None

Tail-drop

60%

WRED-drop

Not supported

Threshold 5

CoS

6 and 7

Tail-drop

80%

WRED-drop

Not supported

Threshold 6

CoS

None

Tail-drop

80%

WRED-drop

Not supported

Threshold 7

CoS

5

Tail-drop

100%

WRED-drop

Not supported

Threshold 8

CoS

None

Tail-drop

100%

WRED-drop

Not supported

2q8t Receive Queues

Feature

Default Value

Standard receive queue 1(low priority)

Threshold 1

CoS

0 and 1

Tail-drop

70%

WRED-drop

Not supported

Threshold 2

CoS

2 and 3

Tail-drop

80%

WRED-drop

Not supported

Threshold 3

CoS

4

Tail-drop

90%

WRED-drop

Not supported

Threshold 4

CoS

6 and 7

Tail-drop

100%

WRED-drop

Not supported

Thresholds 5-8

CoS

None

Tail-drop

100%

WRED-drop

Not supported

Standard receive queue 2(high priority)

Threshold 1

CoS

5

Tail-drop

100%

WRED-drop

Not supported

Thresholds 2-8

CoS

None

Tail-drop

100%

WRED-drop

Not supported

8q4t Receive Queues

Note With releases earlier than Release 12.2(33)SXJ3, do not use the default DSCP-based queue mapping for 8q4t ingress queues unless you configure supporting bandwidth and queue limits (CSCts82932).

•NetFlow and NetFlow data export (NDE) do not support interfaces where egress ACL support for remarked DSCP is configured.

•When egress ACL support for remarked DSCP is configured on any interface, you must configure an interface-specific flowmask to enable NetFlow and NDE support on interfaces where egress ACL support for remarked DSCP is not configured. Enter either the mls flow ip interface-destination-source or the mls flow ip interface-full global configuration mode command.

•Interface counters are not accurate on interfaces where egress ACL support for remarked DSCP is configured.

•You cannot apply microflow policing to IPv6 multicast traffic.

•You cannot apply microflow policing to traffic that has been permitted by egress ACL support for remarked DSCP.

•Traffic that has been permitted by egress ACL support for remarked DSCP cannot be tagged as MPLS traffic. (The traffic can be tagged as MPLS traffic on another network device.)

•When you apply both ingress policing and egress policing to the same traffic, both the input policy and the output policy must either mark down traffic or drop traffic. PFC QoS does not support ingress markdown with egress drop or ingress drop with egress markdown. (CSCea23571)

•If traffic is both aggregate and microflow policed, then the aggregate and microflow policers must both be in the same policy-map class and each must use the same conform-action and exceed-action keyword option: drop, set-dscp-transmit, set-prec-transmit, or transmit.

•You cannot configure PFC QoS features on tunnel interfaces.

•PFC QoS does not rewrite the payload ToS byte in tunnel traffic.

•PFC QoS filters only by ACLs, dscp values, or IP precedence values.

•For these commands, PFC QoS applies identical configuration to all LAN ports controlled by the same application-specific integrated circuit (ASIC):

•Configure these commands only on physical ports. Do not configure these commands on logical interfaces:

–priority-queue cos-map

–wrr-queue cos-map

–wrr-queue random-detect

–wrr-queue random-detect max-threshold

–wrr-queue random-detect min-threshold

–wrr-queue threshold

–wrr-queue queue-limit

–wrr-queue bandwidth

–rcv-queue cos-map

–rcv-queue bandwidth

–rcv-queue random-detect

–rcv-queue random-detect max-threshold

–rcv-queue random-detect min-threshold

–rcv-queue queue-limit

–rcv-queue cos-map

–rcv-queue threshold

Note IP multicast switching using egress packet replication is not compatible with QoS. In some cases, egress replication can result in the incorrect COS or DSCP marking of packets. If you are using QoS and your switching modules are capable of egress replication, enter the mls ip multicast replication-mode ingress command to force ingress replication.

•All versions of the PFC3 support QoS for IPv6 unicast and multicast traffic.

–If you configure both a DSCP value and a Layer 4 "greater than" (gt) or "less than" (lt) operator in an IPv6 ACE, you cannot use the ACL for PFC QoS filtering.

–If you configure a DSCP value in one IPv6 ACL and a Layer 4 "greater than" (gt) or "less than" (lt) operator in another IPv6 ACL, you cannot use both ACLs in different class maps on the same interface for PFC QoS filtering.

•You can apply aggregate and microflow policers to IPv6 traffic, but you cannot apply microflow policing to IPv6 multicast traffic.

•With egress ACL support for remarked DSCP configured, the PFC3 does not provide hardware-assistance for these features:

–Cisco IOS reflexive ACLs

–TCP intercept

–Network Address Translation (NAT)

•You cannot apply microflow policing to ARP traffic.

•The PFC3 does not apply egress policing to traffic that is being bridged to the RP.

•The PFC3 does not apply egress policing or egress DSCP mutation to multicast traffic from the RP.

•With a PFC3A, PFC QoS does not rewrite the ToS byte in bridged multicast traffic.

•The PFC3 supports up to 1023 configurable aggregate policers, but some PFC QoS commands other than the police command will be included in this count. By default, any policy using a set or trust command will be included in the aggregate policer count. You can disable the addition of the set or trust commands to the aggregate policer count by entering the no mls qos marking statistics command, but you will then be unable to collect statistics for the classmaps associated with these commands. You can view the aggregate policer count in the QoS Policer Resources section of the output of the show platform hardware capacity qos command.

Class Map Command Restrictions

•PFC QoS supports a single match command in class-map match-all class maps, except that the match protocol command can be configured in a class map with the match dscp or match precedence command.

This example shows how to enable microflow policing of bridged traffic on VLANs 3 through 5:

Router# configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

Router(config)# interface range vlan 3 - 5

Router(config-if)# mls qos bridged

Router(config-if)# end

Router#

This example shows how to verify the configuration:

Router# show mls qos | begin Bridged QoS

Bridged QoS is enabled on the following interfaces:

Vl3 Vl4 Vl5

<...output truncated...>

Router#

Enabling VLAN-Based PFC QoS on Layer 2 LAN Ports

Note You can attach policy maps to Layer 3 interfaces for application of PFC QoS to egress traffic. VLAN-based or port-based PFC QoS on Layer 2 ports is not relevant to application of PFC QoS to egress traffic on Layer 3 interfaces.

By default, PFC QoS uses policy maps attached to LAN ports. For ports configured as Layer 2 LAN ports with the switchport keyword, you can configure PFC QoS to use policy maps attached to a VLAN. Ports not configured with the switchport keyword are not associated with a VLAN.

1The set-dscp-transmit and set-prec-transmit keywords are only supported for IP traffic.

When creating a named aggregate policer, note the following information:

•Aggregate policing works independently on each DFC-equipped switching module and independently on the PFC, which supports any non-DFC-equipped switching modules. Aggregate policing does not combine flow statistics from different DFC-equipped switching modules. You can display aggregate policing statistics for each DFC-equipped switching module and for the PFC and any non-DFC-equipped switching modules supported by the PFC.

•Each PFC or DFC polices independently, which might affect QoS features being applied to traffic that is distributed across the PFC and any DFCs. Examples of these QoS feature are:

–Policers applied to a port channel interface.

–Policers applied to a switched virtual interface.

–Egress policers applied to either a Layer 3 interface or an SVI. Note that PFC QoS performs egress policing decisions at the ingress interface, on the PFC or ingress DFC.

Policers affected by this restriction deliver an aggregate rate that is the sum of all the independent policing rates.

–To set PFC QoS labels in untrusted traffic, enter the set-dscp-transmit keyword to mark matched untrusted traffic with a new DSCP value or enter the set-prec-transmit keyword to mark matched untrusted traffic with a new IP precedence value. The set-dscp-transmit and set-prec-transmit keywords are only supported for IP traffic. PFC QoS sets egress ToS and CoS from the configured value.

–Enter the drop keyword to drop all matched traffic.

Note When you configure drop as the conform action, PFC QoS configures drop as the exceed action and the violate action.

•(Optional) For traffic that exceeds the CIR, you can specify an exceed action as follows:

–The default exceed action is drop, except with a maximum_burst_bytes parameter (drop is not supported with a maximum_burst_bytes parameter).

–Enter the policed-dscp-transmit keyword to cause all matched out-of-profile traffic to be marked down as specified in the markdown map.

Note When you create a policer that does not use the pir keyword and the maximum_burst_bytes parameter is equal to the normal_burst_bytes parameter (which is the case if you do not enter the maximum_burst_bytes parameter), the exceed-action policed-dscp-transmit keywords cause PFC QoS to mark traffic down as defined by the policed-dscp max-burst markdown map.

•(Optional) For traffic that exceeds the PIR, you can specify a violate action as follows:

Note When you apply both ingress policing and egress policing to the same traffic, both the input policy and the output policy must either mark down traffic or drop traffic. PFC QoS does not support ingress markdown with egress drop or ingress drop with egress markdown.

This example shows how to create a named aggregate policer with a 1-Mbps rate limit and a 10-MB burst size that transmits conforming traffic and marks down out-of-profile traffic:

You can configure these interface types for protocol-independent MAC ACL filtering:

•VLAN interfaces without IP addresses

•Physical LAN ports configured to support EoMPLS

•Logical LAN subinterfaces configured to support EoMPLS

Ingress traffic permitted or denied by a MAC ACL on an interface configured for protocol-independent MAC ACL filtering is processed by egress interfaces as MAC-layer traffic. You cannot apply egress IP ACLs to traffic that was permitted or denied by a MAC ACL on an interface configured for protocol-independent MAC ACL filtering.

This example shows how to create a MAC-Layer ACL named mac_layer that denies dec-phase-iv traffic with source address 0000.4700.0001 and destination address 0000.4700.0009, but permits all other traffic:

Configures an access control entry (ACE) in an ARP ACL for QoS filtering.

When configuring an entry in an ARP ACL for QoS filtering, note the following information:

•This publication describes the ARP ACL syntax that is supported in hardware by the PFC3. Any other ARP ACL syntax displayed by the CLI help when you enter a question mark ("?") is not supported and cannot be used to filter ARP traffic for QoS.

•ACLs entries are scanned in the order you enter them. The first matching entry is used. To improve performance, place the most commonly used entries near the beginning of the ACL.

•An implicit deny ip any mac any entry exists at the end of an ACL unless you include an explicit permit ip any mac any entry at the end of the list.

•All new entries to an existing list are placed at the end of the list. You cannot add entries to the middle of a list.

This example shows how to create an ARP ACL named arp_filtering that only permits ARP traffic from IP address 1.1.1.1:

•When multiple match access-group ACLs are included in a match-any class map, and one ACL contains a deny ip any any entry, all match criteria after the deny ip any any entry (either in the same ACL or in different ACLs) will not be installed in the TCAM.

In the following example, ACLs acl4 and acl5 will not be installed because they follow acl3, which contains a deny ip any any entry:

ip access-list ext acl3

deny ip any any

class-map cmap1

match access-group acl1

match access-group acl2

match access-group acl3

match access-group acl4

match access-group acl5

You can use either of the following workarounds to avoid this issue:

–Move the deny ip any any entry to the end of the ACL and move that ACL to the end of the class map.

–Configure all ACLs that must follow the deny ip any any entry into different class maps.

–If configure both a DSCP value and a Layer 4 greater than (gt) or less than (lt) operator in an IPv6 ACE, you cannot use the ACL for PFC QoS filtering.

–If configure a DSCP value in one IPv6 ACL and a Layer 4 greater than (gt) or less than (lt) operator in another IPv6 ACL, you cannot use both ACLs in different class maps on the same interface for PFC QoS filtering.

•The IPv6 address matching against Layer 4 ports is ignored if the IPv6 address in the ACE is not compressible. The IPv6 source and destination addresses are matched, but the configured source or destination UDP or TCP ports will be ignored. To force Layer 4 port matching, use the mls ipv6 acl compress address unicast command.

(Optional—for IPv4 traffic) Configures the class map to filter based on up to eight DSCP values.

Note Does not support source-based or destination-based microflow policing.

Verifying Class Map Configuration

To verify class map configuration, perform this task:

Command

Purpose

Step 1

Router (config-cmap)# end

Exits configuration mode.

Step 2

Router# show class-mapclass_name

Verifies the configuration.

This example shows how to create a class map named ipp5 and how to configure filtering to match traffic with IP precedence 5:

Router# configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

Router(config)# class-map ipp5

Router(config-cmap)# match ip precedence 5

Router(config-cmap)# end

This example shows how to verify the configuration:

Router# show class-map ipp5

Class Map match-all ipp5 (id 1)

Match ip precedence 5

Configuring a Policy Map

You can attach only one policy map to an interface. Policy maps can contain one or more policy map classes, each with different policy map commands.

Configure a separate policy map class in the policy map for each type of traffic that an interface receives. Put all commands for each type of traffic in the same policy map class. PFC QoS does not attempt to apply commands from more than one policy map class to matched traffic.

Configuring Policy Map Class Actions

When configuring policy map class actions, note the following information:

•Policy maps can contain one or more policy map classes.

•Put all trust-state and policing commands for each type of traffic in the same policy map class.

•PFC QoS only applies commands from one policy map class to traffic. After traffic has matched the filtering in one policy map class, QoS does apply the filtering configured in other policy map classes.

•For hardware-switched traffic, PFC QoS does not support the bandwidth, priority, queue-limit, or random-detect policy map class commands. You can configure these commands because they can be used for software-switched traffic.

•PFC QoS does not support the set qos-group policy map class commands.

Creates a per-interface policer and configures the policy-map class to use it.

When configuring a per-interface policer, note the following information:

•Aggregate policing works independently on each DFC-equipped switching module and independently on the PFC, which supports any non-DFC-equipped switching modules. Aggregate policing does not combine flow statistics from different DFC-equipped switching modules. You can display aggregate policing statistics for each DFC-equipped switching module and for the PFC and any non-DFC-equipped switching modules supported by the PFC.

•Each PFC or DFC polices independently, which might affect QoS features being applied to traffic that is distributed across the PFC and any DFCs. Examples of these QoS feature are:

–Policers applied to a port channel interface.

–Policers applied to a switched virtual interface.

–Egress policers applied to either a Layer 3 interface or an SVI. Note that PFC QoS performs egress policing decisions at the ingress interface, on the PFC or ingress DFC.

Policers affected by this restriction deliver an aggregate rate that is the sum of all the independent policing rates.

•When you apply both ingress policing and egress policing to the same traffic, both the input policy and the output policy must either mark down traffic or drop traffic. PFC QoS does not support ingress markdown with egress drop or ingress drop with egress markdown.

•You can enter the flow keyword to define a microflow policer (you cannot apply microflow policing to ARP traffic). When configuring a microflow policer, note the following information:

–You can enter the mask src-only keywords to base flow identification only on source addresses, which applies the microflow policer to all traffic from each source address. PFC QoS supports the mask src-only keywords for both IP traffic and MAC traffic.

–You can enter the mask dest-only keywords to base flow identification only on destination addresses, which applies the microflow policer to all traffic to each source address. PFC QoS supports the mask dest-only keywords for both IP traffic and MAC traffic.

–To set PFC QoS labels in untrusted traffic, you can enter the set-dscp-transmit keyword to mark matched untrusted traffic with a new DSCP value or enter the set-prec-transmit keyword to mark matched untrusted traffic with a new IP precedence value. The set-dscp-transmit and set-prec-transmit keywords are only supported for IP traffic. PFC QoS sets egress ToS and CoS from the configured value.

–You can enter the drop keyword to drop all matched traffic.

–Ensure that aggregate and microflow policers that are applied to the same traffic each specify the same conform-action behavior.

•(Optional) For traffic that exceeds the CIR, you can specify an exceed action as follows:

–For marking without policing, you can enter the transmit keyword to transmit all matched out-of-profile traffic.

–The default exceed action is drop, except with a maximum_burst_bytes parameter (drop is not supported with a maximum_burst_bytes parameter).

–You can enter the policed-dscp-transmit keyword to cause all matched out-of-profile traffic to be marked down as specified in the markdown map.

Note When you create a policer that does not use the pir keyword and the maximum_burst_bytes parameter is equal to the normal_burst_bytes parameter (which is the case if you do not enter the maximum_burst_bytes parameter), the exceed-action policed-dscp-transmit keywords cause PFC QoS to mark traffic down as defined by the policed-dscp max-burst markdown map.

•(Optional—Not supported with the flow keyword) for traffic that exceeds the PIR, you can specify a violate action as follows:

–For marking without policing, you can enter the transmit keyword to transmit all matched out-of-profile traffic.

–The default violate action is equal to the exceed action.

–You can enter the policed-dscp-transmit keyword to cause all matched out-of-profile traffic to be marked down as specified in the markdown map.

This example shows how to create a policy map named max-pol-ipp5 that uses the class-map named ipp5, which is configured to trust received IP precedence values and is configured with a maximum-capacity aggregate policer and with a microflow policer:

When attaching a policy map to an interface, note the following information:

•Do not attach a service policy to a port that is a member of an EtherChannel.

•PFC QoS supports the output keyword only on Layer 3 interfaces (either LAN ports configured as Layer 3 interfaces or VLAN interfaces).You can attach both an input and an output policy map to a Layer 3 interface.

•VLAN-based or port-based PFC QoS on Layer 2 ports is not relevant to policies attached to Layer 3 interfaces with the output keyword.

•Policies attached with the output keyword do not support microflow policing.

•You cannot attach a policy map that configures a trust state with the service-policy output command.

•Filtering based on IP precedence or DSCP in policies attached with the output keyword uses the received IP precedence or DSCP values. Filtering based on IP precedence or DSCP in policies attached with the output keyword is not based on any IP precedence or DSCP changes made by ingress QoS.

•Aggregate policing works independently on each DFC-equipped switching module and independently on the PFC, which supports any non-DFC-equipped switching modules. Aggregate policing does not combine flow statistics from different DFC-equipped switching modules. You can display aggregate policing statistics for each DFC-equipped switching module and for the PFC and any non-DFC-equipped switching modules supported by the PFC.

•Each PFC or DFC polices independently, which might affect QoS features being applied to traffic that is distributed across the PFC and any DFCs. Examples of these QoS feature are:

–Policers applied to a port channel interface.

–Policers applied to a switched virtual interface.

–Egress policers applied to either a Layer 3 interface or an SVI. Note that PFC QoS performs egress policing decisions at the ingress interface, on the PFC or ingress DFC.

Policers affected by this restriction deliver an aggregate rate that is the sum of all the independent policing rates.

•When you apply both ingress policing and egress policing to the same traffic, both the input policy and the output policy must either mark down traffic or drop traffic. PFC QoS does not support ingress markdown with egress drop or ingress drop with egress markdown.

This example shows how to attach the policy map named pmap1 to Fast Ethernet port 5/36:

Router# configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

Router(config)# interface fastethernet 5/36

Router(config-if)# service-policy input pmap1

Router(config-if)# end

This example shows how to verify the configuration:

Router# show policy-map interface fastethernet 5/36

FastEthernet5/36

service-policy input: pmap1

class-map: cmap1 (match-all)

0 packets, 0 bytes

5 minute rate 0 bps

match: ip precedence 5

class cmap1

police 8000 8000 conform-action transmit exceed-action drop

class-map: cmap2 (match-any)

0 packets, 0 bytes

5 minute rate 0 bps

match: ip precedence 2

0 packets, 0 bytes

5 minute rate 0 bps

class cmap2

police 8000 10000 conform-action transmit exceed-action drop

Router#

Configuring Dynamic Per-Session Attachment of a Policy Map

To configure and enable per-session QoS, perform these steps:

Step 1 Define the ingress and egress QoS policy maps to be assigned when users are authenticated.

Step 2 Configure identity policies to specify the policy maps to be assigned.

Step 3 In the user profiles on the RADIUS server, configure the Cisco vendor-specific attributes (VSAs) to specify which ingress and egress QoS policy maps will be assigned to each user.

To define the policy maps and associate them with an identity policy, follow these steps:

To remove the identity policy from the switch, use the no identity policypolicy_name command.

After the policy maps have been defined on the switch, configure the Cisco AV pair attributes in each user profile on the RADIUS server using the policy map names:

•cisco-avpair = "ip:sub-policy-In=in_policy_name"

•cisco-avpair = "ip:sub-policy-Out=out_policy_name"

To set the Cisco AV pair attributes on the RADIUS server, perform the following task:

Command or Action

Purpose

sub-policy-In=in_policy_name

sub-policy-Out=out_policy_name

Enters the two Cisco AV pairs for service policy on the RADIUS server in the user file. When the switch requests the policy name, this information in the user file is supplied.

A RADIUS user file contains an entry for each user that the RADIUS server will authenticate. Each entry, which is also referred to as a user profile, establishes an attribute the user can access.

In this example, you have configured a service policy that attaches a QoS policy map to the interface and specifies the direction (inbound for data packets traveling into the interface or outbound for data packets leaving the interface).

The policy map applied in the inbound direction is example_in_qos and the outbound policy map is example_out_qos.

This example shows the configuration in the user file on the RADIUS server:

userid Password ="cisco"

Service-Type = Framed,

Framed-Protocol = PPP,

cisco-avpair = "sub-policy-In=example_in_qos",

cisco-avpair = "sub-policy-Out=example_out_qos"

This example shows the output of the show epm session summary command when a session is active:

Router# show epm session summary

EPM Session Information

-----------------------

Total sessions seen so far : 5

Total active sessions : 1

Session IP Address : 192.0.2.1

-------------------

This example shows the output of the show epm session ip ip_addrcommand when a session is active on the interface with IP address 192.0.2.1:

Note In the DSCP mutation map displays, the marked-down DSCP values are shown in the body of the matrix; the first digit of the original DSCP value is in the column labeled d1 and the second digit is in the top row. In the example shown, DSCP 30 maps to DSCP 08.

Attaching an Egress DSCP Mutation Map to an Interface

To attach an egress DSCP mutation map to an interface, perform this task:

When you configure ingress CoS mutation on an IEEE 802.1Q tunnel port that you have configured to trust received CoS, PFC QoS uses the mutated CoS value instead of the received CoS value in the ingress drop thresholds and for any trust CoS marking and policing.

•To avoid ingress CoS mutation configuration failures, only create EtherChannels where all member ports support ingress CoS mutation or where no member ports support ingress CoS mutation. Do not create EtherChannels with mixed support for ingress CoS mutation.

•If you configure ingress CoS mutation on a port that is a member of an EtherChannel, the ingress CoS mutation is applied to the port-channel interface.

•You can configure ingress CoS mutation on port-channel interfaces.

•With ingress CoS mutation configured on a port-channel interface, the following occurs:

–The ingress CoS mutation configuration is applied to the port groups of all member ports of the EtherChannel. If any member port cannot support ingress CoS mutation, the configuration fails.

–If a port in the port group is a member of a second EtherChannel, the ingress CoS mutation configuration is applied to the second port-channel interface and to the port groups of all member ports of the second EtherChannel. If any member port of the second EtherChannel cannot support ingress CoS mutation, the configuration fails on the first EtherChannel. If the configuration originated on a nonmember port in a port group that has a member port of the first EtherChannel, the configuration fails on the nonmember port.

–The ingress CoS mutation configuration propagates without limit through port groups, member ports, and port-channel interfaces, regardless of whether or not the ports are configured to trust CoS or are configured as IEEE 802.1Q tunnel ports.

•An EtherChannel where you want to configure ingress CoS mutation must not have member ports that are in port groups containing member ports of other EtherChannels that have member ports that do not support ingress CoS mutation. (This restriction extends without limit through all port-group-linked member ports and port-channel-interface-linked ports.)

•A port where you want to configure ingress CoS mutation must not be in a port group that has a member port of an EtherChannel that has members that do not support ingress CoS mutation. (This restriction extends without limit through all port-group-linked member ports and port-channel-interface-linked ports.)

•There can be only be one ingress CoS mutation configuration applied to all port-group-linked member ports and port-channel-interface-linked ports.

•You can enter the normal-burst keyword to configure the markdown map used by the exceed-action policed-dscp-transmit keywords.

•You can enter the max-burst keyword to configure the markdown map used by the violate-action policed-dscp-transmit keywords.

Note When you create a policer that does not use the pir keyword, and the maximum_burst_bytes parameter is equal to the normal_burst_bytes parameter (which occurs if you do not enter the maximum_burst_bytes parameter), the exceed-action policed-dscp-transmit keywords cause PFC QoS to mark traffic down as defined by the policed-dscp max-burst markdown map.

•To avoid out-of-sequence packets, configure the markdown maps so that conforming and nonconforming traffic uses the same queue.

•You can enter up to 8 DSCP values that map to a marked-down DSCP value.

Note In the Policed-dscp displays, the marked-down DSCP values are shown in the body of the matrix; the first digit of the original DSCP value is in the column labeled d1 and the second digit is in the top row. In the example shown, DSCP 41 maps to DSCP 41.

Mapping Internal DSCP Values to Egress CoS Values

To configure the mapping of the DSCP value that PFC QoS uses internally on the PFC to the CoS value used for egress LAN port scheduling and congestion avoidance, perform this task:

Note In the Dscp-cos map display, the CoS values are shown in the body of the matrix; the first digit of the DSCP value is in the column labeled d1 and the second digit is in the top row. In the example shown, DSCP values 41 through 47 all map to CoS 05.

Configuring the Trust State of Ethernet LAN Ports

By default, all ports are untrusted. You can configure the port trust state on all Ethernet LAN ports.

Note On non-Gigabit Ethernet 1q4t/2q2t ports, you must repeat the trust configuration in a class map.

This example shows how to configure Gigabit Ethernet port 1/1 with the trust cos keywords:

Router# configure terminal

Enter configuration commands, one per line. End with CNTL/Z.

Router(config)# interface gigabitethernet 1/1

Router(config-if)# mls qos trust cos

Router(config-if)# end

Router#

This example shows how to verify the configuration:

Router# show queueing interface gigabitethernet 1/1 | include trust

Trust state: trust COS

Router#

Configuring Trusted Boundary with Cisco Device Verification

Release 12.2(33)SXI1 and later releases support the trusted boundary with Cisco device verification feature, which configures Ethernet LAN ports to use CDP to detect whether or not a Cisco IP phone is attached to the port.

Configuring the Ingress LAN Port CoS Value

Note Whether or not PFC QoS uses the CoS value applied with the mls qos cos command depends on the trust state of the port and the trust state of the traffic received through the port. The mls qos cos command does not configure the trust state of the port or the trust state of the traffic received through the port.

To use the CoS value applied with the mls qos cos command as the basis of internal DSCP:

•On a port that receives only untagged ingress traffic, configure the ingress port as trusted or configure a trust CoS policy map that matches the ingress traffic.

Allocating Bandwidth Between Standard Transmit Queues

The switch transmits frames from one standard queue at a time using one of these dequeuing algorithms, which use percentages or weights to allocate relative bandwidth to the queues as they are serviced sequentially:

•Shaped round robin (SRR)—SRR allows a queue to use only the allocated bandwidth. Supported as an option on 1p3q8t ports and on 1p7q4t ports.

•Deficit weighted round robin (DWRR)—DWRR keeps track of any lower-priority queue under-transmission caused by traffic in a higher-priority queue and compensates in the next round. DWRR is the dequeuing algorithm on 1p3q1t, 1p2q1t, 1p3q8t, 1p7q4t, and 1p7q8t ports.

Note You configure DWRR ports with the same commands that you use on WRR ports.

•Weighted round robin (WRR)—WRR allows a queue to use more than the allocated bandwidth if the other queues are not using any, up to the total bandwidth of the port. WRR is the dequeuing algorithm on all other ports.

You can enter percentages or weights to allocate bandwidth. The higher the percentage or weight that is assigned to a queue, the more transmit bandwidth is allocated to it. If you enter weights, the ratio of the weights divides the total bandwidth of the queue. For example, for three queues on a Gigabit Ethernet port, weights of 25:25:50 provide this division:

•Queue 1—250 Mbps

•Queue 2—250 Mbps

•Queue 3—500 Mbps

Note The actual bandwidth allocation depends on the granularity that the port hardware applies to the configured percentages or weights.

To allocate bandwidth between standard transmit queues, perform this task:

Common QoS Scenarios

This section provides sample configurations for some common QoS scenarios. If you already know how to configure PFC QoS for your network or if you need specific configuration information, see the other sections of this chapter.

The scenarios in this section are based on a sample network that is described in the "Sample Network Design Overview" section. This section uses this sample network to describe some regularly used QoS configurations.

Sample Network Design Overview

This sample network is based on a traditional campus network architecture that uses Catalyst 6500 series switches in the access, distribution, and core layers. The access layer provides 10/100 Ethernet service to desktop users. The network has Gigabit Ethernet links from the access layer to the distribution layer and Gigabit or 10-Gigabit Ethernet links from the distribution layer to the core layer.

This is the basic port configuration:

Access Layer

switchport mode access

switchport access vlan 10

switchport voice vlan 110

Distribution and Core Interswitch Links

switchport mode trunk

These are the three traffic classes in the sample network:

•Voice

•High-priority application traffic

•Best-effort traffic

The QoS configuration described in this section identifies and prioritizes each of these traffic classes.

Note If your network requires more service levels, PFC QoS supports up to 64 traffic classes.

These QoS scenarios describe the following three fundamental QoS configurations, which are often a general part of QoS deployment:

•Classifying traffic from PCs and IP phones in the access layer

•Accepting the traffic priority value on interswitch links between layers

•Prioritizing traffic on interswitch links between layers

These QoS scenarios assume that the network carries only IP traffic and use the IP DSCP values to assign traffic priority. These QoS scenarios do not directly use IP type of service (ToS) or Ethernet 802.1p class of service (CoS).

IP packets can carry a priority value, which can be set at various points within the network topology. Best-practice design recommendations are to classify and mark traffic as close to the source of the traffic as possible. If traffic priorities are set correctly at the edge, then intermediate hops do not have to perform detailed traffic identification. Instead, they can administer QoS policies based on these previously set priority values. This approach simplifies policy administration.

Note•You should develop a QoS deployment strategy for assigning packet priorities to your particular network traffic types and applications. For more information on QoS guidelines, see RFC 2597 and RFC 2598 as well as the various QoS design guides published by Cisco Systems, Inc.

•Do not enable PFC QoS globally and leave all other PFC QoS configuration at default values. When you enable PFC QoS globally, it uses its default values. These are two problems that exist with the PFC QoS default configuration:

–With PFC QoS globally enabled, the default trust state of the Ethernet ports in the system is untrusted. The untrusted port state sets the QoS priority of all traffic flowing through the switch to the port CoS value (zero by default): all traffic will be zero-priority traffic.

–With PFC QoS globally enabled, the port buffers are allocated into CoS-based queues and only part of the buffer is available for zero-priority traffic: zero-priority traffic has less buffer available than when PFC QoS is disabled.

These problems with the PFC QoS default configuration can have a negative effect on network performance.

Classifying Traffic from PCs and IP Phones in the Access Layer

The access layer switches have a PC daisy-chained to an IP phone on a 100 Mbps link. This section describes how to classify voice traffic from the phone and data traffic from the PC so that they have different priorities.

This is the QoS classification scheme for the traffic arriving on an access layer port:

•Voice traffic: DSCP 46 (highest priority)

•Voice signaling traffic: DSCP 24 (medium priority)

•PC SAP traffic: DSCP 25 (medium priority)

•All other PC traffic: DSCP 0 (best effort)

This classification strategy provides a way to support three different classes of service on the network:

•High priority for voice traffic

•Medium priority for voice signaling and important application traffic

•Low priority for the remaining traffic

You can alter this model to fit other network environments.

PFC QoS can trust received priorities or assign new priorities by applying a QoS policy to the traffic. You configure a QoS policy using the Modular QoS CLI (MQC). In the access switches, the traffic is identified using ACLs, which differentiate the various traffic types entering the port. Once identified, a QoS policy marks the traffic with the appropriate DSCP value. These assigned DSCP values will be trusted when the traffic enters the distribution and core switches.

The port on the access switch where the phone and PC are attached has been configured for a voice VLAN (VLAN 110), which is used to separate the phone traffic (subnet 10.1.110.0/24) from the PC traffic (10.1.10.0/24). The voice VLAN subnet uniquely identifies the voice traffic. The UDP and TCP port numbers identify the different applications.

This is the access port access control list (ACL) configuration:

Identify the Voice Traffic from an IP Phone (VVLAN)

ip access-list extended CLASSIFY-VOICE

permit udp 10.1.110.0 0.0.0.255 any range 16384 32767

Identify the Voice Signaling Traffic from an IP Phone (VVLAN)

ip access-list extended CLASSIFY-VOICE-SIGNAL

permit udp 10.1.110.0 0.0.0.255 any range 2000 2002

Identify the SAP Traffic from the PC (DVLAN)

ip access-list extended CLASSIFY-PC-SAP

permit tcp 10.1.10.0 0.0.0.255 any range 3200 3203

permit tcp 10.1.10.0 0.0.0.255 any eq 3600 any

ip access-list extended CLASSIFY-OTHER

permit ip any any

The next step in configuring the QoS policy is to define the class maps. These class maps associate the identifying ACLs with the QoS actions that you want to perform (marking, in this case). This is the syntax for the class maps:

class-map match-all CLASSIFY-VOICE

match access-group name CLASSIFY-VOICE

class-map match-all CLASSIFY-VOICE-SIGNAL

match access-group name CLASSIFY-VOICE-SIGNAL

class-map match-all CLASSIFY-PC-SAP

match access-group name CLASSIFY-PC-SAP

class-map match-all CLASSIFY-OTHER

match access-group name CLASSIFY-OTHER

After you create the class maps, create a policy map that defines the action of the QoS policy so that it sets a particular DSCP value for each traffic type or traffic class. This example creates one policy map (called IPPHONE-PC), and all the class maps are included in that single policy map, with an action defined in each class map. This is the syntax for the policy map and class maps:

policy-map IPPHONE-PC

class CLASSIFY-VOICE

set dscp ef

class CLASSIFY-VOICE-SIGNAL

set dscp cs3

class CLASSIFY-PC-SAP

set dscp 25

class CLASSIFY-OTHER

set dscp 0

At this point, the QoS policy defined in the policy map still has not taken effect. After you configure a policy map, you must apply it to an interface for it to affect traffic. You use the service-policy command to apply the policy map. Remember that an input service policy can be applied to either a port or to VLAN interfaces, but that an output service policy can only be applied to VLAN interfaces (only the PFC3 supports output policies). In this example, you apply the policy as an input service-policy to each interface that has a PC and IP phone attached. This example uses port-based QoS, which is the default for Ethernet ports.

interface FastEthernet5/1

service-policy input IPPHONE-PC

A QoS policy now has been successfully configured to classify the traffic coming in from both an IP phone and a PC.

To ensure that the policy maps are configured properly, enter this command:

Router# show policy-map interface fastethernet 5/1

FastEthernet5/1

Service-policy input:IPPHONE-PC

class-map:CLASSIFY-VOICE (match-all)

Match:access-group name CLASSIFY-VOICE

set dscp 46:

class-map:CLASSIFY-PC-SAP (match-all)

Match:access-group name CLASSIFY-PC-SAP

set dscp 25:

class-map:CLASSIFY-OTHER (match-all)

Match:access-group name CLASSIFY-OTHER

set dscp 0:

class-map:CLASSIFY-VOICE-SIGNAL (match-all)

Match:access-group name CLASSIFY-VOICE-SIGNAL

set dscp 24:

To ensure that the port is using the correct QoS mode, enter this command:

Accepting the Traffic Priority Value on Interswitch Links

The previous section described how to configure the marking operation. This section describes how the upstream devices will use the packet marking.

You must decide whether the incoming traffic priority should be honored or not. To implement the decision, you configure the trust state of the port. When traffic arrives on a port that is set not to trust incoming traffic priority settings, the priority setting of the incoming traffic is rewritten to the lowest priority (zero). Traffic that arrives on an interface that is set to trust incoming traffic priority settings retains its priority setting.

Examples of ports on which it might be valid to trust incoming priority settings are ports that are connected to IP phones and other IP voice devices, video devices, or any device that you trust to send frames with a valid predetermined priority. If you know that appropriate marking is completed when traffic first enters the network, you may also want to set uplink interfaces to trust the incoming priority settings.

Configure ports that are connected to workstations or any devices that do not send all traffic with a predetermined valid priority as untrusted (the default).

In the previous example, you configured QoS to properly mark the voice, SAP, and other best effort traffic at the access layer. This example configures QoS to honor those values as the traffic passes through other network devices by configuring the interswitch links to trust the packet DSCP values.

The previous example had several different traffic classes entering a port and selectively applied different QoS policies to the different traffic types. The configuration was done with the MQC QoS policy syntax, which allows you to apply different marking or trust actions to the different traffic classes arriving on a port.

If you know that all traffic entering a particular port can be trusted (as is the case on access-distribution or distribution-core uplink ports), you can use the port trust configuration. Using port trust does not provide any support for different traffic types entering a port, but it is a much simpler configuration option. This is the command syntax for port trust:

interface gigabitethernet 5/1

mls qos trust dscp

With ports configured to trust received DSCP, the DSCP value for the traffic leaving the switch will be the same as the DSCP value for the traffic entering the trusted ports. After you have configured the trust state, you can use the following commands to verify that the setting has taken effect:

Router# show queueing interface gigabitethernet 5/1 | include Trust

Trust state:trust DSCP

Prioritizing Traffic on Interswitch Links

This section describes how the switches operate using trusted values.

One of the most fundamental principles of QoS is to protect high-priority traffic in the case of oversubscription. The marking and trusting actions described in the "Classifying Traffic from PCs and IP Phones in the Access Layer" section and the "Accepting the Traffic Priority Value on Interswitch Links" section prepare the traffic to handle oversubscription, but they do not provide different levels of service. To achieve differing levels of service, the networking device must have an advanced scheduling algorithm to prioritize traffic as it sends traffic from a particular interface. This scheduling function is responsible for transmitting the high-priority traffic with greater frequency than the low-priority traffic. The net effect is a differentiated service for the various traffic classes.

These two concepts are fundamental to the provision of differentiated service for various traffic classes:

•Assigning the traffic to a particular queue

•Setting the queue scheduling algorithm

Once QoS has been enabled, default values are applied for both of these features. For many networks, these default values are sufficient to differentiate the network traffic. For other networks, theses values might need to be adjusted to produce the desired result. Only in rare cases should there be a need for significant changes from the default settings for these features.

The Ethernet ports support a variety of queue structures, ranging from a single queue up to an eight-queue architecture. You can compare the queue structure to a group of traffic lanes used to service different traffic types. For example, the police get prioritized treatment when driving down the freeway so that they can get to accidents or crime scenes quickly. In an analogous way, the voice traffic on an IP network requires the same prioritized treatment. The switch uses the queue structure to provide these lanes of differentiated service.

The exact queue type is specific to the Ethernet module that you are working with. This example uses a module that has four transmit queues, described as 1p3q8t, which indicates:

The Ethernet ports also have input queue structures, but these are used less often, and because there probably will not be congestion within the switch fabric, this example does not include them.

To assign traffic to these queues, you need to configure a mapping of priority values to queues. QoS uses the DSCP-to-CoS map to map the 64 possible outgoing DSCP values to the eight possible 802.1p values, and then uses a CoS-to-queue map to map the CoS values to queues.

The example marked the voice traffic with a DSCP value of 46. You can use the command output to translate DSCP 46 to CoS 5. You can use the command output to translate the other marked DSCP values to CoS values.

You can make changes to this mapping table to suit the needs of your particular network. Only minor changes are typically necessary; this example does not make any changes.

For queueing purposes, the configuration derives a CoS value from the outgoing DSCP value. This CoS value is used for queue assignment even if the outgoing port is an access port (that is, not a trunk port). However, there will be no 802.1q VLAN tag transmitted on the network if the outgoing port is an access port.

Map each derived CoS value to the queue structure. This example shows how to display the default CoS-to-queue mapping, which shows the queue to which each of the eight CoS values is mapped:

Router# show queueing interface gigabitethernet 5/1 | begin cos-map

queue thresh cos-map

---------------------------------------

1 1 0

1 2 1

1 3

1 4

1 5

1 6

1 7

1 8

2 1 2

2 2 3 4

2 3

2 4

2 5

2 6

2 7

2 8

3 1 6 7

3 2

3 3

3 4

3 5

3 6

3 7

3 8

4 1 5

<output truncated>

You want voice traffic mapped to the strict priority queue, which is queue 4 on 1p3q8t ports. The example maps the DSCP 46 voice traffic to CoS 5, which means that you want the CoS 5 traffic to be mapped to the strict priority queue, and you can use the output of the show queueing interface command to verify that CoS 5 traffic is mapped to the strict priority queue.

This is a list of the queue mappings for all of the traffic types in this example:

Traffic Type

DSCP

CoS (from DSCP-to-CoS map)

Output Queue

Voice

46

5

Strict Priority

Voice signaling

24

3

Queue 2, Threshold 2

PC SAP

25

3

Queue 2, Threshold 2

Other traffic

0

0

Queue 1, Threshold 1

Traffic that is transmitted through the switch is directed to these different queues (or "traffic lanes") based on priority. Because there are more CoS values (zero through seven) than egress queues (three per interface in this example), there are drop thresholds in each standard (that is, nonstrict priority) queue. When more than one CoS value is assigned to a given queue, different drop thresholds can be assigned to these CoS values to distinguish between the different priorities. The thresholds specify the maximum percentage of the queue that traffic with a given CoS value can use before additional traffic with that CoS value is dropped. The example only uses three QoS values (high, medium, and low), so you can assign each CoS value to a separate queue and use the default 100-percent drop thresholds.

Now you understand how traffic is assigned to the available queues on the output ports of the switch. The next concept to understand is how the queue weights operate, which is called the queue scheduling algorithm.

The scheduling algorithms used on the Ethernet ports are strict priority (SP) queueing and weighted round robin (WRR) queueing. These algorithms determine the order, or the priority, that the various queues on a port are serviced.

The strict priority queueing algorithm is simple. One queue has absolute priority over all of the other queues. Whenever there is a packet in the SP queue, the scheduler will service that queue, which ensures the highest possibility of transmitting the packet and the lowest possible latency in transmission even in periods of congestion. The strict priority queue is ideal for voice traffic because voice traffic requires the highest priority and lowest latency on a network, and it also is a relatively low-bandwidth traffic type, which means that voice traffic is not likely to consume all available bandwidth on a port. You would not want to assign a high-bandwidth application (for example, FTP) to the strict priority queue because the FTP traffic could consume all of the bandwidth available to the port, starving the other traffic classes.

The WRR algorithm uses relative weights that are assigned to the WRR queues. If there are three queues and their weights are 100:150:200 (which are the default settings), then queue 1 gets only 22 percent of the available bandwidth, queue 2 gets 33 percent, and queue 3 gets 45 percent. With WRR, none of the queues are restricted to these percentages. If queue 2 and queue 3 do not have any traffic, queue 1 can use all available bandwidth.

In this example, queue 1 has a lower priority than queue 2, and queue 2 has a lower priority than queue 3. The low-priority traffic (phone-other and PC-other) maps to queue 1, and the medium-priority traffic (voice-signaling and PC-SAP) maps to queue 2.

The strict-priority queue does not require any configuration after traffic has been mapped to it. The WRR queues have a default bandwidth allocation that might be sufficient for your network; if it is not, then you can change the relative weights to suit your traffic types (see the "Allocating Bandwidth Between Standard Transmit Queues" section).

The best way to verify that the switch is handling oversubscription is to ensure that there is minimal packet drop. Use the show queueing interface command to determine where that packet loss is happening. This command displays the number of dropped packets for each queue.

Using Policers to Limit the Amount of Traffic from a PC

Rate limiting is a useful way of ensuring that a particular device or traffic class does not consume more bandwidth than expected. On the Ethernet ports, the supported rate-limiting method is called policing. Policing is implemented in the PFC hardware with no performance impact. A policer operates by allowing the traffic to flow freely as long as the traffic rate remains below the configured transmission rate. Traffic bursts are allowed, provided that they are within the configured burst size. Any traffic that exceeds the configured rate and burst can be either dropped or marked down to a lower priority. The benefit of policing is that it can constrain the amount of bandwidth that a particular application consumes, which helps ensure quality of service on the network, especially during abnormal network conditions such as a virus or worm attack.

This example focuses on a basic per-interface aggregate policer applied to a single interface in the inbound direction, but you can use other policing options to achieve this same result.

The policing syntax is similar enough that we can use the marking example ACL and modify the marking example class map by replacing the set dscp command with a police command. This example reuses the CLASSIFY-OTHER class-map to identify the traffic with a modified IPPHONE-PC policy map to police the matched traffic to a maximum of 50 Mbps, while continuing to mark the traffic that conforms to this rate.

The class maps and the ACL and class-map commands that are used to identify the "other" traffic are included below for reference; no changes have been made.

•ACL commands:

ip access-list extended CLASSIFY-OTHER

permit ip any any

•Class map commands:

class-map match-all CLASSIFY-OTHER

match access-group name CLASSIFY-OTHER

The difference between this policer configuration and the marking configuration is the policy-map action statements. The marking example uses the set dscp command to mark the traffic with a particular DSCP value. This policing example marks the CLASSIFY-OTHER traffic to a DSCP value of zero and polices that traffic to 50 Mbps. To do this, replace the set dscp command with a police command. The police command allows a marking action to take place: it marks all traffic below the 50 Mbps limit to DSCP 0 and drops any traffic above the 50 Mbps threshold.

This is the modified IPPHONE-PC policy map, which includes the police command:

•The 50000000 parameter defines the committed information rate (CIR) for traffic allowed in this traffic class. This example configures the CIR to be 50 Mbps.

•The 1562500 parameter defines the CIR burst size for traffic in this traffic class; this example uses a default maximum burst size. Set the CIR burst size to the maximum TCP window size used on the network.

•The conform action keywords define what the policer does with CLASSIFY-OTHER packets transmitted when the traffic level is below the 50-Mbps rate. In this example, set-dscp-transmit default applies DSCP 0 to those packets.

•The exceed action defines what the policer does with CLASSIFY-OTHER packets transmitted when the traffic level is above the 50 Mbps CIR. In this example, exceed action drop drops those packets.

This is a basic example of a single rate per-interface aggregate policer. The PFC3 also support a dual-rate policer for providing both CIR and peak information rate (PIR) granularity.

Attach the policy map to the appropriate interface using the service-policy input command:

interface FastEthernet5/1

service-policy input IPPHONE-PC

To monitor the policing operation, use these commands:

show policy-map interface fastethernet 5/1

show class-map

show mls qos ip fastethernet 5/1

PFC QoS Glossary

This section defines some of the QoS terminology used in this chapter:

•Buffers—A storage area used for handling data in transit. Buffers are used in internetworking to compensate for differences in processing speed between network devices. Bursts of data can be stored in buffers until they can be handled by slower processing devices. Sometimes referred to as a packet buffer.

•Class of service (CoS) is a Layer 2 QoS label carried in three bits of either an ISL, 802.1Q, or 802.1p header. CoS values range between zero and seven.

•Classification is the process used for selecting traffic to be marked for QoS.

•Marking is the process of setting a Layer 3 DSCP value in a packet; in this publication, the definition of marking is extended to include setting Layer 2 CoS values. Marking changes the value of a label.

•Packets carry traffic at Layer 3.

•Policing is limiting bandwidth used by a flow of traffic. Policing is done on the PFC and Distributed Forwarding Cards (DFCs). Policing can mark or drop traffic.

•Queues—Queues are allocations of buffer space used to temporarily store data on a port.

•Scheduling is the assignment of Layer 2 frames to a queue. PFC QoS assigns frames to a queue based on Layer 2 CoS values.

•Shaped round robin (SRR) is a dequeuing algorithm.

•Threshold—Percentage of queue capacity above which traffic is dropped.

•Type of service (ToS) is a one-byte field that exists in an IP version 4 header that is used to specify the priority value applied to the packet. The ToS field consists of eight bits. The first three bits specify the IP precedence value, which can range from zero to seven, with zero being the lowest priority and seven being the highest priority. The ToS field can also be used to specify a DSCP value. DSCP is defined by the six most significant bits of the ToS. DSCP values can range from 0 to 63.

•Weight—Ratio of bandwidth allocated to a queue.

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples and troubleshooting information), see the documents listed on this page: