RIP Passive Interface Stopping Route Updates on Right Interface
Presenting Symptom
A router configured with RIP is not advertising a directly connected network to its neighbor, even though the interface is up/up and RIP is enabled.
Network Context
Small branch office with two Cisco routers (R1 and R2) running RIP version 2. R1 has a LAN segment (192.168.1.0/24) connected via GigabitEthernet0/1. R1 and R2 are connected via a serial link (10.0.0.0/30). The engineer notices that R2 does not have the 192.168.1.0/24 route in its routing table. Both routers run IOS 15.x.
Diagnostic Steps
Check R2's routing table for the missing route
show ip route ripR2# show ip route rip
10.0.0.0/30 is subnetted, 1 subnets
R 10.0.0.0 [120/1] via 10.0.0.1, 00:00:12, Serial0/0/0
192.168.1.0/24 is not presentThe 192.168.1.0/24 route is missing from R2's RIP routes. This confirms the route is not being advertised from R1.
Verify RIP configuration on R1
show running-config | section router riprouter rip version 2 network 10.0.0.0 network 192.168.1.0 passive-interface GigabitEthernet0/1
The output shows that GigabitEthernet0/1 is configured as a passive interface under RIP. This prevents RIP updates from being sent out that interface, but it also means the network 192.168.1.0 is not advertised to neighbors via that interface. However, the passive-interface command only affects outgoing updates; the network is still included in updates sent out other interfaces unless the interface is the only one. In this case, the passive-interface command on the LAN interface does not stop the network from being advertised out the serial interface. So the issue might be elsewhere.
Check if the passive-interface is on the wrong interface
show ip protocols | include PassiveR1# show ip protocols | include Passive Passive Interface(s): GigabitEthernet0/1
The passive interface is correctly on the LAN interface (where you don't want to send RIP broadcasts). However, the network 192.168.1.0 should still be advertised out the serial interface. So the passive-interface command is not the root cause. Let's check if the network is actually being advertised.
Debug RIP updates on R1 to see what is being sent
debug ip ripR1# debug ip rip
RIP: sending v2 update to 224.0.0.9 via Serial0/0/0 (10.0.0.1)
RIP: build update entries
10.0.0.0/30 via 0.0.0.0, metric 1, tag 0
192.168.1.0/24 via 0.0.0.0, metric 1, tag 0
RIP: sending v2 update to 224.0.0.9 via GigabitEthernet0/1 (192.168.1.1)
RIP: build update entries
10.0.0.0/30 via 0.0.0.0, metric 1, tag 0
192.168.1.0/24 via 0.0.0.0, metric 1, tag 0The debug output shows that R1 is sending updates out both interfaces, including the 192.168.1.0/24 route. So the route is being advertised. The problem must be on R2. Check if R2 is receiving the update.
Check R2's RIP database
show ip rip databaseR2# show ip rip database 10.0.0.0/30 auto-summary 10.0.0.0/30 directly connected, Serial0/0/0 192.168.1.0/24 auto-summary 192.168.1.0/24 via 10.0.0.1, metric 1, not in routing table
The database shows the route is received (via 10.0.0.1) but it is 'not in routing table'. This indicates a route filtering or administrative distance issue. Check if there is a distribute-list or offset-list.
Check for distribute-list on R2
show running-config | section router riprouter rip version 2 network 10.0.0.0 distribute-list prefix DENY_192 in Serial0/0/0
There is a distribute-list applied inbound on the serial interface that filters routes. This is the root cause: the distribute-list is blocking the 192.168.1.0/24 route from being installed in the routing table.
Root Cause
A distribute-list is configured under RIP on R2, applied inbound on the serial interface, which filters the 192.168.1.0/24 route. The route is received but not installed in the routing table due to the filter.
Resolution
Verification
Verify the route appears in R2's routing table: R2# show ip route rip 10.0.0.0/30 is subnetted, 1 subnets R 10.0.0.0 [120/1] via 10.0.0.1, 00:00:12, Serial0/0/0 R 192.168.1.0/24 [120/1] via 10.0.0.1, 00:00:12, Serial0/0/0 Also verify the distribute-list is removed: R2# show running-config | section router rip No distribute-list lines should appear.
Prevention
1. Use route filtering sparingly and document all distribute-lists. 2. When troubleshooting missing routes, always check both the sending and receiving router's configuration. 3. Use 'show ip rip database' to see if routes are received but not installed.
CCNA Exam Relevance
On the CCNA 200-301 exam, this scenario tests understanding of RIP route advertisement and filtering. Questions may present a scenario where a route is missing and ask to identify the cause (e.g., passive-interface on wrong interface, distribute-list, or network statement missing). The key fact is that a distribute-list applied inbound can prevent a route from being installed even if it is received.
Exam Tips
Remember that 'passive-interface' only stops sending updates, not receiving. It does not prevent the network from being advertised out other interfaces.
Use 'show ip rip database' to see if a route is received but not in the routing table; this points to filtering or administrative distance issues.
Distribute-lists can be applied in or out; inbound filters affect route installation, outbound filters affect what is sent.
Commands Used in This Scenario
debug ip rip
Enables real-time debugging of RIP routing updates to troubleshoot routing issues by displaying sent and received RIP updates.
show ip protocols
Displays the current state of all IP routing protocols running on the router, including timers, filters, and network advertisements.
show ip route
Displays the current IP routing table on a Cisco router, used to verify routes, check next-hop addresses, and troubleshoot connectivity issues.
Test Your CCNA Knowledge
Practice with scenario-based questions to prepare for the CCNA 200-301 exam.
Practice CCNA Questions