Re: [OpenAFS-devel] nat mode

[Roland Kuhn]

Hi Jeffrey!

On 16 Feb 2006, at 14:26, Jeffrey Altman wrote:

Roland Kuhn wrote:

Hi Jeff!

It seems like this UDP-based NAT has a lot more problems than I was
aware of. If the firewall were to do NAT based on the RX connections
instead, would that work? What I have in mind is a scheme where a

on port 7001. Are there limitations? Does anybody know of a RX-aware
connection tracking code?

Ciao,
                    Roland

(potentially large) number of clients are behind a firewall which looks to a server like a single client with very many open RX connections, all

in order that callback breaks can be delivered.

The server tracks clients by a combination of source address/port and
UUID (if the client supports it).

While I could conceive of a way of allowing a firewall to maintain its
own RX connection to client mappings, the bigger problem from the
perspective of the server is that the server would not be able to
effectively distinguish the clients.  If two callbacks were requested
for the same object by two clients without UUID support, the file
server would only record one of them.   The callback break would be
delivered to one client and not the other.  Of course, this is exactly
the problem we have today.  So adding another layer does not solve
anything.  The 1.4.1-rc7 file server already has the necessary code to
do the right thing as do all 1.4 clients.

Now we just have to wait while people upgrade.  A slow and painful
process but its the only one we have.

Jeffrey Altman

RX connections are very short lived. Much shorter than the lifetime of callbacks. You need the server to be able to track a particular client across multiple RX connections including ones established by the server

Ciao,
                    Roland

--
TU Muenchen, Physik-Department E18, James-Franck-Str., 85748 Garching
Telefon 089/289-12575; Telefax 089/289-12570
--
CERN office: 892-1-D23 phone: +41 22 7676540 mobile: +41 76 487 4482
--
UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things.
        -Doug Gwyn
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12

PGP++ t+(++) 5 R+ tv-- b+ DI++ e+++>++++ h---- y+++
------END GEEK CODE BLOCK------

Thanks very much for this explanation. So now I just have to convince several big computing centers to upgrade their servers :-) GS/CS/M/MU d-(++) s:+ a-> C+++ UL++++ P+++ L+++ E(+) W+ !N K- w--- M + !V Y+

PGP.sig
Description: This is a digitally signed message part