Re: re-marking DSCP values

stephen jeffrey · ‎03-14-2018

We have a 3560 (12.2(25r)) which was installed a number of years ago. It has Nortel VoIP phones connected to it. the Phones marks signalling traffic with DSCP value of 40. this is re-marked to 26.

I can see this in the qos statistics for the interface.

FastEthernet0/26

dscp: incoming
-------------------------------

0 - 4 : 434769 0 0 0 0
5 - 9 : 0 0 0 0 0
10 - 14 : 0 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 0 0 0 0 0
25 - 29 : 0 0 0 0 0
30 - 34 : 0 0 0 0 0
35 - 39 : 0 0 0 0 0
40 - 44 : 88473 0 0 0 0
45 - 49 : 0 112828 0 0 0
50 - 54 : 0 0 0 0 0
55 - 59 : 0 0 0 0 0
60 - 64 : 0 0 0 0
dscp: outgoing
-------------------------------

0 - 4 : 817469 0 0 0 0
5 - 9 : 0 0 0 0 0
10 - 14 : 0 0 0 0 0
15 - 19 : 0 0 0 0 0
20 - 24 : 0 0 0 0 0
25 - 29 : 0 88588 0 0 0
30 - 34 : 0 0 0 0 0
35 - 39 : 0 0 0 0 0
40 - 44 : 0 0 0 0 0
45 - 49 : 0 102031 0 12 0
50 - 54 : 0 0 0 0 0
55 - 59 : 0 0 0 0 0
60 - 64 : 0 0 0 0
cos: incoming
-------------------------------

0 - 4 : 436225 0 0 0 0
5 - 7 : 0 202054 0
cos: outgoing
-------------------------------

0 - 4 : 1113668 0 0 88588 0
5 - 7 : 102951 244 1004
Policer: Inprofile: 0 OutofProfile: 0

I can see a class-map and policy-map have been created. but no service-policy has been applied to any interfaces. How is this working. Thanks in advance. I'm sure its something simple I've overlooked.

class-map match-all REMARK
match ip dscp cs5
!
!
policy-map RE-MARK40
class REMARK
set dscp af31

interface FastEthernet0/26
switchport access vlan 11
switchport mode access
switchport voice vlan 20
no logging event link-status
srr-queue bandwidth share 10 10 60 20
srr-queue bandwidth shape 10 0 0 0
priority-queue out
mls qos trust device cisco-phone
mls qos trust cos
no snmp trap link-status
auto qos voip cisco-phone
spanning-tree portfast
spanning-tree bpduguard enable

Mark Malone · ‎03-14-2018

Hi

you actually have 2 forms of layer 2 qos in operation there you only need 1

your running both auto qos and mls qos on same switch , you should pick one

The auto qos is seperate to mls , mls creates it own global mls maps too in queues , policy map only gets applied in ios-xe with auto qos on ios you just need get the auto qos under the interface

with priority queue out all that queues gets serviced first before anything else , all critical traffic thats

is not in play if its not in dumped into it

the class map you provided is not in use if not applied

priority-queue out
mls qos trust device cisco-phone
mls qos trust cos
auto qos voip cisco-phone

part 1 and 2 of this doc explain MLS very well how it works on switch

http://www.davidsudjiman.info/2012/02/14/cisco-3560-mls-qos-part-1/

chrihussey · ‎03-14-2018

I agree that there does not appear to be anything specific to the interface that would affect the change.

I would assume that the markings going out of the interface towards the phone have been marked elsewhere on the network or coming into the switch on another port.

With regard to the incoming DSCP 40 packets, I question whether they are getting remarked to 26 at all, but instead getting remarked to DSCP 0. I say this because the interface is configured to trust a cisco-phone. If there is a Nortel phone connected, it would be untrusted and marked to the default best effort DSCP 0.

It may be best to provide the full config (if possible) along with "sh mls qos int f0/26"to better understand what is actually happening.

Hope this helps

stephen jeffrey · ‎03-14-2018

Hi, thanks for replies. I think you may be right, I think I convinced myself the incoming and outgoing for DSCP were the same packets getting re-marked. Config and command below.

I'ts a remote site so cant do monitor on any of the ports to wireshark and see.

ip subnet-zero
ip routing
no ip domain-lookup
!
!
mls qos map cos-dscp 0 8 16 26 32 46 48 56
mls qos srr-queue input bandwidth 90 10
mls qos srr-queue input threshold 1 8 16
mls qos srr-queue input threshold 2 34 66
mls qos srr-queue input buffers 67 33
mls qos srr-queue input cos-map queue 1 threshold 2 1
mls qos srr-queue input cos-map queue 1 threshold 3 0
mls qos srr-queue input cos-map queue 2 threshold 1 2
mls qos srr-queue input cos-map queue 2 threshold 2 4 6 7
mls qos srr-queue input cos-map queue 2 threshold 3 3 5
mls qos srr-queue input dscp-map queue 1 threshold 2 9 10 11 12 13 14 15
mls qos srr-queue input dscp-map queue 1 threshold 3 0 1 2 3 4 5 6 7
mls qos srr-queue input dscp-map queue 1 threshold 3 32
mls qos srr-queue input dscp-map queue 2 threshold 1 16 17 18 19 20 21 22 23
mls qos srr-queue input dscp-map queue 2 threshold 2 33 34 35 36 37 38 39 48
mls qos srr-queue input dscp-map queue 2 threshold 2 49 50 51 52 53 54 55 56
mls qos srr-queue input dscp-map queue 2 threshold 2 57 58 59 60 61 62 63
mls qos srr-queue input dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31
mls qos srr-queue input dscp-map queue 2 threshold 3 40 41 42 43 44 45 46 47
mls qos srr-queue output cos-map queue 1 threshold 3 5
mls qos srr-queue output cos-map queue 2 threshold 3 3 6 7
mls qos srr-queue output cos-map queue 3 threshold 3 2 4
mls qos srr-queue output cos-map queue 4 threshold 2 1
mls qos srr-queue output cos-map queue 4 threshold 3 0
mls qos srr-queue output dscp-map queue 1 threshold 3 40 41 42 43 44 45 46 47
mls qos srr-queue output dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31
mls qos srr-queue output dscp-map queue 2 threshold 3 48 49 50 51 52 53 54 55
mls qos srr-queue output dscp-map queue 2 threshold 3 56 57 58 59 60 61 62 63
mls qos srr-queue output dscp-map queue 3 threshold 3 16 17 18 19 20 21 22 23
mls qos srr-queue output dscp-map queue 3 threshold 3 32 33 34 35 36 37 38 39
mls qos srr-queue output dscp-map queue 4 threshold 1 8
mls qos srr-queue output dscp-map queue 4 threshold 2 9 10 11 12 13 14 15
mls qos srr-queue output dscp-map queue 4 threshold 3 0 1 2 3 4 5 6 7
mls qos queue-set output 1 threshold 1 138 138 92 138
mls qos queue-set output 1 threshold 2 138 138 92 400
mls qos queue-set output 1 threshold 3 36 77 100 318
mls qos queue-set output 1 threshold 4 20 50 67 400
mls qos queue-set output 2 threshold 1 149 149 100 149
mls qos queue-set output 2 threshold 2 118 118 100 235
mls qos queue-set output 2 threshold 3 41 68 100 272
mls qos queue-set output 2 threshold 4 42 72 100 242
mls qos queue-set output 1 buffers 10 10 26 54
mls qos queue-set output 2 buffers 16 6 17 61
mls qos
!
!
no file verify auto
!
spanning-tree mode rapid-pvst
spanning-tree extend system-id
spanning-tree vlan 10,20 priority 4096
!
vlan internal allocation policy ascending
!
class-map match-all REMARK
match ip dscp cs5
!
!
policy-map RE-MARK40
class REMARK
set dscp af31
!
!
interface FastEthernet0/1
description WAN Router Link
no switchport
ip address xxxxxxxxx
priority-queue out
mls qos trust dscp
no snmp trap link-status

interface FastEthernet0/26
switchport access vlan 11
switchport mode access
switchport voice vlan 20
no logging event link-status
srr-queue bandwidth share 10 10 60 20
srr-queue bandwidth shape 10 0 0 0
priority-queue out
mls qos trust device cisco-phone
mls qos trust cos
no snmp trap link-status
auto qos voip cisco-phone
spanning-tree portfast
spanning-tree bpduguard enable

!
interface Vlan11
ip address xxxxxx
!
interface Vlan20
description Lowestoft_Voice
ip address xxxx
ip helper-address xxxxxx
no ip redirects
no ip unreachables
!
ip classless
ip route xxxxxxxxx
ip route xxxxxx
!

#sh mls qos int f0/26
FastEthernet0/26
trust state: not trusted
trust mode: trust cos
trust enabled flag: dis
COS override: dis
default COS: 0
DSCP Mutation Map: Default DSCP Mutation Map
Trust device: cisco-phone
qos mode: port-based

Mark Malone · ‎03-14-2018

So the MLS is trusting COS, so as example phone will mark at source COS5 then MLS will re-map it back to DSCP 46 for priority queuing

mls qos map cos-dscp 0 8 16 26 32 46 48 56
Cos 1 2 3 4 5

you could as an option just set the port to mls qos trust dscp that way it doesn't have to re-map while passing through the switch , set the same on the up link , any values that are set by source device are then trusted by dscp right way through but as its set now it should work fine

its better that class map us not in use anyway as its setting voice to a lower priority which could cause you issues

chrihussey · ‎03-14-2018

So the WAN interface is trusted and will pass the markings. I think you could then ascertain that the signalling is correct coming across the WAN and towards the phone.

However, from the phone to the WAN I would assume that all packets are getting marked DSCP 0, including the voice (DSCP 46) packets. Not sure how the Nortel phones work, but when you make an on net to on net VoIP call with Cisco the packets go phone to phone. If this is the case with the Nortel you could verify possibly verify this if you have someone make a VoIP call from that phone to a VoIP phone in your location and sniff the packets there to see what kind of markings are present from that phone.

Hope that makes sense an helps

Joseph W. Doherty · ‎03-14-2018

"I can see a class-map and policy-map have been created. but no service-policy has been applied to any interfaces. How is this working."

The 3560 (and 3750) supports CoS and/or DSCP translation maps. By default, they shouldn't change values, but they can by modified. Look for statements like:

mls qos map policed-dscp 24 34 46 to 0

PS:

https://www.cisco.com/c/en/us/support/docs/switches/catalyst-3750-series-switches/91862-cat3750-qos-config.html

Mark Malone · ‎03-14-2018

also the wan is where the bottle neck is usually too so if anywhere that's where you should think about adding the actual class/policy map at least for voice anyway , you could just match the voice subnet and make sure its set as EF , you dont want that getting delayed or impeded