Re: 2 nics, 1 network, puzzle?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Well the problem with these scenarios is you can't really do this: Put two
(or more) interfaces in the same computer/router on the same multi-access
(ethernet) network and assign them IPs in the same subnet.
Historically, most platforms wouldn't allow you to assign an IP in the
same subnet as another interface in the box. This was true of Novel
servers as well as Cisco routers. These days many platforms allow you to
do it - but it really doesn't work the way that initial common sense might
make you think.
The problem, as was touched on below, is related to both ARP responses and
outgoing traffic. Lets say you turn up an ethenet interface on a box and
assign it 192.168.1.1/24. The box now basically has a "connected" route to
192.168.1.0/24 with a next hop of this ethernet interface you just turned
up. Now you add another interface and assign it 192.168.1.254/24. The box
now has another "connected" route to 192.168.1.0/24 - through the second
ethernet card. At this point most boxes/routers (if they allow this) will
just choose one of these routes and exclusively use it for sending all
traffic destined to network 192.168.1.0/24. This creates a couple of
problems:
1. Lets say your dual card box has chosen to use interface 1
(192.168.1.1/24) for access to network 192.168.1.0/24. Now imagine adding
a second box to the network with a single interface addressed as
192.168.1.10/24. You log into this box and try to ping 192.168.1.254. The
first thing that happens here is box 2 says "I don't know the MAC address
for this IP" and it sends out an ARP request. The ARP request (which has
an ethernet broadcast address) is received on both interfaces on box 1.
What happens now on a Linux box specifically, I'm not sure, but here is a
guess: The packet is passed up to the kernel twice and one of them is
dropped (it's the same packet after all). The ARP response that is
constructed goes out interface 1 and by virtue of this identifies itself
with the MAC address of interface 1 and on top of that - has the source IP
address of interface one. The result of this is that box 2 never gets the
ARP response it is looking for for 192.168.1.254 and cant send it's ICMP
packet.
2. Outbound traffic from this dual homed box has no standard way to
determine which interface to exit on. Usually if the box allows this to
occur in the first place - it just picks one. However, this situation is
generally confusing to the machine and can cause numerous other problems
or the handling of this situation may just be erratic.
There is a bonding protocol, I think it's 802.1d which is designed to
accomplish basically treating multiple ethernet links as a single logical
unit. Prior to this standard most ethernet switch vendors had their own
proprietary methods of accomplishing bonding of multiple links. I don't
know if there is any support for this as of yet in Linux.
- -Matt
On Wed, 27 Mar 2002, Shawn Yarbrough wrote:
> 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 <shawn@nailstorm.com> 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
> > shawn@nailstorm.com
> >
> >
> > --
> > To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
> > with a subject of "unsubscribe". Trouble? Contact
> > listmaster@lists.debian.org
> >
>
>
> --
> To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Made with pgp4pine 1.76
iD8DBQE8okGVWMfBXOjbFQcRAlL2AKDnR4/wPyhCHWo5W4uhvRCyqrWdhgCeKZ0K
SgW7tgkgZpxb5oM1q5H7ONw=
=u6Og
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: