Routing Information Protocol (RIP) version 2
Published: 01/09/2010
Reference trace files:
cisco_2600_rip_v2_enable.cap
cisco_2600_rip_v2_enable_second_router.cap
cisco_2600_rip_v2_after_unplug_one_route.cap
cisco_2600_rip_v2_after_restore_one_route.cap
RIP is one of those really old routing protocols. If you say its name, dust starts gathering on your shoulders for some reason. Nevertheless, it's a standard protocol which in a pinch works, but in the long run you would probably never run in a production network because it's slow to converge and doesn't offer a lot of scalability. Unless you like pain. To each his own.
Although version 2 offers some extras like classless routing, multicast-based routing updates, and authentication, it's still a protocol of last resort since you have OSPF at your side (or if you're a complete Cisco shop, then EIGRP as well). But any potential CCNA test candidate is still required to know something about it because you never know when that one small business you end up being a consultant for one day still uses it, along with NetWare, NetBEUI, and Windows for Workgroups 3.11. Hey, it can happen. Some people are just stuck in the past.
In this example, we have a network that looks like this:
Configuring the first router
MyRouter01 has FastEthernet 0/0 set up as 172.16.0.1. It also has four Ethernet interfaces, each with 10.0.x.1 addresses. The second router on the other side has the network 192.168.1.0 /24 behind it. The 192.168.1.0 /24 and 10.0.x.0 /24 networks need to talk to each other. The router gods have declared that RIP must be used (no default gateways allowed). In this case we need to use version 2 of RIP since we have multiple 10.x.x.x networks that would normally overlap in a classful scenario if RIPv1 was used. Not a problem since it only involves only one extra command in IOS.
On the first router, the following configuration is entered:
router rip version 2 network 10.0.0.0 network 172.16.0.0 no auto-summary |
The first packet trace file shows that MyRouter01 sends off a RIP Request to the multicast address of 224.0.0.9 via UDP 520 (both source and destination) in the first packet. This is done as the routing configuration commands are being typed. The packet looks like this:
Routing Information Protocol
Command: Request (1)
Version: RIPv2 (2)
Routing Domain: 0
Address not specified, Metric: 16
Address Family: Unspecified (0)
Route Tag: 0
Netmask: 0.0.0.0 (0.0.0.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 16
|
Metric 16 basically refers to a dead route since RIP has a maximum hop count of 15, which is a short range compared to other routing protocols. After the IOS configuration for RIP has been done, however, another RIP packet (this time a RIP Response packet) is sent to the same multicast address and port.
Routing Information Protocol
Command: Response (2)
Version: RIPv2 (2)
Routing Domain: 0
IP Address: 10.0.0.0, Metric: 1
Address Family: IP (2)
Route Tag: 0
IP Address: 10.0.0.0 (10.0.0.0)
Netmask: 255.255.255.0 (255.255.255.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 1
IP Address: 10.0.1.0, Metric: 1
Address Family: IP (2)
Route Tag: 0
IP Address: 10.0.1.0 (10.0.1.0)
Netmask: 255.255.255.0 (255.255.255.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 1
IP Address: 10.0.2.0, Metric: 1
Address Family: IP (2)
Route Tag: 0
IP Address: 10.0.2.0 (10.0.2.0)
Netmask: 255.255.255.0 (255.255.255.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 1
IP Address: 10.0.3.0, Metric: 1
Address Family: IP (2)
Route Tag: 0
IP Address: 10.0.3.0 (10.0.3.0)
Netmask: 255.255.255.0 (255.255.255.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 1
|
It keeps sending this every 30 seconds. Forever. Until the end of time.
Configuring the second router
Now let's enable the second router to do RIPv2 and advertise its routes as well. In this case, MyRouter02 knows about two networks: 172.16.0.0 /24 and 192.168.1.0 /24. The IOS configuration is as follows:
router rip version 2 network 172.16.0.0 network 192.168.1.0 no auto-summary |
It's so easy that it hurts. Once done, the second router sends out a RIP Request just like the first one did at the beginning. This is shown in the second trace file and is referenced in the second packet. In the third packet, we see the first router sending a direct unicast RIP Response to the second router containing the routing updates for the 10.0.x.0 /24 networks. This unicast send is one-time. Afterwards, we see both routers mindlessly sending their routing updates to the multicast address at 224.0.0.9. MyRouter02's update looks like this:
Routing Information Protocol
Command: Response (2)
Version: RIPv2 (2)
Routing Domain: 0
IP Address: 192.168.1.0, Metric: 1
Address Family: IP (2)
Route Tag: 0
IP Address: 192.168.1.0 (192.168.1.0)
Netmask: 255.255.255.0 (255.255.255.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 1
|
It's naturally a little more simpler since it doesn't have as many networks to advertise. At this point, running RIP status commands shows that routing updates are being received from the first router and entered into the routing table of the second router:
Display show ip protocols
Display show ip route
Display show ip rip database
Pulling the plug, because it inevitably happens somehow
Now let's say that today is Bring Your Daughter To Work Day. Your daughter just broke up with her boyfriend so naturally she's upset and emotional. You hope that by showing her the cool stillness of the server room she might calm down. Instead, this plan backfires and when you're not looking she grabs onto one of the network cables and yanks it out of the port, effectively bringing down network 10.0.3.0 /24.
As shown in the third trace file, the first router immediately sends an update to the multicast address, notifying anyone listening that the route for 10.0.3.0 /24 is down by setting a route metric of 16. This is route poisoning.
Routing Information Protocol
Command: Response (2)
Version: RIPv2 (2)
Routing Domain: 0
IP Address: 10.0.3.0, Metric: 16
Address Family: IP (2)
Route Tag: 0
IP Address: 10.0.3.0 (10.0.3.0)
Netmask: 255.255.255.0 (255.255.255.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 16
|
A couple of seconds later, the second router returns a confirmation to the multicast address that 10.0.3.0 /24 is down by setting a route metric of 16. This is the poison reverse method. Neither router has any excuse now to say they didn't know the route was dead. This packet looks exactly the same as the previous one (except who sent it).
Routing Information Protocol
Command: Response (2)
Version: RIPv2 (2)
Routing Domain: 0
IP Address: 10.0.3.0, Metric: 16
Address Family: IP (2)
Route Tag: 0
IP Address: 10.0.3.0 (10.0.3.0)
Netmask: 255.255.255.0 (255.255.255.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 16
|
The first router eventually sends its routing update on time, except this first normal update has the metric of 16 set for 10.0.3.0 /24. The second router also sends a normal update, but also advertises the 10.0.3.0 /24 network with a metric of 16. It's like sending yet another confirmation that the route is down just to be super-super sure. This cycle actually repeats a couple of times. After that, normal routing updates continue without reference to the downed route.
10.0.3.0 /24, of course, just happens to be where the laptops of all the upper-management execs reside.
Saving the day by plugging it back in a hurry
Luckily, you just happened to be logged onto the second router around that moment and typed in the command show ip rip database:
MyRouter02#show ip rip database
10.0.0.0/8 auto-summary
10.0.0.0/24
[1] via 172.16.0.1, 00:00:06, Ethernet0/0
10.0.1.0/24
[1] via 172.16.0.1, 00:00:06, Ethernet0/0
10.0.2.0/24
[1] via 172.16.0.1, 00:00:06, Ethernet0/0
10.0.3.0/24 is possibly down
172.16.0.0/16 auto-summary
172.16.0.0/24 directly connected, Ethernet0/0
192.168.1.0/24 auto-summary
192.168.1.0/24 directly connected, Ethernet0/1
|
That message only taunts you for about a minute after the critical event, then references to 10.0.3.0 /24 are gone entirely. So now you realize what your daughter has done and can feel management fuming in their glass-walled offices five floors up. You run to the network rack, find the unplugged cable, get it back in, wait seemingly forever for the port to greenlight since the switchport it's connected to doesn't have portfast enabled, and then run back to your console.
The fourth trace file shows in the second packet where right after the router port has linked-up, the first router sends out another notification stating that 10.0.3.0 /24 is back up and has a metric of 1 from the perspective of itself.
Routing Information Protocol
Command: Response (2)
Version: RIPv2 (2)
Routing Domain: 0
IP Address: 10.0.3.0, Metric: 1
Address Family: IP (2)
Route Tag: 0
IP Address: 10.0.3.0 (10.0.3.0)
Netmask: 255.255.255.0 (255.255.255.0)
Next Hop: 0.0.0.0 (0.0.0.0)
Metric: 1
|
After this, the normal every-30-seconds routing updates go forth. All is good in the world and you can tell your daughter that she won't be getting a present for her next birthday.
Go back to the main articles list.