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 | [EMAIL PROTECTED] | http://www.logn.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
