We have a slow backup server. Intermittently basic iperf3 results with no special command line switches is reading 0.00 toward the beginning of a TCP session (see below). This doesn't happen to other servers on the network, and it doesn't happen to the loopback from the server (a case for why it is not the server). Physical cable and SFP modules were swapped without change.
- [ ID] Interval Transfer Bandwidth
- [ 4] 0.00-1.00 sec 98.1 MBytes 823 Mbits/sec
- [ 4] 1.00-2.00 sec 73.5 MBytes 617 Mbits/sec
- [ 4] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec
- [ 4] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec
- [ 4] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec
- [ 4] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec
- [ 4] 6.00-7.01 sec 5.75 MBytes 48.0 Mbits/sec
- [ 4] 7.01-8.01 sec 101 MBytes 850 Mbits/sec
- [ 4] 8.01-9.00 sec 99.2 MBytes 838 Mbits/sec
- [ 4] 9.00-10.01 sec 79.2 MBytes 662 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - - -
- [ ID] Interval Transfer Bandwidth
- [ 4] 0.00-10.01 sec 457 MBytes 383 Mbits/sec sender
- [ 4] 0.00-10.01 sec 457 MBytes 383 Mbits/sec receiver
There is a single interesting Wireshark message that states "TCP Window Full". Implying that no response has been received from the server for a while. This appears to correspond.
Pings and UDP iperf3 tests appear to work fine so far but more testing is in order.
I am in the classic position of having to prove the network innocent. Any tips? Does this prove my case if there is a single network device between test targets and there is no drops on either involved interface?
P.S. The test above is to a slow device. This was to more easily capture all related packets. The backup server is capable of realizing 6gig/s TCP sessions and has the same intermittent 0.00 bit/sec behavior.
P.S.2. Sorry about the table spacing
No comments:
Post a Comment