Consider the below network where R1 believes host 3.3.3.3 is reachable via R2, and R2 believes the (same) host, 3.3.3.3 is reachable via R1.
Any packet entering the network will bounce between routers in an endless loop until it eventually gives up. A simple traceroute from R1 to 3.3.3.3 illustrates the problem:
R1#traceroute 3.3.3.3 Type escape sequence to abort. Tracing the route to 3.3.3.3 VRF info: (vrf in name/id, vrf out name/id) 1 1.2.1.2 20 msec 20 msec 20 msec 2 1.2.1.1 24 msec 28 msec 24 msec 3 1.2.1.2 48 msec 44 msec 40 msec 4 1.2.1.1 52 msec 64 msec 44 msec <snip> 30 1.2.1.1 348 msec 344 msec 344 msec R1#
To avoid this problem distance vector routing protocols, such as RIP and EIGRP, deploy a loop avoidance mechanism called Split Horizon.
Simply put Split Horizon will not advertise a route out of the same interface it is received on.
As can be seen in the above diagram, this avoids two adjacent neigbours pointing to each other to reach the same destination.
In fact EIGRP goes one step further and implements Split Horizon with Poisoned Reverse. In other words, if a route is received from a neigbour on a particular interface, then EIGRP advertises the route back with an infinite metric. Effectively saying “I know about this route, but any other path is better than coming via me”
Spilt Horizon is enabled by default on an interface. However there are some instances when it makes sense to turn it off, typically in DMVPN hub and spoke deployments. Consider the following diagram.
In this case there is a single tunnel interface into the DMVPN. Each of the spokes advertise their attached network to the hub, but because of the Split Horizon rule the hub cannot advertise this back down to the other spokes. Disabling split horizon will enable the hub to do this. This can be achieved with the following command:
R1(config-if)#no ip split-horizon
The Traceroute Blog 