A while ago, Cisco IOS did not allow you to run more than 30 routing processes per router, significantly limiting the options of Service Providers who wanted to support OSPF as the PE-CE routing protocol. The architectural reason for the limit is a 32-bit mask that’s used in Cisco IOS to mark individual routing protocols. The routing protocol ID (as displayed by the show ip protocol summary command) is thus limited to values 0 to 31. With value 0 being reserved for connected routes and value 1 for static routes, 30 values are left to number the routing protocols.
Later IOS releases removed the limitation by allowing the same routing protocol ID to be used for different routing protocols in different VRFs. While this solution satisfies the needs of most customers, it also causes interesting side effects.
Let’s conclude the RIP week with an interesting observation made by Yuri Selivanov: when using MD5 authentication with RIP, Cisco routers send 532-byte UDP datagrams while Juniper routers send 512-byte UDP datagrams. The maximum number of route entries (RTE) in a RIP datagram and its size thus varies based on authentication mechanism and router software:
|Authentication type||Cisco IOS||JunOS|
Somehow people expect RIP datagrams to be at most 512 bytes long, which (as you can see from the table) is not always the case.
The moment I wrote “RIP summary routes are not present in the IP routing table” in the RIP Route Database article in the CT3 wiki, I knew it was a recipe for disaster. It’s OK not to advertise what you use (we call this route filters); advertising something you don’t use yourself is slightly stupid.
It didn’t take me long (after I found a few minutes of spare time) to come up with a scenario where RIP interface summary creates a nice routing loop.
Yesterday I’ve introduced a scenario where RIP would (in my opinion) work much better than OSPF. If you were not persuaded by the “management-level” arguments, let’s focus on the technical details (but make sure you read the scenario first).
All you ever want to advertise to the remote sites in this design is the default route (or a network-wide summary). Alternatively, you might want to advertise only a route to a central LAN or server. Both requirements are easily met with RIP per-interface output filters. Doing something similar with OSPF is close to impossible. Either you place every remote site into a separate OSPF area (don’t even think about doing it; there could be hundreds of sites) or the routes within an area will leak between the remote sites.
RIP is also more stable than OSPF in this setup. Whenever a remote site disappears, the change in the OSPF area is unnecessarily propagated to all other remote sites in the same area. RIP doesn’t react at all; the output route filter at the central site stops all unnecessary updates.
As you know, OSPF requires hello packets and adjacencies to work properly. The central hub router must therefore track the adjacency states of hundreds of neighbors. When using RIP, the central router couldn’t care less … it sends out its routes every so often, collects whatever comes back and reports when a new remote route is received or an old one disappears.
Assuming your purchasing department didn’t buy boxes that don’t have enough memory to run OSPF, you could usually choose between RIP and OSPF as the routing protocol … and I would always select RIP in this scenario. Let’s start with the “management-level” arguments: RIP is simpler to design (there is almost nothing to design) and troubleshoot than OSPF. It uses less memory and CPU cycles and I would also expect low-end boxes to have fewer bugs in RIP than in OSPF. More in-depth arguments are coming in the follow-up post.
Did you know that RIP, the venerable routing protocol that is present in Cisco routers for the last 20 years, uses an internal database, not the IP routing table, to process RIP updates? This database contains no fancy information (like EIGRP topology table) that would allow RIP to converge faster, but there are still minor differences between the RIP database and the IP routing table.
Shahid has sent me an interesting observation: he was running RIP in partially-meshed Frame Relay network and wanted to use static host routes to fix next-hop problems, but somehow they didn't work as expected. I ran a series of scenarios testing RIP, OSPF, EIGRP and BGP and found that some of the old tricks don't work any more. Furthermore, it's almost impossible to run RIP over partially-meshed NBMA network, as the default RIP next-hop processing messes up your routing table. The details are explained in the Next-hop fixup in partially-meshed NBMA networks article in the CT3 wiki.
I took one of my standard lab topologies (three routers in a triangle running OSPF between them, see the figure below) and started it in Dynagen.
When the routers were up and running I've configured RIP on all three of them:
router ripNext I've used Dynagen to start the packet capture on the first serial port of the R1 with the capture R1 s1/0 rip.cap PPP command. After a minute, I've stopped the capture with the no capture R1 s1/0 command and opened the rip.cap file with Wireshark. The results are shown below (click to enlarge); RIP multicast updates are actually sent with TTL 2 (at least in IOS release 12.4(15)T).
I've used the same technique to figure out that the RIP unicast updates (configured with the neighbor address router configuration command) are sent with TTL 255.