DSCP Marking & Classification

Every packet on your network competes for the same queues at every router hop. Without a way to express priority, a VoIP call and a bulk file transfer receive identical treatment — the call breaks up while the file transfer barely notices. DSCP (Differentiated Services Code Point) is the 6-bit field in the IP header's ToS byte that carries a packet's QoS intent across the network. Marking traffic at the ingress edge — the first router the packet touches — with the correct DSCP value allows every downstream router to make forwarding and queuing decisions without re-classifying the traffic from scratch.

Cisco IOS implements DSCP marking and classification through the MQC (Modular QoS CLI) framework: a class-map identifies traffic, a policy-map defines what to do with it (mark, police, queue), and a service-policy applies the policy to an interface. Classification can use ACLs for well-known port numbers, or NBAR (Network-Based Application Recognition) for deep-packet inspection that identifies applications by payload signature rather than port alone. This lab covers both approaches and verifies that markings survive all the way across the network.

DSCP marking feeds directly into the queuing and scheduling step that determines how marked traffic is served — see CBWFQ and LLQ Configuration for the queuing policy that consumes DSCP values. For the broader QoS model see QoS Overview, QoS Queuing, and QoS Marking. For the MQC framework foundations see MQC QoS Basics. For traffic policing and shaping applied after marking see Traffic Policing and Shaping. For ACL classification concepts see ACL Overview and Extended ACL Configuration.

1. DSCP — Core Concepts

The IP Header ToS Byte and DSCP Field

  IP Header — Byte 1 (Type of Service / DSCP+ECN byte):
  ┌─────┬─────┬─────┬─────┬─────┬─────┬───┬───┐
  │ DS5 │ DS4 │ DS3 │ DS2 │ DS1 │ DS0 │ECN│ECN│
  └─────┴─────┴─────┴─────┴─────┴─────┴───┴───┘
    ◄──────────── DSCP (6 bits) ──────────────►  ◄ ECN ►
    Bit 7 (MSB)                      Bit 2         Bits 1-0

  DSCP value expressed as decimal: bits DS5–DS0 read left to right
  e.g. EF = 101110 binary = 46 decimal
       AF41 = 100010 binary = 34 decimal
       CS3  = 011000 binary = 24 decimal
       BE   = 000000 binary = 0  (default — no marking)

DSCP Per-Hop Behaviour Classes

Class	DSCP Name	Decimal	Binary	Typical Use
EF	Expedited Forwarding	46	101110	VoIP RTP media — requires strict low latency, low jitter, low loss. Gets LLQ/priority treatment at every hop
CS3	Class Selector 3	24	011000	VoIP call signalling (SIP, H.323, SCCP) — needs low latency but slightly less critical than media
AF41	Assured Forwarding 4-1	34	100010	Interactive video (telepresence, video calls) — high priority, low drop probability within the class
AF31	Assured Forwarding 3-1	26	011010	Critical business applications (SAP, ERP, SQL) — guaranteed bandwidth, low drop probability
AF21	Assured Forwarding 2-1	18	010010	Transactional data (web-based apps, HTTPS business) — moderate priority
AF11	Assured Forwarding 1-1	10	001010	Bulk data (email, FTP, backups) — best-effort with some assurance
CS1	Class Selector 1	8	001000	Scavenger / low-priority — peer-to-peer, consumer video streaming. Gets less-than-best-effort treatment
CS0 / BE	Best Effort / Default	0	000000	Unmarked traffic — default treatment. Most internet traffic arrives here

AF Class Structure — Drop Precedence

Assured Forwarding classes (AF) have an internal structure: the class number (1–4) defines the bandwidth allocation tier, and the drop precedence (1–3) defines which packets within a class are dropped first under congestion:

AF Class	Drop Low (x1)	Drop Medium (x2)	Drop High (x3)
AF4x (video)	AF41 = 34	AF42 = 36	AF43 = 38
AF3x (critical apps)	AF31 = 26	AF32 = 28	AF33 = 30
AF2x (transactional)	AF21 = 18	AF22 = 20	AF23 = 22
AF1x (bulk)	AF11 = 10	AF12 = 12	AF13 = 14

MQC Framework — Three-Object Model

  ┌────────────────┐     ┌──────────────────────┐     ┌──────────────────────────┐
  │   class-map    │────►│     policy-map        │────►│   service-policy         │
  │                │     │                       │     │                          │
  │ Matches traffic│     │ Defines action for    │     │ Binds policy to an       │
  │ by ACL, DSCP,  │     │ each class:           │     │ interface in a direction:│
  │ NBAR protocol, │     │  set dscp ef          │     │                          │
  │ QoS group,     │     │  set dscp af31        │     │ interface Gi0/0          │
  │ interface, etc.│     │  police ...           │     │  service-policy input    │
  │                │     │  bandwidth ...        │     │   MARK-INBOUND           │
  └────────────────┘     └──────────────────────┘     └──────────────────────────┘

  Traffic flow direction:
    input  service-policy → marks/classifies as packet enters the interface
    output service-policy → queues/schedules as packet exits the interface

  Best practice: MARK inbound (input), QUEUE outbound (output)

Trust Boundary

The trust boundary is the point where the network stops trusting DSCP markings set by endpoints and begins enforcing its own policy. End-user devices (PCs, phones) should not be trusted to self-mark their traffic — a PC can mark everything as EF 46, starving legitimate VoIP. The trust boundary is typically the access layer switch or the WAN edge router. Traffic arriving inbound is re-marked or verified at this boundary. For VoIP VLAN configuration that separates phone traffic see Voice VLAN and Voice VLAN Configuration. For VLAN segmentation that creates the user, voice, and server segments see VLANs.

2. Lab Topology & Traffic Profile

  [IP Phones — VLAN 10]  [PC users — VLAN 20]  [Servers — VLAN 30]
         │                      │                      │
         └──────────────────────┴──────────────────────┘
                                │
                          Gi0/0 (LAN in)
                        NetsTuts-R1
                    (Edge Router — Trust Boundary)
                          Gi0/1 (WAN out)
                                │
                          WAN / MPLS core
                                │
                        NetsTuts-R2 (Core)
                          Gi0/0 (WAN in)
                          Gi0/1 (LAN out)

  Traffic to classify and mark on R1 Gi0/0 inbound:
    VoIP RTP   UDP 16384–32767 from VLAN 10   → DSCP EF  (46)
    SIP        UDP/TCP 5060    from VLAN 10   → DSCP CS3 (24)
    Video call UDP 49152–65535 from VLAN 20   → DSCP AF41 (34)
    SAP/ERP    TCP 3200, 3600  from VLAN 30   → DSCP AF31 (26)
    HTTPS      TCP 443         from any       → DSCP AF21 (18)
    Scavenger  (YouTube NBAR)  from any       → DSCP CS1  (8)
    All other                                 → DSCP BE   (0)  — re-mark to zero

3. Step 1 — ACL-Based Classification

ACLs are the most common classification method. Define permit statements that match the specific source IP ranges, protocols, and port numbers for each traffic type. A packet that matches a permit entry is classified into that class:

NetsTuts-R1>en
NetsTuts-R1#conf t

! ── ACL: match VoIP RTP (UDP 16384–32767 from phone VLAN) ─
ip access-list extended ACL-VOIP-RTP
 permit udp 192.168.10.0 0.0.0.255 any range 16384 32767
!
! ── ACL: match SIP signalling ────────────────────────────
ip access-list extended ACL-SIP
 permit udp 192.168.10.0 0.0.0.255 any eq 5060
 permit tcp 192.168.10.0 0.0.0.255 any eq 5060
!
! ── ACL: match video conferencing ────────────────────────
ip access-list extended ACL-VIDEO
 permit udp 192.168.20.0 0.0.0.255 any range 49152 65535
!
! ── ACL: match SAP/ERP application ports ─────────────────
ip access-list extended ACL-SAP
 permit tcp 192.168.30.0 0.0.0.255 any eq 3200
 permit tcp 192.168.30.0 0.0.0.255 any eq 3600
!
! ── ACL: match HTTPS ─────────────────────────────────────
ip access-list extended ACL-HTTPS
 permit tcp any any eq 443
!

ACLs for QoS classification use permit statements — a matching packet is classified into the class; no implicit deny affects packet forwarding. The ACL is only evaluated for classification purposes, not for filtering. Port ranges use the range [low] [high] keyword. Multiple permit statements in the same ACL are OR'd together — a packet matching any line is classified. VoIP RTP port ranges (16384–32767 for Cisco, or the wider 16384–65535 for interoperability) should match only from the phone VLAN subnet to prevent desktop traffic from self-marking into the EF class. For detailed ACL configuration see ACL Overview and Extended ACL Configuration.

4. Step 2 — Class-Maps

A class-map references one or more ACLs (or NBAR protocols, DSCP values, or QoS groups) to define what traffic belongs to a class. The match-any keyword means a packet matching any match statement is classified into the class. match-all (the default) requires all statements to match:

! ── Class-map: VoIP RTP ──────────────────────────────────
class-map match-any CM-VOIP-RTP
 match access-group name ACL-VOIP-RTP
!
! ── Class-map: SIP signalling ────────────────────────────
class-map match-any CM-SIP
 match access-group name ACL-SIP
!
! ── Class-map: Video ─────────────────────────────────────
class-map match-any CM-VIDEO
 match access-group name ACL-VIDEO
!
! ── Class-map: SAP/ERP ───────────────────────────────────
class-map match-any CM-SAP
 match access-group name ACL-SAP
!
! ── Class-map: HTTPS ─────────────────────────────────────
class-map match-any CM-HTTPS
 match access-group name ACL-HTTPS
!
! ── Class-map: re-trust already-marked EF (from trusted phones) ──
class-map match-any CM-TRUST-EF
 match dscp ef
!

Class-maps are evaluated in the order they appear in the policy-map, not in the order they are defined. A packet is classified into the first matching class — subsequent classes are not evaluated. This means more-specific classes (VoIP RTP) should appear before less-specific ones (HTTPS) in the policy-map. The built-in class-default always exists and matches all traffic not caught by any other class — it is used to re-mark untrusted or unclassified traffic to DSCP 0 (Best Effort). The match dscp ef class-map example shows how to re-classify traffic that is already marked — useful at a trust boundary where IP phones self-mark and the edge router validates the marking.

5. Step 3 — NBAR-Based Classification

NBAR (Network-Based Application Recognition) classifies traffic by application signature — payload patterns, port negotiation, and protocol behaviour — rather than just port numbers. This is essential for applications that use dynamic ports, encrypted payloads with known patterns, or that share ports with other applications. NBAR is particularly effective at identifying consumer video streaming (YouTube, Netflix) for scavenger marking:

Enable NBAR Protocol Discovery (Optional — for visibility)

! ── Enable on the inbound interface to discover what's flowing ─
interface GigabitEthernet0/0
 ip nbar protocol-discovery
!
! ── After traffic has flowed, check what NBAR sees ────────
NetsTuts-R1#show ip nbar protocol-discovery interface GigabitEthernet0/0 top-n 10

GigabitEthernet0/0
                              Input                    Output
                              -----                    ------
Protocol                      Packet Count             Packet Count
                              Byte Count               Byte Count
                              30sec Bit Rate (bps)     30sec Bit Rate (bps)
                              30sec Max Bit Rate (bps) 30sec Max Bit Rate (bps)
------------------------      ------------------------ ------------------------
youtube                       48291                    102
                              62813300                 8160
                              1450000                  0
                              2100000                  128

rtp                           12045                    10832
                              19272000                 17331200
                              892000                   802000
                              1050000                  920000

http                           8821                    7654
                              11467300                 9950200
                              224000                   196000
                              380000                   310000

ip nbar protocol-discovery enables real-time monitoring of application traffic. After running for a few minutes during peak hours, show ip nbar protocol-discovery top-n 10 reveals the top 10 applications by packet or byte count. This is invaluable during QoS policy design — it confirms which applications are actually present before writing class-maps, and reveals unexpected traffic (e.g. peer-to-peer applications) that should be scavenger-marked. Disable after the survey by removing ip nbar protocol-discovery — it consumes CPU cycles on every packet and should not run indefinitely in production.

NBAR Class-Maps for Application Recognition

! ── Class-map: YouTube (scavenger) using NBAR ────────────
class-map match-any CM-SCAVENGER
 match protocol youtube
 match protocol netflix
 match protocol bittorrent
 match protocol kazaa2
!
! ── Class-map: Webex video — NBAR knows the signature ────
class-map match-any CM-WEBEX
 match protocol webex-media
 match protocol cisco-webex
!
! ── Class-map: DNS — needed to prevent DNS from being
! ── classified as generic UDP and under-prioritised ───────
class-map match-any CM-DNS
 match protocol dns
!
! ── Class-map: SNMP/NTP management traffic ───────────────
class-map match-any CM-MGMT
 match protocol snmp
 match protocol ntp
 match protocol ssh
 match protocol telnet
!

NBAR protocol names come from Cisco's Protocol Pack library — a regularly updated database of application signatures. Common protocol names include youtube, netflix, bittorrent, webex-media, ms-lync, rtp, sip, http, ssl, and hundreds more. Use show ip nbar protocol-pack active to list all available protocols on the router. NBAR and ACL match statements can be combined in the same class-map using match-any — a packet matching either the NBAR protocol or the ACL is classified into the class. For NTP configuration see NTP Configuration and for SNMP see SNMP v2c/v3 Configuration.

Custom NBAR Protocol (PDLM or Custom Signatures)

! ── Custom port-based protocol definition ────────────────
! ── Use when NBAR does not have a built-in signature ──────
ip nbar custom CUSTOM-APP tcp port 8080 8443

class-map match-any CM-CUSTOM-APP
 match protocol CUSTOM-APP
!

6. Step 4 — Policy-Map with DSCP Marking

The policy-map references class-maps and applies actions. For marking, the action is set dscp [value]. Class order in the policy-map determines match priority — place specific classes before general ones. The mandatory class class-default at the end catches all unmatched traffic:

! ════════════════════════════════════════════════════════════
! Policy-map: inbound marking at the trust boundary
! Applied INPUT on the LAN-facing interface
! ════════════════════════════════════════════════════════════
!
policy-map PM-MARK-INBOUND
 !
 ! ── Highest priority: VoIP RTP → EF ──────────────────────
 class CM-VOIP-RTP
  set dscp ef
 !
 ! ── VoIP signalling → CS3 ────────────────────────────────
 class CM-SIP
  set dscp cs3
 !
 ! ── Video conferencing → AF41 ────────────────────────────
 class CM-VIDEO
  set dscp af41
 !
 ! ── SAP/ERP → AF31 ───────────────────────────────────────
 class CM-SAP
  set dscp af31
 !
 ! ── HTTPS business traffic → AF21 ────────────────────────
 class CM-HTTPS
  set dscp af21
 !
 ! ── Scavenger (YouTube, P2P) → CS1 ───────────────────────
 class CM-SCAVENGER
  set dscp cs1
 !
 ! ── WebEx → AF41 (same as video) ─────────────────────────
 class CM-WEBEX
  set dscp af41
 !
 ! ── DNS → CS2 (needs to get through quickly) ─────────────
 class CM-DNS
  set dscp cs2
 !
 ! ── Management protocols → CS2 ───────────────────────────
 class CM-MGMT
  set dscp cs2
 !
 ! ── Everything else: re-mark to BE 0 (untrusted) ─────────
 class class-default
  set dscp default
 !
!

set dscp default in the class-default explicitly sets DSCP to 0 (Best Effort) — this erases any self-marking from untrusted endpoints. Without this, a desktop PC that sets its own DSCP to EF would have that marking preserved through the network. The re-marking to zero enforces the trust boundary. Each class statement in the policy-map is evaluated against the packet in top-to-bottom order; the first match wins and the packet is not re-evaluated against subsequent classes. Use set dscp [name] (e.g. set dscp ef) rather than the numeric form (set dscp 46) for readability — IOS accepts both.

7. Step 5 — Apply Service-Policy to Interface

A policy-map becomes active only when bound to an interface with service-policy. Marking policies apply inbound (on the ingress interface as the packet enters the router). Queuing and scheduling policies apply outbound (on the egress interface as the packet leaves):

! ── Apply marking policy INBOUND on LAN interface ────────
interface GigabitEthernet0/0
 description LAN-Trust-Boundary
 ip address 192.168.1.1 255.255.255.0
 service-policy input PM-MARK-INBOUND
 no shutdown
!
! ── WAN egress interface: queuing policy goes here ────────
! ── (covered in CBWFQ/LLQ lab) ───────────────────────────
interface GigabitEthernet0/1
 description WAN-Uplink
 ip address 10.0.0.1 255.255.255.252
 ! service-policy output PM-QUEUE-OUTBOUND ← queuing policy
 no shutdown
!
NetsTuts-R1(config)#end
NetsTuts-R1#wr
Building configuration...
[OK]

A single interface can have at most one input and one output service-policy. You cannot stack multiple policy-maps on the same interface in the same direction — instead, use a hierarchical policy-map (parent/child) to layer marking and queuing on a single interface. The input direction is preferred for marking because it stamps the DSCP value as early as possible — all subsequent processing (routing, ACL, NAT) sees the correct marked value. Re-marking on output is possible but means routing decisions were made with incorrect DSCP values. After applying the policy save the configuration with write memory.

Verify Policy is Attached

NetsTuts-R1#show policy-map interface GigabitEthernet0/0

 GigabitEthernet0/0

  Service-policy input: PM-MARK-INBOUND

    Class-map: CM-VOIP-RTP (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: access-group name ACL-VOIP-RTP
      QoS Set
        dscp ef
          Packets marked 0

    Class-map: CM-SIP (match-any)
      0 packets, 0 bytes
      ...
      QoS Set
        dscp cs3
          Packets marked 0

    Class-map: class-default (match-any)
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: any
      QoS Set
        dscp default
          Packets marked 0

Before traffic flows, all counters show zero. The structure confirms the policy is correctly attached. The "Packets marked" counter underneath each QoS Set action is the key verification field — it shows how many packets have had that DSCP value applied. If a class shows packets matched but "Packets marked 0", the set action failed (rare, usually a syntax issue). The 5-minute offered rate shows bandwidth consumed by each class.

8. Step 6 — Verification with Live Traffic

show policy-map interface — With Traffic Flowing

NetsTuts-R1#show policy-map interface GigabitEthernet0/0

 GigabitEthernet0/0

  Service-policy input: PM-MARK-INBOUND

    Class-map: CM-VOIP-RTP (match-any)
      18420 packets, 29472000 bytes
      5 minute offered rate 892000 bps, drop rate 0000 bps
      Match: access-group name ACL-VOIP-RTP
        18420 packets, 29472000 bytes
      QoS Set
        dscp ef
          Packets marked 18420

    Class-map: CM-SIP (match-any)
      342 packets, 68400 bytes
      5 minute offered rate 2800 bps, drop rate 0000 bps
      Match: access-group name ACL-SIP
        342 packets, 68400 bytes
      QoS Set
        dscp cs3
          Packets marked 342

    Class-map: CM-VIDEO (match-any)
      8210 packets, 14778000 bytes
      5 minute offered rate 592000 bps, drop rate 0000 bps
      Match: access-group name ACL-VIDEO
        8210 packets, 14778000 bytes
      QoS Set
        dscp af41
          Packets marked 8210

    Class-map: CM-SAP (match-any)
      1520 packets, 2432000 bytes
      5 minute offered rate 98000 bps, drop rate 0000 bps
      Match: access-group name ACL-SAP
        1520 packets, 1520000 bytes
      QoS Set
        dscp af31
          Packets marked 1520

    Class-map: CM-SCAVENGER (match-any)
      24800 packets, 31000000 bytes
      5 minute offered rate 1240000 bps, drop rate 0000 bps
      Match: protocol youtube
        22100 packets
      Match: protocol bittorrent
        2700 packets
      QoS Set
        dscp cs1
          Packets marked 24800

    Class-map: class-default (match-any)
      42100 packets, 53370000 bytes
      5 minute offered rate 2100000 bps, drop rate 0000 bps
      Match: any
      QoS Set
        dscp default
          Packets marked 42100

With traffic flowing, the key validation is that Packets marked equals packets matched for every class — confirming every matched packet received the intended DSCP value. The scavenger class breakdown shows individual NBAR protocol matches within the class, which is valuable for confirming NBAR is correctly identifying specific applications. The class-default is marking 42,100 packets to DSCP 0 — these are all the packets that did not match any specific class, including any self-marked traffic from untrusted endpoints that is being reset to Best Effort.

show policy-map interface — Output Across the Network (R2)

! ── On R2 (core router), verify R1's markings arrived intact ─
NetsTuts-R2#show policy-map interface GigabitEthernet0/0 input

 GigabitEthernet0/0

  Service-policy input: PM-VERIFY-DSCP

    Class-map: CM-CHECK-EF (match-any)
      18419 packets, 29473600 bytes
      Match: dscp ef (46)
        18419 packets, 29473600 bytes

    Class-map: CM-CHECK-AF41 (match-any)
      12215 packets, 21987000 bytes
      Match: dscp af41 (34)
        12215 packets

    Class-map: CM-CHECK-CS1 (match-any)
      24800 packets, 31000000 bytes
      Match: dscp cs1 (8)
        24800 packets

    Class-map: class-default (match-any)
      42100 packets, 53370000 bytes
      Match: any

To verify markings are preserved end-to-end, deploy a monitoring policy on R2's inbound WAN interface that matches by DSCP value rather than by ACL. If the packet counts on R2's DSCP-match classes correspond to the marking counts on R1's output interface, the markings are being preserved across the network. A discrepancy — e.g. EF traffic arriving at R2 as class-default (DSCP 0) — indicates a re-marking event between R1 and R2, usually a misconfigured intermediate device that is overwriting the DSCP field. Check each transit hop with

show policy-map
    interface

to isolate where the marking is being altered.

Verify DSCP Value on a Specific Packet (Embedded Packet Capture)

! ── Capture packets on the WAN interface to verify DSCP ──
ip access-list extended CAP-VOIP
 permit udp 192.168.10.0 0.0.0.255 any range 16384 32767

monitor capture CAP1 access-list CAP-VOIP interface GigabitEthernet0/1 out
monitor capture CAP1 start

! ── After a few seconds ──────────────────────────────────
monitor capture CAP1 stop
show monitor capture CAP1 buffer brief

 ----------------------------------------------------------------------------
  #   size   sec    usec   srcIP           dstIP
  1   214    0      000000 192.168.10.10   10.20.0.5
  2   214    0      000100 192.168.10.10   10.20.0.5

show monitor capture CAP1 buffer detail

Frame 1:
  DSCP: 46 (EF)       ← confirmed — DSCP EF preserved on WAN egress
  Protocol: UDP
  Src Port: 20480
  Dst Port: 20480

show ip nbar protocol-discovery — Confirm NBAR Classifications

NetsTuts-R1#show ip nbar protocol-discovery interface GigabitEthernet0/0 stats packet-count top-n 5

GigabitEthernet0/0
Protocol                  Input Packets   Output Packets
------------------------  -------------   --------------
youtube                       22100              0
rtp                           18420          16834
http                           5201           4892
bittorrent                     2700              0
dns                            1840           1820

! ── Confirm NBAR is correctly identifying scavenger apps ─

Verification Command Summary

Command	What It Shows	Key Field
`show policy-map interface [intf]`	Per-class packet/byte counts, offered rate, drop rate, and packets marked for each set action	"Packets marked" must equal matched packets — confirms every matched packet was re-marked
`show policy-map interface [intf] input`	Only the input direction policy — useful on interfaces with both input and output policies	Class-default count shows unclassified traffic volume — large number may indicate missing class-maps
`show class-map [name]`	Class-map definition — match criteria and type (match-any/all)	Confirms correct ACL or NBAR protocol names are referenced
`show policy-map [name]`	Policy-map definition — all classes and their configured actions without live counters	Verify set dscp values and class order before applying to interface
`show ip nbar protocol-discovery`	Per-protocol packet and byte counts on NBAR-enabled interfaces	Confirms NBAR is classifying target applications; use `top-n 10` for ranking
`show ip nbar protocol-pack active`	Currently loaded NBAR Protocol Pack version and all available protocol names	Verify a specific NBAR protocol name (e.g. `youtube`) is available before referencing in class-map
`show interfaces [intf] \| include DSCP`	Interface-level DSCP trust state (relevant on switches)	Confirms whether the interface trusts or overwrites incoming DSCP values

9. Step 7 — Ensuring DSCP Preservation Across the Network

Marking traffic at the edge is only valuable if every intermediate device preserves the DSCP value. Several scenarios can corrupt or erase markings in transit:

Scenario A — Verifying a Core Router Is Not Re-Marking

! ── On a core router with NO QoS policy, DSCP passes through unchanged ─
! ── Verify by checking the interface has no service-policy ────────────
NetsTuts-CORE#show interfaces GigabitEthernet0/0 | include policy
  No input service-policy
  No output service-policy
! ── Good: no policy = no re-marking, DSCP preserved ─────────────────

Scenario B — VPN Tunnel Preserving DSCP (GRE/IPsec)

! ── GRE tunnel: copy inner DSCP to outer IP header ───────
interface Tunnel0
 tunnel mode gre ip
 ! ── Copy inner IP header DSCP to outer GRE header ────────
 tunnel dscp propagate
!
! ── IPsec: ensure DSCP is copied from inner to outer header ─
crypto ipsec transform-set TS esp-aes 256 esp-sha256-hmac
 mode transport
!
! ── For IPsec tunnel mode, QoS pre-classify ──────────────
interface GigabitEthernet0/1
 qos pre-classify
!

Two common DSCP loss points are GRE tunnels and IPsec tunnels. When GRE encapsulates a packet, a new outer IP header is prepended. By default the outer header's DSCP field is 0 — the original DSCP value travels inside the tunnel invisible to intermediate routers. tunnel dscp propagate copies the inner DSCP to the outer header, allowing WAN routers to queue the GRE-encapsulated packet based on its application class. For IPsec in tunnel mode, qos pre-classify on the physical interface tells IOS to look inside the IPsec packet at the inner IP header's DSCP before the packet is encrypted, allowing the output queuing policy to operate on the true application DSCP rather than 0. For DMVPN with IPsec transport mode, DSCP is naturally preserved since the outer GRE header is the transport header. See GRE Tunnel Configuration and Site-to-Site IPsec VPN for the underlying tunnel configuration.

Scenario C — Monitoring Policy to Detect DSCP Corruption

! ── Lightweight verification policy: match by DSCP, count only ──
class-map match-any CM-EF-CHECK
 match dscp ef
class-map match-any CM-CS1-CHECK
 match dscp cs1

policy-map PM-DSCP-AUDIT
 class CM-EF-CHECK
  ! ── no action — just count ───────────────────────────────
 class CM-CS1-CHECK
  !
 class class-default
  !

interface GigabitEthernet0/0
 service-policy input PM-DSCP-AUDIT

! ── Check counts match expected values from upstream router ─
NetsTuts-R2#show policy-map interface GigabitEthernet0/0 input

A policy-map with no actions (no set, no police, no bandwidth) is a pure counting policy — it classifies traffic into classes and increments counters without affecting the packets. This is a low-impact way to audit DSCP values at any point in the network without deploying a full queuing policy. Apply it on the inbound interface of each core router during a DSCP audit, compare the class counts to the marking output at R1, and identify exactly which hop is corrupting the markings. Remove the policy after the audit to avoid unnecessary classification overhead.

10. Troubleshooting DSCP Marking

Problem	Symptom	Cause	Fix
Class shows 0 matched packets despite live traffic	`show policy-map interface` shows 0 packets for a class while traffic is clearly flowing from the source subnet	ACL does not match the traffic — wrong source subnet, wrong port number, wrong protocol (TCP vs UDP); class-map references wrong ACL name; service-policy applied in wrong direction (output instead of input)	Test the ACL independently: `show ip access-lists ACL-VOIP-RTP` — if match counts are zero, the ACL itself does not match the traffic. Verify source addresses with `debug ip packet` briefly. Confirm `service-policy input` (not output) on the ingress interface
All traffic landing in class-default	Only class-default has packet counts; all other classes show zero	Class-maps are not matching — ACL names misspelled, NBAR not enabled, or `match-any`/`match-all` logic incorrect; policy-map references wrong class-map names	Run `show class-map` to verify class-map definitions. Check ACL names exactly match the `match access-group name` reference. For NBAR classes, confirm `ip nbar protocol-discovery` is active and run `show ip nbar protocol-discovery` to confirm traffic is being seen
NBAR class matches 0 packets	NBAR class-map for youtube or other protocol shows no matches despite confirmed traffic	Protocol Pack does not include the protocol; protocol name misspelled; NBAR not fully initialised on the interface; NBAR PDL (Protocol Description Language) file not loaded	Run `show ip nbar protocol-pack active` to list available protocols. Confirm spelling exactly matches. Update Protocol Pack with `ip nbar protocol-pack flash:pp-adv-isrg2-154-7.tar` if a newer pack is available
DSCP markings lost at downstream router	R1 marks correctly but R2 receives everything as DSCP 0 or a different value	An intermediate device has a policy-map on the WAN interface that re-marks to default; GRE/IPsec tunnel not propagating DSCP to outer header; ISP service provider is remarking DSCP at their edge	Check each hop: `show interfaces [intf] \| include policy` and `show policy-map interface` on each transit device. For GRE tunnels add `tunnel dscp propagate`. For IPsec tunnels add `qos pre-classify` on the physical interface. Contact ISP if remarking occurs in their network
Cannot apply second service-policy to interface	`% Service policy [name] already attached` error when adding a second service-policy	An interface can only have one input and one output service-policy — attempting to add a second in the same direction fails	Remove the existing policy: `no service-policy input [existing-policy]` then apply the new one. To combine marking and queuing on the same interface, use a hierarchical policy-map (parent with child) — covered in CBWFQ/LLQ configuration
High CPU from NBAR	Router CPU spikes after enabling NBAR; `show processes cpu` shows ip_nbar as top consumer	NBAR performs deep packet inspection on every classified packet — high traffic volume causes significant CPU load, especially on older ISR platforms	Limit NBAR to specific interfaces and traffic classes. Use ACL-based classification for well-known port applications and reserve NBAR for only the protocols that truly need DPI (e.g. YouTube, P2P). Disable `ip nbar protocol-discovery` after the traffic survey — it adds per-packet overhead beyond what class-map matching requires
VoIP traffic marked EF but still experiencing jitter	DSCP EF is correctly applied at ingress; downstream routers show EF class matching; but calls have jitter and packet loss	DSCP marking alone does not prevent jitter — it only tags the traffic. The queuing policy (LLQ priority queue) at each egress interface must consume the EF marking and give those packets strict priority. Without a queuing policy, DSCP is decorative	Apply a queuing policy-map with `priority` (LLQ) on outbound interfaces that match EF traffic. See CBWFQ and LLQ Configuration. Verify with `show policy-map interface [egress-intf] output`

Key Points & Exam Tips

DSCP is a 6-bit field in the IP header's ToS byte, giving 64 possible values (0–63). The remaining 2 bits are the ECN field. DSCP values are expressed as names (EF, AF41, CS3) or decimal numbers (46, 34, 24).
Key DSCP values to memorise: EF = 46 (VoIP media, strict priority), CS3 = 24 (VoIP signalling), AF41 = 34 (interactive video), AF31 = 26 (critical data), CS1 = 8 (scavenger), BE/CS0 = 0 (default).
AF classes have a class tier (1–4) and a drop precedence (1–3). Higher class number = higher priority tier. Higher drop precedence = dropped first under congestion within the same class. AF41 has lower drop probability than AF43.
The MQC three-object model: class-map (match traffic) → policy-map (define action) → service-policy (apply to interface). All three are required.
Marking policies apply input on the ingress interface. Queuing policies apply output on the egress interface. An interface can have one input and one output service-policy simultaneously.
The trust boundary is where the network takes ownership of DSCP markings. Untrusted endpoints must be re-marked at ingress. Always include class class-default → set dscp default to erase self-markings from endpoints.
NBAR classifies by application signature, not port number. Use it for applications with dynamic ports or shared ports. NBAR consumes CPU — use only where ACL classification is insufficient.
DSCP marking alone does not guarantee QoS. Marking tags the packet; a queuing/scheduling policy (LLQ for EF, CBWFQ for AF classes) at egress interfaces must consume the tags to actually differentiate treatment.
For DSCP to survive end-to-end, every device in the path must preserve the DSCP field. GRE tunnels require tunnel dscp propagate; IPsec tunnel-mode interfaces require qos pre-classify.
On the CCNA/CCNP exam: know the EF, AF, CS class purposes; understand the MQC three-step process; know the difference between match-any and match-all in class-maps; understand why class-default must set DSCP to 0 at a trust boundary.

Next Steps: DSCP marking tags traffic — the next step is acting on those tags at congested egress interfaces. See CBWFQ and LLQ Configuration to build queuing policies that give EF traffic strict priority and allocate guaranteed bandwidth to AF classes. For rate-limiting traffic per class after marking see Traffic Policing and Shaping. For the full QoS design framework see QoS Overview, QoS Queuing, and QoS Policing & Shaping. For preserving DSCP across DMVPN tunnels see DMVPN Phase 1, 2 & 3. For measuring VoIP quality end-to-end see IP SLA Configuration & Tracking.

TEST WHAT YOU LEARNED

1. What is the DSCP decimal value for EF (Expedited Forwarding), and why is it reserved specifically for VoIP RTP media rather than being used for all high-priority traffic?

A. DSCP 48 — it is the highest available value and is reserved for VoIP because VoIP generates the most packets per second of any application B. DSCP 40 — it is specifically designed for real-time traffic and using it for anything other than VoIP causes downstream routers to apply incorrect timing compensation C. DSCP 46 — EF is defined by RFC 3246 as a per-hop behaviour that provides low latency, low jitter, and low loss. It maps to a priority queue (LLQ) at every hop. Using EF for bulk or bursty traffic would saturate the priority queue and starve the actual VoIP RTP streams that depend on it — EF traffic should never exceed a small, predictable percentage of link bandwidth D. DSCP 46 — EF is reserved for VoIP by IEEE 802.1p standards which prohibit its use for any other application type across enterprise networks

Correct answer is C. EF (DSCP 46, binary 101110) is defined in RFC 3246 as a single aggregate per-hop behaviour that provides a minimum departure rate greater than or equal to a configured rate — in practice it maps to an LLQ priority queue that is always served before any other queue. The critical design constraint is that EF traffic must be rate-limited (policed) to prevent it from monopolising the priority queue. If file transfers or video downloads were marked EF, they would fill the priority queue and starve VoIP packets that arrive after the queue is already full — introducing exactly the jitter EF is meant to prevent. Cisco's QoS design guidelines recommend EF for real-time voice media only, limited to no more than 33% of link bandwidth, with a policing action to enforce the limit. VoIP signalling (SIP, H.323) uses CS3 (DSCP 24), not EF, because signalling is tolerant of slightly higher latency than the RTP media stream.

2. A policy-map has five class-maps defined. Traffic matching both CM-HTTPS (position 4) and CM-SAP (position 3) — the SAP application uses TCP 443. Which class will the packet be placed in, and why?

A. CM-SAP — the policy-map evaluates classes top-to-bottom; the first matching class wins. Since CM-SAP appears before CM-HTTPS, the packet is classified as SAP and subsequent classes including CM-HTTPS are never evaluated for this packet B. CM-HTTPS — TCP 443 is a more specific match than the SAP port range, and IOS always selects the most specific class regardless of order C. Both CM-SAP and CM-HTTPS — the packet is marked twice, with the last set action taking effect (AF21 from CM-HTTPS overwriting AF31 from CM-SAP) D. class-default — when a packet matches multiple classes, IOS cannot determine the correct classification and falls through to the default class

Correct answer is A. Policy-map class evaluation is strictly sequential — first match wins, no further classes are evaluated. This is identical to ACL processing. If CM-SAP appears above CM-HTTPS in the policy-map and the SAP ACL matches TCP 443 traffic from the SAP server subnet, the packet is classified as SAP (AF31) and marked accordingly. CM-HTTPS never sees the packet. This ordering behaviour is intentional and provides the engineer with control over precedence. The practical implication here is that the SAP ACL should match specifically on source subnet AND port (so it only catches SAP server traffic on 443, not all HTTPS traffic) — or the more specific source-based class should be placed above the generic HTTPS class. When class-maps overlap, order in the policy-map determines outcome. Always test with show policy-map interface counters after applying the policy to verify traffic lands in the intended class.

3. Why must `class class-default → set dscp default` be included in an ingress marking policy at the trust boundary, and what is the security implication of omitting it?

A. It is optional — without it, IOS automatically resets unmatched traffic to DSCP 0 at the ingress interface B. It prevents routing loops — unclassified traffic without a DSCP value cannot be forwarded and would be dropped without this catch-all C. It improves performance by marking unclassified traffic as Best Effort, which reduces the number of packets that reach the priority queue D. Without it, any DSCP value pre-set by an endpoint (PC, server) passes through the router unchanged. A user's PC can set all its traffic to EF (46) — the marking policy classifies nothing it recognises as EF, so the traffic falls to class-default with no action, preserving the fraudulent EF marking. Downstream routers then treat that bulk PC traffic as voice priority, starving legitimate VoIP. Explicitly setting class-default to DSCP 0 erases all endpoint self-markings, enforcing the network's authority over QoS designations

Correct answer is D. The trust boundary principle is that endpoints are untrusted — they can set arbitrary DSCP values and network engineers must never allow those values to propagate into the core. Without set dscp default in class-default, any packet not matched by a specific class retains whatever DSCP value the endpoint set. A sophisticated user who knows the network uses EF 46 for priority treatment can configure their OS to mark all traffic as EF. The ingress policy's specific classes might not match their traffic (wrong subnet, wrong port), the packet falls to class-default, and if class-default has no set action, the EF 46 marking survives. Core routers then queue that traffic in the priority queue alongside legitimate VoIP, potentially causing voice quality degradation for all users. This is both a QoS design flaw and a potential DoS vector. The fix is simple: always include class class-default → set dscp default at every trust boundary to assert that unrecognised traffic has no priority claim.

4. What is the difference between AF41 (DSCP 34) and AF43 (DSCP 38) within the AF4 class, and when would you use AF43 instead of AF41?

A. AF43 has higher priority than AF41 — the higher the drop precedence number, the more important the packet within the class B. Within the AF4 class, all packets receive the same bandwidth allocation. The drop precedence (1=low, 2=medium, 3=high) determines which packets are discarded first when the queue is congested. AF41 packets are the last to be dropped; AF43 packets are the first. You would mark conforming video traffic as AF41 (low drop) and mark traffic that exceeds its committed rate as AF43 (high drop) — incentivising senders to stay within their rate limit C. AF41 is for inbound traffic; AF43 is the same marking used for outbound traffic on the return path — they form a bidirectional pair D. AF43 is deprecated and should not be used — only AF41 and AF42 are supported in current Cisco IOS versions

Correct answer is B. The AF (Assured Forwarding) PHB class structure (RFC 2597) defines four bandwidth tiers (AF1x–AF4x) and within each tier, three drop precedences. The naming convention is AFxy where x is the class (1–4) and y is the drop precedence (1=low, 2=medium, 3=high). All traffic in AF4x shares the same bandwidth allocation and scheduling treatment — the drop precedence only affects which packets WRED (Weighted Random Early Detection) preferentially discards when the queue begins to fill. AF41 (lowest drop precedence) is protected; AF43 (highest drop precedence) is sacrificed first. The canonical use case is a policer that marks conforming traffic as AF41 and exceeding traffic as AF43 — both get the AF4 bandwidth allocation when the link is lightly loaded, but when congestion occurs, the excess-marked AF43 packets are dropped to protect the conforming AF41 traffic. This creates a soft rate limit that degrades gracefully under congestion rather than hard-dropping all excess traffic immediately.

5. A class-map uses `match-all` instead of `match-any` with two match statements — one matching an ACL and one matching DSCP AF31. Which packets are classified into this class?

A. Packets matching either the ACL or having DSCP AF31 — match-all and match-any are equivalent in practice B. Only the first match statement is evaluated — match-all processes only the first matching criterion and ignores subsequent ones C. No packets — match-all with different match types (ACL and DSCP) always produces zero matches because the same packet cannot satisfy both simultaneously D. Only packets that match both the ACL and have DSCP AF31 are classified — match-all requires every match statement to be true for the packet. A packet from the correct subnet (matching the ACL) but with DSCP 0 does not match; a packet with DSCP AF31 from a different subnet does not match. Only a packet satisfying both conditions simultaneously is classified into this class

Correct answer is D. match-all (the default if not specified) implements logical AND across all match statements — every condition must be true. match-any implements logical OR — any single condition being true is sufficient. The match-all example in the question would classify only packets that already have DSCP AF31 AND originate from the ACL-defined source. This is useful when you want to verify that traffic that claims to be AF31 actually comes from the authorised server range — a form of DSCP validation rather than marking. If a packet from the right subnet has DSCP 0 (not yet marked), it fails the DSCP match; if a packet with AF31 arrives from an unknown subnet, it fails the ACL match. In practice, most ingress marking class-maps use match-any because a packet matching any of the classification criteria should be treated as that traffic type. match-all is more commonly used for compound classification: "must be from this subnet AND using this application port."

6. Why is NBAR necessary for classifying YouTube traffic, and why can't a standard ACL with `permit tcp any any eq 443` be used instead?

A. YouTube uses HTTPS (TCP 443), which is shared by thousands of other web applications — an ACL matching TCP 443 would classify all HTTPS traffic as YouTube and scavenger-mark legitimate business web traffic. NBAR identifies YouTube specifically by examining the TLS SNI (Server Name Indication) field, HTTP Host header, and destination IP ranges against Cisco's application signature database, distinguishing YouTube from other HTTPS traffic sharing the same port B. YouTube uses a proprietary non-standard port that changes frequently — ACLs cannot track dynamic port assignments so NBAR is required for any traffic that changes ports C. ACLs can only match on Layer 3 headers; YouTube traffic is identified at Layer 2 using MAC address ranges assigned to Google's CDN servers, which only NBAR can inspect D. NBAR is not actually needed — the ACL approach is better because it matches YouTube's dedicated IP subnet 216.58.0.0/16 which is exclusive to Google services

Correct answer is A. Port 443 (HTTPS/TLS) is used by an enormous range of applications: Microsoft Teams, Salesforce, Zoom, Netflix, banking apps, corporate web portals, VPNs, and of course YouTube. An ACL matching TCP 443 is essentially an ACL matching "most of the internet." Marking all TCP 443 traffic as scavenger (CS1) would devastate legitimate business HTTPS applications. NBAR solves this by performing application-layer analysis — examining the TLS SNI field (the domain name in the initial TLS handshake), HTTP Host headers, and packet payload patterns against Cisco's continuously updated Protocol Pack signatures to identify YouTube specifically. For protocol-distinguished traffic sharing a port, NBAR is the correct tool. For well-known dedicated ports (RTP on 16384-32767, SIP on 5060, SAP on 3200) that are not shared with other applications, ACLs are simpler, more deterministic, and less CPU-intensive than NBAR. Use NBAR only where ACL precision is genuinely insufficient.

7. An engineer applies a marking service-policy to the output direction of an interface instead of the input direction. What is the consequence, and what is the correct placement?

A. There is no difference — service-policy input and output both mark the packet with the same DSCP value before it exits the interface B. Output direction marking works correctly for transit traffic but fails to mark locally generated packets (router CPU-generated packets bypass the output policy) C. Applying a marking policy output means the packet is routed, NAT-translated, and all other processing occurs with DSCP 0 (or the original untrusted value). The DSCP is set only at the final egress step. Any QoS decisions made during forwarding — or on intermediate hops before the packet reaches the next router — operate on the incorrect DSCP value. The correct placement is input on the ingress interface so the mark is applied immediately, before any forwarding decisions, and every subsequent device sees the correct DSCP D. Output direction marking causes a double-marking problem where the output queuing policy also marks the packet, resulting in the DSCP being overwritten by the queuing policy's class actions

Correct answer is C. The timing of DSCP marking matters because downstream processes see whatever value is in the IP header at the time they process the packet. When a marking policy is applied output on the egress interface, the entire router processing pipeline — IP routing table lookups, ACL filtering, NAT translation, policy-based routing, and any queuing policy on the same interface — executes with the original (unmarked or untrusted) DSCP value. If the egress interface also has a queuing policy (CBWFQ/LLQ), the queuing policy's class-maps run before the marking policy writes the DSCP, meaning the queuing policy classifies based on the wrong (pre-marking) DSCP. Applying marking input on the ingress interface means the DSCP is set in the very first step of packet processing — all subsequent processing sees the authoritative marked value, and the egress queuing policy operates on correct DSCP values. The standard QoS design principle is: mark inbound, queue outbound.

8. `show policy-map interface Gi0/0` shows a class with 15,000 packets matched but "Packets marked 0" for the set dscp action. What does this indicate and how should it be diagnosed?

A. The packets were already marked with the target DSCP value — IOS skips the marking operation when the packet's current DSCP matches the set value, so "Packets marked 0" is expected and correct B. This indicates a configuration or platform error — normally matched packets and marked packets should be equal. Possible causes include a software bug, a hardware QoS limitation on the specific platform (some line cards do not support DSCP remarking), or a conflict with another QoS feature (e.g. trust DSCP on the interface overriding the set action). Check show policy-map interface for any error messages, verify the platform QoS capabilities, and check for mls qos trust dscp or similar trust commands on the interface C. The packets were dropped by a policing action before reaching the set dscp action — check for a police statement above the set action in the class D. DSCP marking is not supported in the input direction — move the service-policy to the output direction

Correct answer is B. Under normal operation, the "Packets marked" counter should equal the packets matched for a class with a set dscp action — every matched packet should be marked. A discrepancy where matched is high but marked is zero or low indicates the marking action is being bypassed. Option A is incorrect — IOS does not skip remarking when DSCP already matches; it marks every matched packet unconditionally. The most common platform-specific cause is on Catalyst switches where mls qos trust dscp on the port instructs the switching hardware to trust and preserve the incoming DSCP value, which can conflict with a software QoS policy's set action. On router platforms, this symptom is rarer but can occur on modular platforms where hardware forwarding bypasses software QoS. Check the platform's QoS feature support matrix, look for interface-level trust commands, and review show platform hardware qos or equivalent. Software bugs in specific IOS versions can also cause this — check Cisco's bug search tool for known issues with the specific IOS version and QoS set actions.

9. Why does DSCP marking alone not guarantee that VoIP traffic receives low latency, and what additional configuration is required?

A. DSCP marking guarantees low latency by itself — routers automatically prioritise EF-marked packets without any additional queuing configuration B. DSCP marking must be combined with traffic shaping — without shaping, EF packets arrive at inconsistent rates causing jitter regardless of queuing C. The DSCP field is stripped at each router hop and re-applied — without a re-marking policy at every hop, the EF value does not persist to the destination D. DSCP is purely informational — it is a tag in the IP header that communicates intent but has no automatic effect on forwarding. A queuing and scheduling policy (LLQ using priority command in a policy-map, applied output on each egress interface) must explicitly read the DSCP value and place EF packets in a strict priority queue that is serviced before all other queues. Without the queuing policy, all packets — EF and BE alike — are processed in FIFO order regardless of their DSCP marking

Correct answer is D. This is perhaps the most important conceptual point in QoS. DSCP is a label — it communicates "this packet would like priority treatment" but the network device is under no obligation to act on it unless explicitly configured to do so. A router with no queuing policy (or only FIFO queuing, which is the default) treats every packet identically regardless of DSCP value. The queue has one lane and all packets wait in arrival order. To translate EF markings into actual priority forwarding, a policy-map must be configured with priority [bandwidth] for the EF class (creating an LLQ — Low Latency Queue that is serviced on every scheduling interval before bandwidth is allocated to other classes) and applied as a service-policy output on every congestion point in the path. Without this egress queuing policy at each interface, DSCP marking is completely decorative. The common beginner mistake is to mark traffic at the edge, confirm the markings with show policy-map interface, and conclude QoS is working — without realising the downstream routers have no queuing policy and are ignoring the markings entirely.

10. A GRE tunnel carries DMVPN traffic between two sites. VoIP RTP is marked EF at the ingress edge. The WAN provider's core routers are configured to prioritise EF traffic. After the traffic enters the GRE tunnel, the WAN provider reports seeing only DSCP 0 traffic, not EF. What is the cause and fix?

A. The EF marking is being stripped by IPsec encryption before the packet enters the GRE tunnel — disable IPsec to restore DSCP visibility to the WAN provider B. GRE tunnels automatically re-mark all traffic to DSCP 0 as a security measure — this behaviour cannot be changed on Cisco IOS C. When GRE encapsulates the original IP packet, it prepends a new outer IP header. By default, the outer IP header's DSCP field is set to 0 regardless of the inner packet's DSCP. The WAN provider's routers see only the outer header — they observe DSCP 0 for all traffic. The fix is to add tunnel dscp propagate on the GRE tunnel interface, which copies the inner packet's DSCP (EF 46) to the outer GRE IP header so WAN routers can act on the correct priority marking D. The WAN provider is re-marking all traffic to DSCP 0 at their ingress — this is a provider policy that cannot be overridden by the customer's marking configuration

Correct answer is C. GRE encapsulation creates a "packet within a packet." The original IP packet (with its inner DSCP = 46 for EF) becomes the GRE payload, and a brand new outer IP header is prepended for routing across the WAN. This outer header has its own DSCP field, initialised to 0 by default — the router does not automatically copy the inner DSCP to the outer header. The WAN provider's QoS-aware routers inspect only the outer IP header (which is the header they are routing based on), see DSCP 0, and treat all the tunnel traffic as Best Effort. The inner EF marking is invisible to any device outside the tunnel endpoints. tunnel dscp propagate on the GRE tunnel interface solves this by copying the inner IP header's DSCP value to the outer IP header at encapsulation time. The WAN provider then sees the correct DSCP 46 and can prioritise the VoIP traffic accordingly. For IPsec in tunnel mode, the equivalent mechanism is qos pre-classify on the physical interface, which captures the inner DSCP before encryption and uses it for local output queuing decisions.

Back to Home