From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Mon, 13 Jul 1998 17:27:02 -0700
From: Eric Dorman edorman@tanya.UCSD.EDU
Subject: [9fans] 100base ether card
Topicbox-Message-UUID: 7b0a9000-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19980714002702.JV96fk9zXP3U2X-UQysZvZkFqyp6ucir11kCikdJn2s@z>

On Mon, Jul 13, 1998 at 05:19:03PM -0500, Brandon Black wrote:
> 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]".
[....]
 
  This solves, using dns, an abstract problem I was trying to 
address, i.e. how to get two different answers when asking the question
"fs= what host.domain?" depending on which side of the gateway a 
terminal is on.  It might be tuff to implement in Plan9 tho, with 
the centralized ip database that csquery&etc. refer to.  I guess one 
could construct fs's on both sides of the gateway, each with a 
different sense of the host db, but that seems icky management-wise.

Hmpf, well, uh, one could just say:

/lib/ndb/local:
ip=w.x.y.z ether=blah sys=cpu
   fs=fs-highspeed-interface-ip proto=il

whereas everyone else defaults to
ipnet=w.x.y.0 
   fs=fs-lowspeed-interface-ip

Duh =:)

  I'm (obviously :) ) pretty slow so David may know something I 
don't on how to set different ips on different ethers in the fs; I 
hope so since that would be more code I don't have to write 
myself, me being lazy and all ;)

> On to the cpuserver being an IP "gateway"....
[xxx]
> 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

  Aah, I get it.  In hindsight I can see how that could be a
potential maintenance nightmare as well since things are happening 
outside of the purview of the hosts...  it would not be obvious where
the packets routed to destinations outside the 'subnet' were being
routed.
 
> 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.. :)

  Importing is certainly a feature, but it presumes that Plan9
is aleady up and running.  If, say, the terminals' auth or root
fs server were located on the other side of the gateway, I think 
one would need IP-level gatewaying.  OTOH said topology may be unusual.

  Besides, if it *realllllly* has to work and work fast, one should 
probably get a real IP switch :)
 
> Sorry for the ramble... I guess it's a mood thing today :)

Not at all :)  DNS tricks aren't my forte'
 
> Brandon

Thanks,

Eric Dorman
edorman@ucsd.edu