Verifying RIP Configuration and Operation
Besides viewing the running configuration to ensure that RIP appears with the desired networks as expected, you can use a few commands to help you verify the RIP configuration, fine tune it where necessary, and ensure that it is operating properly.
These commands include the following:
show ip protocols
show ip route
ping
debug ip rip
passive-interface
Verifying RIP Configuration with the show ip protocols Command
Begin verifying the RIP configuration using the show ip protocols command, as demonstrated in Example 8-10.
Example 8-10 show ip protocols Command Output on R1 Displays Detailed Information About RIP Configuration
R1#show ip protocols Routing Protocol is "rip" Sending updates every 30 seconds, next due in 20 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Redistributing: rip Default version control: send version 1, receive any version Interface Send Recv Key-chain Ethernet0 1 1 2 Loopback0 1 1 2 Routing for Networks: 192.168.1.0 192.169.1.0 Routing Information Sources: Gateway Distance Last Update 192.168.1.2 120 00:00:06 Distance: (default is 120) R1#
Review the highlighted fields in the show ip protocols output from Example 8-10. First, you see the following:
Sending updates every 30 seconds, next due in 20 seconds
This indicates that RIP is advertising routes every 30 seconds and that the next advertisement is expected in 20 seconds; this means that R1 just received an update 10 seconds ago. Next, you get the following:
Invalid after 180 seconds, hold down 180, flushed after 240
This means that if R1 does not receive an update from R2 for 180 seconds or more, it marks the routes advertised by R2 as being unusable. If R1 still doesn't receive an update from R2 after 240 seconds, R1 removes the routing table entries that it received from R2. This line also shows that the hold-down timer is set to 180.
The next highlighted line indicates that the default configuration for RIP is to send RIP-1 updates and to receive both RIP-1 and RIP-2 updates.
The last highlighted lines verify that RIP is configured for networks 192.168.1.0 and 192.169.1.0. Each of these networks will be advertised in RIP routing updates.
Compare the show ip protocols output for R1 in Example 8-10 to the show ip protocols output on R2, as shown in Example 8-11.
Example 8-11 show ip protocols on R2
R2#show ip protocols Routing Protocol is "rip" Sending updates every 30 seconds, next due in 28 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Outgoing update filter list for all interfaces is Incoming update filter list for all interfaces is Redistributing: rip Default version control: send version 1, receive any version Interface Send Recv Key-chain Ethernet0 1 1 2 Ethernet1 1 1 2 Loopback0 1 1 2 Routing for Networks: 192.168.1.0 192.168.2.0 192.169.2.0 Routing Information Sources: Gateway Distance Last Update 192.168.1.1 120 00:00:08 Distance: (default is 120) R2#
The highlighted areas show that the only difference is that R2 also is configured to send and receive RIP updates for the 192.168.2.0 network on its Ethernet1 interface. Ideally, you do not want RIP updates to be broadcast out the Ethernet1 interface. The section "Preventing RIP Updates with the passive-interface Command" goes into more detail about this.
Confirming RIP Advertisement Receipt with the show ip route Command
The show ip protocols command indicates that the proper networks are configured for RIP advertisements. You can confirm that these RIP advertisements are being received by looking at the routing table of R1 and R2 using the show ip route command. Example 8-12 provides the output from this command on R1.
Example 8-12 Routing Table of R1 After Successful RIP Configuration
R1#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR
Gateway of last resort is not set
C 192.169.1.0/24 is directly connected, Loopback0
C 192.168.1.0/24 is directly connected, Ethernet0
R 192.168.2.0/24 [120/1] via 192.168.1.2, 00:00:09, Ethernet0
R 192.169.2.0/24 [120/1] via 192.168.1.2, 00:00:09, Ethernet0
R1#
R1 has received two RIP routes from R2: one to network 192.168.2.0 and one to 192.169.2.0. These correspond to Ethernet1 and Loopback0 on R2. Each route is preceded by an R, indicating that the route was learned through RIP.
Example 8-13 shows the routing table of R2.
Example 8-13 R2 Routing Table
R2#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR
Gateway of last resort is not set
C 192.168.1.0/24 is directly connected, Ethernet0
R 192.169.1.0/24 [120/1] via 192.168.1.1, 00:00:19, Ethernet0
C 192.168.2.0/24 is directly connected, Ethernet1
C 192.169.2.0/24 is directly connected, Loopback0
C 192.168.100.0/24 is directly connected, Serial0
R2#
R2 has received one RIP route of 192.169.1.0 from R1. This corresponds to R1's Loopback0 interface and was learned via a RIP advertisement from R1.
Verifying Router Interconnectivity with the ping Command
With the correct routes in R1's and R2's routing tables, R1 and R2 should be capable of pinging each other's Loopback0 interface. In addition, R1 now should be capable of pinging R2's Ethernet1 address of 192.168.2.2. To verify this, first initiate a ping from R2 to R1's Loopback0 address of 192.169.1.1, as shown in Example 8-14.
Example 8-14 Successful ping from R2 to R1's Loopback0 Address
R2#ping 192.169.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.169.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/6/24 ms R2#
Success! Now initiate a ping from R1 to R2's Loopback0 address of 192.169.2.2 and to R2's Ethernet1 address of 192.168.2.2, as shown in Example 8-15.
Example 8-15 Successful ping from R1 to R2's Loopback0 and Ethernet1 Addresses
Termserver#1 [Resuming connection 1 to r1 ... ] R1#ping 192.169.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.169.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms R1#ping 192.168.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms R1#
Success! R1 now has successfully learned the routes necessary to ping R2's Loopback0 and Ethernet1 addresses.
Analyzing Router Processes with the debug ip rip Command
In the lab examples, R1 and R2 learned the desired routes without any problems; however, in the real world, problems might arise where the configuration appears correct but RIP routes are not appearing in the routing table as expected. For more complex scenarios, you can use a debug command to see what is going on in the background RIP process of the router. The command used is debug ip rip and is executed from privileged EXEC mode as follows:
Router#debug ip rip
To turn off IP RIP debugging, use the no form of the preceding command, as follows:
Router#no debug ip rip
To turn off all debugging on the router, you can use either of the following commands:
Router#undebug all Router#no debug all
Observe the RIP routing process on R1 by turning on IP RIP debugging and then turning off all debugging, as shown in Example 8-16.
Example 8-16 debug ip rip Command Output on R1
R1#debug ip rip RIP protocol debugging is on R1# RIP: received v1 update from 192.168.1.2 on Ethernet0 192.168.2.0 in 1 hops 192.169.2.0 in 1 hops R1# RIP: sending v1 update to 255.255.255.255 via Ethernet0 (192.168.1.1) network 192.169.1.0, metric 1 RIP: sending v1 update to 255.255.255.255 via Loopback0 (192.169.1.1) network 192.168.1.0, metric 1 network 192.168.2.0, metric 2 network 192.169.2.0, metric 2 R1#undebug all All possible debugging has been turned off R1#
The debug ip rip output reveals the following information:
R1 received a Version 1 update from 192.168.1.2 (R2) on its Ethernet0 interface. This update contained the two routes configured on R2 to be advertised (that is, 192.168.2.0 and 192.169.2.0).
R1 sent a RIP broadcast on its Ethernet0 interface advertising the network 192.169.1.0.
R1 sent a RIP broadcast on its Loopback0 interface advertising networks 192.168.1.0, 192.168.2.0, and 192.169.2.0.
Preventing RIP Updates with the passive-interface Command
R1 is sending RIP updates via its Loopback0 interface because when a network is added to RIP, RIP not only advertises this network route but also sends updates on the interface corresponding to this network. This is the case with Loopback0 on R1. When R1's Loopback0 network 192.169.1.0 was added to RIP to ensure that it was advertised to R2, RIP also began sending updates on the interface corresponding to network 192.169.1.0 or Loopback0. Because loopback interfaces are virtual interfaces, there is no purpose in sending updates out this interface. Remember that the reason to include the Loopback0 network in RIP was to ensure that it was advertised to R2. You can prevent RIP from sending updates via Loopback0 by configuring Loopback0 to be a passive interface in the RIP routing process. You can do this from router configuration mode using the following command:
R1(config-router)#passive-interface [interface#]
Example 8-17 demonstrates how to configure Loopback0 as a passive interface.
Example 8-17 R1 Loopback0 Configured as a Passive Interface
R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#router rip R1(config-router)#passive-interface loopback0 R1(config-router)#end R1# %SYS-5-CONFIG_I: Configured from console by console R1#
Now turn on IP RIP debugging again and observe the difference in the debug output after Loopback0 has been configured as a passive interface, as shown in Example 8-18.
Example 8-18 debug ip rip Output on R1 After Loopback0 Configured as a Passive Interface
R1#debug ip rip RIP protocol debugging is on R1# RIP: received v1 update from 192.168.1.2 on Ethernet0 192.168.2.0 in 1 hops 192.169.2.0 in 1 hops R1# RIP: sending v1 update to 255.255.255.255 via Ethernet0 (192.168.1.1) network 192.169.1.0, metric 1 R1# RIP: received v1 update from 192.168.1.2 on Ethernet0 192.168.2.0 in 1 hops 192.169.2.0 in 1 hops R1# RIP: sending v1 update to 255.255.255.255 via Ethernet0 (192.168.1.1) network 192.169.1.0, metric 1 R1#
The debug output represents two 30-second RIP interval updates. Notice that after you have configured Loopback0 to be a passive interface, RIP no longer sends updates via Loopback0.
R2 has a similar situation. You do not want RIP updates to be sent out Loopback0 or Ethernet1. Switch over to R2 and observe the current debug ip rip information, as shown in Example 8-19.
Example 8-19 RIP Debug Information on R2 Before Passive Interface Configuration
Termserver#2 [Resuming connection 2 to r2 ... ] R2#debug ip rip RIP protocol debugging is on R2# RIP: received v1 update from 192.168.1.1 on Ethernet0 192.169.1.0 in 1 hops R2# RIP: sending v1 update to 255.255.255.255 via Ethernet0 (192.168.1.2) network 192.168.2.0, metric 1 network 192.169.2.0, metric 1 RIP: sending v1 update to 255.255.255.255 via Ethernet1 (192.168.2.2) network 192.168.1.0, metric 1 network 192.169.1.0, metric 2 network 192.169.2.0, metric 1 RIP: sending v1 update to 255.255.255.255 via Loopback0 (192.169.2.2) network 192.168.1.0, metric 1 network 192.169.1.0, metric 2 network 192.168.2.0, metric 1 R2#undebug all All possible debugging has been turned off R2#
The output indicates that R2 still is receiving network 192.169.1.0 from R1. This corresponds to R1's Loopback0 and verifies that even though Loopback0 was configured as a passive interface on R1, R1 still is advertising this network to R2 as desired. In addition, notice that R2 is sending updates out Ethernet0, Ethernet1, and Loopback0. To remedy this, configure Ethernet1 and Loopback0 to be passive interfaces on R2, as shown in Example 8-20.
Example 8-20 Ethernet1 and Loopback0 Configured as Passive Interface on R2
R2#conf t Enter configuration commands, one per line. End with CNTL/Z. R2(config)# %SYS-5-CONFIG_I: Configured from console by console R2(config)#router rip R2(config-router)#passive-interface ethernet1 R2(config-router)#passive-interface loopback0 R2(config-router)#end R2# %SYS-5-CONFIG_I: Configured from console by console R2#
Example 8-21 shows the change to the debug ip rip information after the new passive interface configuration.
Example 8-21 debug ip rip Output After Loopback0 and Ethernet1 Configured as Passive Interfaces on R2
R2#debug ip rip RIP protocol debugging is on R2# RIP: sending v1 update to 255.255.255.255 via Ethernet0 (192.168.1.2) network 192.168.2.0, metric 1 network 192.169.2.0, metric 1 R2# RIP: received v1 update from 192.168.1.1 on Ethernet0 192.169.1.0 in 1 hops R2#
RIP updates no longer are being sent via Loopback0 and Ethernet1, as intended.
Saving the New Configuration
At this point, turn off all debugging and save the configuration on R1 and R2, as shown in Example 8-22.
Example 8-22 Turning Off All Debugging and Saving Configuration on R1 and R2
R2#undebug all All possible debugging has been turned off R2#copy running startup Building configuration... [OK] R2# Termserver#1 [Resuming connection 1 to r1 ... ] R1#undebug all All possible debugging has been turned off R1#copy running startup Building configuration... [OK] R1#
Next, you can verify that the host table mapping that was set up in Chapter 6 pointing to the loopback interface works between R1 and R2. This is because RIP is advertising the routes to these loopback interfaces via RIP between R1 and R2. Test this on R1 by typing r2 from the privileged EXEC mode, and see if a Telnet session is opened up to R2, as shown in Example 8-23.
Example 8-23 Successful Telnet from R1 to R2 Using Host Table Entry
R1#r2 Trying R2 (192.169.2.2)... Open This is Router 2 User Access Verification Password: R2>enable Password: R2#
Example 8-23 verifies that the host table worked as designed. R1 initiated a Telnet session to 192.169.2.2 (R2's Loopback0 interface), the banner is displayed, and you are prompted for the vty password and finally the enable password. Quit the Telnet session to R2 using the quit command, as demonstrated in Example 8-24.
Example 8-24 Ending Telnet Session Between R1 and R2
R2#quit [Connection to r2 closed by foreign host] R1#
The Telnet session has been terminated, and you are returned to R1.