This post is part of a series of posts about dynamic routing protocols and especially RIP. We’ll try to get a deep understanding of its operation and function as an introductory to dynamic routing logic in general. You’ll see that what we think easy may hide an incrementing complexity…
a little introduction
Berfore we start lets recall that RIP or Routing Information Protocol is one of the so-called distance vector IGP protocol or Interior Gateway Protocols that is, its routing decision is based on a metric. This metric is calculated based on the distance (of the router) from the destination in terms of the number of hops (intermediate networks or routers) that separate the source (or forwarding router of trafic from the source) from the destination. For example, from a router perspective, a path to a destination that is two hops away from the destination is better than a path using three or more hops to the same destination…
let’s focus on times used by RIP
One of important aspects of the operation of any implemention of RIP is the timers it uses to maintain its routing information state up to date. It is also interesting to keep in mind this times when trying to understand the logic of operation of these implementations. The great news is that all these implementations agree on these timers: RIP is standardized allowing an integrated network in terms of multi vendor use of technologies such as: Cisco, Alcatel, etc.
Cisco RIP
Cisco’s RIP implementation defines 4 times (more precise to say time than timers) tight to one periodic update interval and 3 states of route information: invalid, hold-down and flush.
The misleading information is that they are referred to as “timers” in the configuration part!
Apart from the periodic update interval the other times correspond to exactly 2 timers that are attached to the route prefix and to path descriptors respectively. It is to note that every network route in routing table is coded as a prefix descriptor that matches one or many path descriptors. That is a route may have multiple patch attached to a specific destination; a route that has no path to destination is not usable!
To a path descriptor we associate the invalid timer so that a route path is invalidated after the invalid time has expired. This is the first timer. Let’s observe also that if multiple paths are attached to a route and one route is being invalidated, this does not mean that the route enters the down and hold down state…
Then to each prefix we associate only ONE timer (this is the second timer) that moves the prefix to garbage state after holddown state (after not receiving an update about the last valid path for 180 seconds by default corresponding to 6 times the update interval by default but are no correlated such as), and removes it from the routing table after garbage time has elapsed (that is the flush time).
more precisions on timers
In addition to the previous elements let’s note also that:
- Holddown and garbage timer (the first timer for both times) runs separately from invalidation path timer (the second timer);
- More interesting is that only the garbage time is a specification of the 1058 RFC, the recommendation of the workgroup to vendors on how to implement RIP solution;
- Each prefix (that is a route in the routing table) can be in one of this states: valid, holddown, or garbage;
- A prefix in holddown state can not be updated!
The 2 timers are reset every time an update is received which is different from the peridioc interval that triggers an update each time this constant time interval has fired…
further more
To help understand more the operation of those timers please consider our post: RIP time(r)s: let’s understand the flush operation (time) you’ll have the ability to reproduce the same test network and observe how real routers behave, gain more understanding and tools for troubleshooting also (show and debug commands).
