cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
608
Views
0
Helpful
4
Replies

Core Switch not passing on learned routes to downstream Neighbours

GRANT3779
Spotlight
Spotlight

I have come across an issue in my lab which I initially thought was down to some sort of stub flag but now I am not so sure. I run some pcaps and there was no stub flag set.

Acting as my Core Switch -

3560G (flash:c3560-ipservicesk9-mz.150-2.SE10.bin) - 

My Core switch has 2 adjacencies, one with R2 and the other with R3 in AS 1.

UK-ROB-3560G-01#sh ip eigrp neighbors

1 10.44.70.3 Vl970 11 00:20:27 13 100 0 18       - R3
0 10.44.70.2 Vl970 13 00:20:27 8 100 0 11         -R2

R2 and R3 do not have a direct adjacency.

The routing table of my core is as follows -

10.0.0.0/8 is variably subnetted, 10 subnets, 2 masks
C 10.44.0.0/24 is directly connected, Vlan500
L 10.44.0.1/32 is directly connected, Vlan500
C 10.44.3.0/24 is directly connected, Vlan503
L 10.44.3.1/32 is directly connected, Vlan503
C 10.44.70.0/24 is directly connected, Vlan970
L 10.44.70.1/32 is directly connected, Vlan970
D EX 10.49.1.0/24 [170/2172672] via 10.44.70.3, 00:22:35, Vlan970
D EX 10.49.2.0/24 [170/2172672] via 10.44.70.3, 00:22:35, Vlan970
D EX 10.49.3.0/24 [170/2172672] via 10.44.70.3, 00:22:35, Vlan970
D EX 10.49.4.0/24 [170/2172672] via 10.44.70.3, 00:22:35, Vlan970
172.27.0.0/16 is variably subnetted, 4 subnets, 2 masks
D 172.27.0.0/30 [90/2170112] via 10.44.70.3, 00:22:35, Vlan970
D 172.27.0.2/32 [90/2170112] via 10.44.70.3, 00:22:35, Vlan970
D 172.27.0.4/30 [90/2170112] via 10.44.70.2, 00:22:35, Vlan970
D 172.27.0.6/32 [90/2170112] via 10.44.70.2, 00:22:35, Vlan970
192.168.0.0/29 is subnetted, 1 subnets
D EX 192.168.0.0 [170/2172672] via 10.44.70.3, 00:22:35, Vlan970

So for example - I look at routing table on R2 (which has eigrp adjacency with my core) I only see the following. I see the routes attached to my Core, but I do not see any routes that my Core switch has learned from anyone else. I have no filters / route-maps in place. Just simple EIGRP config.


Table from R2 -

10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
D 10.44.0.0/24 [90/3072] via 10.44.70.1, 00:26:44, GigabitEthernet0/0
D 10.44.3.0/24 [90/3072] via 10.44.70.1, 00:26:44, GigabitEthernet0/0
C 10.44.70.0/24 is directly connected, GigabitEthernet0/0
L 10.44.70.2/32 is directly connected, GigabitEthernet0/0
172.27.0.0/16 is variably subnetted, 3 subnets, 2 masks
C 172.27.0.4/30 is directly connected, Serial0/2/0
L 172.27.0.5/32 is directly connected, Serial0/2/0
C 172.27.0.6/32 is directly connected, Serial0/2/0

Any ideas?

Thanks

1 Accepted Solution

Accepted Solutions

So in this scenario you'll get these results. It is the rule of split horizons where a router will not advertise a route out the same interface it was learned. In this case VLAN 970. You could try disabling split horizons to see if this resolves the issue.

Under the VLAN 970 interface, "no ip split-horizon eigrp 1"

View solution in original post

4 Replies 4

chrihussey
VIP Alumni
VIP Alumni

Why is it that R2 and R3 have not established EIGRP neighbors even though they are in the same VLAN (970) peering with the core?

Purely just different design scenario I am working on, it was done purposely for the time being with static neighbors

So in this scenario you'll get these results. It is the rule of split horizons where a router will not advertise a route out the same interface it was learned. In this case VLAN 970. You could try disabling split horizons to see if this resolves the issue.

Under the VLAN 970 interface, "no ip split-horizon eigrp 1"

Due to running named EIGRP I had to add the following -


af-interface Vlan970
authentication mode md5
authentication key-chain KC_MD5
no passive-interface
no split-horizon
exit-af-interface

But yes, that was exactly the issue. Was looking at this and believing it to be more complicated than it was.

Thanks a lot, saved me from more hours of headache.