Q0S -Traffic Shaping - max-reserved-bandwidth on the physical interface higher than shaped value

[fallegretti]

Hi  all,

I am checking an existing QoS solution and have a doubt regarding the bandwidth statement on the physical interface. We are supposed to deliver a 30M circuit over a 100M bearer and are using shaping for it, here is the simplified relevant config

policy-map Inner_Throttle@30M
 class PREMIUM
  priority 1920
  set ip dscp ef
 class ENHANCED2
  bandwidth 100
  police cir 100000 bc 12500 be 18750
   conform-action set-dscp-transmit 26
   exceed-action set-dscp-transmit 28
   violate-action set-dscp-transmit 30
 class MANAGEMENT
  bandwidth 300
  police cir 300000 bc 37500 be 56250
   conform-action set-dscp-transmit 48
   exceed-action set-dscp-transmit 48
   violate-action set-dscp-transmit 48
 class STANDARD
  bandwidth 27380
  police cir 27380000 bc 3422500 be 5133750
   conform-action set-dscp-transmit 10
   exceed-action set-dscp-transmit 12
   violate-action set-dscp-transmit 14
policy-map Outer_Throttle@30
 class class-default
  shape average 30000000
  service-policy Inner_Throttle@30M

interface GigabitEthernet0/1
 no ip address
 duplex full
 speed 100
 max-reserved-bandwidth 100
no shutdown

interface GigabitEthernet0/1.100
 encapsulation dot1Q 100
 ip address a.b.c.d x.x.x.x
 service-policy output Outer_Throttle@30
no shutdown

As you can see the max reserved bandwidth has been set up to 100M, should it be set up to 30M? Does it matter?

[Vasilii Mikhailovskii]

Hello.

Is doesn't matter. The command is not needed under G0/1, but also it does no harm.

Shaping is done inside QoS policy and not with max-reserved-bandwidth.

Notes about QoS (if you are running IOS, not IOS XE):

• you have "priroty 1920" for PREMIUM class -> it's LLQ, but this would allow the class to burst over 1920 (if no congestions) - not sure if it's expected in your design;
• STANDARD class has bandwidth of 27M, but default queue-size (64 packets) -> this could be a bottleneck;
• WRED could be useful for class STARDARD (with adjusted threshold);
• class-default could starve, as you left almost no bandwidth for it;

[fallegretti]

Thanks. That's what I thought.

Regarding your other observations:

• priority 1920 - not sure what the design expected, I didn't do it. Yes I understand what you're saying, the class will use more bandwidth in no congestion, it would self police to 1920 if there is congestion.
• The I deleted some of the config to make it shorter, the complete config for STANDARD is: bandwidth 27380
    random-detect dscp-based
    random-detect exponential-weighting-constant 8
    random-detect dscp 10 2898 4096 1
    random-detect dscp 12 1739 4096 1
    random-detect dscp 14 870 2898 1
    police cir 27380000 bc 3422500 be 5133750
     conform-action set-dscp-transmit 10
     exceed-action set-dscp-transmit 12
     violate-action set-dscp-transmit 14   
• My understanding is that the combination of bandwidth command and random-detect removes the queue-size limit. Do you agree?
• Traffic is classified into STANDARD by a permit ip any any acl, so there should be nothing in the class-default to starve

[Vasilii Mikhailovskii]

Hello.

>>My understanding is that the combination of bandwidth command and random-detect removes the queue-size limit. Do you agree?

It depends on the platform and IOS release.

After you configure the policy-map gather and provide here "show hqf int ..." -> it would have all the information you need.

Btw, if you are using ISR1/2, then there is no way to have mean queue-size of 4096, as max aggregate queue size for physical interface is 2048 or 4096.

PS: there is no reason to have this high thresholds on 30M link, but that is my own opinion.