Re: [9fans] NAT vs /net

Re: [9fans] NAT vs /net

[presotto]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

At its peak there were about 20 people importing our outside interface
to inside machines.  After that we began trusting our path through the
firewall and switched to that in order to push on its harder.

The cost of importing /net is one process on the server machine per
import plus about 5 extra copies of the data due to shoving it trhough
the extra machine plus an extra header per message on the inside net
plus a bunch of context switches you wouldn't need on a nat.

The advantage is no need to worry about embedded addresses since
they would be 'real'.

For a small network, 100 or so machines, I wouldn't bother with
a NAT box and just do the import.  We're building a super-NAT
box for hiding networks the size of Lucent behind a Plan 9
box.  For that, the import surely wouldn't scale.

[-- Attachment #2: Type: message/rfc822, Size: 1452 bytes --]

From: Scott Schwartz <schwartz@bio.cse.psu.edu>
To: 9fans@cse.psu.edu
Subject: [9fans] NAT vs /net
Date: Thu, 25 Jan 2001 21:28:25 -0500
Message-ID: <20010126022825.20068.qmail@g.bio.cse.psu.edu>

On thing I've wondered about is how well importing /net scales.  That
strikes me as an elegant way for folks inside a firewall to talk to the
outside, but with lots of users it means lots of mounts, and running
into limits on number of processes and file descriptors and stuff.
Anyone tested this to destruction?

Re: [9fans] NAT vs /net

[Andrey A Mirtchovski]

i guess lucho's question was more towards using p9 as a nat box from
machines that have no possibility to 'import' /net (such as windows and
linux boxen)...

in this case nat is the only plan9 solution, no?

On Thu, 25 Jan 2001 presotto@plan9.bell-labs.com wrote:

> At its peak there were about 20 people importing our outside interface
> to inside machines.  After that we began trusting our path through the
> firewall and switched to that in order to push on its harder.
> 
> The cost of importing /net is one process on the server machine per
> import plus about 5 extra copies of the data due to shoving it trhough
> the extra machine plus an extra header per message on the inside net
> plus a bunch of context switches you wouldn't need on a nat.
> 
> The advantage is no need to worry about embedded addresses since
> they would be 'real'.
> 
> For a small network, 100 or so machines, I wouldn't bother with
> a NAT box and just do the import.  We're building a super-NAT
> box for hiding networks the size of Lucent behind a Plan 9
> box.  For that, the import surely wouldn't scale.
> 

Re: [9fans] NAT vs /net

[Boyd Roberts]

NAT and UDP can be a real mess; some DNS servers refuse
to answer requests that don't have a source port of 53.

Re: [9fans] NAT vs /net

[Lucio De Re]

On Fri, Jan 26, 2001 at 08:15:07AM +0100, Boyd Roberts wrote:
> 
> NAT and UDP can be a real mess; some DNS servers refuse
> to answer requests that don't have a source port of 53.
> 
Granted that some DNS servers are too strict, but NAT is superfluous
when you can PROXY the service, and DNS is perfectly suited to
letting a host with the right privileges operate on your behalf.

I find it a lot more of a bitch to have to commission and maintain
two DNS services because with NAT you have internal and external
DNS mappings :-(

Which reminds me, if my PROXY is NetBSD - and a long way from here,
at that, how do I get my Plan 9 network to use it?

++L

Re: [9fans] NAT vs /net

[presotto]

[-- Attachment #1: Type: text/plain, Size: 236 bytes --]

I'ld be interested in which ones don't.  We've never sent our requests from
53 and I haven't noticed any parts of the world that we can't resolve, but
then again, there's enough redundancy in DNS that I wouldn't necessarily
notice.

[-- Attachment #2: Type: message/rfc822, Size: 1837 bytes --]

From: "Boyd Roberts" <boyd@planete.net>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] NAT vs /net
Date: Fri, 26 Jan 2001 08:15:07 +0100
Message-ID: <012901c08767$b6c7c2e0$0ab9c6d4@cybercable.fr>

NAT and UDP can be a real mess; some DNS servers refuse
to answer requests that don't have a source port of 53.

Re: [9fans] NAT vs /net

[Boyd Roberts]

apple were doing it last year.  we had NAT and DNS UDP
plugged through a firewall.  it worked at the plugged
site, but not at the NAT'd sight.  it was horrible to
trace, due to to the complexity of the environment and
the physically distinct sites.  i got it eventually.

it also explained other weird things with certain other
web servers, whose DNS servers we similarily configured.

i think proxies and/or plugs are a much better idea than NAT.

[9fans] NAT vs /net

[Scott Schwartz]

On thing I've wondered about is how well importing /net scales.  That
strikes me as an elegant way for folks inside a firewall to talk to the
outside, but with lots of users it means lots of mounts, and running
into limits on number of processes and file descriptors and stuff.
Anyone tested this to destruction?