Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Traffic shapping example and explanation

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

Everyone's tags (3)
12 REPLIES

Traffic shapping example and explanation

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.

Please don't forget to rate any posts that have been helpful. Thanks.
New Member

Traffic shapping example and explanation

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.

Traffic shapping example and explanation

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.

Please don't forget to rate any posts that have been helpful. Thanks.
Super Bronze

Re: Traffic shapping example and explanation

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.

New Member

Traffic shapping example and explanation

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

Super Bronze

Re: Traffic shapping example and explanation

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.

New Member

Traffic shapping example and explanation

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?

Super Bronze

Re: Traffic shapping example and explanation

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.

New Member

Re: Traffic shapping example and explanation

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.

Super Bronze

Re: Traffic shapping example and explanation

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

http://www.cisco.com/en/US/docs/ios-xml/ios/qos_plcshp/configuration/xe-3s/qos-plcshp-ether-ohead-actg.pdf

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.

New Member

Traffic shapping example and explanation

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?

Super Bronze

Re: Traffic shapping example and explanation

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.

1102
Views
10
Helpful
12
Replies
CreatePlease login to create content