Troubleshooting a One-Way Performance Issue – PacketBomb
   

Troubleshooting a One-Way Performance Issue

By Kary | case study

Aug 16

Here’s a fun case study on troubleshooting a one-way performance issue. Of course, the root cause for every one-way performance issue won’t be the same as this one, but it’s a bit of experience to add to your bag.

It’s very important when analyzing packets to take on the perspective of the host from which you captured the data. If it’s the receiving side, then think like the receiver. If it’s the sender side, then think like the sender. To do that and have it lead you to a root cause requires knowledge of what you should expect to see and just plain ol’ experience. So keep at it.

Let me tell you, there was over an hour’s worth of TCP goodness to talk about in this case study so I tried to focus only on the issue at hand to keep it to a reasonable time. I will be coming back to this case study to talk about TCP behavior in-depth in the future.

Download the Wireshark profile from this video. Unzip and copy folder to the Wireshark Preferences folder.

Download the pcaps from the video: client and server

Share this post! Spread the packet gospel!

Facebooktwitterredditlinkedinmail
Follow

About the Author

I like being the hero. Being able to drop a bucket of root cause analysis on a burning network problem has made me a hero (to some people) and it feels real good, y’all. Get good at packet analysis and be the hero too. I also like french fries.

Leave a Comment:

(5) comments

Helmuth August 18, 2015

I knew how important in troubleshooting it is to have traces from both sides but I never had in mind that using realtive Seq Numbers in Wireshark, could make me blind for issues like this.

Another brilliant investigation!

learned a lot – many thanks.

regards
Helmuth

Reply
Vladimir August 25, 2015

Why was it affecting only one-way traffic?
This firewall had to do the same thing in both directions (or no?)..
Or maybe other-way traffic was flawing by another path without that device?

Thanks for the video!

Reply
    Erik Weathers May 16, 2016

    @Vladimir: I believe this problem only affected the server-to-client direction was because the packet that got lost (dropped) was headed that direction. So the SACKs + Duplicate ACKs only needed to be used in that direction to get the server to resend the missing segment but not the rest of the subsequent TCP data that the client successfully received (and SACKed).

    Reply
John April 2, 2017

Hi, getting a 404 tonight on the dropbox pcap download

Reply
    Kary April 4, 2017

    Dropbox changed the public folder settings. Fixed.

    Reply
Add Your Reply

Leave a Comment:

Previous Post Troubleshooting MTU Problems With Wireshark Next Post Troubleshooting Slow FTP Uploads