Re: [9fans] Speaking of routing....

Re: [9fans] Speaking of routing....

[Dan Cross]

Thanks, Skip and Andrey,
   Unfortunately, I was hoping to avoid any mucking with namespaces,
particularly for automated things (like outgoing mail).  Alas, it
seems impossible.  Maybe I should go back to running both interfaces
on the same IP stack.  Hmm....

	- Dan C.

Re: [9fans] Speaking of routing....

[andrey mirtchovski]

I used a special acme just for reading mail (I had enough screen to do so)
and ran a script to bind the proper namespace before reading the mail.dump
file...

Wasn't it the case that certain programs would look for a stack in /net.alt
if the /net one timeouted? Can't remember :(

andrey

On Thu, 13 Feb 2003, Dan Cross wrote:

> Thanks, Skip and Andrey,
>    Unfortunately, I was hoping to avoid any mucking with namespaces,
> particularly for automated things (like outgoing mail).  Alas, it
> seems impossible.  Maybe I should go back to running both interfaces
> on the same IP stack.  Hmm....
>
> 	- Dan C.
>

Re: [9fans] Speaking of routing....

[David Gordon Hogan]

> Wasn't it the case that certain programs would look for a stack in /net.alt
> if the /net one timeouted? Can't remember :(

This behaviour is built into dial().

Re: [9fans] Speaking of routing....

[Dan Cross]

In article <43f3eff7a65deecc69011f7b01d398e4@plan9.bell-labs.com> you write:
>> Wasn't it the case that certain programs would look for a stack in /net.alt
>> if the /net one timeouted? Can't remember :(
>
>This behaviour is built into dial().

I guess it's the 30-second timeout-tax I'm bummed out about.  I guess
I don't see why, if I don't have a default route on the IP stack, it
would take 30 seconds to realize that sending a packet out of that stack
wasn't going to work.

	- Dan C.

Re: [9fans] Speaking of routing....

[northern snowfall]

>
>
>I guess it's the 30-second timeout-tax I'm bummed out about.  I guess
>I don't see why, if I don't have a default route on the IP stack, it
>would take 30 seconds to realize that sending a packet out of that stack
>wasn't going to work.
>
It'd be neat if there was a way to alter the dial() performance
per-user. Maybe
via a namespace config, or, environment variables (within some kind of
restraint).
Don

Re: [9fans] Speaking of routing....

[David Gordon Hogan]

> I guess it's the 30-second timeout-tax I'm bummed out about.  I guess
> I don't see why, if I don't have a default route on the IP stack, it
> would take 30 seconds to realize that sending a packet out of that stack
> wasn't going to work.

Generally how it should work is that name resolution fails on
/net/cs, and dial moves on to /net.alt without having to time
out.  This depends on you having ndb/cs set up right (one
for each interface with its own ndb file) and also ndb/dns for
DNS.  Of course, if you're using numeric IP addresses you'll
get the timeout (unless you give /net.alt explicitly).

Re: [9fans] Speaking of routing....

[Dan Cross]

> > I guess it's the 30-second timeout-tax I'm bummed out about.  I guess
> > I don't see why, if I don't have a default route on the IP stack, it
> > would take 30 seconds to realize that sending a packet out of that stack
> > wasn't going to work.
>
> Generally how it should work is that name resolution fails on
> /net/cs, and dial moves on to /net.alt without having to time
> out.  This depends on you having ndb/cs set up right (one
> for each interface with its own ndb file) and also ndb/dns for
> DNS.  Of course, if you're using numeric IP addresses you'll
> get the timeout (unless you give /net.alt explicitly).

No, everything is using hostnames; perhaps it'll work.  I really need
to power everything up (the whole shebang is currently under my
girlfriend's bed in her apartment, and annoys her when she tries to
sleep; hence frequent power-downs) and test it for real, instead of
stabbing in the dark.

I would imagine that the IP stack would be smart enough, if it got a
packet destined for the outside network (for which it would have no
routes on the internal network) to say immediately, ``I don't know what
to do with this!'' and return an error, prompting dial() to proceed to
/net.alt without a perceptable delay.  Am I wrong?

It also occurs to me that for smtp, I can do bind's in upas's scripts
that go immediately to /net.alt, since no SMTP traffic will ever be
sent on the internal network.

	- Dan C.

Re: [9fans] Speaking of routing....

[Russ Cox]

dialing /net and then /net.alt is a clumsy hack.
if you want the appearance of one ip stack with
multiple interfaces then why not do that?

Re: [9fans] Speaking of routing....

[Dan Cross]

> dialing /net and then /net.alt is a clumsy hack.
> if you want the appearance of one ip stack with
> multiple interfaces then why not do that?

Because you guys never commited my change to tftpd to keep it from
listening to the world.  Yeah, I could mitigate the damage that could
do by giving it a home directory with -h, but that's still not
something I really feel comfortable doing.  Then there's the issue of
dhcpd listening to the outside as well.  That's not a big deal since it
won't answer for hosts it doesn't know about (unless you tell it to),
but again, it's not something I feel entirely comfortable with.  At
least with seperate IP stacks, I can be *real* selective about what
listens where.

Also, I can run an outside DNS server and an inside DNS server, using
seperate data files.  The outside can't see anything about my internal
network, which I like.

Call me paranoid.

	- Dan C.

Re: [9fans] Speaking of routing....

[David Presotto]

Actually, dial does currently dial /net first and then
/net.alt.  It's a hack I've never been too proud of
but I like it better than changing every single service
to check where the call is coming from, mistakes there
are too easy.

Re: [9fans] Speaking of routing....

[northern snowfall]

Just random thought, has anyone played with the concept of a stackable
bind? i.e. instead of /net.alt bound over /net so that accessing /net/cs
always thunks /net.alt/cs, make it so thunk one in the target dir accesses
the top of the LIFO (/net.alt/cs), then, the successive thunk would access
the lower object: the true /net/cs. This would generate a multidimensional
file system rather than solely a linear. There could be fs calls for
resetting the
LIFO, somehow.. Just a thought.
Don

Re: [9fans] Speaking of routing....

[Dan Cross]

> Actually, dial does currently dial /net first and then
> /net.alt.  It's a hack I've never been too proud of
> but I like it better than changing every single service
> to check where the call is coming from, mistakes there
> are too easy.

Okay, here's a question; I honestly don't understand something.  Why
do so many servers take a ``-x'' option to set the network mount point,
instead of taking the (presumably more general) ``-A announce_string''
(or whatever you want to call it, if -A doesn't float your boat)?  Can't
the nework directory be adequately specified using the announce string
syntax: /netdir/proto!addr!service or whatever?

	- Dan C.

Re: [9fans] Speaking of routing....

[David Presotto]

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

As for the delay, there wouldn't be one if your inside dns server
came back quickly with a nonexistant domain response.  However, if
it comes back with an address that won't work in the inside or
doesn't come back, you're stuck with the timeout.

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

From: David Presotto <presotto@closedmind.org>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Speaking of routing....
Date: Thu, 13 Feb 2003 19:21:27 -0500
Message-ID: <b17c702596cf67c84e7bdaaacfda622c@plan9.bell-labs.com>

Actually, dial does currently dial /net first and then
/net.alt.  It's a hack I've never been too proud of
but I like it better than changing every single service
to check where the call is coming from, mistakes there
are too easy.

Re: [9fans] Speaking of routing....

[David Presotto]

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

Mostly because I got tired of typing that much.

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

From: Dan Cross <cross@math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Speaking of routing....
Date: Thu, 13 Feb 2003 19:31:38 -0500
Message-ID: <200302140031.h1E0VcM24680@augusta.math.psu.edu>

> Actually, dial does currently dial /net first and then
> /net.alt.  It's a hack I've never been too proud of
> but I like it better than changing every single service
> to check where the call is coming from, mistakes there
> are too easy.

Okay, here's a question; I honestly don't understand something.  Why
do so many servers take a ``-x'' option to set the network mount point,
instead of taking the (presumably more general) ``-A announce_string''
(or whatever you want to call it, if -A doesn't float your boat)?  Can't
the nework directory be adequately specified using the announce string
syntax: /netdir/proto!addr!service or whatever?

	- Dan C.

Re: [9fans] Speaking of routing....

[Dan Cross]

> As for the delay, there wouldn't be one if your inside dns server
> came back quickly with a nonexistant domain response.  However, if
> it comes back with an address that won't work in the inside or
> doesn't come back, you're stuck with the timeout.

That's fine, I understand that part.  I guess I'm confused with what
the IP stack does with the packet it's trying to send if no route exists
for it.  Why would it take time timing out if it had no place to send
it?  That is, if the IP stack only knows how to send to hosts on
172.16.1.0/24, and no where else, why does it need to timeout when
it tries to send a packet to 146.186.132.2?  More importantly, what's
it doing with that packet in the mean time?  Not that I'm really worried
about it at this point, I'm just curious.

	- Dan C.

Re: [9fans] Speaking of routing....

[David Presotto]

If you have a default route, it'll send it that way.  If it
has no route, and it doesn't stop right away, that's my
fault.  I may easily have screwed up.  I'll check.

Re: [9fans] Speaking of routing....

[Dan Cross]

> If you have a default route, it'll send it that way.  If it
> has no route, and it doesn't stop right away, that's my
> fault.  I may easily have screwed up.  I'll check.

I don't have a default route on the internal network; I'll have to
check when my girlfriend wakes up.

	- Dan C.

Re: [9fans] Speaking of routing....

[David Presotto]

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

I checked and I'm definitely screwing up.  I'll fix it after supper.

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

From: Dan Cross <cross@math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Speaking of routing....
Date: Thu, 13 Feb 2003 19:50:17 -0500
Message-ID: <200302140050.h1E0oHM24845@augusta.math.psu.edu>

> If you have a default route, it'll send it that way.  If it
> has no route, and it doesn't stop right away, that's my
> fault.  I may easily have screwed up.  I'll check.

I don't have a default route on the internal network; I'll have to
check when my girlfriend wakes up.

	- Dan C.

Re: [9fans] Speaking of routing....

[Dan Cross]

> I checked and I'm definitely screwing up.  I'll fix it after supper.

Cool.  Spasiba.

	- Dan C.

[9fans] FS dimension

[northern snowfall]

> Just random thought, has anyone played with the concept of a stackable
> bind? i.e. instead of /net.alt bound over /net so that accessing /net/cs
> always thunks /net.alt/cs, make it so thunk one in the target dir
> accesses
> the top of the LIFO (/net.alt/cs), then, the successive thunk would
> access
> the lower object: the true /net/cs. This would generate a
> multidimensional
> file system rather than solely a linear. There could be fs calls for
> resetting the
> LIFO, somehow.. Just a thought.

Despite the effort it would take to put this theory into function, what
does everyone
think of the basic concept?
Instead of a filesystem accessed as:

    transparent access points
     -----v
        file1    file2    file3    ...
/path    obj1    obj2    obj3    ...  // actual internal FS objects

You now have stacked objective binds:
    % bind -stack ...
    transparent access points
     -----v
        file1    file2    file3    ...
/path2    obj1.2    obj2.2    obj3.2    ...    // second stacked bind
/path1    obj1.1    obj2.1    obj3.1    ...    // first stacked bind
/path    obj1    obj2    obj3    ...    // original

So a given access mechanism (AM) would open "/path/file1". This initial
thunk would pop "obj1.2" off "file1"'s LIFO to the AM. If this isn't the
desired object the AM can request a secondary open on the same path
"/path/file1", popping "obj1.1" off the LIFO, this time. This might be
interesting in database regression environments or, perhaps, stackable
networks. This was just off the top of my head, yesterday, but, I'd
like to know what this mailing group has to say regarding the idea.
Don



>

Re: [9fans] Speaking of routing....

[Skip Tavakkolian]

> That is, when they connect somewhere, they shouldn't have to say,
> ``telnet /net.alt/tcp!foobar''; ``telnet tcp!foobar'' should work
> for hosts internal and external.  Is that possible?

Wouldn't selectively binding /net.alt before /net do it?

Re: [9fans] Speaking of routing....

[andrey mirtchovski]

there is a similar setup to yours at acl.lanl:

(web page doesn't seem to be working currently, so here's google's cache)
http://216.239.57.100/search?q=cache:ddDZwvPb2uUC:www.acl.lanl.gov/plan9/newnetwork/+&hl=en&ie=UTF-8

normally to access external machine i'd open a rio window and bind
/net.alt to /net in it, then leave it alone and use it when the need
arises -- just another beautiful example of private namespaces...

here are some samples taken from the web site above:

-------

This is the only machine that lives on the external network. The secondary
network interface is hooked to the external network the primary interface
is connected to the unrouted network. However all hosts on the internal
network can access the external network by using the command:


import plan9 /net.alt


and then using addresses like:


ping /net.alt/icmp!acl.lanl.gov
ssh /net.alt/tcp!acl.lanl.gov


Actually if you are willing to wait 30 seconds or so for the timeout you
don't need to use the /net.alt/ prefix. Or if you only want to use the
external interface in a given namespace you can import the external
interface on top of the internal interface, and the use "normal"
addresses:


import plan9 /net.alt
import plan9 /net.alt /net orbind /net.alt /net


Which is the method we commonly use.


andrey

On Thu, 13 Feb 2003, Dan Cross wrote:

> I have a question.  I have have a CPU server with two interfaces, one
> mounted on /net, the other on /net.alt.  They're connected to two
> networks; on internal, and the other the Internet.  I want users who
> login to the CPU server to be able to connect to either network
> seamlessly; without jumping through hoops.  Is that possible?  (I know
> this question is sort of vague, and I apologize for that, but I'm
> pressed for time at the moment).
>
> That is, when they connect somewhere, they shouldn't have to say,
> ``telnet /net.alt/tcp!foobar''; ``telnet tcp!foobar'' should work
> for hosts internal and external.  Is that possible?  I'm afraid I
> haven't looked at the code, as the machine is currently powered down,
> and my laptop's battery is dead, and the charger is at home.  :-(
>
> 	- Dan C.
>

[9fans] Speaking of routing....

[Dan Cross]

I have a question.  I have have a CPU server with two interfaces, one
mounted on /net, the other on /net.alt.  They're connected to two
networks; on internal, and the other the Internet.  I want users who
login to the CPU server to be able to connect to either network
seamlessly; without jumping through hoops.  Is that possible?  (I know
this question is sort of vague, and I apologize for that, but I'm
pressed for time at the moment).

That is, when they connect somewhere, they shouldn't have to say,
``telnet /net.alt/tcp!foobar''; ``telnet tcp!foobar'' should work
for hosts internal and external.  Is that possible?  I'm afraid I
haven't looked at the code, as the machine is currently powered down,
and my laptop's battery is dead, and the charger is at home.  :-(

	- Dan C.