05-28-2019 02:06 PM
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)
Solved! Go to Solution.
08-01-2019 09:29 AM
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.
06-06-2019 09:20 AM
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.
07-11-2019 11:35 AM - edited 07-11-2019 11:39 AM
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.
08-01-2019 09:29 AM
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.
05-05-2021 02:53 PM
Having the same issue in 2021, thanks for following up your post.
05-05-2021 03:45 PM
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.
05-05-2021 03:50 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide