NFS mount to DELL/EMC Isilon servers fails with 'permission denied' due to NFS server duplicate response to single EXCHANGE_ID causes mount.nfs to fail auto-negotiation

Issue

• According to the release notes for 7.4, the default version for NFS changed from 4.0 to 4.1. Unfortunately, this causes a breaking outage for hosts connecting to our DELL/EMC Isilon servers. After the upgrade, attempting to mount NFS shares results in:

mount.nfs: access denied by server while mounting <sharename>

• We discovered that we had to explicitly specify 'vers=4.0' on the mount command to restore service.
  This problem does not occur on RHEL7.3 because the default protocol is 4.0 and the Isilon supports that.

• We previously had not given a 'vers=' option, and according to the NFS man page, if you do not specify a version, the protocol versions should be auto-negotiated down but this seems to not occur.

NAME
       nfs - fstab format and options for the nfs file systems
...
  Options supported by all versions
       These options are valid to use with any NFS version.

       nfsvers=n      The NFS protocol version number used to contact the server's NFS service.  If the server does not support the requested version, the mount request  fails.   If
                      this option is not specified, the client negotiates a suitable version with the server, trying version 4 first, version 3 second, and version 2 last.

       vers=n         This option is an alternative to the nfsvers option.  It is included for compatibility with other operating systems

• In Red Hat Enterprise Linux 8, mounting an NFS volume fails with the following error.

mount.nfs: mount system call failed

• Then syslog shows the following message.

kernel: NFS: nfs4_discover_server_trunking unhandled error -5. Exiting with error EIO