Re: 2 nics, 1 network, puzzle?
At 1017239453s since epoch (03/27/02 10:30:53 -0500 UTC), Shawn Yarbrough wrote:
> What everybody seems to be telling me is that because IP is routable, ARP
> replies are also routable, and the kernel is free to mix and match IP
> addresses with Ethernet interfaces however it likes according to it's IP
> routing conventions. I don't agree with this.
You don't agree that it's what's happening, or you don't agree that it
should be the way that the kernel operates? I'll presume the
latter...
Let me also say this: I'm not trying to say that you're wrong here, or
that the problem your having is your fault. I'm just trying to
explain the way it is, and hopefully that'll be good enough.
> When I configured my network, I explicitly bound two IP
> addresses to two Ethernet addresses.
Not quite. You bound an IP to each interface, but you also bound a
*network* to each interface. What you really said was:
eth0: network 192.168.1.255, address 192.168.1.130
eth1: network 192.168.1.255, address 192.168.1.131
The problem with IP routing is that it works at a network level. When
the kernel wants to send an IP packet, it checks the destination and
then applies the routing rules (the ones you get from 'route -a') to
it. If the final destination of the packet is on a network known to
'route', it sends the packet to that network. If it isn't, it sends
it to the default gateway (the 'default' line from the output of 'route').
Your problem is that you're double-dipping on your network segment;
you have two interfaces to the same network. Forget the fact that
they have different addresses; the only thing that matters to the
kernel is "what network do I send this packet to?" Because it works
at an network level and not an address level, both cards appear the
same to the kernel.
What you're doing with those two cards is somewhat analogous to going
scuba diving with two snorkels. You have two interfaces (snorkels) to
the same network (air), but have arbitrarily assigned them addresses
(left and right). Air comes in through one or both snorkels, but your
lungs don't know which they came from. When you exhale, your lungs
have no power to specify which snorkel the air escapes from.
What you're trying to do is say something like "air that enters
through my left snorkel must only exit through my left snorkel". As
you know, you can't make a rule like that. It's simply a limitation
of the system, and not really anybody's fault.
Notice from my last e-mail that you can fix your problem by assigning
the second NIC to a different network. Because the IP routing is done
on a network level, having the NICs on different networks solves your
problem.
Now, you may ask why the kernel can't just keep an affinity between
interfaces. While I don't hack kernels regularly, the answer is most
likely "because it's easier". Let me play devils advocate for a
minute, and let's look at your proposed setup:
Under the current system, your machine answers both IPs and responds
to pings on both IPs. Therefore, it responds the way you want it to
(it's multihomed). In that respect, it doesn't matter if you're using
one card or two; the outside effect is the same.
Both cards are on the same network segment, so if the segment goes
down, the box goes down. Therefore, the second NIC provides no extra
redundancy in the event of network failure.
Both cards are on the same ethernet segment, so if one is transmitting
or receiving, the other cannot (or else a collision would occur).
Therefore, the second NIC provides no extra bandwidth.
Therefore, the only thing the second NIC provides is failover in the
event that one of your NICs fails. However, even if the NICs were
working the way you wanted them to, if one failed, one of your IPs
would go dark, and half of the connections (roughly, if they were
round-robined) would fail to your machine. It seems to me that you'd
have better luck assigning one address to both NICs, and doing
`ifconfig eth0 down; ifconfig eth1 up` in the event that your box
notices that it can't get a network connection anymore. That's what
you really want anyway: failover (not redundancy).
If you want redundancy, set the second NIC on a different network.
Otherwise, it's not really redundant (as explained above).
Does that make any more sense? Basically, while the kernel doesn't
support what you want, one could ask the question, *why* would you
want to do it in the first place? <g> Again, I'm not trying to say
you're wrong in what you want, but I'm just trying to explain why the
kernel probably won't support it.
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: