debug ip routing
Use debug ip routing to monitor real-time IP routing table updates and routing protocol events, helping troubleshoot route installation or removal issues.
Definition: debug ip routing is a Cisco IOS privileged exec command. Use debug ip routing to monitor real-time IP routing table updates and routing protocol events, helping troubleshoot route installation or removal issues.
Overview
The `debug ip routing` command is a powerful diagnostic tool used in Cisco IOS to monitor real-time IP routing table updates and routing protocol events. It provides a live stream of information about route additions, removals, and modifications, as well as the internal decision-making process of the routing information base (RIB). This command is essential for network engineers troubleshooting routing issues, such as missing routes, incorrect next hops, or unexpected routing behavior.
By enabling this debug, you can observe how routes are installed or removed, which can help identify problems with routing protocol configurations, route redistribution, or static route definitions. The command operates at the privileged EXEC level (enable mode) and does not affect the running configuration; it only impacts the router's CPU by generating debug messages. It is important to note that debug output is sent to the console by default and can be buffered or logged to a syslog server.
Due to the high volume of output in a live network, this command should be used with caution and typically in a controlled maintenance window. Alternatives include using `show ip route` for a static snapshot or `debug ip ospf events` for protocol-specific debugging. The `debug ip routing` command fits into the broader troubleshooting workflow as a first step when dynamic routing is not behaving as expected, often used after verifying interface status and basic connectivity.
It is particularly useful for understanding the interaction between multiple routing protocols or when troubleshooting route redistribution issues. The command's output includes timestamps, route source (e.g., connected, static, OSPF, EIGRP), metric, administrative distance, and next-hop information. A key behavior is that the debug output is not stored in the running configuration and is disabled upon reload.
To avoid overwhelming the console, it is recommended to use `logging buffered` and `terminal monitor` for remote sessions. The command requires privilege level 15 or equivalent access. Understanding the output of `debug ip routing` is crucial for CCNA and CCNP candidates as it provides deep insight into the routing process, helping to bridge the gap between theory and real-world troubleshooting.
debug ip routingWhen to Use This Command
- Troubleshooting why a route is not being installed in the routing table after configuring a static route or dynamic routing protocol.
- Monitoring route flapping caused by unstable links or misconfigured routing protocols.
- Verifying the sequence of events when a new route is learned via OSPF or EIGRP and added to the routing table.
- Diagnosing why a specific route is being removed unexpectedly, such as due to a higher administrative distance or route poisoning.
Command Examples
Monitoring a new static route installation
debug ip routingRT: add 192.168.2.0/24 via 10.0.0.2, static metric [1/0] RT: closer admin distance for 192.168.2.0, adding %SYS-5-CONFIG_I: Configured from console by console RT: NET-RED 192.168.2.0/24 via 10.0.0.2, static metric [1/0] RT: add 192.168.2.0/24 via 10.0.0.2, static metric [1/0]
Line 1: RT indicates routing table update; 'add' means route being added; 'via 10.0.0.2' is next-hop; 'static' is protocol; '[1/0]' is administrative distance/metric. Line 2: 'closer admin distance' means this route is preferred over existing. Line 3: syslog confirming config change. Line 4: 'NET-RED' indicates redistribution event. Line 5: repeated add confirms installation.
Observing route removal due to interface down
debug ip routingRT: del 192.168.1.0/24 via 10.0.0.1, connected metric [0/0] RT: interface GigabitEthernet0/0 changed state to down %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to down RT: del 192.168.1.0/24 via 10.0.0.1, connected metric [0/0]
Line 1: 'del' indicates route deletion; 'connected' means directly connected route; '[0/0]' is AD/metric. Line 2: RT message about interface state change. Line 3: syslog confirming line protocol down. Line 4: repeated deletion confirms removal.
Understanding the Output
The debug ip routing output displays real-time routing table changes. Each line starts with 'RT:' indicating a routing table event. 'add' means a route is being inserted, 'del' means removal.
The route prefix and subnet mask are shown (e.g., 192.168.2.0/24). 'via' indicates the next-hop IP address. The protocol source (e.g., static, connected, ospf, eigrp) is listed.
The metric is shown in brackets: [administrative distance/metric]. For example, [1/0] means AD=1, metric=0. 'closer admin distance' messages indicate route selection when multiple sources exist.
'NET-RED' indicates redistribution. Interface state changes are also logged. Good output shows expected adds/dels; bad output includes unexpected flapping or incorrect routes.
Watch for 'del' without corresponding 'add' if routes disappear unexpectedly.
Configuration Scenarios
Troubleshooting missing OSPF routes between two routers
Two routers are configured with OSPF but routes are not being exchanged. The goal is to use debug ip routing to observe if OSPF routes are being installed in the routing table and identify any issues with route advertisement.
Topology
R1(Gi0/0)---10.0.12.0/30---(Gi0/0)R2
R1 Lo0: 192.168.1.1/24
R2 Lo0: 192.168.2.1/24Steps
- 1.Step 1: Enter privileged EXEC mode on R1: enable
- 2.Step 2: Enable debug ip routing: debug ip routing
- 3.Step 3: On R2, ensure OSPF is configured and advertising its loopback: router ospf 1, network 192.168.2.0 0.0.0.255 area 0
- 4.Step 4: Observe the debug output on R1 for route installation messages
- 5.Step 5: If no routes appear, check OSPF neighbor state with show ip ospf neighbor
- 6.Step 6: Disable debugging: undebug all
! R1 OSPF configuration router ospf 1 network 10.0.12.0 0.0.0.3 area 0 network 192.168.1.0 0.0.0.255 area 0 ! R2 OSPF configuration router ospf 1 network 10.0.12.0 0.0.0.3 area 0 network 192.168.2.0 0.0.0.255 area 0
Verify: On R1, use show ip route ospf to see if 192.168.2.0/24 is present. Expected output includes an OSPF route with next-hop 10.0.12.2.
Watch out: Ensure OSPF network statements match the interface IP addresses; a common mistake is using the wrong wildcard mask or forgetting to include the interface subnet.
Debugging route redistribution from EIGRP to OSPF
A router is redistributing EIGRP routes into OSPF, but some routes are not appearing in the OSPF domain. Debug ip routing helps verify if the redistributed routes are being installed in the routing table and then advertised.
Topology
R1(Gi0/0)---10.0.12.0/30---(Gi0/0)R2
R1 Gi0/1: 172.16.1.0/24 (EIGRP domain)
R2 Lo0: 192.168.2.1/24 (OSPF domain)Steps
- 1.Step 1: Enter privileged EXEC mode on R1: enable
- 2.Step 2: Enable debug ip routing: debug ip routing
- 3.Step 3: On R1, configure redistribution from EIGRP into OSPF: router ospf 1, redistribute eigrp 100 subnets
- 4.Step 4: Observe debug output for route installation of redistributed routes
- 5.Step 5: Check if the redistributed routes appear in the OSPF database on R2: show ip ospf database
- 6.Step 6: Disable debugging: undebug all
! R1 configuration router eigrp 100 network 172.16.1.0 0.0.0.255 router ospf 1 network 10.0.12.0 0.0.0.3 area 0 redistribute eigrp 100 subnets ! R2 OSPF configuration router ospf 1 network 10.0.12.0 0.0.0.3 area 0 network 192.168.2.0 0.0.0.255 area 0
Verify: On R2, use show ip route ospf to see if 172.16.1.0/24 is present. Expected output includes an OSPF external route (O E2) with next-hop 10.0.12.1.
Watch out: A common mistake is forgetting the 'subnets' keyword in the redistribute command, which causes only classful routes to be redistributed, missing subnets like /24.
Troubleshooting with This Command
When using `debug ip routing` for troubleshooting, it is important to understand what healthy output looks like versus problem indicators. Healthy output typically shows routes being installed with correct next hops and metrics, such as 'RT: add 192.168.1.0/24 via 10.0.12.2, ospf metric 110'. Problem indicators include messages like 'RT: route 192.168.1.0/24 not installed because of administrative distance conflict' or 'RT: route 192.168.1.0/24 not installed because of metric'.
Key fields to focus on are the route source (e.g., connected, static, ospf, eigrp), administrative distance, metric, and next-hop IP. Common symptoms that this command helps diagnose include missing routes, where the debug may show that the route was received but not installed due to a higher administrative distance from another protocol, or incorrect next hops due to a misconfigured static route. A step-by-step diagnostic flow would be: 1) Enable debug ip routing on the router experiencing the issue. 2) Reproduce the problem (e.g., clear routing table or trigger a route update). 3) Observe the debug output for any 'not installed' messages. 4) Check the administrative distance of the competing route using `show ip route` for the specific prefix. 5) Verify routing protocol configurations and redistribution filters. 6) Correlate with other debug commands like `debug ip ospf events` or `debug eigrp packets` to see if the route is being advertised at the protocol level.
For example, if OSPF is not installing a route, `debug ip ospf events` might show that the LSA was not received. The output of `debug ip routing` can also be correlated with `show ip route` to confirm the current state. It is crucial to use `logging buffered` to capture the output for later analysis, especially in production environments.
Remember that debug commands are CPU-intensive and should be used sparingly; always disable debugging after troubleshooting.
CCNA Exam Tips
CCNA exam tip: debug ip routing is a privileged EXEC command; you must be in enable mode.
CCNA exam tip: Always use 'undebug all' or 'no debug ip routing' to stop debugging; leaving it on can overwhelm the router CPU.
CCNA exam tip: The output shows administrative distance in brackets; remember that lower AD is preferred (e.g., static AD 1 vs. OSPF AD 110).
CCNA exam tip: You may be asked to interpret debug output to determine why a route is not being installed (e.g., higher AD or missing next-hop).
Common Mistakes
Mistake 1: Forgetting to disable debug after troubleshooting, causing high CPU usage and potential router crash.
Mistake 2: Misinterpreting 'add' and 'del' messages; thinking a route is being added when it's actually being deleted (check for 'del' keyword).
Mistake 3: Assuming debug output shows all routing updates; it only shows changes, not the full routing table.
debug ip routing vs undebug all
Although debug ip routing and undebug all serve opposite purposes, they are often considered together because one enables a specific debug and the other disables all debugs. Understanding their distinct scopes and effects is crucial for efficient troubleshooting without overwhelming the router's CPU.
| Aspect | debug ip routing | undebug all |
|---|---|---|
| Scope | Enables debugging for IP routing events only | Disables all active debug operations globally |
| Effect | Increases CPU load by generating routing update logs | Stops all debug output, reducing CPU load |
| Risk | High CPU overhead in production; can cause packet loss | None; safe to use at any time |
| Precedence | Overridden by 'undebug all' or 'no debug ip routing' | Overrides any active debug command |
| Persistence | Not persistent across reloads; lost on reboot | Immediate effect; no persistent state |
| Typical Use | Troubleshoot route flapping or missing routes | Emergency stop when debug output floods console |
Use debug ip routing when you need to observe real-time IP routing updates to diagnose route installation or removal issues.
Use undebug all when you need to immediately stop all debugging activity to prevent CPU overload or console flooding.
Platform Notes
In IOS-XE (e.g., Catalyst 9000 switches), the `debug ip routing` command syntax and output are largely identical to classic IOS. However, on some IOS-XE platforms, the debug output may be rate-limited or require the `platform debug` command for full detail. On NX-OS (e.g., Nexus switches), the equivalent command is `debug ip routing` as well, but the output format differs slightly; NX-OS uses a more structured format with timestamps and event IDs.
For ASA firewalls, there is no direct equivalent; routing debugging is done via `debug ospf` or `debug eigrp` commands specific to the routing protocol. In IOS-XR (e.g., ASR 9000), the command is `debug ip routing` but the output is more verbose and includes process IDs. There are no significant differences between IOS 12.x, 15.x, and 16.x for this command, though newer versions may include additional fields like route tag or origin.
Always check the specific platform documentation for any syntax variations.
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