QoS marking on a Catalyst 9300

[michael.burke]

I'm having trouble with QoS marking on a Catalyst 9300 IOS XE, Version 16.08.01a
I'm marking traffic on the input of the access-port's vlan and egress queueing based on a marking match on a Trunk port.  I'm wondering if the trunk might be my issue?

The marking setup is by ACL

ip access-list extended MISSION-CRITICAL
permit ip any 10.0.1.1 255.255.255.255

class-map match-any TRANSACTIONAL
match access-group name MISSION-CRITICAL

policy-map LAN-TAG
class TRANSACTIONAL
set dscp af21

The issue is that when I check via show policy-map interface I see class match packets but no marking stats

Vlan20

Service-policy input: LAN-TAG

Class-map: TRANSACTIONAL (match-any)
8606 packets
Match: access-group name MISSION-CRITICAL
QoS Set
dscp af21

Class-map: class-default (match-any)
65704 packets
Match: any

This appears to be verified by Netflow data on the WAN egress interface and packet captures. However the egress queuing is registering bytes out in the P3 class but no packets.

 GigabitEthernet1/1/4

  Service-policy output: WAN-COMCAST-POLICY

    Class-map: class-default (match-any)
      0 packets
      Match: any
      Queueing

      (total drops) 408434
      (bytes output) 200610408
      shape (average) cir 20000000, bc 80000, be 80000
      target shape rate 20000000

      Service-policy : CSN-OUT

        Class-map: P1 (match-any)
          0 packets
          Match:  precedence 5
          Match:  dscp cs5 (40) 41  42  43  44  45  ef (46)
          Queueing

          (total drops) 0
          (bytes output) 2919784
          bandwidth 5% (1000 kbps)

        Class-map: P2 (match-any)
          0 packets
          Match:  precedence 4
          Match:  precedence 6
          Match:  precedence 7
          Match:  dscp cs4 (32) 33  af41 (34) 35  af42 (36) 37  af43 (38) 39
          Match:  dscp cs6 (48) 49  50  51  52  53  54  55
          Match:  dscp cs7 (56) 57  58  59  60  61  62  63
          Queueing

          (total drops) 0
          (bytes output) 4116
          bandwidth 10% (2000 kbps)

        Class-map: P3 (match-any)
          0 packets
          Match:  precedence 2
          Match:  precedence 3
          Match:  dscp cs2 (16) 17  af21 (18) 19  af22 (20) 21  af23 (22) 23
          Match:  dscp cs3 (24) 25  af31 (26) 27  af32 (28) 29  af33 (30) 31
          Queueing

          (total drops) 0
          (bytes output) 75073129
          bandwidth 40% (8000 kbps)

        Class-map: class-default (match-any)
          0 packets
          Match: any
          Queueing

          (total drops) 408434
          (bytes output) 122613379
          bandwidth 44% (8800 kbps)

[michael.burke]

Opened a TAC case for this, if anyone has a working MCQ qos config on a 9300 please share the software version and config if you can.   I'm even having and issue with my packet captures not filtering by their associated access list.

[michael.burke]

I'm not having much luck on my TAC case so I wanted to see if I can get guidance on facet of the problem here.  My access ports are clients who's gateway is an SVI.  Should I attempt to mark ingress packets DSCP at the port level or SVI?  Currently I have the tagging on both but maybe that is the issue.

Perhaps this will clarify the setup.  The access ports use an SVI as the client gateway and the WAN connection is a trunk with only the WAN BGP peering SVI allowed. 

Clients use VLAN 10 SVI

WAN uses VLAN 20 SVI -> Trunk with only vlan 20 allowed.

[michael.burke · Accepted solution]

Figured I would close this out.  Turns out that the QoS on these Catalyst 9300's was Marking, still not sure why egress queuing does not register packet counts.

  The real issue appears to be in how the device recognizes TOS tags.  Neither Embedded Packet Captures or Netflow on the device indicates marking, however when I observe traffic at the remote device, an ASR 1000, DSCP markings are represented in both EPC and Netflow.

  So it appears the real bug in these devices is related to how they recognize QoS marking, they always show it as 0x00.

[SteJ]

Having the same issue in 2021, thanks for following up your post.

[michael.burke]

You will likely only be able to prove this issue out if you have access to the next hop device for packet capture.  That was the only way I was able to narrow it down.

[SteJ]

Hahaha. It's a 4500x with it's own weird issues with packet captures that only show a unidirectional flow and upstream of that it's a provider router so it looks like it's gonna be a span session with a laptop

Cheers