Specific route isn't advertised through primary route using EIGRP yet on other remote sites it is

[dfunk0001]

Hi guys,

The majority of routes (98%) on our remote site routers show 'learned via EIGRP (170) ' from the primary WAN yet a few important subnets do not even have a route learned through EIGRP from the primary route, only through the backup route.

We have had to assign a static route through the primary connection (which works).

I'll try my best not to make this scenario complex, but (4) sites have this issue and (4) sites are correct with advertisement learned and used for their primary connection (different WAN providers).

The Core 7010 Nexus devices have the specific subnet in question set as a static route and has 'redistribute route_map static'.

It also list that specific subnet as a 'ip summary-address'

Again, the remote site routers having the issue apparently show 98% of the routes correctly learned and utilizing the primary route yet the specific route in question shows 'learned through EIGRP from the slower backup link' on each one and not even a route through the primary.

It appears as the configured EIGRP 'network' IPs are associated with VLAN IPs and not physical interfaces or port channels.

When I 'show ip eigrp [AS] int'  I see tons of VLANs associated but not the VLAN for the specific WAN provider that I'm having the issue with.

So my question is how can all of the routes have been learned through this VLAN (Primary WAN route) if that VLAN doesn't appear to be in the EIGRP AS process?

I hope I'm on to the issue as the other sites and their VLANs that work correctly appear in the EIGRP AS process.

I have not yet ran the 'debug eigrp',  but I wanted to know if you had some insights on how specific EIGRP routes could not be advertised yet all of the others seem to be advertised fine.

The majority of our network is 10.x.x.x and the subnet that is specific to this issue is a 172.x.x.x

Thanks in advance.

[pwwiddicombe]

In your EIGRP statements, how is the 172.x.x.x network defined?  If it's advertised as a summary address and then somehow the backup path has a more specific subnet defined, the backup path will take precedence in the routing table.

[dfunk0001]

Thanks for the reply,

the subnet in question in the Core's EIGRP section is listed as 'ip summary-address 172.x.x.0' but in the ip route statement as 'static to x.x.x.x'.

The remote router 'sh ip route 172.x.x.x' only shows (1) route for that subnet via the backup route and doesn't even list a feasible successor alternate route (primary WAN).

The primary and secondary WAN routes are both connected to the Core so wouldn't the advertisements show the static route distributed to both and the better route preferred?  I'm not even seeing the route option on the remote side via the primary connection, just the backup.

EDIT - and JUST for these few individual subnets!  All the other 98% routes are going over the primary as they should! Ugh!!!
 

[dfunk0001]

The problem remote routers show;

ip route 172.x.x.x via 'backup route ip', learned via EIGRP from 'backup route router ip' 1w02d

sh ip eigrp topology 172.x.x.x = no feasible successor

The correct working remote sites show both, ip route 172.x.x.x via 'primary route ip' learned from 'primary route router ip' and it list a feasible successor as the backup route with a larger metric.

But, these other WAN provider connection VLANs appear in the 'sh ip eigrp [AS#] int' on the cores

The Core EIGRP network IPs seem to match the VLANS and the remote router's EIGRP match the WAN interface IPs.

The majority of subnets have been working fine, learned from advertisements of the Core for years, we just discovered an application that keeps going over the slower backup link.

I apologize as I'm somewhat green with Routing, CCNA newbie.

[dfunk0001]

Well I resolved the issue and wanted to pass it along to anyone else who may come across this.

The issue was related to the Route Map called Static Redistribute.

One core had the "ip prefix-list Static Redistribute permit 172.X.X.X" and the other core was missing that statement.  That is why some of our WAN routes had the EIGRP route and the others did not.

The route was not being advertised although the VLAN was enabled for that EIGRP Group.

It makes sense now as 98% of the routes were "permitted" to be advertised through these ip prefix list statements and not the specific route that I was troubleshooting.

Thanks to pwwiddicombe for at least trying to help with this issue.