Você está certo em sua suposição de por que o kernel está aceitando / fazendo esses ARPs, no entanto eu explicarei por que eles estão acontecendo.
O ponto é que você tem aqui, na realidade, um único domínio de broadcast com dois netblocks.
Por definição, normalmente, ao falar com uma sub-rede, você fala com a rede que pertence à interface conectada a essa sub-rede; por outro lado, o Linux geralmente fala por padrão com o IP primário da interface.
Assim, ao comunicar-se com r1, a máquina Linux usa como fonte o IP primário da interface (ou da primeira interface, dependendo do arp_announce , tem que testá-la) e, portanto, esses ARPs.
Voltando à suposição de por que eles são aceitos, você está apontando para o lugar certo:
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
Também para enviar respostas:
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.
E além disso:
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
Assim, podemos chegar à conclusão de que os servidores Linux lidam com ARPs no nível do servidor e de uma forma muito descontraída por padrão .
O mesmo não pode ser verdade sobre o roteador r1 na imagem, isso dependerá dos padrões e configurações locais do sistema operacional / firmware.