VMware ESXi and vSphere Cluster Management

Cisco IOS Debug Command: Real-Time Troubleshooting and Safe Use

Learn how to use Cisco IOS debug commands to inspect live protocol and packet activity safely, including ICMP, EIGRP, terminal monitoring, and cleanup.

Cisco IOS is the operating system and command-line environment used by many Cisco routers and switches. Its debug facility is a privileged EXEC diagnostic tool that displays live activity from IOS processes.

Debugging can reveal protocol events, packet handling, control-plane activity, device operations, and errors that may not be visible with ordinary show commands. Because the output is generated while the device is operating, debug is powerful but potentially disruptive.

What the Cisco IOS debug Command Does

Debug commands instruct IOS to report selected internal or protocol activity in real time. For example, an ICMP debug can show events associated with echo requests and echo replies, while a routing-protocol debug can show neighbor or route-exchange activity.

Depending on the feature, output may describe:

Protocol events, such as routing neighbor state changes
Packet reception, processing, forwarding, or rejection
Control-plane activity, including routing and neighbor protocols
Device operations and feature-specific state changes
Errors, timeouts, and failed processing attempts

Selected debugging normally continues until you disable it, the relevant session ends in some circumstances, or the device reloads. Do not assume that debug output stops simply because you have finished looking at the screen.

Why Debugging Must Be Used Carefully

Generating and displaying diagnostic information consumes device resources. The impact can include:

CPU overhead: IOS must detect events, format messages, and send them to an output destination.
Memory and buffering overhead: messages may use process memory or logging buffers.
Logging overhead: debug messages can compete with important system messages when logging is enabled.
Terminal-output overhead: a busy terminal can spend substantial time rendering or transmitting output.

High-volume output may make a router or switch difficult to manage. On an already overloaded device, debugging can worsen packet loss, delay control-plane processing, or make a remote session appear frozen. Use a short, targeted diagnostic session rather than continuous debugging, and avoid broad debugging on busy production devices.

Targeted Debugging Versus Broad Debugging

IOS provides feature- and protocol-specific debug commands. A targeted command observes one relevant category and generally produces less output than a broad command.

debug ip icmp focuses on ICMP events, which is useful while testing with ping.
EIGRP-specific debugging focuses on EIGRP behavior such as adjacency or route exchange. Exact syntax can vary by IOS release and platform, so use command help and platform documentation for the available form.
debug all enables a very broad set of debugging categories and can produce an overwhelming amount of output.

Narrowing the scope reduces the number of events IOS must report and makes the evidence easier to interpret. Choose the narrowest debug that can answer the question you are investigating.

Command	What It Observes	Typical Use Case	Risk Level	How to Stop It
`debug ip icmp`	ICMP events	Relate a ping test to echo requests, replies, or errors	Low to moderate, depending on traffic volume	`no debug ip icmp` or `undebug all`
`debug eigrp` or platform-specific EIGRP syntax	EIGRP protocol activity	Investigate adjacency or route-exchange problems	Moderate to high	Use the matching `no debug` form or `undebug all`
`debug all`	A broad set of debugging categories	Rare, controlled lab or vendor-directed investigation	Very high	`undebug all` or `un all`
`undebug all` / `un all`	Stops active debugging	Immediate cleanup after evidence collection or excessive output	Low	Not applicable
`show debugging`	Currently active debug settings	Verify what is enabled before or after a test	Low	Not applicable

Where Debug Output Appears

Console sessions

A console session is direct local terminal access to the device. Console users normally receive debug output directly, subject to the device's console and logging behavior.

SSH and Telnet VTY sessions

A VTY, or virtual terminal line, provides remote administrative access such as SSH or Telnet. In a remote session, enter:

terminal monitor

This enables debug and logging messages for the current remote terminal. It does not automatically enable monitoring for every other administrator's session.

To stop monitored messages in that remote session, enter:

terminal no monitor

terminal no monitor stops monitored output for the current remote session. It does not disable the debug itself; use the matching no debug command or undebug all to stop debugging.

Access Method	Default Visibility of Debug Output	Required Supporting Command	Operational Notes
Console	Normally displayed directly	Usually none	Useful as a recovery path when remote access is affected
SSH VTY session	Not necessarily displayed in the session	`terminal monitor`	Use only in the session where output is needed; stop monitoring with `terminal no monitor`
Telnet VTY session	Not necessarily displayed in the session	`terminal monitor`	Telnet is less secure than SSH; the same monitoring rule applies

Debugging ICMP Traffic

ICMP, or Internet Control Message Protocol, carries messages used for network diagnostics and error reporting. The ping command normally tests reachability with an ICMP echo request and an ICMP echo reply.

An echo request is sent by the device or host testing reachability.
An echo reply is returned by the destination when it receives and answers the request.

debug ip icmp is a focused way to observe ICMP events on an IOS device. The exact text and direction indicators vary by platform and software version, but diagnostic messages commonly include source and destination IP addresses. Use those addresses to determine which device sent the event and which address was the intended recipient.

Lab example: observe a ping

Connect through the console, or use SSH/Telnet and enter terminal monitor.
Check the device before debugging if needed with a low-impact command such as show ip interface brief or show processes cpu.
Enable the focused debug:

Router# debug ip icmp

Run a controlled test involving a reachable address such as 10.0.0.1:

Router# ping 10.0.0.1

A sequence of reply messages indicates that the device received or generated successful ICMP responses, depending on the direction shown in the output. Compare the source and destination addresses in the messages with the direction of the ping test.

Stop the debug immediately after collecting the required evidence:

Router# no debug ip icmp

Stopping Debug Output

To stop one feature, use the negated form of its command. For ICMP:

no debug ip icmp

To disable all active debugging, use:

undebug all

un all is a commonly accepted IOS abbreviation for undebug all, although command parsing and accepted abbreviations can vary. Use the full command when clarity is important.

Disabling debugging is an immediate cleanup step after collecting evidence. Confirm the result with:

show debugging

The Risks of debug all

debug all enables a very broad set of debugging categories. On a production device, it can generate a huge volume of terminal and logging output and impose substantial CPU and memory load. The output can hide the important message you actually need and may make the device slow or unresponsive.

It is inappropriate for normal production troubleshooting. Prefer a protocol-specific command, use a controlled test, and stop the debug promptly. If debug all has already been enabled, issue:

undebug all

Safe Troubleshooting Workflow

Phase	Action	Reason
Before debugging	Verify the symptom with `ping`, `traceroute`, relevant `show` commands, or logs. Check access and plan console or out-of-band recovery.	Confirms that a debug is necessary and prevents avoidable risk.
During debugging	Choose the narrowest relevant category, define a short observation window, and run one controlled test.	Limits output, device overhead, and ambiguity.
After debugging	Capture only required output, disable the specific debug or all debugging, then verify CPU and device responsiveness.	Removes the diagnostic load and confirms safe cleanup.
If output becomes excessive	Immediately issue `undebug all` or `un all`. Reduce terminal monitoring if appropriate and verify with `show debugging`.	Stops harmful output before it worsens the incident.

Verification and Operational Checks

Check active debugging

show debugging

This command shows which debug options are currently active. Run it before a test to discover existing debugging and after cleanup to confirm that no unwanted categories remain enabled.

Review retained log messages

show logging

show logging reviews available system messages, including messages retained in the logging buffer when buffered logging is configured. A logging buffer is a memory area that stores selected messages for later viewing.

Real-time terminal output and buffered logging are different:

Real-time output is displayed as an event occurs in a console or monitored VTY session.
Buffered output is retained in memory and can be reviewed later, subject to logging configuration, buffer size, and message severity.

Check CPU impact

show processes cpu

Use this or an equivalent platform-appropriate CPU command before, during, and after a debug session. Compare the device's responsiveness and CPU behavior with the pre-debug condition.

Practical Troubleshooting Scenarios

A ping fails although the interface is up

Run a ping with a known source and destination.
Enable debug ip icmp for a short test interval.
Determine whether echo requests, echo replies, or ICMP error messages appear.
Disable the debug.
Use the evidence to guide routing-table, ACL, NAT, interface, or return-path checks.

Debug output does not appear over SSH or Telnet

Confirm that the debug is active with show debugging.
Enter terminal monitor in the same remote session.
Repeat a controlled test.
Disable the debug after collecting the output.

The router becomes slow or the terminal is overwhelmed

Immediately issue undebug all or un all.
Use show debugging to verify that debugging is no longer active.
Check CPU usage with show processes cpu and review messages with show logging.
Retry later with a narrower scope and a shorter test, preferably through console or out-of-band access.

An EIGRP neighbor relationship does not form

EIGRP is a Cisco routing protocol. Start with low-impact verification:

Check physical and IP interface state.
Verify EIGRP configuration and neighbor prerequisites with appropriate show commands.
Enable only the relevant EIGRP debug syntax supported by the platform and IOS version.
Wait for or generate a limited test event.
Review adjacency or route-exchange evidence, then stop debugging and validate CPU and responsiveness.

Exam-Relevant Notes

debug provides live diagnostic output; it is not the same as a stored log review.
debug ip icmp is targeted and commonly paired with ping.
Console users normally see debug output directly; remote VTY users generally need terminal monitor.
terminal no monitor stops monitored messages in the current remote session but does not disable debugging.
no debug ... stops a specific debug, while undebug all and commonly un all stop all active debugging.
debug all is broad and risky, especially on a busy production device.
show debugging verifies active debug settings; show logging reviews retained messages.

For related study, review Cisco IOS debug command usage alongside ping, traceroute, interface verification, routing troubleshooting, and IOS logging concepts.