Bandwidth versus maximum reserved bandwidth

By stretch | Thursday, February 12, 2009 at 2:00 a.m. UTC

By default, a QoS policy applied in IOS will only reserve up to 75% of a link's available bandwidth. The motivation behind this is to leave a bit of headroom for routing protocols and other critical traffic which might not otherwise be accounted for in a QoS policy. While this is effective for low-speed links, it leaves potential for a large amount of wasted bandwidth on high-speed links, particularly when policing is applied. For example, on a 10 Mbps Ethernet link, only 7.5 Mbps is available for CBWFQ or LLQ allocation.

This can present problems if you want to reserve, say, 90% of a link's bandwidth for RTP.

class-map match-all RTP
 match protocol rtp
!
!
policy-map VOIP
 class RTP
  priority 9000

We can see the 75% limitation manifest itself when applying the policy to an interface. We receive the following error:

R1(config-if)# service-policy output VOIP
I/f FastEthernet0/0 class RTP requested bandwidth 9000 (kbps), available only 7500 (kbps)

Oddly, at least on IOS 12.4(9)T1, a fair-queue configuration is applied as an apparent fallback: fair-queue 64 256 256. Not quite what we wanted. One way to fix this would be to artificially increase the bandwidth of the interface to make the router think it has more than it does. To reserve a full 9 Mbps, we could set the interface bandwidth to 12 Mbps; 75% of 12 Mbps is 9 Mbps, so we stay within the 75% ceiling.

R1(config-if)# no fair-queue
R1(config-if)# bandwidth 12000
R1(config-if)# service-policy output VOIP

This time our policy is applied without incident, as we're only reserving 75% of the supposed bandwidth. While our QoS goal has been achieved, we've inadvertently broken something else: routing. Consider a simple lab running a single OSPF area across all routers. Our QoS policy is applied outbound on R1's link to R2. R4 is advertising a default route into the area.

topology.png

With all equal-cost links, R1 should load-balance traffic following the default route across both of its uplinks toward R4. Here's what the OSPF interface table looks like before our bandwidth modification on FastEthernet0/0:

R1# show ip ospf int brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Fa0/1        1     0               10.0.13.1/24       10    BDR   1/1
Fa0/0        1     0               10.0.12.1/24       10    BDR   1/1

But increasing the observed bandwidth of FastEthernet0/0 to 12 Mbps lowers its OSPF cost from 10 to 8, resulting in a lower overall metric to R4:

R1# show ip ospf int brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Fa0/1        1     0               10.0.13.1/24       10    BDR   1/1
Fa0/0        1     0               10.0.12.1/24       8     BDR   1/1

What we've done is killed our equal-cost load balancing; all traffic from R1 to R4 will now flow over the link via R2, effectively cutting our actual available bandwidth in half.

Fortunately IOS provides a much more elegant solution to this problem: max-reserved-bandwidth. This command allows us to change the default limit of 75% to something better suited to our needs. We can lower the configured bandwidth on FastEthernet0/0 to match its actual bandwidth, and increase the maximum QoS-reserved bandwidth to 90%.

R1(config-if)# bandwidth 10000
CBWFQ: Not enough available bandwidth for all classes Available 7500 (kbps) Needed
9000 (kbps)
CBWFQ: Removing service policy on FastEthernet0/0
R1(config-if)# max-reserved-bandwidth 90
R1(config-if)# service-policy output VOIP

With this solution, we can leave the bandwidth settings where they should be while still getting efficient use out of our links.

R1# show interface f0/0
FastEthernet0/0 is up, line protocol is up 
  Hardware is Gt96k FE, address is c201.4188.0000 (bia c201.4188.0000)
  Internet address is 10.0.12.1/24
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, 
...

R1# show policy-map interface f0/0
 FastEthernet0/0

Service-policy output: VOIP

Class-map: RTP (match-all)
  0 packets, 0 bytes
  5 minute offered rate 0 bps, drop rate 0 bps
  Match: protocol rtp
  Queueing
    Strict Priority
    Output Queue: Conversation 264 
    Bandwidth 9000 (kbps) Burst 225000 (Bytes)
    (pkts matched/bytes matched) 0/0
    (total drops/bytes drops) 0/0

Class-map: class-default (match-any)
  7 packets, 522 bytes
  5 minute offered rate 0 bps, drop rate 0 bps
  Match: any 

About the Author

Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.

Posted in Routing

Comments


IPv6Freely (guest)
February 12, 2009 at 4:10 a.m. UTC

Hmm. I would have never thought of using the bandwidth command to make that work... but I guess that's just because I already knew about max-reserved-bandwidth... shrug


windexh8er (guest)
February 12, 2009 at 3:24 p.m. UTC

Nice, I haven't used the 'bandwidth' command to override any QoS stuff for a few years. The problem I had when using it, though, was in reverse. I had some Nokia PRI modems that only had Ethernet interfaces to them from the LAN side. Obviously the WAN speed was limited at far less than 10 or 100Mbps, so I had applied the bandwidth command at the Ethernet side of where QoS lived and also policed the outbound flow so as not to exceed the actual link speed... Hopefully nobody has the luxury of running into that situation any time soon though! :)


ron (guest)
February 12, 2009 at 5:37 p.m. UTC

more qos articles would be great! no more blog drama ;)


vsaltao (guest)
February 13, 2009 at 2:16 p.m. UTC

Very nice blog entry, i am digging now into qos and this tip will help a lot.


TMWalsh (guest)
February 14, 2009 at 9:18 p.m. UTC

Nice write-up, I was scratching my head at first because I was aware of the Max-Reserved-Bandwidth command from my QOS studies. This made me think however which is always a good thing. Hope the job hunting picks up fro you.


Joseph (guest)
February 15, 2009 at 8:06 a.m. UTC

Nice tip! Yes fudging the bandwidth statement to reflect more than is available can have some quirky side effects :)


Ryan (guest)
February 19, 2009 at 10:07 a.m. UTC

One other thing to note...

If you apply a QoS policy on a multilink, be sure that you consider the effect of one (or more) T1's going down.

For example, if you have two T1's multilinked together, and you have the following policy applied on the multilink...

policy-map VOIP
 class RTP
 priority 1544

What happens if one T1 goes down? Of course, the QoS policy becomes disabled on the interface because now your policy exceeds the maximum reservable bandwidth (since the multilink interface bandwidth has now decreased from 3Mb to 1.544Mb).

Perhaps a more appropriate configuration for this type of scenario would be...

policy-map VOIP
 class RTP
 priority percent 50

Just something to consider.


Xaviourz (guest)
February 24, 2009 at 3:34 a.m. UTC

Great article. More QoS article will be great.


Min (guest)
August 10, 2011 at 4:24 a.m. UTC

Thanks Jeremy, it's a very Good article. I realized that this is a article about 2 year ago. There are some changes to the "max-reserved-bandwidth" in newer IOS releases.

"Effective with Cisco IOS XE Release 2.6, Cisco IOS Release 15.0(1)S, and Cisco IOS Release 15.1(3)T, the max-reserved bandwidth command is hidden. "

"Effective with Cisco IOS XE Release 3.2S, the max-reserved bandwidth command is replaced by a modular QoS CLI (MQC) command (or sequence of MQC commands). "

From IOS XE Release 3.2S, the "max-reserved bandwidth" command has been replaced by following "MQC Command Sequence:

Router(config)# policy-map policy-map-name

Router(config-pmap)# class class-default

Router(config-pmap-c)# bandwidth {bandwidth-in-kbps | remaining percent percentage | percent percentage}

"

Have you got a chance to test how the new commands used?
Looks like it increases the bandwidth (as the way you described in the first part of your article) instead of modify the reserved bandwidth percentage.

Suggest you write up an follow-up article to further explain this new commands.


Ioan (guest)
November 17, 2011 at 8:54 a.m. UTC

I have not test or checked. However my understanding is that if bandwidth statement is used under class default the max-reserved-bandwidth is uselles. The default of max-reserved-bandwidth reserves 25% for class-default, so if bandwitdh is set for class default "max-reserved-bandwidth" will have no effect.


BR (guest)
December 23, 2011 at 2:06 p.m. UTC

Hello,

What If I have 80% EF Traffic and the circuit bandwidth is 100mbps. The interface is GigabiEthernet. Is it necessary to configure the max-reserved-bandwidth to 80??? Or is it ok If I max it out to 100?

max-reserved-bandwidth 80 or 100?

Even though I don't configure it It is still accepting the policy under interface.

Thank you!


Alex (guest)
January 6, 2012 at 4:57 a.m. UTC

Hi, good article. I understand that by default the 25% of bandwidth is to leave a bit of headroom for routing protocols and other critical traffic. But would "routing protocols and other critical traffic" fall into the class of class-default in the policy? So why bother?

Regards,
Alex


Jay (guest)
March 17, 2012 at 1:58 p.m. UTC

This is a wonderful forum. I have a question linking bandwidth and QoS:

if a customer has a CIR of 15Mb but want to be able to burst up to 100Mb when necessary, is the config below of ok:

)#policy-map SHAPE
     )#class class-default
           )#shape average 15000000 128000 100000000

)# int fa0/0
  )# speed 100
  )# duplex full
  )# bandwidth 100000
  )# service-policy out SHAPE

Thank you in anticipation of your response.


quang20082008
April 12, 2013 at 8:36 a.m. UTC

Useful topic. Thanks Jeremy.


Lalit (guest)
June 5, 2013 at 5:20 p.m. UTC

Hi Jay,

No. this configuration will not work.

At first, one needs to understand that the terms bc and be are Tc specific.
The maximum data that can be send in one Tc, i.e. bc + be = Access rate (here 100 mbps) * Tc

with CIR = 15000000 bps and bc = 128000 bits, then tc = bc/CIR = 8.533 ms = 9 ms approx.
so in this case the maximum value for be = 100000000 * .009 - 128000 = 772000 bits.

In fact, with shape average command one won't be able to send more than 15 mb of traffic in 1 second cycle.


Caicamina (guest)
July 4, 2014 at 7:16 a.m. UTC

Hi Jeremy,

I have a question:

In the formula BW Available= (BW * Max Reserv BW) - (Sum of all reserve), the "Max Reserv BW" for Cisco Interfaces is by default 75%.

If we use a virtual interface, for example, a service instance EVC, is the rule of 75% Max Reserv BW valid? Or we consider 100%?

Comments have closed for this article due to its age.