debug ip packet – Real-Time Packet Tracing on Cisco Routers

1. What Is `debug ip packet`?

debug ip packet is a Cisco IOS privileged EXEC command that enables real-time monitoring of IP packets as they are processed by a router's CPU. For every packet that the router processes in software (rather than forwarding directly in hardware), the command prints a one-line log entry showing the source, destination, interfaces, packet length, and the router's forwarding decision.

It is one of the most powerful troubleshooting tools in a network engineer's toolkit — and also one of the most dangerous on production equipment. When used correctly with ACL filters, it can pinpoint exactly why a packet is being dropped, denied by an ACL, or failing to route — in real time, without waiting for log files or relying on SNMP polling.

Critical safety note: debug ip packet without a filter on a busy production router can consume 100% of the router's CPU within seconds, dropping packets, crashing BGP/OSPF sessions, and potentially causing a complete network outage. Always use an ACL filter and have undebug all ready to type instantly.

2. Why `debug ip packet` Only Sees Process-Switched Packets

This is one of the most important and least understood aspects of debug ip packet: it only shows packets handled by the router's CPU in process switching mode. It does not show packets forwarded by CEF (Cisco Express Forwarding) in hardware.

Cisco Packet Forwarding Paths

  Packet arrives on interface
          │
          ▼
  CEF (hardware/fast-path) available for this destination?
          │
     Yes ─┤─ No
          │        │
          ▼        ▼
  CEF forwards  Process switching:
  in hardware   packet sent to CPU
  (NOT seen     for routing decision
  by debug)     ← debug ip packet
                  sees this

CEF is enabled by default on all modern Cisco platforms and handles the vast majority of forwarded traffic entirely in hardware at line rate. debug ip packet only intercepts packets that fall through to the CPU — typically:

Packets destined for the router itself (management traffic — SSH, Telnet, OSPF, BGP, ICMP to a router interface)
Packets with IP options set (e.g., Record Route, Timestamp)
Packets that fail CEF lookup (e.g., destination not in FIB — genuinely unroutable)
Packets on interfaces where CEF is disabled
ARP packets and other control-plane traffic

Why this matters for troubleshooting: If you are trying to debug why transit traffic (traffic passing through the router, not to the router) is being dropped, and CEF is enabled on that interface, debug ip packet may show nothing — because CEF is dropping the packet in hardware before the CPU ever sees it. To debug transit traffic being dropped by CEF, use show ip cef to inspect the FIB, or temporarily disable CEF on the interface with no ip cef (with extreme caution on production).

3. Command Syntax — Full Reference

Command	Effect	When to Use
`debug ip packet`	Displays all process-switched IP packets — extremely dangerous unfiltered	Lab only, with near-zero traffic. Never on production.
`debug ip packet <acl-number>`	Shows only packets matching the specified ACL — recommended for all use	Production troubleshooting with a tight ACL filter limiting to specific src/dst
`debug ip packet <acl> detail`	Adds Layer 4 protocol, flags, TTL, checksum to each line's output	When you need to inspect TCP flags, TTL, or protocol-level detail
`undebug all`	Stops all active debug processes immediately	First command when debug output floods the console
`no debug all`	Identical to `undebug all`	Alternative syntax; same effect
`no debug ip packet`	Stops only IP packet debugging — other debug sessions remain	When running multiple debug sessions and only need to stop this one
`show debugging`	Lists all currently active debug sessions	Before starting a debug session, confirm no other debug is already running
`terminal monitor`	Enables debug output on a remote SSH/Telnet session (off by default)	When connecting remotely — required or you will see no debug output
`terminal no monitor`	Disables debug output on the current session	After finishing — prevents future debug from unexpected sessions

terminal monitor is required for SSH/Telnet sessions. When you connect to a router remotely via SSH, debug output is directed to the console port by default — your SSH session sees nothing. You must run terminal monitor first to redirect debug output to your session. When finished, run terminal no monitor.

4. Filtering Debug Output with ACLs

The ACL filter passed to debug ip packet uses the ACL's permit/deny logic purely as a filter selector — it does not affect actual traffic forwarding. Packets matching a permit statement in the ACL are included in the debug output; packets matching deny are excluded. The actual forwarding decision is completely unaffected by this ACL.

Critical distinction: The ACL used with debug ip packet is a display filter only. It does not block, permit, or modify any traffic on the router. It only controls which packets the debug engine shows you. The same ACL can be used simultaneously as a display filter and as a separate traffic filter — they are independent.

Example 1 — Debug Only ICMP (Ping) Traffic

Router(config)# access-list 100 permit icmp any any
Router# debug ip packet 100

! Output: only ICMP packets visible
IP: s=192.168.1.10 (Gi0/0), d=10.0.0.1 (Gi0/1), len 100, sending
IP: s=10.0.0.1 (Gi0/1), d=192.168.1.10 (Gi0/0), len 100, sending

Example 2 — Debug Specific Source to Specific Destination

! Create a precise filter: only host 192.168.1.10 talking to host 10.0.0.5
Router(config)# access-list 101 permit ip host 192.168.1.10 host 10.0.0.5
Router(config)# access-list 101 permit ip host 10.0.0.5 host 192.168.1.10
Router(config)# end
Router# debug ip packet 101

! This filter catches both directions of the conversation

Example 3 — Debug All Traffic on a Specific Subnet

! Debug all packets from the 10.1.1.0/24 subnet
Router(config)# access-list 102 permit ip 10.1.1.0 0.0.0.255 any
Router(config)# end
Router# debug ip packet 102 detail

Example 4 — Debug TCP Traffic on Specific Port

! Debug only TCP port 80 (HTTP) traffic
Router(config)# access-list 103 permit tcp any any eq 80
Router(config)# end
Router# debug ip packet 103 detail
! "detail" adds TCP flags, sequence numbers, TTL to output

Make the filter as specific as possible. A filter with a narrow host-to-host match generates far less output than a subnet-level filter. On a router carrying 1 Gbps of traffic, even a "permit ip host A host B" filter may produce hundreds of lines per second if those hosts are actively communicating. Start with the most specific filter possible.

5. Interpreting Debug Output — Complete Field Reference

Standard Output Format (without `detail`)

IP: s=192.168.1.10 (GigabitEthernet0/0), d=10.0.0.5 (GigabitEthernet0/1), len 84, sending
IP: s=10.0.0.5 (GigabitEthernet0/1), d=192.168.1.10 (GigabitEthernet0/0), len 84, sending
IP: s=172.16.1.1 (GigabitEthernet0/2), d=10.0.0.9, len 60, unroutable
IP: s=192.168.2.5 (GigabitEthernet0/0), d=8.8.8.8 (GigabitEthernet0/1), len 52, ACL deny

Field-by-Field Explanation

Field	Meaning	Notes
`s=<IP>`	Source IP address of the packet	The originating host or router
`(interface)` after s=	Interface on which this packet arrived	The ingress interface — where the packet came in
`d=<IP>`	Destination IP address of the packet	Where the packet is trying to go
`(interface)` after d=	Egress interface — where the router would send it	Only present if the router found a route; absent if unroutable
`len <N>`	IP packet length in bytes (includes IP header + payload)	Helps identify if fragmentation is involved
`sending`	Packet was successfully routed and forwarded	The expected, normal result for routable packets
`encapsulation failed`	Route exists but next-hop ARP resolution failed	Indicates an ARP problem on the outgoing interface
`unroutable`	No route to the destination — routing table lookup failed	Check `show ip route <dest>` — missing route or wrong subnet
`ACL deny`	Packet was denied by an access-list applied to an interface	Check applied ACLs with `show ip interface`
`input ACL check`	Packet hit an inbound ACL — may be permitted or denied	Shows ACL processing is occurring on the ingress interface
`no buffer`	Router buffer is full — packet dropped due to congestion	Indicates potential interface queue issue or high load

Detailed Output Format (with `detail` keyword)

Router# debug ip packet 101 detail

IP: s=192.168.1.10 (Gi0/0), d=10.0.0.5 (Gi0/1), len 84,
    sending full packet
IP: tableid=0, s=192.168.1.10 (Gi0/0), d=10.0.0.5 (Gi0/1), routed via FIB
ICMP type=8, code=0           ← Echo request (ping)

IP: s=192.168.2.1 (Gi0/2), d=10.1.1.1 (Gi0/1), len 52,
    sending full packet
TCP src=52341, dst=80, seq=123456789, ack=0, win=65535 SYN
                              ↑ TCP flags, port numbers, sequence numbers

Additional Fields Visible with `detail`

Additional Field	Meaning
`tableid=N`	Routing table / VRF ID (0 = global table)
`ICMP type=N, code=N`	ICMP type and code values (type 8 = echo request, type 0 = echo reply)
`TCP src=, dst=`	TCP source and destination port numbers
`seq=, ack=`	TCP sequence and acknowledgement numbers
`SYN / ACK / FIN / RST`	TCP flags present in the segment
`ttl=N`	IP Time-to-Live value — reveals if TTL is expiring

6. Performance Risk — Why This Command Is Dangerous

debug ip packet forces the router to interrupt its normal forwarding process and generate a log message for every matching packet. On a high-traffic router, this creates an enormous CPU burden:

A router forwarding 100,000 packets per second with an unfiltered debug enabled generates 100,000 log messages per second — all processed by the CPU.
The router must generate, format, and output each message to the console or syslog buffer in addition to all its normal routing functions.
This can spike CPU utilisation to 100%, causing OSPF/BGP neighbour timeouts, packet drops, and in extreme cases a router crash or reload.

Risk Escalation by Scenario

Scenario	Risk Level	Why
Lab router, no production traffic	Low	Minimal traffic to generate debug output
Production router, tight host-to-host ACL filter	Low-Medium	Only packets between two hosts matched; manageable if traffic is low
Production router, subnet-level ACL filter	Medium-High	Potentially thousands of packets per second matched depending on traffic
Production router, no filter (unfiltered)	CRITICAL	All process-switched packets logged; immediate risk of outage
Production router, CEF disabled on an interface	CRITICAL	All traffic on that interface is process-switched; debug sees everything

Emergency stop: If your console is flooding with debug output and you are losing control of the router, type undebug all immediately. If console output is so fast you cannot type, press Ctrl+C to interrupt or wait for the console to catch up. On some platforms, typing u all (abbreviated) also works.

7. Where Debug Output Goes — Logging Destinations

Debug output follows the IOS logging configuration. By default, debug messages go to the console port only. In a production environment, sending debug output to a syslog server (rather than the console) is far safer as it doesn't block the router's console process.

! Check current logging configuration
Router# show logging

! Send debug output to syslog server instead of console
Router(config)# logging host 10.10.10.50
Router(config)# logging trap debugging
Router(config)# no logging console                    ! Reduces console risk
Router(config)# logging buffered 64000 debugging      ! Also buffer locally

! View the buffered log after debug
Router# show logging

Logging Destinations Summary

Destination	Command	Impact on Router	Notes
Console	`logging console debugging`	High — blocking I/O on the console process	Default; most dangerous for high-volume debug
VTY (SSH/Telnet)	`terminal monitor`	Medium	Must be enabled per session; doesn't affect other sessions
Syslog server	`logging host <IP>`	Low	UDP send; non-blocking; preferred for production use
Local buffer	`logging buffered <size>`	Low-Medium	Stores in RAM; review later with `show logging`

8. Step-by-Step Troubleshooting Scenarios

Scenario 1 — Diagnosing Why a Host Cannot Reach a Destination

Situation: A user at 192.168.1.10 cannot reach the server at 10.0.0.5. Pings time out. Basic show commands haven't revealed the issue.

! Step 1: Check if a route exists first (safer, always do this before debug)
Router# show ip route 10.0.0.5
! If no route → fix the routing issue first; no need for debug

! Step 2: Create a precise ACL filter
Router(config)# access-list 101 permit ip host 192.168.1.10 host 10.0.0.5
Router(config)# access-list 101 permit ip host 10.0.0.5 host 192.168.1.10

! Step 3: Check what debug sessions are already running
Router# show debugging
! Ensure none are active before starting a new one

! Step 4: Enable filtered debug
Router# debug ip packet 101

! Step 5: Generate traffic from 192.168.1.10 (have user ping or telnet)

! Step 6: Observe output
! Case A — unroutable:
IP: s=192.168.1.10 (Gi0/0), d=10.0.0.5, len 84, unroutable
! → Fix: Route missing or wrong. Check show ip route 10.0.0.5

! Case B — ACL deny:
IP: s=192.168.1.10 (Gi0/0), d=10.0.0.5 (Gi0/1), len 84, ACL deny
! → Fix: Check interface ACLs with show ip interface Gi0/0 and Gi0/1

! Case C — encapsulation failed:
IP: s=192.168.1.10 (Gi0/0), d=10.0.0.5 (Gi0/1), len 84, encapsulation failed
! → Fix: ARP for next-hop failed. Check show arp and connectivity to next-hop

! Case D — no debug output at all:
! → CEF is forwarding the packets (not process-switched). Check show ip cef 10.0.0.5

! Step 7: ALWAYS stop debug immediately after
Router# undebug all

Scenario 2 — Verifying ACL Permit/Deny Behaviour

! ACL 120 is applied to Gi0/0. Need to verify HTTP traffic is being denied correctly.
Router(config)# access-list 115 permit tcp any any eq 80    ! Debug filter only
Router(config)# end
Router# debug ip packet 115

! Expected output if ACL 120 is correctly denying HTTP:
IP: s=10.1.1.5 (Gi0/0), d=203.0.113.10 (Gi0/1), len 64, ACL deny

! If instead you see:
IP: s=10.1.1.5 (Gi0/0), d=203.0.113.10 (Gi0/1), len 64, sending
! → HTTP is NOT being denied — check ACL 120 configuration and application

Router# undebug all

Scenario 3 — Detecting a Routing Loop

! Symptom: Packets never arrive but no ACL deny is seen.
! Debug shows packets appearing on multiple interfaces repeatedly.
Router# debug ip packet 101

! Routing loop output pattern:
IP: s=192.168.1.10 (Gi0/0), d=10.5.5.5 (Gi0/1), len 84, sending
IP: s=192.168.1.10 (Gi0/1), d=10.5.5.5 (Gi0/0), len 83, sending  ! TTL decremented
IP: s=192.168.1.10 (Gi0/0), d=10.5.5.5 (Gi0/1), len 82, sending  ! Loop!

! Packet bouncing between Gi0/0 and Gi0/1 with TTL decrementing toward 0
! → Fix: Check routing table for inconsistent routes; check for static route loops

Router# undebug all

9. debug ip packet vs. show Commands — When to Use Which

Feature	`debug ip packet`	`show ip route` / `show ip cef`
Information type	Live, real-time packet-level events as they happen	Static snapshot of routing/forwarding table state
CPU impact	High — can cause outage if unfiltered on busy router	Very low — single table query, safe on production
Shows actual packet fate	Yes — shows "unroutable", "ACL deny", "sending" per packet	No — shows what the router would do in theory
Useful for intermittent issues	Yes — catches packets in real time including transient drops	Limited — may not capture intermittent events
CEF-forwarded traffic visibility	No — CEF bypass means packets not seen	Yes — show ip cef shows the FIB used by CEF
Security risk	High — reveals source/destination IPs, protocols in plaintext log	Low — shows routing table entries only
Safe for production	Only with tight ACL filter, brief use, and immediate stop	Always safe
Best used for	Confirming actual packet fate; diagnosing drops you can't explain from routing table	First step — always check routes and CEF before using debug

Troubleshooting hierarchy: Always start with show commands (show ip route, show ip interface, show ip cef, show access-lists). Use debug ip packet only when show commands don't explain the problem and you need to observe actual packet fate in real time.

10. Alternatives and Complementary Tools

Tool	What It Does	Advantage over debug ip packet
`show ip route`	Displays the routing table — what the router would do with each destination	Zero performance impact; always first step
`show ip cef`	Shows the Forwarding Information Base (FIB) used by CEF — the actual hardware forwarding table	Shows what CEF (not debug) sees; confirms FIB entry for a destination
`show ip interface <int>`	Shows ACLs applied to an interface and their direction	Reveals ACL misapplication without needing live traffic
`show access-lists`	Shows ACL entries with hit counters	Hit counter increments confirm traffic is matching specific ACEs
`traceroute`	Shows the hop-by-hop path a packet takes through the network	Identifies exactly where a packet stops routing without debug
Cisco IPSLA	Automated probes that continuously test reachability and performance	Non-intrusive continuous monitoring without manual debug
Wireshark / tcpdump (on connected hosts)	Full packet capture with payload at the endpoint	Zero impact on router; shows full packet contents including application data
Cisco Embedded Packet Capture (EPC)	Router-based packet capture that saves packets to a PCAP file	Captures at hardware level without process-switching overhead; Wireshark-compatible

Cisco Embedded Packet Capture (EPC) — The Safer Alternative

EPC allows a Cisco router to capture actual packet data directly to a PCAP file without the CPU overhead of debug ip packet. The capture can later be downloaded and opened in Wireshark.

! Define what to capture (ACL 101 as filter)
Router(config)# ip access-list extended EPC-FILTER
Router(config-ext-nacl)# permit ip host 192.168.1.10 host 10.0.0.5
Router(config-ext-nacl)# end

! Attach capture to interface and start
Router# monitor capture MYCAP interface GigabitEthernet0/0 both
Router# monitor capture MYCAP access-list EPC-FILTER
Router# monitor capture MYCAP start

! ... generate traffic ...

! Stop and export
Router# monitor capture MYCAP stop
Router# monitor capture MYCAP export tftp://10.10.10.50/mycap.pcap

! View summary on router
Router# show monitor capture MYCAP buffer brief

See: Troubleshooting Routing Issues | show ip route Command | show ip cef Command

11. Security and Privacy Considerations

Debug output contains sensitive data: Every line of debug ip packet output reveals source and destination IP addresses, the protocols in use, and the router's security decisions. This output must never be shared publicly or left in log files without access controls.
Restrict privilege level access: The debug command family requires privilege level 15. Ensure only authorised engineers have level-15 access and that all debug usage is logged via AAA accounting.
Clear logging buffer after use: Debug output stored in the router's logging buffer (show logging) should be cleared with clear logging after the troubleshooting session is complete.
Don't forward debug to unsecured syslog: If logging to a syslog server, ensure the syslog connection uses secure transport and the syslog server has restricted access — debug messages flowing to an open syslog server are visible to anyone who can reach that server.
Document debug usage: In regulated environments (PCI-DSS, HIPAA), all privileged command usage including debug commands should be recorded in an audit trail via TACACS+ command accounting.

12. Safe Debug Checklist

Follow this sequence every time before running debug ip packet on any router:

Exhaust show commands first — check show ip route, show ip interface, show access-lists before resorting to debug.
Assess traffic volume — estimate how many packets per second will match your filter. If it could be thousands per second, tighten the ACL.
Create the tightest possible ACL filter — host-to-host is better than subnet-level. The filter goes in before you run the command.
Check existing debug sessions with show debugging — never layer multiple debug commands.
Enable terminal monitor if connecting via SSH/Telnet.
Run the filtered debug: debug ip packet <acl>
Generate a small amount of test traffic — one ping, not a continuous flood.
Observe and record — note the status field (sending, unroutable, ACL deny).
Stop debug immediately: undebug all — even if you want more data. Re-run for a second test if needed.
Remove the debug ACL from the config if it was created solely for debugging.

13. Key Points & Exam Tips

debug ip packet shows process-switched packets only — CEF-forwarded traffic is invisible to it.
Always filter with an ACL: debug ip packet <acl-number> — the ACL is a display filter only, it does not affect actual packet forwarding.
The detail keyword adds Layer 4 info: TCP/UDP ports, TCP flags, TTL.
Key status codes: sending (forwarded), unroutable (no route), ACL deny (blocked by access-list), encapsulation failed (ARP failure).
undebug all = no debug all — stops all debug processes immediately.
terminal monitor is required on SSH/Telnet sessions to see debug output.
Unfiltered debug on a busy router = CPU spike = dropped routing protocols = outage risk.
Always try show ip route, show ip cef, and show access-lists before using debug.
Cisco Embedded Packet Capture (EPC) is a safer alternative — captures packets at hardware level without process-switching overhead.
Debug output reveals sensitive network information — restrict access and clear buffers after use.

14. debug ip packet Quiz

1. A network engineer runs `debug ip packet` on a production router to investigate why a specific host cannot reach a server. No filter ACL is applied. Within seconds the console floods with output and the router's CPU reaches 99%. What is the most likely immediate consequence if the engineer does not stop the debug?

A. The routing table is cleared and all routes are lost B. OSPF and BGP neighbour timers expire, adjacencies drop, routes are withdrawn, causing a network-wide outage C. The debug automatically limits itself to 100 packets and stops D. Interface counters are reset and traffic resumes normally

Correct answer is B. When the router's CPU is consumed by debug processing, the CPU cannot service routing protocol hello/keepalive timers. OSPF dead intervals (typically 40 seconds) and BGP holddown timers expire, causing adjacencies to drop and routes to be withdrawn. This propagates outward — other routers in the topology remove routes learned from this router, potentially causing network-wide convergence and traffic loss. The router does not automatically limit debug output — it runs until explicitly stopped with undebug all.

2. An engineer runs `debug ip packet 101` with a filter matching traffic between two hosts. She generates pings from the source host but sees absolutely no debug output. The hosts are communicating successfully (pings succeed). What is the most likely explanation?

A. The ACL 101 is incorrectly configured and needs to be reapplied B. The terminal monitor command was not run and output is going to the console port only C. Debug requires privilege level 16 which the engineer does not have D. CEF is forwarding the packets in hardware — process switching is not involved, so debug ip packet sees nothing

Correct answer is D. debug ip packet only intercepts packets that are process-switched (handled by the router CPU). CEF (Cisco Express Forwarding) forwards packets directly in hardware using the FIB — these never reach the CPU and are therefore invisible to debug. Since pings are succeeding, CEF clearly has a valid FIB entry. To verify the CEF path, use

show ip cef
                  <dest>

. To force process switching (lab only), run no ip cef on the interface, but never do this in production.

3. The following debug output appears repeatedly:
`IP: s=192.168.1.10 (Gi0/0), d=10.5.5.5 (Gi0/1), len 84, sending`
`IP: s=192.168.1.10 (Gi0/1), d=10.5.5.5 (Gi0/0), len 83, sending`
What networking issue does this indicate?

A. An ACL is denying the packet on alternate interfaces B. Load balancing is distributing packets across two equal-cost paths C. A routing loop — the same packet is bouncing between Gi0/0 and Gi0/1 with the TTL decrementing each hop until it reaches 0 D. The router is performing NAT translation between the two interfaces

Correct answer is C. The diagnostic indicators are: the same source/destination pair appearing on alternating interfaces (Gi0/0 then Gi0/1), and the packet length decreasing from 84 to 83 bytes (the IP TTL field in the header is being decremented at each router hop). This is a classic routing loop signature — the router has a route for 10.5.5.5 pointing toward Gi0/1, but the next-hop router has a route pointing back through Gi0/0. The packet bounces until TTL=0, then is dropped with an ICMP Time Exceeded message back to the source.

4. An engineer is connected via SSH to a router and runs `debug ip packet 101` but sees no output. `show debugging` confirms debug is active. What is the most likely cause?

A. terminal monitor has not been run — debug output is being sent to the console port but not to the SSH session B. SSH sessions cannot receive debug output on Cisco routers C. The ACL filter is blocking the debug output from being displayed D. The logging level must be set to level 7 before debug output appears on SSH

Correct answer is A. By default, IOS routes debug (and syslog) messages to the console port only. SSH and Telnet (VTY) sessions do not receive these messages unless the engineer runs terminal monitor in that specific session. This is a very common oversight — the debug appears to do nothing from an SSH session when in reality it is flooding the console port of the router (which may be unmanned). Always run terminal monitor before debug when connected via SSH, and terminal no monitor when finished.

5. A debug output line shows:
`IP: s=10.1.1.5 (Gi0/0), d=172.16.10.20 (Gi0/1), len 52, encapsulation failed`
What does this status indicate and what should be investigated?

A. The packet was denied by an ACL on Gi0/1 B. The packet's destination is not in the routing table C. The route exists (Gi0/1 is the egress), but ARP resolution for the next-hop failed — investigate ARP table and next-hop reachability on Gi0/1 D. The packet's MTU exceeds the interface MTU and fragmentation was required but DF bit is set

Correct answer is C. "Encapsulation failed" means the router found a route (the egress interface Gi0/1 is shown in the output) but could not build the Layer 2 frame because ARP resolution for the next-hop IP address failed. The router knows where to send the packet logically (which interface) but cannot resolve the MAC address of the next hop to put in the Ethernet frame. Investigate with: show arp (check if next-hop has an ARP entry), ping <next-hop> (check basic connectivity to next-hop), and show ip interface Gi0/1 (check interface is up/up).

6. Why does the ACL passed to `debug ip packet <acl>` NOT affect actual packet forwarding on the router?

A. The debug ACL overrides any applied interface ACLs, taking precedence for forwarding decisions B. The debug ACL is a display filter only — it controls which packets the debug engine shows you, not whether packets are forwarded or dropped C. The ACL must first be applied to an interface with ip access-group for it to affect forwarding D. Debug ACLs only work on extended ACLs numbered 100–199, which are not applied to interfaces

Correct answer is B. The ACL number passed to debug ip packet is purely a debug output filter — it tells the debug engine which packets to report on. Packets matching the ACL's permit statements appear in debug output; those matching deny are silently excluded from debug output. The ACL does not block, permit, or in any way alter the forwarding of those packets. You can use the same ACL number simultaneously as a debug filter and as an interface ACL — they are entirely independent functions.

7. An engineer needs to debug TCP traffic on port 443 (HTTPS) between two hosts, and also needs to see TCP flags and port numbers in the output. Which command sequence achieves this?

A. debug ip packet followed by debug ip tcp B. access-list 110 permit tcp any any then debug ip packet 110 C. debug ip packet verbose port 443 D. access-list 110 permit tcp host A host B eq 443 then debug ip packet 110 detail

Correct answer is D. Two elements are required: (1) An extended ACL matching TCP port 443 between the specific hosts — filtering on both hosts and port 443 minimises output volume. Using "any any" as in option B would match all TCP traffic, potentially flooding the console. (2) The detail keyword after the ACL number — this adds TCP-specific information to each debug line including source/ destination ports, sequence numbers, and TCP flags (SYN, ACK, FIN, RST). Without detail, only the basic IP header fields are shown.

8. A network engineer needs to capture actual packet payloads from a Cisco router for deep analysis in Wireshark, without the CPU overhead of `debug ip packet`. Which Cisco IOS feature should they use?

A. Embedded Packet Capture (EPC) — captures packets to a PCAP file at the hardware level and exports via TFTP for Wireshark analysis B. debug ip packet detail with logging redirected to a file C. SNMP v3 packet capture trap sent to a management server D. show ip packet-capture built into IOS show commands

Correct answer is A. Cisco Embedded Packet Capture (EPC) allows a router to capture packets directly at the hardware level — attaching a capture session to an interface, filtering with an ACL, then exporting the capture as a standard PCAP file that Wireshark can read. Unlike debug ip packet, EPC does not require process switching — it captures at the forwarding hardware level. Commands: monitor capture <name> interface <int> both to set up, monitor capture <name> start/stop to control, and monitor capture <name> export tftp://... to save the file.

9. During a troubleshooting session, `debug ip packet 101` shows packets with status `unroutable` for destination 172.20.0.10, but `show ip route 172.20.0.10` shows a valid route via 10.1.1.1 on Gi0/1. Why might debug show unroutable when a route exists?

A. The routing table only shows static routes; debug uses a different lookup table B. The ACL filter 101 is blocking the route lookup process C. The CEF FIB may not be in sync with the routing table — the route is in the RIB but not yet installed in the FIB, or CEF is disabled and the process-switching path is using a different (stale) lookup D. Debug ip packet always shows unroutable as its first output before confirming the route

Correct answer is C. The routing table (RIB — Routing Information Base) shown by show ip route may not be fully synchronised with the CEF FIB (Forwarding Information Base) used for actual forwarding. This can happen during rapid routing changes, after a route flap, or if CEF is experiencing a stale entry. The debug is watching process-switched packets which use the FIB — if the FIB doesn't have the entry yet (or the entry is stale), it reports unroutable even though the RIB shows a route. Verify with show ip cef 172.20.0.10 and consider clear ip cef or clear ip route * to resync.

10. An engineer has finished debugging and the console is still showing a small trickle of debug output. She runs `no debug ip packet` but output continues. What is the most likely cause and correct fix?

A. The router must be rebooted to fully stop debug processes B. Another debug session is still active —

no debug ip
                  packet

stops only IP packet debug; run undebug all to stop all active debug processes, and verify with show debugging C. The logging buffer is replaying stored messages — run clear logging to stop output D. The ACL filter is preventing the debug stop command from taking effect

Correct answer is B. no debug ip packet stops only the IP packet debugging process — if any other debug sessions were started (e.g., debug ip routing, debug ip ospf events, debug spanning-tree), they remain active and continue producing output. The solution is undebug all (or the equivalent no debug all), which stops every active debug process simultaneously. After running it, verify with show debugging — the output should be empty or show only disabled sessions. This is why undebug all is always the recommended stop command.

← Back to Home

debug ip packet – Real-Time Packet Tracing on Cisco Routers

1. What Is debug ip packet?

2. Why debug ip packet Only Sees Process-Switched Packets

Cisco Packet Forwarding Paths

3. Command Syntax — Full Reference

4. Filtering Debug Output with ACLs

Example 1 — Debug Only ICMP (Ping) Traffic

Example 2 — Debug Specific Source to Specific Destination

Example 3 — Debug All Traffic on a Specific Subnet

Example 4 — Debug TCP Traffic on Specific Port

5. Interpreting Debug Output — Complete Field Reference

Standard Output Format (without detail)

Field-by-Field Explanation

Detailed Output Format (with detail keyword)

Additional Fields Visible with detail

6. Performance Risk — Why This Command Is Dangerous

Risk Escalation by Scenario

7. Where Debug Output Goes — Logging Destinations

Logging Destinations Summary

8. Step-by-Step Troubleshooting Scenarios

Scenario 1 — Diagnosing Why a Host Cannot Reach a Destination

Scenario 2 — Verifying ACL Permit/Deny Behaviour

Scenario 3 — Detecting a Routing Loop

9. debug ip packet vs. show Commands — When to Use Which

10. Alternatives and Complementary Tools

Cisco Embedded Packet Capture (EPC) — The Safer Alternative

11. Security and Privacy Considerations

12. Safe Debug Checklist

13. Key Points & Exam Tips

14. debug ip packet Quiz

2. An engineer runs debug ip packet 101 with a filter matching traffic between two hosts. She generates pings from the source host but sees absolutely no debug output. The hosts are communicating successfully (pings succeed). What is the most likely explanation?

3. The following debug output appears repeatedly: IP: s=192.168.1.10 (Gi0/0), d=10.5.5.5 (Gi0/1), len 84, sending IP: s=192.168.1.10 (Gi0/1), d=10.5.5.5 (Gi0/0), len 83, sending What networking issue does this indicate?

4. An engineer is connected via SSH to a router and runs debug ip packet 101 but sees no output. show debugging confirms debug is active. What is the most likely cause?

5. A debug output line shows: IP: s=10.1.1.5 (Gi0/0), d=172.16.10.20 (Gi0/1), len 52, encapsulation failed What does this status indicate and what should be investigated?

6. Why does the ACL passed to debug ip packet <acl> NOT affect actual packet forwarding on the router?

7. An engineer needs to debug TCP traffic on port 443 (HTTPS) between two hosts, and also needs to see TCP flags and port numbers in the output. Which command sequence achieves this?

8. A network engineer needs to capture actual packet payloads from a Cisco router for deep analysis in Wireshark, without the CPU overhead of debug ip packet. Which Cisco IOS feature should they use?

9. During a troubleshooting session, debug ip packet 101 shows packets with status unroutable for destination 172.20.0.10, but show ip route 172.20.0.10 shows a valid route via 10.1.1.1 on Gi0/1. Why might debug show unroutable when a route exists?

10. An engineer has finished debugging and the console is still showing a small trickle of debug output. She runs no debug ip packet but output continues. What is the most likely cause and correct fix?

1. What Is `debug ip packet`?

2. Why `debug ip packet` Only Sees Process-Switched Packets

Standard Output Format (without `detail`)

Detailed Output Format (with `detail` keyword)

Additional Fields Visible with `detail`

2. An engineer runs `debug ip packet 101` with a filter matching traffic between two hosts. She generates pings from the source host but sees absolutely no debug output. The hosts are communicating successfully (pings succeed). What is the most likely explanation?

3. The following debug output appears repeatedly:
`IP: s=192.168.1.10 (Gi0/0), d=10.5.5.5 (Gi0/1), len 84, sending`
`IP: s=192.168.1.10 (Gi0/1), d=10.5.5.5 (Gi0/0), len 83, sending`
What networking issue does this indicate?

4. An engineer is connected via SSH to a router and runs `debug ip packet 101` but sees no output. `show debugging` confirms debug is active. What is the most likely cause?

5. A debug output line shows:
`IP: s=10.1.1.5 (Gi0/0), d=172.16.10.20 (Gi0/1), len 52, encapsulation failed`
What does this status indicate and what should be investigated?

6. Why does the ACL passed to `debug ip packet <acl>` NOT affect actual packet forwarding on the router?

8. A network engineer needs to capture actual packet payloads from a Cisco router for deep analysis in Wireshark, without the CPU overhead of `debug ip packet`. Which Cisco IOS feature should they use?

9. During a troubleshooting session, `debug ip packet 101` shows packets with status `unroutable` for destination 172.20.0.10, but `show ip route 172.20.0.10` shows a valid route via 10.1.1.1 on Gi0/1. Why might debug show unroutable when a route exists?

10. An engineer has finished debugging and the console is still showing a small trickle of debug output. She runs `no debug ip packet` but output continues. What is the most likely cause and correct fix?