cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1230
Views
0
Helpful
6
Replies

A file share issue on MPLS network

patr_zhang
Level 1
Level 1

My custmor have a intranet based carrier's MPLS backbone.CEs has no restriction on data transfer,custmor site-A and site-B can ping each other successfully.

The issue is server-A in site-A and Server-B in site-B are windows 2000 server.Both of these servers can browse shared folder and files each other.

Server-A can copy file shared by server-B from server-B.Server-B can't copy file shared from server-A by input server-A's ip address in brower.

I did some test:

test 1: replaced server-A with a WinXP notebook,it can put file to server-B,it works well.

test2:PCs which on the same segment as server-A can copy file from server-A successfully.

FTP test is same as file copying in windows system,server-B can't get file from server-A using FTP tool.

Why?

6 Replies 6

attrgautam
Level 5
Level 5

This looks a MTU problem. Pls check if you have enabled jumbo frames on the LSP and Check the MTU on the path in between. See if you tweak the MSS at the server end and see if it helps as well.

I quite agree with, sounds like an MTU issue. You can use the ping tool to check also. Ping with various sizes (with df-bit on) and look for the size at which it start to timeout.

(Note -f is for do not fragment, -l for the size of packet).

Knowing the size often gives an idea of where the MTU issue might be i.e.

4 byte - Vlan or 1 MPLS label imposition

8 byte - 2 MPLS label (MPLS VPN)

24 Byte - IP Header (GRE Tunnel)

Thanks for you reply!

I have ping from router-A to router-B and from router-B to router-A,both the largest packet size is 1496byte.

How do you explain that copy file from server-B to server-A success but copy file from server-A to server-B failed

Well, the ping of 1496 confirms that you have an MUT issue. What to note is that when pinging, you sent a packet of 1496 bytes and also recieved 1496. So it does not really matter where you are pinging from, the MTU issue can be in eihter direction.

When downloading a file, the request and acknowledgement packets (upstream) are small, much more lower than 1500 bytes. But if the file is larger than 1500 bytes, it is broken down into chuncks of 1500bytes and sent like that.

I'm not sure of why the download goes one, (it could be TCP MSS setting on the server or routers). Please also note that MTU applies to the transmission, and that the trasmitting interface from A to B, would be a recieving interface from B to A.

Do you have vlans? I would watch out for there because of your 4 bytes overhead. It could also be a label impostion.

Check the following link to help you troubleshoot. While it does not mention MPLS, the technique for resolution are similar.

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tech_note09186a0080093f1f.shtml

I have add 'EnablePMTUDiscovery' under '[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

' to registe file to make source site can negotiate TCP MSS with destination site.

Everything is ok.

Thanks for your help!

I think, this problem occurs because server message block (SMB) write operations to a Windows 2000 may experience a delay of up to 200 milliseconds.You can edit the TcpDelAckTicks registry value to adjust the TCP delayed ACK timer. If you change the TCP delayed ACK timer to a lower value, the server sends an ACK packet more frequently but at shorter intervals.Apply the latest service for Windows 2000 so that you can modify the delayed ACK timer value.From MS:

1. Start Registry Editor (Regedt32.exe).

2. Locate and click the following key in the registry, where Adapter GUID is the globally unique identifier (GUID) for the network adapter that connects to the clients:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\Adapter GUID

3. On the Edit menu, click Add Value, and then add the following registry value:

Value name: TcpDelAckTicks

Data type: REG_DWORD

Value data: You can set this value to a range from 0 to 6. The default setting is 2 (200 milliseconds).

4. Quit Registry Editor.

5. Restart Windows for this change to take effect.

This registry value specifies the number of 100-millisecond intervals to use for the delayed ACK timer on a per-interface basis. By default, the delayed ACK timer value is 200 milliseconds. If you set the TcpDelAckTicks value to 0, delayed acknowledgments are disabled. This setting causes the computer to immediately send an ACK packet for every packet it receives.