Embedded Packet Capture: Wireshark Inside Your Router

You are troubleshooting a problem that only the packets can explain - a malformed handshake, an unexpected retransmission, a mystery drop. The traditional answer is to SPAN a port to a laptop running Wireshark. But the traffic is on a router in another building, or inside a tunnel, or you simply do not have a capture machine handy. Embedded Packet Capture (EPC) puts Wireshark-grade capture inside the router itself - no SPAN, no external host, no cabling.

This article covers EPC on IOS XE, with a real on-router capture from a CML lab, and the syntax difference that will bite you. For the fundamentals, see the IP services pillar.

What EPC is

EPC captures packets traversing the router into an in-memory buffer, which you can then view on the CLI or export as a standard .pcap file to open in Wireshark. It captures at a defined point (an interface, a direction), filtered by an ACL so you grab only what you want, into a buffer you size. It is genuinely a packet analyser living in the router, and for anyone who has ever driven to a site just to plug in a capture laptop, it is a revelation.

The syntax trap: classic vs modern

Here is the thing that will waste your afternoon. IOS XE has two EPC syntaxes, and which one your platform accepts depends on the image. On a lot of virtual and older platforms - including the IOL-XE we used in the lab - the modern syntax is rejected:

R1(config)# monitor capture EPCAP interface Ethernet0/3 both
                            ^
% Invalid input detected at '^' marker.

The modern one-liner (monitor capture NAME interface X both, then match, start, stop) is what most current documentation shows. But where it is not supported, you fall back to the classic buffer-and-point model, which is more verbose but works:

! Classic EPC - four steps
monitor capture buffer EPCBUF size 256 max-size 1518 linear
monitor capture point ip cef EPCPOINT Ethernet0/3 both
monitor capture point associate EPCPOINT EPCBUF
monitor capture point start EPCPOINT

The classic model separates the buffer (where packets are stored - size, type) from the capture point (where and what is captured - the interface, direction, and switching path). You create both, associate them, and start the point. If your platform rejects monitor capture NAME interface, reach for this. Knowing both syntaxes is exactly the kind of platform-specific detail that separates a smooth troubleshoot from a frustrating one.

A real capture

With the capture point started, we generated traffic across the interface (a ping) and stopped the point:

R1# monitor capture point stop EPCPOINT

R1# show monitor capture buffer EPCBUF
09:19:13.115 UTC Jul 12 2026 : IPv4 LES CEF : Et0/3 None
09:19:13.118 UTC Jul 12 2026 : IPv4 LES CEF : Et0/3 None
09:19:13.119 UTC Jul 12 2026 : IPv4 LES CEF : Et0/3 None
09:19:13.123 UTC Jul 12 2026 : IPv4 LES CEF : Et0/3 None

Four real packets, timestamped, captured on the router itself. The parameters view confirms the buffer state:

R1# show monitor capture buffer EPCBUF parameters
Buffer Size : 262144 bytes, Max Element Size : 1518 bytes, Packets : 4
Associated Capture Points:
Name : EPCPOINT, Status : Inactive

Packets : 4 - the buffer holds what we captured. For a detailed per-packet decode, show monitor capture buffer EPCBUF detailed gives you the full protocol breakdown, and dump gives you the raw hex.

Filtering: capture only what you need

An unfiltered capture on a busy interface fills the buffer with noise in milliseconds. Always filter with an ACL that matches only the conversation you are investigating:

ip access-list extended CAP-FILTER
 permit ip host 10.7.7.10 host 10.7.7.1
 permit ip host 10.7.7.1 host 10.7.7.10
!
! Classic: apply the ACL to the capture point
monitor capture point ip cef EPCPOINT Ethernet0/3 both
! ...with the buffer filtered by the ACL association

Match both directions of the conversation (source-to-dest and dest-to-source), or you only see half the exchange and the capture is useless for diagnosing a handshake. This is the most common EPC mistake - a one-directional filter that captures the SYN but not the SYN-ACK.

Buffer type: linear vs circular

Choose by what you are hunting. Investigating a connection setup? Linear, so you keep the first packets. Waiting for an intermittent failure? Circular, so when it happens the recent packets (including the failure) are still there. A linear buffer that fills before your event is the second most common EPC mistake.

Exporting to Wireshark

The CLI view is fine for a quick look, but for real analysis you export the buffer as a pcap and open it in Wireshark or tshark:

R1# monitor capture buffer EPCBUF export tftp://10.7.7.200/capture.pcap

Pull that pcap to your analysis host (or the lab's Linux VM) and you have a standard capture file - full decode, filters, follow-stream, everything Wireshark does. The router did the capture; your workstation does the analysis. This is the workflow that makes EPC genuinely powerful: capture at the exact point in the network where the problem lives, analyse with the best tool.

Operational cautions

• EPC costs CPU and memory. The router is copying packets to a buffer. On a busy production router, a broad capture can hurt. Filter tightly and size the buffer sensibly.
• Stop and remove captures when done. A forgotten running capture keeps consuming resources. monitor capture point stop and remove the buffer.
• It captures control-plane and punted traffic well, but hardware-forwarded traffic on some platforms may need the capture at a specific point. Know your platform's forwarding path.
• The classic-vs-modern syntax is image-dependent. If one is rejected, try the other before concluding EPC is unavailable.

EPC vs SPAN vs debug

Key takeaways

• EPC captures packets inside the router into a buffer, viewable on the CLI and exportable as pcap for Wireshark - no SPAN, no external host.
• Two syntaxes exist: the modern monitor capture NAME interface and the classic buffer/point model. Virtual and older platforms (like the lab's IOL-XE) reject the modern one - fall back to classic.
• Verified: a real 4-packet capture on the router, with show monitor capture buffer and its parameters.
• Filter with an ACL matching both directions of the conversation, or you capture half a handshake.
• Linear buffer preserves the start of an event; circular keeps the most recent - choose by what you are hunting.
• Export with monitor capture buffer X export tftp://... and analyse in Wireshark. Capture at the problem, analyse with the best tool.
• EPC costs router CPU/memory - filter tightly and stop captures when done.

Next: IPv6 services closure - NPTv6, DHCPv6-PD, and general prefix. The full cluster index lives on the IP services pillar, and EPC's packet-analysis kinship links it to the Nmap and Ping clusters.