Example 8-1 IP Routing Table on R1 Before the Configuration of IP RIP

---

RIP Lab Objective

Configure RIP using the following criteria:

• Place R2's E0 and E1 networks into RIP.

• R1's E0 network should be configured for RIP as well.

• Place R1 and R2's loopback interfaces into RIP.

Figure 8-1 depicts that portion of the lab where RIP will be configured.

Figure 8-1. IP RIP Routers

Configuring RIP Between R1 and R2

Before configuring RIP, look at the existing IP routing table of both R1 and R2 to get an idea of the routes that each device currently has in its routing table. Display the IP routing table of a router using the following command:

 Router#  show ip route  

To do this on R1, first resume your reverse Telnet session to R1 and, from privileged EXEC mode, enter the show ip route command as demonstrated in Example 8-1.

 Termserver#  1  [Resuming connection 1 to r1 ... ] 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  R1# 

At the top of the routing table, a legend displays the various routes that may exist in a routing table. Each route type corresponds to a letter. These letters appear next to the route in the routing table. Paying attention to these letters enables you to better understand how the router learned each route in the routing table.

Currently, the only routes that exist on R1 are routes to directly connected interfaces. The letter C preceding the actual route denotes a directly connected route to 192.168.1.0/24 through Ethernet0. In addition, you should see a route to 192.169.1.0/24 directly connected to Loopback0. These routes were created in the IP routing table when you assigned an IP address to each interface and brought the interface up and out of shutdown mode. Loopback interfaces come up out of shutdown mode upon creation and then are placed in the routing table. This was done in Chapter 7, "Router Interface Configuration." Essentially, this means that R1 knows how to route to its directly connected networks, but nothing else.

Next, observe the routing table on R2 by returning to the terminal server, resuming the connection to R2, and then displaying the IP routing table with the show ip route command, as shown in Example 8-2.

Example 8-2 IP Routing Table on R2 Before the Configuration of IP RIP

 Termserver#  2  [Resuming connection 2 to r2 ... ] 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 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# 

As the output in Example 8-2 shows, R2 has directly connected routes off each of its configured interfacesEthernet0, Ethernet1, Loopback0, and Serial0. These also were created in the IP routing table when each interface on R2 was assigned an IP address and was brought out of shutdown using the no shutdown command on the interface.

Suppose that, from R1, you need to get to R2's network of 192.168.2.0. You can check to see if this works by initiating a ping from R1 to R2's Ethernet1 interface of 192.168.2.2. If the ping succeeds, you know that R1 can reach the destination network. To do this, return to R1 and, from privileged EXEC mode, use the following command:

 Router#  ping 192.168.2.2  

Example 8-3 demonstrates this series of transactions.

Example 8-3 R1 Incapable of ping ing 192.168.2.2

 Termserver#  1  [Resuming connection 1 to r1 ... ] 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 0 percent (0/5)  

A standard ping request sends five ICMP echo packets. Receiving an ICMP echo reply in response to the ICMP echo request indicates a successful ping. A successful reply is denoted by an exclamation mark (!). In Example 8-3, no reply was received, as indicated by the five periods (.); this indicates zero replies received to the five ICMP echo packets that were sent. As a result, the success rate was 0 percent, indicating the request failed and that R1 cannot get to the network 192.168.2.0.

It is possible that the ping failed because of physical connectivity problems. In addition, R1 is incapable of ping ing R2's Loopback0 interface of 192.169.2.2, as shown in Example 8-4.

Example 8-4 R1 Incapable of ping ing R2's Loopback0 Interface

 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 0 percent (0/5) R1# 

Example 8-5 demonstrates R1's attempt to ping R2's Ethernet0 interface of 192.168.1.2.

Example 8-5 R1 Successfully ping s R2's Ethernet0 Interface

 R1#  ping 192.168.1.2  Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:  !!!!!   Success rate is 100 percent (5/5)  , round-trip min/avg/max = 1/2/4 ms R1# 

R1 successfully can ping R2's Ethernet0 interface, but it cannot ping any of the other directly connected interfaces of R2. This result indicates that physical connectivity between R1 and R2 exists.

The reason that R1 cannot ping R2's Ethernet1 or Loopback0 interface is that it does not have a route to networks 192.168.2.0 and 192.169.2.0.

This also is verified by R1's routing table, as indicated earlier in Example 8-1. R1 had a route to its directly connected network of 192.168.1.0, but no route to 192.168.2.0 or 192.169.2.0. For this reason, you can ping R2's Ethernet0 interface from R1, but you cannot ping R2's Ethernet1 or Loopback0 interfaces.

NOTE

When you type the command ping 192.169.2.2, the router creates an IP packet with a destination IP address of 192.169.2.2. The router then looks in its routing table to determine what interface it should send the packet out to get to 192.169.2.2. Because the router does not have an entry in its routing table for the IP network 192.169.2.0 where 192.169.2.2 resides, the router discards the packet.

You can resolve this issue by configuring R1 with a static route to the destination networks of 192.168.2.0 and 192.169.2.0; or, you could configure a routing protocol between R1 and R2 that would advertise these routes. For purposes here, configure RIP between R1 and R2. Through RIP, R2 will advertise the routes of its directly connected networks of 192.168.2.0 and 192.169.2.0 to R1. After R1 has received these routes, R1 will be capable of ping ing 192.168.2.2 and 192.169.2.2. In addition, you should be capable of Telnetting from R1 to R2 using the host table configured in Chapter 6, "General Router Configurations," which mapped R2's host name to its Loopback0 interface.

Configuring RIP requires the following steps:

Step 1. Enable the RIP routing process, which places you in router configuration mode via the Router# router rip command.

Step 2. Specify those networks that should be advertised using RIP via the Router(config-router)# network [ network-number ] command.

Begin the RIP configuration by resuming the reverse Telnet session to R1. On R1, you enter global configuration mode and start the RIP routing process. This places you in router configuration mode. Then use the network command to specify networks 192.168.1.0 and 192.169.1.0 to be advertised using RIP. Example 8-6 demonstrates this series of transactions.

Example 8-6 Starting the RIP Routing Process on R1 and Advertising Networks 192.168.1.0 and 192.169.1.0 Through RIP

 Termserver#  1  [Resuming connection 1 to r1 ... ] R1#  configure terminal  Enter configuration commands, one per line. End with CNTL/Z. R1(config)#  router rip  R1(config-router)#  network 192.168.1.0  R1(config-router)#  network 192.169.1.0  R1(config-router)#  end  R1# %SYS-5-CONFIG_I: Configured from console by console R1# 

To get an idea of how this should appear, look at the highlighted portion of the RIP configuration of R1 in Example 8-7.

Example 8-7 Running Configuration of R1 After Configuration of RIP

 R1#  show running-config  Building configuration... Current configuration: ! version 11.2 no service password-encryption no service udp-small-servers no service tcp-small-servers ! hostname R1 ! enable password falcons ! no ip domain-lookup ip host R1 192.169.1.1 ip host R2 192.169.2.2 ip host R3 192.169.3.3 ip host R4 192.169.4.4 ip host R5 192.169.5.5 ip host R6 192.169.6.6 ! interface Loopback0  ip address 192.169.1.1 255.255.255.0 ! interface Ethernet0  description This interface connects to R2's E0  ip address 192.168.1.1 255.255.255.0 ! interface Serial0  no ip address  shutdown ! interface Serial1  no ip address  shutdown !  router rip   network 192.168.1.0   network 192.169.1.0  ! no ip classless ! banner motd ^C This is Router 1 ^C ! line con 0  exec-timeout 0 0  password falcons  logging synchronous line aux 0 line vty 0 4  password falcons  login ! end 

Next, you need to configure R2 with RIP and add networks 192.168.1.0, 192.168.2.0, and 192.169.2.0 to be advertised using RIP. Return to the terminal server, resume the connection with R2, and configure RIP with each of these network statements, as demonstrated in Example 8-8.

Example 8-8 Starting the RIP Routing Process on R2 and Advertising Networks 192.168.1.0, 192.168.2.0, and 192.169.2.0 Through RIP

 Termserver#  2  [Resuming connection 2 to r2 ... ] R2#  configure terminal  Enter configuration commands, one per line. End with CNTL/Z. R2(config)#  router rip  R2(config-router)#   network 192.168.1.0   R2(config-router)#   network 192.168.2.0   R2(config-router)#   network 192.169.2.0   R2(config-router)#  end  R2# %SYS-5-CONFIG_I: Configured from console by console R2# 

When a network is added to RIP, RIP not only advertises this network route, but it also sends updates on the interface corresponding to this network. R2 now broadcasts RIP advertisements to R1 through its Ethernet0 interface. This ensures that R1 receives the routes that it needs to get to R2's directly connected networks.

As done with R1, examine the RIP configuration on R2 as it appears in the running configuration in Example 8-9. As highlighted in the running configuration of R2, three networks on R2 are configured to be a part of the RIP routing process.

Example 8-9 Running Configuration of R2 After Configuration of RIP

 R2#  show running-config  Building configuration... Current configuration: ! version 12.0 service timestamps debug uptime service timestamps log uptime no service password-encryption ! hostname R2 ! enable password falcons ! ip subnet-zero no ip domain-lookup ip host R1 192.169.1.1 ip host R2 192.169.2.2 ip host R3 192.169.3.3 ip host R4 192.169.4.4 ip host R5 192.169.5.5 ip host R6 192.169.6.6 ! ! ! interface Loopback0  ip address 192.169.2.2 255.255.255.0  no ip directed-broadcast ! interface Ethernet0  ip address 192.168.1.2 255.255.255.0  no ip directed-broadcast ! interface Ethernet1  description This interface does not connect with another IP device  ip address 192.168.2.2 255.255.255.0  no ip directed-broadcast ! interface Serial0  description This interface connects to R3's S0 (201)  ip address 192.168.100.2 255.255.255.0  no ip directed-broadcast  encapsulation frame-relay  no ip mroute-cache  frame-relay map ip 192.168.100.3 201 broadcast  frame-relay map ip 192.168.100.4 201 broadcast  frame-relay lmi-type ansi !  router rip   network 192.168.1.0   network 192.168.2.0   network 192.169.2.0  ! ip classless ! banner motd ^CCC This is Router 2 ^C ! line con 0  exec-timeout 0 0  password falcons  logging synchronous  transport input none line vty 0 4  password falcons  login ! end R2# 

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 ping ing each other's Loopback0 interface. In addition, R1 now should be capable of ping ing 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.

Lab Follow-up Tasks

You now have successfully configured RIP and verified its proper operation. Now that RIP has been configured between R1 and R2, draw the RIP routing domains on the master lab diagram to help you to see and understand routing boundaries. For example, because you have configured RIP between R1 and R2, you should draw a line encompassing all interfaces that have been included in the RIP routing process. In this way, you can have a visual representation of what routes you'd expect to be advertised to neighboring RIP routers. See Figure 8-2 for an example.

Figure 8-2. RIP Routing Domain

You now are prepared to move on to IGRP configuration and operation.

---

Top