Hello Chuck,
On Montag 2022-02-14 16:26, Chuck Lever III wrote:
On Feb 14, 2022, at 4:26 AM, Thomas Blume via Libtirpc-devel <libtirpc-devel@xxxxxxxxxxxxxxxxxxxxx> wrote:
In some setups, it is necessary to try rpc protocol version 2 first.
Before applying this, I hope we can review previous discussions of
this issue. I've forgotten the reason some users prefer it, or
maybe I'm just imagining we've discussed it before :-)
We've had a discussion about 1 year ago:
https://sourceforge.net/p/libtirpc/mailman/message/37227894/
actually that encouraged me to send a patch, even though I initially thought
is wasn't good enough for upstream.
The patch description, at the very least, has to have a lot more
detail about why this change is needed. Can it provide a URL to
threads in an email archive, for example?
This goes back to an old SUSE bugreport following the change of rpc protocol
version 2, 3, 4 to 4, 3, 2.
Below an description of issue the customer was seeing:
-->
An 3rd party NFS Server is behind a F5 front end load balancer device.
The F5 front end load balancer device is replacing IP addresses in packets as
they head to a NFS server.
It replaces IP addresses in headers but as you might expect it does not replace
the IP address within the RPC data payload, i.e. within RPC GETADDR request,
which places an address there for the universal address or hint. Without a
correct hint, the GETADDR reply which comes back gives an unexpected address
which happens to be unroutable from the nfs client's point of view.
--<
We agreed that this is rather an issue of the loadbalancer hardware, but we
would have to address that anyway due to backward compatibility.
So, the first question is, do we want to stay backward compatible upstream?
We have to do that as distributor, but of course upstream is different.
Creating the file /etc/netconfig-try-2-first will enforce this.
A nicer administrative API would enable you to update the whole
rpcbind version order, but that might be more work than you want
to pursue.
It would be a nicer if, instead of a separate file, a line is
added to /etc/netconfig to toggle this behavior, or provide the
whole version order. E.g.
# rpcbind 4 3 2
# rpcbind 2 4
Really, though, this isn't related to the transport definitions
in /etc/netconfig, so a separate configuration file might be
more appropriate.
Thanks for the hints, if you deem a patch would be still desireable I will work
on that.
Best regards
Thomas Blume
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5
90409 Nürnberg
Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
