One of the first routing protocol that you would ever learn is the Routing Information Protocol (RIP). It is an Interior Gateway Protocol (IGP), and it uses a distance-vector algorithm called Bellman-Ford Algorithm. Here are my brief notes on what the protocol is and how it works.
The protocol has two versions RIPv1 and RIPv2. Both are in use today and have significant differences. UDP is used to transmit updated. The UDP port is 520. The IPv6 version is called RIPng.
Neighbors exchange their complete routing table at regular interval of 30 seconds (default). This is called the update timer. There is no session formation between RIP neighbors. Once RIP is enabled on a network subnet, it immediately starts sending the RIP updates.
Differences between RIPv1 and RIPv2
RIPv1 | RIPv2 |
---|---|
Update Message is sent to local subnet broadcast address viz. 255.255.255.0 | Update Message is sent to multicast address 224.0.0.9 |
No authentication support is available | Support available for both plain text and MD5 authentication. |
VLSM support not present. Hence RIPv1 is classful. Only the default subnet masks of Class A (/8), Class B (/16) and Class C (/24) addresses are used. These subnet masks are not sent in the updates. When the routes are received, the masks are derived from the addresses. | Supports VLSM. The subnet mask is carried in the updates and hence RIPv2 is classless. Also RIPv2 can still come up when a network is discontiguous due to this feature. |
Doesn’t allow a router to advertise a different next-hop router than itself. | Supports Next Hop field in the Update message. Hence a router can specify another router as a next-hop. |
RIP Timers
RIP uses four different timers which help in maintaining the routing table and helps in avoiding loops. All these timers are per route. These are:
- Update timer (30 secs) – This is the interval which states how often the update for a specific route must be sent.
- Invalid timer (180 secs) – This is the interval which states that once an update is received for a route how long to wait till the route is considered invalid or non-reachable.
- Hold down timer (180 secs) – If a route gets a worse metric and is updated, the hold down timer is started. During this time no other metric for the route is accepted which is equal or worse than the current metric.
- Flush or Garbage timer (240 secs) – This is the interval which states how long to wait since the last valid update before removing the route from the routing table.
Whenever a valid update is received from a neighbor, the update, invalid and flush timer resets to 0. The hold down timer resets to 0 whenever a metric value decreases.
RIP uses hop count as the metric. So in case, a prefix is received from multiple paths, the prefix with a smaller no of hops will be preferred. RIP allows up to 15 hops. 16 hops and above are considered to be infinite, and those routes are deemed to be unreachable. This limit in the number of hops prevents loops. Unlike other protocols like OSPF and ISIS, which are link state protocols and whose implementation itself ensures loop-free network, RIP uses some specific concepts which help in loop prevention. This makes RIP a great protocol in terms of implementation, but this also introduces a more substantial convergence time.
Loop Prevention Concepts in RIP
- Split Horizon – Even though in RIP the entire routing table is sent to the neighbors, RIP omits the routes which has been advertised by the neighbor to whom the update is being sent. In other words, if the outgoing interface of a route matches the interface out of which the new update is to be sent, then that route is omitted.
- Route Poisoning – When a route’s reachability fails, the update is sent with the metric of that route as 16 (infinite) thereby specifying to the neighbors that the route is unreachable.
- Poison Reverse – In this case, the route with an infinite metric is advertised out the same interface through which it is received with the same infinite metric. Split Horizon with Poison Reverse is used together in most of the cases.
Originally published on Shubho.Dev
Featured Image courtesy Jordan Harrison at Unsplash
Top comments (0)