While studying for ONT....

Forsaken_GA

I'm getting prepared to take ONT next week. As I review and go through the steps, I'm trying to gather together a set of commands so I can apply QoS through MCQ.

I'm using the Cisco Press Official Exam Certification Guide as my primary study material.

While I'm going through the CBWRED section, something occurs to me -

I get that when applied to a class through a policy map, it will look at IPP or DSCP values and do random drop based on that. Nowhere in this entire text have I found a set of commands that will actually let me mark traffic. Plenty of ways to classify it, plenty of ways to act on the markings that are there, but no way to set my own IPP or DSCP values.

Now to the actual question - with my GoogleFu, I have run across commands that would seem to alleviate my conundrum.

I use rsync to backup my home network, which consists of several vlans. It tends to hog the bandwidth, especially since all traffic goes through a 2611xm, and they don't handle actually routing between VLAN's at fast ethernet speed without pegging the CPU usage. This interferes with my web browsing, my ssh sessions, etc etc. I also pull data from off my own network, and while this is limited to cable modem speeds and not pegging my CPU, it is consuming all of the local downstream bandwidth, having much the same result.

Am I correct in thinking I can do the following -

-Create a class map (match-rsync) that uses nbar to match rsync
-Create a policy map (die-rsync-die) that uses the class map previously created, and use the set ip dscp 1 command to mark all traffic at dscp 1
-On all of my vlan interfaces, apply service-policy input die-rsync-die

Am I correct in thinking that this would have the result of marking all rsync traffic with dscp 1, which I could then do proper CBWFQ and CBWRED on in an outbound policy, and save my poor routers CPU from freaking out?

If not, what am I overlooking?

(For the Unix savvy - Yes, I'm well aware that rsync has an option to bandwidth limit itself. Since this is designed to be a practical QoS exercise that I can apply in my own live enviroment for the purpose of my own education, I'm pretending that it doesn't)

kalebksp

I doubt that would alleviate your problem, in fact it will probably make it worse. Your now going to be using NBAR on every packet going through that vlan interface, which is going to drive up the processor even more. If the router can handle it, then yeah it could probably work. If your router doesn't have the horse power to route those packets, QOS can't really help you.

An addition:

You would need to give all other traffic some treatment better than rsync as well. As you outlined it above all you're doing is applying WFQ and WRED to rsync. Applying WFQ to a single type of traffic is likely to not have much effect, as all the flows will be very similar. WRED might be helpful in that it would alleviate TCP synchronization, but I've always assumed that was more effective when you had many TCP connections, not just a few.

Forsaken_GA

kalebksp wrote: »

I doubt that would alleviate your problem, in fact it will probably make it worse. Your now going to be using NBAR on every packet going through that vlan interface, which is going to drive up the processor even more. If the router can handle it, then yeah it could probably work. If your router doesn't have the horse power to route those packets, QOS can't really help you.

Trust me, that part I get. I'll be upgrading the router to something a little beefer when the funds come available, it's just what I have to work with at the moment. The cpu starts to squeeze at around 60/mbps, but I don't need my backups transferring that quickly, I'm perfectly happy capping it at around 10/mbps.

You would need to give all other traffic some treatment better than rsync as well. As you outlined it above all you're doing is applying WFQ and WRED to rsync. Applying WFQ to a single type of traffic is likely to not have much effect, as all the flows will be very similar. WRED might be helpful in that it would alleviate TCP synchronization, but I've always assumed that was more effective when you had many TCP connections, not just a few.

Well, yeah, http, ssh, mysql, and any traffic destined for Blizzard's /23 are going to get bumped up to an equivalent of IP precedence 3, CIFS will be classified at 2, and so on, rsync, bittorrent,ftp (essentially any bulk data transfers) are going to get dropped down to 1. 4 and 5 I'll reserve for VOIP, because I will eventually get off my rear and put together an asterisk box. I'll probably also drop SNMP into 4 because I don't like my nagios yelling at me about not being able to contact the router.

I'm not trying to *just* limit rsync, I'm mostly just checking myself to make sure I actually understand how to mark traffic, since the commands to do so aren't in the Cisco Press guide, it was just the most pertinent example I could think of as far as traffic that needs to be reined in. Was trying to keep the example simple

Basically, if I don't implement application level bandwidth limitations, the bulk traffic has the ability to overtake my network, which as I understand it, is one of the things QoS is designed to prevent. While I'm good enough to do my own application limiting, I'm assuming that in a real world deployment, you can pretty much count on the users to do the most inconsiderate things imaginable, and I don't really care if bulk data transfer speeds have to suffer to make sure the bandwidth is there for interactive applications.

kalebksp

Ah, I understand. Yeah, the set command is how you set dscp, precedence, etc. You should keep in mind marking traffic on a single device is only useful if all those markings are going in to a single policy map class that uses WRED. Other than WRED the other QOS tools don't really care about markings, it's more of a way to only classify your traffic once in an entire network, rather than on every device. For studying purposes of course I would probably mark packets even if they we're going through a single device too, just don't think that packets have to be marked for QOS to work. It's also a good idea to remember that a specific classification doesn't mean anything until you tell the router what it means. It's completely possible to make voip marked as EF be treated horribly and put bittorrent marked as BE in a priority queue.

If you have a couple routers, you could create a policy on one that marks different classes and on the other create a policy that matches on those markings. Then use "show policy-map interface" to see the packets matching statistics. Makes for a pretty good lab.

Forsaken_GA

kalebksp wrote: »

For studying purposes of course I would probably mark packets even if they we're going through a single device too, just don't think that packets have to be marked for QOS to work.

Yeah, I know for most of the QoS stuff, traffic doesn't have to be marked, just classified. If I'm not mistaken, you do have to mark traffic to make use of WRED (if this isn't correct, that'd be good to know, because it means I have a horrible misunderstanding of WRED). It wasn't until I sat down and started to plan my local qos deployment that it occurred to me that I didn't actually know how to mark traffic.

It's also a good idea to remember that a specific classification doesn't mean anything until you tell the router what it means. It's completely possible to make voip marked as EF be treated horribly and put bittorrent marked as BE in a priority queue.

Yeah, I'm finding that MQC is pretty easy to deal with. Define your classes in the class-maps, and then tell the router how to use those classes in the policy maps.

If you have a couple routers, you could create a policy on one that marks different classes and on the other create a policy that matches on those markings. Then use "show policy-map interface" to see the packets matching statistics. Makes for a pretty good lab.

Unfortunately, the only thing I have capable of running 12.4 advanced at the moment is the 2611xm. I've got a big enough slush fund built up to purchase what will be the core of my ccie lab, I'm just a little wary of laying out large amounts of cash at the moment with the economy in it's current state. Right now, I'm just trying to finish off the CCNP. The super secret slush fund is quietly building up so I can run a 3725 as my home networks core router

kalebksp

Forsaken_GA wrote: »

If I'm not mistaken, you do have to mark traffic to make use of WRED (if this isn't correct, that'd be good to know, because it means I have a horrible misunderstanding of WRED).

To make use of the weighted part of WRED you need marking. It will still stop TCP synchronization by randomly dropping some packets even if there is no marking. Of course then you lose some control of what gets dropped first.

APA

kalebksp wrote: »

To make use of the weighted part of WRED you need marking. It will still stop TCP synchronization by randomly dropping some packets even if there is no marking. Of course then you lose some control of what gets dropped first.

Cisco doesn't support RED..... if you want WRED you have to use the weight part of it hence the name Weighted-Random Early Detection.

RED is what allows you to prevent global synch by random dropping packets but you don't have control over what it drops...... Unfortunately cisco has no support for this...

Enabling WRED is random-detect (without key word it's IP Precedence by based by default)

kalebksp

A.P.A wrote: »

Cisco doesn't support RED..... if you want WRED you have to use the weight part of it hence the name Weighted-Random Early Detection.

RED is what allows you to prevent global synch by random dropping packets but you don't have control over what it drops...... Unfortunately cisco has no support for this...

Enabling WRED is random-detect (without key word it's IP Precedence by based by default)

There is no weighting if you have only one class of traffic.

From Cisco QOS Exam Certification Guide (Page 429):

In fact, if all packets were precedence 0, RED and WRED would behave identically.

Cisco may not have "RED" exactly, but if your traffic isn't marked (in which case it would all be Prec 0/BE) there is no real difference between RED and WRED.


Forsaken_AG, I just remembered that WFQ does take IP Precedence in to account, so there's another tool which relies on marking to some degree.

APA

kalebksp wrote: »

There is no weighting if you have only one class of traffic.

From Cisco QOS Exam Certification Guide (Page 429):



Cisco may not have "RED" exactly, but if your traffic isn't marked (in which case it would all be Prec 0/BE) there is no real difference between RED and WRED.


Forsaken_AG, I just remembered that WFQ does take IP Precedence in to account, so there's another tool which relies on marking to some degree.

Yeah common sense prevails there though... but if you're turning on random-detect and relying on all your traffic being marked as BE then I would be questioning your motives.... due to not having control over what WRED would be discarding.

Spot on with WFQ as well... keep in mind that WFQ gives preferential treatment to low volume & high precedence flows.... to the detriment of high volume\aggressive flows.
It has the ability to do this due to the formula it uses to apply weighting to packets.

Forsaken_GA

Alright, thanks guys, that tells me what I need to know!

kpjungle

Forsaken_GA wrote: »

Alright, thanks guys, that tells me what I need to know!

You say that you apply it to inbound traffic? afaik the queueing strategies 1) only take place when congestion occurs, and 2) queuing only makes any sense outbound. Ofcourse you can mark it inbound, but applying any congestion management and/or avoidance inbound is futile.

Forsaken_GA

kpjungle wrote: »

You say that you apply it to inbound traffic? afaik the queueing strategies 1) only take place when congestion occurs, and 2) queuing only makes any sense outbound. Ofcourse you can mark it inbound, but applying any congestion management and/or avoidance inbound is futile.

Right, that's what I was looking to do, mark the ingress traffic, apply qos policy to the outbound