There is a point in almost every difficult troubleshooting case where show commands stop being enough and I need to actually see the packets on the wire. Packet capture is, in my opinion, the single most valuable skill in a network engineer’s toolkit, because it removes guesswork entirely — you are looking at exactly what happened, not an interpretation of it. In this guide I am covering how I generate and analyze packet captures directly on Cisco devices, using both embedded capture tools and traditional SPAN-based approaches with Wireshark.
Networking Fundamentals: Why Capture on the Device Itself
Traditionally, packet capture meant configuring a SPAN (Switched Port Analyzer) session to mirror traffic to a port where a laptop running Wireshark was connected. That approach still has its place, but modern Cisco IOS-XE devices support Embedded Packet Capture (EPC), which lets you capture directly on the router or switch CPU/data path without any external hardware. This is enormously useful for remote sites, or any situation where you cannot easily get a laptop physically connected.
The tradeoff is that EPC has buffer size limits and can, in high-traffic scenarios, only capture a sample of what is actually crossing the interface, so understanding both methods and when to use each is important.
Method 1: SPAN/Mirror Port with External Capture
Configuring a Local SPAN Session
Switch(config)# monitor session 1 source interface GigabitEthernet1/0/5
Switch(config)# monitor session 1 destination interface GigabitEthernet1/0/24
This mirrors all traffic (by default, both directions) from the source interface to the destination interface, where I connect a laptop running Wireshark.
Configuring RSPAN for Remote Sites
When the device I need to monitor is not physically near my laptop, I use RSPAN, which mirrors traffic across the switched network using a dedicated RSPAN VLAN:
Switch(config)# vlan 999
Switch(config-vlan)# remote-span
Switch(config)# monitor session 1 source interface GigabitEthernet1/0/5
Switch(config)# monitor session 1 destination remote vlan 999
! On the switch where the laptop is connected:
Switch2(config)# monitor session 1 source remote vlan 999
Switch2(config)# monitor session 1 destination interface GigabitEthernet1/0/24
For traffic that needs to cross Layer 3 boundaries, ERSPAN (available on many platforms) encapsulates the mirrored traffic in GRE, allowing it to be sent to a capture point anywhere in the routed network.
Method 2: Embedded Packet Capture (EPC) on IOS-XE
EPC is my go-to method for quick, on-device captures without needing a SPAN session or physical access.
Basic Capture Setup
Router(config)# monitor capture CAP1 interface GigabitEthernet0/0/1 both
Router(config)# monitor capture CAP1 buffer size 10
Router(config)# monitor capture CAP1 match any
Starting and stopping the capture:
Router# monitor capture CAP1 start
Router# monitor capture CAP1 stop
Viewing Results Directly on the Device
Router# show monitor capture CAP1 buffer detail
This gives you a summarized packet-by-packet breakdown right in the CLI, which is often enough to confirm or rule out a hypothesis without needing to export anything.
Exporting to a PCAP File for Wireshark Analysis
For deeper analysis, I export the capture to a file and pull it into Wireshark:
Router# monitor capture CAP1 export flash:cap1.pcap
I then copy the file off the device (via SCP or TFTP) for analysis:
Router# copy flash:cap1.pcap scp://user@10.10.10.5/captures/cap1.pcap
Filtering Captures with Access Lists
Capturing “everything” on a busy interface fills the buffer instantly, so I always scope captures with an ACL matching the specific traffic I care about:
Router(config)# ip access-list extended CAPTURE-FILTER
Router(config-ext-nacl)# permit tcp host 10.1.1.10 host 10.2.2.20 eq 443
Router(config)# monitor capture CAP1 interface GigabitEthernet0/0/1 both
Router(config)# monitor capture CAP1 access-list CAPTURE-FILTER
Method 3: Packet Capture on Cisco ASA
The ASA has its own capture syntax, and I use it constantly when troubleshooting connectivity or VPN issues through the firewall:
ciscoasa# capture CAP1 interface outside match tcp host 10.1.1.10 host 203.0.113.5 eq 443
To view the capture:
ciscoasa# show capture CAP1
To export it for Wireshark analysis:
ciscoasa# copy /pcap capture:CAP1 tftp://10.10.10.5/cap1.pcap
One thing I always remember on the ASA specifically: because of its stateful firewall architecture, it is often useful to capture on both the ingress and egress interfaces simultaneously to see whether traffic is arriving but being dropped internally versus never arriving at all.
ciscoasa# capture CAP-IN interface inside match ip host 10.1.1.10 any
ciscoasa# capture CAP-OUT interface outside match ip host 10.1.1.10 any
If packets show up in CAP-IN but never in CAP-OUT, the ASA itself is dropping the traffic — at that point I check show asp drop to identify exactly why:
ciscoasa# show asp drop
Analyzing Captures in Wireshark
Once I have a pcap file, my analysis workflow is fairly consistent:
- Apply a display filter to isolate the conversation of interest, e.g.,
ip.addr == 10.1.1.10 && tcp.port == 443 - Check the TCP handshake — look for SYN, SYN-ACK, ACK. If I only see SYN packets with no response, that tells me traffic is not reaching the destination or a firewall is silently dropping it.
- Look for retransmissions and duplicate ACKs — these indicate packet loss somewhere in the path, often correlating with interface errors I would also see in
show interfaceoutput. - Check for TCP resets (RST) — an application or firewall actively rejecting the connection rather than silently dropping it.
- Follow the TCP stream for application-layer visibility when the traffic is unencrypted, which is invaluable for diagnosing HTTP, DNS, or other clear-text protocol issues.
Real-World Enterprise Scenario: Intermittent Application Timeout
I once worked a case where a business application would intermittently time out for users at one branch site, while working fine everywhere else. Show commands on the routers and switches all looked clean — no errors, no interface issues. I set up an EPC capture at the branch router filtered to the application server’s IP and left it running with a large buffer during business hours.
When the timeout occurred again, I pulled the capture and found repeated TCP retransmissions followed by a full session reset, correlated precisely with a burst of CRC errors on the WAN interface that had not yet crossed the threshold I usually associate with “obviously bad” cabling. The packet capture gave me undeniable proof to justify replacing a marginal SFP module that show interface alone had not flagged clearly enough to justify a physical dispatch.
Common Configuration Mistakes
- Capturing with no filter on a high-traffic interface, filling the buffer in seconds and missing the actual event
- Forgetting to stop and clear a capture after troubleshooting, leaving it consuming device memory indefinitely
- Capturing only in one direction when the problem could be asymmetric routing
- Not correlating capture timestamps with the device’s own clock/logging timestamps (NTP misalignment can make correlation across devices very confusing)
Router# monitor capture CAP1 clear
Router(config)# no monitor capture CAP1
Security Best Practices
- Restrict who can configure and export captures — packet captures can contain sensitive data including credentials in clear-text protocols
- Always remove capture configuration and exported files after troubleshooting is complete
- Use ACL-based filtering to limit captured data to only what’s relevant, minimizing exposure of unrelated sensitive traffic
- Encrypt or securely transfer exported pcap files rather than leaving them on shared, unencrypted storage
Performance Tuning
Embedded capture does consume CPU and memory resources, particularly on lower-end platforms, so I always:
- Use the smallest buffer size that will capture the needed event
- Apply a tight ACL filter rather than capturing “any”
- Avoid running captures indefinitely on production routers; use a defined start/stop window
Frequently Asked Questions
What is the difference between SPAN and Embedded Packet Capture? SPAN mirrors traffic to a physical port for an external tool like Wireshark to capture, while EPC captures directly on the device itself without external hardware, though with buffer size limitations.
Can I capture traffic on a Cisco ASA without external tools? Yes — the ASA’s built-in capture command lets you capture and even view basic packet summaries directly in the CLI, and you can export to pcap for full Wireshark analysis.
Why is my packet capture buffer filling up too fast? You are likely capturing without a filter on a busy interface. Apply an ACL to scope the capture to only the traffic relevant to your investigation.
How do I know if the firewall is dropping my traffic versus it never arriving? Capture simultaneously on the ingress and egress interfaces of the firewall — if packets appear on ingress but not egress, the device itself is dropping them, and show asp drop (on ASA) will usually tell you why.
Summary
Packet capture is the definitive way to resolve ambiguous network problems, and Cisco devices offer strong native capabilities — from SPAN/RSPAN for external analysis to Embedded Packet Capture and ASA’s capture command for on-device diagnostics. Scoping captures with ACLs, correlating timestamps across devices, and following a consistent Wireshark analysis workflow will let you turn a vague “it’s slow sometimes” complaint into concrete, defensible evidence of root cause.
References
- Cisco Embedded Packet Capture Configuration Guide — cisco.com
- Cisco ASA Series CLI Configuration Guide: Capturing Packets — cisco.com
- Cisco Catalyst Switch SPAN and RSPAN Configuration Guide — cisco.com
