Cisco IOS XR QoS: Class-Map, Policy-Map and Shaping Examples

Cisco IOS XR implements QoS through the Modular QoS CLI (MQC), the same class-map / policy-map model used on IOS but with XR-specific syntax such as end-class-map, commit-based configuration and per-class shaping on ASR 9000 routers. This article walks through a complete IOS XR QoS configuration: defining traffic classes, building a policy-map with shaping and policing actions, attaching it to an interface, and verifying with show commands - based on the official Cisco ASR 9000 Modular QoS configuration guide.

The MQC Building Blocks on IOS XR

MQC has three stages: class-map selects traffic (match on precedence, DSCP, ACL, CoS, EXP...), policy-map defines what happens to each class (set, police, shape, queue), and service-policy attaches the policy to an interface in the input or output direction. On XR every configuration change must be committed with commit.

Defining a Class-Map

RP/0/RSP0/CPU0:router(config)# class-map class1
RP/0/RSP0/CPU0:router(config-cmap)# match precedence 3
RP/0/RSP0/CPU0:router(config-cmap)# end-class-map
RP/0/RSP0/CPU0:router(config)# commit

Without a match type keyword the class-map defaults to match-any; use class-map match-all when every condition must match.

Building a Policy-Map with Shaping

Shape the priority class at 30 percent and the default class at 20 percent of the interface rate:

RP/0/RSP0/CPU0:router(config)# policy-map policy1
RP/0/RSP0/CPU0:router(config-pmap)# class class1
RP/0/RSP0/CPU0:router(config-pmap-c)# shape average percent 30
RP/0/RSP0/CPU0:router(config-pmap-c)# exit
RP/0/RSP0/CPU0:router(config-pmap)# class class-default
RP/0/RSP0/CPU0:router(config-pmap-c)# shape average percent 20
RP/0/RSP0/CPU0:router(config-pmap-c)# end-policy-map
RP/0/RSP0/CPU0:router(config)# commit

Class order matters: XR programs classes into TCAM in the order they appear in the policy-map and applies the first matching class, so put more specific matches first.

Policing and Marking Actions

Police limits the rate and can mark conform/exceed traffic differently, while set rewrites fields. The example below polices class c1 at 10 Mbps peak 20 Mbps and remarks DSCP per action:

policy-map p1
 class c1
  set dscp af11
  set cos 5
  police rate 10 mbps peak-rate 20 mbps
   conform-action set dscp af12
   conform-action set cos 6
   exceed-action set dscp af13
   exceed-action set cos 4
 end-policy-map

Attaching the Policy to an Interface

RP/0/RSP0/CPU0:router(config)# interface TenGigE0/0/0/0
RP/0/RSP0/CPU0:router(config-if)# service-policy output policy1
RP/0/RSP0/CPU0:router(config-if)# commit

Verification Commands

show policy-map interface TenGigE0/0/0/0
show running-config policy-map policy1
show qos interface TenGigE0/0/0/0

How MQC Policies Are Programmed on ASR 9000

Understanding what happens underneath the CLI explains most QoS surprises on XR. When you commit a policy-map and attach it to an interface, the router compiles the class-map match conditions into ternary CAM (TCAM) entries and the actions into packet-processing microcode. That translation imposes real limits:

• TCAM is a finite resource. Each interface has a fixed number of policy entries it can hold. Adding an eleventh class to an interface that supports ten will fail at commit time with an explicit error rather than silently dropping traffic.
• Match conditions are evaluated in order. The first class that matches wins, exactly as in an ACL. Overlapping classes therefore produce surprising results, and a broad class-default placed first would swallow everything.
• Not every action is available on every line card. Shaping, policing, WRED, marking and queueing are all supported on ASR 9000 Ethernet line cards, but combinations and counts depend on the platform and the number of queues per interface. The show qos interface output tells you what was actually programmed.
• Hierarchical QoS (H-QoS) changes the model. On ASR 9000 you can attach a policy-map to a bundle and a second, different policy to the bundle members, giving per-subscriber shaping under a per-aggregate scheduler. When you do this, the parent policy's bandwidth is the envelope the child policies must fit inside.

Match Criteria in Depth

Class-maps select traffic with a small set of match types. Getting the operator right matters because XR validates it at commit:

class-map match-any VOICE
 match dscp ef
 match precedence 5
end-class-map
!
class-map match-all BULK-DATA
 match precedence 1
 match access-group ipv4 BULK-ACL
end-class-map
!
class-map match-any CONTROL
 match precedence 6 7
 match cos 5
end-class-map

Key points:

• match-any is the default and behaves like a logical OR; match-all is a logical AND.
• match precedence, match dscp, match cos, match mpls experimental topmost and match access-group are the workhorses. DSCP and precedence matches cannot be combined arbitrarily in one class on all platforms, so separate the IP-layer and layer-2 matches when in doubt.
• A class with no match statement is illegal except for class-default, which exists implicitly.
• IP precedence is three bits (values 0–7); DSCP is six bits (values 0–63 or the AF/EF names). Remember that IP precedence is simply the top three bits of the DSCP field, so dscp 32, dscp cs4 and precedence 4 describe the same bits.

Low-Latency Queueing: Combining Priority and Shaping

Voice and video need a queue that is drained before the others. On XR this is the priority action, and it can be combined with an explicit shaping rate to cap the amount of traffic the priority queue can consume — the recommended practice, because an unshaped priority queue can starve every other class when it misbehaves:

policy-map LATENCY
 class VOICE
  priority level 1
  police rate percent 10
 class CONTROL
  bandwidth remaining percent 10
  queue-limit 64 packets
 class class-default
  bandwidth remaining percent 90
  random-detect dscp-based
 end-policy-map

priority level 1 and level 2 let you build two strict-priority tiers, for example voice above signalling. The police statement inside the class limits that queue to 10 percent of the interface rate. Note the contrast with the shaping example earlier in this article: shape average percent 30 smooths traffic into a token bucket and buffers the excess, whereas police drops or remarks the excess immediately.

Policing Versus Shaping: Choosing Correctly

Both actions enforce a rate, but they behave in opposite ways on congestion and they belong in different places in the network:

• Shaping buffers packets that exceed the configured rate and transmits them later, so it produces delay and jitter but almost no loss. Use shaping on egress towards a slower link — a sub-rate hand-off, a satellite or MPLS access circuit, or a customer port where you are the sender.
• Policing drops or re-marks packets that exceed the rate, so it produces loss but no added delay. Use policing on ingress to enforce a contract, to protect the router's own control plane, and to cap priority queues.

A practical rule: shape what you send, police what you receive. Applying shaping on ingress or policing on your own egress towards a customer generally creates either burst-loss or unnecessary delay.

Bandwidth Guarantees Versus Bandwidth Remaining

XR offers two ways to give a class a share of the link, and confusing them is one of the most common QoS design errors:

• bandwidth percent 30 reserves 30 percent of the interface rate for that class, consumed whether or not the class uses it.
• bandwidth remaining percent 30 gives the class 30 percent of whatever bandwidth is left after the strict-priority and guaranteed classes have taken theirs.

Mixing the two in one policy is allowed but the arithmetic must add up. If the sum of all guaranteed bandwidths exceeds the interface rate, the commit fails on most platforms or the policy is scaled down at programming time. Check the result with show policy-map interface, which prints the actual programmed rates rather than the percentages you typed.

Congestion Avoidance and Marking

Where shaping provides a queue, congestion avoidance decides which packets to drop from it. Weighted Random Early Detection (random-detect) drops packets before the queue is full so that TCP senders back off gradually instead of collapsing in a synchronised global retransmit:

policy-map SHAPE-AND-DROP
 class BULK-DATA
  shape average percent 40
  bandwidth remaining percent 40
  random-detect dscp-based
  random-detect precedence 1 40 60 10
 class class-default
  bandwidth remaining percent 60
 end-policy-map

The three numbers after random-detect precedence are minimum threshold, maximum threshold and mark probability denominator. A simpler alternative is random-detect dscp-based, which derives thresholds from an internal DSCP table. On data-centre fabrics running RoCE you would instead pair marking with ECN (random-detect ecn) so that congestion is signalled rather than dropped — the same principle as DCQCN in lossless Ethernet designs, and a good example of why the trust boundary matters before any of this. Marking with set dscp and set cos should generally be done as close to the source as possible, which is a switch or access-port responsibility rather than a core router one.

Common Errors and How to Debug Them

When a QoS policy "does not work", the cause is usually one of these:

• The policy is not attached. show running-config interface TenGigE0/0/0/0 and show qos interface TenGigE0/0/0/0 both must show the service-policy. A mismatch in direction (input versus output) attaches successfully but does nothing.
• The configuration was never committed. On XR this is the first thing to check; show configuration reveals an uncommitted diff.
• Match counters stay at zero. Either the traffic is not arriving, or the match is on the wrong field. Use show policy-map interface TenGigE0/0/0/0 output and read the per-class Classified counters before blaming queues.
• Input drops appear instead. Well-intentioned input policy-maps can exceed the interface's ability to buffer. If you see input drops or NP counters climbing, cross-check with IOS XR input drops and NP counters.
• TCAM exhaustion at commit. Reduce the number of classes per interface or replace long ACL matches with DSCP matches.
• Shaping below the line rate produces unexpected latency. Shaping on a 10G link to 5 Gbps creates a queue and therefore bufferbloat; size the queue with queue-limit and use congestion avoidance, or move the shaping to the aggregation device.

Design Guidelines for a Learnable QoS Baseline

Whatever the platform, a small number of well-tested classes beats a baroque policy nobody can debug. A defensible baseline for a service-provider edge is five classes: a strict-priority voice class with an explicit policer, a signalling class, a real-time video class with remaining-bandwidth guarantees, a business class, and a default class with congestion avoidance. Mark at the edge and trust nothing from the access layer until the access layer has proved it marks correctly. Document the DSCP values you use, because QoS is a cross-team contract: the switch team's trust boundary and the router team's policy-map must describe the same bit patterns.

Related Guides on This Site

QoS problems often show up as drops first - see IOS XR input drops and NP counters, plus IOS XR BGP configuration and XR RPL route policies to complete your router baseline.

原文链接：https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/711x/qos/configuration/guide/b-qos-cg-asr9k-711x/modular-qos-overview.html