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:
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:
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:
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:
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:
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:
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:
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:
On the other hand, the following output is seen on RouterB when it receives updates from RouterA:
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.