cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1686
Views
5
Helpful
2
Replies

QoS Marking Not working

corycandia
Level 1
Level 1

Experts,

I'm following the admin guides for legacy Cat 3750/3650, but must be doing something wrong, or maybe missing a key concept.  Our classes of traffic are not getting marked with our desired DSCP.  I have confirmed this by traffic capture from monitor port to wireshark.

 

Hardware/Software

52 WS-C3560G-48TS 12.2(44)SE3 C3560-IPBASEK9-M

 

Goal:  Standard classify/mark traffic for upstream queuing

 

1.  Confirming QoS enabled globally:

CARM-CORE#show mls qos
QoS is enabled
QoS ip packet dscp rewrite is enabled

2.  ACL for traffic

Extended IP access list ACL_MARK-SMTP
10 permit tcp any any eq smtp

3. Class-map:

Class Map match-all CLASSMAP_MARK-SMTP (id 11)
Match access-group name ACL_MARK-SMTP

4. Policy-map:

Policy Map POLICYMAP_MARK-INGRESS
Class CLASSMAP_MARK-TEAMS-AUDIO
set dscp ef
Class CLASSMAP_MARK-TEAMS-VIDEO
set dscp cs4
Class CLASSMAP_MARK-TEAMS-SCREENSHARE
set dscp af21
Class CLASSMAP_MARK-EMBY
set dscp af31
Class CLASSMAP_MARK-SIP
set dscp cs3
Class CLASSMAP_MARK-WEBSERVER-TRAFFIC
set dscp af11
Class CLASSMAP_MARK-SNMP
set dscp cs2
Class CLASSMAP_MARK-SMTP
set dscp af21
Class class-default
trust dscp

5. Assigned service policy to interfaces:

interface GigabitEthernet0/1
description *** ESX1 QP1 ***
switchport trunk encapsulation dot1q
switchport trunk native vlan 999
switchport trunk allowed vlan 160,165,170,180,185,190,251-254
switchport mode trunk
switchport nonegotiate
mls qos trust dscp
flowcontrol receive desired
channel-group 1 mode active
spanning-tree portfast
spanning-tree bpdufilter enable
service-policy input POLICYMAP_MARK-INGRESS
interface Port-channel1
description *** ESX1 PTCHL ***
switchport trunk encapsulation dot1q
switchport trunk native vlan 999
switchport trunk allowed vlan 160,165,170,180,185,190,251-254
switchport mode trunk
switchport nonegotiate
flowcontrol receive desired

NOTE: The example interface is a member of the port-channel, but in the 3560 series, you apply QoS to physical port, not Ether-channel according to administrator guide.

 

Shows:

CARM-CORE#show mls qos interface gi0/1
GigabitEthernet0/1
Attached policy-map for Ingress: POLICYMAP_MARK-INGRESS
trust state: trust dscp
trust mode: trust dscp
trust enabled flag: ena
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: none
qos mode: port-based
CARM-CORE#show mls qos interface gi 0/1 statistics
Shows all packets in DSCP 0 (default), format doesn't paste well.

Example.PNG

 

 

This photo shows local SMTP server to internet not getting marked to desired af21, but inbound marking at WAN edge router is working as that traffic is getting marked.

I don't understand why the outbound traffic isn't marked.  ACL should match the local traffic.  I have used wireshark to confirm that the outbound SMTP traffic is from local host, src port 55790, dst port 25, which should match any any eq 25.

 

What am I missing here, shouldn't this be easy?

Thanks!

1 Accepted Solution

Accepted Solutions

willwetherman
Spotlight
Spotlight

Hi @corycandia 

 

Your config looks good and you are correct that the service policy should only be applied to the port-channel member interfaces and not the logical port-channel interface itself.

 

Regarding verification, what port are you monitoring to verify the QoS marking? If it is the port(s) connecting to your ESXI server then this will not show the desired marking as the traffic is only marked once received and egresses the switch. Can you try a packet capture on the egress port (assuming facing your internet connection / WAN)?

 

This will be also be the same for the 'show mls qos interface Gig0/1 statistics' command. This will only show packets that are already marked by the end host/application as they are received on the port. Instead, can you run the show command on the egress port and see if DSCP 18 is being marked/incremented for outgoing traffic?

View solution in original post

2 Replies 2

willwetherman
Spotlight
Spotlight

Hi @corycandia 

 

Your config looks good and you are correct that the service policy should only be applied to the port-channel member interfaces and not the logical port-channel interface itself.

 

Regarding verification, what port are you monitoring to verify the QoS marking? If it is the port(s) connecting to your ESXI server then this will not show the desired marking as the traffic is only marked once received and egresses the switch. Can you try a packet capture on the egress port (assuming facing your internet connection / WAN)?

 

This will be also be the same for the 'show mls qos interface Gig0/1 statistics' command. This will only show packets that are already marked by the end host/application as they are received on the port. Instead, can you run the show command on the egress port and see if DSCP 18 is being marked/incremented for outgoing traffic?

You were absolutely right.  I thought the order of operations applied QoS stuff first thing, but nope.  Monitoring on the marking switch was not useful, needed to monitor on the next upstream device.

Got the result we were expecting:

Result.PNG

Review Cisco Networking for a $25 gift card