Not getting routes from EIGRP on 9500

[branden.beachy]

We have a fiber loop connecting about a dozen school buildings.  They have all been running 3850's up until earlier this year, when we started upgrading.  One location now has a 9300 stack.  All of these switches, including the 9300 are broadcasting and receiving EIGRP routes just fine.

I am getting ready to add a new school that will be between the 9300 and one of its 3850 partners, and I have a pair of 9500's that are going to be the layer 3 switches for that building.  In preparing to get that new building running (before the fiber has been finished), I have sat the 9500 stack in the same rack as the 9300 stack for now, and have made a layer 3 link between them.  

I have a console connection to the 9500 stack, so I can get to it for configuration.  On both the 9300 and 9500, when I do a show ip eigrp neighbor, I see the other switch.

When I am consoled on to the 9500, I can get anywhere.  It has all the routes for the rest of the network, so the 9300 is sharing routes properly.

However, from anywhere else on the network, including the 9300, I don't have any of the routes to the 9500's networks, so it is unreachable from anywhere.

I've found one thing that seems to be different, and I'm wondering if this is a clue.  When I do a show ip eigrp neighbors detail on the 9300, I get this:

GMS9300#show ip eigrp neighbors detail
EIGRP-IPv4 Neighbors for AS(2315)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num

0 10.255.255.34 Po1 11 15:52:28 9 100 0 49
Version 17.0/2.0, Retrans: 1, Retries: 0, Prefixes: 218
Topology-ids from peer - 0
Topologies advertised to peer: base

1 10.255.255.30 Po2 14 1w0d 6 100 0 349
Version 17.0/2.0, Retrans: 1, Retries: 0, Prefixes: 229
Topology-ids from peer - 0
Topologies advertised to peer: base

2 10.255.255.46 Te1/1/1 12 3w0d 1 100 0 1773
Time since Restart 1w0d
Version 28.0/2.0, Retrans: 1, Retries: 0
Topology-ids from peer - 0
Topologies advertised to peer: base

0 and 1 are the adjacent 3850's, while 2 is the 9500.  On both of the 3850's, it shows a bunch of prefixes, while on the 9500, "prefix" isn't even listed.  Does that help explain why I'm not getting the 9500's routes?  Is there some extra command I need to have on the 9500?  I just have the standard EIGRP structure like I have on the 9300:

router eigrp 2315
network 10.25.111.0 0.0.0.255
network 10.111.0.0 0.0.255.255
.

.

.
network 10.254.112.0 0.0.15.255
network 10.255.255.44 0.0.0.3
redistribute static

Any help would be appreciated.  Thanks!

[paul driver]

Hello
Make sure you don’t have any policy’s denying traffic, distribution lists, duplicate router ids, auto summarization is disabled (no auto summary) or even split horizon ruling initiating
Enable debug on the 9500 first and if you don’t see anything perform the same on the 9300.

debug ip eigrp

[Richard Burts]

Would you post the output of show ip interface brief from the 9500. We would want to see if any of the subnets that match the EIGRP network statements are in the up state. I am guessing that in setting up the test you connected the link to neighbors but not the interfaces that would be for local connections on the 9500. The config includes redistribute static. I can think of 2 things that might impact this:

1) are there any static routes in the routing table (show ip route and look for static routes). If static routes are configured I am wondering if the next hop is reachable. 

2) in the partial config that was posted there is not any default metric for the redistributed routes.

[Georg Pauwen]

Hello,

post the full runnng configs of both the GMS9300 and the 9500 switch (the one with IP address 10.255.255.46)...

[Giuseppe Larosa]

Hello @branden.beachy ,

as noted by @Richard Burts the more likely reason is that your test subnets are associated to SVI interfaces that are not in up/up state.

To create test subnets that are up you can use loopback interfaces.

So the show ip interface brief output is important to understand the state of your L3 interfaces.

As mentioned by @paul driver  a possible reason for Catalyst 9300 to reject routes coming from C9500 could be  a duplicated EIGRP router id.

In original EIGRP implementation EIGRP RID was reported only for external routes in modern implementation it is reported also for internal routes.

Hope to help

Giuseppe