Cisco Embedded Packet Capture (EPC)

Hi Jason,

Here they are:


Is it possible to provide an example of the above mentioned procedure you provided? Would like to see how this can be configured. Thanks in advance.

Hello Angelos

The lesson itself contains an example where EPC was used to capture the packets on R2, and how the capture file was transferred to a computer to be viewed via Wireshark.

Now what I suggest , and I believe this will also help you in gaining experience, is to try to recreate this topology in GNS3 or some other simulator with the config options that Rene has suggested so you can recreate this example and you can have the opportunity to view the results first hand. I believe that we always learn best when we apply it and gain personal experience from it.

If you do perform the experiment, please share your results with us!

I hope this has been helpful!


I have a question regarding this buffer of 8192K? Does it mean that the max. pcap file can be 8 MB? I think this is really small.

Hello Lukas

The maximum buffer size for the particular device that Rene is using is actually 102400 KB or 102 MB. See the screenshot below:

Now keep in mind that the buffer is in the RAM of the Cisco device, which is usually not excessively large. The maximum sizes available for buffers will depend on the platform, the IOS and the available memory at the time.

For this reason, unlike Wireshark, the EPC feature is not designed to run for extensive periods of time. It should be used to capture specific traffic that is generated for the purpose of it being captured and analysed.

I hope this has been helpful!


1 Like

Hi Laz,

thanks a lot for your nice explanation :slight_smile:

Kind regards,


1 Like

Where are the return packets of the ping?

Hello Arun

In the configuration of the capture buffer, Rene created an access list that specifies which packets will be captured. The specific access list and how it was applied is shown below:

The access list specifies that only traffic from to will be captured. This means that only the echo requests will be captured and not the replies.

I hope this has been helpful!


Just a syntax question … if you want to export capture to local flash what is the command? I have searched various websites / docs but the expectation is always ftp or tftp.

Many Thanks

Hello Frank

In order to redirect the output of a show command, you can use the pipe character “|”. I’m sure you’ve used it with the begin or include keywords, but it can be used to redirect to a file on the device file system. You can use the following syntax:

show command | append flash:showoutput.txt

where the word “command” can be replaced with whatever command you want to show.

Now Cisco actually calls the “flash:showoutput.txt” portion of the command a URL. This can indeed be a URL using FTP or TFTP, but it can also be a URL with the specific file system you want to save to. Some platforms may not use “flash” but another indicator. You can determine which memory you want to save to by issuing the show file systems command. It will list all of the available prefixes that you can use.

I hope this has been helpful!


Hi Rene

Is there any way to capture packet from swtichport using EPC?


Hello Carlo

The EPC packet capturing feature can be applied to Layer 2 switchports as well by simply specifying them. The capture can be performed on physical interfaces, sub-interfaces as well as tunnel interfaces.

I hope this has been helpful!


Hi ,

if i use the linear buffer or circular buffer i don’t have problem to crash the router. confirm me?

Hello Andrea

Packet capturing in general is a mechanism that does use up some CPU and memory resources of the device. Obviously the better the CPU and the more memory you have, the less chance you have of crashing the router.

The use of a linear or circular buffer do not have a very big impact on whether or not the device will crash. A linear buffer will probably be safer, since it automatically stops once the buffer is reached. A circular buffer will continue to capture packets forever until you configure it to stop.

However, the most important configuration parameters that have an impact on CPU and memory usage such as:

  • Decoding and displaying packets
  • using a display and decode mode of "detailed:
  • the activation of a wireshark capture point as this creates a fixed rate policer in the hardware that can flood the CPU
  • capturing an excessive number of attachment points at the same time

Also, the CPU usage during capture depends on how many packets match the specified conditions and on the intended actions for the matched packets (store, decode and display, or both).

You can find more information about what impacts a device’s resource usage at the following Cisco documentation:

I hope this has been helpful!


1 Like

thanks so much for the explanation.

1 Like

Hi Rene and Laz,

I don’t know why but it doesn’t seem to work.

Every time that I opened the pcap file which I transfered to my pc, I’ve got an error message would it be packet corrupted or that the number of packets in the file exceeded the maximum packets that the software can handle - even though I configured 8k max size for the buffer.

I tested the configuration on GNS3 lab, and conencted teh virtual lab to my PC and used tftp from the pc to one of the routers , The file itself is 4.5KB so I don’t know why would it say 7 trilion packets exists in the file when I open it with wireshark.

  • seems like I transferred the file in some ASCII mode instead of binary , after changing to binary mode I can access the files.

used TFTP on windows client.

1 Like

Hi Guys,

Just a query about EPC.
I was doing some packet captures on a 9300 running 16.9.4

I had a read through the configuration guide and it lists the following restriction.

Embedded Packet Capture is not supported on logical ports, which includes port channels, switch virtual interfaces (SVIs), and subinterfaces. It is supported only on physical ports.

I set up the following capture with a SVI as the interface to capture in both directions. .

 Status Information for Capture drillcap
  Target Type: 
 Interface: Vlan704, Direction: BOTH
   Status : Inactive
  Filter Details: 
    Source IP:
    Destination IP:  any
   Protocol: any
  Buffer Details: 
   Buffer Type: LINEAR (default)
  File Details: 
   Associated file name: flash:drillcap.pcap
   Size of buffer(in MB): 100
  Limit Details: 
   Number of Packets to capture: 0 (no limit)
   Packet Capture duration: 600
   Packet Size to capture: 0 (no limit)
   Maximum number of packets to capture per second: 1000
   Packet sampling rate: 0 (no sampling)

I seem to be able to capture with those settings. ALTHOUGH… i do seem to be missing some data that I believe is there. Would this be expected or it shouldn’t work at all?


Hello Rene/Lagapides,

Can EPC capture traffic which is not destined to the switch itself? I mean, can I capture all traffic between two host in the same vlan in a switch in between that its only doing L2 with EPC?
I have tried but packet counter doesnt increase at all.
Is SPAN the only alternative in that case?


Hello Josh

Hmm, that’s interesting. If a feature is “not supported” it should typically not allow you to configure it in an unsupported manner. I was unable to find any info concerning this, but suffice it to say that any resulting captures should not be considered accurate, which is something that you have confirmed with the missing data you have discovered.

This reminds me of the situation where you can assign a switchport to a particular VLAN without that VLAN having been configured yet. It will accept the command, much like in your situation, but it will not be functional (until you actually create the VLAN). It’s not quite the same, but it demonstrates how you can configure a feature without receiving any error messages, even if it is unsupported or non functional.

Thanks for sharing this, as it is useful for us and for the readers of the forum!


Hello Ignacio

EPC is capable of capturing any packets that flow to, through, and from the device. This means that if a packet enters or exits a physical interface of the device, regardless of what the source or destination is, it can be captured. So based on the description of your scenario, i would have to say yes, it should be able to capture such traffic.

Now the fact that you are not capturing traffic may be due to a misconfiguration, platform, or due to EPC prerequisites or restrictions. One of these, mentioned by @ignacio.rodriguez.or and in my post above, is the fact that EPC must be applied only to physical ports of the device and not virtual ports (such as SVIs, or port channels for example).

Take a look at some of the restrictions, and review your configuration and let us know what you find. If you need further assistance, you know where to find us!

I hope this has been helpful!