Troubleshooting RIP 

Troubleshooting RIP:  Below are the potential causes that may affect RIP (Routing Information Protocol) routing.

1. Network statement incorrect or missing under RIP router config.
2. Layer 2 down: Layer 2 can be down due to reasons like unplugged or loose cable, faulty cable, faulty transceiver/SFP, faulty router/device port, faulty network/interface card.
   
3. Layer 2 issue at provider network, in case of a WAN link. There could also be problem with provider Frame Relay switch, other layer 2 media.
4. Missing clock statement, in case of back-to-back serial connection.
5. Distribute-list blocking the RIP route advertisement.
   
6. Access list blocking RIP source address.
7. Access list blocking RIP broadcast/multicast updates.
   
8. Incompatible or mismatch in RIP version type.
9. Mismatch authentication key (RIP-2).
10. Discontiguous network
11. Invalid source.
12. Offset-list with a large metric defined.
13. Routes that reached RIP hop-count limit.

Let's discuss few of these problems that are important. 

Troubleshooting RIP -  Incorrect Network statement  or missing under RIP router config

R1#show ip route 10.10.0.3
% Subnet not in table

R3#show run | section rip
router rip
 version 2
 network 20.0.0.0
 no auto-summary

We can see a wrong network statement configured on R3.  Let's correct it with correct network statement.

 

R3#show run | section rip
router rip
 version 2
 network 10.0.0.0
 no auto-summary

R1#show ip route 10.10.0.3
  Routing entry for 10.10.0.3/32
  Known via "rip", distance 120, metric 2
  Redistributing via rip
  Last update from 10.10.12.2 on FastEthernet1/0, 00:00:02 ago
  Routing Descriptor Blocks:
  * 10.10.12.2, from 10.10.12.2, 00:00:02 ago, via FastEthernet1/0
    Route metric is 2, traffic share count is 1

Troubleshooting RIP - Distribute-list blocking the RIP route advertisement

R1#show ip route 10.10.0.3
% Subnet not in table

R1#show run | s router rip
router rip
 version 2
 network 10.0.0.0
 distribute-list filter in
 no auto-summary

R1#show ip access-lists filter
Standard IP access list filter

10 permit 10.10.0.2 (5 matches)

We can see that only 10.10.0.2 is permitted in access-list 'filter'. Let's permit 10.10.0.3 in the ACL.

 

R1(config-std-nacl)#permit 10.10.0.3

R1#show ip route 10.10.0.3
  Routing entry for 10.10.0.3/32
  Known via "rip", distance 120, metric 2
  Redistributing via rip
  Last update from 10.10.12.2 on FastEthernet1/0, 00:00:02 ago
  Routing Descriptor Blocks:
  * 10.10.12.2, from 10.10.12.2, 00:00:02 ago, via FastEthernet1/0
     Route metric is 2, traffic share count is 1

Troubleshooting RIP - Access list blocking RIP broadcast/multicast updates.

R1#sho ip route 10.10.0.3
% Subnet not in table

We are running RIPv2 in the lab. While troubleshooting, we observed an ACL configured on R1's F1/0 interface that blocks the RIP multicast packets/updates from R2.

R1#show run int f1/0
interface FastEthernet1/0
 ip address 10.10.12.1 255.255.255.0
 ip access-group 100 in

R1#show ip access-lists 100
Extended IP access list 100
10 permit ip host 10.10.12.2 host 10.10.0.1

Let's enable the multicast packet flow in ACL

 

R1#show ip access-lists 100
Extended IP access list 100
20 permit ip host 10.10.12.2 host 224.0.0.9

R1#show ip route 10.10.0.3
  Routing entry for 10.10.0.3/32
  Known via "rip", distance 120, metric 2
  Redistributing via rip
  Last update from 10.10.12.2 on FastEthernet1/0, 00:00:02 ago
  Routing Descriptor Blocks:
  * 10.10.12.2, from 10.10.12.2, 00:00:02 ago, via FastEthernet1/0
     Route metric is 2, traffic share count is 1

For RIPv1 we have to enable broadcast address in ACL as below:

 

R1#show ip access-lists 100
Extended IP access list 100
20 permit ip host 10.10.12.2 host 255.255.255.255

 

Troubleshooting RIP - Incompatible or mismatch in RIP version type.

Let's assume R1 does not support RIPv2, therefore it is running RIPv1.  R2 and R3 are running RIPv2.  RIP communication will fail between R1 and R2 because of RIP version incompatibility. While we enable RIP debugging on R2, we will see below logs of incompatible version.

R2#debug ip rip
RIP protocol debugging is on

R2#
*May  3 01:29:14.318: RIP: ignored v1 packet from 10.10.12.1 (illegal version)

In order to solve this problem, RIP has provision to run both versions 1 and 2 at same time with multiple routers. We can configure R2 running RIPv1 with R1 and running RIP v2 with R3.  We need to configure R2 with RIPv2 and enable sending and receiving of RIPv1 updates with R1 using interface level commands (on f1/0).

 

R2#show ip protocols
Routing Protocol is "rip"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 14 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Redistributing: rip
  Default version control: send version 2, receive version 2
    Interface               Send  Recv  Triggered RIP  Key-chain
    FastEthernet1/0       1     1                    keyset
    FastEthernet1/1         2     2
    Loopback0                2     2
  Automatic network summarization is not in effect
  Address Summarization:
    172.9.0.0/16 for FastEthernet1/1
  Maximum path: 4
  Routing for Networks:
    10.0.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    10.10.12.1           120      00:00:07
    10.10.23.3           120      00:00:06
    Interface             Send  Recv  Triggered RIP  Key-chain
  Distance: (default is 120)

 

Troubleshooting RIP - Mismatch authentication key (RIP-2)

R1#debug ip rip
RIP protocol debugging is on

*May  3 01:44:17.018: RIP: received packet with MD5 authentication
*May  3 01:44:17.022: RIP: ignored v2 packet from 10.10.12.2 (invalid authentication)

Possible issues could be the following:

• Different key-chain or key-string used between peers. We should use same key-chain names at both end in order to solve authentication problem.
• Missed configuring authentication on one of the peers.
• Different authentication types configured at both ends. For example, plain-text authentication configured on R1's f1/0 and MD5 authentication configured on R2's f1/0 interface.

R1#show run int f1/0
interface FastEthernet1/0
 ip address 10.10.12.1 255.255.255.0
 ip rip authentication mode md5
 ip rip authentication key-chain abc
end

R2#show run int f1/0
interface FastEthernet1/0
 ip address 10.10.12.2 255.255.255.0
 ip rip authentication mode md5
 ip rip authentication key-chain xyz
end

Troubleshooting RIP - Invalid source

 

When RIP is configured on Point to Point links and if one of the source interfaces for example, s1/0 of R1 is configured with "ip unnumbered loopback0" command, RIP communication will fail. This is because 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.

R1#sh run int s1/0
 interface Serial1/0
 ip unnumbered Loopback0
 serial restart-delay 0

Note: You cannot configure an Ethernet interface with ip unnumbered loopback 0 command.

While R2 receives the update packets from R1, it will check the source interface with it's local interface R2's S1/0. R2's S1/0 is configured with 10.10.12.2/24. R1's S1/0 interface is having source IP of loopback0 i.e. 172.9.0.1/32. As source IP of R1's update doesn't match with receiving interface IP of R2, it will reject that update.

R2#debug ip rip
RIP protocol debugging is on

*May  3 20:02:20.071: RIP: ignored v2 update from bad source 172.9.0.1 on Serial  1/0

In order to solve this problem, we should configure R1's S1/0 interface with 10.10.12.0/24 subnet IP, for example, 10.10.12.1/24.

Troubleshooting RIP - Offset-list with a large metric defined

R1#show ip route 172.9.0.2
% Subnet not in table

R1#debug ip rip
*May  3 20:22:32.943: RIP: received v2 update from 10.10.12.2 on Serial1/0
*May  3 20:22:32.947:      172.9.0.2/32 via 0.0.0.0 in 16 hops  (inaccessible)

We are receiving update of 172.9.0/2/32 which is 16hops away and therefore declared inaccessible and its route is not installed in R1's routing table. While we explored R2's RIP config, we found an offset-list configured with max hop count 15 in outgoing direction towards R1. We shouldn't advertise such a high RIP metric to a neighbor.

R2#show run | s router rip
router rip
 version 2
 offset-list 1 out 15
 network 10.0.0.0
 network 172.9.0.0
 no auto-summary

R2#show ip access-lists
Standard IP access list 1
  10 permit 172.9.0.2

Click Here for other useful RIP articles

 

I hope you have found this article informative and useful and now have a fair understanding of Troubleshooting RIP Issues. For any of the related queries or feedback, kindly write to us at networkurge@gmail.com