☰

La conectividad IPv6 se pierde repentinamente y el estado del enrutador vecino IPv6 se vuelve STALE al mismo tiempo. ¿Cómo puedo evitarlo?

tag-icon • tag-icon ipv6 arp best-practices
La conectividad IPv6 se pierde repentinamente y el estado del enrutador vecino IPv6 se vuelve STALE al mismo tiempo. ¿Cómo puedo evitarlo?

Tengo una máquina virtual en un host con red en puente (por lo tanto, con su propia dirección MAC). Tanto el host como la VM ejecutan CentOS. Su red se gestiona mediante /etc/sysconfig/network-scripts/ifcfg-enpXsYarchivos simples que contienen direcciones IP estáticas. IPv4 funciona bien.

He asignado una dirección IPv6 a la VM (el host también tiene una) que está enrutada correctamente en el centro de datos. Sin embargo, la mayoría de las conexiones usan IPv4 (aún no hay entrada DNS AAAA para la máquina, todavía estamos probando IPv6).

Cuando inicio la máquina virtual, tiene conectividad IPv6 completa. Sin embargo,Después de un tiempo, la conectividad IPv6 deja de funcionar.(¿Magia IPv6?). He reducido el problema a los datos del vecino (caché ARP/NDISC):

IPv6 no funciona, no puedo hacer ping o conectarme por IPv6 dentro o fuera, entonces veo:

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

Solución/solución alternativa para actualizar el caché:

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

Luego, ping6el host desde la VM para llenar el caché:

# 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

¡La tabla IPv6 vecina/ARP se restableció y la conectividad funciona de manera intermitente!

Entonces mis preguntas son:

  1. ¿Por qué el caché se vuelve obsoleto?
  2. ¿Qué puedo hacer para evitarlo?
  3. ¿Por qué/cómo lo soluciona el comando anterior?

Por supuesto, podría ejecutar esos comandos en un crontrabajo (¿con qué frecuencia?), pero supongo que no es realmente necesario para que IPv6 funcione en general.

PD: utilicé un script para las pruebas:La pila de IPv6 se estropea aproximadamente cada 20 minutos. ¿Puede eso explicarse mediante RFC?

PPS: configuración del firewall (salida abreviada, con suerte todos los 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

Entonces, ICMPv6 aceptó entrada/salida en la VM. ¿Necesito verificar el filtrado en el host?

Respuesta1

En general, el estado estancado es algo bueno; de hecho, es aceptable que tengamos un estado estancado.

Veamos RFC 4861, sección 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.

Ya no se sabe que el vecino es accesible (el temporizador expiró, no hay tráfico últimamente, lo que sea) y la accesibilidad se "verificará" una vez que el tráfico se envíe nuevamente al vecino.

Así que no hay ningún problema si puedes enviar tráfico al vecino nuevamente.

información relacionada