Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

3560 using extended ACLs not marking all Voice traffic.

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?

  • Other Collaboration Voice and Video Subjects
9 REPLIES
Cisco Employee

Re: 3560 using extended ACLs not marking all Voice traffic.

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,

New Member

Re: 3560 using extended ACLs not marking all Voice traffic.

It's just Video traffic that is not being marked. Also odd thing is that's its a percentage that's not being marked roughly 70%-85%.

Re: 3560 using extended ACLs not marking all Voice traffic.

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?

New Member

Re: 3560 using extended ACLs not marking all Voice traffic.

We want to ensure we capture traffic that the application marks with EF as well as unmarked traffic.

Cisco Employee

Re: 3560 using extended ACLs not marking all Voice traffic.

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

New Member

Re: 3560 using extended ACLs not marking all Voice traffic.

Hi, thanks for the suggestion. So you want to separate Video from signalling which is marked with a Cos value of 3 and additionally you are suggesting that Video streams from customer will be marked with af31 in addition to af41. Can you elaborate?

Cisco Employee

Re: 3560 using extended ACLs not marking all Voice traffic.

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,

New Member

Re: 3560 using extended ACLs not marking all Voice traffic.

Hi, you have a valid point about separating video and signalling packets -signalling as you say is CS3 but if I tweaked by config all of the Citrix traffic (AF31) would be remarked as Video!

Cisco Employee

Re: 3560 using extended ACLs not marking all Voice traffic.

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,

619
Views
2
Helpful
9
Replies
This widget could not be displayed.