I am running eigrp. My question is, access switch a seems to load balancing between links to 3750_A and 3750_B to reach the outside world whereas it should only go through 3750_B since it has 1 gb link, isnt it ?
if i do a sh ip route 0.0.0.0 - i see equal metrics (FD) on both routes and hence eigrp seems to load balance
Regarding the terminology, the current metric and the Feasible Distance are not the same thing. What you see in show ip route is the current metric. The FD can be identical or lower to the current metric, as it is the record of the lowest metric towards a destination since the last Active->Passive transition. We are talking about current metrics here.
We need more information from your access switch to diagnose the problem. Please post the output of the following commands:
What i have found is eigrp seems to calculate the same cost or FD for the 100 mb link and 1 gb link as i see the FD is the same value (so the problem lies even before Nexus switches - lies between access sw and 3750_A and 3750_B).
Do i have to enable any command in eigrp to make it understand its 100 mb link (for instantce in ospf i know the cost is 1 for anything over 100 mb).
this is most likely because of what I said in my previous post. If you want to make one path more prefered, try to change the delay value. Best practice is, to make the unpreferred path worse (increasing the delay parameter).
Jan is correct. EIGRP does take the speed of links into account but in contrast to OSPF, it does not sum together the link costs, rather, it always takes the lowest-speed link along the path towards the destination into account, and uses that value to compute the resulting metric (in effect, it uses the bottleneck speed to compute the resulting metric). If the default route is already advertised with the bottleneck speed of 100Mbps from your 3750 switches, the link of 1Gbps is not going to influence the bottleneck speed in any way (it is not lower than the bottleneck speed). So from the viewpoint of your access switch, both paths are equal because the maximum reachable speed over both paths is identical.
As Jan suggested, you should modify the delay parameter to make one path more preferred if necessary. The delay is an interface-level parameter that is computed into EIGRP metric, and is cumulative (i.e. its value is added to the existing total value in the EIGRP advertisement before computing the resulting metric). You may want to increase the delay parameter on the 100Mbps interface to a higher value, say 1000 or 10000 to make the path over the 100Mbps link less preferred.
After modifying the setting, allow for 10-15 seconds to EIGRP to take notice of the metric change.
In addition to Peter's post I would like to point out that the bandwidth parameter which is included into EIGRP metrics is NOT cummulative and it refers to the least value from the whole path. So maybe there is a bandwidth bottleneck of 100Mbit (or lower) elsewhere along the path. Maybe it got there in the process of redistribution by using seeding metrics of 100Mbit for the bandwidth value. Just an idea.
it was a problem on the vlan - the metrics were different on the VLAN than to the one on the actual interface
so if you were to do show inter gi0/1 and show int vlan 100 - then you would see the difference in value for bandwidth and delay. so for some reason eigrp was using the actual interface and not the vlan values. so even though the vlan vlaue were showing correct as BW 100000 and DLY 100 sec, the actual interface was showing as BW 1000000 and DLY 10 sec and eigrp was using actual interface values.
so i went on the vlan inteface and changed the values and this sorted the routing
This is not surprising. EIGRP takes only the metrics of the IP interface, in your case, the interface VLAN into account. EIGRP does not see the individual switchports in the corresponding VLAN and can not use their bandwidths or delays. This is a general rule: routing protocols will only take into account the metrics of Layer3 IP interfaces they operate over. They will never take the Layer2 interface characteristics into account because they assume they have been reflected into the metrics of L3 IP interfaces.
This is actually a very nice story to remember: that when running EIGRP (or OSPF or ISIS) in a multilayer switched environment, the metrics used by these protocols will be those from interface VLAN and no switchport routed ports only. Metrics configured on Layer2 switchports will have no effect.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...