MS SMB WAN File Transfer Speeds

[Benny]

Firstly, anyone got an experts exchange login I can borrow?

Basically we have a WAN link where internet and all other traffic flies, file copies etc run like crap.

It's got to be to do with window sizes and all that crap, but I can't find anything on it.
This sounds similar, but I'm not paying to find out.
http://209.85.229.132/search?q=cache:phuYSQPYiewJ:www.experts-exchange.com/OS/Microsoft_Operating_Systems/Windows/XP/Q_21438646.html+http://www.experts-exchange.com/OS/Microsoft_Operating_Systems/Windows/XP/Q_21438646.html&cd=1&hl=en&ct=clnk&gl=uk

So, WAN connection proved ok, WAN for specific MS is crap. Please don't answer with generic Micro$oft slurs.

[Jabbs]

I've had similar problems in the past when anti-virus software on the server decided to scan the file before the transfer.  Over a WAN this can slow things up.  Ok, I know this isn't exactly the same scenerio but worth considering.

What is the WAN speed?  I know it's probably not the problem if browsing is fast and even small files take an age but it's worth us knowing here to diagnose.

EDIT: Oh and do the same issues appear if you copy files using Command Prompt?  Is it certain types of files? And do you get the same issue if you are copying via a network path i.e. //servername/sharedfolder as you would if you had made a network drive i.e. X:\sharedfolder (where X is actually //servername/).  What OS's?

[no peanuts]

You do know that that link you specified does list the replies at the very bottom of the page without having to log-in?!!!!

Please say "NO", so we can have a little laugh at you :narnar:

Other than that I can't realy help much...sorry

[Anonymous]

You do know that that link you specified does list the replies at the very bottom of the page without having to log-in?!!!!

Please say "NO", so we can have a little laugh at you :narnar:

Other than that I can't realy help much...sorry

You must have a login as when I connect (when I am not logged in) you cannot see the answers.

[Jabbs]

You do know that that link you specified does list the replies at the very bottom of the page without having to log-in?!!!!

Please say "NO", so we can have a little laugh at you :narnar:

Other than that I can't realy help much...sorry

You mean this?  I just noticed this at the very bottom of the page:

ANSWER:

After a LOT of research and experimentation, this particular problem was due to the following factors...

1. Internet Routers between our two VPN boxes were dropping certain packets because the VPN encapsulated packet size was larger than the MTU of the intermediate network media. This was determined by performing a ping between the two networks (both over the VPN and to the non-encypted side of the one of the remote VPN machine) using the -f (no fragment) and -l (payload length) flags and successively reducing the payload size until a successful ping was achieved. e.g.

ping -f -l 1360

Note that the largest successful payload size was different on two days of the test. I can only presume that packets were routed via different paths over the internet on those two days. The lesson here is that if you find a value that works one day then everything breaks at some later date, recheck the permitted payload size.

Once a valid maximum payload size was determined, the XP client registry was updated to nominate the MTU size for the LAN network connection. Refer to method 3 the following article for instructions:

http://support.microsoft.com/default.aspx?scid=kb;en-us;314825

The next issue was that Kerberos authentication was failing because its UDP communications was being fragmented over the VPN. Windows Server 2003 and XP are forced to use TCP for Kerberos communications by reducing the maximum packet size registry setting to 1 (one). TCP allows correct reconstruction of fragmented packets even if they arrive out of order (which is quite possible for UDP packets). Hence, forcing Kerberos to use TCP is a safer alternative over a WAN. Refer to the following article for instructions to set Kerberos to use TCP/IP:

http://support.microsoft.com/default.aspx?scid=kb;en-us;244474

Finally, we were experiencing some dubious behaviour regarding the replication of our Windows Firewall group policy settings between the Win 2003 SBS and remote XP SP2 client machines. Even though the group policy was set to allow both subnets to exchange packets for "File and Printer Sharing", these settings were not being replicated to the remote client machines. We manually set the "File and Printer Sharing" exception on the remote client machines to have the following custom filter: "LocalSubnet,192.168.1.0/24,192.168.2.0/24".

Only one issue remains, which is that certain response packets sourced from port 139 on the Win 2003 SBS machine are still being dropped by the XP Client firewall. This is so, even though we can trace the corresponding XP client request to the SBS machine some eight seconds earlier. The firewall log shows the client machine opening a TCP connection from port xxxx to port 139 on the server and then subsequently closing that port. Approximately eight seconds later, the server attempts to open the a TCP connection from its port 139 to the client machine port xxxx. This connection is dropped by the XP client firewall.

The XP SP2 Windows Firewall has a 3 second limit on allowing responses from multicast messages. I'm not sure this is actually the cause of the dropped packet behaviour, but it is the only clue we have at present. I think the dropped packets are causing Windows Explorer (and hence Windows User Interface generally) to stall for a few seconds every now and then. Although irritating, it is not a show stopper. The file transfer problem that was causing us so much grief is certainly fixed by nominating the smaller MTU size and Kerberos transport protocol.

[no peanuts]

You must have a login as when I connect (when I am not logged in) you cannot see the answers.

Nope...I would'nt pay for something like that.

When I click the link, it shows me all the replies locked:
all comments and solutions are availiable to premium service members only. Sign up to view the solution to this question. Already a member? Login to view this solution.

Then it goes on to list all the categories. Followed by solutions. :g:

05/27/05 01:34 AM, ID: 14092623
   

Rank: Guru
IanTh:
Do you have QOS running as a service on the servers and pc's
       
   05/27/05 07:14 AM, ID: 14094908
   
mih:
Hi IanTh,

I don't believe I have any QoS services running on any of the machines. The XP Client has "QoS RSVP" listed in its available services but it is not activated and is set to "Manual" startup.

The XP Client has "QoS Packet Scheduler" listed as an inactive entry under the Local Area Connection Properties, and the Server doesn't list any connection properties that resemble QoS capabilities at all.

If you were hoping for specifics that I haven't addressed, please let me know.
       
   05/30/05 04:47 PM, ID: 14110133
   
mih:
FURTHER INFORMATION:

File transfers from the remote office (192.168.1.x) to the main office (192.168.2.x) file server using Windows Explorer seem to be (usually) quite fast. The slow copy problem only seems evident when copying files from the file server to a remote client machine. However, attempting to save a file from a Microsoft Office application on the client machine (such as an attachment from Outlook) to the file server is impossibly slow.

Could it be a DNS issue? Is the Windows Explorer file transfer protocol even interested in DNS?
       
   06/06/05 05:26 PM, ID: 14158335
   
mih:
ANSWER:

After a LOT of research and experimentation, this particular problem was due to the following factors...

1. Internet Routers between our two VPN boxes were dropping certain packets because the VPN encapsulated packet size was larger than the MTU of the intermediate network media. This was determined by performing a ping between the two networks (both over the VPN and to the non-encypted side of the one of the remote VPN machine) using the -f (no fragment) and -l (payload length) flags and successively reducing the payload size until a successful ping was achieved. e.g.

ping -f -l 1360

Note that the largest successful payload size was different on two days of the test. I can only presume that packets were routed via different paths over the internet on those two days. The lesson here is that if you find a value that works one day then everything breaks at some later date, recheck the permitted payload size.

Once a valid maximum payload size was determined, the XP client registry was updated to nominate the MTU size for the LAN network connection. Refer to method 3 the following article for instructions:

http://support.microsoft.com/default.aspx?scid=kb;en-us;314825

The next issue was that Kerberos authentication was failing because its UDP communications was being fragmented over the VPN. Windows Server 2003 and XP are forced to use TCP for Kerberos communications by reducing the maximum packet size registry setting to 1 (one). TCP allows correct reconstruction of fragmented packets even if they arrive out of order (which is quite possible for UDP packets). Hence, forcing Kerberos to use TCP is a safer alternative over a WAN. Refer to the following article for instructions to set Kerberos to use TCP/IP:

http://support.microsoft.com/default.aspx?scid=kb;en-us;244474

Finally, we were experiencing some dubious behaviour regarding the replication of our Windows Firewall group policy settings between the Win 2003 SBS and remote XP SP2 client machines. Even though the group policy was set to allow both subnets to exchange packets for "File and Printer Sharing", these settings were not being replicated to the remote client machines. We manually set the "File and Printer Sharing" exception on the remote client machines to have the following custom filter: "LocalSubnet,192.168.1.0/24,192.168.2.0/24".

Only one issue remains, which is that certain response packets sourced from port 139 on the Win 2003 SBS machine are still being dropped by the XP Client firewall. This is so, even though we can trace the corresponding XP client request to the SBS machine some eight seconds earlier. The firewall log shows the client machine opening a TCP connection from port xxxx to port 139 on the server and then subsequently closing that port. Approximately eight seconds later, the server attempts to open the a TCP connection from its port 139 to the client machine port xxxx. This connection is dropped by the XP client firewall.

The XP SP2 Windows Firewall has a 3 second limit on allowing responses from multicast messages. I'm not sure this is actually the cause of the dropped packet behaviour, but it is the only clue we have at present. I think the dropped packets are causing Windows Explorer (and hence Windows User Interface generally) to stall for a few seconds every now and then. Although irritating, it is not a show stopper. The file transfer problem that was causing us so much grief is certainly fixed by nominating the smaller MTU size and Kerberos transport protocol.

EDIT: Just tried some other topics on experts-exchange and it's the same there. I see the login button at the top. there's a question, locked answers, categories and then unlocked answers. :sideways:
are the answers here locked for you too?

[Jabbs]

By the way, here is a Wiki article on MTU sizes which might help

[Anonymous]

EDIT: Just tried some other topics on experts-exchange and it's the same there. I see the login button at the top. there's a question, locked answers, categories and then unlocked answers. :sideways:
are the answers here locked for you too?

Yup

Edit - bleedin minimum of 4 letters crap filter thingy gets my goat when all I need to say is YES

[Benny]

You need to clear your cookies then block the site from giving you any. Or use the cached pages from google a la the first link