Free tech learning for everyone, from basics to pro

Transport Network DesignNetworking SecurityIntermediate

QoS classification and marking on Cisco IOS: class maps, NBAR and set commands

In short: Classification decides what traffic is; marking writes a DSCP or CoS value so later hops do not have to classify again. On Cisco IOS you build this with the Modular QoS CLI: class maps match traffic using ACLs, existing marks or NBAR application recognition, and a policy map sets the marks. Mark as close to the source as you can.

Classify once, mark once

Classification means identifying traffic: this packet is voice, that one is a backup. It can be expensive, especially when the device must inspect the application. Marking records the result in the packet, normally as a DSCP value, so that every later hop only needs to read the mark. The rule of thumb is to classify and mark at the edge, as close to the source as possible, and to trust those marks in the core.

The Modular QoS CLI (MQC) in three stepsclass-mapwhat traffic?policy-mapwhat to do with itservice-policywhere and which wayshow policy-mapverify counters
Figure 1. Every QoS feature on Cisco IOS is built the same way: classify with a class map, act on each class in a policy map, attach the policy to an interface, then check the counters.

Class maps: what to match

A class map lists one or more match conditions. match-all (the default) requires every condition to be true; match-any needs just one. Common conditions are:

  • match access-group name ACL: addresses and ports in an access list.
  • match dscp ef or match precedence 5: an existing mark.
  • match cos 5: the 802.1Q CoS value on a trunk.
  • match protocol NAME: an application recognised by NBAR.
  • match input-interface, match packet length and match qos-group: less common, but useful.

Anything that matches no class falls into the built-in class-default.

NBAR

Network-Based Application Recognition (NBAR), now NBAR2, identifies applications by more than port numbers: it looks at protocol behaviour and, for encrypted traffic, clues such as the server name in the TLS handshake and DNS answers. Cisco updates its signatures through protocol packs. You can also use NBAR only for visibility: ip nbar protocol-discovery on an interface shows which applications use the link, which is a good first step before writing any policy.

Policy maps: marking traffic

Inside a policy map, each class gets actions. For marking, the common ones are set dscp, set ip precedence, set cos and set qos-group (an internal label that never leaves the device). This example marks traffic arriving from a branch LAN:

ip access-list extended POS-SERVER
 permit tcp 10.20.0.0 0.0.255.255 host 10.1.5.20 eq 8443
!
class-map match-any VOICE
 match protocol rtp audio
class-map match-any SIGNALLING
 match protocol sip
class-map match-all POS
 match access-group name POS-SERVER
class-map match-any BULK
 match protocol ftp
 match protocol cifs
!
policy-map MARK-LAN-IN
 class VOICE
  set dscp ef
 class SIGNALLING
  set dscp cs3
 class POS
  set dscp af21
 class BULK
  set dscp af11
 class class-default
  set dscp default
!
interface GigabitEthernet0/1
 description Branch LAN
 service-policy input MARK-LAN-IN

Marking is applied inbound on the LAN-facing interface, so the marks are already in place when the WAN policy queues traffic on the way out. The order of classes matters: a packet takes the first class it matches.

Tunnels and QoS pre-classify

When a router encrypts or encapsulates traffic into a GRE or IPsec tunnel, the original header is hidden inside a new one. IOS copies the ToS byte to the outer header by default, so DSCP-based policies still work. However, a policy on the physical interface that matches on original addresses or ports would see only the tunnel endpoints. The qos pre-classify command, under the tunnel interface or crypto map, keeps a copy of the original header for classification on the way out.

Verifying and troubleshooting

show class-map
show policy-map MARK-LAN-IN
show policy-map interface GigabitEthernet0/1 input
show ip nbar protocol-discovery interface GigabitEthernet0/1

show policy-map interface shows packet counters per class. If everything lands in class-default, check the class order, the match-all/match-any choice, ACL entries and whether NBAR recognises the application.

Real-world example: a chain of eight furniture shops sent card payments, CCTV uploads and staff web browsing over one VPN to head office. Card payments sometimes timed out on Saturday afternoons. The network engineer used NBAR protocol discovery for a week, which showed CCTV uploads taking most of the link at peak times. She added a marking policy on each shop router: payments to the payment gateway as AF21, CCTV as AF11, and everything else as default, then gave AF21 a guaranteed share on the tunnel. Payment timeouts stopped.

Practice

What is the difference between match-all and match-any in a class map?
match-all needs every condition to be true; match-any needs only one of them.
Why is a marking policy normally applied inbound on the LAN interface?
So packets are marked as soon as they enter the router, before output policies on the WAN interface queue them by their marks.
What problem does qos pre-classify solve?
After tunnel encapsulation, an output policy on the physical interface only sees the outer header; pre-classify lets it classify using the original addresses and ports.

Key takeaways

  • Classify and mark at the edge; trust and act on the marks everywhere else.
  • Class maps match traffic by ACL, DSCP, CoS, NBAR protocol and more; unmatched traffic goes to class-default.
  • Policy maps mark with set dscp, set cos or set qos-group, applied with service-policy.
  • NBAR recognises applications and its protocol discovery shows what uses a link.
  • Use qos pre-classify when tunnels hide the fields an output policy needs.
Tracks your learning on this device only. See your progress on the learning paths.

About the author

Mohamed Fayas

Founder of FM TecHub. CCNA certified, with a BTEC HND in Network Engineering, and BEng (Hons) in Computer Networking and Cloud Security. He writes practical, plain-English guides on networking, security and cloud.

More about the author

Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.

Stay up to date by email

New notes, tools and security news from FM TecHub, explained simply. Free.

We only use your email to send these updates. See our privacy policy.