Know how to verify and troubleshoot a protocol or feature is as important as knowing how to configure it because configurations do have errors and assuming that everything is working correctly can lead to major network problems. The following three commands are used to verify and troubleshoot RIP:

  • show ip route
  • show ip protocols
  • debug ip rip

The show ip route command has been covered in the previous chapter and earlier in this chapter. Eventually a complete and correct routing table across the network is the best verification of a routing table. The other two commands are covered below.

Using show ip protocols command to verify and troubleshoot RIP 

As you already know, the show ip protocols command helps verify routing protocols running on the router. An example of the output of this command from RouterB of our network is shown below:

RouterA#sh ip protocols
Routing Protocol is “rip”
  Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 27 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
  Default version control: send version 1, receive version 1
    Interface             Send  Recv  Triggered RIP  Key-chain
FastEthernet0/1       1     1
Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
  Passive Interface(s):
  Routing Information Sources:
Gateway         Distance      Last Update          120      00:00:00          120      00:00:22
Distance: (default is 120) 

Notice in the above output that RIP is being used on the router and it is routing for the and networks. RIPv1 is being used on both the interfaces and updates are being sent every 30 seconds. It also shows the fa0/0 is a passive interface.

While the output is very useful in verifying the configuration, it is also useful for troubleshooting. Looking at the above output, it is fairly easy to figure out what has been configured. For example, the output shows that it is routing for networks and so the following network commands should be present under the routing configuration:


In addition to that, the fa0/0 interface is shown as passive, hence the passive-interface fa0/0 command is also present in the configuration. A quick look at the show ip interface brief command will show you the interfaces of the router and their IP address:

RouterA#sh ip int br
Interface                  IP-Address      OK? Method Status                Protocol
FastEthernet0/0       YES manual up                    up
FastEthernet0/1       YES manual up                    up      

Comparing the above outputs, it is easy to see that RIP is running on the correct interfaces and networks.

Another important thing, which the output shows you, is that it is sending and receiving RIPv1 updates. You can confirm the versions across the routers in the network to rule out version mismatch if routing updates are not seen on few routers.

Using debug ip rip command to troubleshoot RIP

The debug ip rip command displays routing updates on the console as soon as they are sent or received. This output is useful to see if the updates are being sent to and being received from the neighbors or not. The following example shows the output of the command on RouterA:

RIP: received v1 update from on FastEthernet0/1 in 1 hops in 2 hops

RIP: sending v1 update to via FastEthernet0/1 (
RIP: build update entries
network metric 1

RIP: received v1 update from on FastEthernet0/1 in 1 hops in 2 hops

The first output shows the routes received from (RouterB) and the metric associated with each route. It also shows that version 1 is being used. The send output shows RouterA sending out the update for Remember it will not include the and networks in the updates because of split horizon. It is also not sending out updates on fa0/0 because we have configured it as passive.

The last output shows the updates received from (RouterC) and metrics associated with the routes.

The outputs of debug ip rip command are also useful to see the loop prevention techniques in action. To trigger the loop prevention techniques, interface fa0/0 was shutdown on RouterD.

You will remember that a router will wait for the duration of the invalid timer before it sends out poisoned routes and it will wait for the duration of the flush timer before removing the routes. By default the invalid timer is 180 seconds and the route is flushed 60 seconds after invalid timer. The following output shows the poisoned routes received from RouterB and RouterC on RouterA:


Jul 21 00:23:46: RIP: received v1 update from on FastEthernet0/1
Jul 21 00:23:46: in 16 hops (inaccessible)
Jul 21 00:23:50: RIP: received v1 update from on FastEthernet0/1
Jul 21 00:23:50: in 16 hops (inaccessible) 

Sixty seconds after the poisoned routers, the update from RouterB no longer contains the route. This shows that RouterB has flushed that route from its table:

Jul 21 00:24:53: RIP: received v1 update from on FastEthernet0/1
Jul 21 00:24:53: in 1 hops 

Once the interface is brought back up on RouterD, the network is seen again in the update received from RouterB on RouterA:

Jul 21 00:28:58: RIP: received v1 update from on FastEthernet0/1
Jul 21 00:28:58: in 1 hops
Jul 21 00:28:58: in 2 hops 

As a final example, I changed the version on RouterB to 2. This will cause a mismatch with RouterA and RouterD sine they are configured for version 1. The following output on RouterA is seen when it receives the update from RouterB:

Jul 21 00:58:11: RIP: ignored v2 packet from (illegal version) 

On the other hand, the following output is seen on RouterB when it receives updates from RouterA:

Jul 21 01:00:01: RIP: ignored v1 packet from (illegal version) 

The two outputs above clearly show that there is a version mismatch and you will need to use the version command in the routing configuration mode to fix it.