Por que uma interface de rede precisa ter uma entrada na tabela de roteamento configurada para responder a solicitações ARP?

ARP é um protocolo de camada IP; o kernel assume, por padrão, que não faz sentido responder a solicitações ARP de endereços que não podem ser alcançados por nenhuma rota.

Se você estiver curioso sobre a lógica específica do kernel, ela começa net/ipv4/arp.cna arp_rcvfunção, que se organiza para chamar arp_process, que chama ip_route_input_noref, que é o que, em última análise, faz com que o pacote seja descartado porque o endereço está inacessível.

Você pode alterar um pouco o comportamento desabilitando o rp_filtersysctl, que pode assumir os seguintes valores:

• 0- Nenhuma validação de fonte.

• 1- Modo estrito conforme definido em RFC3704.

  Caminho Reverso Estrito: Cada pacote de entrada é testado contra o FIB e se a interface não for o melhor caminho reverso, a verificação do pacote falhará. Por padrão, os pacotes com falha são descartados.

• 2- Modo solto conforme definido no RFC3704.

  Caminho reverso frouxo: o endereço de origem de cada pacote recebido também é testado em relação ao FIB e, se o endereço de origem não puder ser acessado por nenhuma interface, a verificação do pacote falhará.

Se você desabilitar a validação da fonte configurando rp_filterpara 0:

ip netns exec ns2 sysctl net.ipv4.conf.my_veth2.rp_filter=0
ip netns exec ns2 sysctl net.ipv4.conf.all.rp_filter=0

O valor usado é o maior de my_veth2e, allportanto, precisamos desabilitá-lo alltambém (no meu sistema, o allvalor já era 0, mas nem sempre será esse o caso, então é melhor defini-lo explicitamente).

Então você verá que o kernel realmente responde à solicitação ARP. Se eu executar run ip netns exec ns1 ping 2.3.4.5, vejo o seguinte em ns1:

08:36:00.463621 my_veth1 Out ARP, Request who-has 2.3.4.5 tell 1.2.3.4, length 28
08:36:00.463666 my_veth1 In  ARP, Reply 2.3.4.5 is-at 5a:69:5d:ef:1e:5f, length 28
08:36:00.463672 my_veth1 Out IP 1.2.3.4 > 2.3.4.5: ICMP echo request, id 15496, seq 1, length 64

E em ns2:

08:36:00.463628 ARP, Request who-has 2.3.4.5 tell 1.2.3.4, length 28
08:36:00.463664 ARP, Reply 2.3.4.5 is-at 5a:69:5d:ef:1e:5f, length 28
08:36:00.463673 IP 1.2.3.4 > 2.3.4.5: ICMP echo request, id 15496, seq 1, length 64

Com a validação de origem desabilitada, o kernel responde à solicitação ARP, mas os dois namespaces não conseguem se comunicar porque ainda não há rota de ns2 para ns1, então não há como ns2 responder à pingsolicitação.

Você pode ter o arp_ignoresysctl definido como 2.

sysctl net.ipv4.conf.{all,default,my_veth2}.arp_ignore

Tradicionalmente, o Linux responde ARP para endereços locais pertencentes a todas as interfaces (ou seja, como se os endereços pertencessem ao host como um todo), por exemplo, eth0 responderá com seu próprio endereço MAC em nome de endereços locais atribuídos a eth2. Frequentemente isso é inesperado (e não consigo pensar em muitas situações em que seria de alguma utilidade) e muitos administradores desabilitam esse comportamento configurando arp_ignore=1o que faz o Linux responder ARP apenas para endereços atribuídos à mesma interface. (É assim que o IPv6 NDP sempre se comporta no Linux, e também o mesmo que o IPv4 ARP se comporta em vários outros sistemas operacionais, então arp_ignore=1geralmente é uma boa escolha.)

Mas alguns sistemas vão além e usam arp_ignore=2o que adicionalmente suprime respostas ARP se o endereço IP do remetente (que também é codificado em consultas ARP) não for "parte da mesma sub-rede", o que em termos Linux é determinado pela verificação se há uma rota de link para ela. Tal restrição pode fazer sentido em algumas situações em que múltiplas sub-redes IP compartilham o mesmo domínio de transmissão Ethernet... embora geralmente tais solicitações ARP (como a sua) não ocorram em uso normal.

Documentação/rede/ip-sysctl.rst

arp_ignore - INTEIRO
    Defina diferentes modos para enviar respostas em resposta a
    recebeu solicitações ARP que resolvem endereços IP de destino locais:

    - 0 - (padrão): responder para qualquer endereço IP de destino local, configurado
      em qualquer interface
    - 1 - responder somente se o endereço IP de destino for um endereço local
      configurado na interface de entrada
    - 2 - responder somente se o endereço IP de destino for um endereço local
      configurado na interface de entrada e ambos com o
      o endereço IP do remetente faz parte da mesma sub-rede nesta interface
    - 3 - não responder para endereços locais configurados com escopo host,
      somente resoluções para endereços globais e de link são respondidas
    - 4-7 - reservado
    - 8 - não responda para todos os endereços locais

    O valor máximo de conf/{all,interface}/arp_ignore é usado
    quando a solicitação ARP é recebida na {interface}

Há outro sysctl semelhante, arp_filter, onde a condição é "...se o kernel rotearia ou não um pacote do IP ARP para fora dessa interface (portanto, você deve usar o roteamento baseado na origem para que isso funcione)."