02-05-2009 07:38 AM - edited 03-06-2019 03:52 AM
Hi,
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
02-05-2009 07:48 AM
Are you matching the ACL in the class "QOS-RTP-Voice-Trust "?? You config should look like:-
class match-all QOS-RTP-Voice-Trust
match access-group 100
??
Then also check if you are getting hits on the ACL?
HTH>
02-05-2009 02:54 PM
Andrew,
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.
02-06-2009 01:26 AM
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!
HTH>
02-06-2009 02:51 AM
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 192.168.160.128 0.0.0.63 range 17000 17013 any
!
ip access-list extended VVLAN-ERICSSON-CALL-SIGNALLING
permit udp 192.168.160.128 0.0.0.63 any range 1718 1719
permit tcp 192.168.160.128 0.0.0.63 any eq 1720
permit tcp 192.168.160.128 0.0.0.63 any eq 1722
permit tcp 192.168.160.128 0.0.0.63 eq 1720 any
permit tcp 192.168.160.128 0.0.0.63 range 1390 1396 any
permit udp 192.168.160.128 0.0.0.63 eq 2948 any
permit udp 192.168.160.128 0.0.0.63 range 49152 49153 any
!
ip access-list extended VVLAN-ANY
permit ip 192.168.160.128 0.0.0.63 any
!
class-map match-all VVLAN-ERICSSON-VOICE
match access-group name VVLAN-ERICSSON-VOICE
class-map match-all VVLAN-ERICSSON-CALL-SIGNALLING
match access-group name VVLAN-ERICSSON-CALL-SIGNALLING
class-map match-all VVLAN-ANY
match access-group name VVLAN-ANY
!
policy-map ERICSSON-IPPHONE+PC-BASIC
class VVLAN-ERICSSON-VOICE
set dscp ef
police 128000 8000 exceed-action drop
class VVLAN-ERICSSON-CALL-SIGNALLING
set dscp cs3
police 32000 8000 exceed-action policed-dscp-transmit
class VVLAN-ANY
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.
HTH
Andy
02-07-2009 04:49 AM
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.
02-10-2009 07:55 PM
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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: