[9fans] 100base ether card

[9fans] 100base ether card

[Kenji]

Hello 9fans,

Thank you for the information on 100base ether cards.

jmk says:
>We have used a mixture of 100BASE-X cards with Brazil using the
>following chips:
>	3COM			3C595, 3905, 3C905B
>	Intel 82557/8	EtherExpress PRO/100B
>					Allied Telesyn 2560FX
>	Digital 21140	Fast EtherWORKS PCI 10/100 adapter  
(DE-500-X)
>					Accton EN1207-COM
>					Adaptec (Cogent) ANA-6910FX
>					SMC 9332
>...
I would be happy if these cards are available on Plna9.
Now 100base card are cheap enough, so I really want to connect
file server and cpu server with 100base cards.

And Eric Dorman says:
>  The driver compiles cleanly now and I'm going through and
>checking out all the functions.  I hope to have it working
>relatively soon.  If you'd like to play with it I can forward
>the code to you.
When you finish the work, please forward the code to me.

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp

[9fans] 100base ether card

[Eric]

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

[9fans] 100base ether card

[Brandon]

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

[9fans] 100base ether card

[Eric]

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

[9fans] 100base ether card

[Eric]

On Fri, Jul 10, 1998 at 04:17:32PM +0900, Kenji Arisawa wrote:
> Hello 9fans,
> 
> Thank you for the information on 100base ether cards.
[xxx]
> >...
> I would be happy if these cards are available on Plna9.
> Now 100base card are cheap enough, so I really want to connect
> file server and cpu server with 100base cards.

My goal is to have a 10baseT network for terminals and etc.
while having a IP-capable 'backbone' for fs<>cpu communication.
Unfortunately the current fs has no plumbing for IP routing so
all that glop will have to be written plus multiple interface
stuff and config syntax to match.

The 'quick&dirty' way would be to convince fs and cpu that
the 100base is a fiber, but that does not serve my particular
purpose.

One question though:  The plan9 documents show an abstract
picture of a 'large plan9 installation' which contains
(I believe) two cpus connected to an fs over fiber.  Was
there actually a system built with fiber like that anywhere?

> And Eric Dorman says:
> >  The driver compiles cleanly now and I'm going through and
> >checking out all the functions.  I hope to have it working
> >relatively soon.  If you'd like to play with it I can forward
> >the code to you.
> When you finish the work, please forward the code to me.

Sure.  I now have a BayNetworks FA310TX de21140 card, so hope
to have something more available working than the older
Linksys LNE100TX card (sadly NLA).  Presumably the cards jmk
mentioned should work as well.

> Kenji Arisawa
> E-mail: arisawa@aichi-u.ac.jp

Regards,

Eric Dorman
edorman@ucsd.edu

[9fans] 100base ether card

[Eric]

On Thu, Jul 02, 1998 at 09:09:13AM +0000, Kenji Arisawa wrote:
> Hello 9fans!
> Does anyone use 100-base ether cards?
> I would like to buy the cards for my plan9 system.
> Please advise me.
> Kenji Arisawa
> E-mail: arisawa@aichi-u.ac.jp

Hello,
  I've done some of the work in getting a dec 21140-based
card to work, a Linksys LNE100TX (sadly NLA) though the
BayNetworks Netgear FA310TX is also based on this chip.
The driver is based on a brazil driver kindly supplied by jmk,
which is supposed to work with with some other dec 21140-based
 cards as well.

  The driver compiles cleanly now and I'm going through and
checking out all the functions.  I hope to have it working
relatively soon.  If you'd like to play with it I can forward
the code to you.

  One problem I've yet to decide how to solve is how to 
have the fs and everything else use precisely the same 
driver for ether.  While the differences are relatively 
minor, the decision of which target to compile for tends 
to be decided using #ifdefs.  I feel this hides structural 
weakness (fs uses different buffering structure from 
everything else) and is just plain hard to read..  a more
complete solution would be to rewrite the interface layer
on the fs (which I have to do anyway to support multiple
interfaces in the fs) to use the same structure as the 
other codes, then just use the usual set of ether drivers.
Damn sight more work but I think more rewarding in the
long run :)

  I've been delayed on this work since my auth server died
an unnatural death and now I have to replace it :<

Regards,

Eric Dorman
edorman@ucsd.edu

[9fans] 100base ether card

[jim]

We have used a mixture of 100BASE-X cards with Brazil using the
following chips:
	3COM			3C595, 3905, 3C905B
	Intel 82557/8	EtherExpress PRO/100B
					Allied Telesyn 2560FX
	Digital 21140	Fast EtherWORKS PCI 10/100 adapter (DE-500-X)
					Accton EN1207-COM
					Adaptec (Cogent) ANA-6910FX
					SMC 9332
I also have, but untried as yet
	3COM			3C572 (EISA)
	Digital 21140	Netgear FA-310TX 10/100 PCI
					Kingston ENET PCI 10/100
The Netgear costs ~$30, the Kingston ~$40.

All of the tried cards work fine.
Third-party cards based on the 21140 sometimes require more tweaking than
they should to get the link established and I'll be working on that in the
near future.

As to drivers, I gave copies of Brazil drivers for these cards to a couple
of people on the mailing list early this year (maybe even last year)
on the understanding that the backported Plan9 drivers would be made available,
but I haven't heard anything back.

--jim

[9fans] 100base ether card

[Kenji]

Hello 9fans!

Does anyone use 100-base ether cards?
I would like to buy the cards for my plan9 system.
Please advise me.

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp