Problem: RIP Routes Not in the Routing Table

The routing table must have a network entry to send the packets to the desired destination. If there is no entry for the specific destination, the router will discard all the packets for this destination.

Example 3-1 shows that the routing table of R2 doesn't hold an entry for network 131.108.2.0.

Example 3-1 Routing Table for R2 Shows No RIP Routes for Subnet 131.108.2.0

 R2#  show ip route 131.108.2.0   % Subnet not in table  R2# 

The possible causes for this problem are as follows :

• Missing or incorrect network statement

• Layer 2 down

• Distribute list blocking the route

• Access list blocking RIP source address

• Access list blocking RIP broadcast/multicast

• Incompatible version type

• Mismatch authentication key (RIP-2)

• Discontiguous network

• Invalid source

• Layer 2 problem (switch, Frame Relay, other Layer 2 media)

• Offset list with a large metric defined

• Routes that reached RIP hop-count limit

• Sender problem (discussed in the next chapter)

Figure 3-1 provides a network scenario that will be used as the basis for troubleshooting a majority of the aforementioned causes of the problem of RIP routes not in the routing table. The sections that follow carefully dissect how to troubleshoot this problem based on specific causes.

Figure 3-1. Example Topology for the Problem of RIP Routes Not in the Routing Table

Figure 3-1 shows a setup in which Router 1 and Router 2 are running RIP between them.

RIP Routes Not in the Routing Table ‚ Cause: Missing or Incorrect network Statement

When you confirm that the route is missing from the routing table, the next step is to find out why. A route can be missing from the routing table for many reasons. The flowcharts at the beginning of this chapter can help isolate the cause that seems to fit most in your situation.

The obvious thing to check after discovering that the routes are not in the routing table is the router's configurations. Also check to see whether the network statement under router rip is properly configured.

When the network statement is configured, it does two things:

• Enables RIP on the interface and activates the capability to send and receive RIP updates

• Advertises that network in a RIP update packet

If the network statement under router rip command is not configured or misconfigured, it can cause this problem.

Figure 3-2 shows the flowchart to follow to solve this problem based on this cause.

Figure 3-2. Problem Resolution Flowchart

Debugs and Verification

Example 3-2 shows the configuration for Router R2 (as illustrated in Figure 3-1). The loop-back interface is used in this example and many other examples throughout the chapter. If the loopback interface is replaced with any other interface, it will not change the meaning. We suggest that you treat the loopback as any interface that is up and functional and that has a valid IP address.

Example 3-2 Configuration for Router R2 from Figure 3-1

  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0   !   router rip    network 131.107.0.0    !  

Refer back to Figure 3-1 and compare it to the configuration for R2 in Example 3-2. You notice that network 131.108.0.0 is missing from R2's configurations.

Example 3-3 shows the output of the show ip protocols command on R2. This output shows that the routing information source is also not displaying 131.108.1.1 as a gateway.

Example 3-3 show ip protocols Missing Gateway Information for Routing Information Source

 R2#  show ip protocols  Routing Protocol is "rip"   Sending updates every 30 seconds, next due in 11 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   Automatic network summarization is in effect   Routing for Networks:     131.107.0.0   Routing Information Sources:     Gateway         Distance      Last Update   Distance: (default is 120) 

Debug Commands

Example 3-4 shows the debug ip rip output. In this debug, R2 is ignoring the RIP updates coming from R1 because RIP is not enabled on Ethernet 0. This is because of the lack of a network statement for 131.108.0.0 under router rip in the router configuration mode.

Example 3-4 debug ip rip Command Output Displays That RIP Updates from Router R1 Are Being Ignored

 R2#  debug ip rip  RIP protocol debugging is on R2#  RIP: ignored v1 packet from 131.108.1.1 (not enabled on Ethernet0)  R2# 

Solution

Because the network statement is missing on Router 2, as shown in Example 3-2, it ignores RIP updates arriving on its Ethernet 0 interface, as seen in the debug output in Example 3-4. This problem can also happen if incorrect network statements are configured. Take a Class C address, for example. Instead of configuring 209.1.1.0, you configure 209.1.0.0, assuming that 0 will cover anything in the third octet. RIP-1 is a classful protocol, and it assumes the classful network statements. If a cidr statement is configured instead, RIP will not function properly.

To correct this problem, you must add the network statement in the configurations.

Example 3-5 shows the new configuration for Router R2 that solves this problem.

Example 3-5 New Configuration of R2 That Solves the Problem

  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0   !   router rip   network 131.107.0.0    network 131.108.0.0   

Example 3-6 shows the output of show ip protocols on R2. This output displays the gateway information now.

Example 3-6 show ip protocols Showing Gateway Set to the R1's Interface IP Address

 R2#  show ip protocols  Routing Protocol is "rip"   Sending updates every 30 seconds, next due in 12 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  Triggered RIP  Key-chain     Ethernet0        1     1 2     Loopback0        1     1 2   Automatic network summarization is in effect   Routing for Networks:     131.108.0.0   Routing Information Sources:     Gateway         Distance      Last Update  131.108.1.1          120      00:00:09  Distance: (default is 120) 

Example 3-7 shows the output of show ip route, which shows that Router R2 is learning the RIP route after the configuration change.

Example 3-7 show ip route Displays the Route Being Learned After Fixing the Problem

 R2#  show ip route 131.108.2.0  Routing entry for 131.108.2.0/24   Known via "rip", distance 120, metric 1   Redistributing via rip   Last update from 131.108.1.1 on Ethernet0, 00:00:11 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:11 ago, via Ethernet0       Route metric is 1, traffic share count is 1 

RIP Routes Not in the Routing Table ‚ Cause: Layer 1/2 Is Down

One cause for routes not in the routing table is Layers 1 or 2 being down. If Layers 1 or 2 are down, it's not a RIP problem. The following is a list of the most common things to check if the interface or line protocol is down:

• Unplugged cable

• Loose cable

• Bad cable

• Bad transceiver

• Bad port

• Bad interface card

• Layer 2 problem at telco, in case of a WAN link

• Missing clock statement, in case of back-to-back serial connection

Figure 3-3 shows the flowchart to follow to solve this problem based on this cause.

Figure 3-3. Flowchart to Solve Why RIP Routes Don't Show Up in a Routing Table

Debugs and Verification

Example 3-8 shows that the Ethernet interface's line protocol is down, indicating that something is wrong at Layer 1 or Layer 2.

Example 3-8 show interface output Displays That the Line Protocol Is Down

 R2#  show interface ethernet 0  Ethernet0 is up,  line protocol is down  Hardware is Lance, address is 0000.0c70.d41e (bia 0000.0c70.d41e)   Internet address is 131.108.1.2/24 

Debugs

Example 3-9 shows the output of debug ip rip. In this debug, R2 is not sending or receiving any RIP updates because Layer 2 is down .

Example 3-9 debug ip rip Command Output Shows Nothing Is Being Sent

 R2#  debug ip rip  RIP protocol debugging is on R2# 

Solution

RIP runs above Layer 2. RIP cannot send or receive any routes if Layer 2 is down.

The Layer 2 problem must be fixed. Sometimes, the problem could be as simple as loose cables, or it could be as complex as bad hardware; in which case, the hardware must be replaced.

Example 3-10 shows the output of show interface Ethernet 0 on R2 after the Layer 2 problem is fixed. The output shows that the line protocol is now up.

Example 3-10 show interface Output After Fixing the Layer 1/2 Problem Shows the Interface Ethernet0 Is Now Up

 R2#  show interface Ethernet0  Ethernet0 is up,  line protocol is up  Hardware is Lance, address is 0000.0c70.d41e (bia 0000.0c70.d41e)   Internet address is 131.108.1.2/24 

Example 3-11 shows the output of show ip route, which illustrates that the RIP route is being learned after fixing the Layer 1/2 problem.

Example 3-11 Routing Table Entry After Fixing the Layer 1/2 Problem

 R2#  show ip route 131.108.2.0  Routing entry for 131.108.2.0/24   Known via "rip", distance 120, metric 1   Redistributing via rip   Last update from 131.108.1.1 on Ethernet0, 00:00:07 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Ethernet0       Route metric is 1, traffic share count is 1 

RIP Routes Not in the Routing Table ‚ Cause: distribute-list in Is Blocking the Route

A distribute list is a filtering mechanism for routing updates. The distribute list calls an access list and checks to see which networks are supposed to be permitted. If the access list doesn't contain any network, the routing update will be automatically denied . A distribute list can be applied on either incoming routing updates or outgoing routing updates.

In this example, the distribute-list in is configured; however, the access list doesn't contain the permit statement for 131.108.0.0, so R2 is not installing these routes in the routing table.

Figure 3-4 shows the flowchart to follow to solve this problem based on this cause.

Figure 3-4. Flowchart to Solve Why RIP Routes Don't Show Up in a Routing Table

Debugs and Verification

Example 3-12 shows the current configuration of Router R2. In this configuration, access-list 1 is used to permit network 131.107.0.0; however, there is an implicit deny at the end of every access list, so 131.108.0.0 will also be denied. In the access list configuration, network 131.108.0.0 is not permitted, so the router is not installing any subnets of the 131.108.0.0 network.

Example 3-12 R2's Configuration Shows That Network 131.108.0.0 Is Being Blocked with an Implicit deny Under access-list 1

  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0   !   router rip   network 131.108.0.0    distribute-list 1 in     !     access-list 1 permit 131.107.0.0 0.0.255.255   

Solution

When a distribute list is used, you should always double-check your access list to make sure that the networks that are supposed to be permitted actually are permitted in the access list. The access list in Example 3-12 permits only 131.107.0.0 and denies everything else because there is an implicit deny at the end of each access list. To fix this problem, permit 131.108.0.0 in access-list 1.

Example 3-13 shows the new configuration of Router R2 with the access list to permit 131.108.0.0.

Example 3-13 Correcting the Configuration on R2 to Fix the Problem

  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0   !   router rip   network 131.108.0.0    distribute-list 1 in    !    access-list 1 permit 131.107.0.0 0.0.255.255     access-list 1 permit 131.108.0.0 0.0.255.255   

Example 3-14 shows that Router R2 is learning RIP routes after the configuration change.

Example 3-14 R2 Routing Table Is Learning the RIP Routes After the Correction

 R2#  show ip route 131.108.2.0  Routing entry for 131.108.2.0/24   Known via "rip", distance 120, metric 1   Redistributing via rip   Last update from 131.108.1.1 on Ethernet0, 00:00:07 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Ethernet0       Route metric is 1, traffic share count is 1 

RIP Routes Not in the Routing Table ‚ Cause: Access List Blocking RIP Source Address

Access lists are used to filter the traffic based on the source address. Extended access lists are used to filter the traffic based on the source or destination address, T-2. To filter the incoming and outgoing traffic, these access lists may be applied on the interface with this interface-level command:

  ip access-group   access-list number  {  in   out  } 

When the access list is applied in a RIP environment, always make sure that it doesn't block the source address of the RIP update. In this example, R2 is not installing RIP routes in the routing table because access-list 1 is not permitting the source address of RIP updates from R1.

Figure 3-5 shows the flowchart to follow to solve the problem based on this cause.

Figure 3-5. Flowchart to Solve Why RIP Routes Don't Show Up in a Routing Table

Debugs and Verification

Example 3-15 shows the current configuration of router R2. The access list in R2 is not permitting the source address of RIP updates, that is, 131.108.1.1. In Figure 3-1, 131.108.1.1 is the source address of R1 RIP updates. Because there is an implicit deny at the end of each access list, 131.108.1.1 will be automatically denied.

Example 3-15 access-list 1 Is Not Permitting the Source Address

 R2#  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0    ip access-group 1 in    !   router rip   network 131.108.0.0   !    access-list 1 permit 131.107.0.0 0.0.255.255   

Debugs

The output of debug ip rip in Example 3-16 shows that RIP is only sending the updates, not receiving anything, because the source address 131.108.1.1 is not permitted in the input access list of R2.

Example 3-16 debug ip rip Output Reveals That R2 Is Not Receiving Any RIP Updates

 R2#  debug ip rip  RIP: sending v1 update to 255.255.255.255 via Ethernet0 (131.108.1.2) RIP: build update entries         subnet 131.108.3.0 metric 1 RIP: sending v1 update to 255.255.255.255 via Loopback0 (131.108.3.1) RIP: build update entries         subnet 131.108.1.0 metric 1RIP: sending v1 update to 255.255.255.255 via Ethernet0 (131.108.1.2) RIP: build update entries         subnet 131.108.3.0 metric 1 RIP: sending v1 update to 255.255.255.255 via Loopback0 (131.108.3.1) RIP: build update entries         subnet 131.108.1.0 metric 1 R2# 

Solution

The standard access list specifies the source address. In this case, the source address is 131.108.1.1, which is the sending interface address of R1 . This source address is not permitted in the standard access list of R2, so RIP routes will not get installed in the routing table of R2. To solve this problem, permit the source address in access list 1.

Example 3-17 shows the new configuration change to fix this problem.

Example 3-17 The Modified Access List Permits the Source Address

 R2#  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0   ip access-group 1 in   !   router rip   network 131.108.0.0   !   access-list 1 permit 131.107.0.0 0.0.255.255    access-list 1 permit 131.108.1.1 0.0.0.0   

This problem can also happen when using extended access lists if the RIP source address is not permitted in the access list. This solution also can be used in the case of an extended access list. The idea here is to permit the source address of RIP update.

Example 3-18 shows the configuration with an extended access list.

Example 3-18 The Correct Extended Access List Configuration, if Used

 R2#  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0   ip access-group 100 in   !   router rip   network 131.108.0.0   !   access-list 100 permit ip 131.107.0.0 0.0.255.255 any    access-list 100 permit ip host 131.108.1.1 any   

Example 3-19 shows the routing table of Router R2, which shows that it has learning RIP routes after the configuration change.

Example 3-19 R2 Is Receiving RIP Routes After Fixing the Access List Configuration

 R2#  show ip route 131.108.2.0  Routing entry for 131.108.2.0/24   Known via "rip", distance 120, metric 1   Redistributing via rip   Last update from 131.108.1.1 on Ethernet0, 00:00:07 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Ethernet0       Route metric is 1, traffic share count is 1 

RIP Routes Not in the Routing Table ‚ Cause: Access List Blocking RIP Broadcast or Multicast (in Case of RIP-2)

Access lists are used to filter certain types of packets. When using access lists on the interface inbound, always make sure that they are not blocking the RIP broadcast or UDP port 520, which is used by RIP-1 and RIP-2 (or the RIP multicast address, in cases of RIP-2).

If these addresses are not permitted in the access list that is applied on the interface inbound, RIP will not install any routes in the routing table learned on that interface.

Figure 3-6 shows the flowchart to follow to solve this problem based on this cause.

Figure 3-6. Flowchart to Solve Why RIP Routes Don't Show Up in a Routing Table

Debugs and Verification

Example 3-20 shows the current configuration of R2. In this configuration, RIP's des-tination address of 255.255.255.255 is not being permitted. This will result in no RIP routes being installed in R2's routing table. The RIP updates sent from R1 to the destination of 255.255.255.255 will be blocked by R2.

Example 3-20 R2 Configuration Does Not Permit RIP-1 Broadcast Addresses

 R2#  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0    ip access-group 100 in    !   router rip   network 131.108.0.0   !    access-list 100 permit ip 131.107.0.0 0.0.255.255 any     access-list 100 permit ip host 131.108.1.1 host 131.108.1.2   

Solution

RIP-1 broadcasts its routing updates on 255.255.255.255. This address must be permitted in the input access list of the receiving router so that it can receive the RIP updates.

Example 3-21 shows the new configuration for Router R2. access-list 100 is modified so that it can permit the RIP broadcast address that was being blocked before.

Example 3-21 Configuring Router R2's Input Access List to Accept RIP-1 Broadcasts

  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0    ip access-group 100 in    !   router rip   network 131.108.0.0   !   access-list 100 permit ip 131.107.0.0 0.0.255.255 any   access-list 100 permit ip host 131.108.1.1 host 131.108.1.2    access-list 100 permit ip host 131.108.1.1 host 255.255.255.255   

In cases of RIP-2, the configuration will change slightly. The multicast address needs to be permitted instead of the broadcast address, as shown in Example 3-22.

Example 3-22 Configuring Router R2's Input Access List to Accept RIP-2 Multicast

  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0    ip access-group 100 in    !   router rip    version 2    network 131.108.0.0   !   access-list 100 permit ip 131.107.0.0 0.0.255.255 any   access-list 100 permit ip host 131.108.1.1 host 131.108.1.2    access-list 100 permit ip host 131.108.1.1 host 224.0.0.9   

Example 3-23 shows the routing table of R2 after correcting the problem.

Example 3-23 R2 Routing Table After Correcting the Access List Shows That the RIP Routes Are Being Learned

 R2#  show ip route 131.108.2.0  Routing entry for 131.108.2.0/24   Known via "rip", distance 120, metric 1   Redistributing via rip   Last update from 131.108.1.1 on Ethernet0, 00:00:07 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Ethernet0       Route metric is 1, traffic share count is 1 

RIP Routes Not in the Routing Table ‚ Cause: Incompatible RIP Version Type

When RIP is configured on a router, it is run by default as Version 1, which means that all its interfaces will send and receive RIP-1 packets only. To run Version 2 of RIP, you must add the version 2 line under router rip. When a router running Version 1 receives a RIP update from a router running Version 2, it ignores the updates and does not install any routes in the routing table. For a router to accept a Version 2 packet, the interface must be con-figured to accept the RIP-2 updates.

Figure 3-7 shows the flowchart to follow to solve this problem based on this cause.

Figure 3-7. Flowchart to Solve Why RIP Routes Don't Show Up in a Routing Table

Debugs and Verification

Example 3-24 shows the configuration of Router R2. In this configuration, RIP is configured to send and receive Version 1 packets only.

Example 3-24 R2 Configuration Shows That It Is Configured for RIP-1, Which Is the Default

 R2#  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0   !   router rip   network 131.108.0.0   !  

Example 3-25 shows the output of the debug ip rip command. This command reveals that R2 is receiving a RIP packet from R1, which is configured to send Version 2 updates.

Example 3-25 debug ip rip Command Output Shows the Version Incompatible Message on R2

 R2#  debug ip rip  RIP protocol debugging is on  RIP: ignored v2 packet from 131.108.1.1 (illegal version)  

Example 3-26 shows the output of the show ip protocols command, which indicates that the Ethernet0 interface is sending and receiving RIP-1 packets. This means that if a Version 2 packet is received on Ethernet 0 of R2, it will be ignored because the interface can send and receive only Version 1 packets.

Example 3-26 show ip protocols Command Output Reveals the RIP Sends Out and Receives Only RIP Version 1 Packets on Ethernet0

 R2#  show ip protocols  Routing Protocol is "rip"   Sending updates every 30 seconds, next due in 9 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 version 1  Interface        Send  Recv   Key-chain   Ethernet0        1     1   Loopback0        1     1  Routing for Networks:     131.108.0.0   Routing Information Sources:     Gateway         Distance      Last Update     131.108.1.1          120      00:01:34   Distance: (default is 120) R2# 

Example 3-27 shows the configuration of R1. This shows that sender R1 is configured to send Version 2 packets. The command version 2 enables a router to send and accept only RIP-2 packets.

Example 3-27 R1's Configuration Reveals That It Is Configured for RIP Version 2 Packets

 R1#  router rip    version 2    network 131.108.0.0  

Example 3-28 shows the output of the show ip protocols command, which shows that the sender R1 is sending and receiving only Version 2 packets. This is because of the version 2 command that is configured under router rip.

Example 3-28 show ip protocols Command Output Reveals That R1 Is Sending and Receiving Only RIP Version 2 Packets

 R1#  show ip protocols  Routing Protocol is "rip"   Sending updates every 30 seconds, next due in 13 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 2, receive version 2  Interface        Send  Recv   Key-chain   Ethernet0/1      2     2   Loopback1        2     2  Routing for Networks:     131.108.0.0   Routing Information Sources:     Gateway         Distance      Last Update     131.108.1.2          120      00:04:09   Distance: (default is 120) 

Solution

If the receiver R2 is configured to receive only RIP Version 1 packets, it will ignore the RIP Version 2 updates. You must configure Router R1 on the sender's side so that it will send both Version 1 and Version 2 packets. When R2 receives the Version 1 packet, it will install the routes in the routing table. R2 will ignore RIP-2 packets because it is configured for RIP-1.

Example 3-29 shows the new configuration for R1. In this configuration, the sender (R1's Ethernet interface) is configured to send and receive both RIP-1 and RIP-2 packets.

Example 3-29 New Configuration of R1 to Send and Receive Version 1 and Version 2 Packets

 R1#  interface Loopback0   ip address 131.108.2.1 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.1 255.255.255.0    ip rip send version 1 2     ip rip receive version 1 2    !   router rip    version 2    network 131.108.0.0  

Example 3-30 shows the output of show ip protocols, which indicates that the Ethernet0 interface is sending and receiving Version 1 and Version 2 packets. The advantage of send-ing both Version 1 and Version 2 updates is that, if any devices on this Ethernet segment are running Version 1 only or Version 2 only, those devices will be capable of communicating with R1 on Ethernet.

Example 3-30 show ip protocols Command Output Reveals the RIP Version 1 and 2 Packets Being Sent and Received by R1's Ethernet0 Interface

 R1#  show ip protocols  Routing Protocol is "rip"   Sending updates every 30 seconds, next due in 4 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 2, receive version 2     Interface        Send  Recv   Key-chain  Ethernet0        1 2   1 2  Loopback0        2     2   Routing for Networks:     131.108.0.0   Routing Information Sources:     Gateway         Distance      Last Update     131.108.1.2          120      00:00:07   Distance: (default is 120)  R1# 

Example 3-31 shows R2's routing table after the configuration change.

Example 3-31 R2 Routing Table After R1 Is Configured to Send and Receive RIP-1 and RIP-2 Packets

 R2#  show ip route 131.108.2.0  Routing entry for 131.108.2.0/24   Known via "rip", distance 120, metric 1   Redistributing via rip   Last update from 131.108.1.1 on Ethernet0, 00:00:07 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Ethernet0       Route metric is 1, traffic share count is 1 

RIP Routes Not in the Routing Table ‚ Cause: Mismatch Authentication Key (RIP-2)

One of the options in RIP-2 is that the RIP-2 updates can be authenticated for increased security. When authentication is used, a password must be configured on both sides. This password is called the authentication key. If this key does not match with the key on the other side, the RIP-2 updates will be ignored on both sides.

Figure 3-8 shows the flowchart to follow to solve this problem based on this cause.

Figure 3-8. Flowchart to Solve Why RIP Routes Don't Show Up in a Routing Table

Debugs and Verification

Example 3-32 shows the configurations of routers R1 and R2 when this problem happens. In this configuration, a different RIP authentication key is configured on R1 and R2. The R2 Ethernet interface is configured with the key cisco1, whereas R1 is configured with the key Cisco. These two keys do not match, so they ignore each other's update and routes will not be installed in the routing table.

Example 3-32 Configurations for R1 and R2 Show That Different Authentication Keys Are Configured on Each Side

 R2#  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0    ip rip authentication key-chain cisco1    !   router rip    version 2    network 131.108.0.0   !  _____________________________________________________________________________________ R1#  interface Loopback0   ip address 131.108.2.1 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.1 255.255.255.0    ip rip authentication key-chain cisco    !   router rip    version 2    network 131.108.0.0   !  

Example 3-33 shows the output from the debug ip rip command on R2 that indicates that R2 is receiving a RIP packet that has invalid authentication. This means that the authen-tication key between sender and receiver doesn't match.

Example 3-33 debug ip rip Command Output Reveals Invalid Authentication for a RIP-2 Packet Received on R2

 R2#  debug ip rip  RIP protocol debugging is on  RIP: ignored v2 packet from 131.108.1.1 (invalid authentication)  

Solution

When using authentication in RIP, make sure that the sender and the receiver are configured with the same authentication key. Sometimes, adding a space at the end of the key can cause the invalid authentication problem because a space will be taken as a literal key entry. As a result, this causes a problem that cannot be corrected just by looking at the configurations.

Debugs will show that there is a problem with the authentication key. To solve this problem, configure the same keys on both sender and receiver, or retype the authentication key, making sure that no space is being added at the end.

Example 3-34 shows the new configuration to correct this problem. The authentication key is reconfigured on Router R2 to match Router the key on R1.

Example 3-34 R2 Configuration with the Corrected Authentication Key

 R2#  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0    ip rip authentication key-chain cisco    !   router rip    version 2    network 131.108.0.0   !  

Example 3-35 shows the routing table of R2 after the configuration change.

Example 3-35 R2 Routing Table After Reconfiguring the Authentication Key on R2

 R2#  show ip route 131.108.2.0  Routing entry for 131.108.2.0/24   Known via "rip", distance 120, metric 1   Redistributing via rip   Last update from 131.108.1.1 on Ethernet0, 00:00:07 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Ethernet0       Route metric is 1, traffic share count is 1 

RIP Routes Not in the Routing Table ‚ Cause: Discontiguous Network

When a major network is separated by another major network in the middle, this is called a discontiguous network. Chapter 2, "Understanding Routing Information Protocol (RIP)," provides a detailed explanation of why RIP does not support discontiguous networks. Enabling RIP with this topology causes problems.

Figure 3-9 shows an example of a discontiguous network that exists when a major network is separated by another major network.

Figure 3-9. An Example of a Discontiguous Network

Figure 3-10 shows the flowchart to follow to solve this problem based on this cause.

Figure 3-10. Flowchart to Solve Why RIP Routes Don't Show Up in a Routing Table

Debugs and Verification

Example 3-36 shows the configuration of Router R1 and Router R2. RIP is enabled on the Ethernet interfaces of R1 and R2 with the correct network statement.

Example 3-36 Configuration of R1 and R2 in a Discontiguous Network Environment

 R2#  interface Loopback0   ip address 137.99.3.2 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0   !   router rip   network 131.108.0.0   network 137.99.0.0   !  _____________________________________________________________________________________ R1#  interface Loopback0   ip address 137.99.2.1 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.1 255.255.255.0   !   router rip   network 131.108.0.0   network 137.99.0.0   !  

Example 3-37 shows the debug ip rip output for routers R1 and R2. Both debugs shows that the network 137.99.0.0 is being sent across.

Example 3-37 debug ip rip Output Showing That Both Routers Are Sending Summarized Major Network Addresses Across

 R2#  debug ip rip  RIP protocol debugging is on RIP: received v1 update from 131.108.1.1 on Ethernet0  137.99.0.0 in 1 hops  RIP: sending v1 update to 255.255.255.255 via Ethernet0 (131.108.1.2) RIP: build update entries         network 137.99.0.0 metric 1 R2# _____________________________________________________________________________________ R1#  debug ip rip  RIP protocol debugging is on R1# RIP: received v1 update from 131.108.1.2 on Ethernet0  137.99.0.0 in 1 hops  RIP: sending v1 update to 255.255.255.255 via Ethernet0 (131.108.1.1) RIP: build update entries         network 137.99.0.0 metric 1 

As a result, both routers will ignore the 137.99.0.0 update from each other. Because R1 and R2 are already connected to this major network, they will ignore the update.

Solution

RIP is not installing the route 137.99.0.0 in the routing table because RIP doesn't support discontiguous networks, as discussed in the beginning of the chapter. Several solutions to this problem exist. The quick solution is to configure a static route to the more specific subnets of 137.99.0.0 on each router. The second solution is to enable Version 2 of RIP. Another solution is to replace RIP with another IP routing protocol, such as OSPF, IS-IS, EIGRP, and so on, that supports discontiguous networks.

Example 3-38 shows the configuration change that is required for both Router R1 and Router R2 to fix the problem. This configuration adds the static route for the discontiguous subnets. Because you cannot pass the subnet information across in case of discontiguous networks in RIP-1, the only solution is to patch it with static routes.

Example 3-38 Static Route Configuration Should Solve This Problem

 R1#  interface Loopback0   ip address 137.99.2.1 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.1 255.255.255.0   !   router rip   network 131.108.0.0   network 137.99.0.0   !    ip route 137.99.3.0 255.255.255.0 131.108.1.2   _____________________________________________________________________________________ R2#  interface Loopback0   ip address 137.99.3.2 255.255.255.0   !   interface Ethernet0   ip address 131.108.1.2 255.255.255.0   !   router rip   network 131.108.0.0   network 137.99.0.0   !    ip route 137.99.2.0 255.255.255.0 131.108.1.1   

Example 3-39 shows the alternate solution to fix this problem, in the case of RIP-2. The solution is to run RIP-2 with no auto-summary configured. With the no-auto summary command added, RIP-2 will not autosummarize when crossing a major network boundary. The specific subnet information will be sent across.

Example 3-39 Configuration That Works Under RIP-2 in a Discontiguous Network Environment

  router rip    version 2    network 131.108.0.0   network 137.99.0.0    no auto-summary   

Example 3-40 shows the routing table of R2 after fixing this problem.

Example 3-40 R2 Routing Table Shows That 137.99.2.0/24 Is Learned Through RIP-2 After Configuring the no-auto summary Command

 R2#  show ip route 137.99.2.0   Routing entry for 13799.2.0/24   Known via "rip", distance 120, metric 1  Redistributing via rip   Last update from 131.108.1.1 on Ethernet0, 00:00:07 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:07 ago, via Ethernet0       Route metric is 1, traffic share count is 1 

RIP Routes Not in the Routing Table ‚ Cause: Invalid Source

When RIP tells the routing table to install the route, it performs a source-validity check. If the source is not on the same subnet as the local interface, RIP ignores the update and does not install routes in the routing table coming from this source address.

Figure 3-11 shows the network diagram for invalid source problem.

Figure 3-11. Network Diagram for Invalid Route Source

In Figure 3-11, Router 1's Serial 0 interface is unnumbered to Loopback 0. Router 2's serial interface is numbered. When Router 2 receives a RIP update from Router 1, it complains about the source validity because the source address is not on the same subnet as Router 2's Serial 0 interface.

Figure 3-12 shows the flowchart to follow to solve this problem based on this cause.

Figure 3-12. Flowchart to Solve Why RIP Routes Don't Show Up in a Routing Table

Debugs and Verification

Example 3-41 shows the configuration of both Router R2 and Router R1. In this config-uration, R1's Serial 0 interface is unnumbered to Loopback 0. R2's Serial 0 interface is numbered.

Example 3-41 Configuration of R2 and R1 Showing That R1's Serial 0 Interface Is Unnumbered and R2's Isn't

 R2#  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Serial0   ip address 131.108.1.2 255.255.255.0   !   router rip   network 131.108.0.0   !  _____________________________________________________________________________________ R1#  interface Loopback0   ip address 131.108.2.1 255.255.255.0   !   interface Serial0    ip unnumbered Loopback0    !   router rip   network 131.108.0.0   !  

The debug ip rip output in Example 3-42 shows that R2 is ignoring the RIP update from R1 because of a source validity check. The RIP update coming from R1 is not on the same subnet, so R2 will not install any routes in the routing table.

Example 3-42 debug ip rip Message Shows That R2 Is Receiving RIP Updates from a Different Source Address Than Its Own Interface

 R2#  debug ip rip  RIP protocol debugging is on  RIP: ignored v1 update from bad source 131.108.2.1 on Serial0  R2# 

Solution

When one side is numbered and the other side is unnumbered, this check must be turned off. This is usually the case in a dialup situation when remotes are dialing into an access router. The access router's dialup interface is unnumbered, and all remote routers get an IP address assigned on their dialup interfaces.

Example 3-43 shows the new configuration change on Router R2 to fix this problem.

Example 3-43 Configuration of R2 to Turn Off the Source Validity Check

 R2#  interface Loopback0   ip address 131.108.3.2 255.255.255.0   !   interface Serial0   ip address 131.108.1.2 255.255.255.0   !   router rip    no validate-update-source    network 131.108.0.0   !  

Example 3-44 shows that after changing the configurations of R2, the route gets installed in the routing table.

Example 3-44 R2 Routing Table After Turning Off Source Validity Check

 R2#  show ip route 131.108.2.0   Routing entry for 131.108.2.0/24   Known via "rip", distance 120, metric 1  Redistributing via rip   Last update from 131.108.1.1 00:00:01 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:07 ago       Route metric is 1, traffic share count is 1 

RIP Routes Not in the Routing Table ‚ Cause: Layer 2 Problem (Switch, Frame Relay, Other Layer 2 Media)

Sometimes, multicast/broadcast capability is broken at Layer 2, which further affects Layer 3 multicast. As a result, RIP fails to work properly. The Layer 3 broadcast/multicast is further converted into Layer 2 broadcast/multicast. If Layer 2 has problems in handling Layer 2 multicast/broadcast, the RIP updates will not be propagated. The debugs show that broadcast or multicast is being originated at one end but is not getting across.

Figure 3-13 shows the network diagram for Frame Relay problems while running RIP.

Figure 3-13. Two Routers Running RIP in a Frame Relay Environment

In Figure 3-13, Router 1 and Router 2 are connected through any Layer 2 media ‚ for example, Frame Relay, X.25, Ethernet, FDDI, and so on.

Figure 3-14 shows the flowchart to follow to solve this problem based on this cause.

Figure 3-14. Flowchart to Solve Why RIP Routes Don't Show Up in a Routing Table

Debugs and Verification

Example 3-45 shows the output of the debug ip rip command, which shows that R1 is sending and receiving RIP updates without any problem. On R2, RIP updates are being sent but not received. This means that the RIP update is being lost at Layer 2.

Example 3-45 debug ip packet Against access-list 100 Shows That R1 Is Sending RIP Updates on the Wire, and R2 Is Not Receiving It

 R1#  debug ip packet 100 detail  IP packet debugging is on (detailed) for access list 100 R1#  IP: s=131.108.1.1 (Ethernet0), d=255.255.255.255, len 132, sending broadcast/   multicast   UDP src=520, dst=520  IP: s=131.108.1.1 (Ethernet0), d=255.255.255.255, len 132, rcvd 2     UDP src=520, dst=520 _____________________________________________________________________________________ R2#  debug ip packet 100 detail  IP packet debugging is on (detailed) for access list 100 R2# IP: s=131.108.1.2 (Ethernet0), d=255.255.255.255, len 132, sending broadcast/ multicast     UDP src=520, dst=520 IP: s=131.108.1.2 (Ethernet0), d=255.255.255.255, len 132, sending broadcast/ multicast     UDP src=520, dst=520 

Example 3-46 shows access-list 100, which is used against the debug to look at the RIP broadcast/multicast specifically .

Example 3-46 access-list 100 Is Used Against the Debugs to Minimize the Traffic

  access-list 100 permit ip any host 255.255.255.255   access-list 100 permit ip any host 224.0.0.9  

Example 3-47 shows a way to find out if this is the problem when running RIP-2. Ping the multicast address of 224.0.0.9 ‚ if the neighbor doesn't reply, this can mean that multicast is broken at Layer 2.

Example 3-47 Multicast Pings Are Failing, Which Means That R2's Multicast Is Getting Lost at Layer 2

 R2#  ping 224.0.0.9  Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 224.0.0.9, timeout is 2 seconds:  .....  R2# 

Solution

RIP-1 sends an update on a broadcast address of 255.255.255.255. In the case of RIP-2, the update is sent on a multicast address of 224.0.0.9. If these two addresses get blocked at Layer 2 or are not being propagated at Layer 2, RIP will not function properly. Layer 2 could be a simple Ethernet switch, a Frame Relay cloud, a bridging cloud, and so on. Fixing the Layer 2 problem is beyond the scope of this book.

Example 3-48 shows that after fixing the Layer 2 problem, RIP routes get installed in the routing table.

Example 3-48 R2 Is Installing RIP Routes After Fixing the Layer 2 Problems

 R2#  show ip route 131.108.2.0   Routing entry for 131.108.2.0/24   Known via "rip", distance 120, metric 1  Redistributing via rip   Last update from 131.108.1.1 00:00:01 ago   Routing Descriptor Blocks:   * 131.108.1.1, from 131.108.1.1, 00:00:07 ago       Route metric is 1, traffic share count is 1 

RIP Routes Not in the Routing Table ‚ Cause: Offset List Has a Large Metric Defined

Offset lists are used to increase the metric value of RIP updates coming in or going out. The use of an offset list can directly influence the routing table. This list can be applied on selected networks that can be defined in an access list. If the offset value is a large number, such as 14 or 15, the RIP metric will reach infinity when it crosses a couple of routers. That's why the offset list value should be kept to a minimum value.

Figure 3-15 shows a network setup that can produce a problem in the case of a misconfigured offset list.

Figure 3-15. Network Topology Used for Misconfigured Offset Lists Problem Reproduction

Example 3-49 shows that the specific router 131.108.6.0 is not in the routing table of R2.

Example 3-49 R2's Routing Table Missing the Subnet That Is Off R3

 R2#  show ip route 131.108.6.0   % Subnet not in table  

Figure 3-16 shows the flowchart to follow to solve this problem based on this cause.

Figure 3-16. Flowchart to Solve Why RIP Routes Don't Show Up in a Routing Table

Debugs and Verification

Troubleshooting should be done to investigate RIP's normal behavior.

Example 3-50 shows that R2 is receiving other RIP routes, but not 131.108.6.0/24.

Example 3-50 R2 Is Missing 131.108.6.0/24 from Its Routing Table

 R2#  show ip route RIP  131.108.0.0/24 is subnetted, 4 subnets R       131.108.5.0 [120/1] via 131.108.1.1, 00:00:06, Ethernet1 R       131.108.3.0 [120/1] via 131.108.1.1, 00:00:06, Ethernet1 

This shows that problem is with 131.108.6.0/24, not with RIP in general. The reason is that R3 is receiving other RIP routes from R1, so the RIP update that is coming from R1 is working fine.

Example 3-51 shows the routing table of R1, where 131.108.6.0/24 is present in the routing table.

Example 3-51 R1 Sees 131.108.6.0/24 in Its Routing Table

 R1#  show ip route 131.108.6.0   Routing entry for 131.108.6.0/24   Known via "rip", distance 120, metric 1  

So why is R2 not installing 131.108.6.0/24? This could be because of one of the following reasons:

• R1 is not advertising to R2.

• R1 is advertising, but R2 is not receiving.

• R2 is receiving but is discarding it because of an infinite metric.

The simplest way to troubleshoot such problems is quick configuration examination.

Example 3-52 shows the configuration of Router R1.

Example 3-52 The Offset List Has a Large Value Configured on R1 for 131.108.6.0/24

 R1#  router rip   version 2    offset-list 1 out 15 Ethernet0/1    network 131.108.0.0   !    access-list 1 permit 131.108.6.0   

The administrator has configured an offset list with a very large metric. The offset list is used to change the metric of RIP update.

From the configuration, you can surmise that any update that passes access-list 1 will have 15 added in the metric. In Example 3-52, access-list 1 permits 131.108.6.0. This means that the metric of 131.108.6.0 is 16, which, to RIP, is an infinite metric; upon receiving it, R2 will reject it.

To verify this, run the debug ip rip command, as demonstrated in Example 3-53.

Example 3-53 debug ip rip on R2 Shows That 131.108.6.0 Is Received with an Infinite Metric

 R2#  debug ip RIP  RIP: received v2 update from 131.108.1.1 on Ethernet1  131.108.6.0/24 -> 0.0.0.0 in 16 hops (inaccessible)  

Because 16 is the infinite metric for RIP, R2 will reject 131.108.6.0/24 from going in the routing table.

Solution

Typically, offset lists are not used in RIP networks. When the network has redundant equal-hop (cost) paths and the administrator wants one route preferred over another, an offset list can be used.

For example, suppose that two links exist between R1 and R2. One of the links could be either congested or experiencing delay.

The administrator might want to shift the IP traffic for certain destination subnets to a noncongested link for a short time, to get better throughput and to alleviate some of the congestion. An offset list is an easy way to achieve this by making the RIP metric higher for the subnets on the congested interface.

Example 3-54 shows the new configuration of Router R1.

To fix the problem, configure an offset value so that the hop count won't reach its limit

Example 3-54 New Configuration on R1 with Appropriate Offset List Value

 R1#  router rip   version 2    offset-list 1 out 1 Ethernet0/1    network 131.108.0.0   !   access-list 1 permit 131.108.6.0  

Example 3-55 shows the routing table of Router R2 after fixing the problem.

Example 3-55 R2's Routing Table Shows the Entry for 131.108.6.0/24 After Configuring the Proper Offset List

 R2#  show ip route 131.108.6.0  Routing entry for 131.108.6.0/24  Known via "rip", distance 120,  metric 1  

RIP Routes Not in the Routing Table ‚ Cause: Routes Reached RIP Hop Count Limit

The RIP metric can go up to a maximum of 15 hops. If a network has more than 15 hops, RIP is not a suitable protocol for it.

Figure 3-17 shows a network setup that produces a RIP hop-count limit problem.

Figure 3-17. Network Setup That Can Produce a RIP Hop-Count Limit Problem

R2 is receiving an update for a RIP route, which is several (more than 15) hops away. R2 doesn't install that route in the routing table, as demonstrated in the output in Example 3-56.

Example 3-56 R2's Routing Table Is Missing the Route for 131.108.6.0

 R2#  show ip route 131.108.6.0   % Subnet not in table  

Figure 3-18 shows the flowchart to solve this problem.

Figure 3-18. Flowchart to Solve Why RIP Routes Don't Show Up in a Routing Table

Debugs and Verification

The most logical way to start troubleshooting this problem is to look at R1 and determine whether R1 is receiving 131.108.6.0/24.

Example 3-57 shows that Router R1 is receiving RIP routes for 131.108.6.0/24.

Example 3-57 R1's Routing Table Has 131.108.6.0/24 with a Metric of 15 (Maximum RIP Metric)

 R1#  show ip route 131.108.6.0  Routing entry for 131.108.6.0/24 Known via "rip", distance 120,  metric 15  

R1 is receiving the route in question, but with a metric of 15. R1 will add 1 more to 15 when advertised to R2, which will result in an infinite metric, consequently preventing the route from being placed in the routing table.

To prove this, in R1, you can run the debug ip rip command to view the process in real time.

Example 3-58 shows the output of debug ip rip on Router R1.

Example 3-58 debug ip rip Output Shows That R1 Is Advertising 131.108.6.0 with a Metric of 16 (Infinity)

 R1#  debug ip rip  RIP protocol debugging is on RIP: sending v2 update to 224.0.0.9 via Ethernet1 (131.108.1.1)          131.108.6.0/24 -> 0.0.0.0,  metric 16,  tag 0 

Example 3-59 shows the output of debug ip rip on Router R2. Router R2 receives this update and discards it because the metric shows that this network is infinitely far away and, therefore, unreachable.

Example 3-59 debug ip rip Output on R2 Shows That R2 Is Receiving Routes with an Infinite Metric

 R2#  debug ip rip  RIP protocol debugging is on RIP: received v2 update from 131.108.1.1 on Ethernet1        131.108.6.0/24 -> 0.0.0.0 in  16 hops (inaccessible)  

Solution

This is a classical RIP problem in which a route passes through more than 15 devices. IP networks these days usually have more than 15 routers. There is no way to overcome this behavior other than to pick a routing protocol that does not have a 15-hop limitation. You should use OSPF, EIGRP, or IS-IS instead.