Cisco: Speed vs Bandwidth interface command

It’s not uncommon to see people making mistake about the two interface commands speed and bandwidth. Most of the young engineers ( and not only ) assume that bandwidth and speed have the same meaning when applied under the interface and that purpose is to reduce the throughput of the interface up to the limit specified by bandwidth or speed.

Well this cannot be more wrong. The two commands are not doing at all throughput limitation and their scope is totally different. Let’s analyze them a little bit:


What is saying about it:

To set the inherited and received bandwidth values for an interface, use the bandwidth command in interface configuration mode. To restore the default values, use the no form of this command.

bandwidth {kbps | inherit [kbps] | receive[kbps]}

no bandwidth {kbps | inherit [kbps] | receive[kbps]}

Now for the explanation. Bandwidth command is an optional, but most of the time, recommend interface command. Despite the word, it is not there to limit the bandwidth and you cannot adjust the actual bandwidth of an interface using this command.The interface bandwidth command is used  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. Another effect of this command is that  TCP will adjust its initial retransmission parameters based on the bandwidth configured on the interface.

I’m sure that you are familiar or at least heard about the dynamic routing protocols like OSPF and EIGRP or at least you heard of it. Now, OSPF and EIGRP in particular use the interface bandwidth to calculate metrics.  I will not go into mathematics calculation of metrics for OSPF and EIGRP, but rather explain it in human terms. Imagine that you have 100Mbps interfaces connecting two routers, with 2 connection in parallel (2 x 100Mbps interface / router)  over provider network. The provider is limiting your actual bandwidth to 10Mbps on one connection and to 1 Mbps over the other connection. You run OSPF or EIGRP over this connection.  If you don’t specified the accurate bandwidth on each connection, OSPF or EIGRP will calculate the metrics based on the default interface speed (100Mbps). From their point fo view both lines are equal, you have equal metric and you can run on the problem that the routers will push packets on both lines, but one line will have a higher throughput, so the packet will arrive at destination out-of-order.

If you specify the bandwidth command under the 100Mbps interface (bandwidth 10000 and bandwidth 1000) then IP routing protocols will sense the difference and the 10Mbps line will be more prefered than 1Mbps line.


What is saying about it:

To configure the speed for a Fast Ethernet or Gigabit Ethernet interface, use the speed command in interface configuration mode. To return to the default setting, use the no form of this command.

speed {10 | 100 | 1000 [negotiate] | auto [speed-list]}

no speed

Speed command explanation is actual much more simplest than bandwidth. Some interface (hardware dependent) allow you to set the speed. So, even if the interface is a 100Mbps you can set it to 10Mbps. That means that the interface is transmitting packets on up to 10Mbps.  You will ask me now, probably, OK, then if we set the interface speed to 10Mbps,  this will not tell the OSPF / EIGRP to calculate the metrics based on this value. Of course, yes. But what will you do when there is another value than standard 10Mbps or 100Mbps for the speed command. Like 1Mbps. You cannot set speed 1. Or if you have a hardware card which does not support speed slower than 1Gbps? That’s why you use the bandwidth command to tell the upper protocols the actual interface capability of throughput.

Speed command is also important, as it has to be the same on both ends of the connection. It can auto-negotiate is true, but sometimes it fail and when speed auto-negotiation fails, it default to 10Mbps half-duplex. You know what duplex is, don’t you? Well, imagine that your interfaces are 100Mbps full-duplex capable, but due to auto-negotiation failure, you will transmit at 10Mbps and half-duplex (only one packet in a direction at the time on the wire). That will be a huge drawback in your network capacity. If you have doubts about your device auto-negotiation capability, better hardcode there speed and duplex for to enjoy your night sleep.

I hope you understood the differences between speed and bandwidth interface command and I was clear in my explanation. If not, there are always comments for. Just ask me.

Published by


Calin is a network engineer, with more than 20 years of experience in designing, installing, troubleshooting, and maintaining large enterprise WAN and LAN networks.

17 thoughts on “Cisco: Speed vs Bandwidth interface command”

  1. ok Mr.CALIN , thank you
    but i want to make sure that i did understand , (sorry for bad english)
    speed command : will set the actual speed of an interface to 10 or 100 or auto >> right ?
    bw command : will tell the eigrp or ospf process about what the interface speed that we want thay to think , so we will be able to control metrics and best routes choosing, without affecting the real speed of the interface >> right ?
    the following part is a part of your explination i didn’t understand it properly , so if you can re-explain it by different way please ?
    “” You will ask me now, probably, OK, then if we set the interface speed to 10Mbps, this will not tell the OSPF / EIGRP to calculate the metrics based on this value. Of course, yes. But what will you do when there is another value than standard 10Mbps or 100Mbps for the speed command. Like 1Mbps. You cannot set speed 1. Or if you have a hardware card which does not support speed slower than 1Gbps? “””
    thank you again

    1. Basically you understand everything correctly. In more simple words, the SPEED command has to do more with the physical part of the connections (the wires) and it’s used when the auto-negotiation (for example) is not supported. Example: you have a 100Mbps interface, the other end has 10Mbps, auto-negotiation is not supported, so you configure your interface with speed 10, to be able to communicate with the opposite end. Think at the speed more like the access rate of an interface. Will it influence routing protocol? Yes.
      Bandwidth is more like CIR in terms of QoS and is used to set the bandwidth allocated to you by provider. It’s more to be set on WAN or Metro interfaces. Or, of course, if you want to manipulate IGP (that consider bandwidth for metric calculation) in LAN. Think of the bandwidth command as following. You have a 100Mbps interface, but your provider offers you a CIR of 2Mbps, then you configured the bandwidth command for 2Mbps.
      SPEED is taking care of industry defined standard values (10,100…).You should see this as the hardware portion. BANDWIDTH is more for logical part, think of like the software part.
      I hope you understand my explanation. If not come back and we can have a chat on this topic.

    2. thank you yotis
      i have a some points to discuss of your reply :
      1- when you said ” Will it influence routing protocol? Yes. ”
      we had reached an understanding that the routing protocols will be affected by bandwidth command , so why you now said that the speed will influence routing protocols ???
      2- also in your example : ” You have a 100Mbps interface, but your provider offers you a CIR of 2Mbps, then you configured the bandwidth command for 2Mbps “”
      my questions here :
      a- if i didn’t configure the interface with bandwidth command of 2 mbps , what will be happens in this case ?
      b- is this right : we use the bandwidth command in this case because the speed command doesn’t offer the value of 2 mbps , (its offer either 10 or 100 or auto ) , am i right ??
      if i am right , so if the provider offers you a CIR of 10Mbps , you will be able to use the speed command in this case , right ????
      thank you …

  2. yotis, I think your explanation to the main article makes it more confusing…. Bandwidth is for routing metrics in the Main article but Bandwidth is for speed shaping in your additional explanation…

    1. Hello Vlad,

      “Additional explanation”… what do you refer by additional explanation? I cannot find the words “speed shaping” in my explanation.

      Sorry if you find this more confusing.

      For me Bandwidth is used to communicate the “speed” (line access capacity) of the interface to the upper layer protocols (like OSPF). It’s related only to software part and has nothing to do with the physical interface speed.

      Speed on the other hand is used to reflect the physical port “speed”, like for speed / duplex negotiation on the.

      Let’s take OSPF. OSPF derives it’s link cost from the interface bandwidth. If the “bandwidth” command is not there, it will assume that the available bandwidth is the interface speed (
      Nevertheless, this is not always true, because the interface may be 1 Gbps (speed) and the actual available bandwidth is only 100Mbps (bandwidth). If you do not specify the “bandwidth” command, OSPF will calculate link cost on using 1 Gbps reference (

    2. OK. I’m just googling for a possibility to shape our bandwidth by cisco hardware. We are getting 100Mbt Internet, and I’m thinking how to divide it on 2 subnets (50/50Mbt or 30/70Mbt/s), so I came across these 2 commands…I’m CCNA and I’m aware of routing metrics but I don’t have knowledge about rate limiting (not a 10/100/1000 half/full duplex)…

    3. These commands are not the way to go for what you want…
      You maybe be able to do prioritization of traffic using marking or packet match based on the source subnets.

      You can try also some PBR if you are dual-home connected.

      Three are more than just one solution, but depend mostly of your existing infrastructure and configuration.

  3. Bandwidth command is also useful for the below case.

    You have 10G interface between two switches and you have a vlan SVI between these switches for routing. By default interface svi , bandwidth is 1Gbps. OSPF will not reflect on the 10G underlying physical interface , but calculated based on the SVI interface bw.

    Also, SNMP OIDs will show you are exceeding the BW if it crosses 1Gbps. But in reality you have 10G underlying BW. Here to fix the issue, bandwidth command is used under interface vlan.

  4. thanks man..also ISPs like to fool people by playing with the words bandwidth/speed interchangeably when we talk about internet..i have a post about this on my blog

  5. Yotis did give good info, but yes, other commenters are correct that he also gave contradictory/confusing statements.

    A cisco router (depending on the router) will allow you to adjust the “speed” of an interface. On a fastethernet interface, the only options for speed that i’m aware of are to configure the interface speed for 10 or 100. The “speed” is the physical capacity for sending traffic onto the wire. But what happens if you lease a 50Mb circuit from your ISP? You will always want to set your speed either equal or higher than the bandwidth that your isp is providing to you. But if you set your router to “speed” 100, you risk sending too much traffic too quickly to the isp, and the isp will drop the excess traffic above 50Mb. So what you do in this case is you create a “policy map” and “shape” the traffic for 50Mb and you apply it to your interface facing the isp.

    So far everything that I am speaking of has nothing to do with the “bandwidth” command. The “bandwidth” command does NOT rate limit your traffic. A “Policy Map” command will do that for you.

    Let’s say though that you have a 50Mb circuit, you are going to set your “speed” to 100 and then apply a “policy map” to rate limit your traffic down to 50Mb. But applying a “policy map” specifically to rate limit your traffic is NOT going to let your routing protocol (e.g. ospf or eigrp) know that your circuit is actually only 50Mb. Further, if you have a fastethernet interface, the default for the “bandwidth” command is going to be 100mb. So by default your “bandwidth” statement is set to 100, But if you only have a 50Mb circuit (or 30Mb or 10 or 5, etc), you will want to adjust your “bandwidth” statement to 50mb, so your routing protocols will actually know what speed you are using, so your routing protocol can correctly calculate the metric/cost for that link and route your traffic accordingly.

    Higher protocols (eigrp, ospf, tcp) look to the “bandwidth” value for their guidance on how to do their job. They don’t use the “speed” value, because there are not enough “speed” options (only 10 or 100 on a fastethernet interface) to choose from to accurately reflect what your actual physical speed is.

    Lastly, a lot of people forget to use a policy map to actually rate limit their traffic and later they complain that their connection is slow or they are seeing retransmissions (because their isp is dropping their excess traffic)- I know all this, because managing the Provider and Customer Edge routers use to be my job at a major isp.

  6. If my router supports only 1 Gigabit Ethernet SFP and is connected to service provider router and the service provider is providing bandwidth is 100Mbps WAN link; In this case eventhough my spped on the Giagbit interface router is set to 1000Mbps, but my bandwidth will be set to 100Mbps? Is my understanding correct ?

    1. Do you use any dynamic routing protocols that may take advantage of the bandwidth command? Otherwise, will not make much of a difference…

  7. My carrier has my port speed set at 500M, but the bandwidth is 1000M. What are the advantages and drawbacks of this scenario?

    1. Nick, how would that work? I mean if the port is limited at 500M, you can type whatever you want on the bandwidth command…this will just mess up the dynamic routing protocols if you use any. And just for the record, what you say is a bit confusing. It like the provider connected me via a 100M port and sells me 1000M bandwidth (aka. QoS CAR)

Any opinion on this post? Please let me know:

This site uses Akismet to reduce spam. Learn how your comment data is processed.