One way throughput problem
Connectivity: Host A ----- Switch ----- Router ----- Router ----- Switch ----- Host B
IP:
Host A: 10.10.10.1
Host B: 10.10.10.2
Host A and B are connected through Router and Switch over an EVPN VPWS tunnel. When transferring data from Host B to Host A, not getting throughput more than 20 Mbps in a single session. However, when transferring data in the opposite direction from Host A to Host B, getting 97 Mbps in a single session. There is no packet loss between Routers. Need help to troubleshoot one way throughput issue.
Capture for file transfer from Host B to Host A:
Host A: https://drive.google.com/file/d/1l1yr...
Host B: https://drive.google.com/file/d/1zBp-...
Capture for file transfer from Host A to Host B:
Host A: https://drive.google.com/file/d/1tlt3...
Host B: https://drive.google.com/file/d/1aBDv...
Thank You.
Those capture files (B>-A files > 200MB; A->B files > 600 MB) are kinda big for analysis.
Can you describe the "transferring data" (protocol, application, type of data) to give some insight to how the files might be pared down.
"Upload_from_10.10.10.2-Capture_from_10.10.10.1.pcapng (241M) is too large for Google to scan for viruses. Would you still like to download this file?"
Good day Chuckc.
File transferred over HTTP (TCP, Port 80) using HTTPFileServer.
For the file transfer from Host B > Host A, I noticed a very high number of tcp.analysis.flags on both sides, but at Host A it is higher (55%) than at Host B (27%). At Host A, TCP Out-of-Order is also relatively high.
However, tcp.analysis.flags for the file transfer session from Host A > Host B are 7% and 2%.
Suspecting Tx path issue from Host B > Host A. Need guidance to identify the actual point of failure and the root cause.
hi
If you plug in Host C in to the same switch where Host A is connected are you able to reproduce the problem? can you do the same test but this time connect Host C to the switch where Host B is connected.
Also can you use iperf for your thruput test and post the results?
Upload_from_10.10.10.2-Capture_from_10.10.10.2.pcapng - 3 way handshake isn't captured
Looks like this is the HTTP server OP is using - > https://sourceforge.net/projects/hfs/...
Hi @net_tech Trying to share the result of the suggested environment using Host C at both side and iperf.
Yes, HFS HTTTP file server used for throughput test.
What Windows OS is being used on a server where HFS is installed / running? Can you also run iperf between hosts A and B in both directions and share the capture results
Also, when making new packet captures, please start your capture before doing the tests so that the 3-way handshake will be captured too.
@net_tech both side OS is 64bit Windows 10. Will share capture for iperf.
@SYN-bit, noted.
Shall I use iperf with the default parameters or any specific requirement?
yes, defaults are fine. -s for server -c for client
@net_tech and @SYN-bit The pcap files for iperf TCP and UDP 10 seconds session between Host A <> Host B stored as compressed file (.rar) in the following google drive url.
https://drive.google.com/file/d/1W9e6...
@net_tech The pcap files for iperf TCP and UDP 10 seconds session between Host A <> Host C connected in the same switch are uploaded as compressed (.rar) in the following google drive url. As Host B is located in the remote site, not able to generate Host B <> Host C on the same switch scenario.
https://drive.google.com/file/d/1ssN0...
Before uploading in google drive, both the files were checked with antivirus and found clean.
OS:- Host A: 64-bit Windows 10, Host B: 64-bit Windows 11, Host C: 64-bit Windows 10
Thanks for your time.
You are getting almost wirespeed when you are testing A->C (984Mbps)
A Hardware: 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz (with SSE4.2) OS:64-bit Windows 10 (2009), build 22631 Application: Dumpcap (Wireshark) 3.0.6 (v3.0.6-0-g908c8e357d0f)
C->A Is slightly less, negligible difference on the grand scheme of things (905Mpbs). Here you have 0.1% of TCP Window Full (260 out of 202,263 packets) where host C is telling host A to hold up as it can't empty the buffer fast enough to receive more data.
C Hardware: Intel(R) Core(TM) i5-1035G1 CPU @ 1.00GHz (with SSE4.2) OS:64-bit Windows 10 (22H2), build 19045 Application: Dumpcap (Wireshark) 4.0.2 (v4.0.2-0-g415456d13370)
If you can do the same test at the remote site and get B<->C iperf tests, we would be able to rule out host B. Until then the ...(more)