Strange routing issue

[Amafsha1]

Hello, I've run into a strange issue that I can't wrap my head around.  This issue is not causing any impact, but I don't quite understand it.

If you look at the picture, that is what the network looks like.  

On core 1 of Datacenter 1, when I do a traceoroute to a branch transit ip address(public ip address of /30s that connect up the branches to ISP 65.100.x.x) the traceroute  goes for some reason through the 10gig metro-e circuit, to datacneter2, then out to the  MPLS Wan Router over there.  But when I do traceroute from the other core 2 on datacenter 1, it goes straight down to the WAN router of datacenter 1 and to the MPLS...which is how we would obviously want it since it's a shorter and more optimal path.  Would anyone know why Core 1 would act differently in the traceroute by taking the long way?  What makes it even more hard to understand is when I do "sh ip route 65.100.x.x" on both cores1/2 on datacenter 1, the routing table shows them both to go to the same place...which is the MPLS WAN router in Datacenter 1....which is the right place...yet the traceroute off core 1 tells a different story.  I'm confused by this. 

The pink arrows in the picture are the weird core 1 traceroute, the orange arrow are the logical core 2 traceroute.  

[Georg Pauwen]

Hello,

hard to tell without knowing more about your topology. Can you post the configs of both core1 and core2 routers ?

[Amafsha1]

Thank you.  

[Amafsha1]

Just found something kind of weird...maybe it's not, but the way the eigrp neighborships are setup.

I have attached a picture of what the eigrp neghobrsihp toplogy looks like.

Blue lines are eigrp neighbors.

Red lines are not.

[paul driver · Accepted solution]

Hello

How is DC1 core2 and Dc2 core2 connecting then (static routing?)

It’s possible dc1core 2 for that specific destination looks like its calculated the

better feasible neighbour towards that destination over this link and it is advertising this to its dc1 core 1 neighbour and dc 1 core 1 is selecting that as its successor 

[Amafsha1]

Hey Paul, they are not connected via static routing.  Some of the routes in our route tables are actually looping I think.  Although it's not service-impacting the design is definitley not stable.  Would you have any idea why they are not becoming eigrp neighbors?  They both have the 'ip router eigrp 1' command configured under their interfaces..   Could this be a bug?  

[Amafsha1]

omg I'm so dumb lol.  The port is flapping that's why. 

[paul driver]

Hello

Dont be so hard on yourself, at least you found the issue

[paul driver]

Hello
Eigrp calculates each route destination independent from router to router and as such It seems in this case to suggest DC1 Core1 sees DC2 Core1 as a successor towards your branch subnet but DC1 Core2 see DC1 Wan router as it successor.

If you check from either DC1 core 1/2 and validate the feasible distance metric it should show you the computed distance to that particular destination since the last time eigrp made calculation for it.

sh ip eigrp topology 65.100.x.x

[Amafsha1]

Thank you for the response.  That's the first place I looked:

Core2# sh ip eigrp top 65.100.x.x 255.255.255.252

IP-EIGRP (AS 1): Topology entry for 65.101.112.232/30
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 25630976
Routing Descriptor Blocks:
172.31.255.5 (Ethernet1/23), from 172.31.255.5, Send flag is 0x0 (route through MPLS WAN Router at Datacenter 1)
Composite metric is (25630976/25600256), Route is External
Vector metric:
Minimum bandwidth is 100 Kbit
Total delay is 1210 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
Internal tag is 209
External data:
Originating router is 10.0.0.32
AS number of route is 65425
External protocol is BGP, external metric is 0
Administrator tag is 209 (0x000000d1)

----------------------------------------------------------------------------

Core1# sh ip eigrp top 65.100.x.x 255.255.255.252

IP-EIGRP (AS 1): Topology entry for 65.101.112.232/30
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 25630976
Routing Descriptor Blocks:
172.31.255.1 (Ethernet1/23), from 172.31.255.1, Send flag is 0x0 (route through MPLS WAN Router at Datacenter 1)
Composite metric is (25630976/25600256), Route is External
Vector metric:
Minimum bandwidth is 100 Kbit
Total delay is 1210 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
Internal tag is 209
External data:
Originating router is 10.0.0.32
AS number of route is 65425
External protocol is BGP, external metric is 0
Administrator tag is 209 (0x000000d1)
172.16.250.18 (Ethernet1/44), from 172.16.250.18, Send flag is 0x0 (Route through the Metro-E circuit to Datacenter 2)
Composite metric is (25631232/25630976), Route is External
Vector metric:
Minimum bandwidth is 100 Kbit
Total delay is 1220 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
Internal tag is 209
External data:
Originating router is 65.x.x.162
AS number of route is 65425
External protocol is BGP, external metric is 0
Administrator tag is 209 (0x000000d1)

This is what caught my eye.  I would expect them to be the same.   The metrics for Core1 are better to go through the MPLS WAN router, yet it goes through the 10 gig circuit through core-to-core...