Troubleshooting RIP

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/0interface FastEthernet1/0 ip address 10.10.12.1 255.255.255.0

ip access-group 100 in

R1#show ip access-lists 100Extended 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 100Extended IP access list 10020 permit ip host 10.10.12.2 host 224.0.0.9R1#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 100Extended IP access list 10020 permit ip host 10.10.12.2 host 255.255.255.255

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 ripRIP protocol debugging is onR2#*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 protocolsRouting 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) R1#debug ip ripRIP 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/0interface FastEthernet1/0 ip address 10.10.12.1 255.255.255.0 ip rip authentication mode md5 ip rip authentication key-chain abcendR2#show run int f1/0interface FastEthernet1/0 ip address 10.10.12.2 255.255.255.0 ip rip authentication mode md5 ip rip authentication key-chain xyz

end

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 ripRIP 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 tableR1#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 riprouter rip version 2 offset-list 1 out 15 network 10.0.0.0 network 172.9.0.0 no auto-summaryR2#show ip access-listsStandard 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 [email protected]