☰

A conectividade IPv6 foi perdida repentinamente e o status do roteador vizinho IPv6 se tornou STALE ao mesmo tempo. Como posso evitar isso?

tag-icon • tag-icon ipv6 arp best-practices
A conectividade IPv6 foi perdida repentinamente e o status do roteador vizinho IPv6 se tornou STALE ao mesmo tempo. Como posso evitar isso?

Eu tenho uma VM em um host com rede em ponte (portanto, com seu próprio endereço MAC). Tanto o host quanto a VM executam o CentOS. Sua rede é gerenciada por /etc/sysconfig/network-scripts/ifcfg-enpXsYarquivos simples que contêm endereços IP estáticos. IPv4 funciona perfeitamente.

Atribuí um endereço IPv6 à VM (o host também possui um) que é roteado corretamente no data center. No entanto, a maioria das conexões usa IPv4 (ainda não há entrada DNS AAAA para a máquina, ainda estamos testando o IPv6).

Quando inicializo a VM, ela tem conectividade IPv6 completa. No entanto,depois de um tempo, a conectividade IPv6 para de funcionar(mágica IPv6?). Limitei o problema aos dados do vizinho (cache ARP/NDISC):

IPv6 não funciona, não consigo executar ping ou conectar-me por entrada ou saída IPv6, então vejo:

# ip -6 neighbour 
fe80::1 dev enp1s2 lladdr 0c:86:72:2e:04:28 router STALE

Correção/solução alternativa para atualizar o cache:

# ip -6 neighbour flush dev enp1s2
# ip -6 neighbour
(empty, as expected)

Em seguida, ping6o host da VM para preencher o cache:

# ping6 2912:1375:23:9a6c::2
PING 2912:1375:23:9a6c::2(2912:1375:23:9a6c::2) 56 data bytes
64 bytes from 2912:1375:23:9a6c::2: icmp_seq=1 ttl=64 time=2.35 ms
64 bytes from 2912:1375:23:9a6c::2: icmp_seq=2 ttl=64 time=0.468 ms
^C
# ip -6 neighbour
fe80::1 dev enp1s2 lladdr 0c:86:72:2e:04:28 router REACHABLE
2912:1375:23:9a6c::2 dev enp1s2 lladdr 08:21:4b:b7:f8:31 DELAY

Tabela vizinho IPv6/ARP restaurada para validade e a conectividade está funcionando dentro e fora!

Então minhas perguntas são:

  1. Por que o cache fica obsoleto?
  2. O que posso fazer para evitá-lo?'
  3. Por que/como o comando acima corrige isso?

É claro que eu poderia executar esses comandos em um crontrabalho (com que frequência?), Mas suponho que isso não seja realmente necessário para que o IPv6 funcione em geral.

PS: usei um script para testes:A pilha IPv6 quebra a cada 20 minutos. Isso pode ser explicado pelas RFCs?

PPS: Configuração do firewall (saída abreviada, esperançosamente todos os bits relevantes):

# ip6tables -nvL
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 9023  709K ACCEPT     icmpv6    !lo    *       ::/0                 ::/0                
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 9360  785K ACCEPT     icmpv6    *      !lo     ::/0                 ::/0

Portanto, ICMPv6 aceito entrada/saída na VM. Preciso verificar a filtragem no host?

Responder1

Geralmente o estado obsoleto é uma coisa boa; na verdade, é aceitável que tenhamos um estado obsoleto.

Vejamos RFC 4861, seção 5.1. :

  STALE       The neighbor is no longer known to be reachable but until traffic is sent to the neighbor, no attempt should be made to verify its reachability.

O vizinho não é mais acessível (temporizador expirou, nenhum tráfego ultimamente, seja o que for) e a acessibilidade será 'verificada' assim que o tráfego for enviado ao vizinho novamente.

Portanto, não há problema se você puder enviar tráfego para o vizinho novamente.

informação relacionada