IP Access List Security for CCNA Exam #640-607
Date: Apr 19, 2002
This chapter covers the following key topics:
- RIP routing updates
- RIP routing metric
- RIP scalability and limitations
- RIP stability features
- Configuring RIP
RIP Fundamentals
The Routing Information Protocol (RIP) is a comparatively old interior gateway protocol (IGP) still in widespread use. IGPs are used for routing within networks that are under a common network administration, whereas exterior gateway protocols are used to exchange routing information between networks. As an IGP, RIP performs routing only within a single autonomous system. RIP is a classical distance vector routing protocol that uses hop count as its metric for determining the best route to a given destination.
RIP Routing Updates
RIP sends routing update messages at regular 30-second intervals and when the network topology changes. RIP uses broadcast User Datagram Protocol (UDP) data packets to exchange routing information. The routing update process is termed advertising. When a router receives a routing update that includes changes to an entry, it updates its routing table to reflect the new route. The metric value for the path is increased by 1, and the sender is indicated as the next hop. RIP routers maintain only the best route (the route with the lowest metric value) to a destination. After updating its routing table, the router immediately begins transmitting routing updates to inform other network routers of the change. These updates are sent in addition to the regularly scheduled 30-second interval updates that RIP routers send.
RIP Routing Metric
RIP uses a single routing metric (hop count) to measure the distance between the source and a destination network. Each hop in a path from source to destination is assigned a hop-count value, which is 1. When a router receives a routing update that contains a new or changed destination-network entry, the router adds 1 to the metric value indicated in the update and enters the network in the routing table. The IP address of the sender is used as the next hop.
RIP prevents routing loops from continuing indefinitely by implementing a limit on the number of hops allowed in a path from the source to a destination. The maximum number of hops in a path is 15. If a router receives a routing update that contains a new or changed entry, and if increasing the metric value by 1 causes the metric to be infinity (defined as 16), the network destination is considered unreachable.
RIP Scalability and Limitations
The low hop count of RIP is considered a scalability limitation for large networks. Another limitation is that RIP Version 1 (RIP-1) is a classful routing protocol and does not carry subnet mask information in its routing updates.
NOTE
RIP Version 2 (RIP-2) was introduced to address this limitation. The RIP-2 specification (described in RFC 1723) allows more information, such as the subnet mask, to be included in RIP packets and provides a simple authentication mechanism.
Because of this, RIP-1 does not support the use of variable-length subnet masking (VLSM). VLSM provides the capability to specify a different subnet mask for the same network number, but on different subnets. Before RIP-1 sends out an update, it performs a check against the subnet mask of the network that is about to be advertised. If a VLSM has been assigned, the subnet gets dropped from the advertisement. This limitation also poses scalability issues for large networks in which address space is limited.
RIP Stability Features
RIP implements mechanisms such as split horizon, hold-down timers, hop-count limits, and poison reverse to prevent routing loops and maintain network stability, as explained in the list that follows:
Split horizon—If a route is learned on an interface, the information about that route is not sent back out the interface where it was learned. In this way, split horizon prevents routing loops within the network.
Hold-down timers—These timers ignore routing update information for a specified period of time. Hold-down timers can be reset when the timer expires, a routing update is received that has a better metric, or a routing update is received indicating that the original route to the network is valid. Hold-down timers are useful in preventing routing information from flooding the network when network links are unstable.
Hop-count limit—This limits the number of hops allowed in a path from source to destination. The maximum is 15, and 16 is deemed unreachable. The hop-count limit prevents routing loops from continuing indefinitely.
Poison reverse—A route is "poisoned" when a router marks a route as unreachable by setting the hop count to 16 and then passes this route out to a neighboring router, causing the neighboring router to remove the route from its routing table. This speeds network convergence by preventing invalid routes from being propagated throughout the network.
These features allow RIP to adjust to network-topology changes and prevent routing loops from being propagated and continuing indefinitely.
Now that you are familiar with the fundamentals of RIP, you should be able to begin the lab for this chapter.
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.
Example 8-1 IP Routing Table on R1 Before the Configuration of IP RIP
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 interfaces—Ethernet0, 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 pinging 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 pinging R2's Loopback0 interface of 192.169.2.2, as shown in Example 8-4.
Example 8-4 R1 Incapable of pinging 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 pings 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 pinging 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 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.
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.