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:
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:
192.168.1.0
192.168.2.0
Passive Interface(s):
FastEthernet0/0
Routing Information Sources:
Gateway Distance Last Update
192.168.2.2 120 00:00:00
192.168.2.3 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 192.168.2.0 and 192.168.3.0 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 192.168.1.0 and 192.168.2.0 so the following network commands should be present under the routing configuration:
Router(config-router)#network 192.168.2.0
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:
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 192.168.1.1 YES manual up up
FastEthernet0/1 192.168.2.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 192.168.2.2 on FastEthernet0/1
192.168.3.0 in 1 hops
192.168.4.0 in 2 hops
RIP: sending v1 update to 255.255.255.255 via FastEthernet0/1 (192.168.2.1)
RIP: build update entries
network 192.168.1.0 metric 1
RIP: received v1 update from 192.168.2.3 on FastEthernet0/1
192.168.3.0 in 1 hops
192.168.4.0 in 2 hops
The first output shows the routes received from 192.168.2.2 (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 192.168.1.0. Remember it will not include the 192.168.3.0 and 192.168.4.0 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 192.168.2.3 (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:
RouterA#
Jul 21 00:23:46: 192.168.4.0 in 16 hops (inaccessible)
RouterA#
Jul 21 00:23:50: RIP: received v1 update from 192.168.2.3 on FastEthernet0/1
Jul 21 00:23:50: 192.168.4.0 in 16 hops (inaccessible)
Sixty seconds after the poisoned routers, the update from RouterB no longer contains the 192.168.4.0 route. This shows that RouterB has flushed that route from its table:
Jul 21 00:24:53: 192.168.3.0 in 1 hops
Once the interface is brought back up on RouterD, the 192.168.4.0 network is seen again in the update received from RouterB on RouterA:
Jul 21 00:28:58: 192.168.3.0 in 1 hops
Jul 21 00:28:58: 192.168.4.0 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 192.168.2.2 (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 192.168.3.4 (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.