Re: 2 nics, 1 network, puzzle?
At 1017168824s since epoch (03/26/02 14:53:44 -0500 UTC), Shawn Yarbrough wrote:
> What is blowing my mind is that the ping request is actually entering the
> system on the wrong interface, presumably because the system is responding
> to my switch's ARP query on the "wrong" interface.
>
> I think that if I unplug the network cable attached to .131, nobody on the
> network should be able to ping the .131 interface anymore, unless perhaps
> I was doing some really tricky (and *explicit*) proxy-ARP magic, which I'm
> not, or maybe if the system was a router, which it isn't.
IANAKH (I am not a kernel hacker), but I'll take a shot anyway. It's
been a while since my networking course in college, but here's my
theory (feel free to comment/correct/flame):
You've got two things going right now: IP and Ethernet. The kernel
knows about IP addresses, and the card(s) know about ethernet.
So you've got two cards, each on the same IP subnet. The kernel's
routing table now has two entries for the same subnet:
192.168.1.0 eth0
192.168.1.0 eth1
As you suspected, for outgoing packets, the kernel will simply pick a
route and send the traffic through it. Usually, it just picks the
first one it finds (eth0) and uses it for everything. Many people
(myself included) have quickly found out that you can't hook up 2 NICs
and hope for double the bandwidth -- it just doesn't work that way
(and, for reasons external to the box, it probably wouldn't work even
if the kernel supported balancing between the two cards).
Incoming packets, however, are a little different. I'm a little fuzzy
on what's going on, but here's my theory:
You turn on both NICs. The kernel's routing table now has both
entries in it, and the kernel now knows that it has two IP addresses:
.130 and .131.
Somebody tries to ping .130. Because the IP address is not known
to the network yet, an ARP goes out. Your machine receives it, and
answers it. But it answers the ARP using the first route it picks.
Let's assume that it picks the correct card, eth0 (.130).
Now someone pings .131. The ARP goes out, your box gets it, and it
sends out an answer. But again, the answer goes out on the default
link (eth0). The result is that everyone's ARP cache now has the MAC
address of eth0 stored for both IP addresses. There's nothing wrong
with this; it's exactly what IP aliasing would have done.
Your NIC doesn't know (or care) about IP; it simply listens for its
MAC address on the network and passes valid frames in to the machine.
The kernel doesn't care about MAC addresses (unless you're running
firewall code); it will happily accept and decode IP packets
regardless of the interface they came in on. This is why a good
firewall does sanity checking on packets to ensure that they arrived
on the correct interfaces. Is this a security bug? Maybe.
So what we're left with is the fact that you're running IP aliasing,
even though you really didn't mean to. Again, this is my theory, but
you could check it. Get on another machine, ping both your IPs,
and then check the pinging machine's ARP cache (`arp` on a linux box
will show this). If the same MAC address is listed for both IPs, then
that's what you're getting.
Now, as for what to do with the second card (as it would be a shame to
let it go to waste). You could leave it in, and have it 'down' most
of the time. Run some kind of heartbeat on the box, and if eth0 dies,
bring eth1 up in its place.
Even easier is to set eth1 up on a different subnet (192.168.0.2).
This is true multihoming, with each NIC on a different subnet. The
kernel should correctly route packets in this case. However, this
requires you to actually have a second subnet to connect to. If you
don't have one, don't just invent one on the same ethernet segment; it
won't be worth the trouble. But if you do have multiple subnets,
that's an easy (and correct) way to use the second NIC.
Hope something in there helped somebody,
Jason
--
Jason Healy | jhealy@logn.net | http://www.logn.net/
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: