Let’s say you have a DHCP server running on a Cisco Switch that is behaving strangely and you want to examine the traffic over a couple of hours while not creating a gigantic unmanageable capture file.
A note here: I am doing this on a Cisco switch, but most all vendor switches support this port mirror or span port capability. Just substitute how your system does this in the process outlined below.
Many years ago I wrote an article on this in my Cisco How To’s that you can also refer to here.
What you will need:
- A Switch that support port mirroring or span ports
- A Gigabit Ethernet Cable
- A Laptop running Wireshark.
In this example we are using Cisco IOS. Cisco calls this ability to mirror traffic SPAN and RSPAN. For Cisco specific info on SPAN and RSPAN see: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3560/software/release/12-2_52_se/configuration/guide/3560scg/swspan.html
On the switch, in privileged mode, go into config mode (config t)
Enter the following command to specify which port you wish to “mirror”. You can specify multiple ports if you wish, but be careful here. If you combine multiple ports and they are running at more than 50% capacity, you are likely to drop packets going to the single mirror port.
monitor session 1 source interface gigabitethernet0/1
What is happening above we are creating a “session 1” sourced from GigE0/1.
monitor session 1 destination interface gigabitethernet0/4 encapsulation replicate
This is specifying which port we will be mirroring to. Make sure the GigE0/4 is not shut down.
Now connect the cable from GigE0/4 to the laptop ethernet interface.
Open Wireshark on the laptop.
Select the Ethernet interface from the Wireshark home screen – just click once – it will be highlighted.
I always like to start with a quick test: just start capturing, and verify you are seeing traffic. You may want to ping the DHCP server and see if you see those ICMP packets in the capture. There are some clever ways to ping and you can see my article on using Ping for Troubleshooting here.
If all looks good, stop the capture without saving.
Start a new capture, this time we will leverage WIreshark’s Ring Buffer feature as follows:
Click on Capture> Options. You will get the following pop up:
Yours will have different interfaces. Make sure the promiscuous mode checkboxes are checked.
Again – your Ethernet interface should be highlighted here as well.
Now click on the Output Tab:
1. Click the browse button and select desktop, and start the filename with a seed (remember I used the word Test). Say OK and you should return to this pop up with the path and filename populated.
2 and 3. Select After next to time, enter 10 and change #3 to minutes. So each file will have 10 minutes of traffic
4. Choose the gzip button.
5. Set the number of files to 12
The result of this is that Wireshark will create 12 files – each with 10 minutes of traffic – resulting in 2 hours of capture.
In your network you may want to vary these settings as needed.
Now you can either click start at this point, or you can select the options tab, and at the bottom tell Wireshark to stop automatically after 12 files.
If you are not sure when the problem occurs – like an intermittent issue, I would let this run as Wireshark’s ring buffer feature will overright the oldest file with a newer file – like a sliding window, you will always have the last 2 hours of traffic.
Packet Analysis Step
At this point we have 12 files, each containing 10 minutes of traffic on the DHCP server we wanted to analyze and troubleshoot. I would open these one at a time, examining the traffic in Wireshark. I would use my DHCPv4 Wireshark Profile (look here) to then perform an analysis of the traffic. I would walk through each of the 12 files in the same manner, looking for changes in protocol behavior, pattern changes, time changes and so forth. Going deeper into specifically troubleshooting DHCP is beyond the scope of this article, but I hope this has launched you in the right direction.
If everything worked, we need to turn off the port mirroring on the switch with this command:
no monitor session 1
In this article I took a detailed look into how we can leverage using port mirroring/SPAN ports and Wireshark packet analysis in troubleshooting. This was not all encompassing, and I am sure readers and visitors will have some additional steps or suggestions they use in the comments. We all welcome those pearls of wisdom on this subject.
I hope you find this article and its content helpful. Comments are welcomed below. If you would like to see more articles like this, please support us by clicking the patron link where you will receive free bonus access to courses and more, or simply buying us a cup of coffee!, and all comments are welcome!