At 1017271717s since epoch (03/27/02 19:28:37 -0500 UTC), Shawn Yarbrough wrote:
> So, you cram all three 10 Mbit/s network cards into the computer and hook
> it up to the network's 10/100 hub on three seperate ports.
Ethernet is a shared medium. If any one of those three cards
transmits, the hub will repeat it to all the ports, effectively
blocking the other cards from transmitting. Even if the kernel
cooperated with you and let you route packets on each card, the
underlying media would still pin you down to 10Mb/s (the speed of the
network).
This follows from the assumption that each IP subnet corresponds to a
single physical network segment (and vice versa).
Now, if you hooked each of those cards up to a separate network
segment (pardon my terrible ASCII art):
________ _______
|------------------ eth0 (10.0.0.0)-| |
Your | | Your |
Networks|------------------ eth1 (10.0.1.0)-|Server|
________| | |
\__________________eth2 (10.0.2.0)-|______|
Now each of those horizontal lines is a different physical network
segment, each with its own collision domain, so each can run at a full
10Mb/s independently. And, if you set up a Linux box like this, it
will work exactly as you want it to, with no questions asked! This is
what multihoming is.
> Also, of course, you would like something in the kernel to spread the
> outgoing packets between all three interfaces. It would be nice if
> packets from a server socket bound to a particular interface would
> transmit only out that interface, possibly falling back to other less busy
> interfaces when the main interface was congested. But even if the kernel
> randomly spread all outgoing packets between all three network cards, that
> should work pretty well, and I imagine would be easy to implement.
> (but IANAKH).
Getting the kernel to spread the outgoing packets between its
interfaces is a little tricky, but it can be done (by default, you
provide a single default route for non-local packets. Getting linux
to share between multiple available routes requires a few kernel
options and some routing software). Basically, you're turning your
machine into a router; you want it to pick the lowest-cost (least
busy) interface to send its packets out on. I'm not a router admin,
so I don't know what this takes on the average linux box.
> *I* wanted to put multiple cards on one network mainly because I have an
> annoying tendency to "ifdown" the interface that I'm remotely connected
> thru, locking up my terminal and making my remote server unreachable. It
> would be really nice if by installing an extra network card, I could
> always have a backup connection into the server thru which such silly
> mistakes could be fixed after the fact.
That would actually probably work with your current solution. When
you ifdown an interface, I think it takes the routing information with
it. The kernel would (after a brief time) begin answering requests on
the second card. Again, this isn't a standard kind of thing, so the
only way to find out would be to try it.
Note, however, that failover would not be automatic... if your first
card died for some reason (but did not get ifdown'ed), then the
routing info would stay in the kernel, and the second card would never
get used.
> Also I wanted the convienence of having multiple IP addresses without
> having to compile IP aliasing into the kernel, but that's a minor
> thing.
True. Also, the stock Debian kernels should have this, right? I
don't use it, so I haven't checked, but the Debian kernels tend to
have a maximum of stuff rolled into them. Of course, if you roll your
own...
> I really, really, don't see why this doesn't work automatically.
See previous e-mail. <g>
I hope this clears things up somewhat. What you want isn't
unreasonable, but given the way the underlying ethernet protocol is
designed, and its interaction with IP, the kernel makes some
assumptions that prevent you from getting what you want. The kernel
does this because (1) the assumptions are valid according to the
protocols and (2) because its easier to code and faster for the
machine to implement.
Rock on,
Jason
--
Jason Healy | [EMAIL PROTECTED] | http://www.logn.net/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
