09-12-2013 12:59 AM - edited 03-04-2019 09:00 PM
Hi all,
If i have 1M WAN link, what would be the value for traffic shaping: 1024000 or less? Bellow is an example of configuration on one of the routers in my company, and shapping value is set at 768000 with explanation that it always must be less because of the packet headers. For me, this doesn have much sense, because headers will go through that interface anyway. I believe that this value should be set to link speed (1M), not 768k.
Thans in advance
policy-map Shape-1024K
class class-default
shape average 768000
interface FastEthernet0/1
service-policy output Shape-1024K
09-12-2013 02:22 AM
Hello
Shaping comes into play on your routers when your physical wan lines exceeds the your traffic rate by the
ISP or your neighboring site- eg: your access rate is 2mb but your CIR
( committed information rate) is 1MB. or your CIR is 2mb and your neigbouring site is set to 1mb.
This means you need to send traffic 1/2 of the time to avoid egress blocking ( over time you can overwhelm the neigbouring site link as its CIR is lower then yours), This is where shaping can come into play to shape the link the same at both ends.
You can shape an average/peak/percent/rate/percent/percent remaining) - And all are different but shape average and Shape peak allow bursting of traffic ( Committed burst =BC & Excessive bursts=BE with a defined Time Interval = TC
Shape value = bps
Bc/Be value =bytes per second
Shaping average & peak tc/bc/values
Bc=Tc*CIR/8
Tc=Bc/Shaped rate(CIR
Be=Bc
TC= 0.125 default
TC= 0.025 for lower 320kps
TC= 0.010 for sensitive applications
Example:
Shape average ( default BC no BE)
Shape average 768000
Shape average 768000 (bits) bc of 12000 (bytes) ( this would send 12K bytes every .125 of a secs = 96000 bytes *8 =768000 bits
res
Paul
Please don't forget to rate any posts that have been helpful.
Thanks.
09-12-2013 02:38 AM
Hi pdriver,
Thaks for your response. I do realize that congestion mechanism will take place only whe there is congestion. However, my routers FastEthernet interface is connected to my providers interface. ISP is allowing me only 1Mb/s and, since speed of my interface is 100 Mb/s, i have to use shapping to avoid packet drops. I have read abouot shaping and policing, but my dilemma is diferent.
My question was would i use value of 768k or 1024k for 1M link? shape average 768000 or shape average 1024000?
I would said that you will use value of 1024k to shape trafiic in this case, because my CIR is 1024k.
09-12-2013 02:57 AM
Hello
If you need to conform to a CIR of 1MB then shape average of 1024000 would be required.
res
Paul
Please don't forget to rate any posts that have been helpful.
Thanks.
09-12-2013 03:07 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
Cisco's documentation, to me, has not been real clear, but I too believe most shapers only account for L3, they don't also account for L2 overhead. (Note I have seen some shaper documentation that L2 is accounted for too - on "better" or carrier grade platforms.)
When a vendor provides "1Mbps", they often enforce Ethernet wire bandwidth.
If your shaper doesn't account for L2 overhead, shaping at 1 Mbps would actually oversubscribe the path which can lead to drops of the WAN provider's "choice" rather than your choice. If might also lead to additional queuing delays, where you've now unable to prioritize as you desire.
L2 overhead varies per L3 packet. As L2 overhead is fixed per frame, it's a higher percentage for small packets and less for large packets.
If you do need to allow for L2, you could allow for "average" overhead for your traffic (i.e. analyze packets sizes being used) or you might allow for "worst case". 768 Kps for 1 Mbps, seems to me more like the latter.
09-12-2013 06:24 AM
Hi JosephDoherty,
Thanks for replying. I have found your post https://supportforums.cisco.com/thread/2147463 where you've explained that shapping value should be 5 to 15% less than actual link speed, because of the L2 header.
I'm also using nested policy and VoIP (bellow are the configuration and IOS version). Router models are 2801 and 2811.
How can i check how does the shapper works for theese models? I've tried Cisco documentation, but without luck.
How do you accuratelly determines will it be 5, 10 or 15% less?
System image file is "flash:c2800nm-advipservicesk9-mz.124-25a.bin"
policy-map My_Policy
class VOICE
priority 256
class VOICE-CONTROL
bandwidth remaining percent 9
police 512000
class VIDEO
bandwidth remaining percent 16
police 256000
class My_Class_01
bandwidth remaining percent 9
police 512000
class My_Class_02
bandwidth remaining percent 42
police 512000
class My_Class_02
bandwidth remaining percent 16
police 512000
class class-default
bandwidth remaining percent 8
random-detect
police 512000
!
policy-map Shape-1024K
class class-default
shape average 768000
service-policy My_Policy
09-12-2013 08:59 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
As I've noted, Cisco documentation isn't very clear what bandwidth a shaper actually accounts for. (I never thought about L2 vs. L3 until I came across some Cisco documentation that mentioned the shaper accounting for L2 as a feature. I've inferred from that, most other Cisco shapers don't.)
As to being accurate, you cannot be accurate, because the L2 overhead percentage varies per the packet's size. Again, you can analyze your traffic, determine the average packet size and then allow for average L2 overhead. Or you can figure what's the L2 overhead for a minimum size packet and allow for that (which would be worst case, but then, on average, you're likely shaping slower than available capacity). Shaping for worst case, though, helps insure you don't unexpectedly overrun your available bandwidth which might be important for critical performing applications like VoIP. (Oh, standard L2 overhead varies per media, believe it's usually 18 bytes per frame for Ethernet.)
PS:
Interesting policy - not sure I see the benefit of all the class policers, though. I also recommend against using RED unless you really understand it.
Also BTW, when shaping for 1 Mbps on FE, you might want to tune down tx-ring-limit. As you're doing VoIP, you might also want to insure the shaper's Tc is small, say 10ms or less.
09-13-2013 07:20 AM
I've found this document (http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/12sl2os.html) which describes L2 happing configuration, but it says that is implemented on a specific module card. I'm not sure how other Cisco devices implements this functionality.
As for the number of classes, they have its purpose because of different priorities. Althoug i'm not that much into QoS, this configuration was implemented by CCIE guy, so i believe that he knew what he was doing
I'm not sure that i fully understood configuration of tx-ring-limit. I've searched Cisco site, but all i've found was related to ATM. Could you please provide me some links about this? Regarding VoIP, we are using it in our network, but we don't nave any problems with it. This remark was related to packet latency?
09-13-2013 09:35 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've found this document (http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/12sl2os.html) which describes L2 happing configuration, but it says that is implemented on a specific module card. I'm not sure how other Cisco devices implements this functionality.
Good find! That's either what I've read in the past, or something similar. Note it's concerning carrrier grade equipement and IOS.
Again, my guess, other Cisco equipment usually just accounts for L3.
As for the number of classes, they have its purpose because of different priorities. Althoug i'm not that much into QoS, this configuration was implemented by CCIE guy, so i believe that he knew what he was doing
Well I've found CCIEs, indeed, often know what they are doing. Yet, it's difficult to truly be an expert in all aspects of networking. Again, I'll just say that the policy is (cough) interesting.
I'm not sure that i fully understood configuration of tx-ring-limit. I've searched Cisco site, but all i've found was related to ATM. Could you please provide me some links about this? Regarding VoIP, we are using it in our network, but we don't nave any problems with it. This remark was related to packet latency?
Unsure there's much additional (whitepaper/technote) documentation about tx-ring-limit except in reference to ATM.
Tx-ring-limit adjusts the depth of the interface's hardware FIFO queue. Basically, only when the hardware FIFO queue overflows does the software CBWFQ queues prioritize the overflow traffic as you intend. Later IOS versions, I recall, are supposed to adjust the interface queue down when CBWFQ is enabled on the interface.
If you're happy with performance, then leave it alone.
09-14-2013 12:25 PM
I am satisfied with VoIP performance. we have no problem with jitter, latency or any other parameter, so i won't be changing anything regarding this.
However, i'm not happy about shapping. My link is shaped ad 75% of it's capacity. I'm still not convinced that this is how it should be done. Same CCIE guy originally shapped it at 1024k, but my colleagues reduced this at 768k, with no so clear explanation about headers overhead. Reading one of your previous posts, i beleive they ment same thing as you when you were talking abou 5-15% less.
Since Cisco isn't be very clear about L2/L3 shapping on newer devices (if 2801 is that ), i guess that only way to check this is to try it myself, and to check number of dropped packets on interfaces. But, since this is my production environment, i'll have to think this through before i do it.
09-15-2013 04:59 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
BTW, I did forgot to mention, there's additional Etherenet (non-VLAN tagged) overhead beyond the L2 framing overhead (18) that wraps the IP packet, the preamble (8) and interframe gap (12), so if you want to shape for actual available wire bandwidth, you may need to account for those too. For non-VLAN tagged frames, all the total overhead is 38 bytes. So for a 1500 byte IP packet, your overhead is only 38 / 1538 = (about) 2.47% For a minimum size Ethernet packet, overhead is 38 / (8 + 64 +12) = (about) 45.24%! So, depending on your packets sizes, and whether the device's shaper can account for some or all non-L3 bandwidth, and whether you want to allow for worst case or average case, it's possible even 25% allowance is too little.
BTW, I just found another Cisco document which notes a feature in XE 3S to enable L2 overhead accounting within a shaper. See
Again, considering the "vintage" of XE 3S, I would presume other (older) IOSs without this feature don't account for the L2 overhead this feature can.
09-16-2013 05:58 AM
I've just remembered that i have DMVPN implemented, and that on Tunnel interface which source is FastEthernet on which i do shapping. On my Tunnel interface, i have MTU set to 1400 (although output of the show int tunnel shows that mtu is 1514), and MTU on FastEthernet interface is 1500. Now i'm confused?!?!
Writing this makes me wonder, why do we even discuss about L2/L3 shapping? If Cisco isn't explicitly telling you to take care about this, why do we trying to figure out how to configure this? We've found some documents that covers older and specific device. Is it possible that you don't need to care about this, that it is left to hardware to handle this? Otherwise, Cisco should mention something when they are talking about traffic shapping.
I'm thinking, when your provider gives you 1 or 2 or 5 Mb/s, he doesn't says is it L2 or L3 Mb/s or is it wire speed. They simply tells you that it is speed allocated to you. From that point of view, do i really need to take care of L2/L3 shapping? My data packets are bigger and they will be e.g. 1532 bytes, but my VoIP packets are smallerand they will be 520 bytes. My speed says that i can send 1 Mb (1024*1024 bytes) of traffic per seccond. If my packet is bigger, it will send less packets and other way arround. It's impossible to cover every scenario with every packet size, isn't it? Do you understand what i'm trying to say?
09-16-2013 07:10 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've just remembered that i have DMVPN implemented, and that on Tunnel interface which source is FastEthernet on which i do shapping. On my Tunnel interface, i have MTU set to 1400 (although output of the show int tunnel shows that mtu is 1514), and MTU on FastEthernet interface is 1500. Now i'm confused?!?!
Ah, well with tunnels, other consideration apply. BTW - Later DMVPN supports per tunnel QoS (a nice enhancement).
For tunnels, you normally want your physical interface at its normal MTU. The tunnel interface's IP MTU set to allow for tunnel overhead (usually about 60 to 80 bytes less than MTU). Tunnel PMTUD enabled. And if supported, tcp adjust-mss configured 40 bytes less than IP MTU.
Writing this makes me wonder, why do we even discuss about L2/L3 shapping? If Cisco isn't explicitly telling you to take care about this, why do we trying to figure out how to configure this? We've found some documents that covers older and specific device. Is it possible that you don't need to care about this, that it is left to hardware to handle this? Otherwise, Cisco should mention something when they are talking about traffic shapping.
We discuss shaping, because without it we often "lose" QoS policy management (i.e. congestion issues may appear "downstream" on devices beyond our management control).
Yea, Cisco doesn't tell you much about shaping. But consider how much they tell you about routing. They principally provide the features and assume you know what to do with them. (Note - of course there's Cisco press books on routing and on QoS - the latter, hopefully, would discuss shaping.)
I'm thinking, when your provider gives you 1 or 2 or 5 Mb/s, he doesn't says is it L2 or L3 Mb/s or is it wire speed. They simply tells you that it is speed allocated to you. From that point of view, do i really need to take care of L2/L3 shapping? My data packets are bigger and they will be e.g. 1532 bytes, but my VoIP packets are smallerand they will be 520 bytes. My speed says that i can send 1 Mb (1024*1024 bytes) of traffic per seccond. If my packet is bigger, it will send less packets and other way arround. It's impossible to cover every scenario with every packet size, isn't it? Do you understand what i'm trying to say?
Yes I understand. However, first time I really thought about logical Etherent L2 overhead was because one of our WAN vendors provided a NDA document discussing the importantance of accounting for L2 overhead when you're working with an interface that doesn't run natively at that provisioned bandwidth.
Basically, if a provider drops you a physical 10 Mbps Ethernet connection (without any logical cap), you get 10 Mbps of wire bandwidth. But what do they mean when they provide you 10 Mbps cap on a 100 Mbps FastEthernet connection? Well, it seems most providers mean you get the same bandwidth as a physical 10 Mbps Ethernet provides. The problems for us, a physical 10 Mbps interfaces provides "back pressure" based on its actual transmission. But when dealing with a logical 10 Mbps cap, ideally we want to it to behave like the physical interface, but to make this happen, we need to account for the same L2 overhead that's "automatic" with the physical interface.
As logical caps on Ethernet hand-offs are a somewhat recent popularity, something like QoS shaping, with L2 overhead accounting, is only now starting to "catch-up".
Also keep in mind, other serial interfaces, that run at less than their full potential (e.g. half T1), are usually physically clocked slower. I.e. the interface is natively running at the "slower" bandwidth. This differs from Ethernet where the "slower" bandwidths are logical caps of one kind or another. That noted, when dealing with something like frame-relay CIR, that has less than physical interface bandwidth, shaping, and L2 overhead issues, arise too. However, back when frame-relay was common, you didn't so much deal with things like VoIP shared on a PVC with data traffic. I.e. precise shaping wasn't as critical as it can be today.
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