EIGRPCCNA 200-301

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

1

Check EIGRP neighbor relationships

show ip eigrp neighbors
R1# 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  7

All 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.

2

Examine the EIGRP topology table on a spoke

show ip eigrp topology all-links
R2# 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/0

On 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.

3

Check the EIGRP topology table on the hub

show ip eigrp topology all-links
R1# 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/1

On 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.

4

Verify EIGRP split horizon status on hub interfaces

show ip interface serial 0/0/0 | include split horizon
Split 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.

5

Check for route filtering or distribute-lists

show running-config | section router eigrp
router 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

Remove the distribute-list that is filtering the route. On the hub router (R1): ``` R1(config)# router eigrp 100 R1(config-router)# no distribute-list prefix DENY_R3 in Serial0/0/1 ``` If the distribute-list is no longer needed, ensure no other filters are blocking the route. Alternatively, modify the prefix-list to permit the necessary routes.

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

1.

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.

2.

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.

3.

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