Category: RIP

… updated on Tuesday, December 29, 2020 09:34 UTC

Limitations of VRF Routing Protocols on Cisco IOS

Cisco IOS allows up to 32 routing protocols contributing routes into a routing table (two of them are always connected and static). The limitation applies to the global routing table as well as to each individual VRF; 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.

Due to the implementation details of Cisco IOS, the BGP, RIP and each EIGRP routing process consume routing protocol ID in all VRFs (regardless of whether they are used or not). You can view the IDs of individual routing protocols with the show ip protocol [vrf name] summary command.

read more see 7 comments

RIP Rocks in Low-End Hub-and-Spoke Networks

Yesterday, I 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 propagate the topology change; the central site’s output route filter stops all unnecessary updates.

As you know, OSPF requires hello packets and adjacencies to work correctly. Therefore, the central hub router must 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.

see 7 comments

Why is RIP still kicking?

One of my readers called RIP “Rest in Piece” routing. Although it’s probably the routing protocol that dinosaurs used to find their way around, it’s still useful in modern networks. Imagine that you have to deploy hundreds (or thousands) of low-cost remote sites with dual uplink capability (for backup purposes). They could be automated kiosks, point-of-sale terminals or even ATM machines.
If you’re infinitely lucky (and have huge budget), you could afford an ISR router at each location and use different design options that Cisco IOS gives you. In most cases, you have to work with devices that barely know what routing is … but you still need dynamic routing protocol to give them the ability to detect primary route failure and switch over to the backup route.

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.
add comment

RIP route database

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.

The article in which I described that feature is long gone, but fortunately archive.org saved the day.

Would you like me to migrate that article to ipSpace.net? Send me a message and I just might do it...

see 1 comments
Sidebar