> ## Content Index
> Fetch the complete content index at: https://www.pinglabz.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Embedded Packet Capture: Wireshark Inside Your Router
- URL: https://www.pinglabz.com/embedded-packet-capture-ios-xe/
- Published: 2026-07-12T09:34:25.000Z
- Updated: 2026-08-24T09:42:19.000Z
- Description: Embedded Packet Capture puts Wireshark-grade capture inside the IOS XE router itself: no SPAN, no capture laptop, no cabling. Includes a real on-router capture from a CML lab and the syntax difference that will bite you.
- Author: Jaime
- Tags: IP Services, Labs, CCIE, #Import 2026-08-01 19:54

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](https://www.pinglabz.com/ip-services/).

## 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 analyzer 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

linear

Captures until the buffer is full, then **stops**. Good for catching the *start* of an event - the first packets are preserved. The lab used linear.

circular

Overwrites the oldest packets when full, keeping the **most recent**. Good for catching an event you are waiting for - leave it running and stop it when the event fires.

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, analyze with the best tool.

What you do with the file once it is on your workstation is a separate skill from getting it there, and it is the part that decides whether the capture was worth taking. The [guides on reading a capture to find the anomaly](https://www.pinglabz.com/packet-analysis/) pick up exactly where this export leaves off.

## 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

**EPC** Capture inside the router, no external host, exportable to pcap. Best for remote sites and tunnelled traffic. Costs router resources. 

**SPAN** Mirror a port to a capture host. Best when you have a host on-site and want zero router overhead. Needs the cabling and the host. 

**debug** Protocol-level events, not raw packets. Best for "what is the protocol thinking", dangerous on a busy box. Not a substitute for a real capture. 

There is a fourth option that table leaves out, because it does not run on the router at all. If there is a Linux box sitting on the segment you care about, [taking the same capture from the host side](https://www.pinglabz.com/tcpdump-for-network-engineers/) costs the router nothing, and the BPF filter syntax maps closely enough onto the ACL logic above that you can move between the two without relearning anything.

## 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 analyze in Wireshark. Capture at the problem, analyze 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](https://www.pinglabz.com/ipv6-nptv6-dhcpv6-pd/). The full cluster index lives on the [IP services pillar](https://www.pinglabz.com/ip-services/), and EPC's packet-analysis kinship links it to the [Nmap](https://www.pinglabz.com/nmap/) and [Ping](https://www.pinglabz.com/ping/) clusters.