In the next screenshot, I’ve made the following changes: We’ll need to make some modifications to make this display a bit better. We’ll be using the same filter as above: Let’s add the retransmissions to the Graph 2 field. In this case, we already know why that happened – we started taking errors on an up-stream interface and experienced packet loss of +/- 50%.
The first thing that jumps out is that the PPS (packets per second) dropped. The IO Graph window opens and default displays the total count of packets per second. Let’s start by opening the IO Graph in Wireshark: Feel free to use these traces to work through the examples. The examples below were all created from this trace on pcapr. We’re going to walk through the process of graphing retransmissions for a single host, then look at how to compare the count of retransmissions for two hosts. If you open a trace file and see something that looks like the below screenshot, you’ll want to review the process for removing duplicate frames here. This is very common in data center capture architectures. Make sure you haven’t captured the same frame twice. It’s very easy for Wireshark to count a duplicate packet as a retransmission. Wireshark calculates TCP retransmissions based on SEQ/ACK number, IP ID, source and destination IP address, TCP Port, and the time the frame was received. It’s important to note that there is no flag or unique identifier associated with a TCP retransmission. Once we have this filter applied, we can begin to see how many retransmissions we’re seeing in the trace. The first step is to identify the retransmissions within the packet list with this filter: Identifying TCP Retransmissions in Wireshark The idea is that if the retransmissions are charted out, they are easier to compare to things like spikes in throughput, error count increments, or even server CPU/memory utilization. With this post, I want to share how to provide a visual reference of the count of retransmissions over time.
I’m going into this post with the assumption that we all understand what a retransmission is, and that TCP retransmissions could be a symptom of a problem – but not a cause. That said, let’s talk about TCP retransmissions.
Unfortunately, we need to step in every once in a while to make sure things are going as we designed. Fortunately for us, TCP does a great job of ensuring this happens for us without much intervention. As network engineers, our lives revolve around making sure data gets from point A to point B.
0 kommentar(er)
