Messages in this thread | | | From | Fred Reimer <> | Subject | RE: Re: ARP (mis)behavior | Date | Fri, 20 Aug 1999 18:18:08 -0400 |
| |
On Fri, 20 Aug 1999, Chris Leech wrote: > I realize that this is not a terribly useful setup, but it was reported to > me by a tester who thought it might be a driver bug of some sort. I guess > what confuses me is if ARP should map an IP to any device on a host or to a > specific device bound to that IP. What I'm hearing here is that the binding > of an IP to a specific network interface is only used to determine routing > of outgoing packets, and that any interface can accept incomming traffic for > any IP assigned to the host.
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/
| |