Routers running dynamic routing protocols advertise the prefixes of network destinations found within 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. And this is where some problems may arise. What happens when a router receives a prefix from its neighboring router? Should it advertise it back? And if it does, should that router advertise it back to the original router?
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 is also an integral part of internal BGP (iBGP). For all of these protocols, split horizon’s primary function is to prevent the creation of routing loops that result from 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. In this article, we’ll take a closer look at split horizon to help you understand how it works, when to use it, and when to avoid it.
A deep dive on split horizon
To fully understand the need for split horizon and how it works, let’s take a closer look at what happens without it. For our examples, we’ll use this network topology:
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.
Let’s see how the three routers advertise networks. R1 will advertise the 10.10.10.0/24 network to R2, and R2 will advertise this newly learned information to R3:
Notice how the metric's value in the routing tables increases for this advertised network.
Now, without split horizon, R3 will take this information about 10.10.10.0/24 and advertise it back to R2 like so:
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 does not replace the existing route in the routing table.
Even though the spilt horizon is disabled, the circular advertisement has not caused any routing problems. The only issues are the extra bandwidth and router resources consumed to send a useless update from R3 to R2. But it could be argued that it’s no big deal… yet.
Next, let’s assume that the dynamic routing protocol has fully converged and that all routers have learned about all the prefixes in the network like so:
Now, what happens if the Fa0/1 interface of R3 fails? Let’s take a look:
R3 will automatically remove its entry of 20.20.20.0/24 from the routing table. However, dynamic routing protocols will periodically send updates. What happens if R2 sends an update to R3 informing it of a route to the 20.20.20.0/24 network?
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 like so:
This time, R2 modifies its previous entry in the routing table with an increased metric. Unlike the last scenario where the routing update was ignored because there was already an entry with a lower metric, the entry is modified because it has come from the same source (R3).
If we continue this trend, R2 and R3 will continuously exchange routing updates ad infinitum, resulting in higher and higher 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.
There are mechanisms that mitigate against IP packets traveling through such topologies forever, such as the Time To Live (TTL) field in the IP header, as well as a maximum metric applied by dynamic routing protocols. But these do not prevent the creation of a routing loop in the first place.
How split horizon resolves these problems
When split horizon is enabled, routers will not re-advertise prefixes to routers from which they were originally received. How would this change the procedure described above? Let’s take a look at our topology with the failed Fa0/1 interface on R3 again.
With split horizon enabled, R2 will never send an update to R3 containing the prefix 20.20.20.0/24 since it received this prefix from R3 in the first place. How do we know? Because 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 further refine the definition of the split horizon rule like so:
A router will not advertise a prefix out of the same interface from which it was learned.
The result is a stable routing topology without routing loops. What happens when a packet is sent to 20.20.20.1 in this case?
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 will be dropped because there is 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 to the 20.20.20.0/24 network will eventually expire using the mechanisms in place for 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 out a triggered update indicating to its neighbors that this route is no longer available. This is done by sending a maximum, or infinity, metric value indicating that this route is unreachable.
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.
{{banner-8="/design/banners"}}
Split horizon examples for dynamic routing protocols
Now that we’ve covered the fundamentals of split horizon, let’s take a closer look at its usage with different dynamic routing protocols.
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 on a per-interface basis 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:
EIGRP
As an enhanced distance vector routing protocol, EIGRP employs split horizon by default as well. EIGRP uses additional features to ensure loop prevention, 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:
BGP
Although not a distance vector routing protocol, BGP uses split horizon for 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:
As you can see from the diagram, the original update sent from R1 to R2, is then sent to R3, and back to R1 again. In fact, R3 also receives an update directly from R1 as well!
So if R3 sends that message to R1, R1 will receive an update about a prefix that it originated, which is a surefire way to create a routing loop. With the split horizon rule, R2 will never forward an iBGP prefix that it learns from R1 towards R3 as shown:
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, it is necessary for all iBGP routers to become neighbors with all other iBGP routers within the AS, resulting in a full mesh adjacency. Otherwise, iBGP updates will not be sent successfully, and convergence will not occur.
This is a built-in feature of iBGP and cannot be modified.
OSPF and eBGP: routing protocols that don’t use split horizon
OSPF is a link-state dynamic routing protocol and does not 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 (SFP) algorithm and creates the shortest path tree (SPT) to the intended destination. SPT is a loop-free path by definition, and therefore the split horizon rule is not 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 will not 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 if absolutely necessary.
The situations where it makes sense to disable split horizon typically involve a hub and spoke network topologies where spoke-to-spoke communication is not possible, and may require split horizon to be disabled.
The diagram below provides a practical example.
In this topology, communication occurs only between the Hub and Spoke1 and between the Hub and Spoke2. Direct spoke-to-spoke communication does not take place. You would 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 will not be readvertised to Spoke 2 because the Hub does not 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 is best practice to do so.
{{banner-sre="/design/banners"}}
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 particular topologies to function correctly, but these cases should be approached with caution to ensure routing loops are avoided.
