Routing Protocols – Part 4

Continuing our discussion of techniques for improving the performance of Distance-Vector routing protocols, imagine that we have a topology route_image2consisting of three routers (R1, R2 and R3) in a triangle, with each router directly connected to the other two (a full mesh). R1 also has a directly connected stub route, 10.1.0.0/16, for a total of four subnets.

Once the network has converged, the situation will be:

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

Since R2 and R3 consider R1 to be their best next hop to reach 10.1.0.0/16, per the split-horizon rule neither R2 nor R3 is advertising 10.1.0.0/16 to R1, but they are advertising it to each other. Let’s assume that R1 loses its connection to the 10.1.0.0/16 subnet, and thus from the routers’ perspectives we now have:

  • R1 sees 10.1.0.0/16 as unreachable
  • R2 sees 10.1.0.0/16 as reachable via R1 (one hop)
  • R3 sees 10.1.0.0/16 as reachable via R1 (one hop)

Notice that R2 and R3 are currently mistaken as to the state of 10.1.0.0/16. At this time, R1 sends flash updates to R2 and R3, poisoning the route to 10.1.0.0/16. Let’s imagine that R2 processes the flash update prior to R3. The situation at this moment is:

  • R1 sees 10.1.0.0/16 as unreachable
  • R2 sees 10.1.0.0/16 as unreachable
  • R3 sees 10.1.0.0/16 as reachable via R1 (one hop)

Notice that R3 is currently mistaken. Let’s imagine that just before processing the flash update it received from R1, R3’s periodic update timer expires, so R3 sends its routing table to R2. The current situation is:

  • R1 sees 10.1.0.0/16 as unreachable
  • R2 sees 10.1.0.0/16 as reachable via R3 (two hops)
  • R3 sees 10.1.0.0/16 as reachable via R1 (one hop)

Now R2 and R3 are both mistaken. Since R2 did not receive its best (and only) route for 10.1.0.0/16 from R1, it’s free to advertise the route to R1 via a flash update, which it does, resulting in:

  • R1 sees 10.1.0.0/16 as reachable via R2 (three hops)
  • R2 sees 10.1.0.0/16 as reachable via R3 (two hops)
  • R3 sees 10.1.0.0/16 as reachable via R1 (one hop)

Now all three routers are mistaken. Since R1 learned the best route to 10.1.0.0/16 from R2, it will not advertise it to R2, but it will advertise it to R3, giving us:

  • R1 sees 10.1.0.0/16 as reachable via R2 (three hops)
  • R2 sees 10.1.0.0/16 as reachable via R3 (two hops)
  • R3 sees 10.1.0.0/16 as reachable via R1 (four hops)

At this point, we have a routing loop, in which R1 advertises 10.1.0.0/16 to R3, R3 advertises it to R2, R2 advertises it to R1, etc. The result of this will be that data packets bound for 10.1.0.0/16 (which is actually unreachable by any router) will loop in the direction opposite to that taken by the routing updates.

As discussed before, each individual packet that becomes caught in the loop will be discarded when its TTL reaches zero, and the routing loop itself will end when the metrics count up to the maximum value. What it comes down to is that split horizon does not prevent routing loops in topologies that include three or more routers connected in a physical loop. To solve this problem, the “Hold Down” timer was introduced, which we’ll discuss in the next installment.

Author: Al Friebe

In this article

Join the Conversation