Capturing Packets on Your Cisco Router
I’m a big fan of using network taps when I’m going to be working with Wireshark, but they require either foresight during installation or downtime while they are put in place. Most of the time, I just end up using a SPAN (Switch Port ANalyzer) from a switch, but there are times where you are either not allowed to do that, or there are technical reasons why that wouldn’t work. In the event of one of those “technical reasons”, one of the options you have is to use the packet capture feature that is part of Cisco’s IOS. There are some scenarios, like VTI (Virtual Tunnel Interface), where even if you setup a tap, all you would see is encrypted traffic (which tends to get pretty boring pretty quick, plus not that helpful). Now that you know why this might be useful to you, let’s take a quick look at how to get it running.
A couple pre-reqs:
- A TFTP Server
- IP connectivity from your router to said TFTP Server
The commands are going to look like this:
Router#monitor capture buffer BUFFER_NAME
Router#monitor capture point ip cef POINT_NAME gig 0/1 both
Router#monitor capture point associate POINT_NAME BUFFER_NAME
Router#monitor capture point start POINT_NAME
Router#monitor capture point stop POINT_NAME
Router#monitor capture buffer BUFFER_NAME export tftp://<ip address>/<name.pcap>
The two major parts of setting up a capture are the buffer configs and the point configs. The buffer has settings on how large or how many packets. In the commands above I named the buffer “BUFFER_NAME”, associated it with the capture point I setup, and then exported it to a TFTP server. Obviously, when you are doing this you would replace <ip address> with the IP address of your TFTP server, and <name.pcap> should be replaced with the name you would like for your capture, for example “capture.pcap”. Your point settings define the interface and direction you would like to capture. I normally use bi-directional traffic for troubleshooting, but there are certain instances where you might just want it in a single direction (which would make your capture smaller, if space is a concern). The start command begins the capture. After this command, you will need to wait for whatever traffic you are expecting. For example, if you are looking for some web traffic, you would start the capture on the router, browse to whatever website on your computer, and then stop the capture. What you are troubleshooting will have a direct impact on the time between the start and the stop. The last command is where you would like to dump the capture. Just make sure whichever TFTP server you are using is accessible, and the router has permissions to write in whatever folder you are dumping the traffic. From this point, you can head over to your TFTP server and open up the .pcap in Wireshark.
There are a couple of interesting things I noticed while doing this. First, it seemed the router was somewhat selective on which traffic it actually sent. When I did the initial capture, I was expecting to see some EIGRP traffic, but I didn’t actually see any even though I know it was there. The other point is that it matters which interface you are capturing from. For example, if you are running an encrypted tunnel using tunnel 0, but it is using Gig 0/0 as a tunnel source, you probably do not want to run your capture from Gig 0/0. You will see the traffic, but it will all be encrypted. In the described scenario, you would probably want to run the capture on Tunnel 0 instead.
Another note on the embedded capture feature is that you will need to be clear the buffer between each series of captures. I did a bunch of these in a row and noticed a repeat in traffic, which you will not want. You can clear the buffer with the following command:
Router#monitor capture buffer BUFFER_NAME clear
That should be enough to get you started. I don’t have a bunch of experience with this, so if you would like to read more, check this out.