F5F Stay Refreshed Power Users Networks Unusual actions from Odd NFS client Behavior patterns observed in the client

Unusual actions from Odd NFS client Behavior patterns observed in the client

Unusual actions from Odd NFS client Behavior patterns observed in the client

J
Jyok
Member
Find
144
01-22-2023, 12:37 AM
#1
I have two interfaces on my NAS, 192.168.1.253 which is on the LAN and 192.168.192.253 which is directly connected to my desktop. My desktop has 192.168.1.1 assigned by DHCP on a 2.5Gbit NIC and 192.168.192.1 static IP on its on-board gigabit connected to the NAS. I was originally going to use NFS multipathing to combine both links but there is so little documentation on it, I couldn't figure out how to do it. So as an alternative I decided to try mounting one of my shares on the Gigabit link instead of the LAN. Server: /etc/exports /home/alexatkin 192.168.1.1(rw,no_subtree_check) /home/newsbin 192.168.1.1(rw,no_subtree_check,all_squash,anonuid=1002,anongid=100) 192.168.192.1(rw,no_subtree_check,all_squash,anonuid=1002,anongid=100) Client: /etc/fstab server:/home/alexatkin /home/alexatkin/Server/Documents nfs4 noatime,bg,tcp,actimeo=1800 0 0 192.168.192.253:/home/newsbin /home/alexatkin/Server/Newsbin nfs4 noatime,bg,tcp,actimeo=1800 0 0 But NFS for some bizarre reason is mounting the second entry like this: server:/home/newsbin on /home/alexatkin/Server/Newsbin type nfs4 (rw,noatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,acregmin=1800,acregmax=1800,acdirmin=1800,acdirmax=1800,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.1,local_lock=none,addr=192.168.1.253) Even if NFS has realised its the same NFS server, why would it ignore my explicit instruction to mount by a specific IP address? That IP address is not in DNS, it does not resolve to server. What's even more puzzling is the client routing table shows: Destination Gateway Genmask Flags Metric Ref Use Iface default Router.lan 0.0.0.0 UG 101 0 0 enp1s0f2u1 192.168.1.0 0.0.0.0 255.255.255.0 U 101 0 0 enp1s0f2u1 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 192.168.192.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s31f6 So surely it should prioritise 192.168.192.253 anyway if it knows there are multiple paths to the server? If I run iperf3 or ping to 192.168.192.253, it goes over the correct interface. Why is NFS behaving differently? I could probably remove the export for that share over the LAN as its not needed, but I really want to know why NFS is behaving like this as I may wish to do it with other shares which ARE shared to the whole LAN. Worth noting is I did used to mount this share using the server:path but both client and server has been rebooted since then so it shouldn't be remembering that session.
Reply
Reply
J
Jyok
01-22-2023, 12:37 AM #1

I have two interfaces on my NAS, 192.168.1.253 which is on the LAN and 192.168.192.253 which is directly connected to my desktop. My desktop has 192.168.1.1 assigned by DHCP on a 2.5Gbit NIC and 192.168.192.1 static IP on its on-board gigabit connected to the NAS. I was originally going to use NFS multipathing to combine both links but there is so little documentation on it, I couldn't figure out how to do it. So as an alternative I decided to try mounting one of my shares on the Gigabit link instead of the LAN. Server: /etc/exports /home/alexatkin 192.168.1.1(rw,no_subtree_check) /home/newsbin 192.168.1.1(rw,no_subtree_check,all_squash,anonuid=1002,anongid=100) 192.168.192.1(rw,no_subtree_check,all_squash,anonuid=1002,anongid=100) Client: /etc/fstab server:/home/alexatkin /home/alexatkin/Server/Documents nfs4 noatime,bg,tcp,actimeo=1800 0 0 192.168.192.253:/home/newsbin /home/alexatkin/Server/Newsbin nfs4 noatime,bg,tcp,actimeo=1800 0 0 But NFS for some bizarre reason is mounting the second entry like this: server:/home/newsbin on /home/alexatkin/Server/Newsbin type nfs4 (rw,noatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,acregmin=1800,acregmax=1800,acdirmin=1800,acdirmax=1800,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.1,local_lock=none,addr=192.168.1.253) Even if NFS has realised its the same NFS server, why would it ignore my explicit instruction to mount by a specific IP address? That IP address is not in DNS, it does not resolve to server. What's even more puzzling is the client routing table shows: Destination Gateway Genmask Flags Metric Ref Use Iface default Router.lan 0.0.0.0 UG 101 0 0 enp1s0f2u1 192.168.1.0 0.0.0.0 255.255.255.0 U 101 0 0 enp1s0f2u1 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 192.168.192.0 0.0.0.0 255.255.255.0 U 100 0 0 enp0s31f6 So surely it should prioritise 192.168.192.253 anyway if it knows there are multiple paths to the server? If I run iperf3 or ping to 192.168.192.253, it goes over the correct interface. Why is NFS behaving differently? I could probably remove the export for that share over the LAN as its not needed, but I really want to know why NFS is behaving like this as I may wish to do it with other shares which ARE shared to the whole LAN. Worth noting is I did used to mount this share using the server:path but both client and server has been rebooted since then so it shouldn't be remembering that session.

Reply
Reply