ARP problems can typically cause that, and that's most easily troubleshot using show commands on your switch and/or router.Īttempt: ICMP is working to the server, but SSH is not. It doesn't cause packets with the wrong destination address to reach a host.

Response: That's not how asymmetric routing works. Next!Īttempt: How are you going to verify asymmetric routing? Only Wireshark can show you if packets with the wrong destination address are reaching a host.

Anyway, Netflow is the best answer, if the question is 'verify that the traffic is being marked with the proper DSCP.' Why would you EVER default to pulling captures and viewing them in Wireshark when Netflow, SFLOW, etc can easily tell you what traffic is going across your device, and if it has any DSCP markings. My Response: Netflow, or even show policy-map interface and verify that the counters for Priority Queue and Signaling Queue are incrementing. What easier way to do this is there than viewing their traffic in Wireshark? Here were some of the attempts at answering my inquiry, and my replies to them.Īttempt: A VoIP Customer (apparently you are working at a UCaaS vendor?) is complaining of call drops and quality issues, and wants you to verify that their traffic is being marked with the proper DSCP values. You're doing someone else's job for them. You are NOT troubleshooting a network issue at that point. At that point you're doing the application owner's or the server owner's job for them. If you want to see if a server didn't send a SYN+ACK, or see what error message it sent, something like that, that's not a Networking problem. I stand by what I said, that for a Networking Engineer, you don't need to EVER go to Wireshark to solve any NETWORKING problem. Name any situation where a NETWORKING problem (read: layers 1-3, something that you would have to fix on a switch or router) where you could only, or most easily, solve the problem by jumping to Wireshark and looking at packet captures.Īnd honestly, no one was able to answer it. However, I also posed a question in response to my backlash: If I'm wrong, prove me wrong. (At least for this sub.) That comment was that a good networking engineer didn't really need to learn how to read packet captures in Wireshark as a core networking skill, because our primary responsibilities are layers 1 through 3, and you should never need to open up Wireshark to troubleshoot ANY issue in those layers.

Yesterday I made a semi-obnoxious comment in another thread that got me downvoted pretty hard.

Wireshark pcap problem