Split horizon will break loops between neighbors, but it will not stop loops in a network such as the one
in Figure 4.6. Again, 10.1.5.0 has failed. Router D sends the appropriate updates to its neighbors router C
(the dashed arrows) and router B (the solid arrows). Router B marks the route via D as unreachable, but
router A is advertising a next-best path to 10.1.5.0, which is 3 hops away. B posts that route in its route
table.
B now informs D that it has an alternative route to 10.1.5.0. D posts this information and updates C,
saying that it has a 4-hop route to the network. C tells A that 10.1.5.0 is 5 hops away. A tells B that the
network is now 6 hops away.
"Ah," router B thinks, "router A's path to 10.1.5.0 has increased in length. Nonetheless, it's the only route
I've got, so I'll use it!"
B changes the hop count to 7, updates D, and around it goes again. This situation is the counting-toinfinity
problem because the hop count to 10.1.5.0 will continue to increase to infinity. All routers are
implementing split horizon, but it doesn't help.
NOTE
Defining infinity
The way to alleviate the effects of counting to infinity is to define infinity. Most distance vector protocols
define infinity to be 16 hops. As the updates continue to loop among the routers in Figure 4.6, the hop
count to 10.1.5.0 in all routers will eventually increment to 16. At that time, the network will be
considered unreachable.
This method is also how routers advertise a network as unreachable. Whether it is a poisoned reverse
route, a network that has failed, or a network beyond the maximum network diameter of 15 hops, a router
will recognize any 16-hop route as unreachable.
Setting a maximum hop count of 15 helps solve the counting-to-infinity problem, but convergence will
still be very slow. Given an update period of 30 seconds, a network could take up to 7.5 minutes to
reconverge and is susceptible to routing errors during this time. The two methods for speeding up
reconvergence are triggered updates and holddown timers.