RIP is probably one of the oldest routing protocols and if i'm honest, it should stand for Rest In Peace instead of Routing Information Protocol. In saying that, at one stage it was a great little lightweight protocol. RIP is a distance vector routing protocol that uses hop count as a metric. Each router in the path to a network is considered a hop.
RIP has 2 versions (well 3 if we include IPv6 but i'll talk about RIPng later), RIPv1 and, you guessed it, RIPv2. RIPv1 is based on classful routing and will only send routing information in full Class A, B or C ranges. RIPv2 improves on that by allowing classless information to be send between RIP routers meaning that subnet masks are included in the routing updates.
RIPv1 as mentioned above, is a classful routing protocol meaning that it only advertises classful subnets. If you have multiple interfaces in the 172.16.0.0/16 range, RIP will only advertise the classful subnet 172.16.0.0/16. When a RIP router starts, it will send out a broadcast Request message using UDP port 520, out all RIP enabled interfaces. The router will then wait for a RIP reply. When a router receives a RIP Request message, the contents of it's entire routing table is send in the RIP Reply. When the reply is received, the RIP router will look at the information and determine if there are any new routes, or route changes such as a different metric value. If so, the router will update the route table with the new information.
By default RIPv1 will send out response messages every 30 seconds, however the RIP update timer uses a random variable to prevent route table synchronisation and means that the actual timer could be between 25 and 35 seconds. These response messages contain the full routing table with the exception of routes that fall into the split horizon rule. The split horizon rule prevents a router from advertising a route back on the interface from which it was learned. For example, take the below three router topology. R3 advertises, 10.0.0.0/8 to R2, and R2 advertises the same route to R1. R1 would also advertise this back to R2 but split horizon would prevent R2 from accepting the route.
In order for a RIP route to stay in the route table, it must receive response messages from neighbours advertising the route. If a RIP router does not see a specific prefix in the response message for a period of the expiration timer/invalid timer (180 seconds by default), the route is marked as having a hop count of 16 and unreachable. The router will then advertise to all other RIP routers that the route is unreachable for a period of the garbage collection or flush timer (240 seconds by default) and then remove from the route table.
Below is the format of the RIPv1 header
Note, that if a router includes more than 25 routes in its RIP update, then multiple RIP messages must be sent. Also notice that no subnet mask information is sent in RIPv1 updates. RIPv1 and v2, can be configured to use unicast messages towards neighbouring RIP routers if you specifically configure a neighbour IP using the router rip configuration subcommand neighbor <neighbour-ip>. In the below packet capture you can see that the RIP messages are sent to the unicast address 10.1.12.2.
To configure RIPv1, use the global configuration command router rip followed by the rip configuration subcommand version 1. Once you have enabled RIP on the router, you need to configure the interfaces that RIP should advertise routes on. You do this using the RIP configuration subcommand network <network>. When configuring RIP, you do not need to specify a subnet mask, you only need to configure the full classful network for RIPv1. The same applies for RIPv2 but you can specify classless subnets as well with RIPv2.
As you can see, even if you enter the full classless network range, RIPv1 only configures the classful subnet.
RIPv2 makes improvements over RIPv1 such as:
- sending subnet mask information in routing updates
- authentication of routing updates
- next-hop-address carried with each route
- External route tags
- multicast route updates
The biggest improvement would have to be the sending of subnet mask information in routing updates allowing RIPv2 to become a classless routing protocol. All of the timers and operational procedures of RIPv2 are the same as v1, except for the broadcast of messages. RIPv2 uses the multicast address 184.108.40.206 to send updates instead of broadcasting them throughout the network reducing overhead of devices that don't need to receive RIP messages.
To support these extra features RIPv2 messages include additional fields in the header information as seen below. RIPv2 messages are still sent using UDP port 520.
As you can see the subnet mask information is sent in the header allowing for classless routing to be used. Notice from the packet header that the 220.127.116.11/32 subnet however is still advertised as 18.104.22.168/8 yet the 10.1.14.0/24 subnet is advertised correctly as a /24 subnet? This is because by default cisco rioters running RIP auto summarises networks that are contiguous. This is why 10.1.14.0/24 is advertised correctly because it is being advertised out an interface that exists within the auto summarised network range of 10.0.0.0/8. In order to turn off auto summary use the RIP router configuration subcommand no auto-summary.
Configuring RIPv2 is pretty straight forward. You first tell the router to use the rip routing protocol by using the global configuration command router rip. You then need to tell the router to use RIPv2 by using the command version 2. The rest of the RIP configuration is the same. You must now configure the interfaces that RIP you up will be enabled on using the command network <network>. I will also disable auto summarisation using the command no auto-summary.
R1 and R2 have 2 interfaces in the 10.0.0.0/8 subnet range. When configuring RIP, regardless of version, you only need to specify the classful network range for this. If you don't want an interface to send RIP messages, you can use the router rip subconfiguration command passive-interface <interface> command.
Verifying RIP Routes
To verify that a router is receiving RIP routes, you can look at the route table using the show command show ip route. You can also specify the rip keyword at the end of that to only show RIP routes.
You can also look at the routers RIP database in order to see what routes are being advertised and what routes are being learned and what their next hop address and interface are using the command show ip rip database.
Authentication of RIP messages is another feature added to RIPv2. Authentication helps prevent malicious users from altering route tables and using a man in the middle attack or other malicious attack on our route tables. RIPv2 supports 2 methods of authentication:
- plain text
- MD5 hash
There are obvious issues with using plain text passwords. If an attacker has a packet capture tool running on the network, they are able to capture the RIP messages and clearly see the password.
Using an MD5 hashing algorithm encrypts the entered clear text password in an MD5 hash. This MD5 hash of the clear text password that you enter, is not reversable.
To configure RIP authentication, you must configure key-chains. Key-chains are a flexible way of configuring 1 or more passwords that are used for authentication. They can even be used based on date and time. To configure a key chain, use the global configuration command key chain <name>. Once you are in key-chain configuration submode, you need to configure the key number using the command key <number> where the number can range from 0 to 2147483647. You then need to configure the password string to use using the command key-string <0|6|7> <password>. If you specify the keywords 6 or 7, then you need to enter the hashed password in after. If you specify 0, then you can enter the clear text password.
Now that we have the key chain configured, we need to tell the router which interface to use RIP authentication on. You do this using the interface configuration subcommand ip rip authentication key-chain <name> where name, is the name of the key chain you specified in the previous step. Once you have done that, if you choose to use MD5 hashing, you then need to enter the interface configuration subcommand ip rip authentication mode <md5|text>.