RIPv2 Overview

RIPv2 is a simple routing protocol - at least when compared to other major routing protocols like OSPF and BGP. The pros for using RIPv2 in a network is the ease of configuration and maintenance of the routes and also the network traffic generated by the protocol is somewhat less than that of other routing protocols. Also, most vendor equipment supports RIPv2 and so is a fairly common protocol to come by in smaller routing environments. The cons, however, are the protocols slow convergence time and lack of scalability.

Below are listed some of the quick hard facts of RIPv2. The below summary is based on the defaults of Cisco's implementation of RIPv2 - timers and the likes can vary from vendor to vendor.

• Defined in RFC 2453
• Supports classless routing operation (unlike RIPv1 which is only classfull)
• Runs on port UDP/520
• Sends updates to multicast address 224.0.0.9
• can be changed to unicast with the neighbor <ip address> command under the routing process
• can be changed to broadcast with the ip rip v2-broadcast command under a given interface
• Metric is based on hop count with 15 being the maximum and 16 being infinity (unreachable)
• The sending router increments the hop count in advertised routes before sending it out to its neighbors. Thus, receiving routers do not increment the metric, but enters the metric directly into its routing table
• Default administrative distance is 120
• It is driven mainly by timers
• Update timer: 30 sec.
• sends out the entire routing table every 30 sec. on RIP enabled interfaces (routes affected by the split horizon rule are excluded from the update)
• Triggered updates occur when a route change occurs and an update, including only the changed route, is sent out. Regular updates are unaffected by this and are still sent per the update timer interval
• Cisco implements a RIP_JITTER variable that randomly subtracts 0-15% from the 30 second timer to avoid the synchronization of routing updates with its neighbors. This changes the effective update interval to between 25,5 and 30 seconds
• Invalid timer: 180 sec.
• The invalid timer tracks the validity of a specific route. It resets to 0 whenever a route is received in an update and a route is considered invalid after 180 sec.
• After the invalid timer expires the route is advertised with a metric of 16 (unreachable) until it is purged from the routing table
• Holddown timer: 180 sec.
• After the invalid timer expires the holddown timer starts counting. Even if a valid route is received in an update, it will not be entered into the routing table until the holddown timer expires or the route is flushed from the routing table (either manually or by the timer)
• Flush after timer: 240 sec.
• The flush after timer (or garbage collection timer) starts counting after the last routing update is received - effectively counting alongside the invalid timer and subsequently the holddown timer
• By default, 60 seconds after the invalid timer expires (and only 60 seconds into the holddown timer) the flush after timer runs out and the route is purged from the routing table
• No neighbor adjacency is formed and no hello packets are sent
• An update message can contain up to 25 entries
• Supports authentication using plain-text or MD5 hashing
• RIPv2 is able to tag routes being redistributed into the routing process

Below is a packet capture of RIPv2 update (also known as a response) sent from 10.0.0.1 to a multicast address of 224.0.0.9. Worth noting is that the packet is filled with 25 network entries all with a metric of 1 except for the first entry being advertised with a metric of 16 due to a simulated network failure (interface shutdown) on the source router 10.0.0.2. Not shown in the screen dump is the subsequent packet sent from the router 10.0.0.2 including two additional subnets.

RIPv2 response message, including 25 entries

If we look deeper into one of the entries we can see that the entry includes a subnet mask (which is not included in RIPv1) making it possible to advertise variable length subnet masks (VLSM) - making it a classless routing protocol. Also, note the next-hop being set to all 0's, which means that the next-hop address is assumed to be the same as the source of the update (10.0.0.2).

RIPv2 response message entry

A short explanation of split-horizon is warranted. Split-horizon simply states that a router should not advertise a route out of the same interface that it learned it from. This is to prevent routing loops from occurring, but it can in some cases cause issues with routes not being sent to valid neighbors on DMVPN interfaces for example.