review of split-horizon

Distance vector routing protocols like RIP and EIGRP rely on a number of measures for loop avoidance. One of these is split horizon, which prevents a route from being readvertised out the interface on which it was received. For example, if a router learns about 192.168.0.0/16 from a neighbor on its Serial1/0 interface, it can't advertise that route back out Serial1/0. This helps mitigate routing loops while working to optimize communication between neighbors.
However, there are instances where split horizon is undesirable. One good example of such a scenario is a nonbroadcast multiaccess (NBMA) frame relay network lacking a full mesh. Such a topology is illustrated below:

The point-to-multipoint frame relay network is comprised of two virtual circuits, one between R1 and R2 and one between R2 and R3. All three routers are addressed within the 10.0.0.0/24 subnet. EIGRP adjacencies are formed along the virtual circuits (R1 peers with R2 but not with R3):

R1# show ip eigrp neighbors
IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                        (sec)         (ms)       Cnt Num
0   10.0.0.2                Se1/0            153 02:26:57   16   200  0  11

R2# show ip eigrp neighbors
IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                        (sec)         (ms)       Cnt Num
1   10.0.0.3                Se1/0            134 02:27:00  527  3162  0  7
0   10.0.0.1                Se1/0            169 02:27:00  547  3282  0  7

Remember that the split horizon rule forbids R2 from relaying advertisements back out the interface on which they were received. As a result, R3 never receives advertisements from R1 and vice versa. Here we can verify R3 has no knowledge of R1's 192.168.1.0/24 network:

R3# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
   D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
   N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
   E1 - OSPF external type 1, E2 - OSPF external type 2
   i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
   ia - IS-IS inter area, * - candidate default, U - per-user static route
   o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

10.0.0.0/24 is subnetted, 1 subnets
C       10.0.0.0 is directly connected, Serial1/0
D    192.168.2.0/24 [90/2195456] via 10.0.0.2, 02:29:48, Serial1/0
C    192.168.3.0/24 is directly connected, FastEthernet0/0

One solution to this predicament is to disable split horizon for EIGRP on R2. This is accomplished with the command no ip split-horizon eigrp <AS> under interface configuration.

R2(config)# interface s1/0
R2(config-if)# no ip split-horizon eigrp 1

This command will prompt EIGRP to immediately tear down and reestablish all its adjacencies on the interface, as evidenced by this log message on R2:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.0.0.3 (Serial1/0) is resync: split
horizon changed

When the adjacencies are reformed, we can see that R2 is now relaying advertisements between R1 and R3:

R3# show ip route

10.0.0.0/24 is subnetted, 1 subnets
C       10.0.0.0 is directly connected, Serial1/0
D    192.168.1.0/24 [90/2707456] via 10.0.0.2, 00:02:39, Serial1/0
D    192.168.2.0/24 [90/2195456] via 10.0.0.2, 02:33:55, Serial1/0
C    192.168.3.0/24 is directly connected, FastEthernet0/0

Additionally, if we were running RIP instead of EIGRP, the command to disable split horizon is simply no ip split-horizon at the interface.

hints:
1.Split Horizon is disabled by default for RIP on interfaces with Frame Relay or SMDS encapsulation, but not for EIGRP, not for subinterfaces, and not for other encapsulation types.
2.
While you can do this in a NBMA network (like FRS) to allow connectivity this can also be solved another way.
You can enable SubInterfaces on all NBMA segments instead keeping split horizon enabled for nearly loop-free performance and still allowing full connectivity in an NBMA FRS.
3.This is also very useful in DMVPN deployments where you don't have a full EIGRP mesh.