When to Disable EIGRP Split-Horizon


Within a properly configured network, one thing that is very important is loop prevention. A Network loop can bring a wide range of issues from misrouted traffic to physical effects on devices such as high CPU and memory use. Regardless, this is something that is a big focus when configuring a network. For Cisco based networks, the Cisco proprietary routing protocol EIGRP is a commonly used choice. EIGRP natively and by default has a loop prevention safeguard build in. This is called split-horizon. To summarize the functionality of split horizon, you should focus on route advertisements. Split-horizon will not allow a route to be advertised out the same interface it was received on. In most cases, if this was done, it would cause a loop in the network. That is why it is enabled by default and commonly left enabled. Commonly left enabled, yes, but this article will describe when to disable EIGRP split-horizon.

When would you ever disable EIGRP split-horizon?

There is one scenario where split-horizon is very commonly disabled and that is within a hub and spoke configuration. Look at our topology above. It is an example of a DMVPN topology in which we have a hub and two spokes. The example is really simple in this case. R1 will receive advertisements from Spoke1 on its Tunnel0 interface. The problem here is that it also has a connection with Spoke2 on that same tunnel interface. If we don’t disable EIGRP split-horizon, then the Hub will not relay routes from Spoke1 to Spoke2 and the other way around. That is because it received those routes on interface Tunnel0 and therefore can’t \ won’t advertise it back out that same interface.

How to disable EIGRP split-horizon.

The process to disable EIGRP split-horizon is a single command. This is done on the specific interface in question. In our case, it will be interface Tunnel0 on the HUB router, R1:

R1(config)# interface tunnel0
R1(config-if)# no ip split-horizon eigrp 123  (where 123 is the AS number)

And with that you’re all set! R1 will be able to advertise routes to Spokes that were received from another Spoke router. Keep in mind that you want to be careful and only use this command in situations where you understand the implications of what will really be done. As mentioned with this DMVPN example, there’s a time and place for everything!


Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.