Comments on: QoS Policing http://aconaway.com/2008/04/07/qos-policing/ It's possible that someone somewhere needs to see this. Fri, 10 Feb 2012 13:52:17 -0700 hourly 1 http://wordpress.org/?v=3.1.4 By: Aaron Conaway http://aconaway.com/2008/04/07/qos-policing/comment-page-1/#comment-2921 Aaron Conaway Tue, 08 Jul 2008 01:53:42 +0000 http://aconaway.com/2008/04/07/qos-policing/#comment-2921 Thanks for the comments, Richard. You've had some great input. :) Thanks for the comments, Richard. You’ve had some great input. :)

]]> By: Richard http://aconaway.com/2008/04/07/qos-policing/comment-page-1/#comment-2920 Richard Tue, 08 Jul 2008 01:49:16 +0000 http://aconaway.com/2008/04/07/qos-policing/#comment-2920 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! 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!

]]> By: Richard http://aconaway.com/2008/04/07/qos-policing/comment-page-1/#comment-2918 Richard Tue, 08 Jul 2008 01:38:00 +0000 http://aconaway.com/2008/04/07/qos-policing/#comment-2918 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. 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.

]]> By: Aaron Conaway http://aconaway.com/2008/04/07/qos-policing/comment-page-1/#comment-1047 Aaron Conaway Wed, 16 Apr 2008 21:49:40 +0000 http://aconaway.com/2008/04/07/qos-policing/#comment-1047 So it is. Corrected. Thanks for that, bubba-jay. So it is. Corrected. Thanks for that, bubba-jay.

]]> By: bubba-jay http://aconaway.com/2008/04/07/qos-policing/comment-page-1/#comment-1046 bubba-jay Wed, 16 Apr 2008 20:58:38 +0000 http://aconaway.com/2008/04/07/qos-policing/#comment-1046 One quick correction... its 'name' and not 'named' on the 'match access-group named SQUASHSSH' line. One quick correction… its ‘name’ and not ‘named’ on the ‘match access-group named SQUASHSSH’ line.

]]> By: Aaron Conaway http://aconaway.com/2008/04/07/qos-policing/comment-page-1/#comment-1015 Aaron Conaway Tue, 08 Apr 2008 11:53:25 +0000 http://aconaway.com/2008/04/07/qos-policing/#comment-1015 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. 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.

]]> By: Clint Young http://aconaway.com/2008/04/07/qos-policing/comment-page-1/#comment-1012 Clint Young Tue, 08 Apr 2008 03:13:30 +0000 http://aconaway.com/2008/04/07/qos-policing/#comment-1012 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!) 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!)

]]>