cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
458
Views
9
Helpful
7
Replies

Traffic shaping and BW reservation/prioritization - L2 header included?

Difan Zhao
Level 5
Level 5

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!

 

1 Accepted Solution

Accepted Solutions

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.

View solution in original post

7 Replies 7

Joseph W. Doherty
Hall of Fame
Hall of Fame

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.

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!

 

 

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).

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?

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.

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
 

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.

Review Cisco Networking for a $25 gift card