[9fans] 100base ether card

[Brandon Black photon@dtmf.com]

Just thoughts on this from an IP networking perspective, to add to this
discussion...

The main issue here on the multiple-ether scenario comes down to
host-based addressing versus interface-based addressing.  Even in
routers, this is sometimes a religous choice.. there are arguments for
both (personally, however, I lean strongly towards interface-based
addressing as being the "correct" solution).

Now... supposing we pick interface-based addressing, where each of the
multiple interfaces has a different IP on a different network.... Well..
now you have to consider naming system issues.  Luckily, usually only
one interface on a host is the real "primary" interface in the sense of
routing (i.e. points towards a real default route to the internet).  The
others are private networks.  So, if you have a hostname hostone, with
three interfaces, and eth0 is the primary interface:

Set the machine's official "hostname" to "hostone".
Set up DNS such that the IP of the main interface actually
forward/reverse maps to "hostone".  Optionally, also set up DNS entries
for the other two IP addresses, naming them "hostone-eth[12]".

In the /etc/hosts files of machines on the private network attached to
eth1, you set up an entry mapping the eth1 IP to the name "hostone"...
ditto for the eth2 IP on machines on the eth2 private network.

The end result is that from everywhere on the network, the name
"hostone" reaches the right interface and the right box.  (This assumes
the machines involved lookup in /etc/hosts before trying DNS, not always
the default on some machines (AIX and HPUX I think do it backwards)).

And then of course there are many subtle variations on that naming
solution... like making the eth0 ip address map to hostone-eth0 in DNS,
and putting a DNS CNAME from hostone to hostone-eth0, etc... but they
are all the same basic stuff...

On to the cpuserver being an IP "gateway"....

in the *nix/IP world sense.. the correct way to handle this would be to
put real IP routing code in the cpu server, such that it actually
correctly routes traffic between subnets, and acts as a "default
gateway" to other hosts.

The method you described below regarding ARP replies is known as
Proxy-ARP, and it is a sort of hack/solution.... and you'd typically
only use it if the "seperate" networks the cpuserver is dividing are
actually all in the same IP "subnet".. which is kind-of not a very
correct way to do things.  In that scenario, the CPU server is acting as
a transparent IP router between hosts who really think they are on the
same network

The whole combined issue of all of these things is messy and complex in
the *nix/IP world... and even worse (or maybe perhaps better) in the
Plan 9 world.

In plan 9, you could bypass routing/gateway functions at the IP level,
because you can import the ip interface of the cpu server.  This adds a
layer of complexity to the whole issue.. but also offers an easy out of
the whole thing.  The easy out is to set up true disparate IP subnets,
with a gateway cpu server connected to all of them, and hook your
multiple-interface FS up to all of them.  Neither have to support
routing/gatewaying traffic between subnets....  just have to have
interfaces on them.  Then a terminal on subnet "A" can import the
ethernet interface of the cpu server which is attached to subnet "B",
and use that to communicate to hosts on subnet "B" directly... (sort
of.. :)

Sorry for the ramble... I guess it's a mood thing today :)

Brandon



Eric Dorman wrote:

> On Fri, Jul 10, 1998 at 08:02:35PM -0500, G. David Butler wrote:
> > From: Eric Dorman <edorman@tanya.UCSD.EDU>
> >
> > >while having a IP-capable 'backbone' for fs<>cpu communication.
> > >Unfortunately the current fs has no plumbing for IP routing so
> > huh?  il runs over ip...
>
> just because one runs il over ip doesn't mean the plumbing
> is there to support all the bells and whistles of multihoming.
> as the fs code stands now it assigns the same ip address to all
> interfaces (same ipmask and ipgw as well) which isin't what I
> want (been there, done that :) ).  perhaps i'm wrong but
> it seems to me that these need to be different.  I had to
> construct tables expanding the sysip, ipgw and ipmask variables
> to support these variables for all installed interfaces.
>
> the syntax i've used here is sort-of silly, since i'm not
> precisely sure yet what is known when the config table is
> evaluated.
> i say to the fs:
>   ip 128.54.16.3
>   ipmask 255.255.0.0
>   ipgw 128.54.16.1
> which sets up ether0..
> succeeding blocks of ip/ipmask/ipgw set up ether1, etc.
>
> i'd rather like to say
>   ip 128.54.16.3 0
>   ipmask 255.255.0.0 0
>   ipgw 128.54.16.1 0
>   ip 128.55.16.3 1
>   ipmask 255.255.0.0 1
>   ip 128.56.16.3 2
>   ipmask 255.255.0.0 2
>
> or somesuch to explicitly name the interface when setting
> the ipa, but i'm trying to modify fs as little as possible on
> the first swipe.  option #2 is uglier though.  sigh.
>
> the routing stuff is in fact there; i was incorrect about that.
> there's just no way to tell fs which ipnet is which.
>
> > >all that glop will have to be written plus multiple interface
> > >stuff and config syntax to match.
> > huh?  multiple interfaces are already in fs and my multiple
> > interface cpu stuff will be provided Real Soon Now...
>
> one can't set the ipa on ether2 independently of ether0
> in the fs, that I can see.  ether everything calls getipa(Ifc *)
> which always assigns the interfaces' ip addr to sysip.
>
> on the cpu/terminal side, i numbered ethers /net/ether0
> /net/ether1 ... which caused some changes to some network
> programs:
>  arpd   (always got ip from "ether")
>  snoopy (always assumed "ether")
>  ipconfig  (to find undocumented -s option)
>            (don't think I had to change anything..)
>
> i also changed sparc to generate /net/ether0 vice /net/ether
> for its single interface to make the scripts/programs more
> general (i have some sparcs).  unfortunately i can't test
> the other architectures.
>
> i have a modified devether (based on jmk's brazil stuff kindly
> provided) that supports these interfaces so i can now bootp
> terminals on any interface, ftp into the cpuserver, etc.  only
> thing missing is the fs part so fs can straddle two networks.
>
> one thing i haven't figured out yet is how cpus act as gateways.
> to gateway it seems to me that arp on the cpu/gw should respond
> to ip's on the 'other side' network with its own mac address..
> i haven't dredged into the rest of the arp code to make sure.
> OTOH setting ipgw=cpu/gw for the 'this side' network may be
> sufficient?
>
> it shall be enlightening to compare notes!
>
> > David Butler
> > gdb@dbSystems.com
>
> Regards,
>
> Eric Dorman
> edorman@ucsd.edu