QOS marking and queuing for VoIP on Catalyst 3550

Unanswered Question
Jan 21st, 2007
User Badges:

We have a Catalyst 3550-24 on 12.2(25) that I need to configure to mark VoIP with dscp vales and to prioritize VoIP SCCP and RTP traffic outbound on interface F0/1 so it can be processed by our ASA firewall based on DSCP values. I think I have the configuration correct for the marking, but need confirmation, as well as assistance in applying prioritization for the VoIP traffic on the 3550. Attached is a configuration excerpt of the policy and class-maps I am considering.



Attachment: 
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
swharvey Mon, 01/22/2007 - 10:30
User Badges:

Anyone have a response for my inquiry? Is this the correct Netforum to post this question to?

fred.s.mollenkopf Mon, 01/22/2007 - 10:58
User Badges:
  • Gold, 750 points or more

Scott,


First and foremost, check out the QoS SRND as it has a section dedicated for 3550. This includes classification as well as queueing. Typically queueing on switches is recommended but in the real world you will find it's not deployed as much as best practices warrant.


Here is the link to the QoS SRND.


http://www.cisco.com/univercd/cc/td/doc/solution/esm/qossrnd.pdf


Please rate any helpful posts


Thanks


Fred

fred.s.mollenkopf Mon, 01/22/2007 - 11:08
User Badges:
  • Gold, 750 points or more

Scott,


Ok looking at the configuration, you don't currently have any queueing. I would recommend the basic configuration from the SRND. This can be found on page 94, section 2-42.


CAT3550(config)#interface range FastEthernet0/1 - 24

CAT3550(config-if)# wrr-queue bandwidth 5 25 70 1

! Q1-5% Q2-25% Q3-70% Q4=PQ

CAT3550(config-if)# wrr-queue cos-map 1 1

! Assigns Scavenger to Q1

CAT3550(config-if)# wrr-queue cos-map 2 0

! Assigns Best Effort to Q2

CAT3550(config-if)# wrr-queue cos-map 3 2 3 4 6 7

! Assigns CoS 2,3,4,6,7 to Q3

CAT3550(config-if)# wrr-queue cos-map 4 5

! Assigns VoIP to Q4 (PQ)

CAT3550(config-if)# priority-queue out

! Enables Q4 as PQ

CAT3550(config-if)#exit

CAT3550(config)#


Your classification looks ok with the exception that want to set the service-policy as an input and not an output. Also IP addresses for signaling need to encompass source addresses from IP Phones to CCM 2000 2002 (which looks like you have but can't tell without knowing your network). And RTP voice streams need to encompass all voice endpoints to all other voice endpoints on UDP 16384 32767 (again you have these but unsure on IP, most use port based only ACLs with any IP range but security dictates what you specify).


interface f0/1

service-policy input voip-qos


or range to set all ports


interface range f0/1 - 24

service-policy input voip-qos


Also using a Trusted model is easier. If they are all Cisco Phones then you could simplify the configuration by using "mls qos trust device cisco-phone" on all of your switchports.


interface range f0/1 - 24

mls qos trust device cisco-phone


With CCM 4.x the DSCP value for call signaling has changed to CS3 from AF31. If you would prefer to still use AF31 then you will want to use you marking configuration above that you originally posted. Note it's recommended to still look for AF31 and CS3 on all VoIP signaling queued hops until this has univerally been changed.


Please rate any helpful posts


Thanks


Fred




swharvey Mon, 01/22/2007 - 12:22
User Badges:

Thanks Fred for the excellent assessment and comments/recommendations. You information on the DSCP signalling changes on CM4.x is good to know. Regarding the acls, I did not want to use actual ip's in my example, but the source/destinations are correctly defined. Here is some further background that may explain what I am attempting to acheive. The 3550-24 is a DMZ L3 switch, with an SSL VPN appliance connected to F0/3. F0/1 connnects to an ASA Firewall, where I intend to implement QOS matching on DSCP values. The SSL VPN has remote Cisco IPC softphones, so I need to mark and prioritize their voice sig and data traffic with DSCP values on the 3550.


In hashing through your comments, I agree that I should be marking the packets on the ingress of F0/3 (inbound from ssl vpn appliance with softphone users) rather than outbound through F0/1 to the firewall. In addition, I understand the class-map and policy-map functions, but the queueing portion is the piece that is unclear to me. As I see, the example you provide is doing priority queuing, with 4 queues and 802.1p cos. A couple questions if I may:


1) If I use the basic queuing you provided, would I still need to apply the queuing to all 24 ports, even though I am only concerned about marking and prioritizing the traffic inbound on f0/3 and outbound on f0/1?


2) How do I tie the queuing example configuration to my class/policy-maps?


3) Can you explain in summation what the example queueing configuration is doing?


You're knowledge of QOS is formidable and I appreciate your help with this matter.


-Scott


fred.s.mollenkopf Mon, 01/22/2007 - 14:11
User Badges:
  • Gold, 750 points or more

Scott,


1) QoS queuing on switchports is usually more generic. As I said before, not even a lot of people apply it. You can theorectically apply it to just the ones you need but most admins do all of the ports and set and forget. Your call.


2) On that platform, the queueing is specified at the interface level. You can use the class/policy-maps in your example and if you are looking to limit the traffic do it via policing and not queueing. Policing is documented in the examples with the softphones and is applied in the policy-map with the "police" command. If you have specific questions on that let me know.


3) Yes, the example was creating a Weighted Round Robin Queue and assigning different COS values to bandwidth allocation for 3 queues (the 4th queue is actually Strict Priority and setting of 1 indicates it doesnt participate in WRR). Lastly it was applying anything in queue 4 as the priority queue so it would be serviced first on congestion. I believe the base for PQ is 30% so even though it looked like it was getting 1, that actually just sets the amount WRR bandwidth not overall bandwidth. From there WRR bandwidth gets about 70% of the link with the following percentages of the 70%, 5%-Q1,25%-Q2,70%-Q3. Which by the way it's good that you brought up CoS. There is a COS to DSCP map that needs to be changed depending on whether or not you are using AF31 or CS3.


AF31 use this command set.


mls qos map cos-dscp 0 8 16 26 32 46 48 56


CS3 use this command set.


mls qos map cos-dscp 0 8 16 24 32 46 48 56


Let me know if you have any questions.


Please rate any helpful posts


Thanks


Fred

swharvey Mon, 01/22/2007 - 18:23
User Badges:

Fred,


Below is the actual syntax of the configuration I implemented. Marking and prioritizing on the LAN is sufficient for my situation (vs. policing). Please take a minute to review the configuation and let me know if you see any issues with it:


mls qos

class-map match-all voip-signal

match access-group name voip-signal-qos

class-map match-all voip-rtp

match access-group name voip-rtp-qos


mls qos map cos-dscp 0 8 16 24 32 46 48 56


interface range FastEthernet0/1 - 24


wrr-queue bandwidth 5 25 70 1

wrr-queue cos-map 1 1

wrr-queue cos-map 2 0

wrr-queue cos-map 3 2 3 4 6 7

wrr-queue cos-map 4 5

priority-queue out


policy-map voip-qos

class voip-signal

set dscp cs3

class voip-rtp

set dscp ef


interface f0/3

service-policy input voip-qos


ip access-list extended voip-signal-qos

remark acl to mark cag voip signal traffic to other voice subnets with dscp cs3

permit tcp 10.1.202.0 0.0.0.127 gt 1023 host 10.1.2.11 eq 2000

permit tcp 10.1.202.0 0.0.0.127 gt 1023 host 10.1.2.12 eq 2000


ip access-list extended voip-rtp-qos

remark acl to mark and prioritize cag voip rtp traffic to other voice subnets with dscp ef

permit udp 10.1.202.128 0.0.0.127 10.1.2.0 0.0.1.255 range 16384 32767

permit udp 10.1.202.128 0.0.0.127 10.1.55.0 0.0.0.255 range 16384 32767

permit udp 10.1.202.128 0.0.0.127 10.1.57.0 0.0.0.255 range 16384 32767

permit udp 10.1.202.128 0.0.0.127 10.1.64.0 0.0.0.255 range 16384 32767

permit udp 10.1.202.128 0.0.0.127 10.1.66.0 0.0.0.255 range 16384 32767

permit udp 10.1.202.128 0.0.0.127 10.1.69.0 0.0.0.255 range 16384 32767

permit udp 10.1.202.128 0.0.0.127 10.1.73.0 0.0.0.255 range 16384 32767

permit udp 10.1.202.128 0.0.0.127 10.1.57.0 0.0.0.255 range 16384 32767

fred.s.mollenkopf Tue, 01/23/2007 - 06:57
User Badges:
  • Gold, 750 points or more

Scott,


This looks good. The only thing is RTP is bi-directional, so somewhere in the network on the edge ports I'm assuming you are doing the same type of classification from the phones to the VPN connected phones, which you probably are. Go ahead and deploy it, then you can verify everything is getting marked correctly by doing a "sh policy-map interface f0/3". This should verify that your traffic is coming into the switch from the VPN port is hitting your policy-map correctly, which it should.


Thanks


Fred

Actions

This Discussion