i'm wondering how other network engineers use packet capture utilities in the real world. i'm still relatively new to this field and i'm on a LAN team supporting a large campus for a big company. i sometimes hear general requests like "can you put a sniffer on the network and see why its running slow?"

follow up questions usually isolate the problem to one particular application or server....on some ocassions i'll dig around and find a bad uplink port or duplex mismatch or something, but i've never yielded any useful information from simply putting a sniffer on the network.

I can see how an application developer might find packet traces useful in debugging and i do find them useful in learning how various protocols work, from an educational perspective....but I don't necessarily see how they are used to solve/isolate general 'network is slow' problems.

how do you guys use packet captures for troubleshooting??

The benefit realized when using a sniffer to troubleshoot is directly proportional to the engineer's understanding of the protocol(s) in question. For example, if one doesn't grasp the fundamentals of TCP, all the packet captures in the world aren't going to help him troubleshoot a TCP issue.

I've found sniffers most useful when troubleshooting software or machines to which I have limited access. Sometimes it's just easier (and always more reliable) to look at the wire itself rather than navigating through an unfamiliar configuration to see what traffic is really being sent. Hope that makes sense.

I too am getting started with wireshark. I think it is not only a knowledge of the protocols (which I am learning), so no I don't full grasp them, but also a learning curve of using wireshark itself.

I try to use it as much as possible and when I find something I don't know about (often) I google it. The problem I am having is the amount of captures to sift through. I think once I learn how to use WS better this will be a amazing diagnostic tool.

Several years ago, I had the opportunity to attend a SANS course called Intrusion Detection In Depth. It was two days of nothing but looking for the evil bit in packet captures and how to detect intrusions. I had some knowledge of sniffing before the class, but my expertise was quick accelerated.

I have used Wireshark, actually being a Linux CLI type, tcpdump, to find all types of things. Nothing really stands out in my mind at the moment, but the training I got in the class has been extremely helpful to quickly resolve issues.

As Stretch has said, knowing how the protocol works is the most important thing.

I work for a telephone company, we do all FTTP and calls on our network are either SIP or MGCP. We utilize packet captures all the time to help isolate network issues. Customer calls in complaining of call quality issues, by doing a packet capture at certain points in the network we can determine if the issue is on or off network. If it is off network then we open a ticket with the upstream carrier, if it's on network then the packet capture can give us a relatively good idea of where in the network packet loss or jitter are occuring. If we are able to re-create the issue wireshark also gives us the ability to reassemble the audio stream and actually hear the problem. Customers will many times complain of static on the line when in all actuality it is packet loss.

I would agree however, your ability to utilize packet captures is directly proportional to your understanding of the underlying protocol. Almost everyone in my NOC can take a packet capture and listen to the audio stream, only one or two people can take that packet capture and tell you what number was being called specifically and know when a call was put on hold, transferred or some other call service was applied.

Hey guyz,

im very new to the field of networking and packet captures. i really am interested in getting more exposure in packet captures and reading em. can you guys tell me how do you manage to capture packets if its not an issue on the machine?

do you use a span port to capture packets? how do you guys determine which perticular device (specifically switches) has an issue?

1. Isolating an issue to being with a DHCP server, and not with relay agents.
2. Isolating an issue to being with routing, and not with a DHCP server.
3. Isolating an issue with name resolution to being with the firewall, and not with a DNS server

In all cases I had understanding of the respective protocols and was able to compare how it's supposed to work to what I was observing....from there I isolated and reached a solution.

@nishantvshah, You can still observe the protocol in action even if there is no issue on the machine. You would just be watching the protocol working "as designed." I'd recommend starting off with basic, everyday protocols such as DHCP, DNS, and HTTP. First you have to understand how the protocol works (so read up a little on each) and then install Wireshark or other sniffer on a workstation to just observe. After you observe it, read more about it so you know exactly why it's working the way it's working.