Does anyone experience the Spoke to Spoke file transfer bandwidth degration issue?

[jl20]

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.

[PhilipDAth]

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.

[jl20]

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.

[PhilipDAth]

If it makes things better - use it as a permanent fix.

[jl20]

Just tried the suggestion and didn't get better result.

[PhilipDAth]

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?

[KarstenI]

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.