From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 13 Jul 1998 17:19:03 -0500 From: Brandon Black photon@dtmf.com Subject: [9fans] 100base ether card Topicbox-Message-UUID: 7affd5f2-eac8-11e9-9e20-41e7f4b1d025 Message-ID: <19980713221903.N3Wp2hrI5Y8vNC6uGNWOWXJJouRf0634_mG26nkV8RU@z> 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 > > > > >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