3560 QoS - classification not working

Unanswered Question
Feb 5th, 2009
User Badges:


I am trying to use a policy map on a 3560 L2 interface in order to classify non-Cisco VoIP traffic. The policy map is using an extended access list to match the protocol information. Based on sniffer captures the config I have doesn't seem to be working. Snippets are pasted below. Any suggestions are greatly appreciated.

policy-map QOS-Police

class QOS-RTP-Voice-Trust

set dscp ef

class QOS-SIP-Control-Trust

set dscp cs3

class class-default

set dscp default

access-list 100 permit udp any range 3462 3525 any

access-list 101 permit udp any any eq 5060

int fa0/16

srr-queue bandwidth share 1 70 25 5

srr-queue bandwidth shape 3 0 0 0

priority-queue out

spanning-tree portfast

service-policy input QOS-Police

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
klmueller Thu, 02/05/2009 - 14:54
User Badges:


I forgot I paste that piece:

class-map match-all QOS-RTP-Voice-Trust

match access-group 100

class-map match-all QOS-SIP-Control-Trust

match access-group 101


Have you had luck using IP access lists in this scenario? I guess my concern was that for some reason those may not work in the config I have on a 3560 L2 switchport.

I have used acl's for QoS marking/policing quite alot. However mainly on routers - which handle this stuff really well. I have also done QoS on 65xx,3750Metro & 3750-PS switches. They on the other hand are crap at showing what is going on. To date I have not done anything with the 3550/36500's.

But the peice of information that I have found totally invaluable is the QoS SRND - http://www.cisco.com/univercd/cc/td/doc/solution/esm/qossrnd.pdf

In the above you have the 3550/3560 recommendations & config examples - more importantly the relevant "show" commands to give you an idea on what is going on with your policy!


andrew.butterworth Fri, 02/06/2009 - 02:51
User Badges:
  • Gold, 750 points or more

What you have shown should work. I have working examples of a similar setup for Ericsson/Aastra IP Phones as follows:

ip access-list extended VVLAN-ERICSSON-VOICE

permit udp range 17000 17013 any


ip access-list extended VVLAN-ERICSSON-CALL-SIGNALLING

permit udp any range 1718 1719

permit tcp any eq 1720

permit tcp any eq 1722

permit tcp eq 1720 any

permit tcp range 1390 1396 any

permit udp eq 2948 any

permit udp range 49152 49153 any


ip access-list extended VVLAN-ANY

permit ip any


class-map match-all VVLAN-ERICSSON-VOICE

match access-group name VVLAN-ERICSSON-VOICE


match access-group name VVLAN-ERICSSON-CALL-SIGNALLING

class-map match-all VVLAN-ANY

match access-group name VVLAN-ANY




set dscp ef

police 128000 8000 exceed-action drop


set dscp cs3

police 32000 8000 exceed-action policed-dscp-transmit


set dscp default

police 32000 8000 exceed-action policed-dscp-transmit

class class-default

set dscp default

police 5000000 8000 exceed-action policed-dscp-transmit


interface FastEthernet0/48

description Ericsson IP Phone + PC

switchport access vlan 10

switchport mode access

switchport voice vlan 50

switchport port-security maximum 2 vlan access

switchport port-security maximum 1 vlan voice

switchport port-security

switchport port-security aging time 10

switchport port-security violation restrict

switchport port-security aging type inactivity

srr-queue bandwidth share 1 70 25 5

srr-queue bandwidth shape 3 0 0 0

priority-queue out

no snmp trap link-status

spanning-tree portfast

spanning-tree bpdufilter enable

spanning-tree bpduguard enable

service-policy input ERICSSON-IPPHONE+PC-BASIC

ip dhcp snooping limit rate 100


I have verified this on the egress ports using a sniffer and the packets are defintely marked as per the ingress policy. The counters in the command 'show policy-map interface x/x' don't work so don't expect to see any of these increment. You need to look on the egress port with the command 'show mls qos interface statistics' as well as monitoring (span session) the egress port. You won't see any remarking on the ingress port through a span session.



cdusio Sat, 02/07/2009 - 04:49
User Badges:
  • Bronze, 100 points or more

Chances are that you're just not receiving traffic that's matching the ACL you are trying to trigger. Andy is correct that the best way to see this would be to look at a sniffer trace. You can always set the router to reclassify the traffic accordingly but that might defeat the purpose as your intent seems to be to provide Layer II QoS and then send it out onn the WAN accordingly.

klmueller Tue, 02/10/2009 - 19:55
User Badges:

Thanks for all the suggestions. It turns out the classification was working, you just can't see its effect when monitoring with a sniffer the ingress port that the policy-map is applied to. When I got packet captures of the switch uplink port I could see all the packets classified as I intended.


This Discussion