Date: Wed, 13 Mar 2002 15:28:54 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: "Jeremy C. Reed" <reed@reedmedia.net> Cc: freebsd-chat@freebsd.org Subject: Re: ethernet interface listening to other interface's IP Message-ID: <3C8FE0B6.F831632A@mindspring.com> References: <Pine.LNX.4.43.0203131351060.31667-100000@pilchuck.reedmedia.net>
next in thread | previous in thread | raw e-mail | index | archive | help
"Jeremy C. Reed" wrote: > Should an ethernet interface listen to another interface's IPs? > > I've been told that all flavours of Unix work that way. I should do some > tests, but I am interested in some comments. What do you mean "listen"? In general, unless a cards MAC address is the destination address for the ethernet frame, then the interface will discard it, unless the interface is in promiscuous mode. By default, no interfaces are in promiscous mode. The section of RFC 1122 on multihoming that DES pointed you to is actually only relevent in the "Weak ES Model", where you are getting the packets up the IP stack because they are on a wire you atached to with an interface in promiscuous mode, or you are acting as a gateway, and are the designated gateway for the packets on the local wire. Normally, the only time this would happen is for a non-gateway host with an interface in promiscuous mode (e.g. running tcpdump). In general, it's bogus to do: ,-------. | A | `-------' | o-------+---------------+---------------+----------o 10.0.0/24 | | ,-------. ,-------. | 1 | | 2 | `-------' `-------' | | o-------+---------------+---------------+----------o 10.0.1/24 | ,-------. | B | `-------' And expect one machine to take over for the other automtaically, unless you are running something like VRRP, and (1) and (2) are acting as routers. Even then, you need explicit hardware support for VRRP domain MAC addresses, and the ARP failover has to be done corectly. If on the other hand, you have: ,-------. | A | `-------' | o-------+---------------+---------------+----------o 10.0.0/24 | | ,-------. ,-------. | 1 | | 2 | `-------' `-------' And A periodically makes connections to 10.0.0.1, and tha machine dies, and you expect 10.0.0.2 to take over... well, IP failover is another problem. It's partially resolvable using something like VRRP, but since (1) and (2) are endpoints, you can't expect the takeover to be transparent. Also, like the VRRP case, it is an error for the machine which is not the primary to respond to ARP "who has" requests for the secondary. > I was told (under Linux) that this server had two NIC cards configured > with different IPs, but with one cable disconnected from one NIC card, the > other interface still listened to the other's IP. This is wrong, unless they have an explicit failover mechanism. Actually, if you refer to the first diagram, getting from (A) to 10.0.1.1 depends on the gateway from the 10.0.0/24 to the 10.0.1/24 network. It's possible that if (1) was the designated gateway, and (1) went down *AND* you had a VRRP style protocol, then the path could change from A->10.0.0.1->10.0.1.1 to transit through (2) instead, e.g. A->10.0.0.2->10.0.1.2->10.0.1.1 (say if the interface for 10.0.0.1 failed). Most likely, though your IP address for the gateway would be something like 10.0.0.V, for the IP of the virtual router, which was then associated with the virtual MAC address. In the failover case, the virtual MAC address has to physically move to the other card for this to work. For Tigon II cards, there are 2 MAC addresses you can assign like this (though the driver does not support it, nor does FreeBSD's ARP code or network interface code, which would have to have a cloned driver for the other interface). For Tigon III cards, this goes up, and for Intel Gigabit cards, it goes to 4. None of these are sufficient for service failover (for example), which really can't be handed correctly in terms of current hardware, though there are some kludges that are close to working, which involve raw ethernet packets and putting the card into promiscuous mode at all times (the if_ep cards can actually be made to "support" two MACs by abusing the multicast mask). Plus FreeBSD supports none of this failover voodoo anyway, because it lacks the necessary infrastructure for the multiple MACs on one card with correct ARP handling. > I was told that you have to firewall so the packets will only be accepted > on the correct interface. Packets are only accepted if the MAC address matches a MAC address on the card, or a multicast group that passes the multicast mask on the card. If you don't jam the card into promiscuous mode, then it's not a problem, since you will only ever get packets from the card that match the MAC address. To prove this to yourself, on a non-gateway machine (so that the ARP doesn't cause the packets to be sent to the machines MAC address to transit the gateway, and therefore bypass the card MAC check), do a tcpdump without putting the interface into promiscouous mode (the "-p" option to tcpdump disables use of promiscuous mode). > I think that that you shouldn't have to setup a firewall as a workaround: > If your NIC card is configured for a particular IP and you want to stop > it, then simply unplugging the ethernet cable should do it. > > (I do understand that many services listen to INADDR_ANY; but I am > referring to the connection being listened to in the first place at the > interface itself.) > > What is the correct behaviour and why? See the posting by DES. If your interface has the MAC address that is the target for the ARP for the "who has" for the IP address, or if the interface is in promiscous mode, or if the interface is known to be the gateway and so your IP represents the default route for the packet from another machine, then the packet won't make it in. If you want the packet to be denied based on its source, when you have misconfigured your hardware, or have intentionally configured it to acpet packets that you don't want it to accept (begs the question: why the heck did you do that in the first palce, if you didn't want it to act the way you configured it to act?!?), then you have to stop it using the sysctl DES suggested. In general, this shouldn't *ever* be necessary, unless you've screwed up your configuration. The only reason I could think of for actually doing this would be to offer differential service to hosts on the same wire by virtue of their gateway address. In general, putting more than one physical card on the same wire in one machine is a really bad thing to do. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C8FE0B6.F831632A>