Preventing Count to Infinity Issues on Your Network - dummies

Preventing Count to Infinity Issues on Your Network

By Edward Tetz

The Counting to Infinity phenomenon can quickly disable a Distance Vector routing protocol managed network. The following sections explore ways to prevent count to infinity and the resulting routing loops from happening on your network.

Split horizon

If you are using RIPv1, you have a solution in the form of a concept called split horizon. In this concept, if you receive routing on one interface, sending that information back out of that interface is not likely to be productive.

So, if you examine only the routing information for the network in the routing process, the flow of the route information is passed as follows:

  1. Router2 learns of the route to

    It learns of the route through interface S0/1 facing Router3.

  2. Router2 sends its routing table updates.

    The updates go out through both of its interfaces, but filters the route to out of the list when it sends the routes out through interface S0/1, as shown in the following figure.

  3. Router1 receives the route to from Router2 on interface S0/0.

  4. Router1 sends its routing table updates.

    These updates go out through both of its interfaces, but filters the route to out of the list when it sends the routes out through S0/0.


Route poisoning

Rather than using split horizon, RIPv2 implements a process called route poisoning. Following is the sequence for the route poisoning process:

  1. Router3 identifies that the link to is down.

    The Router3 immediately updates its metric for that network to infinity — or in the case of RIPv2, a hop count of 16 — and sends that routing table update out immediately, as illustrated in Figure 6-7.

  2. Router2 gets the update.

    It then updates its own routing table by removing the route to, because it is no longer valid. After this update is complete, Router2 sends its own update out through interface S0/0.

  3. Router1 gets the update.

    This update no longer includes a route to, causing Router1 to remove the route to that network.


With router poisoning, the update process escalates so that improper route information is removed from the network in a timely manner. You can extend this system using a process called poison reverse.

In this case, after Router2 sees the hop count or metric go to infinity, it also sends a routing table update back to Router3 with an infinite metric telling it that the route to is no longer available. This process reduces the chance that an improper update will make it through to Router3 and cause a loop.

Hold-down timers

Hold-down timers are another solution to routing loops that some routing protocols implement. Hold-down timers prevent protocol update messages from improperly updating routes for links that are currently down. Following is the hold-down timers implementation sequence:

  1. Router2 receives an update telling it that the link to is down.

  2. Router2 marks the route as possibly down and sets a hold-down timer.

  3. Router2 waits for an update.

    • If it gets an update with a metric better than the original one, Router2 records the route as up and accessible.

    • If it does not get an update in the timer interval, Router2 removes the route from its routing table.

    • Routes that Router2 receives with a metric worse than the original route are automatically removed.

During the hold-down period, if any data is being sent to the network, the data is sent on as a delivery attempt. The delivery attempt is made in the event that the link to is having an intermittent problem.

Triggered updates

Triggered updates deal with count to infinity issues by forcing an update as soon as the link changes.

So, going back to the network layout you have been using, when the link to network goes down, Router3 sends an immediate update notifying its neighbors that the link is down. Router2 receives the update and immediately passes the update to its neighbors, such as Router1.

As part of its normal update schedule, Router2 might still receive another update from Router1 prior to getting the update to remove the route. The solution is to combine triggered updates with hold-down timers, which prevents routes with worse metrics from being added to a router’s routing table.