Building network automation solutions

9 module online course

Start now!

Category: RIP

VRF routing process limitations

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.

Read more in the VRF routing process limitations article in the CT3 wiki.

see 7 comments

RIP trivia: maximum RIP packet size varies between Cisco and Juniper routers

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 typeCisco IOSJunOS
None25/51225/512
Password24/51224/512
MD524/53223/512

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.

read more see 3 comments

RIP interface summaries can cause routing loops

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.

Read the whole article in the CT3 wiki.

RIP rocks in low-end hub-and-spoke networks

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.

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.

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.

Read the full article in CT3 wiki …

see 1 comments

Next-hop fixup in partially-meshed NBMA networks

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.

This article is part of You've asked for it series.
see 1 comments

RIP multicast updates are sent with TTL of 2

The “culprit” for today's post is Francois Ropert, who provides a nice summary of Cisco-related blogs in his Planet Cisco web site. Reading the CCIE-related posts, I've stumbled across a post by Ethan Banks wondering whether the RIP updates are really sent with IP TTL set to 2. He concluded that this information cannot be deduced from the debugging outputs (anyone having an idea how you can get this information on the router?) and that he would need a sniffer to figure it out … and I thought: What a nice job for Dynamips.

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 rip
 version 2
 network 10.0.0.0
Next 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.

see 9 comments
Sidebar