I’ve recently noticed that there seems to be some confusion
over the Cisco IOS bandwidth
statement. What does the bandwidth
statement really do? Is that really your bandwidth? Why is the bandwidth statement there? In this
article, I want to clear up the confusion with the Cisco IOS bandwidth command.

A common assumption

Someone recently asked me why their organization’s network wasn’t
getting the 4 Mbps of bandwidth from its Internet connection that they had
configured. When the person told me that they’re using a T1 circuit connection,
I clarified that it was a full T1, explaining that a T1 boasts a raw bandwidth
of 1.544 Mbps, full duplex.

The person countered that the router had a set bandwidth
statement of 4096, so the network should be getting 4 Mbps of bandwidth. Unfortunately,
it just doesn’t work that way. Let’s find out why.

The bandwidth
command’s real purpose

First, let’s discuss the real purpose of the bandwidth command. In the above
scenario, the questioning administrator didn’t understand the true purpose of
this command, incorrectly assuming instead that the network would receive the
bandwidth configured with the command.

The bandwidth
command is only there to communicate the speed of the interface to higher level
protocols. Most of the time, a routing protocol needs to know the speed of the
interface so it can choose the best route.

In the case of routing protocols, IGRP, EIGRP, and OSPF all
use the bandwidth statement. However,
TCP will also adjust its initial retransmission parameters based on the
bandwidth configured on the interface.

OSPF uses cost as its routing metric, which it calculates
using bandwidth. For example, OSPF takes 108
and divides it by the bandwidth of the interface. To calculate the cost of a
full T1, OSPF divides 100,000,000 by 1,544,000, which returns an OSPF cost of
64. (Cisco routers don’t use floating-point math, so they drop the numbers
after the decimal.)

On the other hand, EIGRP uses the bandwidth of the link to
calculate its routing metric. Here’s the EIGRP metric formula:

metric = [K1*bandwidth + (K2*bandwidth)/(256 - load) 
+ K3*delay] * [K5/(reliability + K4)]

We won’t try to calculate a metric in this article, but as
you can see, the process definitely requires using bandwidth. In fact, due to
the default K values, the only values used to calculate the EIGRP metric are
bandwidth and delay.


You configure the Cisco IOS bandwidth command on interfaces. Here’s an example:

interface Serial0/0
 bandwidth 128
 ip address

This command has only one option—the bandwidth, in kilobits,
of the interface.

Router(config-if)# bandwidth ?
 <1-10000000> Bandwidth in kilobits

There are always default bandwidth values set for each type
of interface, such as the Serial interface, as shown below:

Router# show interface s0/0
Serial0/0 is administratively down, line protocol is down 
 Hardware is PowerQUICC Serial
 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,

In the case of a serial interface, the default bandwidth is
1,544 K (or a full T1 circuit). However, you could have a fractional T1 circuit,
and the default may be incorrect.

As you can see, setting the correct bandwidth on each
interface is very important when it comes to routing protocols choosing the
right router. However, no matter what you set the bandwidth command to, you won’t actually get faster throughput out
of any interface—the two simply aren’t related.

For more information, check out Cisco’s bandwidth command documentation and Cisco’s Setting
Bandwidth reference

How familiar are you with Cisco’s bandwidth command? Has this helped clear up any confusion? Share
your experiences and questions in this article’s discussion.

Miss a column?

Check out the Cisco Routers and Switches
, and catch up on David Davis’ most recent columns.

Want to learn more
about router and switch management? Automatically
sign up for our free Cisco Routers and Switches newsletter
, delivered each

David Davis has worked
in the IT industry for 12 years and holds several certifications, including
CCIE, MCSE+I, CISSP, CCNA, CCDA, and CCNP. He currently manages a group of
systems/network administrators for a privately owned retail company and
performs networking/systems consulting on a part-time basis.

Subscribe to the Developer Insider Newsletter

From the hottest programming languages to commentary on the Linux OS, get the developer and open source news and tips you need to know. Delivered Tuesdays and Thursdays

Subscribe to the Developer Insider Newsletter

From the hottest programming languages to commentary on the Linux OS, get the developer and open source news and tips you need to know. Delivered Tuesdays and Thursdays