This topic is to discuss the following lesson:
based on the previous lessons, i thought the bandwidth command doesn’t do anything except it only affects the routing protocols best path decision like EIGRP and OSPF?
Hi John,
That’s right and still true. We use the bandwidth command so it reflects the actual bandwidth of the interface, it doesn’t influence the actual bandwidth. Routing protocols like OSPF or EIGRP use the bandwidth for their metric calculation.
Rene
Another question, on point-to-point scenario, what if our hub router had 1024kbps bandwidth, and we have 10 spoke routers that each have 64kbps. so 64x10 = 640kbps. which is 640kbps is less than 1024kbps. If this is our case, do we still need the “ip bandwidth-percent eigrp” command?
also what if our hub router is equals to the sum of bandwidth of 10 spoke routers?
hub router bandwidth = 640kbps
Sum of bandwidth of 10 spoke routers = 640kbps
do we still need to config this?
thanks rene! i just want to make things clear if this 2 scenario will happen.
Hi John,
If the hub had 1024 kbps then it would provision 102.4 kbps for each PVC. EIGRP can use up to 50% of that so that’s 51.2 kbps.
The spokes only have 64 kbps, 50% of that is 32 kbps. I would use the IP bandwidth-percent eigrp command so that the hub also uses no more than 32 kbps for EIGRP.
32 / 102.4 * 100 = about 31% so that’s what I could configure on the hub.
If the bandwidth of the hub is 640 kbps then it will provision 64 kbps for each spoke. There’s no need to use the ip bandwidth-percent eigrp command now.
Don’t forget to use the “regular” bandwidth command though, normally a serial interface is seen as a T1 interface which is 1.544 Mbit.
Rene
so i will retain the 1024kbps on the hub. and i will configure the Hub and Spoke router with “ip bandwidth-percent eigrp 1 31”
and also what will be the bandwidth of the spoke routers? on your example, you input bandwidth 25, which you get by dividing the bandwidth of hub to 10 spokes.
You only have to set it to 31% on the hub so it will use a maximum of ~32 kbps of EIGRP traffic. The spokes are fine, their default is 50% of 64 kbps which is 32 kbps.
The bandwidth of the spokes will be 64 kbps (their CIR rate).
In my example above, the 10 spokes exceed the bandwidth of the hub.
Hi Rene,
in multipoint:
Hub(config)#interface serial 0/0
Hub(config-if)#bandwidth 256
Do we also have to set the 4 spokes with a CIR of 64 kbps each?
Does it mean that PVC 3: CIR 256 kbps will become 64 kbps and will only be using a maximum of 32 kbps for EIGRP traffic?
Thanks
Hi Andrea,
You might want to do this yes so that the spokes are unable to overburden the hub router with EIGRP traffic.
It’s no problem to set the bandwidth to 64 kbps, this means EIGRP only gets 32 kbps (50%) of traffic. The PVC still has a CIR of 256 kbps, the bandwidth command doesn’t change this. It only affects the bandwidth that EIGRP can use.
Rene
Hi.
In the example with 10 spokes you only set the bandwidth on the physical interface, and not on sub interfaces. the ip bandwidth-percent was applied to the sub interfaces, but the sub interfaces have a default bandwidth of 1544 kbps. Which bandwidth would the ip bandwidth-percent command use?, the sub interface one or the physical one (divided between the total number of spokes)?
(sorry about my English, it’s not good enough)
Jaime,
By default, if a bandwidth command is not specifically entered for a sub-interface, then that sub-interface inherits the bandwidth from the parent interface (not defaulting to 1544). So in this case, it doesn’t matter whether a bandwidth command was entered for the sub-interface.
1 Like
Hi Rene,
What is the best order of approach for bandwidth-percent for use with point-to-point interfaces?
My example is:
1 hub router with a 256kbps interface.
6 spoke routers, each having a 64kbps VC.
- When the hub router attempts to communicate with all spoke routers at the same time at full capacity = 64kbps X 6 = 360kbps.
360kbps is more than the 256kbps on our interface. Start with the hub router, divide the bandwidth of 256kbps by our 6 links to give us 42kbps per VC.
QUESTION: The 42kbps is way short of the 64kbps per link, before even considering EIGRP!
EIGRP will use up to 50% of the 42kbps - 21kbps.
We have a solution for ensuring that EIGRP utilises more of the VC, but what about when the link is under utilised even before considering the impact of EIGRP traffic?
Bit confused. I understand why we would need to set the hub bandwidth to 42kbps to avoid the 360kbps vs. 256kbps situation, but it massively under utilises the links?
I think I must be missing an obvious point somewhere.
Thanks.
Hi James,
First of all, keep in mind that the bandwidth command doesn’t affect the actual bandwidth of the interface. It is only used as the input for things like QoS or routing protocols like EIGRP to calculate the metric. We also use it in this example to figure out how much bandwidth EIGRP can use. In a scenario like this, you want to make sure that EIGRP doesn’t use more than X% of the bandwidth that you have.
With 6 spoke routers, you would have 256 kbps / 6 = 42 kbps per PVC. The actual PVC offers 64 kbps.
If we want to configure EIGRP so that it can still use 50% of the bandwidth, then we can do it like this:
32 kbps / 42 kbps * 100 = 76%
So when we configure it as 76%, EIGRP will be able to use up to 32 kbps.
Hub(config)#interface serial 0/0
Hub(config-if)#bandwidth 256
Hub(config)#interface serial 0/0.1 point-to-point
Hub(config-subif)#ip bandwidth-percent eigrp 1 76
Hub(config)#interface serial 0/0.2 point-to-point
Hub(config-subif)#ip bandwidth-percent eigrp 1 76
Hub(config)#interface serial 0/0.3 point-to-point
Hub(config-subif)#ip bandwidth-percent eigrp 1 76
Does this help?
Rene
1 Like
Hi Rene,
I am confused with multipoint scenario.
-
“When you run EIGRP over a frame-relay multipoint network then EIGRP will divide the bandwidth of the physical interface by the number of EIGRP neighbors.” Let’s assume that we have hub router with physical bandwith of 1544kbps and 4 neighbors, so 1544/4 =386. Is this correct that maximum CIR on our PVCs can’t be greater then this value?
-
In your scenario you configured only a hub router with bandwidth 256 subint command. That’s how I see it: Spoke 3 with CIR 256kbps on PVC3 still will be sending EIGRP traffic up to 128kbps(256/2), but on the hub router there will be a queue with eigrp traffic, since it can only send 256/4 * 50%=32kbps. Am I correct?
Hello Artem
First of all, in this lesson, we are talking ONLY about the traffic that EIGRP generates in order to maintain routing and topology tables on the routers participating in EIGRP. That is, hello, update, query request and reply packets. We are not talking about the traffic that is generated by users on the network and their applications.
As stated in the lesson, EIGRP will use up to 50% of the bandwidth of a link. The bandwidth that EIGRP always uses to gauge “how much is 50%” is the bandwidth parameter of the physical interface, NOT the actual physical throughput available. In a point to point situation, if the interface is configured with a bandwidth parameter of 1.544Mbps for example, then up to half of that (772Kbps) will be available to be used by EIGRP at any time. In a multipoint topology however, the question is how do we calculate 50%? 50% of what?
When stating that “EIGRP will divide the bandwidth of the physical interface by the number of EIGRP neighbours” we are essentially saying that whatever is configured as the bandwidth parameter on the physical interface, we take that and divide it by the number of spokes in the topology. So if we have 1544 Kbps as you stated, the resulting number is 386Kbps. This means that EIGRP will use up to 386Kbps/2 = 193Kbps for each spoke for EIGRP traffic.
Now, what Rene is saying in the lesson is that this is often still too large for EIGRP traffic going from spoke to spoke, especially if you have varying CIRs on each spoke. So in order to make sure that the EIGRP traffic will not overwhelm your links, it is a good idea to limit all EIGRP traffic to half of the smallest CIR available on your spokes. This way, no link will be overwhelmed.
In order to do this, take the smallest CIR and multiply by the number of spokes. That is, 64Kbps*4 = 256Kbps. Configure this as the bandwidth parameter of your physical interface on your hub. The result will be that EIGRP will not use more than half of each spoke’s available bandwidth.
How much is that? Well we start off with the physical bandwidth configured on the hub which is 256Kbps. Divide that by the number of spokes (4) and we get 64Kbps. EIGRP will not use more than 50% of this value, that is 32Kbps, so none of the four spokes nor the hub link will be overwhelmed with this setup.
I hope this has been helpful!
Laz
,
1 Like
Thanks a lot, Laz! Now it’s clear to me.
2 Likes
Hi Lazaros,
Would you please explain Non-broadcast multi access.
Hi @mrayubzada,
I’m not Laz but I can try to explain it to you quickly.
The Term Non-broadcast multi access (in short NBMA) refers to a network in which neither Broadcast nor Multicast is Supported.
Like Rene explained in the beginning of this Lesson Frame-Relay is an example as it just mimics broadcast and multicast traffic by sending a copy of the original frame from the originating PVC to all other PVCs.
Best regards,
Marcel
1 Like
Hi together,
Does EIGRP Bandwidth Percent get calculated like that:
[Documented_Bandwidth / PVCs] * [Bandwidth-% / 100]
Or does EIGRP calculate it like this:
[Documented_Bandwidth / EIGRP_Neighbors] * [Bandwidth-% /100 ?
In the Notes of that lesson there was a point that it uses EIGRP-Neighbors but at the beginning of that lesson it looked like it’s dependent on the number of PVCs
Best regards,
Marcel