Under normal circumstances, EIGRP will divide the bandwidth of the physical interface by the number of EIGRP neighbors. Rene’s example shows how this can easily overwhelm such a network. So there are two solutions:
get rid of multipoint and use point to point subinterfaces, so the bandwidth of each subinterface will be used for the EIGRP bandwidth usage calculation, and this will be done on a per neighbor basis.
If you don’t want to get rid of the topology, then you must calculate the bandwidth that you should configure on the physical interface. The way to configure it is the following:
Take the PVC with the lowest CIR, multiply by the number of PVCs participating in EIGRP and use this as the bandwidth of the hub router. This is a different calculation than the one being described at the beginning. The first is done by the router, the second is done by the administrator.
I’m confused with the calculations for the Point-to-Point Scenario.
Just to quote:
256 kbps / 10 PVCs = 25 kbps for each PVC.
However each PVC has a bandwidth of 64 kbps so we should do something to make sure EIGRP can still use up to 50% of the available bandwidth.
50% of 64 kbps = 32 kbps.
By default, EIGRP will use up to 50% of the “interface” bandwidth. Since we know that each hub sub-interface has a 25 kbps bandwidth capacity, and the EIGRP will use up to 50% of the interface bandwidth, why are we working out 50% of the CIR 64 kbps? And not 50% of 25 kbps (the available bandwidth capacity per sub-interface)?
Quote:
“So when we configure it as 128%, EIGRP will be able to use up to 32 kbps.”
Why would we allow it to use up to 32 kbps when only 25 kbps is available?
There is a difference between the actual physical bandwidth, and the bandwidth parameter on each point to point sub-interface. In this particular case, the bandwidth parameter within each subinterface is automatically calculated to be the bandwidth parameter of the physical serial interface divided by the number of PVCs, which results in 25 kbps.
Now this bandwidth parameter does not affect the physical bandwidth of each PVC which is up to 64 kbps, so you can still achieve 64 kbps on one PVC, assuming that enough of the other PVCs are idle at that particular time.
Now EIGRP will by default take up to 50% of the available bandwidth, but what “bandwidth” are we talking about? The bandwidth parameter, and not that of the physical subinterface/PVC. But the bandwidth parameter is at 25, and the interface can achieve 64kbps.
Because the actual maximum available bandwidth is 64 kbps, and this is the reason why we modify the amount of bandwidth that EIGRP can use.
The truth is that the lesson doesn’t make it clear when it is talking about the physical bandwidth and when it is talking about the bandwidth parameter. I will ask Rene to clarify these terms in the lesson.
Typically, the bandwidth-percent feature is used for low bandwidth PVCs, with bandwidths on the order of several dozens of kilobits per second. Even the most intensive exchange of EIGRP information wouldn’t amount to more than 100 Kb/s unless you have an extremely large number of routes being exchanged using EIGRP, on the order of several thousand.
In the scenario that you are describing, the CIR for the HUB is 10 Mb/s, and that for the spokes is 1 Mb/s. I’m also assuming that you won’t have more than a dozen prefixes being exchanged between the EIGRP routers. For this reason, I don’t believe you will require the use of the EIGRP IP bandwidth-percent feature at all as these speeds are quite large compared to the amount of bandwidth you would expect EIGRP to use.