Routing Protocols – Part 2

The Distance-Vector (D-V) protocols such as RIP work, but they’re not perfect. Let’s imagine that we have two routers (R1 and R2) and three subnets (10.1.0.0/16, 10.2.0.0/16 and 10.3.0.0/16), connected in a string, like this:

  • 10.1.0.0/16 – R1 – 10.2.0.0/16 – R2 – 10.3.0.0/16

Once the network has converged, both routers will know the best path to each of the three subnets. Looking specifically at the 10.3.0.0/16 subnet:

  • R2 sees 10.3.0.0/16 as directly connected  (zero hops)
  • R1 sees 10.3.0.0/16 as reachable via R2 (one hop)

Imagine now that the 10.3.0.0/16 subnet becomes unreachable, and R2 removes it from its routing table. Since we’re running RIP, a D-V protocol, each router is periodically flooding its routing table. At this moment R1, which is not yet aware of the change, sends its table to R2. As a result, R2, which can no longer reach 10.3.0.0/16 directly, now thinks that it can reach that subnet via R1, and that it is two hops away:

  • R2 sees 10.3.0.0/16 as reachable via R1 (two hops)
  • R1 sees 10.3.0.0/16 as reachable via R2 (one hop)

When R2 next floods its routing table, R1 will see that 10.3.0.0/16 is now reachable via R2, and that it’s three hops away:

  • R2 sees 10.3.0.0/16 as reachable via R1 (two hops)
  • R1 sees 10.3.0.0/16 as reachable via R2 (three hops)

When R1 next floods its routing table, we’ll have:

  • R2 sees 10.3.0.0/16 as reachable via R1 (four hops)
  • R1 sees 10.3.0.0/16 as reachable via R2 (three hops)

And after R2’s next update:

  • R2 sees 10.3.0.0/16 as reachable via R1 (four hops)
  • R1 sees 10.3.0.0/16 as reachable via R2 (five hops)

There are two things to note about the current situation. First, R1 thinks that it can reach 10.3.0.0/16 via R2, and R2 thinks that it can reach it via R1. The truth is that neither router can reach that subnet. The effect of this is that any packet destined for 10.3.0.0/16 will be caught in a routing loop between R1 and R2. This is bad because as R1 and R2 ping-pong the packet it’s wasting their time, as well as wasting bandwidth on the link between them. Fortunately the packet will not loop forever, because eventually the TTL of the packet will hit zero, at which time the packet will be discarded (see RFC 1812 for details).

Second, you’ll notice that the metrics are increasing with every update cycle. This behavior is referred to as the “count to infinity”, and it is a symptom of a routing loop in a D-V protocol. When the metric hits the maximum as determined by the number of bits in the metric field, it will next go back to zero, and the cycle will repeat.

It’s important to note that for a particular data packet that’s caught in the loop, the TTL field in the packet’s IP header is counting down towards zero (at which point the packet is discarded), while the metric fields in the routing tables are counting up to the max (at which point the cycle repeats). While an individual packet does not loop forever, the loop does last forever.

One could make the case that since the 10.3.0.0/16 subnet is unreachable, the fact that traffic for that subnet loops is a non-issue. However, since the looping traffic gets in the way of other traffic, this is not the case. Thus, having routing loops for unreachable destinations is sub-optimal, and we want the entries for any unreachable subnets removed from all routing tables as quickly as possible.

Next time, we’ll look at some techniques used with Distance-Vector protocols to solve the looping problem, and to speed convergence.

Author: Al Friebe

In this article

Join the Conversation

1 comment

  1. Narinder Pal Singh Reply

    You know guys this was simply the best explanation I have come across as long as the Routing Loop and the Count to infinity problem is talked about. Thanks a lot , it was just a matter of time of reading it and understanding everything. Thanks CHEERS!