Hi, Problem: The users experience a frequent disconnection. We have run wireshark on the PC of the user who was complaining. During the capture, he was connected to a few servers (setup explanation coming below) and claims his database connectivity & his SSH connections got disconnected. The wireshark capture also shows a lot of HTTP traffic originating from this user going out onto the internet. Link to sanitised file: https://www.cloudshark.org/captures/812a16a5d79a Setup: UserPC (Wireshark Running) -> Cisco Layer 2 Switch -> CoreSwitch -> IDS/IPS -> Core Firewall -> DMZ Firewall -> Perimeter IDS/IPS -> Perimeter Firewall -> Internet User Connections: 1. Connected to servers in the server VLAN (Database, SSH, ERP etc.) 2. Connected to websites on the internet Review of Capture: There is a spike in HTTP Traffic for 4-5 seconds. Second 1 - 130000 bytes Second 2 - 160000 bytes Second 3 - 550000 bytes Second 4 - 300000 bytes Second 5 - 150000 bytes During this time, there is a spike in TCP out of order packets (mainly due to HTTP). And the user experienced a network issue at this time. How should we analyse this situation? Thanks asked 02 Oct '14, 19:56  raymondw edited 13 Oct '14, 21:25 |
2 Answers:
The out of order packets are due to the IDS/FW/Proxy sending to you using a reduced MSS of 1360 while receiving data at a MSS 1460 from the internet. This leads to 2 segments being sent to you: one with 1360 bytes and one with 100 bytes. Regards Matthias answered 14 Oct '14, 08:48  mrEEde |
Hard to say without a look at the capture itself, because even though there is a lot of scenario description it does not really help that much. Something like "there is a spike for x seconds" is way to unspecific for any conclusion. My advice would be either to post a capture, e.g. at Cloudshark (sanitize it first if necessary, e.g by using TraceWrangler) and have someone here look at it. If you can't do that you'll have to look for signs of trouble in your capture, e.g. by searching for TCP reset packets that indicate session problems. The trouble with that is that you need some experience to do that because there are resets that are perfectly normal and expected. You can also try to filter on "tcp.analysis.flags" to see if you have interesting expert symptoms - but still, a skilled analyst is often required to tell which ones are important and which can be ignored. answered 03 Oct '14, 03:50  Jasper ♦♦ |
Thank you Jasper.
I will sanitize and upload at cloudshark in a day. Thanks for the suggestion.
I have already seen the "tcp.analysis.flags". I didn't feel there was anything wrong with that. But, will look at it again, just in case.
Hi Jasper,
I have uploaded the sanitized trace file in cloudshark. Can I send you the link to the file?
Thanks
Edit your question with the link.