The debug ip rip Command
The debug ip rip command shows routing updates as they are sent and received on the
router to the console session. If you are telnetted into the router, you’ll need to use the
terminal monitor command to be able to receive the output from the debug commands.
You can see in this output that RIP is both sending and receiving (the metric is the hop
count):
R3#debug ip rip
RIP protocol debugging is on
R3#terminal monitor
*Mar 17 19:08:34.371: RIP: sending v1 update to 255.255.255.255 via Serial0/0/1
(10.1.5.2)
*Mar 17 19:08:34.371: RIP: build update entries
*Mar 17 19:08:34.371: subnet 10.1.10.0 metric 1
*Mar 17 19:08:34.371: subnet 10.1.11.0 metric 1
*Mar 17 19:08:34.371: subnet 10.1.12.0 metric 2
*Mar 17 19:08:40.107: RIP: received v1 update from 10.1.5.1 on Serial0/0/1
*Mar 17 19:08:40.107: 10.1.1.0 in 1 hops
*Mar 17 19:08:40.107: 10.1.2.0 in 1 hops
*Mar 17 19:08:40.107: 10.1.3.0 in 1 hops
*Mar 17 19:08:40.107: 10.1.4.0 in 1 hops
*Mar 17 19:08:40.107: 10.1.6.0 in 2 hops
*Mar 17 19:08:40.107: 10.1.7.0 in 2 hops
*Mar 17 19:08:40.107: 10.1.8.0 in 2 hops
*Mar 17 19:08:40.107: 10.1.9.0 in 2 hops
*Mar 17 19:08:47.535: RIP: sending v1 update to 255.255.255.255 via
FastEthernet0/1 (10.1.11.1)
*Mar 17 19:08:47.535: RIP: build update entries
*Mar 17 19:08:47.535: subnet 10.1.1.0 metric 2
*Mar 17 19:08:47.535: subnet 10.1.2.0 metric 2
*Mar 17 19:08:47.535: subnet 10.1.3.0 metric 2
*Mar 17 19:08:47.535: subnet 10.1.4.0 metric 2
*Mar 17 19:08:47.535: subnet 10.1.5.0 metric 1
*Mar 17 19:08:47.535: subnet 10.1.6.0 metric 3
*Mar 17 19:08:47.535: subnet 10.1.7.0 metric 3
*Mar 17 19:08:47.535: subnet 10.1.8.0 metric 3
*Mar 17 19:08:47.535: subnet 10.1.9.0 metric 3
*Mar 17 19:08:47.535: subnet 10.1.10.0 metric 1
*Mar 17 19:08:49.331: RIP: received v1 update from 10.1.11.2 on FastEthernet0/1
*Mar 17 19:08:49.331: 10.1.12.0 in 1 hops
R3#undeug all
Let’s talk about the parts I highlighted in bold. First, RIP is sending v1 packet to
255.255.255.255—an “all-hands” broadcast, out interface Serial0/0/1, via 10.1.5.2. This is
where RIPv2 will come in handy. Why? Well, RIPv2 doesn’t send broadcasts; it used the multicast
224.0.0.9. So even though the RIP packets could be transmitted onto a network with no
routers, all hosts would just ignore them, making RIPv2 a bit of an improvement over RIPv1.
On this R3, I’m using the passive interface so I’m not sending broadcasts out to a LAN with
any routers connected. Continuing with the debug ip rip command, let’s take a quick look
at a route update when using RIPv2 with MD5 authentication.
R3#debug ip rip
RIP protocol debugging is on
*May 3 20:48:37.046: RIP: received packet with MD5 authentication
*May 3 20:48:37.046: RIP: received v2 update from 192.168.10.1 on Serial0/0
*May 3 20:48:37.050: 10.0.0.0/8 via 0.0.0.0 in 1 hops