Courseiva
DebugPrivileged EXEC

debug ip rip

Enables real-time debugging of RIP routing updates to troubleshoot routing issues by displaying sent and received RIP updates.

Definition: debug ip rip is a Cisco IOS privileged exec command. Enables real-time debugging of RIP routing updates to troubleshoot routing issues by displaying sent and received RIP updates.

Overview

The `debug ip rip` command is a powerful diagnostic tool used in Cisco IOS to enable real-time debugging of Routing Information Protocol (RIP) updates. RIP is a distance-vector routing protocol that uses hop count as its metric to determine the best path to a destination network. It is commonly used in smaller networks due to its simplicity and ease of configuration.

The command is essential for network engineers troubleshooting RIP-related issues such as missing routes, routing loops, or incorrect metric calculations. By enabling this debug, the router displays all sent and received RIP updates, including the source and destination IP addresses, the networks being advertised, and the metric (hop count) associated with each route. This real-time output helps engineers verify that RIP updates are being exchanged correctly between neighbors and that the routing tables are being populated as expected.

The command is typically used when there is a discrepancy between expected and actual routing behavior, such as when a network is not reachable despite proper configuration. Alternatives include using `show ip rip database` or `show ip route rip` to view the current RIP state, but these provide static snapshots rather than dynamic update information. The `debug ip rip` command fits into the broader troubleshooting workflow after verifying basic connectivity and RIP configuration.

It is often used in conjunction with `debug ip packet` or `debug ip routing` to correlate RIP updates with packet forwarding decisions. Important IOS behaviors to note: debug output is sent to the console by default and can be overwhelming in production networks; it is recommended to use `logging buffered` to capture output for later analysis. The command requires privileged EXEC mode (enable mode) and does not affect the running configuration.

However, it can impact router performance due to the CPU overhead of generating debug messages, especially in networks with frequent updates. Therefore, it should be used with caution and disabled immediately after troubleshooting using `undebug all` or `no debug ip rip`. The command is available in all IOS versions and is a staple for CCNA and CCNP candidates learning RIP troubleshooting.

Syntax·Privileged EXEC
debug ip rip

When to Use This Command

  • Diagnosing why a RIP route is not being learned on a router
  • Verifying that RIP updates are being sent and received correctly after configuration changes
  • Troubleshooting RIP version mismatches or authentication failures
  • Monitoring RIP updates during network convergence after a link failure

Command Examples

Basic RIP debug output

debug ip rip
RIP: sending v2 update to 224.0.0.9 via GigabitEthernet0/0 (192.168.1.1)
RIP: build update entries
      10.0.0.0/8 via 0.0.0.0, metric 1, tag 0
      172.16.0.0/16 via 0.0.0.0, metric 2, tag 0
RIP: received v2 update from 192.168.1.2 on GigabitEthernet0/0
      192.168.2.0/24 via 0.0.0.0 in 2 hops
      10.0.0.0/8 via 0.0.0.0 in 3 hops

Line 1: Router sends RIP v2 update to multicast address 224.0.0.9 out of interface G0/0 with source IP 192.168.1.1. Line 2: Indicates building update entries. Lines 3-4: Routes being advertised: 10.0.0.0/8 with metric 1, 172.16.0.0/16 with metric 2. Line 5: Router receives a RIP v2 update from neighbor 192.168.1.2 on G0/0. Lines 6-7: Received routes: 192.168.2.0/24 with hop count 2, 10.0.0.0/8 with hop count 3.

RIP debug with triggered updates

debug ip rip events
RIP: sending v2 update to 224.0.0.9 via GigabitEthernet0/0 (192.168.1.1)
RIP: Update contains 2 routes
RIP: Update queued
RIP: Update sent via GigabitEthernet0/0
RIP: received v2 update from 192.168.1.2 on GigabitEthernet0/0
RIP: Update contains 1 routes
RIP: Update processed

Line 1: Router sends RIP update. Line 2: The update includes 2 routes. Line 3: Update is queued for transmission. Line 4: Update sent successfully. Line 5: Router receives an update from neighbor. Line 6: Received update contains 1 route. Line 7: Update has been processed and routing table updated.

Understanding the Output

The debug ip rip command outputs real-time messages for each RIP update sent or received. Each line begins with 'RIP:' to indicate the protocol. For sent updates, it shows the interface, source IP, and the routes being advertised with their metrics and tags.

For received updates, it shows the neighbor IP, interface, and the routes learned with hop counts. The metric (hop count) is critical: a metric of 16 means the route is unreachable. In a stable network, you should see periodic updates every 30 seconds.

If updates are missing or contain unexpected routes, it indicates a problem. Watch for 'RIP: ignored v2 update from ...' which may indicate authentication failure or version mismatch. The output can be verbose; use 'undebug all' to stop debugging.

Configuration Scenarios

Troubleshoot missing RIP routes between two routers

R1 and R2 are directly connected via a serial link and both are configured with RIP version 2. However, R2 cannot ping the loopback interface on R1 (192.168.1.1/24). The goal is to verify that RIP updates are being sent and received correctly.

Topology

R1(Lo0:192.168.1.1/24)---(Gi0/0:10.0.12.1/30)---(Gi0/0:10.0.12.2/30)R2

Steps

  1. 1.Step 1: On R1, enter privileged EXEC mode: enable
  2. 2.Step 2: Enable RIP debugging: debug ip rip
  3. 3.Step 3: Observe the output for RIP updates being sent and received.
  4. 4.Step 4: On R2, also enable debug ip rip to see if updates are received.
  5. 5.Step 5: Check if R2's routing table includes the 192.168.1.0/24 network: show ip route rip
Configuration
! On R1
interface Loopback0
 ip address 192.168.1.1 255.255.255.0
!
interface GigabitEthernet0/0
 ip address 10.0.12.1 255.255.255.252
!
router rip
 version 2
 network 10.0.0.0
 network 192.168.1.0
!
! On R2
interface GigabitEthernet0/0
 ip address 10.0.12.2 255.255.255.252
!
router rip
 version 2
 network 10.0.0.0

Verify: On R2, use 'show ip route rip' to verify that the route to 192.168.1.0/24 appears with a next-hop of 10.0.12.1. Also, 'show ip rip database' should show the route.

Watch out: A common mistake is forgetting to include the network statement for the loopback interface under the RIP process. Without 'network 192.168.1.0', R1 will not advertise that network.

Identify RIP routing loop caused by passive interface misconfiguration

In a network with three routers (R1, R2, R3) running RIP, a routing loop is suspected because pings to a remote network are intermittent. The debug will help identify if updates are being sent out interfaces that should be passive.

Topology

R1(Gi0/0)---10.0.12.0/30---(Gi0/0)R2(Gi0/1)---10.0.23.0/30---(Gi0/0)R3 R3(Lo0:172.16.1.1/24)

Steps

  1. 1.Step 1: On R2, enable debug ip rip to see updates.
  2. 2.Step 2: Observe if R2 is sending RIP updates out interface Gi0/1 towards R3, which should be passive if R3 is a stub.
  3. 3.Step 3: Check the routing tables on all routers for inconsistencies.
  4. 4.Step 4: Verify passive-interface configuration on R2 for Gi0/1 if intended.
Configuration
! On R2
interface GigabitEthernet0/0
 ip address 10.0.12.2 255.255.255.252
!
interface GigabitEthernet0/1
 ip address 10.0.23.2 255.255.255.252
!
router rip
 version 2
 network 10.0.0.0
 passive-interface GigabitEthernet0/1
!

Verify: Use 'show ip route rip' on R2 to see if it has a route to 172.16.1.0/24. Also, 'show ip protocols' to verify passive interface status.

Watch out: A common mistake is applying 'passive-interface default' without then using 'no passive-interface' on the interfaces that should send updates. This can cause all interfaces to stop sending RIP updates, breaking routing.

Troubleshooting with This Command

When using `debug ip rip` for troubleshooting, the first step is to enable the debug on the router experiencing the issue. The output will show lines like: `RIP: sending v2 update to 224.0.0.9 via GigabitEthernet0/0 (10.0.12.1)` and `RIP: received v2 update from 10.0.12.2 on GigabitEthernet0/0`. Healthy output should show regular updates (every 30 seconds by default) with correct network prefixes and metrics.

Problem indicators include: no updates being sent or received, updates with incorrect metrics (e.g., metric 16 indicating unreachable), updates from unexpected sources, or updates that are missing expected networks. Focus on the source IP address to ensure it matches the configured neighbor; if updates are received from an unexpected IP, it may indicate a misconfiguration or a rogue router. Also, check the metric field: a metric of 16 means the route is poisoned (unreachable).

Common symptoms this command helps diagnose include: missing routes (no update received for a network), routing loops (updates bouncing between routers with increasing metrics), and slow convergence (updates delayed or not sent). A step-by-step diagnostic flow: 1) Enable `debug ip rip` on the router that should be receiving the route. 2) Wait for a few update cycles (30 seconds each). 3) Observe if the expected network appears in the output. 4) If not, check the sending router's debug output to see if it is advertising the network. 5) Verify that the sending router has the network in its RIP database (`show ip rip database`). 6) Check for access lists or distribute lists that might be filtering updates. 7) Ensure that the receiving router's interface is not configured as passive. Correlate `debug ip rip` output with `show ip route` to see if the route is installed, and with `debug ip routing` to see if the route is being added or removed.

Also, use `show ip protocols` to verify RIP timers and neighbor relationships. Remember to disable debugging with `undebug all` after troubleshooting to avoid performance impact.

CCNA Exam Tips

1.

CCNA exam tip: Remember that 'debug ip rip' can cause high CPU load on production routers; always use with caution and disable with 'undebug all'.

2.

CCNA exam tip: The exam may ask you to interpret debug output to identify why a route is not being learned (e.g., metric 16, wrong interface, or access-list blocking).

3.

CCNA exam tip: Know that RIP updates are sent every 30 seconds; if you don't see updates, check network connectivity or passive-interface configuration.

4.

CCNA exam tip: Be aware that 'debug ip rip events' provides a less detailed but more CPU-friendly view compared to 'debug ip rip'.

Common Mistakes

Mistake 1: Leaving debug enabled after troubleshooting, causing performance degradation. Always use 'undebug all' or 'no debug ip rip'.

Mistake 2: Misinterpreting metric 16 as a valid route instead of unreachable. Metric 16 means the route is poisoned.

Mistake 3: Forgetting that RIP updates are sent to multicast 224.0.0.9; if multicast is blocked, updates won't be received.

debug ip rip vs undebug all

These two commands are commonly paired because debugging RIP involves enabling it with 'debug ip rip' and then disabling it with 'undebug all' once troubleshooting is complete. They are often confused by new engineers who may not realize that 'undebug all' stops all active debugs, not just RIP.

Aspectdebug ip ripundebug all
ScopeRIP-specific debuggingAll active debug commands
EffectEnables real-time RIP update outputDisables all running debug output
CPU ImpactIncreases CPU load with RIP trafficReduces CPU load by halting all debugging
PersistenceNot saved to running-configNot saved to running-config
PrecedenceCan be overridden by undebug allOverrides all individual debug commands
Typical UseTroubleshooting RIP routing issuesStopping all debugging after troubleshooting

Use debug ip rip when you need to monitor RIP updates in real-time to diagnose routing problems.

Use undebug all when you want to quickly stop all debugging output and reduce CPU utilization.

Platform Notes

In IOS-XE (e.g., Catalyst 9000 switches), the `debug ip rip` command syntax and output are identical to classic IOS. However, on some IOS-XE platforms, debug output may be rate-limited or directed to a specific log file if configured. The NX-OS equivalent is `debug rip` (without the `ip` keyword) on Nexus switches.

For example, `debug rip events` or `debug rip packets` provide similar functionality. On ASA firewalls, RIP debugging is done via `debug rip` as well, but the ASA uses a different codebase and the output format differs slightly. In IOS-XR, RIP is not supported as a routing protocol; instead, OSPF or IS-IS are used.

Therefore, `debug ip rip` does not exist in IOS-XR. Between IOS versions (12.x, 15.x, 16.x), the command behavior is consistent, but the verbosity of output may vary slightly. For instance, IOS 12.x might show more detailed packet dumps, while later versions may summarize.

Always check the specific platform documentation for any nuances.

Related Commands

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 IP routing table showing all known routes, their source protocols, administrative distances, metrics, next-hops, and outgoing interfaces.

undebug all

Disables all active debug operations on the router, used to stop debugging output and reduce CPU load.

Practice for the CCNA 200-301

Test your knowledge with practice questions covering all CCNA 200-301 exam domains.

Practice CCNA 200-301 Questions