I have faced similar problem and after analyzing the packet traces I am able to resolve this issue,
One of the possible reason for this :-
Clustered Data ONTAP has an option called fastpath. This allows the SVM to respond to a client without taking time to check the routing table. There are certain items that will not use fastpath, such as icmp. If you do not have a default route configured,icmp(ping), when initiated from the SVM, will fail.
In this case, the issue occurs as soon as there is packet loss on the wire. This is more likely to be seen with larger file transfers. The client is writing data and a packet does not reach the SVM. The client keeps sending data. The SVM receives these other packets, but will send a DupAck. This is to let the client know to resend the lost packet. The issue occurs because a DupAck does not use fastpath. So it will check the routing table, not find a route and drop the DupAck. The client will eventually start trying to retransmit the last non-acked packet, until it reaches a timeout and stops the stream.
Two methods to confirm:
Check if the default route is not configured for the Vserver: network route show -vserver <vserver> cluster::> network route show -vserver svm1 (8.2 command is network routing-groups route show) There are no entries matching your query.
Ping a working IP that is on a different subnet than the LIFs on the cluster: net ping -lif <svm1_lif1> -vserver <vserver> -destination <destination>
Add a default route: network route create -vserver <vserver> -destination 0.0.0.0/0 -gateway <gateway ip> Note: Data ONTAP 8.2.x requires a routing-group. For more information, see article3013489: Ethernet routing in Clustered Data ONTAP 8.0 and 8.1
Confirm the route was added: cluster::> network route show -vserver <vserver> Vserver Destination Gateway Metric ------------------- --------------- --------------- ------ <vserver> 0.0.0.0/0 <gateway ip> 20 <<<<<<< The new route is added
It seems to be a SMB problem with ONTAP 8. I tried to copy a big file from a NetApp filer with ONTAP 8 to my local Win 7 PC with windows explorer. The copy starts with 2 MB/s or less. Within a few minutes the copy slows down to < 1MB/s. Only reading is a problem, writing works fine. Also reading from a Windows Server 2003/2008 works fine. Seems to be a smb problem with ONTAP 8.
The same situation on a NetApp filer with an ONTAP 7.3.6 works fine.
Our workaround is:
Run Cmd with
netsh interface tcp set global autotuning=disabled
I'm having the same problem, but only on one share that's running on the first controller. Our other two shares on the second controller work fine. The settings are all the same, the only difference i've noticed is that when copying the large file, the share that fails is actually copying twice as fast as the other two shares that work.