I've thought up a good example of why somebody might want to put multiple network cards, in one computer, all on the same network:
Imagine that you have an existing 100 Mbit/s network, a fast computer not yet on the network, and three salvaged 10 Mbit/s network cards. Sure, you could go out and buy a shiny new 100 Mbit/s network card... but why? I think Linux should help you to preserve your existing hardware investment. 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. You run an ftp server bound to eth0, a web server bound to eth1, and an IRC server bound to eth2. Your fast computer is now a 30 Mbit/s server on a 100Mbit/s network. Oops, except that the kernel screws up the the ARP resolution, so that web and IRC clients all connect on the one card that was supposed to be mainly for the ftp server. 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). *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. 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. I really, really, don't see why this doesn't work automatically. Already knowing how to install network cards in Linux, I thought I would just install two cards onto the same network and run with it. Is this *really* that difficult to implement? On Tue, 26 Mar 2002 10:31:45 -0600 Shawn Yarbrough <[EMAIL PROTECTED]> wrote: > I have an x86 server computer containing two network cards: > > eth0 --> 192.168.1.130 > eth1 --> 192.168.1.131 > > Both cards work fine alone. As you can see, both cards are on the same > network. The subnet mask is 255.255.255.0. I can disable either card > with ifdown and sucessfully ping the other card from elsewhere on the > network. > > The puzzle comes when both cards are up at the same time. > > The kernel seems to pick one of the cards (somewhat arbitrarily) and > starts answering pings to BOTH addresses on the ONE card! Could this be > some kind of ARP bug? I can physically pull the plug out of the other > card (the one that the kernel appears to not be using anymore) and the > system still answers pings to both addresses! > > > I first noticed this strange behavior by watching the indicator lights > during pings. Pings to both addresses are clearly going thru only one > of the cards. The other card remains idle. > > This is a Debian Woody system (freshly installed and not currently in > use for anything). The behavior is identical running either kernel > 2.2.20 or kernel 2.4.18. In /etc/network/options the ip_forward setting > is no. > > This is NOT a router-type computer. It's just a server that I really > want to have on the same network, twice. And I'd rather not use IP > aliasing + one card. I really want two cards for convienence and > redundancy. (ex: in theory if one card failed or was misconfigured I > should still be able to reach the machine through the other card). > > > Anyone got a clue what's going on here? Thanks, > > Shawn Yarbrough > [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
