Hi, i am little confused as what is meant by burst size ?? and what is meant by traffic rate ? since traffic rate is measured in number of bits and burst size is measured in bytes so what i have understood is that, burst size determines the biggest packet that could be sent in a stream, am i right ??
Let us assume you want to rate limit traffic on a FastEthernet interface to 20 Mbit/s.
How fast is a single frame sent? Well, line rate, which is 100 Mbit/s - there is no other choice on a FastEthernet interface. So every single frame is sent above the desired 20 Mbit/s.
Given those facts 20 Mbit/s has to be the "long term" average.
What is "long term"? "Long term" does not always mean one second, Burst size defines the time window. In case you set the Burst size to 1000000 Bytes in my example, then the rate is measured in a time window of 1000000*8/20000000 sec= 400 ms
Within a 400 ms window 1000000 Bytes are allowed no matter how fast they are sent. If there are more Bytes in the time window, then the configured action will be taken, which depends on whether you use a policer or a shaper.
In brief: Time window = Burst size / rate
As such you are right, the burst size could be set to the maximum packet size. But in mose cases this would specify a very small time window, which would be not desireable. In reality much larger values are used - like in the example - dependent on interface speed and other parameters defining an appropriate time window to measure the rate.
Just to note, you can also let IOS determine the burst values, by not configuring them.
Martin's post has it right, but let me offer another perspective that also might help.
When you look at a bandwidth graph that indicates something like 10% utilization over 5 minutes on a FastEthernet interface, does this mean the interface only transmitted at 10 Mbps? Of course not, since it always transmits at 100 Mbps. What it means is the interface was only active 10% of the time, although we don't know how the 10% was distributed over the 5 minutes.
Time periods are very important. If the 10% over five minutes, above, was all done in the first 30 seconds of a 5 minute period, but if we measured usage now on 1 minute intervals, the first minute would show 50% utilization, and the remaining 4 minutes would each show only 0% utilization.
Over a 30 second measured periods, again with data all transmitted in the first 30 seconds, the first would show 100% and the next 9 also 0%.
If instead of a 100 Mbps interface, we set the speed down to 10 Mbps, the interface would
actually be busy 100% of the time for all 5 minutes to transmit the same number of bits. It would also measure at 100% regardless of how we subdivide the 5 minute period.
If instead of setting the interface to 10 Mbps, we shape or police at 10 Mbps. Does this now simulate a 10 Mbps interface? Not exactly, but how close it does is related to the burst size which sets the measurement window.
If we set the burst size large enough that 5 minute period is defined, the shaper or policer will not allow more bits to be sent during the whole 5 minutes than would exceed 10% of the total time. Once again, we don't know where in the 5 minutes the bits are transmitted.
If we set the burst size such that the time period is 1 second, again the shaper or policer will insure only 10% of the time interval is used for transmission. If there were 30 seconds of 100 Mbps traffic awaiting in the queue, an average rate policer would transmit for 100 ms and drop all the remaining traffic. An average rate shaper would transmit for 100 ms, pause 900 ms, and repeat until all the data was transmitted, which would take 5 minutes (and now more closely simulates a 10 Mbps interface -- over time).
The above is simplified. Normal burst sizes and their corresponding time windows are often down in the 25 to 40 ms range. Since we work with frames and not bits, effective rates can be slower than expected (or as defined). Not discussed has been peak rate vs. average rates.
In practice, a policer or rate-limiter, simulates a lower speed interface without any queuing. A shaper queues traffic, but its queue depth and queue management might differ from a physical interface you're attempting to simulate. If you're dealing with a downstream provider that "caps" excess bandwidth, it's often advantageous to implement like "caps" where you can control the traffic and see what's happening. In this latter instance, important to find out what all the parameters the provider is using for their "cap", i.e. more than just a CIR or PIR rate.
Sorry to resurrect an old thread, but I have a question that pertains to this topic...
In the case of QoS for VoIP traffic (over IPSEC VPN):
If I have priority for Voice traffic via DSCP (ef) and I don't want to limit this traffic, what should I use to limit all of the other traffic? I think I should use shaping, because I don't want to drop packets and cause issues. TCP may recover, but that's not what i'm after here. The VPN tunnel uses cable or DSL (can't remember).
I have this so far:
match dscp ef
match flow ip destination-address
match tunnel-group DefaultL2LGroup ! My L2L tunnel to another site
police output 200000 37500
service-policy VoicePolicy interface outside
If I can find the upload speed of this link, could I then determine the what to set the burst size as? Let's say that I want to give Voice traffic the top 25% of the upload bandwidth all to itself and limit the Data to 75%. (I think that the Voice traffic would be unrestricted with the policy-map above, wouldn't it?)
2Mbps UP = 512Kbps for Voice traffic (I think about 6 phones).
One more question on policing:
The command 'police output ; what is the first number for?
If I do setup shaping instead of policing, i'm considering this configuration:
shape average [75% of upload bandwidth converted to kbits]
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...