Disclaimer: I am not a Cisco IOS expert.

I have dealt with them mostly in dialup (access server) capacity, but I have some QoS experience with these routers. I have worked mainly with the 2600series. First things first: If you do not have control over the hardware at BOTH ends of your link, you will have suboptimal performance. However I have found that with a little work it's not quite so bad. I will be talking about my real-world setup: a point-to-point HDSL DS1 to MCI, and a similar T1, but with a 2500-series router and AT&T. Both routers try to keep the incoming traffic UNDER the maximum link speed in order to prevent the upstream router from plugging the link with traffic and drowning out VOIP traffic. Since you cannot shape traffic coming to you, you try and police it instead. NOTE: This only works with TCP traffic. UDP/ICMP traffic cannot be policed, since these protocols do not try and ensure that data transmission was successful. I have an access group (105) which matches any of my VOIP traffic: access-list 105 remark VOIP (SIP/IAX/IAX2) traffic gets top priori ty (5) access-list 105 permit udp any any eq 4569 access-list 105 permit udp any any eq 5004 access-list 105 permit udp any any eq 5036 access-list 105 permit udp any any eq 5060 access-list 105 permit ip host OTHER.VOIP.HOST.HERE any access-list 105 permit ip any host OTHER.VOIP.HOST.HERE As you can see, I'm matching UDP 4569 (IAX2), 5004 (RTP), 5036 (IAX1) and 5060 (SIP). I am also allowing any traffic from OTHER.VOIP.HOST.HERE to be included. This is a SIP device and I'm trying to also match the actual voice traffic. SIP's an awful little protocol since it uses dynamic port allocation. You may want to alter these rules to taste; You can accidentally include non-VOIP traffic here very easily. I'm not overly worried about it in my particular setup. Now, to prevent the upstream from plugging up the link, I am going to set up two input rate-limit rules to police the incoming traffic. The first will allow 128k of VOIP traffic in no matter what, set its precedence to high priority (5) and transmit it. The other part of the first rule will allow any excess VOIP traffic (above 128k), but its precedence set to best-effort (0) and the remaining police rule will be evaluated as well. The second rate-limit command will allow no more than 1408kbps through; any excess will be dropped. Again, this only works for TCP traffic, since dropped packets will cause the sender to back off and try again slower. If your link is full of other protocols without this particular feature, this won't do anything to help: in s0/0 rate-limit input access-group 105 128000 65536 65536 conformaction set-prec-transmit 5 exceed-action set-prec-continue 0 rate-limit input 1408000 8000 8000 conform-action transmit exceedaction drop At any rate, that takes care of the incoming traffic. Ideally you want to be able to control the traffic on both sides of the link, but the world is far from ideal.

Now to handle outgoing traffic. This is where you have all the power. In the 2600 series of routers you can use service polices and LLQ (Low Latency Queueing) this queueing discipline was _designed_ for VOIP. I am running IOS 12.1(21) RELEASE. Setting it up is a snap: class-map voice match access-group 105 ! policy-map policy1 class voice priority 96 class class-default fair-queue ! The first pair of commands sets up a class called 'voice', which matches any traffic which matches access group 105 (the VOIP ACL I have defined above). The second group actually sets up the police map; it guarantees 96kbps of traffic for the voice class, and everything else is queued using the fair-queue discipline. Now all you have to do is attach this to an interface: in s0/0 service-policy output policy1 in e0/0 service-policy output policy1 Again, you can only do meaningful QoS on OUTGOING traffic. Once the traffic's in the pipe, you're stuck with it. Other hints: My particular setup has an incoming T1 to the 2600, then it is split off to various companies through an SDSL DSLAM. I have set up ACLs to match the companies who are using VOIP in a similar fashion to how I did the s0/0 polcing; I try to keep ther individual links from plugging up so that any VOIP traffic can get through, even under excessive TCP load. An example: in e0/0 rate-limit output access-group 2128 512000 8000 8000 conformaction set-prec-transmit 1 exceed-action continue rate-limit output access-group 2128 128000 8000 8000 conformaction set-prec-transmit 1 exceed-action drop Here ACL 2128 matches one of the companies /30 network (all companies have a /30 network with us, and additional IPs are routed to their end of the /30 if necessary). They have a 768kbps link. The first rate-limit matches the first 512kbps of their traffic, which I send off immediately. Above 512kbps they fall into the second ACL which gives them a second kick at the cat, so to speak. After they exceed 768k total, their traffic starts to get dropped. This "dual-action" rate-limit on traffic to their router seems to work better than a single 768000 rate-limit. I can only guess that it is working with the output service policy in nicer manner.

I need to set up more output policies to enforce minimum VOIP traffic on a per-customer basis in order to get better VOIP functionality.

Another example: class-map match-any VOIP-SIGNAL match ip dscp cs5 match ip precedence 4 match ip precedence 3 class-map match-any VOIP-RTP match ip dscp ef match ip precedence 5 ! ! policy-map QOS-Policy class VOIP-SIGNAL priority percent 5 class VOIP-RTP priority percent 70 class class-default fair-queue random-detect ! interface Serial0/0/0:0 service-policy output QOS-Policy Yet another example, this time for routers using sub-interfaces: no access-list 117 access-list 117 remark VOIP (SIP/IAX/IAX2) signaling gets ensured bandwidth (16) access-list 117 permit udp any any eq 4569 access-list 117 permit udp any any eq 5036 access-list 117 permit udp any any eq 5060 no access-list 118 access-list 118 remark VOIP (RTP) traffic gets top priority (5) access-list 118 permit udp any any range 16384 32767 class-map match-all voice-traffic match access-group 118 class-map match-all voice-signaling match access-group 117 policy-map qos-voice class voice-traffic priority 240 class voice-signaling bandwidth 16 policy-map qos-parent class class-default shape average 2000000

service-policy qos-voice interface FastEthernet0/0.1 service-policy output qos-parent -b Configuring Cisco Switches for QoS with Cisco 79xx IP Phones: interface FastEthernet0/1 description IP Phone port switchport trunk encapsulation dot1q switchport trunk native vlan 106 data vlan switchport mode trunk switchport voice vlan 103 ur voice vlan switchport priority extend cos 0 o IP Phone don't also classify traffic spanning-tree portfast

!subsitute "106" for your !subsitute "103" for yo !ensures PCs connected t

With this configuration all voice traffic will get an L2 COS tag of 5 and a L3 IP Precedence of 5. All data traffic from the connected PC will get an L2 COS of 0. Additionally ensure the the speed and duplex settings for the port are set to auto. If the port is statically configured to 100baseT full-duplex, the phone will configure it's port to 100baseT halfduplex, resulting in a duplex mismatch. If your switch supports inline power, add the following: power inline auto -b Yet another way, this time for those of us stuck with DSL (ATM w/ PPPoE)

Here is where you create classes that will be used by the VoicePolicy below. You could do some direct matches here. I prefer to do this via access lists. That way you can create multiple and test different things by switching between which list you map.

class-map match-any signaling match access-group 102 class-map match-any voice match access-group 101

Here is where you create your voice policy. Here you can reserve bandwidth for your traffic. You may need to adjust these values to reflect your specific case and upload speeds. The idea here is to have plenty of room for RTP and SIP traffic with overhead no matter what other traffic is present.

policy-map VoicePolicy class voice priority 384 class signaling priority 128 class class-default fair-queue

This is where the QoS policy is applied for outbound. Note your Interface name, DSL settings, and bandwidth is probably different than mine. My upload is 768 so if you had 512 upload you would use vbr-nrt 512 512. If you regularly see LESS than your maximum upload you may wish to adjust the second value to match your true upload speed. i.e vbr-nrt 512 384. The most interesting part of this and most important part though is the tx-ring-limit statement. I originally had this setup without it and it QoS never seemed to work. Turns out, according to a cisco tech, the DSL interface has its own rather large packet buffer. Apparently it will store large a mounts of packets that may bypass QoS. Setting this setting only allows 3 packets in that buffer thus forcing QoS policies to apply on active non buffered traffic. You can then check out if this actually worked by running 'show policy-map interface'. Make sure neither of your voice or signaling maps are dropping packets. Remember, you can only apply the service policy on OUTBOUND traffic in any useful way. We have no way of controlling the flow of traffic flowing inbound.

interface ATM0/0/0 no ip address no atm ilmi-keepalive bundle-enable dsl operating-mode auto pvc 0/35 vbr-nrt 768 768 tx-ring-limit 3 service-policy output VoicePolicy pppoe-client dial-pool-number 1

You'll note here that QoS does NOT get applied to the dialer interface like you would think. It actually goes on the ATM PVC which calls the dialer

interface Dialer0 ip unnumbered FastEthernet0/0 no ip redirects no ip unreachables ip mtu 1492 encapsulation ppp no ip route-cache cef no ip route-cache ip tcp adjust-mss 1452 no ip mroute-cache dialer pool 1 no cdp enable

ppp authentication pap chap callin ppp pap sent-username <your PPPoE Username> password 0 <Your PPPoE Password>

Change these access lists to match your situation. Here we match only UDP ef voice traffic and af41 signaling traffic

access-list 101 remark ***QoS for RTP and IAX*** access-list 101 permit udp any any dscp ef access-list 102 remark ***QOS for SIP*** access-list 102 permit udp any any dscp af41 -raymckay See Also:

QoS Cisco IOS Cisco QoS: Quality of Service in VOIP Networks

Created by andrew, Last modification by raymckay on Mon 28 of Apr, 2008 [14:59]

Comments
Comments Filter Messages

Style

Sort

set

QoS in Cisco C837 (IOS C837-K9O3SY6-M Ver 12.4(3) )

by Juan Ignacio Acosta on Friday 11 of August, 2006 [07:15:22] Sorry for the repeat comments, I have some problems whit the internet explorer... Here is my config for a Cisco 837 Router whit IOS show in the topic, that support QoS services.. But I still having problems whit jitter when some protocol overhead the connection.. In my case, I share a DSL connection for terminal services and VOIP, and the problem is when any TS user prints, this solve at 80% the problem, but still whit problems. class-map match-any SDMVoice-Ethernet0 match protocol rtp audio class-map match-any SDMTrans-Ethernet0 match protocol citrix match protocol finger match protocol secure-telnet match protocol sqlnet match protocol sqlserver match protocol ssh

match protocol telnet match protocol xwindows class-map match-any SDMScave-Ethernet0 match protocol napster match protocol fasttrack match protocol gnutella class-map match-any SDMBulk-Ethernet0 match protocol exchange match protocol ftp match protocol irc match protocol nntp match protocol pop3 match protocol printer match protocol secure-ftp match protocol secure-irc match protocol secure-nntp match protocol secure-pop3 match protocol smtp match protocol tftp class-map match-any SDMSignal-Ethernet0 match protocol h323 match protocol rtcp class-map match-any SDMRout-Ethernet0 match protocol bgp match protocol eigrp match protocol ospf match protocol rip match protocol rsvp class-map match-any SDMManage-Ethernet0 match protocol dhcp match protocol dns match protocol imap match protocol kerberos match protocol ldap match protocol secure-imap match protocol secure-ldap match protocol snmp match protocol socks match protocol syslog class-map match-any SDMIVideo-Ethernet0 match protocol rtp video class-map match-any SDMSVideo-Ethernet0 match protocol cuseeme match protocol netshow match protocol rtsp match protocol streamwork match protocol vdolive policy-map SDM-Pol-Ethernet0 class SDMSignal-Ethernet0 bandwidth remaining percent 10 set dscp cs3

class SDMManage-Ethernet0 bandwidth remaining percent 7 set dscp cs2 class SDMRout-Ethernet0 bandwidth remaining percent 7 set dscp cs6 class SDMTrans-Ethernet0 bandwidth remaining percent 75 set dscp af21 class SDMVoice-Ethernet0 priority percent 58 set dscp ef

QoS in Cisco C837 (IOS C837-K9O3SY6-M Ver 12.4(3) )

by Juan Ignacio Acosta on Friday 11 of August, 2006 [07:14:18]

QoS in Cisco C837 (IOS C837-K9O3SY6-M Ver 12.4(3) )

by Juan Ignacio Acosta on Friday 11 of August, 2006 [07:13:52]

Cisco 1721 example - QoS settings for config

by Jon Carnes on Thursday 03 of August, 2006 [10:10:55] Here is a standard config we use on Cisco routers for prioritizing Voice when the data hits a network bottle-neck. In this example the bottle-neck is the data/voice moving off the local 100Mb LAN over a T-1 link (1.5Mb). Client side router

Using 1427 out of 29688 bytes

version 12.3 service timestamps debug datetime msec localtime service timestamps log datetime msec localtime service password-encryption hostname Cisco1721 enable secret 0 BIGsecret enable password 0 bigsecret memory-size iomem 15 clock timezone EST -5 clock summer-time EST recurring no aaa new-model ip subnet-zero no ip domain lookup ip cef class-map match-all VOIP-CONTROL match access-group 101 class-map match-all VOIP-RTP

match ip rtp 16383 16383 match ip precedence 5 policy-map QOS-POLICY-1544K class VOIP-CONTROL bandwidth 80 class VOIP-RTP priority 384 class class-default fair-queue interface FastEthernet0/0 ip address 192.168.30.1 255.255.255.0 speed auto interface Serial0/0 bandwidth 1536 ip address 10.192.168.30 255.255.255.252 encapsulation ppp load-interval 30 no cdp enable service-policy output QOS-POLICY-1544K hold-queue 200 in hold-queue 200 out ip classless ip route 0.0.0.0 0.0.0.0 10.129.168.29 no ip http server access-list 101 permit ip any any precedence flash access-list 101 permit ip any any dscp af31

These mark the control protocols used by our Cisco phones Look at your phones and see what DSCP they use for call control
no cdp run line con 0 line aux 0 line vty 0 4 password 0 BIGpass login sntp server 10.192.168.11 end Notes: The Class-Map VOIP-CONTROL matches the control packets sent out by

our Cisco Phones. The Class-Map VOIP-RTP matches the packets carrying the actual Voi ce stream The Policy-Map QOS-POLICY-1544K sets aside 80kb of the available b andwidth for the control packets, and 384kb for the Voice stream it also gives the Voice stream priority to the CPU so the Voice pa ckets always cut to the head of the line (no FIFO here!). The serial interface is set to use the Policy-Map QOS-POLICY-1544K for all outbound traffic. We are only concerned about Outbound tra ffic since the traffic on this interface is moving from an inbound 100Mb to an outbound 1.5Mb... which is quite a bottle-neck. If you can't do any fancy Policy-Maps (due to router limitations), then the next best thing is to use the built in priorities of the packets. You can do this by adding "fair-queue" as one of the inte rface options listed under the Serial interface. By default all in terfaces use FIFO which is a very poor choice for a bottle-neck on a VoIP network. Using Fair-Queueing gives noticably better results , though not as good as a Policy Map that prioritizes voice traffi c and reserves bandwidth for voice to use... Note that we also increase the size of the Holding Queues for the Serial interface. This keeps the buffers from filling up during hi gh traffic use. If the buffers filled up then no packets would mak e it into the interface - and all packets (Voice and Data) would b e bounced for a few ms till enough packets in the buffer were proc essed to allow new packets in. You can use the exact same programming on the other router's serial interface. This gives Voice priority in passing through the bottle-neck caused by the small bandwidth of the T-1. Jon Carnes (FeatureTel.com)

Need setup for Cisco ADSL Router

by borghart on Friday 09 of June, 2006 [06:48:40] Hi, has someone got a cisco adsl router with approved voip prioritisation up and running? i need such a config for a cisco 826. tnanks, borghart

Need help setting up QoS on Cisco 2621 running 12.2 IOS

by cmattfletcher on Thursday 04 of August, 2005 [12:29:44] I need help getting QoS configured. I've been reading about different setups and guarenteed bandwidth, priority, blah blah, etc. I have a full T and will cap it about 10% to 1408. I want to set aside 512k for voice priority and 896k for data. 499 is the max I would ever use for VoIP because I have 8 phones @ 62.4k per IP. I want data to be able to creep over into the priority side as needed. Any ideas? There is a Netscreen firewall in front of the cisco and a Nortel Phone system behind it. I will be serving three other offices for VoIP from this Cisco 2621 and eventually plan to have Cisco 1750's on the other end at each office. Any assistance getting this off the ground is much appreciaited. Thanks!

priority vs bandwidth
by SeanWalberg on Monday 11 of April, 2005 [17:20:52] bandwidth doesn't control jitter. priority is what you want to use. The priority value you give in your policy-map should be the maximum you will use, ie 5 G.711 calls @80Kbit = "priority 400". If you're not using all 400K, your other classes can use it. I once put together a great example of two pcs and two phones going through a small network link using the CBWFQ+PQ Without the PQ SQL*Slammer kills everything, with it, the voice is clear as a bell.

priority doesn't do what you think it does

by alan on Saturday 23 of October, 2004 [16:27:45] The priority command is useful when you have a fixed amount of bandwidth being selected but breaks down badly when you go past it. Another issue is that LLQ causes that part of your overall bandwidth to be unuseable except for what you are promoting. From the 12.2 IOS docs: Guaranteed allowed bandwidth, in kbps, for the priority traffic. The amount of guaranteed bandwidth varies according to the interface and platform in use. Beyond the guaranteed bandwidth, the priority traffic will be dropped in the event of congestion to ensure that the nonpriority traffic is not starved I have a variable amount of QOS traffic depending on how many folks are calling people over the WAN so I use the bandwidth command instead. Voice traffic above the bandwidth limit will roll over into the CBWFQ. If you aren't moving any voice traffic, the regular traffic can use the full span. policy-map wan-edge-out class voice-sip bandwidth 300 class class-default fair-queue Alan

Additional info
by Anonymous on Sunday 05 of September, 2004 [22:20:17] Looks good. I've also been playing with various configurations for Voice use. I find that it helps to break up larger data packets so that your voice packets don't get stuck waiting form them to leave

the interface. One way of doing this in Cisco is you use a multilink for your serial connection and then: ppp multilink interleave interface Multilink1 no ip address no ip mroute-cache service-policy output QoS no cdp enable ppp multilink ppp multilink interleave multilink-group 1 interface Serial1/0 description Connection to Voice T1 bandwidth 1536 ip address 10.10.12.1 255.255.255.252 encapsulation ppp load-interval 30 no fair-queue no cdp enable ppp multilink multilink-group 1 === Additionally I've found that managed switches can really help with Voice in larger companies. I've got one company where the data travels out a cheap DSL connection and the voice goes across a nailed up T1 connection straight to my switches. In that setup I use Cisco3500 or Cisco2900xlt switches and disable vlan1 (which of course you can't really do - so it's still used for the data), and then activate a second Vlan, Vlan10 which is then used for Voice. interface FastEthernet0/1 description Connection to Internet Router duplex full speed 10 spanning-tree portfast interface FastEthernet0/2 description connection to VoIP router duplex full speed 100 switchport access vlan 10 spanning-tree portfast interface FastEthernet0/3 switchport trunk encapsulation dot1q switchport mode trunk switchport voice vlan 10 interface FastEthernet0/4 switchport trunk encapsulation dot1q switchport mode trunk

switchport voice vlan 10 Ports 3 on up are all used for phone/computer connections. In many cases the computers are using the phones as a switch (Cisco 7940 and 7960 phones with additional PC network connections in the back of the phones). So far this setup is bulletproof. Even when the data side was dragged to a slow crawl by a virus outbreak, the voice quality stayed clear and untroubled. Jon Carnes FeatureTel - Hosted Telephony company based in RTP, NC