Back to RIP Guide RIP troubleshooting

Master Guide: Troubleshooting RIP Like a Network Engineer

RIP does not form strict neighbor adjacencies like OSPF or EIGRP. It simply broadcasts or multicasts routing updates and expects the other side to listen. Because of that, RIP failures usually show up as one simple symptom: missing routes in the routing table.

show ip protocols debug ip rip Missing Routes Passive Interface Metric 16

Master Guide: Troubleshooting RIP Like a Network: Quick Summary

To troubleshoot RIP well, start with show ip protocols, confirm the correct network statements and version settings, then verify local route candidates with show ip rip database. If routes are still missing, use debug ip rip to inspect live updates, metrics, and route poisoning behavior.

First command show ip protocols
Database check show ip rip database
Live packet view debug ip rip
Dead metric 16 hops

Master Guide: Troubleshooting RIP Like a Network: Table of Contents

  1. Scenario 1: Missing or Incorrect Network Command
  2. Scenario 2: Interface Status Issue
  3. Scenario 3: Passive Interface Trap
  4. Scenario 4: Version Mismatch
  5. Scenario 5: Hop Count Limit
  6. Scenario 6: Authentication Failure
  7. Scenario 7: Route Filtering
  8. Scenario 8: Split Horizon in Hub-and-Spoke
  9. Scenario 9: Auto-Summarization and Discontiguous Networks

Scenario 1: The Missing or Incorrect Network Command

The Topology

  • R1 and R2 are directly connected through 192.168.12.0/24.
  • R2 has a local network, 2.2.2.0/24, that it needs to advertise to R1.

The Problem

R1's routing table is empty. It is not learning 2.2.2.0/24 from R2.

The Investigation

The best place to start is show ip protocols.

R1 - Incorrect RIP Network

R1# show ip protocols
  Routing for Networks:
    192.168.21.0

R2 - Correct RIP Networks

R2# show ip protocols
  Routing for Networks:
    2.0.0.0
    192.168.12.0

The Fix

R2 is advertising correctly, but R1 has a typo. It is configured for 192.168.21.0 instead of 192.168.12.0. Because the connected link is not enabled under RIP, R1 refuses to process updates on that interface.

R1 - Correct the Network Statement

R1(config)# router rip
R1(config-router)# no network 192.168.21.0
R1(config-router)# network 192.168.12.0
Lesson learned: RIP only listens to and talks out of interfaces matched by the network command. Always check for typos.

Scenario 2: The Interface Status Issue

The Topology

  • R1 and R2 are connected through 192.168.12.0/24.
  • R2 has Loopback0 configured as 2.2.2.2/24 to simulate a LAN.

The Problem

R1 still does not see the 2.2.2.0/24 route. Both routers have the correct RIP network commands.

The Investigation

If the network statements are correct, check whether R2 has placed the route in its own RIP database.

R2 - RIP Database Missing Loopback Network

R2# show ip rip database
192.168.12.0/24    auto-summary
192.168.12.0/24    directly connected, FastEthernet0/0

The 2.0.0.0 network is missing from R2's database, so the next check is interface state.

R2 - Loopback Interface Status

R2# show ip interface brief | include Loopback0
Loopback0            2.2.2.2         YES manual administratively down down

The Fix

RIP will not advertise a network attached to a down physical or logical interface.

R2 - Enable Loopback0

R2(config)# interface loopback 0
R2(config-if)# no shutdown
Lesson learned: If a route is missing from the local show ip rip database, check Layer 1 and Layer 2. The interface must be up/up.

Scenario 3: The Passive Interface Trap

The Topology

  • R1 and R2 are connected on FastEthernet0/0.
  • R2 should share its internal 2.0.0.0 network with R1.

The Problem

R1 has an empty routing table. Interfaces are up/up, and the network commands are correct.

The Investigation

Check R2 for interface restrictions.

R2 - Passive Interface Found

R2# show ip protocols
  Routing for Networks:
    2.0.0.0
    192.168.12.0
  Passive Interface(s):
    FastEthernet0/0

The Fix

FastEthernet0/0 is passive, so R2 listens but refuses to send updates out toward R1.

R2 - Remove Passive Interface

R2(config)# router rip
R2(config-router)# no passive-interface FastEthernet 0/0
Lesson learned: Passive interfaces are useful on user-facing LANs, but they break dynamic routing if applied to router-to-router links.

Scenario 4: The Version Mismatch

The Topology

R1 and R2 are connected through a point-to-point link.

The Problem

R1 is not receiving routes. Interfaces are up, no passive interfaces exist, and the network commands are correct.

The Investigation

Check version control in show ip protocols.

R1 - RIPv1 Only

Default version control: send version 1, receive version 1

R2 - RIPv2 Only

Default version control: send version 2, receive version 2

The Fix

R1 is speaking classful broadcast RIPv1, while R2 is speaking classless multicast RIPv2. Standardize the domain on RIPv2.

R1 - Enable RIPv2

R1(config)# router rip
R1(config-router)# version 2
Lesson learned: Always enforce version 2 globally on all routers in the RIP domain.

Scenario 5: The Hop Count Limit (Infinity)

The Topology

R1 and R2 are directly connected. An administrator has applied an artificial metric offset to R2's outgoing routes to simulate a large network.

The Problem

R1 receives updates from R2, but the routes never appear in show ip route.

The Investigation

When updates arrive but routes do not install, use debug ip rip.

R1 - RIP Debug Shows Inaccessible Route

R1# debug ip rip
RIP: received v2 update from 192.168.12.2 on FastEthernet0/0
     2.2.2.0/24 via 0.0.0.0 in 16 hops  (inaccessible)

The Fix

RIP supports a maximum usable hop count of 15. A metric of 16 means infinity, so R1 discards the route. In small labs, this is often caused by an incorrect offset list.

R2 - Remove the Bad Offset List

R2(config)# router rip
R2(config-router)# no offset-list 0 out 15
Lesson learned: If the hop count reaches 16, the route is dead. Check for metric manipulation with offset lists.

Scenario 6: Authentication Failure

The Topology

R1 and R2 are connected. The enterprise requires secure routing updates to prevent rogue routers from joining the RIP domain.

The Problem

R1 is not installing routes.

The Investigation

Turn on debugging on R1 to see what happens when a RIP packet arrives from R2.

R1 - Invalid Authentication Debug

R1# debug ip rip
RIP: ignored v2 packet from 192.168.12.2 (invalid authentication)

The Fix

Authentication is applied at the interface level, not under the router rip process. On R1, show run interface FastEthernet 0/0 shows MD5 authentication enabled with a key chain, but R2 has no matching authentication configured.

To quickly restore connectivity, remove the strict security requirement from R1. In production, the better fix is to configure the matching key chain, key ID, and key string on R2.

R1 - Remove RIP Authentication

R1(config)# interface FastEthernet 0/0
R1(config-if)# no ip rip authentication mode md5
R1(config-if)# no ip rip authentication key-chain MY_CHAIN
Lesson learned: RIPv2 cryptographic authentication must be mirrored on both routers, including the key string and key ID.

Scenario 7: Route Filtering (Access Lists)

The Topology

R1 and R2 are connected. An administrator previously tried to restrict routing behavior using Access Control Lists (ACLs).

The Problem

R1's routing table is empty. RIP versions, passwords, and interfaces all match correctly.

The Investigation

Check the routing protocol output on R1 for filtering rules.

R1 - Incoming Filter Found

R1# show ip protocols
  Incoming update filter list for all interfaces is not set
    FastEthernet0/0 filtered by 1 (per-user), default is not set

Then inspect Access List 1.

R1 - ACL Denying RIP Routes

R1# show access-lists 1
Standard IP access list 1
    10 deny   any (10 matches)

The Fix

A distribute-list is tying ACL 1 to the RIP process and filtering incoming routing updates. Modify the ACL to permit the 2.2.2.0/24 network.

R1 - Permit the Missing Network

R1(config)# ip access-list standard 1
R1(config-std-nacl)# 1 permit 2.2.2.0 0.0.0.255
Lesson learned: Distribute-list filters are silent routing killers. Always check whether an ACL is blocking the subnet before it enters the routing table.

Scenario 8: Split Horizon in a Hub-and-Spoke

The Topology

A central hub router connects to Spoke 1, which owns network 2.0.0.0, and Spoke 2, which owns network 3.0.0.0. The topology uses one physical serial interface with a multi-access technology such as Frame Relay.

The Problem

The hub router sees both spoke networks. However, Spoke 1 cannot see Spoke 2's network, and Spoke 2 cannot see Spoke 1's network.

The Investigation

Check the hub router's interface configuration.

Hub - Split Horizon Enabled

Hub# show ip interface Serial 1/0 | include Split
  Split horizon is enabled

The Fix

Split horizon is a loop-prevention rule that says: never advertise a route back out the same interface it was learned on. Because the hub learns Spoke 1's network through Serial 1/0, it refuses to send that route back out Serial 1/0 to Spoke 2.

In a hub-and-spoke topology sharing a single physical interface, disable split horizon on the hub's main interface.

Hub - Disable Split Horizon

Hub(config)# interface Serial 1/0
Hub(config-if)# no ip split-horizon
Lesson learned: Split horizon can break point-to-multipoint hub-and-spoke designs. Disable it carefully on the hub interface when the topology requires route reflection between spokes.

Scenario 9: Auto-Summarization and Discontiguous Networks

The Topology

  • R1 connects to R2, and R2 connects to R3.
  • R1 hosts 172.16.1.0/24.
  • R3 hosts 172.16.3.0/24.
  • The two 172.16.x.x networks are separated by 192.168.x.x transit networks, creating a discontiguous network.

The Problem

R2's routing table load-balances traffic to 172.16.0.0/16 through both sides, causing some packets to be dropped or sent to the wrong router.

R2 - Bad Summary Routes

R2# show ip route rip
R    172.16.0.0/16 [120/1] via 192.168.23.3
                   [120/1] via 192.168.12.1

The Investigation

When RIPv2 has auto-summary enabled, it behaves like RIPv1 at classful network boundaries. R1 and R3 advertise their /24 subnets across a 192.168 boundary, and the routers summarize them into the larger classful 172.16.0.0/16 network.

R2 receives 172.16.0.0/16 from both directions and assumes it has two equal paths to the same destination.

The Fix

Disable legacy summarization on the edge routers.

R1 and R3 - Disable Auto Summary

R1(config)# router rip
R1(config-router)# no auto-summary

R3(config)# router rip
R3(config-router)# no auto-summary

After this change, R2 learns the specific and separate /24 routes correctly.

Lesson learned: Auto-summary creates routing black holes in modern subnetted networks. Always turn it off.