<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: Rate Limiting Traffic</title>
	<atom:link href="http://blog.super-networking.net/2006/06/rate-limitingtraffic/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.super-networking.net/2006/06/rate-limitingtraffic/</link>
	<description></description>
	<pubDate>Tue, 07 Feb 2012 16:54:39 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Super-Networking Blog &#187; Blog Archive &#187; Another stab at Bandwidth shaping</title>
		<link>http://blog.super-networking.net/2006/06/rate-limitingtraffic/comment-page-1/#comment-18</link>
		<dc:creator>Super-Networking Blog &#187; Blog Archive &#187; Another stab at Bandwidth shaping</dc:creator>
		<pubDate>Wed, 28 Jun 2006 19:49:12 +0000</pubDate>
		<guid isPermaLink="false">http://blog.super-networking.net/?p=9#comment-18</guid>
		<description>[...] I retook a look at the settings that I in place before for shaping traffic going out a particular interface on our Cisco 7609. I wrote about is in a past post which can be viewed here. This policy was a hard policing of traffic from certain subnets going out on interface that was limited to 20Mbps. The policy worked great and helped out the bandwidth problem we were having when those networks took over all the bandwidth. The problem we ran into with this one is there are periods of time where our overall traffic is low and these rate limited subnets could/need more this policy didn&#8217;t allow for it. So I went back to the drawing board and came up with a plan to set up a queuing policy that reserved a certain amount of bandwidth for the critical traffic and allowed all other traffic to have what is left. This allowed our critical traffic to have the breathing room it needs while allowing the other traffic to grow with the availablity of bandwidth. This policy has been working great so far but I have only had in place for a few hours so I still need to monitor for a while. I am putting the generic version of these policies below. Any questions leave a comment. [...]</description>
		<content:encoded><![CDATA[<p>[...] I retook a look at the settings that I in place before for shaping traffic going out a particular interface on our Cisco 7609. I wrote about is in a past post which can be viewed here. This policy was a hard policing of traffic from certain subnets going out on interface that was limited to 20Mbps. The policy worked great and helped out the bandwidth problem we were having when those networks took over all the bandwidth. The problem we ran into with this one is there are periods of time where our overall traffic is low and these rate limited subnets could/need more this policy didn&#8217;t allow for it. So I went back to the drawing board and came up with a plan to set up a queuing policy that reserved a certain amount of bandwidth for the critical traffic and allowed all other traffic to have what is left. This allowed our critical traffic to have the breathing room it needs while allowing the other traffic to grow with the availablity of bandwidth. This policy has been working great so far but I have only had in place for a few hours so I still need to monitor for a while. I am putting the generic version of these policies below. Any questions leave a comment. [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

