In this article we will discuss Cisco Embedded Packet Capture (EPC). This feature allows us to capture packets that are going through the router (transit traffic), packets that are destined to the router or packets that are generated by the router. The packets can be analyzed on the router or they can be exported to a remote device in a pcap format where advanced packet analyser are available.
CCNA Training – Resources (Intense)
The following can be performed with EPC:
Capture IPv4 and IPv6 packet in CEF
Display the packet directly on the device
Granular filtering of the packets captured
Ability to export the capture outside the device for advanced packet analysis
Let’s discuss two basic notions related to EPC:
Buffer – is a memory location where the packets are stored. The memory can be linear (when the maximum size of the buffer is reached, then the capture stops) or circular (when the maximum size of the buffer is reached, the oldest entry is overwritten).
Capture point – is the point on the router where the capture is taken. When this is configured, the type of packets has to be specified (IPv4 or IPv6), whether it is CEF or process switched, the interface and the direction (ingress, egress or both).
There is no configuration related to EPC that is saved in the running configuration of the device. That is if the device reboots, the buffer and the configuration that enabled the packet capture is lost. The exception is the optional ACL used to filter the packets that are put in the packet capture.
So let’s start configuring EPC on a router with classic IOS on 15.2. This is our topology. At the end of the article, we will export the buffer to a device that has Wireshark installed to check the packets in a friendlier format.
We are starting by configuring the buffer specifying the size of the packet capture and the type of buffer. The default value for the size of the buffer is 1024KB (1MB) and the buffer is linear, which means that the packet capture will stop when the buffer will be full.
In our example, we will configure a circular buffer with a size of 2048KB:
R1#monitor capture buffer BUFFER_PC1_PC2 circular R1#monitor capture buffer BUFFER_PC1_PC2 size 2048 R1#
We can capture all the traffic passing through the router, but we will filter it out meaning that we will capture only the traffic between PC1 and PC2. For this, we need to define the traffic that will be captured by configuring an access-list and then tying it to the buffer that we just configured:
This is the access-list matching the interest traffic:
R1#conf t Enter configuration commands, one per line. End with CNTL/Z. R1(config)#ip access-list extended 101 R1(config-ext-nacl)#permit ip host 10.10.1.100 host 10.10.2.100 R1(config-ext-nacl)#permit ip host 10.10.2.100 host 10.10.1.100 R1(config-ext-nacl)#end R1#
And this is how it is tied to the buffer:
R1#monitor capture buffer BUFFER_PC1_PC2 filter access-list 101 Filter Association succeeded R1#
The next step is to define a capture point and that is where you want to take the capture. We will take the capture on FastEthernet1/0. As mentioned, there are few options about the direction where the capture should be taken. We will use both directions and both entering and exiting packets will be captured:
R1#monitor capture point ip cef R1_F1/0 FastEthernet1/0 both R1#
If the capture point was correctly created, you should see in the logs something like this:
*Jun 14 08:42:16.067: %BUFCAP-6-CREATE: Capture Point R1_F1/0 created.
The next step is to associate the capture point with the buffer that we configured previously:
R1#monitor capture point associate R1_F1/0 BUFFER_PC1_PC2 R1#
If the association was correct, you should see something similar like this in the logs:
*Jun 14 08:44:51.475: %BUFCAP-6-ENABLE: Capture Point R1_F1/0 enabled.
Everything looks fine, but the capture is not started and this is the last step in order to store the packets in the router memory:
R1#monitor capture point start R1_F1/0 R1#
From this moment on, any packet that is matched by the ACL will be stored in the buffer.
Let’s continue with EPC monitoring and see how we can check the parameters of the EPC and what are the packets stored in the buffer.
But first, let’s send some traffic between PC1 and PC2 and between PC1 and PC3 and confirm that we have in the buffer only the packets between PC1 and PC2. In this test, I sent one ICMP packet from PC1 to both PC2 and PC3:
PC1> ping 10.10.2.100 -c 1 84 bytes from 10.10.2.100 icmp_seq=1 ttl=63 time=19.323 ms PC1> ping 10.10.3.100 -c 1 84 bytes from 10.10.3.100 icmp_seq=1 ttl=63 time=14.775 ms PC1>
Because we are monitoring both direction of F1/0, this means that we will have two packets: the ICMP request (which is ingress) and the ICMP reply (which is egress):
R1#show monitor capture buffer BUFFER_PC1_PC2 parameters Capture buffer BUFFER_PC1_PC2 (circular buffer) Buffer Size : 2097152 bytes, Max Element Size : 68 bytes, Packets : 2 Allow-nth-pak : 0, Duration : 0 (seconds), Max packets : 0, pps : 0 Associated Capture Points: Name : R1_F1/0, Status : Active Configuration: monitor capture buffer BUFFER_PC1_PC2 size 2048 circular monitor capture point associate R1_F1/0 BUFFER_PC1_PC2 monitor capture buffer BUFFER_PC1_PC2 filter access-list 101 R1#
As you can see, we have two packets in the capture. Also, we can see the buffer size, what are the associated points and how this buffer’s characteristics were configured.
The number of the packets from the buffer is confirmed by the ACL counters:
R1#show ip access-lists Extended IP access list 101 10 permit ip host 10.10.1.100 host 10.10.2.100 (1 match) 20 permit ip host 10.10.2.100 host 10.10.1.100 (1 match) R1#
Let’s check the association point:
R1#show monitor capture point R1_F1/0 Status Information for Capture Point R1_F1/0 IPv4 CEF Switch Path: IPv4 CEF , Capture Buffer: BUFFER_PC1_PC2 Status : Active Configuration: monitor capture point ip cef R1_F1/0 FastEthernet1/0 both R1#
To see brief information about the packets in the capture, you can use this command:
R1#show monitor capture buffer BUFFER_PC1_PC2 08:53:24.815 UTC Jun 14 2015 : IPv4 CEF Turbo : Fa1/0 None 08:53:24.823 UTC Jun 14 2015 : IPv4 CEF Turbo : Fa1/1 Fa1/0 R1#
However, if you want to see the actual packets, you can use this command:
R1#show monitor capture buffer BUFFER_PC1_PC2 dump 08:53:24.815 UTC Jun 14 2015 : IPv4 CEF Turbo : Fa1/0 None 67FE1790: CA014DD8 001C0050 79666802 08004500 J.MX...Pyfh...E. 67FE17A0: 005416D5 00003F01 4CF90A0A 01640A0A .T.U..?.Ly...d.. 67FE17B0: 02640800 4AF4D516 00010809 0A0B0C0D .d..JtU......... 67FE17C0: 0E0F1011 12131415 16171819 1A1B1C1D ................ 67FE17D0: 1E1F2021 00 .. !. 08:53:24.823 UTC Jun 14 2015 : IPv4 CEF Turbo : Fa1/1 Fa1/0 67FE1790: 00507966 6802CA01 4DD8001C 08004500 .Pyfh.J.MX....E. 67FE17A0: 005416D5 00003F01 4CF90A0A 02640A0A .T.U..?.Ly...d.. 67FE17B0: 01640000 52F4D516 00010809 0A0B0C0D .d..RtU......... 67FE17C0: 0E0F1011 12131415 16171819 1A1B1C1D ................ 67FE17D0: 1E1F2021 00 .. !. R1#
This dump can be decoded, but you would need to be familiar with the IP headers. For instance, the second packet is the ICMP reply from 10.10.2.100 to 10.10.1.100. How do I know this?
Let’s decode the following octets (the ones highlighted):
0A0A0264 – 10.10.2.100 0A0A0164 – 10.10.1.100 00 – Type 0 (ICMP reply) 00 – Code 0
You have the ability to filter what packets from the buffer are displayed, but they will be shown in a brief format. However the filtering is quite interesting as you can filter on the packet size or time when it was written in the buffer:
R1#show monitor capture buffer BUFFER_PC1_PC2 filter ? direction Filter output based on direction input-interface Filters packet on an input interface l3protocol Filter packets with specific L3 protocol output-interface Filters packet on an output interface pak-size Filter output based on packet size time Filter packets from a specific clock time/date R1#
For instance, by default the ICMP packets have 64B size and I sent another ICMP packets with a size of 200B. Let’s filter the capture by using the packet size. These are the packets that should have a size of 200B:
PC1> ping 10.10.2.100 -l 200 -c 1 228 bytes from 10.10.2.100 icmp_seq=1 ttl=63 time=25.792 ms PC1>
And now we can see them in the packet capture:
R1#show monitor capture buffer BUFFER_PC1_PC2 filter pak-size 199 300 09:28:06.323 UTC Jun 14 2015 : IPv4 CEF Turbo : Fa1/0 None 09:28:09.335 UTC Jun 14 2015 : IPv4 CEF Turbo : Fa1/1 Fa1/0 R1#
In case you need to clear the buffer, you need to first stop the capture point and then clear it. This is how you stop the capture point:
R1#monitor capture point stop R1_F1/0 R1#
And this is how you clear the buffer:
R1#monitor capture buffer BUFFER_PC1_PC2 clear R1#
You have the possibility to export the capture to a remote device where you can use a packet analyser for an easier decoding of the packets. To do this, you first need to stop the capture point and then export it. Here is how you can export it using FTP:
R1#monitor capture buffer BUFFER_PC1_PC2 export ftp://cisco:firstname.lastname@example.org/capture.pcap Writing capture.pcap R1#
Now that we have the file, let’s open it with Wireshark and confirm that we are seeing only packets between PC1 and PC2:
To remove any EPC configuration from memory, you need to stop the capture point and then do the following:
R1#no monitor capture buffer BUFFER_PC1_PC2 Capture Buffer deleted R1#no monitor capture point ip cef R1_F1/0 f1/0 R1#
Then everything should be removed:
R1#show monitor capture point all R1#show monitor capture buffer all parameters R1#
And we reached the end of the article where we saw what Cisco Embedded Packet Capture is, how to configure it and how to monitor and troubleshoot it.
As said, the feature allows you to quickly be able to filter specific packets to be analyzed.
The article focused on classic IOS, but EPC is available on other IOS flavours as well. Additional features might be available which can allow more friendly display of the capture dump or more advanced filtering.
However, this article will give you a good starting point when you start using the feature, regardless of the platform you are using.