Hi There, Network background: I got a call from a company to troubleshoot many issues including poor connectivity in sections of their office. The network setup was pretty simple, ISP to router, router to cisco smb 200 managed switch, from it an up link to another cisco smb 16 port switch (not managed) in another room, and finally from it an uplink to another cisco sbm 200 switch in another room (not managed). Users connected to the managed switch (the one connected to the router) had no issues. The rest of the office (those connected via uplink) experienced awful network issues, to be exact network was slow. From the problem area I had network connection and was able to browse the web but at an unacceptable performance. I ran wireshark and notice a lot of retransmission and many small windows size value and unknown windows scaling value. After verifying that the the uplinks and port settings were working fine I decided to swap the cisco smb 16 port with another one unit, once it did it magic happened and everything worked fine. The questions I have is: What could've been the best way to use wireshark for troubleshooting this issue? what should I have looked into wireshark to find out that the switch was the issue? Should I have installed wireshark on different sections of the network and capture communication two way communication instead? I'm glad the problem is fixed but now that i'm reviewing the issue I realized I missed something in the capture that would've pointed me to the root cause. Thanks in advanced... asked 13 Sep '13, 06:56  kjzd28b |
One Answer:
Usually, I'd move the sniffer through the network path (from bad to good), and capture (if possible) on both sides of the device in question. If the device is a switch I'd use network TAPs on both sides because I can't trust the SPAN ports on the device I don't trust (transitive mistrust, so to speak :-)) Then comes the (sometimes) hard part: compare the two traces to see what went in, and what came out. It helps to narrow it down to a single bad connection to quickly find it in both traces. answered 13 Sep '13, 07:15  Jasper ♦♦ thanks jasper and kurt, i think that considering the retransmission issue helps isolate the issue to a L1 or L2. I didn't have network taps with me and the faulty switch wasn't managed so I couldn't span the port. Japer, when you capture on both sides and compare the traces you have tons of data from everyone on both sides of the switch, what do you look at to narrow it down? (14 Sep '13, 07:41) kjzd28b I'd use a specific PC to do some tests from the "bad" location. This way I can narrow the traces down to IP and (often) a few ports. Finding TCP conversations is not that hard - filter both on the same IP and port pairs, and use the absolute sequence numbers to match packets. (14 Sep '13, 14:04) Jasper ♦♦ |
I don't think so.
Obviously it depends on the problem within the switch, but usually you won't see a direct indicator in the capture file, other than TCP retransmissions and that could have been caused by everything in the network.
The correct think to do, is already described by @Jasper.