Why does an IP on a dummy interface answer to an ARP request on eth0

Question

I've brought up a dummy interface on my (Ubuntu 15.10) laptop with an ip address of 10.0.3.144, netmask 255.255.255.255

I have a USB -> Ethernet adaptor. When plugged in this is configured to provide an "eth0" interface, which gets its IP address via DHCP in the range 10.0.3.2 - 10.0.3.10 (netmask 255.255.255.0)

I notice that when eth0 comes up - for example on 10.0.3.2, other machines can reach 10.0.3.144 - this is desired behaviour, but I don't understand exactly WHY this is happening. I do not have any kind of bridging set up, so I would have thought that the machine would not have answered for the dummy interface.

I can see arp requests and replies on the laptops eth interface -

tcpdump -n -i eth0 arp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

tcpdump -n -i eth0 arp
14:01:31.948781 ARP, Request who-has 10.0.3.144 tell 10.0.3.254, length 48
14:01:31.948842 ARP, Reply 10.0.3.144 is-at 00:23:55:9c:52:31, length 28

This behaviour is repeatable if I remove the ARP entry on 10.0.3.254 (which happens to be a router also running Linux)

Can anyone advise if I can rely on this behaviour? (and why a computer would answer on the an interface for an IP address not bound to it - and relatedly - would this have the potential to, under certain circumstances, stuff up routing in scenarios where there were multiple interfaces on different subnets and packets should be forced to traverse a firewall?).

Answer 1

why a computer would answer on the an interface for an IP address not bound to it

That's not necessarily true on a Linux host.
The IP address by default belongs to the Linux host, not an interface.
See Linux considers an IP address as belonging to a host rather than an interface

This "feature" of Linux is sometimes referred to as the "ARP flux problem", and is described in section 2.1.4 of Address Resolution Protocol (ARP)

There are several methods of changing this behaviour in Linux. I have in the past patched the kernel to eliminate it. Other methods are less intrusive, as mentioned in the LVS HOWTO.
If you do nothing, then this ARP behaviour should be consistent.

Answer 2

Other devices believe that 10.0.3.144 is part of the network. The 255.255.255.255 subnet mask (a.k.a. /24) specifies the network size of 256 addresses. With the way that subnets are laid out, the 256-address subnet that contains 10.0.3.2-10.0.3.10 is the subnet that goes from 10.0.3.0 through 10.0.3.255. So, when other devices try to communicate to 10.0.3.144, then that address appears to be part of the same subnet. As a result, other devices will try to communicate using Layer 2 (ARP, Ethernet/WiFi), not Layer 3 (routing using IPv4/IPv6).

The computer which receives the Layer 2 traffic is recognizing 10.0.3.144 to be part of a subnet that it uses. So the computer pays attention to the traffic, which is addressed to the computer. Perhaps at a later point, the computer might even realize that 10.0.3.144 is an IP address that is on the other NIC. Because Networking is implemented with different software components, designed to handle one or more of the "layers" of the OSI model, it is entirely possible that the component which recognized 10.0.3.144 to be a Layer 3 IP address is not the same set of instructions/code/programming that determined that the ARP address was acceptable.

Understand that computers do not typically have system-wide IP addresses. Network ports have IP addresses. So each network card typically gets its own IP address.

If you don't want the second network card to be receiving traffic, you may need to do one or more of these things:

• set the IP address to be part of a different subnet. (Seeing a Variable Length Subnet Mask ("VLSM") chart may help to visualize what addresses are part of what subnets. The common charts typically just focus on the last octet, making the charts easiest to understand for /24 - /32 networks (where the first 3 octets of the IPv4 subnet mask are ("255.255.255").
• Disabling forwarding may be helpful. I think different computers may act differently about whether traffic to a different NIC, on the same system, is considered to be "forwarding". If forwarding is enabled, then there should be even less surprise that traffic may have reached another NIC.
• Firewalls may be useful for blocking some types of traffic. (Note that some firewalls may be limited. For instance, I happen to know that in OpenBSD, the DHCP client uses BPFs which don't get blocked by the IP firewall.)

To answer another question: Bridging can often be thought of as "Layer 2 forwarding". Layer 3 forwarding could also result in the traffic crossing to another NIC, even if you're not using Layer 2 bridging.

Regarding whether you can rely on the behavior: I believe so. But you should understand it, and ask questions until you do. Once you understand how things ought to work, you can verify if that is how things are working; if so, it ought to be rather reliable. If there are still mysteries, then surprises may be likely, so do be sure to keep asking about whatever is still unclear.