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 192.168.1.0/24, while E0/1 goes to SysAdmins’ PCs on 192.168.2.0/24. We want to restrict all SSH access from 192.168.2.0/24 to 192.168.1.0/24 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 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 eq 22
Next, create a class-map that matches that traffic.
class-map SQUASHSSH-CMAP
match access-group name SQUASHSSH
Create your policy-map. This is where you actually set the bandwidth restrictions.
policy-map SQUASHSSH-PMAP
class SQUASHSSH-CMAP
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.
https://masto.ai/@aconaway
- Netbox Upgrade Play-by-play - April 25, 2023
- Sending Slack Messages with Python - March 15, 2023
- Using Python Logging to Figure Out What You Did Wrong - February 26, 2023
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!)
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.
One quick correction… its ‘name’ and not ‘named’ on the ‘match access-group named SQUASHSSH’ line.
So it is. Corrected. Thanks for that, bubba-jay.
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.
More info:
http://www.cisco.com/en/US/tech/tk543/tk545/technologies_q_and_a_item09186a00800cdfab.shtml#policing
http://www.cisco.com/en/US/docs/ios/12_0/qos/configuration/guide/qcpolts.html#wp6499
Cheers!
Thanks for the comments, Richard. You’ve had some great input. 🙂