Well, it's my understanding is that "it depends." Say you have two
>separate< networks, A and B. Your IP's are 192.168.1.1 on network A
and 192.168.2.1 on network B (both 24 bit mask). If a device on
network A (say 192.168.1.222) sent a packet to your IP on network B
your interface on network A will surely "accept" the packet. But why?
Well, the other device on network A would have to have a routing entry
for network B pointing to your IP address locally (on network A).
Otherwise it wouldn't know where to send the packet. So it will do an
ARP for your IP address on network A, which you respond to. Then it
sends the packet to your IP on network B, but the MAC address is for
the "gateway" or your interface on network A. You "receive" the packet
because it is destined for your MAC.
What happens now depends on how you have your computer configured. If
you have ip_forward turned OFF should you "route" the packet to your
other interface (internally) or drop the packet? Without being an IP
stack expert and not looking at any RFCs I'd guess that you should drop
the packet. What about if you have ipchains and some firewall stuff
configured? Well that definately can have an impact which would depend
on how you setup the rules.
In "general" though, with ip_forward turned on and no firewall rules
blocking the traffic, packets sent to the interface on network B will
"appear" to be accepted on interface A. I don't think that
symantically it's that simple though.
> What I had exepected to find was not for the requested IP in an ARP request
> to be compared against all IPs on the host, but instead only against any IPs
> bound to the interface that the packet was recieved on.
I would expect the same behavior, >especially< when you start talking
about interfaces on different segments and network numbers. Why should
the interface on network A (192.168.1.1) reply to an ARP for the
interface on network B (192.168.2.1)? It's clear that it should not do
that, as the MAC address of the interface 192.168.2.1 is configured for
is not even on the Ethernet segment where the ARP originated from (but
that specific ARP should not even be sent out as it's not to a
"local"/same subnet IP address). Interface A would have to enter
promiscuous mode even to "see" the traffic destined for Interface B.
Now, let's assume that the interfaces are configured with two IP's in
the same subnet and on the same Ethernet "segment." Actually, let's be
clear and call it an Ethernet broadcast domain (most people use
switches now a days, especially when you have so much traffic you need
two interfaces on the same IP subnet). Let's say the interfaces are
eth0 and eth1 with IP's 192.168.1.1 and 192.168.1.2 and MACs
000000000001 and 000000000002 respectively (I know - just imagine!). A
user with IP 192.168.1.3 (same subnet) sends out an ARP for
192.168.1.1. It's broadcast, because it's an ARP. Both eth0 and eth1
receive the packet. Should eth0 respond? I would hope so. It sends
of MAC 000000000001 in the response. If the switch didn't already have
it in it's FDB table it puts MAC 000000000001 on port 1 (where eth0 is
plugged into).
What does your computer do to the ARP that it receives on eth1? Does
it respond? If so, does it respond with MAC 000000000001 or MAC
000000000002? If it responds with MAC 000000000001 then the switch
would change the FDB to point to port 2 (where eth1 is plugged in) for
this MAC. eth1 wouldn't see any traffic unless it was in promiscuous
mode for that MAC. All traffic to MAC 000000000001 would be going
to eth1 instead of eth0 and eth1 wouldn't "see" the traffic. That would
not be good.
If it responded with MAC 000000000002 what would happen? Well, the
switch would map that MAC to port 2, correctly. The PC would think
that the MAC for IP 192.168.1.1 was 000000000002 incorrectly. Other
devices may think the IP was at 000000000001. It would look like there
were duplicate IP addresses to any intelligent network administration
utilities. In addition, what would the PC do with two responses to an
ARP with different MACs? Would it take the first one and ignore the
second or the opposite? What about the switch? If it's a layer 3
switch it would have an ARP table itself in addition to a FDB (for
routing from other subnets). Does it store the interface in the ARP
table in addition to the MAC address (and VLAN)? I believe the switches
I've seen do. If it had different timings for FDB timeouts and ARP
table timeouts could it get into a situation where it thought IP
192.168.1.1 had MAC 000000000002 in port 1 (or MAC 000000000001 in port
2)? If so, eth0 or eth1 (or both) would have to be in promiscuous mode
in order to get traffic destined for it.
I would conclude that there are just to many "bad" things that could
happen if interfaces respond to ARP requests for IP's they are not
configured for. Because of the advent of switches (both layer 2 and
layer 3) I believe the only "correct" behaviour would be for ONLY the
interface that was configured for a particular IP address to respond to
ARPs for the IP address. May be this is not addressed in any current
RFCs, but I can't think of a reason this "standard" should not be
implemented in Linux.
If a "special" configuration was possible where the same IP address was
configurable on two separate interfaces that shared the same MAC then I
wouldn't see any problem with either of them replying to an ARP. The
only "complication" would be that the FDB table would bounce between
port 1 and port 2 for each packet send out the interfaces. (the switch
ARP table would bounce the port the IP/MAC was on also but this
wouldn't cause any "problems" unless the switch software couldn't
handle flipping the tables around so much -- because of possible issues
with the switch software even this behaviour could cause "problems"
that you might not see until you actually pushed utilization to a very
high level on both interfaces simultaneously).
Sorry for the "rant" but hopefully this will cause some discussion on
how things "should" work...
> I did question some people about it, but perhaps I'll go do some
testing on > other OSs to see how they behave in this strange situation.
>
> Thanks for the feedback,
>
> Chris Leech
> christopher.leech@intel.com
>
> ------Original Message------
> From: "Richard B. Johnson" <root@chaos.analogic.com>
>
> Err.. Do you, per chance, have both network cards running on the same
> network, with the same network address, and a netmask which will allow
> them to listen to the same ARP requests? If so, how could they do
> anything different than you describe?
>
>
> Cheers,
> Dick Johnson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/