Cisco Debug Commands – Overview & Safe Usage

1. What Are Debug Commands and Why Are They Powerful?

Cisco IOS debug commands are real-time diagnostic tools that generate detailed, continuous output about the operation of specific protocols, processes, and packet flows on a router or switch. Unlike show commands — which provide a snapshot of the current state at a single point in time — debug commands stream a running log of every event processed by the specified function as it happens.

This makes debug commands extraordinarily powerful for diagnosing transient faults, protocol negotiation failures, intermittent connectivity problems, and events that are invisible to show commands because they happen too quickly. When a routing adjacency flaps and recovers in seconds, or a VPN negotiation fails on the first attempt and then succeeds, show commands may not capture the failure state. Debug output captures every step of every event in real time.

Feature	show Commands	debug Commands
Output type	Point-in-time snapshot of current state	Continuous real-time stream of events as they occur
CPU impact	Low — executed once on demand	High — runs continuously; each event generates output processed by the CPU
Best for	Stable-state verification: routes, interfaces, neighbours	Transient events: protocol negotiations, packet flows, VPN handshakes, intermittent failures
Risk to production	Very low — no ongoing resource consumption	Significant — can overwhelm CPU on busy devices, causing packet drops and outages
Duration	Instantaneous — runs once and exits	Continuous — runs until explicitly disabled
When to use	Default first step in all troubleshooting	After show commands fail to reveal the problem; use with caution on production devices

2. The Critical Safety Warning — Debug in Production

Debug commands are the most dangerous commands an engineer can run on a production router or switch. Misusing them is a known cause of network outages. Understanding why — and how to mitigate the risk — is the most important thing to know about debug before touching the command.

Why Debug Is Dangerous

  How IOS processes debug output:

  Normal packet forwarding: processed in hardware (CEF — Cisco Express Forwarding)
  → packets forwarded at wire speed, minimal CPU involvement

  When debug is enabled for a protocol:
  → Every packet or event matching the debug criterion is
    PROCESS-SWITCHED (copied from hardware to the CPU for inspection)
  → The CPU must generate a debug message for EACH event
  → The debug message is sent to the console buffer
  → The console output itself consumes CPU

  The danger scenario:
  Router is forwarding 1,000,000 packets per second (normal for a WAN router)
  Engineer runs: debug ip packet

  1,000,000 × (process switch to CPU + format debug message + output to console)
  = Router CPU → 100% within seconds
  = Router stops forwarding packets — neighbours drop adjacencies
  = Network outage caused by the troubleshooting command itself

  Real-world consequence: "I was trying to troubleshoot a slow link and
  accidentally took down the entire network for 10 minutes."

Safety Rules for Debug

Rule	Reason
Always run show commands first	show commands are free — they cost no CPU and reveal the current state. Only escalate to debug when show output is insufficient to identify the problem.
Never run debug ip packet without an access-list filter on a production router	debug ip packet without a filter captures EVERY IP packet. On a busy interface this is hundreds of thousands of events per second — instant CPU overload.
Check CPU utilisation before running debug	If CPU is already above 70%, any debug command could push it to 100%. Check with `show processes cpu sorted` first.
Use conditional debug to limit scope	Restrict debug to a single IP address or interface — massively reduces event volume and CPU impact.
Run at off-peak hours when possible	Lower traffic volume = fewer debug events = lower CPU impact during the debug session.
Always have undebug all ready to run	If debug output floods the console and the CPU spikes, type `undebug all` (or `no debug all`) immediately. Know these commands before starting any debug.
Prefer lab simulation over production debugging	If the issue can be reproduced in a lab, debug there — no production risk.

3. Debug Prerequisites — Console, Timestamps, and Terminal Monitor

Before running any debug command, a few configuration steps ensure the output is useful, timestamped, and visible in the current management session.

3.1 Timestamped Debug Output

  By default, debug output has no timestamp:
  *Mar  1 00:00:00.000: IP: s=10.1.1.1 (GigabitEthernet0/0), d=10.2.2.2, len 100

  Enable timestamps for debug (and logging) messages:
  Router(config)# service timestamps debug datetime msec localtime
  Router(config)# service timestamps log datetime msec localtime

  With timestamps:
  *Mar 15 14:23:45.123: IP: s=10.1.1.1 (GigabitEthernet0/0), d=10.2.2.2 ...

  "datetime msec" = includes date, time, and milliseconds
  "localtime"     = uses the router's local clock timezone
  Without timestamps, correlation of debug events with other logs is impossible.

3.2 Debug Output Destination

  Debug output is sent to the router's logging buffer and to active console/VTY.

  Console connection (rollover cable):
  - Debug output automatically appears on the console.

  VTY (SSH/Telnet) connection:
  - Debug output does NOT appear by default on VTY sessions.
  - Must enable with:
  Router# terminal monitor
  - This enables real-time syslog/debug output on the current VTY session.
  - To disable:
  Router# terminal no monitor

  Logging to buffer (review debug output after the fact):
  Router(config)# logging buffered debugging 65536
  ! Sets buffer size to 65536 bytes at debug level
  Router# show logging   ! review buffered debug output — see show logging

3.3 Logging Synchronous (Prevent Output Corruption)

  Without logging synchronous, debug output interrupts mid-command:

  Router# show ip rout   ← typing this when debug fires:
  *Mar 15 14:23:45.123: OSPF: Rcv hello from 10.1.1.2 ...
  e                      ← you typed "e" but it appeared after the debug line
  Router# show ip route  ← command is corrupted

  Enable logging synchronous on the console and VTY lines:
  Router(config)# line console 0
  Router(config-line)# logging synchronous
  Router(config)# line vty 0 4
  Router(config-line)# logging synchronous

  With logging synchronous, Cisco IOS reprints the current command line
  after each debug message — command input is clean and readable.

4. Disabling Debug — undebug all

Knowing how to stop a debug session immediately is as important as knowing how to start one. There are two equivalent commands to stop all active debugs:

  Stop ALL active debug sessions immediately:
  Router# undebug all
  Router# no debug all     ← identical, alternative syntax

  Stop a specific debug only:
  Router# no debug ip packet
  Router# no debug ip ospf events
  Router# no debug crypto isakmp

  View which debugs are currently active:
  Router# show debug
  IP packet debugging is on (detailed)
  OSPF packet inbound debugging is on
  (All other debugging is turned off)

  If debug output floods the console and you cannot type:
  1. Wait for a gap in output and type: undebug all
  2. If on a VTY session: closing the SSH session does NOT stop debug —
     the debug continues running, just with no one reading the output.
     The CPU impact remains. Reconnect and run undebug all.
  3. Last resort: reboot the device — all debug states are cleared on reload.

  IMPORTANT: Simply disconnecting from an SSH session does NOT stop debug.
  The debug process continues consuming CPU even with no terminal session.
  Always run undebug all BEFORE closing a debug session.

Critical exam and real-world fact: Closing an SSH session while debug is running does not stop the debug. The debug continues consuming CPU resources until either undebug all is run from any management session or the device is rebooted. Always disable debug before disconnecting.

5. Conditional Debug — Limiting Scope with Access Lists

Conditional debug is the safe way to run debug on a production device. By associating a debug command with an access list, the debug output is limited to only the packets or events that match the access list — dramatically reducing the volume of debug events and CPU impact.

debug ip packet with Access List Filter

  Problem: debug ip packet alone generates output for EVERY IP packet.
  On a busy interface: millions of events per second → CPU overload.

  Solution: restrict debug to a specific source IP using an access list.

  Step 1 — Create a standard ACL matching only the traffic of interest:
  Router(config)# ip access-list standard DEBUG_FILTER
  Router(config-std-nacl)# permit host 192.168.1.5   ! only packets to/from this host
  Router(config-std-nacl)# exit

  Step 2 — Run debug ip packet referencing the ACL:
  Router# debug ip packet 50 detail
  !                       ↑  ↑
  !                  ACL# or name  "detail" = include more detail in output

  ! Using named ACL:
  Router# debug ip packet DEBUG_FILTER detail

  Result: only packets with source or destination matching 192.168.1.5
          generate debug output — all other packets are ignored.

  Volume reduction: from 1,000,000 events/sec → perhaps 10 events/sec
                    (only the troublesome host's traffic)

debug condition — Interface-Level Conditional Debug

  Restrict all debugs to a specific interface (Cisco IOS 12.3+):

  Router# debug condition interface GigabitEthernet 0/0
  Condition 1 set
  !
  ! Now ALL debug commands only generate output for events on Gi0/0.
  ! Debug commands on other interfaces are silently filtered.

  Verify active conditions:
  Router# show debug condition

  Remove the condition:
  Router# no debug condition interface GigabitEthernet 0/0

6. debug ip packet — IP Packet Forwarding

debug ip packet is one of the most powerful and most dangerous debug commands. It shows every IP packet that is process-switched by the router — meaning every packet that the CPU handles directly (not forwarded by CEF hardware).

When to Use debug ip packet

Use debug ip packet when: ping fails and you need to see if the router is actually processing the packet; you need to confirm whether the router is receiving or forwarding a packet; or you need to see which path a specific packet is taking.

  ALWAYS use with an access-list filter on production routers:

  ! Create filter for the troublesome host (192.168.5.10):
  Router(config)# access-list 99 permit host 192.168.5.10

  ! Run debug with filter:
  Router# debug ip packet 99 detail

  Sample debug ip packet output:
  *Mar 15 14:23:01.500: IP: tableid=0, s=192.168.5.10 (GigabitEthernet0/0),
      d=10.20.0.5 (GigabitEthernet0/1), routed via RIB
  *Mar 15 14:23:01.500: IP: s=192.168.5.10, d=10.20.0.5 (GigabitEthernet0/1),
      len 100, sending

  If a packet is being DROPPED by the router, the output shows:
  *Mar 15 14:23:01.500: IP: s=192.168.5.10 (GigabitEthernet0/0),
      d=10.20.0.5, len 100, unroutable
  → "unroutable" = no route to destination in routing table

  *Mar 15 14:23:01.500: IP: s=192.168.5.10 (GigabitEthernet0/0),
      d=10.20.0.5, len 100, access denied
  → "access denied" = ACL is dropping the packet (identify which ACL)

  Key output messages:
  "routed via RIB"   → packet matched a route and is being forwarded
  "unroutable"       → no route — router will send ICMP unreachable
  "access denied"    → ACL is blocking the packet
  "encapsulation failed" → ARP failed, no next-hop MAC address available

CEF vs process switching: Modern Cisco routers use CEF (Cisco Express Forwarding) to forward most packets in hardware without CPU involvement. debug ip packet only shows packets that are process-switched (handled by the CPU). If CEF is enabled (default), a forwarded packet may not appear in debug output at all — because it never reached the CPU. To disable CEF temporarily for debugging a specific interface: no ip cef (use with extreme caution on production — disabling CEF forces ALL forwarding to the CPU, causing severe performance degradation).

7. debug ip routing — Routing Table Changes

debug ip routing displays real-time events whenever the IP routing table is modified — routes added, removed, or updated. This is invaluable for diagnosing routing protocol instability, flapping routes, or mysterious route disappearances.

  Router# debug ip routing

  Sample output — route added via OSPF:
  *Mar 15 14:25:01.100: RT: add 10.20.0.0/24 via 172.16.0.2, ospf metric [110/2]
  *Mar 15 14:25:01.100: RT: SET_LAST_RDB for 10.20.0.0/24

  Sample output — route removed (OSPF neighbour lost):
  *Mar 15 14:25:45.220: RT: del 10.20.0.0/24 via 172.16.0.2, ospf metric [110/2]
  *Mar 15 14:25:45.220: RT: no routes to 10.20.0.0/24, flushing

  Sample output — route flapping (instability):
  *Mar 15 14:25:01.100: RT: add 10.20.0.0/24 via 172.16.0.2, ospf metric [110/2]
  *Mar 15 14:25:01.350: RT: del 10.20.0.0/24 via 172.16.0.2, ospf metric [110/2]
  *Mar 15 14:25:01.600: RT: add 10.20.0.0/24 via 172.16.0.2, ospf metric [110/2]
  ← route is adding/removing every 250 ms → routing instability
  Root cause: OSPF neighbour flapping due to link error or keepalive issue.

  What debug ip routing reveals:
  - Which routes are being added or removed
  - Which routing protocol is making the change
  - The next-hop IP address and metric
  - The exact time of each change (with timestamps enabled)
  - Route flapping patterns that indicate instability

  CPU impact: Lower than debug ip packet — only fires on routing table
  changes, not for every forwarded packet. Still use with care during
  periods of routing instability (flapping = many events per second).

8. debug ip ospf — OSPF Protocol Events

OSPF debug commands reveal the detailed operation of the OSPF protocol — hello exchanges, neighbour state machine transitions, LSA flooding, and SPF calculations. They are essential for diagnosing OSPF adjacency problems.

  Main OSPF debug commands:

  Router# debug ip ospf events          ! major OSPF events (adjacency changes)
  Router# debug ip ospf hello           ! hello packet details (most used for adj)
  Router# debug ip ospf adj             ! adjacency formation process in detail
  Router# debug ip ospf packet          ! all OSPF packet types (verbose — careful)
  Router# debug ip ospf lsa-generation  ! when and why LSAs are generated

  Sample — debug ip ospf adj (adjacency failing):
  *Mar 15 14:30:01.001: OSPF-1 ADJ   Gi0/0: Rcv DBD from 10.1.1.2 seq 0x1BEE
      opt 0x52 flag 0x7 len 32 mtu 1500 state EXSTART
  *Mar 15 14:30:01.150: OSPF-1 ADJ   Gi0/0: Nbr 10.1.1.2 MTU mismatch!
      local: 1500, nbr: 1400
  *Mar 15 14:30:01.150: OSPF-1 ADJ   Gi0/0: Nbr 10.1.1.2 going to DOWN
  ← FOUND: MTU mismatch — one interface is 1500, neighbour is 1400.
  Fix: ip ospf mtu-ignore on one interface, or correct MTU settings.

  Sample — debug ip ospf hello (hello mismatch):
  *Mar 15 14:30:01.001: OSPF-1 HELLO Gi0/0: Rcv hello from 10.1.1.2
      area 0 int mask 255.255.255.0  dead 40 hello 10
  *Mar 15 14:30:01.001: OSPF-1 HELLO Gi0/0: Dead/Hello Mismatch
      (from nbr 10.1.1.2), Dead: 40, our Dead: 120
  ← FOUND: Hello/dead timer mismatch. Local dead=120, neighbour dead=40.
  Fix: Ensure both neighbours have matching hello and dead timers.

  Common OSPF problems revealed by debug:
  - Hello timer mismatch            → adjacency never forms
  - Dead timer mismatch             → adjacency never forms
  - MTU mismatch                    → stuck in EXSTART/EXCHANGE
  - Authentication mismatch         → packets rejected
  - Area ID mismatch                → adjacency never forms
  - Network type mismatch           → DR/BDR election problems

See: OSPF Neighbor States | OSPF DR/BDR Election | OSPF Adjacency Troubleshooting Lab

9. debug ip eigrp — EIGRP Protocol Events

  Main EIGRP debug commands:

  Router# debug eigrp fsm            ! EIGRP Feasible Successor state machine
  Router# debug eigrp neighbors      ! neighbor formation and loss events
  Router# debug ip eigrp             ! EIGRP updates, queries, replies (verbose)
  Router# debug ip eigrp summary     ! summarised EIGRP event overview

  Sample — EIGRP neighbour going down:
  *Mar 15 14:35:01.001: EIGRP-IPv4 4: Neighbor 10.1.1.2 (GigabitEthernet0/0)
      is down: holding time expired
  ← Holdtime expired — neighbour stopped receiving hello packets.
  Root cause: interface error, unidirectional link, ACL blocking EIGRP,
              or hello timer mismatch.

  Sample — EIGRP query with no feasible successor:
  *Mar 15 14:35:10.500: EIGRP-IPv4 4: 10.20.0.0/24, metric 28160,
      sending query — no feasible successor
  ← Route entered ACTIVE state — router is querying all neighbours.
  Extended: if queries are unanswered, route goes STUCK-IN-ACTIVE (SIA).

10. debug crypto isakmp — IKE/IPsec VPN Negotiation

VPN debugging is one of the most common use cases for debug commands. IPsec VPN establishment is a multi-phase process — IKE Phase 1 (ISAKMP) and IKE Phase 2 (IPsec SA). When a VPN fails to establish, the error is almost always in one of these phases, and debug output precisely identifies which parameter is mismatched.

  Main IPsec/VPN debug commands:

  Router# debug crypto isakmp          ! IKE Phase 1 negotiation (most useful)
  Router# debug crypto ipsec           ! IKE Phase 2 / IPsec SA establishment
  Router# debug crypto engine          ! encryption/decryption engine operations
  Router# debug crypto map             ! crypto map matching and ACL evaluation

  Sample — debug crypto isakmp (Phase 1 failure — mismatched pre-shared key):
  *Mar 15 14:40:01.001: ISAKMP:(0): processing HASH payload. message ID = 0
  *Mar 15 14:40:01.001: ISAKMP:(0): processing NOTIFY AUTHENTICATION_FAILED
      protocol 1, spi 0, message ID = 0
  *Mar 15 14:40:01.001: ISAKMP:(0): deleting SA reason "DELETE_REASON_AUTH_FAIL"
  ← FOUND: Authentication failed — pre-shared keys do not match.

  Sample — IKE Phase 1 proposal mismatch:
  *Mar 15 14:40:05.001: ISAKMP:(0): atts are not acceptable — attribute mismatch
  *Mar 15 14:40:05.001: ISAKMP:(0): no offers accepted!
  ← FOUND: ISAKMP policy attributes do not match — encryption algorithm, hash,
  DH group, or lifetime differs between the two peers.

  Sample — successful IKE Phase 1 completion:
  *Mar 15 14:40:10.001: ISAKMP:(1001): SA is doing pre-shared key auth
  *Mar 15 14:40:10.100: ISAKMP:(1001): IKE->AUTH_KEY_EXCH
  *Mar 15 14:40:10.200: ISAKMP:(1001): SKEYID state generated
  *Mar 15 14:40:10.300: ISAKMP:(1001): SA authentication status: authenticated
  *Mar 15 14:40:10.350: ISAKMP:(1001): SA has been authenticated — Phase 1 DONE
  ← IKE Phase 1 completed successfully.

  Common VPN problems revealed by debug crypto isakmp:
  - "AUTHENTICATION_FAILED"           → pre-shared keys do not match
  - "atts are not acceptable"         → ISAKMP policy mismatch
  - "no offers accepted"              → no matching Phase 1 proposal
  - "Main mode connection attempt"    → peer is not responding (firewall blocking
                                        UDP 500 or NAT issue)
  - Phase 1 completes, Phase 2 fails  → switch to "debug crypto ipsec"

See: IPsec Basics | IPsec VPN | Site-to-Site vs Remote Access VPN | Site-to-Site IPsec VPN Lab

11. Other Commonly Used Debug Commands

debug ip rip — RIP Protocol Events

  Router# debug ip rip

  Sample output:
  *Mar 15 14:45:01.001: RIP: received v2 update from 192.168.1.2 on GigabitEthernet0/0
    10.20.0.0/24 via 0.0.0.0 in 1 hops
    10.30.0.0/24 via 0.0.0.0 in 2 hops

  *Mar 15 14:45:01.001: RIP: sending v2 update to 224.0.0.9 via GigabitEthernet0/0
    subnet 10.10.0.0/24, metric 1

  Useful for: verifying RIP updates are being sent/received; checking hop counts;
  confirming split horizon is working correctly.

debug ip bgp — BGP Events

  Router# debug ip bgp 10.1.1.2 events   ! events for a specific BGP peer
  Router# debug ip bgp 10.1.1.2 updates  ! BGP UPDATE messages (can be verbose)

  Sample — BGP peer going down:
  *Mar 15 14:50:01.001: BGP: 10.1.1.2 went from Established to Idle
  *Mar 15 14:50:01.001: BGP: 10.1.1.2 TCP connection closed
  ← Peer connection dropped — check the TCP session, ACLs, and keepalives.

  CPU warning: "debug ip bgp updates" on a router with many BGP prefixes
  (full Internet table = ~900,000 routes) can be extremely verbose — filter
  by peer or prefix before running in production.

debug dhcp — DHCP Server/Client Events

  Router# debug ip dhcp server events    ! DHCP server events (offer, ack, etc.)
  Router# debug ip dhcp server packet    ! detailed DHCP packet content

  Sample — DHCP DORA process:
  *Mar 15 14:55:01.001: DHCPD: DHCPDISCOVER received from client 0100.1122.3344.55
  *Mar 15 14:55:01.010: DHCPD: Sending DHCPOFFER to client on GigabitEthernet0/0
  *Mar 15 14:55:01.050: DHCPD: DHCPREQUEST received from client 0100.1122.3344.55
  *Mar 15 14:55:01.060: DHCPD: Sending DHCPACK to 192.168.1.10 on Gi0/0

  Sample — DHCP pool exhausted:
  *Mar 15 14:55:10.001: DHCPD: DHCPDISCOVER from 0100.5566.7788.99 — no free addresses
  ← DHCP pool has no addresses left — increase pool or check for lease hoard.

debug ppp — PPP Serial Link Events

  Router# debug ppp negotiation         ! LCP and NCP negotiation
  Router# debug ppp authentication      ! PAP/CHAP authentication

  Sample — CHAP authentication failure:
  *Mar 15 15:00:01.001: PPP Se0/0/0: CHAP: O CHALLENGE id 1 len 23 from "R1"
  *Mar 15 15:00:01.050: PPP Se0/0/0: CHAP: I RESPONSE id 1 len 23 from "R2"
  *Mar 15 15:00:01.060: PPP Se0/0/0: CHAP: Failed to authenticate — MD5 mismatch
  ← CHAP authentication failed — passwords do not match.
  Fix: Verify username/password pairs match on both ends.

debug spanning-tree — STP Events

  Switch# debug spanning-tree events    ! STP topology changes, port state transitions

  Sample — STP topology change:
  *Mar 15 15:05:01.001: STP: VLAN0010 GigabitEthernet0/1 moved from FORWARDING
      to BLOCKING
  *Mar 15 15:05:01.001: STP: VLAN0010 Topology Change count 47 last change occurred 0:00:01 ago

  High topology change count = STP instability → investigate portfast, rogue switches,
  or flapping interfaces.

See: STP Overview | PortFast & BPDU Guard

debug arp — ARP Resolution Events

  Router# debug arp

  Sample — ARP request and reply:
  *Mar 15 15:10:01.001: IP ARP: sent req src 192.168.1.1 0023.0405.0607,
      dst 192.168.1.5 0000.0000.0000
  *Mar 15 15:10:01.005: IP ARP: rcvd rep 192.168.1.5 0012.3456.7890,
      added to arp cache

  Sample — ARP failing (host unreachable at L2):
  *Mar 15 15:10:01.001: IP ARP: sent req for 192.168.1.99 [no reply received]
  ← ARP request sent but no reply — destination MAC unknown.
  Root cause: host is down, wrong VLAN, STP blocking, or firewall dropping ARP.

12. Debug Commands Quick Reference

Debug Command	What It Shows	CPU Risk	Typical Use Case
`debug ip packet [acl] [detail]`	IP packet forwarding, drops, routing decisions	Very High — always use ACL filter	Why is a specific packet being dropped or misrouted?
`debug ip routing`	Routing table adds, deletes, updates in real time	Medium — only fires on RIB changes	Why is a route disappearing or not being added?
`debug ip ospf events`	OSPF state changes, adjacency events	Low–Medium	OSPF neighbour forming or dropping
`debug ip ospf hello`	OSPF hello packet contents and timer mismatches	Low–Medium	Why won't OSPF neighbours form?
`debug ip ospf adj`	OSPF adjacency formation — detailed state machine	Low–Medium	OSPF stuck in EXSTART or EXCHANGE
`debug eigrp neighbors`	EIGRP neighbour up/down events	Low	EIGRP neighbour flapping or not forming
`debug eigrp fsm`	EIGRP feasible successor state machine	Low–Medium	EIGRP route going ACTIVE or stuck-in-active
`debug ip rip`	RIP update packets sent and received	Low	RIP routes not being learned or advertised
`debug ip bgp [peer] events`	BGP peer state changes and session events	Medium — use peer filter	BGP peer not establishing or dropping
`debug crypto isakmp`	IKE Phase 1 negotiation	Low–Medium	IPsec VPN not establishing — Phase 1 failure
`debug crypto ipsec`	IKE Phase 2 / IPsec SA negotiation	Low–Medium	Phase 1 OK but VPN not passing traffic
`debug ip dhcp server events`	DHCP discover, offer, request, ack events	Low	Clients not receiving DHCP addresses
`debug arp`	ARP requests and replies	Low–Medium	Host not reachable at Layer 2 despite routing OK
`debug ppp negotiation`	PPP LCP/NCP negotiation on serial links	Low	Serial WAN link up/down — PPP negotiation failing
`debug ppp authentication`	PAP/CHAP authentication exchanges	Low	PPP authentication fails on WAN link
`debug spanning-tree events`	STP topology changes, port state transitions	Low–Medium	STP instability, unexpected topology changes

13. Debug Commands Summary — Key Facts

Topic	Key Fact
debug vs show	show = point-in-time snapshot, low CPU; debug = real-time event stream, high CPU
When to use debug	Only after show commands fail to reveal the problem; use on production with extreme caution
Greatest danger	debug ip packet without ACL filter on busy router = instant CPU overload = network outage
Stop all debug	`undebug all` or `no debug all` — know these before starting any debug
Disconnecting SSH	Does NOT stop debug — debug continues consuming CPU until undebug all is run
Conditional debug	Use ACL to filter debug ip packet to a specific host; or use `debug condition interface`
VTY visibility	`terminal monitor` required to see debug output on SSH/Telnet sessions (console sees it automatically)
Timestamps	`service timestamps debug datetime msec` — essential for correlating debug events with other logs
debug ip ospf adj	Shows OSPF adjacency detail — reveals MTU mismatch, timer mismatch, authentication failure
debug crypto isakmp	Shows IKE Phase 1 — reveals pre-shared key mismatch, policy mismatch; most common VPN debug
debug ip routing	Shows routing table changes in real time — essential for diagnosing route flapping
View active debugs	`show debug` — lists every debug currently enabled

14. Debug Commands Quiz

1. What is the fundamental difference between a `show` command and a `debug` command on a Cisco IOS device, and what is the primary risk of debug on a production router?

A. show commands require privilege level 15; debug commands only need privilege level 1 B. show commands provide a point-in-time snapshot of current state with minimal CPU impact. debug commands generate a continuous real-time stream of events as they occur — every event consumes CPU resources. The primary risk is CPU overload: a debug command on a busy router can push CPU to 100%, causing packet drops and a network outage. C. show commands work on interfaces; debug commands work on routing protocols only D. They are equivalent — both produce real-time output; the difference is only the command keyword used

Correct answer is B. This is the core debug concept for the CCNA exam and real-world practice. show commands execute once, return current state information, and exit — their CPU impact is negligible. debug commands register a callback for every matching event and format a message to the console for each one — they run continuously until disabled. On a router forwarding millions of packets per second, an unfiltered debug ip packet command means millions of CPU-side events per second, causing the router to spend all its CPU time on debug output instead of forwarding traffic. The router drops packets, neighbours lose adjacencies, and users experience an outage — caused by the troubleshooting tool, not the original problem.

2. An engineer wants to run `debug ip packet` on a production router to investigate why packets from 192.168.5.10 are being dropped. What is the correct safe approach?

A. Run debug ip packet immediately — the router will automatically limit output to relevant packets B. Run debug ip packet detail to get more complete output with less CPU impact C. Schedule the debug to run during off-peak hours without an access list D. Create a standard ACL that permits only host 192.168.5.10, then run debug ip packet referencing that ACL. This restricts debug output to only packets involving that host, reducing event volume from millions per second to potentially a few per second — safe for production.

Correct answer is D. Conditional debug with an ACL is the correct approach for production use of debug ip packet. The steps are: (1) create a standard ACL:

access-list 99 permit
                  host 192.168.5.10

; (2) run debug with the filter:

debug ip
                  packet 99 detail

. The router now only generates debug output for packets where the source or destination IP matches 192.168.5.10. On a router handling millions of packets per second, this reduces debug events from millions to perhaps a handful — completely safe. The "detail" keyword adds more information about each matched packet including why it was dropped. Without the ACL filter, debug ip packet is one of the most dangerous commands on a production router.

3. An engineer runs a debug command on a router via SSH, sees useful output, and then closes the SSH session. What happens to the debug process?

A. The debug continues running and consuming CPU resources even though the SSH session is closed. The debug output is simply discarded (no one is receiving it). To stop the debug, the engineer must reconnect and run undebug all. B. Debug automatically stops when the SSH session that started it is closed C. Debug pauses until the engineer reconnects, then resumes automatically D. The router reboots automatically when a debug session is orphaned

Correct answer is A. This is one of the most critical debug safety facts. Debug commands in Cisco IOS are global — they are not associated with a specific management session. When the SSH session closes, the debug process continues running in IOS. Every matching event still consumes CPU to format a debug message — the message is simply discarded because there is no active terminal to receive it. The CPU impact remains until the debug is explicitly disabled. This means an engineer who starts a debug, sees the information they need, closes the SSH window, and goes to lunch has left a CPU-consuming process running on the production router for the entire afternoon. Always run undebug all before closing any management session where debug was active.

4. What command is used to stop ALL currently running debug processes on a Cisco IOS device, and what is the alternative syntax?

A. stop debug and debug stop B. clear debug and debug clear all C. undebug all and no debug all — both are equivalent and stop every active debug simultaneously. show debug can be used to verify no debugs remain active. D. debug off and disable debug

Correct answer is C. The two commands are undebug all and no debug all — they are completely equivalent in function. Both immediately stop every debug process currently running on the device. Memorise both syntaxes because under stress (CPU high, console flooded with output) you need to type this command without hesitation. After running either command, use show debug to confirm the output "All possible debugging has been turned off" — this verifies no debug processes remain active. To stop only a specific debug: no debug ip packet, no debug ip ospf events, etc.

5. An engineer connects to a router via SSH and enables a debug command, but sees no debug output in the terminal. The router has active traffic and the debug should be generating output. What is the most likely cause?

A. Debug is disabled by default in Cisco IOS and must be enabled with a global debug enable command first B. terminal monitor has not been entered on the VTY session. Debug output is sent to the console automatically, but on VTY (SSH/Telnet) sessions it must be explicitly enabled with terminal monitor. C. The debug is filtering incorrectly because an ACL was applied to it D. The router's CPU is too high to generate debug output

Correct answer is B. This is one of the most common "debug is not working" scenarios. By default, Cisco IOS sends syslog and debug output to the physical console port automatically. VTY sessions (SSH and Telnet connections) do NOT receive this output by default — the engineer sees the debug is running (show debug confirms it is enabled) but no output appears on the terminal. The fix is to enter terminal monitor in the privileged EXEC prompt on the VTY session. This command enables forwarding of console/syslog/debug messages to the current VTY session. To stop this forwarding: terminal no monitor. Note: this setting applies only to the current session and resets when the session ends.

6. `debug ip ospf adj` output shows: "Nbr 10.1.1.2 MTU mismatch! local: 1500, nbr: 1400". What is the root cause and what is the fix?

A. The OSPF process ID is different on each router — change both to the same process ID B. The OSPF area IDs do not match — fix the area configuration on one router C. The routing protocols are different — one router runs OSPF, the other runs EIGRP D. The interface MTU values are different on the two OSPF neighbours — one is 1500 bytes, the other is 1400 bytes. OSPF exchanges the MTU during DBD packets and refuses to form an adjacency if they mismatch. Fix: either set both interfaces to the same MTU, or configure ip ospf mtu-ignore on one interface to bypass the MTU check.

Correct answer is D. During the OSPF adjacency formation process, routers exchange Database Description (DBD) packets. Each DBD packet includes the sender's interface MTU. When the receiving router compares this value against its own interface MTU, a mismatch causes the adjacency to get stuck in EXSTART state and eventually fail. This is a very common OSPF problem, especially on links where one end is a Cisco device with default MTU 1500 and the other end is a device with a different MTU (tunnel interfaces, some vendor equipment, GRE tunnel overhead). The correct permanent fix is to make both interface MTUs match. The workaround is ip ospf mtu-ignore — this tells OSPF to ignore the MTU check and form the adjacency anyway (risk: actual data plane fragmentation may still occur if frames exceed the smaller MTU).

7. `debug crypto isakmp` output shows "AUTHENTICATION_FAILED" when a site-to-site IPsec VPN is being established. What is the root cause and fix?

A. The pre-shared keys on the two VPN peers do not match. Both ends must have identical pre-shared keys in their crypto isakmp key configuration. Verify and correct the key on both devices. B. The ISAKMP transform set encryption algorithms are mismatched C. UDP 500 is being blocked by a firewall between the VPN peers D. The crypto map is applied to the wrong interface

Correct answer is A. "AUTHENTICATION_FAILED" in IKE Phase 1 (ISAKMP) debug output is the definitive indicator that the pre-shared key authentication has failed — both peers agreed on the ISAKMP policy (encryption, hash, DH group) but when they attempted to authenticate each other's identity using the pre-shared key, the key did not match. This is caused by a typo in the key on one or both sides, or by the correct key being associated with the wrong peer IP address. Fix: carefully verify the exact key string on both routers — keys are case-sensitive and trailing spaces cause failures. Policy mismatch produces "atts are not acceptable" rather than "AUTHENTICATION_FAILED". A blocked UDP 500 would prevent the IKE session from starting at all (no debug output would appear). See: IPsec VPN

8. Which command would an engineer run to see real-time output whenever routes are added to or removed from the IP routing table, for example to diagnose a route that keeps disappearing?

A. debug ip packet B. debug ip ospf events C. debug ip routing — this command generates output every time a route is installed or removed from the routing table, showing the route prefix, next-hop, protocol, metric, and timestamp of each change. D. debug ip rip

Correct answer is C.

debug ip
                  routing

is the go-to command when routes are mysteriously appearing and disappearing. It outputs a line every time the routing table (RIB — Routing Information Base) is modified: "RT: add 10.20.0.0/24 via 172.16.0.2, ospf metric [110/2]" when a route is installed, and "RT: del 10.20.0.0/24 via 172.16.0.2, ospf metric [110/2]" when it is removed. With timestamps enabled, you can see exactly when routes are changing and correlate with interface events or protocol changes. If you see the same route alternating between "add" and "del" rapidly, that is route flapping — and the protocol source (ospf, eigrp, etc.) in the output tells you which protocol to investigate next.

9. Why is `service timestamps debug datetime msec` considered essential before running any debug command?

A. It reduces the CPU impact of debug by rate-limiting output to one message per millisecond B. Without timestamps, debug output lines have no time reference — events cannot be correlated with each other, with syslog messages, or with user-reported incident times. With millisecond timestamps, the exact sequence and timing of every event is visible, making root cause analysis possible. C. It enables debug output to be sent to a syslog server automatically D. It enables debug output on VTY sessions instead of only the console

Correct answer is B. By default, Cisco IOS debug output is displayed without time information — you see the event but not when it happened. This makes it impossible to answer critical questions: Did the OSPF adjacency drop before or after the interface error? How many milliseconds elapsed between the ISAKMP authentication failure and the retry? Was the route removed at the same moment the interface went down? service timestamps debug datetime msec localtime prepends every debug line with the full date, time, and milliseconds, enabling precise event correlation. The msec keyword is important for fast-moving events — many protocol events happen in sub-second windows where second-level granularity is insufficient. This should always be configured before any debug session.

10. Before running any debug command on a production router, what should an engineer check first, and which command provides this information?

A. Check that logging is enabled — show logging B. Check that the interface is up — show ip interface brief C. Check that no other debugs are running — show debug D. Check the current CPU utilisation with show processes cpu sorted. If the CPU is already high (above 70–80%), any debug command risks pushing it to 100% and causing a packet-forwarding outage. Also check show debug to confirm no stray debugs are already consuming CPU.

Correct answer is D. The pre-debug CPU check is a critical safety step that many engineers skip, leading to avoidable outages. show processes cpu sorted displays current CPU utilisation sorted by process — it shows the 5-second, 1-minute, and 5-minute CPU averages, plus which processes are consuming the most CPU. If the CPU is already at 85% due to a routing table calculation, adding a debug command will consume the remaining 15% and cause the router to starve normal forwarding processes. A CPU below 50% generally has headroom for a carefully filtered debug. Also run show debug first to confirm that a previous engineer has not left a debug running — finding an existing stray debug (possibly from days ago) explains why the router might already be under stress.

← Back to Home