SUSE Linux Enterprise Server 12 Service Pack 3 (SLES 12 SP3)
SUSE Linux Enterprise Server 12 Service Pack 4 (SLES 12 SP4)
SUSE Linux Enterprise Server 15
A SLES NFS client system is pointing to a NFS Server behind a F5 Networks load balancer which is doing Network Address Translation. (Possibly, other NAT devices could be involved).
After adding maintenance updates to SLES 12 SP3 or SLES 15 SP0, or after installing SLES 12 SP4, showmount or rpcinfo commands pointing to the remote server fail. Common failures include "no route to host" and/or timeout, but other failures messages or behaviors might occur.
On SLES, update libtirpc packages. There may be more than one package installed whose name begins with "libtirpc", and they typically will be updated together. For example, "libtirpc3" and "libtirpc-netconfig" are likely present, and possibly others.
On SLES 12 SP3 or SP4, update to libtirpc packages v1.0.1-17.9 or higher.
On SLES 15, update to libtirpc packages 1.0.2-3.8 or higher.
Once the updated libtirpc is in place, create a file with the following command:
touch /etc/netconfig-try-2-first
When the new libtirpc sees this file present, it will try rpc v2 first, instead of v4.
The failure is due to Network Address Translation methods which need to be enhanced to handle rpc v3 and v4. This will require enhancement at the NAT device. However, SUSE is putting forth a workaround for the time being.
The Linux community recently altered libtirpc, changing the order of RPC versions it attempts to use. Previously, it first attempted v2, and if that was not found, it would attempt v3, and then v4. In newer libtirpc packages, it now tries v4 first, and if that is not found, it attempts v3 and then v2. This change is only now starting to get into various Linux distributions. It is not limited to SUSE, but it will depend upon how recently packages were pulled from the Linux libtirpc project into any particular Linux distribution.
RPC v4 and v3 use additional functions that were not present in v2. One of those functions, "GETADDR" , inserts IP addresses into the data portion of its calls and replies. If the packets are passing through a NAT device which only translates the IP headers of these packets, and does not know to inspect them more deeply and translate the embedded addresses also, subsequent communication attempts can break down.
While rpc v4 and v3 have been around for some time, Linux systems have not been using them by default, and therefore this concern with NAT devices may not have been previously exposed.
The update / workaround described in this document is not necessarily being submitted to the Linux community libtirpc project. SUSE is providing this workaround to help systems which were working previously and were updated into the problem. However, the real solution is for NAT devices to enhance their translation abilities in order to cover this need. This issue is similar to the way that FTP negotiates addresses within the data portion of PORT and PASV functions, which modern NAT devices already watch for and translate. When NAT only translates addresses within IP headers, it causes failures for protocols that share IP address information in the data payload.
This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.
