VMware ESXi and vSphere Cluster Management

Split Horizon in Distance Vector Routing

Learn how split horizon prevents routing loops in RIP and EIGRP, how it works per interface, and how to verify it on Cisco IOS.

What Is Split Horizon?

Split horizon is a routing-update rule used by distance vector routing protocols. A router does not advertise a route through the same interface on which it learned that route.

A distance vector routing protocol is a protocol family in which routers exchange destination reachability and metric information with neighboring routers. RIP is the classic example. EIGRP is commonly categorized as an advanced distance vector protocol and also supports split-horizon behavior.

Split horizon applies to routing updates, which are control-plane messages used to advertise or withdraw networks. It does not directly change ordinary data-plane forwarding decisions. The router still forwards packets according to its routing table; split horizon controls which learned routes it sends to neighbors.

Why Distance Vector Protocols Need Loop Prevention

A routing loop occurs when packets are repeatedly forwarded among routers because each router has incorrect or stale reachability information. Instead of reaching the destination, the packets circulate between routers.

Loops can cause:

Packet loss when packets eventually expire or are discarded.
Excess bandwidth consumption as the same packets cross links repeatedly.
Increased CPU utilization while routers process looping packets and routing updates.
Destinations that appear reachable in routing tables but are effectively unreachable.
Higher latency and unstable application behavior.

Distance vector protocols are especially vulnerable after a link or topology failure. A router may know that its own path has failed but hear from a neighbor that the neighbor can still reach the destination. If that information is stale or was originally learned through the same neighbor, routers can incorrectly select one another as paths.

This is part of the slow convergence problem. Convergence is the process by which routers update their information and reach a consistent view after a network change. During slow convergence, incorrect routes can remain in routing tables while failure information travels through the network.

Three-Router RIP Example

Consider this linear topology:

R1 -------- R2 -------- R3 -------- 10.0.0.0/24
             |           |
        transit link  directly connected LAN

The destination network, 10.0.0.0/24, is directly connected to R3. A directly connected route is created because a router has an active local interface in that network. A learned route is installed from information received from another router.

Initial Route Propagation

R3 originates an advertisement for its directly connected 10.0.0.0/24 network.
R3 sends a RIP update to R2.
R2 installs the network as a learned route through R3.
R2 advertises the route onward to R1.
R1 installs the route with R2 as its next hop.
R1 does not advertise that learned route back out its interface toward R2 because it learned the route from R2 on that interface.

The next hop is the neighboring router to which packets are forwarded to reach a destination. In this example, R1 sends packets for 10.0.0.0/24 to R2, and R2 sends them to R3.

Router	How 10.0.0.0/24 is learned	Next hop toward 10.0.0.0/24	May advertise the route toward R2?	Reason
R3	Directly connected	None; the network is local	Not applicable for a route learned from R2	R3 originates the route.
R2	RIP update received from R3	R3	Yes, if the update is sent through the R1-facing interface	The route was learned on the R3-facing interface, not the R1-facing interface.
R1	RIP update received from R2	R2	No	Split horizon suppresses a route from being advertised back through the interface where it was learned.

In a diagram, the normal control-plane flow is R3 to R2 and then R2 to R1. Split horizon prevents R1 from reflecting the learned route back toward R2.

What Happens Without Split Horizon?

Assume R1 previously learned 10.0.0.0/24 through R2. If split horizon is disabled, R1 could advertise that route back to R2. R2 might interpret the advertisement as evidence that R1 has an alternate path to the destination.

Failure Scenario

The R2-R3 link fails.
R2 loses its working path to the directly connected LAN behind R3.
Without split horizon, R2 may still receive stale information from R1 claiming that R1 can reach 10.0.0.0/24.
R2 selects R1 as its next hop for the failed destination.
R1 still believes R2 is its next hop for the same destination.
Traffic from R1 goes to R2, and R2 sends the traffic back to R1.

R1: 10.0.0.0/24 via R2
R2: 10.0.0.0/24 via R1

Packet path: R1 -> R2 -> R1 -> R2 -> ...

This is a two-router forwarding loop caused by stale distance vector information and delayed failure propagation. Packets continue circulating until their IP TTL values expire or another mechanism removes the incorrect routes.

Event stage	R1 route state	R2 route state	R3 reachability	Potential forwarding result
Before failure	10.0.0.0/24 via R2	10.0.0.0/24 via R3	Reachable through R3	R1 -> R2 -> R3
Immediately after R2-R3 failure	May still point to R2	Direct path is gone; may have stale information	Unreachable from R2	Traffic may be sent toward a stale next hop.
After reflected information without split horizon	Still points to R2	May select R1	Unreachable from R2	R1 -> R2 -> R1 loop
After convergence	Route withdrawn or marked unreachable	Route withdrawn or marked unreachable	Still unreachable until restored	Packets are discarded or use a valid alternate path, if one exists.

Split Horizon and Other Loop Safeguards

Split horizon is one part of distance vector loop prevention. It reduces the chance that a route will be reflected to the neighbor that originally supplied it, but no single mechanism eliminates every possible loop in every topology or failure condition.

Mechanism	What the router does	Primary purpose	Example effect after a link failure
Split horizon	Does not advertise a learned route back through the learning interface.	Prevents simple route reflection.	R1 does not send its R2-learned route back to R2.
Route poisoning	Advertises a failed route with an unreachable metric.	Explicitly tells neighbors not to use the route.	R2 advertises the failed network with RIP's unreachable metric.
Poison reverse	Advertises a route back toward its source with an unreachable metric instead of omitting it.	Makes the reverse path explicitly invalid.	R1 tells R2 that the route learned from R2 is unreachable through R1.
Triggered update	Sends an update immediately after a significant route change instead of waiting for the normal update interval.	Speeds failure propagation.	Routers learn about a failed network sooner.
Hold-down timer	Temporarily limits acceptance of potentially incorrect route updates after a failure.	Prevents rapid acceptance of unstable information.	R2 temporarily rejects suspicious claims about the failed route.
Maximum hop count	Limits the metric a route can reach before it is considered unreachable.	Bounds persistent count-to-infinity behavior.	RIP eventually removes a route after its hop count reaches the unreachable value.

Route poisoning differs from split horizon. Split horizon omits a learned route on a particular interface. Route poisoning advertises the route as unreachable. Poison reverse is a specific variation in which the unreachable advertisement is sent back toward the route's source.

Where Split Horizon Is Used

Split horizon is a standard loop-reduction behavior in distance vector protocols. RIP commonly enables it by default on relevant router interfaces. EIGRP also uses split-horizon behavior, with protocol-specific configuration and verification details.

Because the rule concerns an outgoing interface, split horizon is generally configured or verified at the interface level, rather than being a universal property attached to a route in the routing table. Exact behavior can depend on the platform, interface type, protocol, and software release.

Hub-and-Spoke Multipoint Exceptions

Special care is required on a hub-and-spoke multipoint network. In this design, several spokes may connect through one shared physical or logical hub interface.

Suppose the hub learns a spoke's network on the shared interface. Default split horizon may prevent the hub from advertising that route out the same interface to the other spokes. The hub is obeying the normal rule, but the design may require the hub to relay one spoke's route to the others.

Disabling split horizon can allow spoke routes to be advertised out the shared hub interface. However, it can also reintroduce routing-loop risk. Do not disable it merely because route advertisements are missing. First determine whether the topology requires the exception, then test the result and confirm that other loop safeguards and addressing assumptions are correct.

Verifying Split Horizon and RIP

Verification should answer three questions:

Which router supplied the route?
Which interface and next hop will be used?
What routing updates are sent and received on each interface?

Cisco IOS Route and Protocol Commands

show ip route
show ip route rip
show ip protocols
show ip rip database
debug ip rip

show ip route displays the routing table, including route source, metric, next hop, and outgoing interface.
show ip route rip filters the table to RIP-learned routes.
show ip protocols shows routing protocol settings and participating interfaces.
show ip rip database displays RIP route information and metrics.
debug ip rip shows RIP updates being sent and received. Use debugging only in a controlled lab or maintenance context because it can generate substantial output.

Inspecting Interface Behavior

interface <interface-id>
ip split-horizon
no ip split-horizon

The no ip split-horizon form is an exception, commonly considered for certain multipoint hub-and-spoke deployments. Its exact applicability depends on the platform and interface type.

For EIGRP where supported, protocol-specific syntax may be used:

interface <interface-id>
ip split-horizon eigrp <autonomous-system-number>
no ip split-horizon eigrp <autonomous-system-number>

Validate EIGRP syntax and behavior against the documentation for the target platform and software release.

Minimal RIPv2 Lab Context

router rip
 version 2
 network <connected-network>
 no auto-summary

RIPv2 is useful for a lab because it advertises classless prefixes, such as 10.0.0.0/24, with their subnet masks.

Controlled Failure Test

Build the R1-R2-R3 topology and advertise 10.0.0.0/24 from R3.
Confirm that R1 learns the route through R2 and that R2 uses R3 as its next hop.
Inspect the routing tables and RIP database on all routers.
Simulate the R2-R3 link failure in a lab.
Observe route withdrawal, route poisoning, triggered updates, and timer-related changes.
Use a controlled ping or traceroute to confirm that traffic does not circulate between R1 and R2.
Review RIP debugging output only as needed, then disable debugging after the test.

Troubleshooting Common Symptoms

A Learned Route Appears to Return to Its Source

Possible causes include disabled split horizon, a topology with distinct interfaces, or confusion caused by a multipoint interface.

Verify the route source, next hop, and learned interface.
Review interface-level split-horizon settings.
Capture or debug routing updates in a controlled lab.

Traffic Alternates Between Two Routers

Repeated traceroute hops or traffic alternating between two routers may indicate stale distance vector information, incomplete convergence, or disabled loop-prevention mechanisms.

Inspect the route entry on both routers.
Check the failed interface and neighbor reachability.
Use traceroute and routing-update inspection to identify repeated hops and stale advertisements.
Look for rising TTL-related failures, packet loss, unstable routes, and excessive link utilization.

Spokes Cannot Learn Each Other's Routes

On a multipoint hub-and-spoke network, the hub may suppress routes learned from one spoke when sending updates through the same shared interface.

Confirm whether all spokes share one hub interface.
Compare received and transmitted routing updates at the hub.
Validate whether separate logical interfaces or a carefully tested split-horizon exception is appropriate.

Exam-Relevant Summary

Split horizon means: do not advertise a route out the interface where it was learned.
It controls routing updates, not normal packet-forwarding decisions.
RIP is the primary example; EIGRP also supports split-horizon behavior.
In the R1-R2-R3 example, R1 learns 10.0.0.0/24 from R2 and must not advertise that route back to R2.
Without split horizon, stale information can cause R1 and R2 to select each other as next hops.
Route poisoning advertises an unreachable metric; poison reverse sends that unreachable information back toward the source.
Split horizon is normally an interface-level behavior and may require special evaluation on multipoint hub-and-spoke networks.
Use routing-table, protocol, database, and update inspection commands to verify actual behavior.

For a related review, see Split Horizon Explained.