Debug commands are the network engineer's scalpel — precise, powerful, and dangerous if mishandled. On the CCNA 200-301 exam, you won't be asked to memorize every debug command, but you must understand when to use them, how to interpret their output, and most critically, how to avoid crashing a production router. This chapter covers the essential IOS debug commands, their best practices, and the exam traps that separate certified engineers from the rest.
Jump to a section
Imagine you're a mechanic diagnosing a car that stalls at intersections. You could randomly replace parts (like blindly changing configurations), but that's expensive and slow. Instead, you plug a scan tool into the OBD-II port under the dashboard. This tool gives you real-time data: engine RPM, fuel mixture, spark timing, and sensor readings — all without disassembling the engine. Similarly, IOS debug commands let you watch packets flow, routing updates exchange, and error messages appear in real time, without stopping the router's operation. However, just as a scan tool can drain the car's battery if left connected while the engine is off, debug commands consume CPU cycles. On a busy router, turning on 'debug ip packet' without an access list is like recording every sensor on a car simultaneously — the scan tool (CPU) becomes overwhelmed, and the car's performance degrades. The mechanic must use the tool selectively: filter by specific conditions (e.g., only watch the oxygen sensor voltage). In IOS, you filter debug output using 'debug ip packet 100' where access list 100 defines the traffic of interest. Both tools share the same principle: real-time monitoring is invaluable for pinpointing intermittent issues, but misuse can cause more harm than good. The mechanic also knows to disconnect the scan tool after the test; likewise, you must disable debug commands with 'undebug all' as soon as you've gathered enough data.
What Are Debug Commands?
Debug commands in Cisco IOS provide real-time, granular visibility into the inner workings of protocols and processes. Unlike 'show' commands, which take a snapshot of the current state, debug commands generate a continuous stream of messages as events occur. This makes them indispensable for troubleshooting transient issues, such as routing flaps, authentication failures, or packet drops, that might not appear in static show outputs.
Why They Are Dangerous
Debug commands run at the process level, consuming CPU cycles. On a router handling thousands of packets per second, enabling 'debug ip packet' without filters can cause the CPU to spike to 100%, crashing the router or causing it to drop routing protocol keepalives. Cisco IOS prioritizes debugging output over packet forwarding on some platforms, leading to catastrophic failures in production. The CCNA exam emphasizes this danger: you must always use access lists to filter debug output and never leave debug enabled on a production device.
Common Debug Commands on the CCNA
The exam focuses on a handful of debug commands that align with the core topics (OSPF, EIGRP, VLANs, STP, ACLs, NAT). You should know the command syntax, what it does, and the risks.
debug ip ospf hello – Displays OSPF Hello packet exchanges. Useful for verifying adjacency formation and timer mismatches.
debug ip ospf adj – Shows OSPF adjacency state changes (down, init, 2-way, exstart, exchange, loading, full). Critical for troubleshooting neighbor issues.
debug ip eigrp – Displays EIGRP packets sent and received. Use with caution; EIGRP can be chatty.
debug ip rip – Shows RIP updates. Safer because RIP is less CPU-intensive.
debug spanning-tree – Monitors STP topology changes. Helps identify flapping ports.
debug ip packet – Displays IP packet forwarding details. Extremely CPU-intensive; always filter with an ACL.
debug ip nat – Shows NAT translations in real time. Useful for verifying PAT and dynamic NAT.
debug ip icmp – Shows ICMP messages (echo, echo-reply, unreachable). Useful for basic reachability testing.
debug interface – Shows interface status changes (up/down). Good for physical layer issues.
Best Practices for Using Debug
Always Use an Access List – For CPU-intensive debugs (e.g., debug ip packet, debug ip ospf events), define an extended ACL that matches only the traffic of interest. For example:
access-list 100 permit ip host 10.1.1.1 host 10.2.2.2Then enable the debug with the ACL number:
debug ip packet 100Use Timestamps – Enable service timestamps to correlate debug output with syslog messages:
service timestamps debug datetime msec
service timestamps log datetime msecLimit Output with Conditional Debug – For advanced scenarios, use conditional debugging to restrict output to a specific neighbor or interface:
debug ip ospf hello condition interface gigabitethernet 0/0Disable Debug Immediately – After gathering enough data, run:
undebug allOr use the shortcut:
u allUse Logging Buffered – Send debug output to a buffer instead of the console to avoid overwhelming the console session:
logging buffered 16384 debuggingThen view the buffer with:
show logNever Debug on a Production Router Without a Maintenance Window – The risk of CPU overload is too high.
Interpreting Debug Output
Debug output appears as syslog messages. Example for OSPF Hello:
*Mar 1 00:00:05.123: OSPF: Send hello to 224.0.0.5 via GigabitEthernet0/0 area 0
*Mar 1 00:00:05.124: OSPF: Rcv hello from 10.0.0.2 area 0 from GigabitEthernet0/0 10.0.0.2Key fields: timestamps, protocol, action (Send/Rcv), destination address, interface, area, source IP.
Example for debug ip packet with ACL 100:
*Mar 1 00:00:10.000: IP: s=10.1.1.1 (GigabitEthernet0/0), d=10.2.2.2, len 100, rcvd 3
*Mar 1 00:00:10.001: IP: s=10.1.1.1 (GigabitEthernet0/0), d=10.2.2.2 (GigabitEthernet0/1), len 100, forwardThis shows a packet received on G0/0 and forwarded out G0/1.
Interaction with Logging
Debug output is sent to the console by default. If you have a remote SSH session and debug, output appears on the console, not your session, unless you use:
terminal monitorThis command copies debug messages to your VTY session. Always use it when debugging remotely.
Enable Timestamps and Logging
Before any debug, configure service timestamps to see when events occur. Use 'service timestamps debug datetime msec' for millisecond precision. Set up a buffer to capture output without flooding the console: 'logging buffered 16384 debugging'. This allows you to debug without overwhelming your session, then review the buffer with 'show log'. On a remote SSH session, also issue 'terminal monitor' to receive debug messages in your session; otherwise, they go to the console only.
Create a Filter Access List
For CPU-intensive debugs like 'debug ip packet', define an extended ACL that matches only the traffic you care about. For example, to watch packets between 10.1.1.1 and 10.2.2.2, configure 'access-list 100 permit ip host 10.1.1.1 host 10.2.2.2'. The ACL number must match the one used in the debug command. This prevents the router from generating debug output for every packet, saving CPU cycles.
Enable the Debug Command
Issue the debug command with the optional ACL number. For example, 'debug ip packet 100' enables packet debugging only for traffic matching ACL 100. For OSPF adjacency issues, use 'debug ip ospf adj'. For STP, 'debug spanning-tree events'. Start with a specific debug to minimize CPU impact. If the debug is not CPU-intensive (e.g., 'debug ip icmp'), you may skip the ACL, but it's still good practice.
Observe and Interpret Output
Watch the real-time output. Look for patterns: repeated messages indicating flapping, error messages like 'OSPF: Rcv hello from ... state INIT' indicating adjacency problems, or 'IP: s=... d=... rcvd 0' indicating packet drops. Use the timestamps to correlate events. If output is overwhelming, stop the debug immediately. For example, if you see thousands of lines per second, disable the debug and consider using a more specific filter.
Disable Debug with 'undebug all'
As soon as you have enough information, disable all debugging. The command 'undebug all' (or 'u all') turns off every active debug. Leaving a debug enabled on a production router is a common CCNA exam trap — it can cause CPU overload. Always verify that debugs are off with 'show debug' (or 'show debugging'). The output should list no active debugs.
Verify No Active Debugs
After disabling, confirm with 'show debug'. This command displays all currently enabled debugging options. If any remain, disable them individually or re-issue 'undebug all'. Also check CPU usage with 'show processes cpu' to ensure the router is not under heavy load. A common exam scenario: a router crashes because a debug was left on. Always end your troubleshooting session by turning off debugs.
In an enterprise network, debug commands are a last resort after show commands fail to reveal the issue. For example, consider a branch office router that intermittently loses OSPF adjacency with the head-end. 'show ip ospf neighbor' shows the neighbor as full, but the adjacency drops every few hours. The engineer enables 'debug ip ospf adj' with an ACL filtering the neighbor's IP. The debug reveals that the neighbor transitions from full to down due to a Dead timer expiry, but the Hello timer is correct. Further investigation shows the link has occasional high latency causing Hello packets to arrive after the Dead interval. The engineer adjusts the Dead timer to 60 seconds (4x Hello) to accommodate the latency.
Another scenario: NAT is failing for some users. 'show ip nat translations' shows no entries for certain flows. The engineer enables 'debug ip nat' with an ACL matching the user's IP. The output shows 'NAT: translation failed (no resources)' — indicating the NAT pool is exhausted. The engineer increases the pool size or implements PAT.
A third scenario: a switch is experiencing STP topology changes every few seconds. 'debug spanning-tree events' shows 'Topology change detected on port GigabitEthernet0/1' repeatedly. The engineer discovers a host with a misconfigured NIC that is flapping. The fix is to enable PortFast on access ports to prevent STP from reacting to host link changes.
Performance considerations: Debug commands increase CPU utilization. On a router with 90% CPU, enabling debug can push it to 100%, causing packet loss or even a reload. In production, always use low-impact debugs first (e.g., 'debug ip icmp') and escalate to CPU-intensive ones only during maintenance windows. If the router has limited memory, the logging buffer can fill quickly, so set an appropriate size (e.g., 16384 bytes) and monitor it.
Misconfiguration: The most common mistake is forgetting to disable debug. A junior engineer enables 'debug ip packet' on a core router and walks away. Within minutes, the router's CPU hits 100%, OSPF neighbors drop, and the network goes down. The fix is to have a script or automation that disables all debugs after a timeout, or to use the 'no debug all' command as a reflex.
The CCNA 200-301 exam tests debug commands in the context of troubleshooting methodology and best practices. You will not be asked to recall obscure debug commands, but you must know:
The danger of CPU overload from debugs.
How to filter debug output with ACLs.
The difference between debug and show commands.
When to use 'terminal monitor'.
How to disable all debugs with 'undebug all'.
Common wrong answers:
'debug ip packet' is safe on any router. Wrong — this is the most dangerous debug because it processes every packet. Candidates choose this because they think 'debug' is like 'show' but more detailed. The correct answer is to always filter with an ACL.
'undebug all' disables only the current debug. Wrong — it disables all active debugs. Candidates think they need to specify the debug name, but 'all' is a catch-all.
Debug output appears automatically in a Telnet/SSH session. Wrong — by default, debug goes to the console. Candidates forget 'terminal monitor'.
'show debug' enables debugging. Wrong — it only displays enabled debugs. Candidates confuse it with 'debug'.
Exam traps:
A question describes a router crashing after a debug is enabled. The answer is that the debug consumed all CPU.
A scenario where an engineer cannot see debug output remotely. The solution is 'terminal monitor'.
A question asks how to limit debug output. The answer is to use an access list with the debug command.
A question about best practice: always disable debug after use.
Decision rule: If the question involves real-time monitoring of transient events, the answer likely involves a debug command. If it involves a snapshot of current state, it's a show command. For safety questions, always choose the option that includes filtering or disabling debug.
Memorize these commands exactly: - 'debug ip packet [acl-number]' - 'debug ip ospf adj' - 'debug ip icmp' - 'undebug all' - 'terminal monitor' - 'show debug' - 'service timestamps debug datetime msec'
Debug commands run at process level and consume CPU; 'debug ip packet' is the most dangerous and must always be filtered with an ACL.
Use 'terminal monitor' to see debug output in a remote SSH/Telnet session; otherwise, output goes to the console only.
Always disable debugging with 'undebug all' immediately after gathering data; leaving debug on can crash the router.
Use 'service timestamps debug datetime msec' to add precise timestamps to debug output for correlation.
Use 'logging buffered 16384 debugging' to capture debug output in a buffer, then review with 'show log'.
'show debug' displays currently enabled debugging options; it does not enable debugging.
Common CCNA debug commands include 'debug ip ospf adj', 'debug ip eigrp', 'debug spanning-tree', and 'debug ip nat'.
These come up on the exam all the time. Here's how to tell them apart.
Show Commands
Provide a static snapshot of current state or statistics.
Do not consume significant CPU resources.
Safe to use on production routers at any time.
Output is a single set of data, not continuous.
Examples: 'show ip ospf neighbor', 'show running-config'.
Debug Commands
Provide real-time, continuous event messages.
Consume CPU cycles; can crash a router if overloaded.
Use with caution; always filter and disable after use.
Output is a stream of messages until disabled.
Examples: 'debug ip ospf adj', 'debug ip packet'.
Mistake
Debug commands are safe to use on any router because they only display information.
Correct
Debug commands consume CPU cycles and can cause a router to crash if the CPU becomes overloaded, especially with 'debug ip packet' on a busy router.
Candidates confuse debug with show commands, which are read-only and do not impact CPU significantly.
Mistake
Debug output automatically appears in my Telnet/SSH session.
Correct
By default, debug output is sent to the console. To see it in a remote session, you must issue 'terminal monitor'.
Candidates assume that because they are logged in remotely, they will see all output, but IOS separates console and VTY output.
Mistake
'undebug all' disables only the debug command I just issued.
Correct
'undebug all' disables all active debugging on the router, not just the last one.
The word 'all' is misinterpreted as 'the current one' rather than 'every debug'.
Mistake
Using an access list with a debug command filters the debug output displayed on the screen.
Correct
The access list actually prevents the router from processing debug events for non-matching traffic, reducing CPU load. It does not just filter output.
Candidates think of ACLs as filters for displayed data, but in this context, they control which events trigger the debug code path.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
'Show' commands provide a static snapshot of the current state (e.g., 'show ip route'), consuming minimal CPU. 'Debug' commands provide real-time, continuous output of events as they happen (e.g., 'debug ip ospf hello'), consuming significant CPU resources. Use 'show' for routine checks and 'debug' only for transient issues that cannot be captured with 'show'. Always disable debug after use.
By default, debug output goes to the console. To see it in your SSH session, issue 'terminal monitor' before enabling the debug. This command copies debug messages to your VTY line. If you forget, you can still issue it and then re-enable the debug, but it's best to do it first. Also ensure 'logging console' is not disabled.
Yes. Debug commands run at process level and can consume 100% CPU if the router is busy processing packets that match the debug criteria. This can cause routing protocol keepalives to be missed, leading to neighbor drops, or even cause the router to reload. Always filter with ACLs and disable debug as soon as possible. On very busy routers, avoid CPU-intensive debugs like 'debug ip packet' entirely.
It enables debugging of IP packet forwarding, but only for packets that match access list 100. ACL 100 must be an extended ACL that defines the traffic of interest. The router will generate debug messages only for packets that are permitted by the ACL, reducing CPU load. Without the ACL number, the debug would apply to all IP packets, which is dangerous.
Use the 'no' form of the specific debug command. For example, to disable 'debug ip ospf adj', issue 'no debug ip ospf adj'. Alternatively, you can use 'undebug ip ospf adj'. The 'undebug all' command disables everything, so use the specific form if you want to keep other debugs active.
'logging buffered 16384 debugging' configures a buffer in RAM to store debug and log messages. Instead of sending debug output directly to the console (which can overwhelm your session), the messages are stored in the buffer. You can later view them with 'show log'. This allows you to debug without real-time display, reducing the risk of session lockup.
If you enabled a debug and then the router reloaded, the debug state is lost because debug commands are not saved to the running config. Also, if you used 'undebug all' earlier, it would have cleared all debugs. Always verify with 'show debug' immediately after enabling. If it shows nothing, re-issue the debug command.
You've just covered IOS Debug Commands and Best Practices — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?