EIGRP Split Horizon Blocking Routes on Hub-and-Spoke
Presenting Symptom
Remote spoke routers cannot reach each other via the hub router, but each spoke can reach the hub and the hub can reach all spokes.
Network Context
This is a hub-and-spoke EIGRP network with a hub router (R1) and two spoke routers (R2 and R3) connected via point-to-point serial links. All routers run Cisco IOS 15.x. The hub router has a single LAN interface and two serial interfaces. Spoke routers have one serial interface and one LAN interface. The network is a small branch office setup with about 10 routes total.
Diagnostic Steps
Check EIGRP neighbor relationships
show ip eigrp neighborsR1# show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.1.1.2 Se0/0/0 13 00:15:00 1 100 0 5
1 10.1.2.2 Se0/0/1 14 00:14:30 1 100 0 7All neighbors should be in the 'Up' state. If any neighbor is missing or in 'Init' state, there is a Layer 2 or authentication issue. In this scenario, all neighbors are up, so the problem is not adjacency.
Examine the EIGRP topology table on a spoke
show ip eigrp topology all-linksR2# show ip eigrp topology all-links
EIGRP-IPv4 Topology Table for AS(100)/ID(2.2.2.2)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 10.1.1.0/24, 1 successors, FD is 409600
via Connected, Serial0/0/0
P 10.1.2.0/24, 1 successors, FD is 409600
via 10.1.1.1 (409600/409600), Serial0/0/0
P 192.168.1.0/24, 1 successors, FD is 409600
via Connected, Loopback0
P 192.168.2.0/24, 1 successors, FD is 409600
via 10.1.1.1 (409600/409600), Serial0/0/0On R2, check if the route to R3's LAN (e.g., 192.168.3.0/24) is present. If it is missing, the route is not being advertised. In this case, the route to R3's LAN is not in the topology table, indicating it is not being received.
Check the EIGRP topology table on the hub
show ip eigrp topology all-linksR1# show ip eigrp topology all-links
EIGRP-IPv4 Topology Table for AS(100)/ID(1.1.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 10.1.1.0/24, 1 successors, FD is 409600
via Connected, Serial0/0/0
P 10.1.2.0/24, 1 successors, FD is 409600
via Connected, Serial0/0/1
P 192.168.1.0/24, 1 successors, FD is 409600
via Connected, Loopback0
P 192.168.2.0/24, 1 successors, FD is 409600
via 10.1.1.2 (409600/409600), Serial0/0/0
P 192.168.3.0/24, 1 successors, FD is 409600
via 10.1.2.2 (409600/409600), Serial0/0/1On the hub, both spoke LAN routes are present. This confirms the hub receives routes from both spokes. The problem is that the hub is not advertising one spoke's route to the other spoke.
Verify EIGRP split horizon status on hub interfaces
show ip interface serial 0/0/0 | include split horizonSplit horizon is enabled
Split horizon is enabled by default on EIGRP. In a hub-and-spoke topology, split horizon prevents the hub from advertising routes learned on one interface back out the same interface. Since both spokes are on different interfaces, split horizon should not block. But if the hub has a multipoint interface (e.g., Frame Relay), split horizon can block. In this case, interfaces are point-to-point, so split horizon is not the issue. However, if the hub uses a single multipoint interface, split horizon would block. The scenario assumes point-to-point, so we need to check other causes.
Check for route filtering or distribute-lists
show running-config | section router eigrprouter eigrp 100 network 10.0.0.0 network 192.168.1.0 distribute-list prefix DENY_R3 in Serial0/0/1
A distribute-list applied inbound on the hub's interface to R3 would filter routes from R3, preventing them from being installed in the hub's routing table. This would cause the hub not to advertise R3's routes to R2. In this scenario, a distribute-list is present, filtering R3's routes.
Root Cause
An inbound distribute-list on the hub router's interface to R3 (Serial0/0/1) is filtering the route to R3's LAN (192.168.3.0/24), preventing it from being installed in the hub's routing table. Consequently, the hub does not advertise this route to R2, causing R2 to be unable to reach R3's LAN.
Resolution
Verification
On R2, verify the route to R3's LAN is now present: ``` R2# show ip route eigrp 192.168.3.0/24 [90/409600] via 10.1.1.1, 00:00:05, Serial0/0/0 ``` Also verify that R2 can ping R3's LAN: ``` R2# ping 192.168.3.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.3.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms ```
Prevention
1. Avoid using distribute-lists unless absolutely necessary; use route summarization or EIGRP stub routing instead. 2. In hub-and-spoke designs, consider configuring EIGRP stub on spoke routers to prevent them from acting as transit and to simplify route filtering. 3. Document all route filters and review them during network changes to ensure they are still required.
CCNA Exam Relevance
On the CCNA 200-301 exam, this scenario tests understanding of EIGRP route filtering and distribute-lists. The exam may present a troubleshooting scenario where a spoke cannot reach another spoke, and candidates must identify that a distribute-list is blocking the route. The key fact is that distribute-lists can filter routes inbound or outbound, and they affect the routing table and subsequent advertisements.
Exam Tips
Remember that distribute-lists can be applied inbound or outbound; inbound filters prevent routes from being installed in the local routing table, while outbound filters prevent routes from being advertised to neighbors.
In hub-and-spoke EIGRP, if spokes cannot reach each other but can reach the hub, check for route filtering on the hub (distribute-lists, prefix-lists, route-maps) or split horizon issues if using multipoint interfaces.
Know the command 'show ip eigrp topology' to see all learned routes, and 'show ip route eigrp' to see installed routes. If a route is in the topology table but not in the routing table, a distribute-list inbound is likely blocking it.
Commands Used in This Scenario
Test Your CCNA Knowledge
Practice with scenario-based questions to prepare for the CCNA 200-301 exam.
Practice CCNA Questions