The modular framework replaced a collection of per-feature commands with three objects and one idea: separate what traffic is from what should happen to it, and from where that happens. Once those three are separate, a classification written once can be reused everywhere, an action can be changed without touching the classification, and the same policy can be attached in several places.
The framework is straightforward. What is not straightforward is the design decision underneath it, which is where classification happens. A network that identifies traffic deeply at every device is doing the same expensive work repeatedly and arriving at different answers in different places. A network that identifies it once, at the edge, marks the result and trusts that marking afterwards has a scheme it can reason about — and a boundary it has to defend.
This article covers the three objects and why the separation matters, how traffic should be classified and the two matching modes that are constantly confused, where marking belongs and what a trust boundary actually is, which actions act on every packet and which only under congestion, and why the same policy behaves differently on two devices. It is written for the lab rather than for the written exam, and sits alongside the rest of the CCIE Enterprise Infrastructure lab certification track.
The three objects separate what traffic is from what happens to it and from where, which is what allows one classification to be written once and reused across every device in the network.What Are the Three Objects?
How do they relate?
A class map defines what traffic is, using one or more match criteria. A policy map names classes and states what happens to each. A service policy attaches a policy map to an interface in a direction. The separation is the point: the same class map appears in several policies, the same policy is attached in several places, and changing what happens to a class does not require touching the definition of that class.
A Deeper Dive into the Framework
Why the separation matters in practice
A network with forty branch routers needs one definition of what voice traffic is. With the objects separate, that definition exists once, is referenced by every policy, and a correction to it propagates by configuration management rather than by forty edits.
The older per-feature approach embedded the traffic definition in each feature's configuration, which meant the same definition appeared in several places on one device and drifted between them. That drift is the problem the framework removed.
The default class
Every policy has one implicitly: everything that matched no other class. It can be named and given actions like any other, and the traffic that falls into it is frequently more than expected, because a classification scheme that looks complete rarely is.
Reading its counter is the fastest way to find out whether the classification actually covers what it was meant to. A default class carrying a substantial share of the traffic means several things are unclassified, and until they are identified nothing can be said about whether the policy is doing what was intended.
! The three objects, in order
R1(config)# class-map match-any VOICE
R1(config-cmap)# match dscp ef
!
R1(config)# policy-map WAN-OUT
R1(config-pmap)# class VOICE
R1(config-pmap-c)# priority percent 20
R1(config-pmap)# class class-default
R1(config-pmap-c)# fair-queue
!
R1(config)# interface GigabitEthernet0/1
R1(config-if)# service-policy output WAN-OUT
!
! How much is actually unclassified?
R1# show policy-map interface GigabitEthernet0/1 output | section class-default
Order of evaluation
Classes are evaluated in the order they appear and the first match wins. That makes ordering a functional part of the policy rather than a cosmetic one, and it is how exceptions are expressed: put the specific class above the general one.
Getting it backwards produces a class whose counter stays at zero forever. The policy is accepted, the configuration reads correctly, and one class simply never sees a packet because a broader class above it took them all.
show policy-map interface shows zero for the specific class and an inflated count for the one above it. Fix: move the specific class above the general one; ordering is functional, not cosmetic, and this is how exceptions are expressed.Nesting classes
A class map can match another class map, which allows a complex definition to be assembled from simpler ones. That is genuinely useful for expressing something like "business traffic, but not from the guest network" without a long list of criteria in one place.
It is also a readability hazard. Two levels is manageable and three is a definition nobody can evaluate by reading. Where a definition needs three levels, the question is usually whether the classification scheme itself is too complicated.
! Nesting: build a definition from simpler ones
R1(config)# class-map match-any REALTIME
R1(config-cmap)# match dscp ef
R1(config-cmap)# match dscp cs5
!
R1(config)# class-map match-all REALTIME-NOT-GUEST
R1(config-cmap)# match class-map REALTIME
R1(config-cmap)# match not access-group name GUEST-SUBNET
!
! Two levels reads fine. Three does not.
R1# show class-map REALTIME-NOT-GUEST
Reusing a policy in several places
One policy attached to several interfaces behaves independently on each — the counters, the queues and the rates are per attachment. That is what makes a single policy applicable to twenty branch uplinks.
Where the policy contains absolute rates, reuse is limited to interfaces of the same speed. Percentages remove that limit, which is one of several reasons percentages are the better default in any policy intended for more than one place.
| Object | Answers | Reused | Changing it affects |
|---|---|---|---|
| Class map | What is this traffic? | Across every policy | Every policy naming it |
| Policy map | What happens to it? | Across every interface | Every attachment |
| Service policy | Where, and which direction? | — | That interface only |
| Default class | What did we miss? | Implicit in every policy | Read it before trusting anything |
How Should Traffic Be Classified?
What are the criteria?
At the edge, whatever identifies the traffic: addresses and ports through an access list, an application recognition engine, the physical port it arrived on, or an existing marking from a device you trust. Away from the edge, exactly one criterion — the marking. That split is the design. Deep classification is expensive and produces different answers on different platforms; reading a marking is cheap and produces the same answer everywhere.
A Deeper Dive into Classification
The two matching modes
A class requiring any one criterion to match, and a class requiring all of them. The first is for a list of alternatives — several markings that all belong to one class, several ports that all indicate the same application. The second is for a conjunction — traffic from this subnet and to this port.
The confusion is persistent and produces a specific failure: a class requiring all criteria, listing several markings, matches nothing at all, because a packet carries one marking and cannot satisfy two requirements simultaneously. The class is valid, the policy is accepted, and the counter never moves.
! Correct: any one of these markings belongs to the class
R1(config)# class-map match-any BUSINESS
R1(config-cmap)# match dscp af21
R1(config-cmap)# match dscp af22
R1(config-cmap)# match dscp af23
!
! Correct: both conditions must hold
R1(config)# class-map match-all GUEST-WEB
R1(config-cmap)# match access-group name GUEST-SUBNET
R1(config-cmap)# match protocol http
!
! WRONG: a packet cannot have two DSCP values
! class-map match-all BROKEN
! match dscp af21
! match dscp af22 <- this class matches nothing, ever
Access lists as classification
The most explicit criterion and the most maintainable for traffic identified by addresses and ports. A named list per class, referenced by the class map, keeps the definition readable and keeps the class map short.
The semantics are the same as in any classification context: a permit entry means the packet belongs to the class, a deny entry means it does not and evaluation continues to the next class. A deny entry is not a discard, and using it as one sends the traffic to the default class rather than dropping it.
Application recognition
An engine that inspects traffic and names the application it belongs to removes the need to maintain port lists. It is genuinely useful at the edge, where identification has to happen somehow and ports no longer identify much.
Two limits are worth stating plainly. Encrypted traffic cannot be identified by inspecting its contents, so an engine's accuracy on a network where most traffic is encrypted depends on weaker signals. And the cost is per packet on the processor, which makes it an edge tool rather than a core one.
! Edge classification: recognise, then mark and never look again
R1(config)# class-map match-any EDGE-VOICE
R1(config-cmap)# match protocol rtp audio
R1(config)# class-map match-any EDGE-VIDEO
R1(config-cmap)# match protocol rtp video
R1(config)# class-map match-any EDGE-BUSINESS
R1(config-cmap)# match access-group name BUSINESS-APPS
!
R1(config)# policy-map EDGE-MARK
R1(config-pmap)# class EDGE-VOICE
R1(config-pmap-c)# set dscp ef
R1(config-pmap)# class EDGE-VIDEO
R1(config-pmap-c)# set dscp af41
R1(config-pmap)# class EDGE-BUSINESS
R1(config-pmap-c)# set dscp af21
R1(config-pmap)# class class-default
R1(config-pmap-c)# set dscp default
Matching on the marking, everywhere else
Once traffic is marked at the edge, every subsequent device classifies by reading that marking. One criterion, no inspection, no processor cost, and the same answer on every platform regardless of what recognition engine it has.
This is what makes a consistent treatment across a network achievable. A network where each device works out for itself what the traffic is will treat the same flow differently in three places, and reconciling that is not a solvable problem.
How many classes
Enough to express the distinctions that matter and no more. Four to six is typical and adequate: something served first, something guaranteed, something general, and something deliberately last. Twelve classes require twelve well-founded distinctions and twelve sets of measurements to size them.
The practical constraint is the hardware, which has a fixed number of queues on switching platforms. A scheme with more classes than the smallest queue count in the estate cannot be implemented consistently, and the classes that share a queue are chosen by the platform rather than by you.
Documenting the scheme
One table, listing each class, its marking, what belongs in it and why. That table is the network's quality of service design and everything else is an implementation of it.
Its absence is what produces the situation where each device's policy is slightly different and nobody can say which is correct. With it, any policy can be checked against the table in a minute.
Where Does Marking Belong?
What is a trust boundary?
The point at which the network stops believing what arrives and starts believing what it wrote itself. Inside the boundary, a packet's marking was set by the network and is trusted. Outside it — on a port facing a user device — the marking is whatever the device chose to send and must be rewritten. The boundary is normally the access port, and the entire scheme depends on it being enforced there rather than assumed.
A Deeper Dive into Trust
Why the boundary is at the access port
It is the first network device the traffic reaches and the last place where the traffic's origin is unambiguous. Marking there means every packet entering the network carries a marking the network chose, and every device afterwards can read it without deciding whether to believe it.
Moving the boundary inward — trusting the access layer and rewriting at distribution — means the access layer is carrying markings nobody has validated, which matters as soon as the access layer itself applies any queuing.
What an untrusted port must do
Rewrite. Every packet arriving on a user-facing port gets a marking determined by the network's classification, including packets that arrive already marked. A device that marks its own traffic as the highest class is not being malicious, usually — some applications do it by default — and the effect is the same either way.
Rewriting to a default is the safe baseline: everything from an untrusted port is ordinary unless the network's own classification says otherwise. That is one class and one action and it closes the hole completely.
! Untrusted by default on a switch access port
Sw1(config)# interface GigabitEthernet1/0/12
Sw1(config-if)# switchport mode access
Sw1(config-if)# service-policy input EDGE-MARK
!
! A trusted device gets an exception, conditionally
Sw1(config)# interface GigabitEthernet1/0/13
Sw1(config-if)# trust device cisco-phone
!
! Confirm what the port is doing
Sw1# show policy-map interface GigabitEthernet1/0/12 input
Sw1# show run interface GigabitEthernet1/0/13 | include trust
Conditional trust
A telephone marks its own traffic correctly and also forwards traffic from a computer plugged into it. Trusting the port outright trusts both. Conditional trust solves this: the port trusts markings only while a recognised telephone is present, and the phone itself is responsible for rewriting what the computer behind it sends.
The dependency is on the discovery protocol that identifies the phone. Disabling that protocol as part of a hardening exercise removes the recognition, the port stops trusting, and every call from that desk is marked as ordinary traffic. The two configurations are in different documents maintained by different people, which is why this happens.
The two marking fields
One in the Ethernet header, one in the IP header. The first exists only within a Layer 2 domain and is lost the moment a packet is routed. The second travels end to end.
The practical rule is to carry the decision in the IP field, because that is the one that survives. The Ethernet field matters where a switch makes queuing decisions before routing, and it should be derived from the IP field rather than maintained independently — two fields maintained separately will disagree.
Marking at the edge, not at the WAN
A common shortcut is to classify and mark on the WAN router, where the congestion is. It works, and it means every device between the user and the WAN router has treated the traffic as ordinary, including any congested link in the campus.
It also means the classification has to be maintained on the WAN routers rather than in one place, and that WAN routers are doing deep inspection they would not otherwise need to do. Marking at the edge costs one policy on access ports and removes both problems.
Remarking on the way out
A carrier may require a different marking scheme from the one used internally, or may only honour a subset. Translating at the handover — internal scheme to the carrier's scheme, on the way out — keeps the internal design clean and satisfies the contract.
What must be checked is what the carrier does with markings it does not recognise. Some rewrite them to default, which means the return traffic arrives unmarked and the internal classification has to be reapplied on ingress from the WAN. Reading this once is not the same as being able to do it under time pressure, which is what repetition against realistic CCIE lab practice scenarios is for.
! Translate to the carrier's scheme on the way out
R1(config)# policy-map WAN-REMARK
R1(config-pmap)# class VOICE
R1(config-pmap-c)# set dscp ef
R1(config-pmap)# class BUSINESS
R1(config-pmap-c)# set dscp af31
R1(config-pmap)# class class-default
R1(config-pmap-c)# set dscp default
!
! And restore the internal scheme on the way back in
R1(config)# interface GigabitEthernet0/1
R1(config-if)# service-policy input WAN-IN-RECLASSIFY
R1(config-if)# service-policy output WAN-PARENT
| Port faces | Trust | Action | Why |
|---|---|---|---|
| A general user device | No | Classify and mark | Anything can mark itself |
| A telephone | Conditionally | Trust while recognised | It marks correctly and shelters a PC |
| Another network device | Yes | Read the marking only | Inside the boundary |
| A carrier handover | No, inbound | Reclassify on ingress | They may have rewritten it |
| A server | Depends | Usually classify and mark | Applications mark themselves badly |
Which Actions Act Always, and Which Only Under Congestion?
What is the split?
Marking and policing act on every packet, always, regardless of load. Queuing actions — guaranteed bandwidth, strict priority, early discard — act only when a queue exists, which means only when the interface cannot transmit immediately. Shaping is in between: it acts whenever traffic exceeds the rate, which creates the queue the queuing actions then need. A policy combining both kinds has half of it working continuously and half of it waiting for congestion that may never arrive on that interface.
A Deeper Dive into the Actions
Marking, which always works
A set action rewrites a field on every packet in the class. There is no condition and no dependency on load, which is why a marking policy can be verified immediately after applying it by looking at the counters.
This is also why marking policies are the reliable part of any deployment: they either work or they do not, and it is visible at once.
Policing, which also always works
A policer measures the rate and applies an action to traffic above it — discard, or rewrite the marking to something more likely to be discarded later. It acts regardless of whether the interface is congested, because it is enforcing a rate rather than managing a queue.
Remarking rather than discarding is the more useful configuration in many cases: excess traffic is permitted through but marked so that it is the first thing discarded if congestion does occur later. That requires the rest of the network to honour the remarking, which brings the design back to the trust boundary.
! Police inbound: excess is marked down, not discarded
R1(config)# policy-map EDGE-POLICE
R1(config-pmap)# class BUSINESS
R1(config-pmap-c)# police cir 10000000 bc 625000
R1(config-pmap-c-police)# conform-action transmit
R1(config-pmap-c-police)# exceed-action set-dscp-transmit af22
R1(config-pmap-c-police)# violate-action set-dscp-transmit af23
!
R1(config)# interface GigabitEthernet0/0
R1(config-if)# service-policy input EDGE-POLICE
!
! Policing counters move immediately, congested or not
R1# show policy-map interface GigabitEthernet0/0 input | include conform|exceed|violate
Queuing, which waits for congestion
Guaranteed bandwidth and strict priority decide the order in which a queue is drained. No queue, no decision. On an interface that is never full, these statements are present, accepted and inert.
That is the single most common reason a policy appears to do nothing, and it is covered in depth elsewhere: the remedy is a shaper that creates the congestion point deliberately where the physical interface is faster than the real capacity.
Early discard, which needs a queue that is filling
Discarding a few packets as a queue grows works well for traffic that responds by slowing down, and it requires the queue to exist and to be partially full. On an interface that goes from empty to overflowing in a burst, it has little opportunity to act.
It should be applied to classes whose traffic is responsive and never to a priority class, which does not slow down in response to loss and simply degrades.
Direction, and what is allowed where
Marking and policing are available in both directions. Queuing and shaping are outbound only, because both concern how traffic leaves an interface. A policy containing queuing actions attached inbound will be rejected, or will silently do nothing depending on the platform.
The practical arrangement follows from this. Inbound at the edge: classify, mark, police. Outbound toward congestion: shape and queue. Those are two different policies with different contents, and trying to write one policy for both directions produces something that is wrong in one of them.
! Two policies, two directions, different contents
R1(config)# interface GigabitEthernet0/0
R1(config-if)# description To the campus
R1(config-if)# service-policy input EDGE-MARK
!
R1(config)# interface GigabitEthernet0/1
R1(config-if)# description To the WAN
R1(config-if)# service-policy output WAN-PARENT
!
! Confirm each is where it should be
R1# show policy-map interface brief
R1# show running-config | include service-policy
Verifying an action actually fires
Marking and policing can be verified at any time from the counters. Queuing cannot, because it does not act without congestion, and confirming it works therefore requires generating load deliberately.
A few minutes of load at commissioning, with the queue depth and per-class drops observed, is the only way to establish that the queuing half of a policy does anything. It is skipped almost universally and it is the difference between a policy that is configured and a policy that is known to work.
| Action | Acts when | Direction | Verified by |
|---|---|---|---|
| set | Always | In or out | Counters, immediately |
| police | Always | In or out | Counters, immediately |
| shape | Above the rate | Out only | Queue depth under load |
| bandwidth / priority | Only with a queue | Out only | Generated load |
| random-detect | As a queue fills | Out only | Generated load |
Why Does the Same Policy Behave Differently in Two Places?
What causes the difference?
Platform implementation. A router queues in software with as many queues as the policy names. A switch queues in hardware with a fixed number, and a policy naming more classes than there are queues is mapped onto what exists — accepted without error, behaving differently from what it says. Beyond that, supported actions, supported directions and the units in which limits are expressed all vary, and none of it is visible in the configuration.
A Deeper Dive into Platform Differences
The queue count
The most consequential difference. A six-class policy on a platform with four queues results in classes sharing queues, chosen by the platform's mapping rather than by the design. Two classes intended to be separate are serviced together, and the distinction the design depended on does not exist.
The answer is to design the class scheme to the smallest queue count in the estate. A four-class scheme implemented identically everywhere is worth more than a six-class scheme implemented differently in three places.
Trust behaviour by default
Platforms differ in whether an unconfigured port trusts incoming markings. On some, markings pass through untouched; on others they are rewritten to default. A network with both, and no explicit trust configuration, has markings surviving in some places and not others.
Configuring it explicitly everywhere removes the question. It is a line per port range and it makes the behaviour a property of the configuration rather than of the platform.
! Never rely on the default. State it.
Sw1(config)# interface range GigabitEthernet1/0/1 - 48
Sw1(config-if-range)# service-policy input EDGE-MARK
!
Sw1(config)# interface TenGigabitEthernet1/0/1
Sw1(config-if)# description Uplink - inside the trust boundary
Sw1(config-if)# trust device none
!
! What the platform actually supports
Sw1# show platform hardware fed switch active qos queue config interface Te1/0/1
Sw1# show policy-map interface Te1/0/1
Where limits are expressed differently
Queue limits appear as packets on one platform, bytes on another and time on a third. A value that is correct in one unit is meaningless in another, and a policy copied between platforms carries a number that no longer means what it did.
Time is the most useful unit because it expresses the thing that matters — how long a packet can wait. Where only packets are available, the equivalent time depends on the rate, which means the same number is a different delay on a ten megabit circuit and a hundred megabit one.
Actions that are accepted and not implemented
Some platforms accept a policy containing an action they do not support, and simply do not perform it. There is no error and no indication in the running configuration; the only evidence is the absence of an effect.
Checking the policy against the platform's capability before deployment is the only defence. The per-interface policy output usually shows what is actually installed, which is a more reliable source than the running configuration.
A commissioning checklist
Six items. The policy is attached in the intended direction. The default class carries a small and understood share. Every class has a non-zero counter. Marking counters increment immediately. Queue depth grows under generated load. And per-class drops under that load match the intent — bulk dropping, priority not.
All six are quick, and the fifth and sixth require load. That is the part that gets skipped and the part that distinguishes a policy that works from one that is merely present.
! Six checks, the last two under load
R1# show running-config | include service-policy
R1# show policy-map interface GigabitEthernet0/1 | section class-default
R1# show policy-map interface GigabitEthernet0/1 | include Class-map
R1# show policy-map interface GigabitEthernet0/1 | include packets
!
! With traffic generated:
R1# show policy-map interface GigabitEthernet0/1 output | include depth
R1# show policy-map interface GigabitEthernet0/1 output | include drops
What to monitor afterwards
The default class's share, whose growth means new traffic has appeared that nobody classified. Per-class drops, which are the direct evidence the policy is acting. And the marked packet counts at the edge, whose ratio to total traffic tells you whether the trust boundary is doing its job.
The first of those is the one that decays without anybody noticing. A classification scheme written three years ago covers the applications of three years ago, and the drift shows up as a default class that is quietly carrying a third of the traffic.
Blueprint framing
The CCIE Enterprise Infrastructure v1.1 blueprint covers quality of service within its infrastructure services domain, and the modular framework is the mechanism through which all of it is expressed. What is examined tends to be the framework and the classification semantics — matching modes, class ordering, and which actions are permitted in which direction — rather than a large policy build.
| Difference | Router | Switch | Consequence |
|---|---|---|---|
| Queue count | As many as named | Fixed by hardware | Classes share queues |
| Default trust | Varies | Varies | Configure it explicitly |
| Queue limit units | Packets or time | Often packets only | Copied values are wrong |
| Unsupported actions | Usually rejected | Sometimes accepted silently | No effect, no error |
| Recognition engine | Available | Often not | Edge classification differs |
Conclusion
The framework is three objects and one idea: what the traffic is, what happens to it, and where. The separation is what lets one definition of voice traffic exist once for an entire network instead of forty times, and it is the problem the framework was built to solve. Within a policy, class order is functional rather than cosmetic — first match wins, so a broad class above a specific one leaves the specific one permanently empty.
The design decision underneath the framework is where classification happens, and the answer is once, at the edge. Identify the traffic there with whatever it takes, write the result into the marking, and every device afterwards classifies by reading one field. That makes the trust boundary the load-bearing element: a user-facing port must rewrite what arrives, because any device can mark its own traffic as the highest class, and conditional trust for telephony depends on a discovery protocol that a hardening exercise will happily disable.
And half of any policy cannot be verified when it is deployed. Marking and policing act on every packet and show their effect immediately. Queuing acts only when a queue exists, so on an interface that is never congested it is present, accepted and inert. A few minutes of generated load at commissioning, with queue depth and per-class drops observed, is the only thing that distinguishes a policy that works from one that is merely configured — and it is skipped almost every time. More CCIE Enterprise Infrastructure material — labs, protocol breakdowns and study guides — is collected on the SPOTO CCIE site.
External Links
- RFC 2474 — Definition of the Differentiated Services Field
- RFC 2475 — An Architecture for Differentiated Services
- RFC 4594 — Configuration Guidelines for DiffServ Service Classes
- RFC 3246 — An Expedited Forwarding PHB
- RFC 2597 — Assured Forwarding PHB Group
- RFC 3662 — A Lower Effort Per-Domain Behavior
- Cisco Learning Network — CCIE Enterprise Infrastructure
Reference Notes
- RFC 2474 defines the differentiated services field in the IP header and the codepoints used to select a per-hop behaviour.
- RFC 2475 describes the differentiated services architecture, in which classification and marking occur at the network boundary and interior nodes act on the marking alone.
- RFC 2475 defines a traffic conditioner as comprising a classifier, marker, meter, shaper and dropper, which correspond to the actions available in a policy.
- RFC 2475 states that interior nodes need only implement per-hop behaviour selection based on the codepoint, which is the basis of classifying by marking away from the edge.
- RFC 3246 defines the expedited forwarding behaviour for traffic requiring low loss, latency and jitter, and requires it to be rate limited.
- RFC 2597 defines the assured forwarding group, comprising four classes each with three drop precedences, which is the model behind marking excess traffic down rather than discarding it.
- RFC 3662 defines a lower effort per-domain behaviour for traffic that should yield to all other traffic.
- RFC 4594 provides configuration guidelines for differentiated services classes, recommending codepoints and treatment for voice, video, signalling, transactional data and bulk data.
- Cisco documentation describes the modular QoS command-line interface, comprising class maps, policy maps and service policies as separate configuration objects.
- Cisco documentation states that classes within a policy map are evaluated in configuration order and that the first matching class is applied.
- Cisco documentation distinguishes match-all and match-any class maps, requiring all or any of the configured criteria to be satisfied respectively.
- The CCIE Enterprise Infrastructure v1.1 unified exam topics include quality of service within the infrastructure services domain.