In RIP, how does simple split horizon differ from split horizon with poisoned reverse, and why is poisoned reverse considered safer?

## The problem both rules solve In RIP, a router that learned a route from a neighbour has nothing useful to tell that neighbour about it: the neighbour's path cannot run back through the router without forming a loop. Without a rule, the router would advertise the route back anyway, and if the neighbour later lost its own path it could take that echo for an alternative. RFC 2453 calls this "mutual deception" — two routers each claiming to reach a destination through the other. **Split horizon** is the family of rules that stops the echo. ## Simple split horizon **Simple split horizon** omits a route from updates sent to the neighbour it was learned from. - On a point-to-point link, that is one neighbour. - On a broadcast network the rule is per network: every route learned from any router on that segment is left out of the update sent onto it. The other routers there can reach the source directly, so none needs a path through you — which is also why one update can serve the whole segment. - It costs nothing on the wire; updates actually get smaller. Its weakness is that it is passive. If two routers already have routes pointing at each other — after a lost update, say — silence does not correct them. In the RFC's words, if reverse routes "are simply not advertised, the erroneous routes will have to be eliminated by waiting for a timeout." ## Split horizon with poisoned reverse **Poisoned reverse** includes those routes but sets their metric to 16, RIP's infinity. The update now says explicitly: do not use me for this destination. - A neighbour whose route points at you receives 16 from its own next hop, must believe it, and drops the route at once. - RFC 2453 therefore calls it safer: "If two routers have routes pointing at each other, advertising reverse routes with a metric of 16 will break the loop immediately." - The cost is size. The RFC's example is a campus backbone where each building router has a few local networks. With simple split horizon each router advertises only those; with poisoned reverse it must also list every route it learned from the backbone, at 16 — "a large update message, almost all of whose entries indicate unreachable networks." ## Side by side | | Simple split horizon | Split horizon with poisoned reverse | |---|---|---| | Route learned from neighbour N, in the update to N | omitted | sent with metric 16 | | Two routers already pointing at each other | cleared only by a timeout | cleared by the next update | | Update size | smallest | grows with the routes learned on that interface | | RFC 1812 requirement | MUST implement | SHOULD implement; MAY be switchable | ## What the standards ask 1. RFC 1812, the IPv4 router requirements, says a RIP implementation **must** implement split horizon and **should** implement split horizon with poisoned reverse, and may offer an option to choose. 2. It also says an implementation **should** limit how long it sends reverse routes at infinity: its algorithms poison a route for one route lifetime (typically 180 seconds) after the route changes, then fall back to omitting it. 3. RFC 2453 allows hybrids of exactly that kind, and RFC 2080 (RIPng) calls poisoned reverse the preferred method while asking for a per-interface choice between no split horizon, simple split horizon and poisoned reverse. ## The limit of both Both rules look at a single fact: which neighbour a route was learned from. That catches a loop between two routers. It does not catch a loop around three or more, because each router's stale route reaches the next router from a different direction, never back toward its own source. RFC 2453 says so plainly — split horizon "cannot stop such a loop" — and such loops end only when the metric counts up to 16. Triggered updates make them unlikely, not impossible.