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