3

I have a following simple network topology:

server network topology

I saw a situation in this server where ARP requests sender address(192.168.1.15) was from different broadcast domain than the target(10.10.10.252):

server:~ # tcpdump -nei eth0 host 10.10.10.252
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:56:36.152174 00:16:3e:1a:61:b4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.10.10.252 tell 192.168.1.15, length 28
16:56:37.150442 00:16:3e:1a:61:b4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.10.10.252 tell 192.168.1.15, length 28
16:56:38.150449 00:16:3e:1a:61:b4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.10.10.252 tell 192.168.1.15, length 28
16:56:39.159566 00:16:3e:1a:61:b4 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 10.10.10.252 tell 192.168.1.15, length 28
^C
4 packets captured
5 packets received by filter
0 packets dropped by kernel
server:~ #

Am I correct that this behavior is possible because of loose default(0) arp_announce settings?

  • 2
    IMHO that happens because the way you assign two IPv4 addresses to a single interface is not supported well - layer 2 really doesn't know about layer 3 oddities like this one. Please describe why you need two IPv4 addresses in a different broadcast domain, on the same interface, and why other methods (macvlan, VLAN, etc.) won't work for you. – dirkt Dec 19 '17 at 9:24
  • @dirkt I no longer have this setup. I was simply interested, why such ARP requests were sent. – Martin Dec 19 '17 at 15:34
1

You are right on your assumption of why the kernel is accepting/doing those ARPs, however I will explain why they are happening.

The point is that you have here in reality a single broadcast domain with two netblocks.

By definition normally when talking with a subnet, you talk with the network that belongs to the interface connected to that subnet; on the other hand, Linux usually talks by default with the primary IP of the interface.

Thus, when communicating with r1, the Linux machine uses as source the primary IP of the interface (or of the first interface, depending on arp_announce, have to test it out), and as such those ARPs.

Coming back to your assumption why they are accepted, you are pointing at the right place:

arp_announce - INTEGER Define different restriction levels for announcing the local source IP address from IP packets in ARP requests sent on interface: 0 - (default) Use any local address, configured on any interface

Also for sending replies:

arp_filter - 0 - (default) The kernel can respond to arp requests with addresses from other interfaces. This may seem wrong but it usually makes sense, because it increases the chance of successful communication. IP addresses are owned by the complete host on Linux, not by particular interfaces. Only for more complex setups like load- balancing, does this behaviour cause problems.

And in addition to it:

arp_ignore - INTEGER Define different modes for sending replies in response to received ARP requests that resolve local target IP addresses: 0 - (default): reply for any local target IP address, configured on any interface

So we can reach to conclusion that a Linux servers deals with ARPs at server level, and in a very relaxed way by default.

The same could not be true about the router r1 in the picture, it will depend on the local defaults and configurations of it´s OS/firmware.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.