04-03-2015 10:51 PM - edited 03-05-2019 01:10 AM
Hi,
This question might seem to be dumb but I will still ask.
On ISR platform, does it take into consideration of the L2 header size when specifying the bandwidth? Please see below for the configuration. My question is the rates configured in "shape", "priority" and "bandwidth".
policy-map TEST class class-default shape average 512000 service-policy TEST-nested ! policy-map TEST-nested class Voice priority 60 <... some other classes> class class-default bandwidth 100
I am asking because in the "show policy-map interface xxx" output, I see that number of bytes matched in each class does include the L2 header size.
Thanks!
Solved! Go to Solution.
04-06-2015 11:40 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
For LLQ classes, excess is dropped but often that only happens when there's congestion. I.e. if not congestion, bandwidth can exceed priority settings. If you want to insure excess is always dropped, you can also add an explicit policer. (I'm unsure you can define a shaper in a LLQ class, but if you can, it's contrary to the purpose of LLQ.)
For non-LLQ classes, bandwidth sets a minimum bandwidth guarantee, i.e. it doesn't limit maximum. Any of these classes can use all the interface bandwidth. If that's not what you want, you can add an explicit policer or shaper.
04-06-2015 05:54 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 suspect on many ISRs, shaping and policing (which should include the LLQ priority statement) don't account for L2 overhead, but I'm not 100% certain. (The reason I suspect this because I came across a higher level platform where tracking L2 overhead was touted as a "feature".)
Whatever the "bandwidth" statement uses, it wouldn't normally be critical because all it normally does is assign dequeuing weights between queues.
04-06-2015 08:56 AM
Thanks Joseph. So is "priority" same as the "bandwidth" which only assigns the dequeuing weights? Traffic exceeding the "priority" or "bandwidth" configured will fall in the "class-default" and will be handled equally with the traffic in that class, correct?
We have customers on very limited BW (like 128kbps). I want to assign the voice-class with fairly accurate priority configuration. As you know that the voice payloads are very small so L2 overhead does play a big role in BW calculation.
Another question which is irrelevant, is that what queuing does class-default use? In my config there is nothing except a "bandwidth" configured in this class. Does it just do FIFO queuing? Should I use "fair-queue"? I know that "fair-queue" cares for the DSCP dynamically. Does it also care about packet size or smaller packets get better treatment than big TCP file transfer packet? Thanks!
04-06-2015 09:55 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
"So is "priority" same as the "bandwidth" which only assigns the dequeuing weights?"
No, priority is the keyword for LLQ. Traffic in the LLQ is always has absolute priority over all other traffic. Although there's only one LLQ, each LLQ class also has its own implicit policer.
"Traffic exceeding the "priority" or "bandwidth" configured will fall in the "class-default" and will be handled equally with the traffic in that class, correct?"
No. Traffic always says in the matched class. The class-default class if the class that matches "none-of-the-above". You always have a class-defaut. (I.e. it doesn't have to be explicitly defined, but when explicitly defined, you have set different options.)
"Another question which is irrelevant, is that what queuing does class-default use?"
By default, FIFO.
"Should I use "fair-queue"?"
I personally like FQ in all classes that support it, but insufficient information to say whether you you use it.
"I know that "fair-queue" cares for the DSCP dynamically."
Not post HQF. (Which should be the case on a 39xx router.)
"Does it also care about packet size or smaller packets get better treatment than big TCP file transfer packet?"
Yes and no. FQ monitors bandwidth usage. In theory, a single small packet gets "better" treatment vs. a single large packet because the former consumes less bandwidth. However, if the sum consumption of a sequence of small packets equals the single large packet, the transmission rate from two queues should be about equal (I'm also assuming the two flows are prioritized the same).
04-06-2015 10:52 AM
Thanks Joseph! Last question, if the exceeding traffic from a class is not falling into class-default, how are they handled? I have tried to configure a very small "priority" and I was generating much more traffic and they all passed through. What is the mechanism of handling the traffic? Are they handled the same as the exceeding traffic from other classes?
04-06-2015 11:40 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
For LLQ classes, excess is dropped but often that only happens when there's congestion. I.e. if not congestion, bandwidth can exceed priority settings. If you want to insure excess is always dropped, you can also add an explicit policer. (I'm unsure you can define a shaper in a LLQ class, but if you can, it's contrary to the purpose of LLQ.)
For non-LLQ classes, bandwidth sets a minimum bandwidth guarantee, i.e. it doesn't limit maximum. Any of these classes can use all the interface bandwidth. If that's not what you want, you can add an explicit policer or shaper.
04-06-2015 05:00 PM
Hi Joseph, I did a quick testing. I generated traffic and both the offered rate and matched bytes take into consideration of the L2 overhead... Is there a way to confirm whether the "priority" requires L2 to be counted or not? Thanks!
#sh policy-map int g0/3.301 | sec Voice
Class-map: Voice (match-any)
143574 packets, 21437371 bytes
30 second offered rate 161000 bps, drop rate 0000 bps
Match: dscp ef (46)
120996 packets, 19639992 bytes
30 second rate 130000 bps
Match: access-group name ACL_xxx
22578 packets, 1797379 bytes
30 second rate 31000 bps
Priority: 120 kbps, burst bytes 3000, b/w exceed drops: 0
04-06-2015 05:44 PM
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
What comes to my mind is sending enough traffic to oversubscribe the egress interface (which should trigger the LLQ policer) and then send "known" amount of traffic to LLQ and see when and how much is dropped.
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