3560 using extended ACLs not marking all Voice traffic.

Unanswered Question

Customer is using OCS for Voice and Video conferencing and is pre-marking packets and we are using extended acls to mark traffic and mls qos trust dscp on user ports to trust dscp values. See config below. (The 3560 isn't capable of displaying stats for show policy map int <fax/xx> and there are no hits on the access-lists.) Show mls qos int <fax/xx> stats do show dscp markings and DSCP value 34 incrementing during Video conference sessions. DSCP values 40-47 are mapped to queue 1 so Video would go in queue 4 which it services in a weighted round robin manner with other traffic. We are using Wireshark packet captures which reveal that only about 15 - 30% of packets remain marked after going through our access switch.

(Switch is running the following image - c3560-ipbase-mz.122-50.SE1.bin)

mls qos

class-map match-any citrix

match access-group 103

class-map match-any video-and-sip

match access-group 102

class-map match-any voice

match access-group 101

!

!

policy-map mark

class voice

set dscp ef

class video-and-sip

set dscp af41

class citrix

set dscp af31

class class-default

set dscp af11

interface FastEthernet0/1

description *** User ***

switchport mode access

priority-queue out

mls qos trust dscp

no snmp trap link-status

no cdp enable

spanning-tree portfast

service-policy input mark

access-list 101 permit ip any any dscp eq ef

access-list 101 permit udp any any range 16400 16499

access-list 101 permit udp any any eq 5004

access-list 102 permit ip any any dscp eq af41

access-list 102 permit tcp any any range 5060 5061

access-list 102 permit udp any any 5060

access-list 103 permit tcp any 10.224.252.128 0.0.0.128 eq 2598

access-list 103 permit tcp any 10.224.253.0 0.0.0.128 eq 2598

access-list 103 permit tcp any 10.196.144.0 0.0.0.128 eq 2598

access-list 103 permit tcp any 10.196.147.0 0.0.0.128 eq 2598

Why isn't the switch trusting the dscp values?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 2 (1 ratings)
Loading.
parshah Mon, 06/15/2009 - 12:50

Hi,

I see that your access-list 101 is set for range 16400 - 16499.

Per RFC, RTP uses even ports between rage 16384-32767. Now, MS might have a different range but to verify can you change the access-list 101 to the range per RFC and see if it helps.

Also, which packets are not being marked? voice, voice, signalling?

Thanks,

Florin Barhala Thu, 06/25/2009 - 06:16

Hy,

I don't get it. With class-map Voice you're catching all the traffic with DSCP value set to EF. (ACL 101).

Then why you set AGAIN this traffic with DSCP value EF, in your policy-map?

parshah Thu, 06/25/2009 - 09:08

Hi,

Can you tweak you ACL and class-map as such

mls qos

class-map match-any citrix

match access-group 103

class-map match-any video

match access-group 102

class-map match-any voice

match access-group 101

class-map match-any signalling

match access-group 104

!

!

policy-map mark

class voice

set dscp ef

class video

set dscp af41

class citrix

set dscp af31

class signalling

set dscp cs3

class class-default

set dscp af11

interface FastEthernet0/1

description *** User ***

switchport mode access

priority-queue out

mls qos trust dscp

no snmp trap link-status

no cdp enable

spanning-tree portfast

service-policy input mark

access-list 101 permit ip any any dscp eq ef

access-list 101 permit udp any any range 16400 16499

access-list 101 permit udp any any eq 5004

access-list 102 permit ip any any dscp eq af41

access-list 102 permit ip any any dscp eq af31

access-list 104 permit tcp any any range 5060 5061

access-list 104 permit udp any any 5060

access-list 103 permit tcp any 10.224.252.128 0.0.0.128 eq 2598

access-list 103 permit tcp any 10.224.253.0 0.0.0.128 eq 2598

access-list 103 permit tcp any 10.196.144.0 0.0.0.128 eq 2598

access-list 103 permit tcp any 10.196.147.0 0.0.0.128 eq 2598

parshah Thu, 06/25/2009 - 10:38

Hi,

What I am suggesting is to seperate video packets and signalling packets and have different dscp markings per the Cisco QoS recommendations.

Usually, video packets are AF31 or AF41, so that is what you should be looking at. I don't entirely agree with your config where you match the packet by DSCP marking and re-mark them. You are just adding additional overhead.

Ideally, if you want to re-mark the packets, you should be matching them by protocol and ports and not by dscp marking.

Anyway, the config I sent you, I just want you to try that and see if the switch is marking the video packets properly.

Thanks,

parshah Mon, 06/29/2009 - 08:56

Hi,

In your policy class, you are re-marking your traffic. So even though the ACL matches video packets that are AF41 and AF31, the policy map will re-mark it to AF41. So you should not have issues.

Anyway, the reason I am asking you to try this is to find out if there is a likelihood that there were some video packets that were AF31 and were not being marked properly.

Like I said before, the QoS config you have is not as recommended by QoD SRND and you might come across issue in future as your network grows.

Thanks,

Actions

This Discussion