Hi, I was wondering if someone could assist me or guide me on what could be the issue, Recently have had some users complaining of the network a tad bit slow, Im currently running pfSense and did a packet capture though pfSense let run about 3mins. After looking over it saw a lots of ARP requests and a handful of Spanning-tree but in black, I was reading about the Spanning-tree , and correct me if im wrong which is to ensure a loop-free topology for any bridged Ethernet local area network. Right now our Setup is 2 HP switches which the 2nd switch connects to switch 1 nothing complex. But on wireshark it shows Black and saying that the packet was wrong (see packet capture), Also for the ARP request I find it odd because all the LAN has Static IP the DHCP server and the user should not be looking for "who has". Then we also have an SQL server express which run an MRP, which shows the users how long it takes to fill a box in production, they told me it lags alot on chrome, after running the test i saw many TCP retransmission's, but the question is how can debug this or track down the issue? Im attaching the wireshark with the filters https://www.mediafire.com/folder/s87uotce7v5wuhm,bzaa43ba6yv6ke2/shared Thank you asked 12 May '17, 16:19  killmasta93 |
One Answer:
So all in all, no problem in your files. answered 13 May '17, 02:02  Jasper ♦♦ |
Thanks for the reply, Wow very interesting answer, especially number 3 did not know it can capture the packet twice. So when looking at issue s at latency in a network how can one check it? Been reading and studying about this and most of them say its TCP packet drops or either loops or excessive ARP requests, or i guess what is normal of amount of ARP request?
Thank you
For more information about TCP analysis and how duplicates can create chaos, check https://blog.packet-foo.com/2015/03/tcp-analysis-and-the-five-tuple/
TCP packet loss is the most common reason for latency issues, yes. One way to check if there's really packet loss (and not just retransmissions caused by duplicates) is to verify if you have "previous packet not captured" messages in you capture - if there are none, you don't have packet loss. If you have them, check if there's retransmissions matching the lost sequence numbers, because otherwise it may just be another capture problem.
Loops aren't really causing latency (well, they do, but that's insignificant in this case), but usually bring whole networks itto a complete overload situation. Which means that basically all communication comes to a halt.
ARP requests are more or less frequent, and you can try to find devices using excessive ARP. But once a TCP communication starts, ARP isn't involved anymore. So I wouldn't worry that much about it in a TCP latency troubleshooting situation.