split horizon
termA distance-vector routing rule: never advertise a route back out the interface you learned it from.
Documented in RFC 1058, the 1988 RIP specification, split horizon breaks the simplest routing loop: without it, two neighbors can advertise a dead route back and forth, counting the metric up toward infinity while traffic ping-pongs. The stricter variant, split horizon with poison reverse, does advertise the route back but with an infinite metric (16 in RIP), which kills the loop faster at the cost of bigger updates. The idea outlived RIP: iBGP applies its own split-horizon rule, refusing to re-advertise a route learned from one iBGP peer to another, which is exactly why iBGP needs a full mesh or route reflectors. Not to be confused with split brain, an unrelated high-availability failure that happens to share the adjective.
The rule survives inside link-state protocols wherever they pass summaries instead of maps. Between OSPF areas only summaries and external routes travel, and FRRouting's documentation draws the conclusion that routing between areas is distance vector, not link state. RFC 2328 then applies the old rule: an area border router does not originate a summary of a route back into an area when the route's next hops lie in that same area, which the RFC calls the logical equivalent of split horizon. OSPF also forces inter-area routing into a star, with area 0 as the hub.
IS-IS meets a similar loop between its levels: a prefix leaked from Level 2 down into a Level 1 area could be picked up by another router and advertised back up into the backbone. RFC 1195's answer was to allow advertising only upward; RFC 5305 records the later remedy for leaking, the up/down bit, set to 1 when a prefix travels down so that it may only continue down the hierarchy.
Sources
- RFC 1058 - Routing Information Protocol (split horizon)
- RFC 2328, OSPF Version 2, April 1998: sections 3.2 and 12.4.3 (read 2026-10-19)
- FRRouting documentation, OSPFv2 (ospfd), latest: Areas (read 2026-10-19)
- RFC 5305, IS-IS Extensions for Traffic Engineering, October 2008: section 4.1 (read 2026-10-19)