Split Horizon

It should be fairly obvious that the looping problem described in the "Counting to Infinity" section could be prevented with the application of logic. The term used to describe this logic is split horizon. Although RFC 1058 RIP doesn't support split horizon, understanding it will facilitate understanding its somewhat more complicated variant, split horizon with poisoned reverse. The essence of split horizon is the assumption that it is not useful to advertise routes learned from an interface back out to the network attached via that interface. Figure 8-16 illustrates this point.

Figure 8-16: A split horizon.

Figure 8-16: A split horizon.

In Figure 8-16, the routers support the split horizon logic. Therefore, Router C (which supports the only path to Router D) cannot receive updates from Router A about Network D. This is because A relies on C

(and even B) for this route information. Router A must omit from its routing table information about routes learned from C. This simple approach to splitting loops can be relatively effective, but it does have a serious functional limitation: By omitting reverse routes from advertising, each node must wait for the route to the unreachable destination to timeout. In RIP, a timeout occurs only after six update messages fail to update a route. Therefore, a misinformed node has five opportunities to misinform other nodes about an unreachable destination. It is this time delay that creates the opportunity for invalid routing information to start the loop.

Due to this limitation, RIP supports a slightly modified version known as Split Horizon with Poisoned Reverse.

0 0

Post a comment