Distance Vector basics

A vector protocol transmits the destination prefix to its directly connected neighbors. Each neighbor, when it receives the route information, modifies the information in such a way that the route information indicates the distance from that router to the originating router. For example, RIP increases the router hop count by one. The modified route is then added into the router's routing table. Only then is the route sent to that router's own directly connected neighbors,

Processing of the update messages involves two steps. First, the advertised hop count is incremented by one. If router B tells router A that a destination prefix is two hops away from itself, router A increments the hop count to three to indicate its own distance to the destination.

If the route table already contains an entry for the processed route, the hop counts are compared. If the newly incremented hop count of the received route is equal to or greater than the hop count of the existing entry, no change is made. But if the hop count of the received route is less than the hop count of the existing entry, the entry is replaced by the new route. In this way, the shortest route to each destination is maintained in the routing table.

• Each router along a path plays a part in the route calculation. If any router makes a mistake in its calculation, all subsequent routers inherit the mistake.
• A router cannot update its neighbors about a route until it has performed its own route calculation.

This is significant because the processing at each router takes some finite amount of time.

If the processing time at each router is t, then the time for a route to be processed across three routers is 3t, and across six routers 6t. If the route includes many router hops, the convergence time the time for the last router on the path to correctly enter the route into its routing table can be unacceptably long.

• If a destination is not directly connected, all a router knows about the destination is what a directly connected neighbor tells it.

The neighbor might be mistaken, or might even give you intentionally incorrect information. It cannot "see" the entire network topology.

Split-horizon - Because vector protocols process updates hop by hop, the updates for a particular destination should always flow Downstream that is, away from the destination. Updates should not flow upstream toward a destination; this can help only in liner networks

In case of an indirect link failure in a mesh network there is a possibility that the downstream routers can be confused about the network topology

• Imagine a very small time period in which two things happen 

D sends a periodic unsolicited update to C before it processes the update from B.

C receives and processes the update from B before receiving the update from D.

Router C has already processed the update from B and knows that 10.1.1.0 is no longer reachable through that neighbor. But then it receives the update from D, claiming it can reach 10.1.1.0 2 hops away. C assumes this information is accurate (remember, a vector protocol only knows what its neighbors tell it), and makes an entry in its routing table indicating that the previously unreachable 10.1.1.0 is now reachable via D, three hops away.

The new route at C triggers an update to B, which now thinks 10.1.1.0 is reachable from C, four hops away. B updates D, which records the subnet reachable via B, five hops away.

D then sends this information to C. When C receives this new update, the route is compared with the existing route table entry. The existing entry says that 10.1.1.0 is three hops away, whereas the new route shows the same subnet six hops away. However, both the existing route and the new route came from router D.

Therefore, C must assume that the new entry describes the same route, and that the distance has increased for some unknown reason. So, C replaces the existing route with the new one. Another consequence of "I only know what my neighbors tell me."

C then updates B, which increments its route to seven hops and updates D, which increments its route to eight hops and updates C, and so on. Because this circular pattern of updates could go on, theoretically, until the hop count reaches to infinity, the problem is called counting to infinity.

The ill effects of counting to infinity can be limited by defining a finite value at which a route is considered unreachable. RIP, for example, defines an unreachable route as being 16 hops. In our example, the first router to increment the route to 16 hops marks the route as unreachable and then updates its downstream neighbor that the route is unreachable. Such a procedure eventually stops the counting to infinity loop, but it does not prevent the loop.

A solution for preventing the counting to infinity problem is a holddown timer. If a router learns a route from a neighbor and then hears from that same neighbor that the route has become unreachable, a holddown timer is set for the route. Until the timer expires, the router will not accept any new information about that destination unless either

• The information comes from the same neighbor that announced that the route was unreachable; or
• Another neighbor advertises a route to the destination with a distance that is equal to or less than the distance of the original route.