NFS v4 mounts pointing to multihomed systems do not appear as expected

SUSE Linux Enterprise Server 15
SUSE Linux Enterprise Server 12
SUSE Linux Enterprise Server 11

A NFS v4 client system has two or more mounts pointing to different IP addresses (or hostnames).  However, these IP addresses actually belong to the same remote host (a practice known as mulithoming).  For example, an /etc/fstab may contain:

Server1:/export1   /mnt1   nfs   vers=4.2    0  0
Server2:/export2   /mnt2   nfs   vers=4.2    0  0

"Server1" resolves to 192.168.1.1 and "Server2" resolves to 192.168.1.2.  However, both these IP address are bound to one NFS Server machine.

After the client mounts these, checking a list of current mounts from the "mount" command or from /proc/mounts may show that both show they are using the same hostname and "addr" parameter, even though they were configured different in /etc/fstab:

Server1:/export1 on /mnt1 type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.250,local_lock=none,addr=192.168.1.1)
Server1:/export2 on /mnt2 type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.250,local_lock=none,addr=192.168.1.1)

Or in some cases (possibly related to the total number of such mounts in question, possibly 3 or more) the data might show all the hostnames one way, but with all the "addr" parameters pointing to the IP that doesn't belong to that name.

Imagine that in addition to the 2 fstab entries above, there is also a 3rd entry, pointing to a 3rd export within the 2nd hostname:

Server2:/export3   /mnt3   nfs  vers=4.2   0 0

The results might be:

Server2:/export1 on /mnt1 type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.250,local_lock=none,addr=192.168.1.1)
Server2:/export2 on /mnt2 type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.250,local_lock=none,addr=192.168.1.1)
Server2:/export3 on /mnt3 type nfs4 (rw,relatime,vers=4.2,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.250,local_lock=none,addr=192.168.1.1)

 

This is expected behavior for NFS v4, due to a feature known as "trunking detection."
 

NFS v4 includes a feature known as "trunking detection" whereby the client detects when two (or more) different addresses lead to the same NFS Server.  This feature has evolved over time and may be implemented slightly differently in different versions of NFS 4.x (4.0, 4.1, 4.2).  Different kernel versions may contain slight variations as well.  Therefore, the behavior might not always match what is described in this document. 

When multiple mounts of the same NFS version point to the same NFS Server, they can share resources.  For example, NFS 4.1 mounts can share connections and resources with other 4.1 mounts, and NFS 4.2 mounts can share with other 4.2 mounts.  The NFS 4 client can detect when different names or IP addresses actually lead to the same NFS Server, and will still group these together to share resources.  This can result in the "addr" parameter of the mount taking effect differently than expected.  Typically, the mount accomplished first will determine which IP address is used for each mount of that version.  However, fstab order does not necessarily determine mount order, because work can be done in parallel.

The name displayed after the fact is determined differently, and may not always match intuitively.  However, this is cosmetic and should not affect functionality.

NFS v3 does not have the "trunking detection" feature.

It is also notable that with SLES 15, NFS client mounts default to v4.2.  In SLES 12, they default to 4.0, and in SLES 11 they default to 3.  Therefore, fstab entries or mount commands which do not specify a version number may suddenly have new behavior after a major upgrade of the OS.

SLES 11 SP4 supports NFS versions up to 4.1, but defaults to 3.
SLES 12 SP4 and SP5 received the addition of support for NFS 4.2, but default to 4.0.
SLES 15 (all SPx) also support up through 4.2, and default to 4.2.

Unlike SLES 12 and 15, SLES 11 doesn't recognize minor versions on the "vers=" parameter.  So instead of "vers=4.1" use "vers=4,minorversion=1".  Both formats are valid on SLES 12 and 15.