Would Half-Duplex factor into EIGRP route selection?

genewolfe · ‎11-08-2009

I had an issue where EIGRP was choosing to route all traffic over a T1 instead of a 10 Mbit circuit. When I changed the router's ethernet interface connected to the 10 Mbit circuit from Half Duplex to Full Duplex the routes changed to use the 10 Mbit circuit. I looked through the EIGRP metrics and I don't see where that would factor into the calculation of choosing a route. The T1 route and 10 Mbit route are both going to the same router, same number of hops, same delay, only the T1 is much slower than the 10 Mbit circuit and yet EIGRP on the router chose the T1. Would the interface being set to Half Duplex cause EIGRP to choose a T1 over a 10 Mbit circuit? I tested this on equipment at home and EIGRP always chooses the route with the fastest configured bandwidth even if the interface is set to Half Duplex. Would Half Duplex cause this in some situations? Does anyone have any clues as to why the above might occur?

Thanks in advance.

Giuseppe Larosa · ‎11-08-2009

Hello Gene,

generally speaking half-duplex settings shouldn't influence EIGRP metric calculation.

>> I tested this on equipment at home and EIGRP always chooses the route with the fastest configured bandwidth even if the interface is set to Half Duplex.

this is what is expected

only possible explanation that the change of duplex may have triggered an EIGRP recalculation and that EIGRP was stucked.

Hope to help

Giuseppe

Richard Burts · ‎11-09-2009

Gene

You mention that you changed your interface from half duplex to full duplex. But you do not mention if you also changed the interface of the other router connected to your router on the Ethernet interface. So it leads me to wonder if there might have been a duplex mismatch between your router and the other router. If there is a duplex mismatch, then the result is many dropped packets (because the device at half duplex is sensing many collisions where the other device is sending while recieving). I wonder if the duplex mismatch was dropping enough EIGRP protocol messages (like HELLOs) to prevent a successful neighbor relationship. And changing your router interface resolved that issue. Is this possible?

HTH

Rick

HTH

Rick

genewolfe · ‎11-09-2009

Thanks for this suggestion.

The connection went from this router, into a cloud, into another router. I didn't know what was in the cloud until today but I did know after looking into it all the other customer interfaces were manually set to full duplex, 100 Mbit which is why I changed this one odd interface which was set to auto/auto and for some reason ended up auto negotiating to half duplex.

I talked to the cloud provider today and received a copy of their provisioning documents which state the customer router interfaces should be manually set to full duplex, 100 Mbit so the provider equipment and all of the other customer equipment was manually set to full duplex, 100 Mbit.

I tested this in my lab and EIGRP still chose the 10 Mbit route but my lab has different equipment and may not behave the way the network in question did.

Richard Burts · ‎11-09-2009

Gene

If your router was configured for auto negotiation of duplex and the provider router was configured to hard set the duples, the your router attempt to negotiate duplex would fail. And when the attempt to negotiate duplex is not successful then the fall back solution is to set the interface for half duplex.

If your router falls back to half duplex and the provider router is set for full duplex, then this does produce a mismatch of duplex. And your router interface should see lots of collisions, a good number of late collisions, and runts. The bottom line is that your router would discard quite a few frames sent from the provider router. So my theory that the discarded frames might impact the EIGRP neighbor relationship is plausible.

HTH

Rick

HTH

Rick

genewolfe · ‎11-11-2009

Interesting.

I went back and looked at some historical show interface output and there was almost no traffic on that 10Mbit interface and to my surprise there were 0 collisions, 0 late collisions, and 0 runts.

Perhaps your theory occurred at one point when the interface was brought up and by the time I looked at the interface it hadn't been in use and the counters had been reset.