I can't explain this behaviour and I'm hoping someone can elighten me on this. I have an eigrp environment with multiple paths to various offices. In one office a route was being advertised to it e.g 10.33.1.0/24 via eigrp through two circuits, once the redundant link was activated the path through it for destinations to 10.33.1.0/24 incremented by 180ms. This redundnant line is a dedicated line that has other traffic flowing through it with 1ms latency, suddenly just for the route 10.33.1.0/24 the latency jumps up to 180ms.
Looking deeper I found a static route on the router advertising the route 10.33.1.0 out through the redundant link, as soon as I removed it latency through that link traffic destined for 10.33.1.0/24 dropped to 1ms. Can someone please explain why this happened?
Thanks for the reply. Let's say I have link1 and link2 running eigrp on both links. For subnet 10.33.1.0/24 link1-destination is the best route as determined by eigrp, however on failure of link1 traffic for the above subnet was routed via link2. Link2 is routed like: source-link2-site2-link3-destination. The router at site 2 had a static route stating:
ip route 10.33.1.0 255.255.255.0 10.30.8.1 (destination router). This same route was being learned at site2 via eigrp from the destination router. The static route added a latency of 180ms when pinging from source to destination. As soon as I removed the static route at site2 and only allowed eigrp to decide the routing the latency dropped to 1ms when doing the same ping. Traceroute confirms that on both occassions (static and via eigrp) the exact same route was taken from source to destination
cisco WS-C6509-E (R7000) processor (revision 1.2) with 458720K/65536K bytes of memory
Let me know if you need more info.
The 180 ms comes in between step 3 (3750) switch and the 6509 switch (destination). If I put the static route on the 3750 switch the latency between the two hops increases to 180ms. If I take it out and let EIGRP do it's work it drops to 180ms. The link between the two is a Gig link.
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 custome...