Received-SPF: pass (google.com: domain of linux-nfs+bounces-1036-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
MIME-Version: 1.0
References: <CALXu0UdFR7Xn51eKFUUi6a68wvDKc-RXz7F4LKyQgDptqfYbgw@mail.gmail.com>
 <CALXu0UfSJ0Qc3HOecf4pQ=VnEVqxRw6OGzNwhh9BUVYaHV7_oQ@mail.gmail.com>
 <ZZwJLb7j65QXR1+K@tissot.1015granger.net> <CALXu0UdJanF-_=3TzgzUskwh1RGPjw+LeZ0Cht+yP1aQgr8v+w@mail.gmail.com>
 <B5750E41-D130-44CF-8446-EC71BB149E7D@oracle.com>
In-Reply-To: <B5750E41-D130-44CF-8446-EC71BB149E7D@oracle.com>
From: Martin Wege <martin.l.wege@gmail.com>
Date: Thu, 11 Jan 2024 16:06:59 +0100
Message-ID: <CANH4o6Mr0UxFboUZE8QurghWDQmqHmFf6nstgdsi5BXeV-Z7dw@mail.gmail.com>
Subject: Re: nfs-utils&nfsd&autofs not supporting non-2049 TCP port numbers -
 Fwd: showmount -e with custom port number?
To: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Jan 10, 2024 at 4:11=E2=80=AFPM Chuck Lever III <chuck.lever@oracle=
.com> wrote:
>
>
>
> > On Jan 10, 2024, at 1:06=E2=80=AFAM, Cedric Blancher <cedric.blancher@g=
mail.com> wrote:
> >
> > On Mon, 8 Jan 2024 at 15:39, Chuck Lever <chuck.lever@oracle.com> wrote=
:
> > If you look at Solaris BUGSTER (remember, we were a big SUN customer
> > in the 1990/2000, so we had lots of bugs open for this mess), you'll
> > find lots of reasons why one single port for NFS is not feasible in
> > all scenarios.
>
> > Just some examples, but certainly not limited to:
> > - Fine-grained HSM, all on one host
> > - Fine-grained project/resource management, i.e. one nfs server per
> > project, all on one host
> > - Competing teams
> > - Hostile IT department (e.g. port 2049 blocked out of FEAR - not
> > reason, no further discussion/negotiation possible)
> > - NFSv4 tunneled via ssh
> > - NAT, e.g. private IPv4 address range inside, only one IPv4 address ou=
tside
> > - IPv4 address shortage
> > - Software test deployments in parallel to the production systems, on
> > the same machine
> > - ...
> >
> > In any of these scenarios you'll end up with NFSv4 certainly not using
> > TCP port 2049.
>
> In most of these cases, the use of alternate ports has been
> superceded in the past 20 years.

From a viewpoint of university hosting, HPC environments and pretty
much everything else I've seen, that statement is FAR from reality.
This even gets worse in Germany, Europe and Asia (not US of course,
you're hogging public IPv4 addresses), where we have IPv4 address
shortage, lots of NAT, and only a small amount of IPv6 (except Asia).
In all these scenarios you have NFSv4 connections all over the port
numbers, and not only 2049.

Also, reality is, storage virtualisation for NFSv4 on the outgoing
side is typically done on the port level, and not IP address level,
e.g. many servers behind NAT, and NAT then translates the accesses to
the NFSv4 server into a single IPv4 address with different ports
(because of address shortage). And because of convenience, the NFSv4
servers start with the same port number as used by NAT on the
outside...

Short: Non-2049 port number are the not a "corner case"

Thanks,
Martin