I am trying to setup QoS and would like some input on what I have done so far.
I have a 2821 with 11 t1 lines connected to it, most of the sites are single t1 and a couple sites have two in a multi-link. I just want to make sure that none of our main services are completely starved and voice doesn't ever get stepped on along with that I want to keep system updates(wsus-updates) from killing everyone on the other side. So for every important serivce I have bandwidth 35 and every non important service I have bandwidth 8.
Is this working the way I am thinking where anything that is important is getting 4.35:1 more bandwidth than anything that is not? While voice is guaranteed 40% of the bandwidth. One other thing is I want to kill P2P so I shaped it to 8k.
Any insight would be appriciated.
Here is what I have done so far.
class-map match-all icmp
match access-group name icmp-traffic
class-map match-all http
match protocol http
class-map match-any exchange
match protocol exchange
class-map match-any networking
match protocol ssh
match protocol snmp
match protocol telnet
class-map match-all VoIP-Control
match ip dscp af31
class-map match-any low-priority
match protocol kazaa2
match protocol gnutella
match protocol edonkey
match protocol fasttrack
match protocol streamwork
match protocol winmx
class-map match-all wsus-updates
match access-group name wsus-list
class-map match-any microsoft-ds
match protocol netbios
match protocol microsoftds
match protocol ldap
class-map match-all VoIP-Voice
match ip dscp ef
class-map match-all https
match protocol secure-http
priority percent 40
shape average 8000 1000 0
Thanks in advance!
your approach seems very reasonable, however I would suggest to simplify things a little. For example, voice control despite what the books say, it's actually robust and does not necessarily need a class of its own and can put togher with other important, but not absolute priority things.
I think that if you reduce the number of classes a little it will be also easier for you to check if it's working or not.
Well I simplified it a tiny bit, I got rid of icmp and placed it with other networking protocols and instead of matching it in an access list I match it with nbar. I reduced voip control to 8k since it is just for call setup like you said but I can't find another category that I want to mix it with so I left it seperate. I set the desired things to 32 so it is exactly 4x more than less desired things.
I did talk to a user on the other side of a t1 today and they said the network worked well so I am feeling good about things so far.
I am going to need to visit a site and get a feel for it being on and not...
Thanks for the input.
Unsure I see much benefit to shaping p2p to 8 K, unless you want to allow it. If you don't want it at all, just drop it. If you do want to allow it, just deprioritize it (if the bandwidth is otherwise available, why not allow it to have it).
I would suggest trying:
class-map match-any VoIP
match ip dscp ef
match ip dscp af31
priority percent 40
bandwidth percent 1
Then tune/expand as and if necessary.
My suggested policy drops all the NBAR selected p2p, but you could change that to a bandwidth of 1% instead. If you do, you might allow wsus-updates a bigger bandwidth guarantee, maybe somewhere between 5 and 10 percent.
The low bandwidth and single FIFO queue for wsus-updates pretty much allows this class to use all available bandwidth but with little impact to other traffic since the bandwidth guarantee is minimum. I.e. other traffic will generally push it aside although not totally starve it.
Class-default FQ usually does a very good job of dealing well with most traffic unless there's real need to treat some specific traffic special. Except for real-time, like your VoIP, or known low priority backgound flows, like your virus updates, you'll likely not need to "micro manage" the other traffic types you've listed.
I've placed voice signalling into LLQ. This is contrary to the "book" solution, but this traffic tends to be bandwidth light, yet critical for good VoIP functioning. Since I'm using FQ within class-default, and I believe this upsets bandwidth reservations for other non-LLQ classes on most Cisco platforms, LLQ assures it the necessary service.
I also advise against using random-detect unless you fully understand RED. FQ tail drops, I believe, usually works better.
BTW, if you're going to use a class dedicated for Microsoft traffic, don't forget the newer TCP port 445 traffic, which I recall NBAR doesn't match as a protocol.
Also, something I've been burned with, NBAR SSH also includes SCP which can quickly consume bandwidth you've intended for SSH to network devices.
We have a unique situation where the desktop folder is actually on the network. It was supposed to be a better solution than Roaming.... NOT my idea.
Anyhow once I started looking at nbar, the protocols we use are microsoftds, exchange, http and https. So I want to guarantee those are never completely out of bandwidth.
I thought random-detect was superior than tail-drop since that would keep from getting sawtooth bandwidth patterns.
I thought of sticking voice control into voice, I have done that this morning instead of what I did eariler.
As far as P2P goes we can't block anything completely but I will remove random from it and the other non-important traffic.
Thank you for reminding me of virus updates. I will add it to wsus. :)
I don't have anything for Class-default and I am not sure if I should and if I did wouldn't I want RED even if I had FQ. Going to have to learn more here!
I did a custom nbar to match 445.
ip nbar custom microsoftds tcp 445
Good to know about SSH, we don't have anything doing SCP over our t1 links.
It all seemed so simple at first :)
Thank you for you suggestions. Based on your suggestions I am still wondering if the tail-drop you suggest would sawtooth?
"Anyhow once I started looking at nbar, the protocols we use are microsoftds, exchange, http and https. So I want to guarantee those are never completely out of bandwidth. "
That's also accomplished by FQ within class-default.
"I thought random-detect was superior than tail-drop since that would keep from getting sawtooth bandwidth patterns. "
That's the basic theory, but there's much, much more to successful usage. I've also found on slow links and with few TCP flows, it doesn't work very well. (Actually, if I'm working with marked packets, I'll turn in on more for its stats of counting packets by markings rather than for its intended purpose.)
"I did a custom nbar to match 445.
ip nbar custom microsoftds tcp 445 "
That how I would probably do it.
"It all seemed so simple at first :)"
Yes it does, and in fact it is often simple, but is takes lots of knowledge to make it so, otherwise you tend to bump into "gotcha's".
One reason I push FQ within class-default is because each flow often has its own queue. On most platforms, class queues only have one queue for the class, which is fine until one flow within that class fills the class queue and all the other same class traffic suffers. On the few Cisco platforms that support FQ within any class, you can nicely implement a more complex QoS model.
Well darn, So with my complex setup a single flow in exchange can fill up the queue and keep others from getting bandwidth?
I will create another qos a lot like you show, visit a site and try each of them. This should give me a better feeling for how they perform and if I should stop trying to cater to too many protocols.
"Well darn, So with my complex setup a single flow in exchange can fill up the queue and keep others from getting bandwidth? "
Yes, but only for that class. Other classes would have their own queues. If there was one heavy Exchange flow, other Exchange flows could be impacted, but, for instance, your HTTP class wouldn't be impacted in the same way.
There's nothing wrong with catering to many protocols if there's a real need to.
BTW: I believe FQ within class-default might actually be WFQ. If it is, you can increase the amount of bandwidth a flow can obtain by using different IP Precedence values for different types of traffic.
If you're working with VoIP, you might also want to manually tune tx-ring, although the later IOSs are supposed to set it better.
Cisco recommends 33% to be prioterized for VOIP.
Another Insight, Inorder to apply shaping along with queing mechanism, you will need hierarcal policy (nested policy) to be applied.
"Cisco recommends 33% to be prioterized for VOIP. "
I recall the recommendation is to not exceed 33%, but further recall they note in some situations you may need to exceed it.
"Another Insight, Inorder to apply shaping along with queing mechanism, you will need hierarcal policy (nested policy) to be applied. "
No, believe you can shape within classes although a heirarchal policy does use a parent policy map with class shaper.