EIGRP bandwidth recap help

[Andy White]

Hello,

I've created a simple EIGEP lab network in GNS3 so I can understand the routing and topology tables better.  Every router can ping each other, but I have yet to add loop backs as this may confuse things further for me.  I have been trying to influence the path from R1 to R5 by using the 'bandwidth' command on the serial interfaces on R1 to change the path thus the successors and feasable successors, but the bandwidth command seems to make no difference to the routing table or topology table, should I be using something else to influence the eigrp paths?  I want to make some links 256kbps and some T1 lines and see what happens.  Does the clock rate come into play?

Thanks

[Peter Paluch]

Hello Andy,

First of all - you are saying you want to play with the FD (Feasible Distance)? There is a common misunderstanding about this term. The FD is not the current metric to a particular destination, contrary to the popular belief. In reality, the FD is a record of the historically lowest metric to a destination since the last time the destination went from Active to Passive state. Because your actual distance may have increased since the Active->Passive transition but in such a way that you have never lost your successor or feasible successor, the FD will stay the same although the current, actual distance will change.

These are some of numerous threads where I tried to explain it:

https://supportforums.cisco.com/message/3449507#3449507

https://supportforums.cisco.com/message/3882959#3882959

Perhaps that will be a good reading.

Second, you are saying that you are using the bandwidth argument to influence the best path selection. Can you be more specific how are the bandwidths configured? Perhaps there is an issue with the fact that EIGRP uses the minimum bandwidth along the path towards the destination, so increasing the bandwidth at some point in the network while the bottleneck along the path stays the same will not lead to any modification in the best path.

In addition, the bandwidth shall not be used to influence EIGRP path selection because of three primary reasons:

• Another IOS mechanisms, including QoS tools, use the bandwidth setting for their own computations. If the bandwidth setting is skewed, so will be the computation result of these mechanisms
• Because EIGRP takes the smallest banwidth along the path to the destination into account, increasing the bandwidth on an interface may not result into any change in the best path selection because of slower links somewhere further along the path.
• EIGRP has the right to allocate as much as 50% of configured bandwidth on an interface for its own traffic. If the bandwidth setting is incorrect, it may either lead to choking the EIGRP communication or to saturating the interface, in both cases introducing instability.

Instead of the bandwidth command, you should use the delay command to manipulate EIGRP metrics. The delay is a cumulative value so it behaves in a completely natural way, and it has no other effects beyond EIGRP metric calculation.

Please feel welcome to ask further!

Best regards,

Peter

[Andy White]

I used the bandwidth command only on the interfaces between R1 <> R2 and R1 <> R3, so all other links were kept at their default which I think is 1544kbps?  Under the serial interfaces I just used bandwidth 512000 to lower the speed (well that's what I thought).

I have been watching EIGRP lab videos and their topology labs show different speeds on their links so I what to understand this, but it has shown be that it isn't straight forward.

You mention using the delay which I believe is the 3rd K metric value?  I think the default is 1 like the bandwidth, so would it be normal to raise this to say 2 for slow links and 3 for very slow links?

Thanks again for your detailed replies.

Kindest Regards