Warning: count(): Parameter must be an array or an object that implements Countable in /homepages/29/d134578137/htdocs/wp-includes/post-template.php on line 284

Warning: count(): Parameter must be an array or an object that implements Countable in /homepages/29/d134578137/htdocs/wp-includes/post-template.php on line 284

Warning: count(): Parameter must be an array or an object that implements Countable in /homepages/29/d134578137/htdocs/wp-includes/post-template.php on line 284

Warning: count(): Parameter must be an array or an object that implements Countable in /homepages/29/d134578137/htdocs/wp-includes/post-template.php on line 284

With all this knowledge filling my head for the CCIE, I wanted to try to do something useful with the QoS! I’m not entirely sure I’ve accomplished what I set out to do, but I hope so. Maybe some of you QoS experts out there can lend a hand or a comment.

Here is the situation:  I pay Comcast for 8Mb/384Kb internet service. I also have Vonage for phone service. Comcast comes into my Cisco 3725 router’s Fa0/1 interface. It’s other interface, Fa0/0 is trunked down to a cisco switch. The Fa0/0 interface is divided into 3 subinterfaces to provide VLANs. Fa0/0.1 is VLAN 1 for my wired network, Fa0/0.2 is VLAN 2 for my wireless segment, and Fa0/0.4 is for Vonage.

A problem I often run into is that if I am downloading a large file using bit-torrent or some such thing, it can really smoke all my bandwidth. It is not uncommon for me to be pulling down at 800KB/s (yes kilo-Bytes! , which comes out to about 6.5 Mb/s). This puts a damper on simple things like checking email, and especiall web browsing, DNS query’s, etc. Also, if I do a speed test from speakeasy.net I can pull up to 16Mb/s during non-peak hours. My goal was to prioritize traffic such that if bit-torrent or some such thing was sucking all my bandwidth, priority protocols (such as http, pop3, https, smtp, dns, etc) would get guaranteed traffic. Additionally, if the phone rings or I place a call I want Vonage to have guaranteed traffic.

This presented more problems than I thought!!! Well what can I do? I first thought about CBWFQ. Going out fa0/1 to the internet it was easy. I set bandwidth 384 on the interface, and created the following: Basically, I have to shape the interface going to the internet to 384Kb/s outbound or else there will NEVER BE CONGESTION and thus NO queueing because it is just 384Kb going out a 100Mb interface! What this does is shape all the outbound traffic to 384Kb/s and gives my priority protocols 50% (192Kb), Vonage voice 128Kb and the SIP the other 10%.

Policy Map parent
Class class-default
Traffic Shaping
Average Rate Traffic Shaping
CIR 384000 (bps) Max. Buffers Limit 1000 (Packets)
service-policy priority-traffic

Policy Map priority-traffic
Class priority-traffic
Bandwidth 50 (%) Max Threshold 64 (packets)
Class call-signalling
Bandwidth 10 (%) Max Threshold 64 (packets)
Class voice
Strict Priority
Bandwidth 128 (kbps) Burst 3200 (Bytes)

Class Map match-any priority-traffic (id 4)
Match protocol http
Match protocol secure-http
Match protocol telnet
Match protocol smtp
Match protocol pop3
Match protocol imap
Match protocol secure-pop3
Match protocol secure-imap
Match protocol secure-ftp
Match protocol ftp
Match access-group name rdp
Match protocol ssh
Match protocol icmp
Match protocol dns

interface FastEthernet0/1
description WAN
bandwidth 384

no ip dhcp client request dns-nameserver
ip dhcp client route track 1
ip address dhcp
ip access-group firwall-wan in
ip nbar protocol-discovery
ip nat outside
ip virtual-reassembly
no ip mroute-cache
load-interval 30
duplex auto
speed auto
no cdp enable
max-reserved-bandwidth 100
service-policy output parent

This actually worked really well so far as I can tell! That wasn’t so bad. But then I started thinking about the traffic coming back IN. So right now by queueing outbound it is good if I am uploading a bunch of traffic and need to go to a webpage…the GET request from me will get priority during congestion. But what about downloading? What if I am downloading a huge file and it is sucking all 8Mb of my bandwidth and I go to surf the net? Those http,dns, voice packets coming back into my network are going to get crapped on. So, I started thinking about outbound queueing on the LAN facing interfaces. This is where I ran into the bulk of my problems.

IF there is nothing priority going on, I want my PC to be able to pull down as much as possible from comcast, which as I said I have seen in speed tests peak to 16Mb/s. However, if say about 75% of the bandwidth I pay for is being sucked up, I want to prioritize my “priority” traffic and voice traffic so they are always fast. One problem again is that my Fa0/0.1 and fa0/0.2 , fa0/0.4 subinterfaces cannot have queueing without shaping first. After shaping you can nest in your CBWFQ configurations. What happens is that by shaping, you are actually creating congestion, which then allows queueing to happen. OK, so how do I shape those subinterfaces? If I use MQC to “shape average” to 8Mb it will not allow throughput of over 8Mb/s on average over time. Then, I could create congestion and queue, but lose out on that peak to 16Mb thing. If I “shape peak” with CIR of 8Mb and PIR of 16Mb it seems the shaper only goes active at 16Mb, which basically will never happen. Which I think means I will no longer have active queueing as there will be no congestion. So I was kind of stuck.

Here is what I came up with. I am pretty much learning QoS for the CCIE lab exam so am very new to it. I’d love to hear any feedback from you guys on 1) If I am doing this correctly and 2) Better ways or ideas!!!!

So here is my fa0/0.1 interface… Oh yeah, you will notice the class “outside” which nests the other stuff instead of class class-default. This is so that only traffic from the internet coming into my LAN gets shaped. Otherwise, I would have Inter-VLAN routing traffic from WLAN –> LAN shaped!

So the idea here is this, and again I’m not sure this is a correct implementation of what I have explained.   Anything with a source address of ANYTHING not 10.x.x.x gets shaped to 8Mb/s. Thus, if there is more than 8Mb/s traffic coming into the lan (out the fa0/0.1 interface) it is shaped and thus creates congestion, which in turn allows queueing. IF there is congestion my priority traffic should get a guaranteed 4.5Mb/s of traffic. That should be more than enough to keep my stuff snappy.  Now, a problem. What happens to traffic that is NOT priority during congestion? It still gets passed as best effort through the default-class right? So say I am sucking down a huge download and it is taking all my bandwidth…the queueing kicks in and 4.5Mb gets allocated to my priority stuff and life is good. Now, the phone rings …..well the rest of the bandwidth is being chewed up by the large download so I’m screwed. Remember, Vonage is on a seperate sub-interface which is not bound by this queueing system. This is why I have a class called “other” which is basically the opposite of anything defined as priority traffic. It actually gets put into a priority queue with 1.5Mb because by creating a priority queue I also police! So hopefully if I am sucking down a huge download, 4.5Mb will be allocated to priority, 1.5Mb will be given to the rest of the junk (large download) and NO MORE than 1.5Mb ….this adds to 6Mb and should still leave me with more than enough for quality phone conversations. Note fa0/0.4 is a /30 and only has 1 device on it, the vonage phone, so the ONLY traffic going out that queue is voice traffic so I should not have to queue it.

interface FastEthernet0/0.1
bandwidth 8000

encapsulation dot1Q 1 native
ip address x.x.x.x secondary
ip address
ip access-group firewall-lan in
ip pim sparse-mode
ip nat inside
ip virtual-reassembly
no ip mroute-cache
ipv6 address xxxx:F4B8:2600:C::1/64
ipv6 address xxxx:F4B8:2600:C::/64 eui-64
ipv6 enable
ipv6 nd prefix xxxx:F4B8:2600:C::/64
service-policy output lan

Policy Map lan
Class outside

Traffic Shaping
Average Rate Traffic Shaping
CIR 8000000 (bps) Max. Buffers Limit 1000 (Packets)
service-policy priority-lan
Class class-default

Class Map match-all outside (id 5)
Match access-group 55

Standard IP access list 55
10 deny, wildcard bits (29740 matches)
20 permit any (8771772 matches)

Policy Map priority-lan
Class priority-traffic
Bandwidth 4500 (kbps) Max Threshold 64 (packets)
Class other
Strict Priority
Bandwidth 1500 (kbps) Burst 37500 (Bytes)
Class class-default

Class Map match-all other (id 6)
Match not class-map priority-traffic

I guess that is it! I am still pretty uncertain about this and would love some feedback. On a sidenote, I am still screwed on that 16Mb burst thing so far as I can tell since I am shaping!

– Joe A


7 Responses to “Exploration into QoS land”

  1. Wayne on January 22nd, 2009 6:19 pm

    My understanding on this is that you cannot really shape your download traffic, this can only be done by comcast on the egress interface facing you.

    I’m not aware of any way to tell a server how fast to send you the data, let alone dynamically adjust if you get a voip call. i think the data will still fill your pipe but sit in a queue on your router.

    If I’m wrong please apply the clue stick so I can learn something.


  2. Scott V on January 23rd, 2009 1:16 am

    Hey Joe,

    I admit that it’s been a VERY long day and also a pretty long week, so I could’ve given this a more careful read that I just did. But I’m fundamentally not getting something here, so I’ll just throw out a question with a promise to read more carefully if you have a good answer for me:

    Why are you creating a secondary, after-the-fact layer of congestion in your own network? Of course I understand the concept of artificially inducing congestion for the purpose of implementing strict priority queuing and so forth (was in fact just explaining that concept to a client today). But this is done in a “pre-congestion” scenario, such as having a gigabit Ethernet interface tied to an EVDO cellular data card. You know you’re going to experience congestion in the cellular cloud, so you go ahead and move it back a step so that you can schedule out the real-time traffic first. If I’ve read you correctly here, you’re artificially inducing congestion a second time, after it’s already occurred in the first place back on your carrier’s outbound interface (and likely that congestion is artificially induced also by way of some form of traffic shaping!). To what end? I fail to see what this accomplishes? You can’t influence the scheduling of your inbound voice ahead of bulk file transfer (for example) where it really matters, which is on your carrier’s side of the bottleneck, no? So I would think that you would just push out whatever arrives from the carrier/Internet as quickly as you possibly can (and 8 or 16 Mbps of traffic over a 100 Mbps interface would best be served by simply being serialized out as it presents itself). You can’t somehow make voice go faster than it’s arriving at your router, so move it out of that router just as fast as you possibly can!

    LOL, maybe you could send them a service-policy of your own creation for their interface looking back at you!



  3. Scott V on January 23rd, 2009 2:00 am

    And just an additional clarifying thought here that surfaced the moment I hit “Submit Comment”…

    I do not mean to imply that you can’t have any impact whatsoever on your inbound traffic with the approach as I understand you to have described it; if you were to shape your bulk traffic outbound from your router towards your home network, you certainly could leave yourself with sufficient BW for reasonably good voice quality, etc (assuming your bulk transfer was via TCP, that is). But I don’t think that’s the sum total of what you meant to do is it? Again if I understand you correctly, you don’t desire that your bulk traffic always be shaped to some value less than 8 Mbps, which would waste available BW when you had nothing other than bulk going on.

    Now if you really wanted to get sick and twisted, you could look into something I stumbled upon after reading one of Ivan’s blog posts (http://blog.ioshints.info/2008/12/this-is-qos-who-cares-about-real-time.html):


    I would think “Application Aware Triggered Quality of Service” could be expanded to include the other classes of traffic you deem to be priority. The whole thing was a bit much for me, with all of the scripts and whatnot, but certainly the concept overall was intriguing enough!

  4. Joe A on January 23rd, 2009 3:13 pm

    Hey, thanks for the comments. Scott, I guess the idea I had was basically, if my bulk downloads are using all my download bandwidth, I thought that by shaping the outbound interface it would force it to cut off at a certain point so that there would be bandwidth left over for voice and priority stuff to use.

    In other words lets say I am downloading a large file and it is eating my full 8Mb/s bandwidth. When priority traffic comes in, I want it to basically say “whoah you can now only use 6Mb/s” At that point I figure I am only utilizing 6Mb/s from the provider thus leaving me with 2Mb/s left over. I think what you might be saying is that even if I shape the traffic, I am still utilizing the full 8Mb/s from the provider but it is just being queued on my router?

  5. Scott V on January 23rd, 2009 10:02 pm

    Hi Again Joe,

    OK, had another read of your objectives and looked quickly over your configs. With regard to the latter, there may be a few things there in need of some attention, BTW. But I’m racing a deadline all through the weekend so we’ll leave that for another time.

    As for your issue of losing out on the 16 Mbps burst bonus feature, I’m not sure what you can do. As you’ve noted, you need to generate “back pressure” when traffic reaches the minimum level that could potentially be your peak allowable throughput at any given time (so your contracted CIR of 8 Mbps).

    As for whether or not this can be made to work at all, I think it totally depends on your specific traffic flows. Recall that TCP endpoints will adapt to the narrowest bottleneck along the complete end-to-end path via the windowing process. So if you deploy a hierarchical policy that offers strict priority to a given traffic class and then leave what’s left to your default class, then any TCP flows within that default class should adapt to the lost segments that inevitably will result (yes, you will drop some of those TCP segments that have successfully made it all the way to your own router!) and then throttle back accordingly. UDP, on the other hand, will come down your last-mile circuit between yourself and your carrier just as fast as your carrier pushes that traffic in your direction, so indeed you will queue and could subsequently drop significant traffic after it has already successfully arrived at your home network. And being UDP, we know what the result of that will be!

    So in summary, you should be able to throttle TCP in the default class. Depending on your traffic flows, that may or may not be beneficial to you. Doubt you’ll have any luck with UDP no matter what you try. And nothing leaps to mind as far as helping out with your 16 Mbps burst capability – it likely just goes away.

    As for your configs, again I think that needs some attention but I don’t really have sufficient time just now. In short, though, if it’s your goal to police your “other” class, using the implicit policer of a strict priority queue is probably not the best choice (I think that was your angle but can’t be certain – feel free to correct me on that interpretation). Recall that strict priority queuing has implications for scheduling traffic out of an interface. Do you really want to be giving the very most preferential treatment to your least valuable class of traffic just so that you can police it? Maybe think about some other options there.

    I’m also a tad fuzzy on the whole subinterface thing. At first glance, it appears as though you’re shaping to 8 Mbps down at fa0/0.1, where only your wired users exist? So wouldn’t it be the case that your queuing would remain un-invoked until your wired users’ subinterface saw enough traffic to initiate shaping (@ 8 Mbps per your config, if I read it correctly)? At that point, what’s left for your wireless and your phone subinterfaces? Prior to that point, though, you don’t have any congestion and thus no queuing and scheduling – just FIFO. So maybe reevaluate some of the specifics of your initial implementation and then do some experimentation and post some nice output for us!



  6. Jared V on February 19th, 2009 1:28 am

    If you guys figure out how to do this solely in the router, I’d love to hear about it. AATQoS has been working great for me over the last year. I’ve since modified my setup to key off of ACL matches instead of having to run Snort – but you still need a Linux box to parse the logs.

    Ivan wasn’t able to get a real-time configuration working with EEM (there was at least a 10 second lag between the start of a phone call and the application of the rate-limit), although if Cisco could fix that we could do it directly in the router.

    I’d also be interested in hearing if you find a QoS policy that has the same effect! Ideally it is full access most of the time, with rate-limiting for bulk traffic only when interactive, low-latency traffic is present on the WAN.


  7. Scott V on February 23rd, 2009 12:31 am

    Hi Jared,

    I _might_ have some down time in the coming week. Be interested in hashing some things with you if so. I can be reached at scott underscore ccie underscore list at it hyphen ag dot com.



Leave a Reply