Wednesday, October 27, 2010

Doing ASA Quality of Service (QOS) on DSL or Cable Internet

Needed a way to help improve the QOS on our Cisco IP Phones (we use mainly 7940 / 7941 and 7960 / 7961 phones). On our WAN there is no problem as it is all controlled via our own routers and our VOIP provider's routers which we have direct T1's with.  Our Cisco Call Manager is hosted by a VOIP solution provider, the equipment is not at our site (not that it really matters). 

So the problems were at our small remote project sites which usually only have DSL or Cable Internet connections to the internet (not direct to our VOIP provider).  We know and fully understand that we really can't control QOS over the internet but the IP Phones have worked out pretty well in the past with out it.  However, recently these sites have been doing a lot more paperless work which is taking up a lot more outbound bandwidth because of scanning documents and uploading to a project web-site with a document repository.  Whenever someone was scanning documents (which uploaded to an off-site server) the phone quality went down the tubes.  This is mostly noticed by the person on the other (remote) end, not the employee at the project site.  

We've been replacing PIX 501's with Cisco ASA 5505's as you can't do QOS on a PIX.  However, simply adding the basic QOS commands to the ASA doesn't do the trick.  The problem is that the ASA has a 100MB connection to the DSL router and as far as the ASA is concerned there is no congestion and pushes out the data as fast as it can and never really priorities anything.  Now when the DSL router starts pushing the data up its tiny 1MB pipe, that's where the choppy audio starts.  So what we needed to do was to tell the ASA what the actual available bandwidth was so it could properly "throttle" and packets and properly prioritize the VOIP packets. 

We still have no control over what the vendor provided DSL router (or cable modem, etc.) does with the packets after they leave the ASA, but it does help. With the ASA knowing the speed limit, it can tell the lower priority traffic "whoa... slowdown fellas!", leaving upload bandwidth available for VOIP traffic. 

The main disadvantage is that some available outbound bandwidth may be wasted as we are basically setting it aside for VOIP.  If we have 1MB available from our ISP but we restrict non-VOIP traffic to 600MB, that is the best upload speed available, even if there is no VOIP call in progress.  

Okay, here are the magic commands.  The only thing you will really need to tweak is the SHAPE AVERAGE value.  The value I have below is for 600K.  This should not be set to your available DSL upload speed, it should be set to how much bandwidth you want to give to lower priority traffic.  It may take a good hour of your time testing different values until you get the results you want.  Make a VOIP call, then start an upload, listen for jitter or watch the stats on the up-stream phone for dropped packets, jitter, and call quality if possible.

This example is doing traffic Shaping vs. Policing.  Shaping seemed to work better.  Policing is similar but allowed low priority traffic to burst for 10 seconds which caused jitter during that time.  

priority-queue outside        Creates the priority queue
class-map VOIP-TRAFFIC     defines a class map to match VOIP (EF) traffic
 match dscp ef

policy-map PRIORITY-POLICY     The policy for priority traffic (in this case VOIP based on the class map)

policy-map QOS-TRAFFIC-OUT        The actual policy map that gets applied to the interfaces and uses the stuff we just defined
 class class-default                                Default traffic policy
  shape average 600000                    Default traffic conforms to this value
  service-policy PRIORITY-POLICY    Exception to the default policy (in this case VOIP traffic which will have no limit)

service-policy QOS-TRAFFIC-OUT interface outside    actually applies it to the interface (remove this to test with and without QOS).

You can get a lot more complex with this, giving FTP traffic more or even less bandwidth for example, but this does the trick to prioritize VIOP traffic and restrict everything else.  This example does not discuss prioritizing via a VPN, this could be done also but is not what we wanted to do.

For more detailed info check out:

Yes, you can throttle inbound also but it doesn't help very much and probably isn't worth it.  You actually can't do Shaping on outbound and inbound at the same time, but you could do policing (i.e. Police Outbound 6000000 within a CLASS).  I played with it, cutting the bandwidth in half even, but it didn't do much.  It may have helped just slightly but the loss of available download bandwidth wasn't worth it.  The problem really lies in the fact the packets coming down have already traversed the slow link, so once it hits the ASA it is really too late and VOIP prioritization doesn't do much.  I think the slight improvement was only because it caused the download I was doing (for testing) to come down slower, but it didn't give the results I wanted.  So for me, I'm just doing outbound (upload) QOS and that is where the main problem was anyhow.  


  1. Thanks!! Just what I was looking for, great info!

  2. I am at 8.0(3), not all the commands are available. What release do you need to be at for the above?

  3. I just checked one of the ASA's I am doing this on and it is only at 7.2(4). Cisco may have changed some of the commands or syntax. Which commands are not working?

  4. May be it's a bit too late, but why do you shape at 600 Kbt only?
    Should not you shape at your CIR (1Mb)?
    And from there PRIORITY-POLICY will act in a way to prioritize VOIP-TRAFFIC ?

    In other words, everything will be shaped at 1Mb speed apart from voice which will be prioritized (still remains in 1Mb boundaries in case it becomes more 1Mb in volume).

  5. Flooter - in this example, the "shape average 600000" is what I'm leaving available for non prioritized traffic. So if I have 1Mb of available bandwidth then I'm leaving 400Kbt for my voice and 600Kbt for other, non priority traffic. If you did a speed test the upload speed wouldn't be beyond 600Kbt. If it was set to 1000000 then that wouldn't leave any reservation for voice. Now if you have a 10Mb connection, you'd want to bump that up to say 9Mb or even 9.5mb (ie. shape average 9500000). If you use the 600Kbt example then no matter how much bandwidth you have, only 600Kbt will be given to normal traffic for uploads.

    1. Brian - I think Flooter is more correct. Can you state the basis on why you wouldn't shape for just below the CIR? The priority queue should still carve bandwidth out of the CIR rate. I'm just curious why you are limiting your bandwidth to say 600 and losing 400Kbps at any other time.

    2. Brian, you FIRST shape ALL traffic by using the only "class class-default" statement with a single "shape" command in it and THEN "service-policy PRIORITY-POLICY" looks to what traffic to prioritize (this traffic has already been shaped by now).
      If you want to strictly reserve X amount of bandwidth for VoIP you should do that like this:
      policy-map QOS-TRAFFIC-OUT
      class VOIP-TRAFFIC
      class class-default
      shape average 600000
      Policy is matched from top to bottom (like an ACL)
      If matches VOIP-TRAFFIC and... do nothing, leaving it to go freely.
      If traffic is NOT Voice - then it will be classified as "class-default" and will be shaped at 600K.

      However it is not an optimal solution.

      Please have a look at the book "IP Telephony Self-Study: Cisco QOS Exam Certification Guide, Second Edition" by "Wendell Odom, Michael J. Cavanaugh", ISBN: 1-58720-124-0 ,
      Chapter 6, "Tuning Shaping for Voice Using LLQ and a Small Tc"

      there you can find exactly your case.

    3. Flooter - true enough on a router. Just wondering if this works the same on an ASA.

  6. Quick question: I want to use this strategy to QOS traffic going between 2 hosts. Each host is at a different site and the sites are connected via VPN. The VPN headend is a 5505 ASA and the remote is a 2921 ISR. I want to QOS some video (VIDYO) traffic over this link. VIDYO does not mark their traffic, so I need an alternate way to capture the traffic. I chose an ACL but the ASA is throwing an error when I try that. So what I want to do is QOS traffic that I define with an ACL going across a VPN tunnel. Any ideas???

    ip access-list extended vidyo_traffic
    permit ip host host

    class-map US_voice

    description “match voice on US-LIMA Tunnel Group based on flows”

    match tunnel-group

    match dscp ef


    class-map US_vidyo

    description “match video on US-LIMA Tunnel Group based on flows”

    match tunnel-group

    match access-group vidyo_traffic


    priority-queue outside

    queue-limit 512

    tx-ring-limit 64


    policy-map VPNQOS_US-LIMA

    class US_voice


    class US_vidyo



    service-policy VPNQOS_US-LIMA interface outside

    However when I tried to apply this to the PERU ASA I get the following error…

    ASA_FW# conf t
    ASA_FW(config)# class-map US_voice
    ASA_FW(config-cmap)#  description .match voice on US-LIMA Tunnel Group based o$
    ASA_FW(config-cmap)#  match tunnel-group
    ASA_FW(config-cmap)#  match dscp ef
    ASA_FW(config-cmap)# !
    ASA_FW(config-cmap)# class-map US_vidyo
    ASA_FW(config-cmap)#  description .match video on US-LIMA Tunnel Group based o$
    ASA_FW(config-cmap)#  match tunnel-group
    ASA_FW(config-cmap)# match access-list vidyo_traffic
    ERROR: 'match access-list' can't be configured with tunnel-group.

    1. Hi, did you ever get a answer to this question? I am running into the same issue. I know this thread is 2 years

  7. Hi there,
    thanks for your post. Based on what you've seen with the cisco ASA's, I am wondering if you can provide an example for the following:

    I have a dsl modem connected to my asa 5505. On one vlan I have an Office_network. On a second Vlan I have a public_Wifi_network. The DSL connection is 3Meg down, and 1 meg up. I would like to ensure that the office_network gets 75% of the inbound and outbound internet connection.

    Is this possible?


  8. Hi (Hope this very late response is allowed),

    The past weeks I've been dealing whith the same set-up as discribed here.
    Just wanted to let you know if you apply the shaping like you did over here, the priority doens't seem to work.
    Checked the priority-queue statistics and everything goes into the BE-queue and not in the LLQ like it should.
    It also seems better to apply shaping on the whole bandwidth like Flooter said.
    The best option I found so far is:

    policy-map shape-priority-policy
    class TG-voice
    class class-default
    police output 1000000

    Wich moves the voice-traffic to the LLQ, the rest-traffic to the BE-queue and police everything except the voice-traffic.

    Plz let me your thoughts..

    1. Hi, let say the DSL upload speed is 1.5Meg, from above your example, all non-voice traffic will be policed to 1Meg and voice traffic will get the remaining .5Meg "IF" the link is congested? Am I understand you correctly?

    2. In the traffic shaping example, the reason everything goes into the Best Effort queue and not the Low Latency Queue is because priority queuing is not compatible with traffic shaping. It has no effect. This is according to Cisco documentation.

  9. Bandwidth Management(Rate Limit) Using QoS Policies:

    QoS mechanisms that are supported on the ASA:

    also this example describes QoS for VoIP Traffic on VPN Tunnels:

  10. Contrary to what the author writes, you can throttle inbound traffic quite effectively by policing traffic leaving the inside interface for the host machine, that is, output policing. With an ACL, I targeted UDP traffic in particular and limited the rate to about two-thirds of my available downstream bandwidth, and the UDP traffic was precisely pegged at the target rate, leaving plenty of upstream bandwidth for my VOIP calls.

    Neither Standard Priority Queuing nor Hierarchical Priority Queuing with traffic shaping worked reliably for me. Whereas policing worked perfectly for me every time to guarantee adequate bandwidth for VOIP traffic.

    1. Sure you can throttle inbound traffic (I said that); my point was that by the time it gets to your ASA it is pretty much pointless. If you have 10MB download speed from your ISP then that's your choke point (of which you have no control), why choke it more on your ATA's inside interface?? From there you can blast it through at 100 or 1000MB. Depending on your ISP, you most likely have no priority control over your UDP traffic until it reaches your ATA, and once it does then bandwidth probably isn't an issue any longer.

      Think of a funnel. Going out, you are poring into the big opening and it gets squished down to fit through the smaller opening. You CAN control that and you can limit the amount of regular traffic to leave more room for VoIP. But, on the way back in, you have no control on how stuff gets to the smaller opening, only once it gets through; and thus your ATA is the big opening. So why funnel it down again? Blast it through...

  11. Hi Brian,

    I am using 5505 9.3.1 version and trying to setup QOS on it. Could you please advise if it is ok? I am trying to allocate 8mb for VoIP traffic.

    class-map voip-inside-class
    description VoIP traffic
    match dscp ef
    policy-map voip-inside-policy
    description voip on inside interface
    class voip-inside-class
    police output 67108500
    please let me know if I have made any mistake?


Please let me know if this helped you out, or if you would like to submit other suggestions or correct something I may have mis-stated.

About Me

My photo
Science Fiction Author / Vice President of Technology for The Christman Company