QoS Policing

We covered QoS tagging the other day, but that just marks packets. I think you’re old enough now that we should actually do some policing. Policing is where you restrict the amount of bandwidth that a flow or set of flows can use. For example, say you have a site that serves webpages to the rest of the network. HTTP is the primary function, but the SysAdmins also have to maintain the boxes via SSH, right? To make sure that their SSH sessions don’t squash the bandwidth that your HTTP servers need, you can police the SSH sessions by giving the a bandwidth ceiling that they can’t cross.

Let’s set up a scenario. You have a router with two Ethernet ports. E0/0 goes to your webservers on, while E0/1 goes to SysAdmins’ PCs on We want to restrict all SSH access from to to 8k of bandwidth. That’s right, you don’t like your admins and want them to struggle with their daily tasks. Let’s set it up.

Remember the steps? ACL, class-map, policy-map, interface. First, create an ACL that matches the traffic you want to police.

ip access-list extended SQUASHSSH
permit tcp eq 22

Next, create a class-map that matches that traffic.

match access-group name SQUASHSSH

Create your policy-map. This is where you actually set the bandwidth restrictions.

police 8000 conform-action transmit exceed-action drop

Last time, we just did a set dscp af43, but this time we actually take action on a packet instead of just marking it. The long lines does three things — it sets the ceiling to 8000 bits per second, transmits if the rate is below that number, and drops if its exceeded. So, if one of the admins tries to SCP a file over, he’s gonna be in for a surprise with only an 8k window to use. If he goes over 8k, the packets are just dropped, and it’s up to TCP to retransmit. It’ll take a while. Remember, too, that this policy applies to anything matching the ACL, so, if two admins are SCPing files at the same time, they have to share that 8k. Wow, you’re mean!

Setting it up on the interface is pretty straightforward. It’s just like we did before.

interface E0/0
service-policy output SQUASHSSH-PMAP

I set this up in a dynagen lab to test it, but, instead of SSH traffic, I policed ICMP. If I did a normal, 5-packet ping, it worked great. If I sent a 100-packet set, drop, drop, drop. Or if I increased the size of the packets. Just to be sure it was the service-policy doing the dropping, I sent a 100-packet set and removed the policy from the interface; it missed a few at first, but, when the policy was removed, it zoomed right along without a single miss or hesitation.

NOTE: I do not condone policing traffic from your coworkers machines to 8k, but it would be funny.

Aaron Conaway

I shake my head around sometimes and see what falls out. That's what lands on these pages. If you have any questions, the best way to contact me is through Twitter at @aconaway.

More Posts

Follow Me:

7 comments for “QoS Policing

  1. Clint Young
    April 7, 2008 at 10:13 pm

    Okay, one question about this then. Lets say we have 1.544 Megabits worth of traffic – a trusty ole’ DS1. Lets say that I want to allow my co-workers to SCP to their hearts content, ONLY if the bandwidth is available. Suddenly, while the SCP is in progress, a new patch comes out and everybody starts hitting up our web servers! I want to have the traffic on the SSH session throttled back to the 8k of bandwidth. (Or in another scenario at home, I am download/uploading a few Linux ISOs on a P2P connection, suddenly the VoIP phone rings, and I want to give it the bandwidth it deserves, so my wife doesn’t drop her phone call!)

  2. April 8, 2008 at 6:53 am

    Great question, Clint.

    In those scenarios, you’re not looking to restrict traffic from using bandwidth, but, rather, you’re wanting to guarantee bandwidth for other traffic. Instead of using “police”, you would actually use “priority” and set how much bandwidth to guarantee.

    Logically, that’s the next article, so keep an eye out.

  3. April 16, 2008 at 3:58 pm

    One quick correction… its ‘name’ and not ‘named’ on the ‘match access-group named SQUASHSSH’ line.

  4. April 16, 2008 at 4:49 pm

    So it is. Corrected. Thanks for that, bubba-jay.

  5. Richard
    July 7, 2008 at 8:38 pm

    In this situation I think you are better off using CBWFQ instead of CAR. With CAR your traffic patterns tend to be more of a TCP see-saw instead of a gradual leveling. This leads to some applications behaving odd and a general feeling that a flow is slower than it actually is. There is a very good article on Cisco.com’s website comparing the two (the link escapes me at the moment though). They both have there pro’s and con’s but for throttling internal non DoS related traffic CBWFQ is the way to go.

  6. July 7, 2008 at 8:53 pm

    Thanks for the comments, Richard. You’ve had some great input. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *