We have tried to do windows file transfer between 2 spokes but the performance was very poor and was only able to get 3-4 Mbps. Spoke 1 & 2 both connects to the same hub.
Spoke 1 has 45Mpbs upload
Spoke 2 has 300Mbps download
Hub uses 100Mbps DIA.
Use Microsoft File Sharing to send a file from spoke 1 to spoke 2 and the transfer rate was only 3-4 Mbps.
The issue will go away if we do auto vpn full mesh, so it's not the ISP issue.
My personal guess - the Windows TCP stack is failing to handle different response times causing packet retransmission.
On the two computers being used, try enabling TCP timestamping as per this article and please retest.
http://ithitman.blogspot.com/2013/02/enabling-tcp-timestamp-linux-and-windows.html
On Windows:
netsh int tcp set global timestamps=enabled
On Windows I'm not 100% sure - but I think this setting might only take effect after a reboot.
Thank you for the reply.
Will this command solve the file transfer slow issue or just so we can get better test result?
During two support sessions, IPERF troubleshooting was performed.
We performed SMB transfer and support detected & captured Initial TCP3way (after several attempts).
Support said that's the expected performance.
If it makes things better - use it as a permanent fix.
Just tried the suggestion and didn't get better result.
If you do a packet capture on one of the clients during the file copy do you see any errors coming up, like packet retransmission or lost packets?
3 to 4 MBit for sure is too low. But be aware that with hub and spoke each packet has a decent amount of processing overhead on the hub. It has to be decrypted, processed, and encrypted again. If the two spokes (or one of them) is receiving much traffic, I would configure that device permanently as a hub.