Distance Vector Concepts 157

Now Router C has an infinite-distance (metric 16 for RIP) route to 162.11.7.0, but Router B has a route to the same subnet, metric 2, pointing through Router C. So Router B now thinks that 162.11.7.0 can be reached through Router C, and Router C thinks that 162.11.7.0 is unreachable.

Because Routers B and C use the same update interval between updates, this process repeats itself with the next routing update. This time, Router B advertises metric 3, and Router C advertises an infinite (bad) metric for subnet 162.11.7.0. This continues until both numbers reach infinity, so this phenomenon is often called counting to infinity. Thankfully, each distance vector routing protocol implementation sets a metric value for which the number is considered infinite; otherwise, this process would continue indefinitely.

Split horizon solves the counting-to-infinity problem between two routers. Split horizon can be briefly summarized as follows:

All routes with outgoing interface x are not included in updates sent out that same interface x.

For example, in Figure 5-6, Router C’s route to subnet 162.11.7.0 points out Serial1, so Router C’s updates sent out Serial1 do not advertise subnet 162.11.7.0. Therefore, when Routers B and C’s updates pass each other, one update shows the route with an infinite metric, and the other says nothing about the route, so the counting-to-infinity problem goes away.

Figure 5-6 Complete Routing Update with Split Horizon Enabled

Because of split-horizon rules, Router B does not advertise routes to subnets 162.11.6.0 or 162.11.10.0 in updates it sends to Router C. Similarly, Router C does not advertise routes to subnet 162.11.7.0 in updates sent to Router B. Because Router C does not advertise a route to 162.11.7.0 out its Serial1 interface, the counting-to-infinity problem over the serial link no longer occurs.

Split Horizon with Poison Reverse

So far, you have read about how split horizon and route poisoning work. However, Cisco distance vector routing protocols actually use a variant of split horizon called split horizon with poison reverse (or simply poison reverse). When the network is stable, it works just like plain old split horizon. When a route fails, the router advertises an infinite-metric route about

158 Chapter 5: RIP, IGRP, and Static Route Concepts and Configuration

that subnet out all interfaces—including interfaces previously prevented by split horizon. Figure 5-7 shows the pertinent contents of the routing update from Router C, using split horizon with poison reverse.

Figure 5-7 Split Horizon Enabled with Poison Reverse

162.11.7.016

As Figure 5-7 illustrates, after Router C hears of the infinite metric (metric 16 for RIP) route to 162.11.7.0, it then ignores split-horizon rules for that route and advertises the subnet back to Router B with an infinite metric. Using split horizon prevents counting to infinity, and adding poison reverse ensures that all routers know for sure that the route has failed. Both RIP and IGRP use split horizon with poison reverse by default in a Cisco router.

Hold-Down Timer

Split horizon solves the counting-to-infinity problem over a single link. However, counting to infinity can occur in redundant networks (networks with multiple paths) even with split horizon enabled. The hold-down timer defeats the counting-to-infinity problem when networks have multiple paths to many subnets.

Figure 5-8 shows the version of the counting-to-infinity problem that split horizon does not solve but that holddown does solve. Subnet 162.11.7.0 fails again (someone should check the cabling on that Ethernet!), and Router B advertises an infinite-metric route for subnet 162.11.7.0 to both Router A and Router C. However, Router A’s update timer expires at the same time as Router B’s timer (shown as the circled number 1s in the figure), so the updates sent by Routers A and B occur at the same time. Therefore, Router C hears of an infinitedistance metric to that subnet from Router B, and a metric 2 route from Router A, at about the same time. Router C correctly chooses to use the metric 2 route through Router A. Table 5-7 lists the pertinent information about Router C’s routing table entry for subnet 162.11.7.0 after the updates shown in Figure 5-8.

After the updates labeled with a 1 in Figure 5-8, Router C thinks it has a valid route to 162.11.7.0, pointing back to Router A. So, on Router C’s next update (the circled 2 in Figure 5-8), it does not advertise subnet 162.11.7.0 out S0 because of split-horizon rules. However, Router C does advertise 162.11.7.0 out Serial1 with metric 3. Now Router B believes it has a valid route, metric 3, to subnet 162.11.7.0. Router B, in its next update (not shown in the figure), also tells Router A that it has a route to 162.11.7.0, this time with metric 4. So counting to infinity occurs even though split horizon is enabled.

Distance Vector Concepts 159

Figure 5-8 Counting to Infinity with a Need for Holddown

Table 5-7 Router C Routing Table After the Updates Shown in Step 1 of Figure 5-8 Are Received

Distance vector protocols use a hold-down timer to defeat these types of counting-to-infinity problems. The concept is simple—as soon as you see the problem. Holddown is defined as follows:

When learning that a route has failed, ignore any information about an alternative route to that subnet for a time equal to the hold-down timer.

With holddown enabled, Router C does not believe the metric 2 route learned from Router A in Step 1 of Figure 5-8 for some period of time. During the same time, Router B advertises infinite-metric routes to 162.11.7.0 to Routers A and C, and then Router A starts advertising an infinite-distance route to Router C. In effect, all routers ignore good routing information about that subnet until enough time passes so that everyone has heard the old, bad information. Essentially, the hold-down timer means that the routers just need to exercise a little patience while everyone learns that the route has failed, preventing loops. It is much better to wait a little longer for convergence to prevent the problems caused by looping packets.