Here is a link to a tcpdump of my desktop machine trying to tcp mount a nfs export.
http://romeodesktop.unet.maine.edu/desktop_mount_tcp_nfs.pcap
In this tcpdump, I try to mount the volume like so:
mount -o proto=tcp na2-vif2:/vol/vol0 /mnt/filer
# na2-vif2 has an ip address of 10.10.2.12 and the vif1 has an ip address of 10.10.2.10
and as the tcpdump shows the filer responds to the initial getport calls from vif1. It eventually seems to respond out of vif2 and then things proceed to mount up after 30 seconds or so.--
On Fri, Apr 2, 2010 at 12:05 AM, Steve Francis <sfrancis@logicmonitor.com> wrote:
Huh - well that seems to indicate something else odd in the network setup.
Does a tcpdump from the host trying to mount the volume show the
return TCP packet being sourced with the incorrect IP? Or is it not
making back to the host if it exits out the "wrong" vif?
On Thu, Apr 1, 2010 at 7:59 AM, Romeo Theriault
<romeotheriault@gmail.com> wrote:
> I get the same behavior regardless of if I try to mount with udp or tcp.
>
> On Thu, Apr 1, 2010 at 11:53 PM, Steve Francis <sfrancis@logicmonitor.com>
> wrote:
>>
>> You could also switch to TCP mounts, instead of UDP (which I'm just
>> assuming you are currently using.)
>> Fastpath should be the answer, but with fastpath off, UDP packets that
>> were sent to VIF1, that are replied to by VIF2 (due to the filers
>> route table), will have a source address of VIF2 (and hence be dropped
>> by the mounting system.) TCP packets will be source with the IP
>> address of the destination interface on the filer, regardless of the
>> egress interface.
>>
>> So switching to TCP mounts will make your current config work rapidly,
>> but not necessarily with the transit paths as you want.
>>
>> (The above is characteristic of UDP - not just NetApps.)
>
Romeo Theriault
System Administrator
Information Technology Services