Could you please provide a proof link, that routers do not account these?
Sorry, don't have a link specifically for that, but some later Cisco shapers mention accounting for L2, so that would imply others do not. My experience also seems to imply many do not.
e.g.:
QoS: L2 Overhead Specification for Shaping and Policing Parameters for Ethernet
The Layer 2 (L2) Overhead Specification for Shaping and Policing Parameters for Ethernet allows you to configure shaping and policing bit rates that count Layer 2 encapsulation frame lengths in addition to Layer 3 packet lengths.
Feature History for QoS: L2 Overhead Specification for Shaping and Policing Parameters for Ethernet
|
Release
|
Modification
|
|
12.0(28)S
|
This feature was introduced for the Cisco 12000 Series 4-Port Gigabit Ethernet ISE Line Card.
|
http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/12sl2os.html
Could you please clarify what did you mean by "L2 overhead" - is this about L2 header only or you also mean preamble and check-sum?
The latter.
And how did you come up with 15%?
I've found it to be a reasonable average for "typical" (e.g. IMIX) L2 overhead. Of course, actual L2 percentage of overhead varies based on packet size. Highest overhead percentage for minimum sized packets and lowest percentage for maximum sized packets. Adjust your L2 percentage allowance to what you believe is suitable for your traffic. Also adjust toward worst case percentage if you're really trying to guarantee performance.
PS: it's a first time I hear the recommendation to shape 15% slower, that is why I'm trying to understand if it's justified by documentation.
As noted above, the 15% is subject to change. Otherwise, you're right, I don't recall mention often made of this. But then, there are other subtle points to QoS that aren't often covered in the "book".
For example, when I first started to do serious QoS on Cisco routers, I didn't appear to be getting the prioritization performance I expected, although config looked correct. I then came across a Cisco whitepaper (this one?: http://www.cisco.com/c/en/us/support/docs/asynchronous-transfer-mode-atm/ip-to-atm-class-of-service/6142-txringlimit-6142.html) mentioning the need to manually adjust tx-ring-limit on ATM interfaces so that the interface FIFO queue will overflow sooner into the CBWFQ queue, so that packets like VoIP would get the LLQ priority desired. Searching for more information on tx-ring-limit setting, came across a few other tidbits, but there's not much mention of this issue.
The first I came across the L2 overhead issue, was from confidential performance paper provided by a tier 1 SP, which explained when they implemented a CIR it was a L2 CIR, and if you didn't want to overrun it, you need to shape for the L2 bps. (I don't recall whether that paper suggested 15%, but it was over 15 years ago. I think I recall they did mention the need to allow for L2 overhead if using a shaper that only accounted for L3 bps.)
As far as I know, there is a logic to shape to 95% (due to pack_priority) and 90% (to additionally make sure you fit PE policer bc or buffer on dummy devices in the middle).
Interesting - I was unaware of either.
