12-11-2011 10:13 PM - edited 03-04-2019 02:35 PM
Hi,
Can any one please explain what is the difference between shape average and shape peak in QOS.
From my understanding shape average is CIR and shape peak is max BW of link.
so is it possible if link bandwith is 64K then we can allocate shape average 256k.
Thanks
Saurabh
Solved! Go to Solution.
12-13-2011 11:44 PM
Hi Joseph,
I've performed the experiments in our network lab using 1841 routers running 15.1(4)M2 Advanced IP Services, interconnected via Fa0/1 interfaces. The topology:
Generator ---> (Fa0/0) 1841 (Fa0/1) ---> (Fa0/1) 1841 (Fa0/0) ---> Receiver
The shaping was configured on the leftmost 1841 as follows:
policy-map fa0/1-out
class class-default
no fair-queue
shape average 100000 8000 8000
!
interface FastEthernet0/1
service-policy output fa0/1-out
The generator created a flow of IP/UDP packets of total size of 1000 bytes, 150 packets per second, totalling a rate of 1.2 Mbps.
I used Wireshark to capture the flow and graph it out. Following is the screenshot of the graph flow:
Up to the roughly 180th second, the configuration of the shaping was as indicated, i.e. shape average 100k 8000 8000. The graph shows the throughput to oscillate around the configured CIR of 100 Kbps. At around the 180th second, I have modified the command to
shape peak 100000 8000 8000
As it can be seen, the total throughput jumped twofold and now oscillates around the value of 200 Kbps which appears to align with my original explanation and derivation of CIR' = configured CIR * (1+Be/Bc) = configured CIR * 2, as in my case, the Be=Bc.
Furthermore, around the 230th second, I modified the configuration again to:
shape peak 100000 8000 4000
The rate dropped to 150 Kbps which also aligns to the CIR' = configured CIR * (1+4000/8000) = configured CIR * 1.5
This experiment used the generator to create a substantially higher load than the configured CIR. Another experiment was performed under the same sequence of settings on the router, however, the stream consisted of 100 byte packets, 300 packets per second, totalling the rate of 240 Kbps.
In short, the results were absolutely identical, see the following graph:
Till the 95th second, the shape average 100k 8000 8000 command was used. Between the 95th and 130th second, the shape peak 100k 8000 8000 was used. After the 130th second, the shape peak 100k 8000 4000 was used.
If these experiments do not align with what you requested, Joseph, please feel welcome to give me your description of the experiment so that I can replicate it in our lab.
My personal feeling is that the shape peak is good for those customers who have negotiated both the CIR and EIR with their service provider (Bc, Be and Tc), and want to always shape up to CIR+EIR, i.e. they want to always go to the PIR, accepting the risk that the packets over the CIR may get dropped or marked for future dropping. Naturally, they specify the CIR in their shape peak command but the shaping in this case is backed up by the idea that they can always send Bc+Be bytes.
I would love to hear your opinion on all of this.
Best regards,
Peter
12-14-2011 02:57 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
"If these experiments do not align with what you requested, Joseph, please feel welcome to give me your description of the experiment so that I can replicate it in our lab."
Peter, your experiments do align with what I requested, and thank you very, very much for taking the time and effort to conduct them!
"I would love to hear your opinion on all of this."
First, your experiment not only confirms your explanation of what you expected but also confirms an experiment I had a hazy recollection of trying myself years ago, as I've already noted. Yet, if you re-read my original post's Cisco text, these results are, I believe, contrary to what one would expect if only Bc tokens are replenished per Tc.
Further, I'm not sure I see the benefit of such an implementation because as you've already noted, you can achieve the same results by using average 2x vs. peak 1x (or other settings of average, i.e. your shape peak 100000 8000 4000 test could be 1.5x average, i.e. shape average 150000 8000 8000).
If peak actually worked as I believe it should (also more like ATM's PCR/SCR), it would maintain a long term (average) CIR yet support transient bursts better. Consider my prior posting (assuming average and peak functioned as described) where the transient bursts would have less latency (if shaped) or less drops (if policed).
To reiterate, if shape average 200000 8000 # equals shape peak 100000 8000 8000 or shape average 150000 8000 # equals shape peak 100000 8000 4000, I'm not seeing a real advantage of having both average and peak; do you?
Again, Peter, thank you so much for your effort in investigating this.
12-16-2011 01:57 AM
Hi Joseph,
To reiterate, if shape average 200000 8000 # equals shape peak 100000 8000 8000 or shape average 150000 8000 # equals shape peak 100000 8000 4000, I'm not seeing a real advantage of having both average and peak; do you?
I do not, either. Sustained rate of the one can be recalculated into the sustained rate of another. The size of the bursts may apparently differ, though: with constant load, the shape average can burst up to Bc bytes, whereas shape peak always bursts up to Bc+Be, but you could recalculate both values so that the bursting is identical again... phew. This seems to be a rather useless feature in the IOS, only contributing to users' confusion.
Petr Lapukhov tried to explan it in his own words here:
http://blog.ine.com/2008/08/26/understanding-the-shape-peak-command/
But even he admits that with proper argument manipulation, one command can be forced to behave exactly as the other.
Best regards,
Peter
12-16-2011 03:56 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Hmm, personally I don't think its especially accurate to consider either shape average or shape peak to "burst" when both allow you to sustain their rate. This is like saying Ethernet allows you to burst to 10 Mbps (it does, but also allows that as a sustained rate) although I've seem such references too.
It's interesting your referenced blog mentions frame-relay and minCIR, since I had thought to mention them where I mentioned ATM's PCR/SCR, but I thought the latter a better representation of burst allowance over a committed rate as it's enforced by the interface without any dependence on some kind of actual congestion indication.
I didn't read the blog throughly, but don't believe I noticed any reference to token replenishment. This is what could make all the difference. Your tests seem to demonstrate that replenishment doesn't operate as documented in the Cisco reference I provided, for if it did, don't believe you would have obtained the results you did.
Well put "This seems to be a rather useless feature in the IOS, only contributing to users' confusion." but I think it would be useful if it operated as I think it should, i.e. peak allowing carrying forward some credit for prior bandwidth utilization below CIR.
Peter thanks again for your effort and analysis. I hope the original poster didn't mind this side bar.
12-20-2011 03:51 AM
Hi Joseph and Peter,
Sorry , i was away from the discussion.
and i did not mine for the sidebar its making my funda more clear. thanks peter for doing lab test.
I would like to ask few question from my previous config.
policy-map VPN-CHILD-POLICY
class Trading
set ip dscp af31
bandwidth 200
class Netman
set ip dscp af42
bandwidth 16
class class-default
set ip dscp af21
bandwidth 40
random-detect dscp-based
policy-map VPN-POLICY
class class-default
shape average 256000
service-policy VPN-CHILD-POLICY
1.Total bandwith assign to different classes should not be max then 64k which interface bandwidth.
or can we assign more BW to differnet classes - i do not think so because interface BW is 64k.
like here class trading
200
Netman
16
and default
40
so total is 256.
so this total bandwith should be equal to 64K or less than 64k.
PS:
If you only have 64 Kbps, no need to shape, just use your "child" policy as you main policy on the interface.
what will be the result if i use shape average ? and second thing if i am using shape average then what value of CIR i should assign for 64k.
Can we assign shape average to the interface bandwidth.
ex-
it will be shape average 64000 ? or should be less than 64000
and below config is right ?
policy-map VPN-CHILD-POLICY
class Trading
set ip dscp af31
bandwidth 200 -> should be less than 64k
class Netman
set ip dscp af42
bandwidth 16
class class-default
shape average 64000 Bc ? Be ?
How do we calculate CIR on interface bandwidth or we can assign any value less than actual BW.
Please explain.
Thanks
Saurabh
12-20-2011 08:03 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
I'm a little confused. What's the interface's actual bandwidth?
You normally only need to shape if you there's a need to hold traffic below available physical bandwidth. Shaping (or policing) can be used to "reserve" bandwidth for other traffic, but prioritization (if supported) is often better.
For example, say your link had both VoIP flows and bulk high bandwidth consuming flows. You could shape or police the bulk traffic to leave what you believe would be sufficient bandwidth for the VoIP traffic, but then bandwidth not being used by VoIP would go unused. Instead if you prioritize the VoIP traffic, it gets the bandwidth it needs when it needs it, but your bulk traffic could fully utilize the link otherwise unused bandwidth.
From what you've have seen to have described, you have no need to shape bandwidth for 256 Kbps if your physical bandwidth is 64 Kbps (because the shaper would never engage). If you had 256 Kbps there can be reasons why you might need to shape for 64 Kbps, but they don't appear to apply in your case.
12-20-2011 10:29 PM
Hi Joseph,
thanks for replying.
bandwidth for interface is 64k.
but if you will have a look on policy they configured the 200 for
policy-map VPN-CHILD-POLICY
class Trading
set ip dscp af31
bandwidth 200
that means you are allowing 200k that is not possible if your bandwidth is hardcoded to 64k.
so i need to adjust bW less than 64k what bandwidth i want to shape it.
and second thing shape average we need to configure always under class default.
and if we configure shape avergae 64000 - to the actual bandwith of interface the it will engage qos or not.
if we put command shape average 64000 do we need to also put value for Bc and Be or we can just leave shape average 64000.
if we need to put Bc and be value then how do we calculate.
Sorry, i am asking you to many question but i think you expalnation will make my funda more clear
Thanks
Saurabh
12-21-2011 08:33 AM
Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
Ok, if "bandwidth 200" is the issue on a 64 Kbps bandwidth, then correct the allocation or uses a % (if supported).
From what you've described, you don't need to shape.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide