Split Horizon: Tutorial & Examples

Split horizon: Tutorial & examples

Routers running dynamic routing protocols advertise the network destination prefixes in their routing tables to their neighbors. This allows routers to populate their routing tables with prefixes found throughout the routing domain.

Additionally, a router will advertise a prefix it learns to all neighboring routers. This is where problems arise. Without safeguards, a router that receives a prefix from a neighbor might readvertise it back, and that neighbor might readvertise it again, creating circular advertisements.

Without the right precautions, routers can create routing loops and incorrect metric calculations by sending these circular advertisements.

How split horizon addresses routing loops

Split horizon addresses these problems by enforcing this logic:

A router must not advertise a prefix to a neighbor from which it learned the prefix in the first place.

Put simply, if router A sends an advertisement to router B containing prefix 10.10.10.0/24, router B must not readvertise that prefix back to router A.

Where is split horizon used?

Split horizon is a central part of distance vector routing protocols such as EIGRP and RIP. It’s also an integral part of internal BGP (iBGP). For all of these protocols, split horizon’s primary function is to prevent routing loops caused by prefixes being readvertised to the routers that originally advertised them.

However, there are cases where split horizon is undesirable. In those cases, it must be disabled for the proper operation of dynamic routing protocols.

Why split horizon matters in distance vector networks

To fully understand the need for split horizon, consider what happens without it. The following topology illustrates the problem:

Topology with initial routing tables

The descriptions here closely resemble the operation of RIP, but the concepts are the same for other protocols such as EIGRP.

Notice that before any dynamic routing protocols operate, the routing tables contain only the directly connected networks, each with a metric of 0 to reach them.

In the diagram below, a dynamic routing protocol has been configured on these routers.

R1 will advertise the 10.10.10.0/24 network to R2, and R2 will advertise this newly learned information to R3:

Topology with routing tables after advertisement of the 10.10.10.0/24 network

Notice how the metric’s value in the routing tables increases for this advertised network.

Without split horizon, R3 advertises the 10.10.10.0/24 prefix back to R2:

R3 re-advertises the 10.10.10.0/24 network to R2

R2 receives this update from R3 for 10.10.10.0/24, but the metric to this particular destination is 3, which is larger than the metric already installed in the routing table, which has a value of 1. Because the metric for this prefix is better via Fa0/0 than via Fa0/1, this prefix doesn’t replace the existing route in the routing table.

Even though split horizon is disabled, the circular advertisement hasn’t caused any routing problems. The only issues are the extra bandwidth and router resources consumed to send a useless update from R3 to R2. The extra bandwidth and processing overhead are minor inefficiencies, but not routing failures.

Assume the dynamic routing protocol has fully converged and all routers have learned about all the prefixes in the network:

Fully converged topology with routing tables

When the Fa0/1 interface on R3 fails, the routing loop problem becomes clear:

The Fa0/1 interface on R3 has failed

R3 will automatically remove its entry of 20.20.20.0/24 from the routing table. However, dynamic routing protocols will periodically send updates. When R2 sends an update to R3 for the 20.20.20.0/24 network, R3 installs it as an alternate route:

R2 re-advertises the 20.20.20.0/24 network to R3

R3 now has an alternate route to 20.20.20.0/24 via its Fa0/0 interface. After a certain amount of time, R3 will readvertise this route to R2:

R3 re-advertises the 20.20.20.0/24 network to R2

This time, R2 modifies its previous entry in the routing table by increasing the metric. Unlike in the last scenario, where the routing update was ignored because there was already an entry with a lower metric, this entry is modified because it comes from the same source (R3).

If we continue this trend, R2 and R3 will exchange routing updates ad infinitum, resulting in ever-increasing metric assignments. This phenomenon is known as a “count to infinity” situation.

If a packet with a destination of 20.20.20.1 is sent from R1 during this exchange, that packet will enter a routing loop between R2 and R3.

R1 sends a packet to 20.20.20.1, resulting in a routing loop between R2 and R3

There are mechanisms that mitigate against IP packets traveling through such topologies indefinitely, such as the Time To Live (TTL) field in the IP header and the maximum metric applied by dynamic routing protocols. But these don’t prevent the creation of a routing loop in the first place.

How split horizon resolves these problems

When split horizon is enabled, routers won’t re-advertise prefixes to routers from which they were originally received. With split horizon enabled, the failed Fa0/1 interface on R3 produces a different result.

The Fa0/1 interface on R3 has failed

With split horizon enabled, R2 won’t send an update to R3 containing the prefix 20.20.20.0/24 since it received this prefix from R3 in the first place. The interface corresponding to the 20.20.20.0/24 prefix in R2’s routing table is Fa0/1. That’s the interface through which R2 is connected to R3. Thus, we can refine the split horizon rule more precisely:

A router won’t advertise a prefix out of the same interface from which it was learned.

The result is a stable routing topology without routing loops. When a packet destined for 20.20.20.1 is sent, R3 drops it because there’s no matching entry in its routing table:

R1 sends a packet to 20.20.20.1, which is dropped when it reaches R3

The packet will reach R3 because R1 and R2 still have the 20.20.20.0/24 network in their routing tables. However, when the packet reaches R3, it’ll be dropped because there’s no longer any such entry in the routing table.

Poison reverse

Without any further updates from R3 about this network, R2 and R1’s entries for the 20.20.20.0/24 network will eventually expire under the mechanisms of the employed dynamic routing protocol. However, split horizon’s companion feature, poison reverse, can address this problem.

Poison reverse ensures that these entries are removed as soon as R3 loses connectivity to the 20.20.20.0/24 network. When R3’s Fa0/1 interface fails, the 20.20.20.0/24 network is removed from its routing table. At the same time, R3 will send a triggered update to its neighbors indicating that this route is no longer available. This is done by sending a maximum (or infinite) metric value, indicating that this route is unreachable.

R3 is sending a route poison for the 20.20.20.0/24 network to R2 and R1, resulting in an infinite metric to that destination in their routing tables

This immediately informs R1 and R2 that this network is no longer reachable via R3, eliminating the need for a timeout to remove those entries from their routing tables.

Split horizon examples for dynamic routing protocols

Split horizon behaves slightly differently across RIP, EIGRP, and BGP.

RIP

The above examples most closely resemble how RIP employs split horizon, so there’s not that much more to be said.  However, it is essential to note that split horizon is enabled by default on most interface types when RIP is used. 

A split horizon is configured per interface in interface configuration mode on a Cisco router.  

To disable it on a RIP-enabled Cisco IOS device, use the following command on the desired interface:

Device(config-if)# no ip split-horizon

EIGRP

As an enhanced distance vector routing protocol, EIGRP employs split horizon by default.  EIGRP uses additional features to prevent loops, such as the feasibility condition, which we will not explain here. To disable split horizon on an interface participating in EIGRP, you must use the following command:

Device(config-if)# no ip split-horizon 1

BGP

Although not a distance-vector routing protocol, BGP uses split horizon in interior BGP. It is slightly different from the split horizon implementation used for distance vector routing protocols. iBGP split horizon states that:

A BGP router will not advertise prefixes from one iBGP neighbor to another iBGP neighbor.

Without the split horizon rule, BGP updates within a specific AS may be announced like this:

BGP updates without the split horizon rule

The original update sent from R1 to R2 is then sent to R3, and back to R1 again. R3 also receives an update directly from R1.

So if R3 sends that message to R1, R1 will receive an update about a prefix that it originated, which will create a routing loop. With the split horizon rule, R2 won’t forward an iBGP prefix that it learns from R1 towards R3 as shown:

iBGP updates with the split horizon rule

Indeed, split horizon here dictates that no iBGP router will forward any prefixes learned via iBGP to any other iBGP router. Because of this split horizon rule, all iBGP routers need to become neighbors with every other iBGP router within the AS, resulting in a full mesh adjacency. Otherwise, iBGP updates won’t be sent successfully, and convergence won’t occur.

This is a built-in feature of iBGP and can’t be modified.

OSPF and eBGP: Routing protocols that don’t use split horizon

OSPF is a link-state dynamic routing protocol and doesn’t employ the concept of split horizon. Unlike distance vector protocols, link-state protocols provide routers with a complete network topology. OSPF uses the shortest-path first (SPF) algorithm to create the shortest-path tree (SPT) to the intended destination. SPT is a loop-free path by definition, and therefore, the split horizon rule isn’t needed.

External BGP (eBGP) is used by routers to determine the path to a destination via autonomous systems. eBGP uses the AS_PATH attribute to avoid routing loops. An eBGP router won’t accept a prefix if it sees its own AS number. Thus, eBGP inherently avoids routing loops and makes split horizon unnecessary. On the other hand, one could say that this check actually resembles a split horizon mechanism.

When should split horizon be disabled?

There are some use cases for RIP and EIGRP where administrators should disable split horizon. However, because of the risk of routing loops, administrators should only disable split horizon when necessary.

The situations where it makes sense to disable split horizon typically involve hub-and-spoke network topologies where spoke-to-spoke communication isn’t possible, and split horizon may need to be disabled.

The diagram below provides a practical example.

A hub and spoke topology

In this topology, communication occurs only between the Hub and Spoke1 and between the Hub and Spoke2. Direct spoke-to-spoke communication doesn’t take place. You’d see such a topology when implementing Frame-Relay or DMVPN Phase 1. The important thing to note here is that the Hub communicates with both Spokes via the same interface.

In such a scenario, the split horizon rule prevents the spokes from learning each other’s networks. The 10.10.10.0/24 network advertised from Spoke 1 to the Hub won’t be readvertised to Spoke 2 because the Hub doesn’t advertise a network out of the same interface it learned it from. That would be a violation of the split horizon rule. In such cases, split horizon must be disabled, and it’s best practice to do so.

Conclusion

Split horizon is a vital component of distance vector protocols such as EIGRP and RIP, as well as for iBGP. Without this rule, routing loops would make these protocols unusable. Along with poison reverse, split horizon mitigates routing loops and speeds up convergence when topologies change.

In some cases, administrators need to disable split horizon to allow certain topologies to function correctly, but this should be done with caution to avoid routing loops.

FAQs