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.
