Windows file sharing issues

[touchstone_81]

Hi been having an issue thats driving me crazy.hopefully i am addressing this in the right forum.

Problem: Share access to a netapp storage box is fast when accessed by name i.e., \\netapps

but takes a long time when accessed by ip i.e., \\10.*.*.*

Netapps OS: Unix

Windows DC OS: win2003

DNS: active directory integrated.

Netapps support say the issue is with windows DNS, which i cannot agree because the name is being resolved and the host records are properly set up, verified this with nslookup.

If i am not mistaken when i use \\ip dns should not come into the picture right?

Also when the share is accessed by \\ip it opens up after like 20 seconds,and clicking on a share gives a system busy cursor symbol after which it eventually does open the share.

This does not happen when share is accessed by name.

This is seen to be happening across all clients in our domain.

Somebody please help.

[cluberti]

Might be extremely interesting to get a network trace from the client accessing the share, one when accessing by IP, one when accessing by DNS. What's different? If they appear the same (other than huge delays in the \\IP access trace), then the problem is on the filer itself. Knowing that netapp filers sometimes have issues with ldap lookups, if your filer is configured to lookup AD or some other LDAP user structure, this could cause it too. One other thing, if you're accessing \\DNSNAME you may be using kerberos - \\IP forces NTLM, so you may have an NTLM issue on the network as well, perhaps your timeout is waiting for the netapp to timeout on a lookup?

Gotta get those network traces (wireshark or netmon will work on a windows box).

[touchstone_81]

Great let me get the trace. &

Thanks for the quick response.

[touchstone_81]

Hi Cluberti i captured two sets of trace's. each set included,one with IP and another with name.

The second set was captured in a new logon session.

I have never used wireshark before so maybe i am not looking for the correct info.But here is what i did:

in wireshark there is an option "analyze" under that went to expert info and there i could see that:

1. when accessed using IP

There were no connections to the DC from the client

2. when accessed using name

there was a connection to the DC from the client.

Not sure if that is significant though.

There was mention of NTLM in both.Apart from that couldnt notice much difference.

Hey Cluberti do you think you have the time to look at the trace?

[cluberti]

Hey Cluberti do you think you have the time to look at the trace?

Put it somewhere and let me know where I can grab it. Also, let me know the IP addresses of the netapp and the client(s). I'll try to get to it when I can.

[touchstone_81]

Hi Cluberti find the link for the trace below.The info you asked has been enclosed.

http://www.2shared.com/file/3380022/70dc1f...work_trace.html

Please do look at it when you get the time and lend your thoughts on the same.

[cluberti]

I looked - when you're connecting by name, you're using kerberos over SMB and your session is setup within 2 hundredths of a second. However, when you connect by IP, the client and server do the same negotiate protocol handshake, the client chooses NTLMSSP_NEGOTIATE, the netapp sends an NTLMSSP_CHALLENGE request, the client sends the netapp it's credentials (AONIN1\netsoladm), the netapp ACKs the cred packet, but doesn't respond with the Session Setup AndX Response packet for 16 seconds.

The problem is likely on the netapp . The client shows no delays, but the netapp appears to be having trouble with NTLM. Were you able to get the netapp folks to gather a trace from the netapp when you were using the IP to connect? There's nothing client-side here that is at fault, so you'll have to get them to show you what happened on the netapp during those 16 seconds.

[touchstone_81]

hey thats great cluberti.Thank you for sharing your views;and no although netapps support was very helpful their efforts were pretty much centered around proving that DNS was the culprit, and what's more some of our own people were convinced that it was indeed dns.this made it all the more frustrating.

Anyways i had told netapps to put the issue on hold so will go back to them with the new findings thanks to you and see what they say about that.