This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Latency for SMB protocol over internet IPSEC

0

Hi anyone have issues after migrating from a dedicated point to point link like FR or T1 to a high latency 300ms+ INET IPSEC connection with a SMB file copy ??

attached is a very chatty pcap

asked 15 May '13, 11:25

franki21's gravatar image

franki21
1112
accept rate: 0%


2 Answers:

0

a high latency 300ms

300 ms latency? Well.... don't expect any wonders regarding throughput ;-))

attached is a very chatty pcap

Sorry, no link found.

Regards
Kurt

answered 15 May '13, 11:28

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

will post in a min

(15 May '13, 11:32) franki21

0

If you're using SMB (v1), then you can only tranfer one 64K block per RTT, so in your case that would mean about 192K which is about 1,5Mbit/s. But it could also be that your SMB client is using 4K blocks in which case you'll end up with about 100 Kbit/s.

So, please check the blocksize that is being used and the SMB version. This can be seen in the trace.

Also, when doing IPsec, make sure you adjust the MSS on the VPN devices to prevent IP fragmenting of full sized TCP segments. Also, when there is some packet loss, this can really slow things down.

You will benefit from a WAN optimizer if you want to do SMB over a high-latency link.

answered 15 May '13, 12:04

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

OK, looking at the trace file, I can see SMBv1 with a blocksize of 32K. This means a maximum transfer speed of about 750Kbit/s.

But there is packet loss (about 3% retransmissions) and therefor TCP is doing congestion avoidance. Therefor it is not fully streaming the data, resulting in extra RTT delays at the TCP level, waiting for ACK's.

The main thing to investigate is the packet-loss. Once that is resolved (if that is possible), you could benefit from a WAN optimization solution to conquer the effect of the high latency on SMB. You might also try to use SMBv2, which does not wait for acknowledgement of each block before sending the next one.

(15 May '13, 12:22) SYN-bit ♦♦

SMB ver 1, GRE tunnel interface over IPSEC in transport mode, ip mtu 1400, ip tcp adjust-mss 1360

this is by the way from US to Pune india, Routing looks normal, latency is still at 300ms up to 500ms at times

(15 May '13, 12:22) franki21

yep SMB v2 or move to FTP, user reporting 60-80kbps over a t1 file copy took 1 hour, now takes 3 over a 6MB ipsec GRE tunnel. bandwidth reporting shows not maxing out

Thanks for ALL response

(15 May '13, 12:26) franki21

Are yo seeing the block size int the smb header 0x32 ?

(15 May '13, 12:35) franki21