Estoy al límite de mi ingenio, por lo que se agradece cualquier ayuda.
Tengo un host IPv6 (Linux 4.15.1-gentoo SMP x86_64) que deja de enviar anuncios de vecinos de forma aleatoria. La ejecución de tcpdump muestra muchas solicitudes de solicitud de vecinos y casi ninguna reacción a esas solicitudes. Ocasionalmente, el host seguirá enviando NA, pero solo después de un par de docenas de solicitudes NS ignoradas. Obviamente, esto rompe por completo la conectividad IPv6.
No sé si es relevante, pero IPv6 está configurado en una interfaz puente (también se ejecutan un par de contenedores lxc en ese puente). El puente es un puente brctl típico con STP desactivado.
IPv6 está configurado estáticamente (tanto el host como la puerta de enlace).
Inundar manualmente la red con anuncios de vecinos no solicitados (usando ndsenddesde, vzctlpor ejemplo) puede mitigar un poco el problema, pero obviamente no es una solución.
Lo que es aún más extraño, deshabilitar y volver a habilitar ipv6 en la interfaz a través de procfs ( /proc/sys/net/ipv6/conf/br0/disable_ipv6) y reconfigurarlo ( ip -6 addr add, etc.) "soluciona" temporalmente el problema. Sin embargo, vuelve a suceder en uno o dos días.
Para completar, hay un firewall nftables ejecutándose en el host, pero permite explícitamente todo el tráfico icmpv6 (a través de ip6 nexthdr ipv6-icmp accepttodas partes). Deshabilitar el firewall cuando se manifiesta el problema no cambia nada.
Entonces, aquí está la pregunta: ¿qué puedo hacer para identificar el problema subyacente?
ACTUALIZAR: Para mí, el problema desapareció después de algunas actualizaciones del kernel, pero hay informes de problemas similares en versiones posteriores del kernel, particularmente con tablas de enrutamiento grandes y/o una gran cantidad de vecinos. Según se informa, un posible culpable aquí es el pequeño límite en el tamaño de caché de ruta/vecino ipv6 en el kernel. Si tiene problemas similares, intente aumentar net.ipv6.route.max_sizeel parámetro sysctl a un valor relativamente grande ( 1048576por ejemplo), ejecutando sysctl -w net.ipv6.route.max_size=1048576y/o editando /etc/sysctl.conf. También es probable que desee aumentar net.ipv6.route.gc_threshpara evitar ejecutar el recolector de basura con demasiada frecuencia. Además, verifique net.ipv6.neigh.default.gc_thresh1y
net.ipv6.neigh.default.gc_thresh2si
net.ipv6.neigh.default.gc_thresh3tiene muchos registros en la caché vecina. Verhttps://www.kernel.org/doc/Documentation/networking/ip-sysctl.txtpor lo que hacen todas esas opciones.
Respuesta1
Acabo de descubrir que hay un error en multicast_snooping en puentes compatibles con Linux VLAN. No afectará los anuncios del enrutador, pero bloqueará el descubrimiento de vecinos incluso si multicast_flooding está activado. Lo que sucede es que al arrancar un sistema funcionará como papá, y ese papá permanecerá en la base de datos de reenvío de multidifusión. Pero eso caduca después de 200 o 300 segundos. Después de eso, cualquier paquete de multidifusión de descubrimiento de vecinos se descartará en ese puerto. Esto sólo sucede con el descubrimiento de vecinos, no con la publicidad del enrutador. Puedes presenciarlo haciendo:
bridge mdb show
Si le muestra entradas, tendrá activado multicast_snooping. Y es posible que experimente/experimentará el error. En mi caso, aproximadamente el 80% de los sistemas que configuré comenzaron a bloquear la multidifusión de descubrimiento de vecinos únicamente. Cualquier otra multidifusión está inundada o espiada correctamente.
La solución por ahora es desactivar multicast_snooping:
echo 0 > /sys/net/devicename/bridge/multicast_snooping
Cuando tenga tiempo haré una prueba de configuración. Este error me ha estado picando el trasero durante 2 años y finalmente tuve tiempo durante el mantenimiento de emergencia para comprender completamente el problema.
Respuesta2
Estaba teniendo el mismo problema con un kernel 4.16.2-gentoo. Pero en mi caso resultó no tener ninguna relación con el kernel.
La caja en cuestión servía como puerta de enlace VPN ipv6 y tenía una conexión estable. Incluso el enrutador de subred detrás de él estaba perfectamente bien, solo la subred enrutada perdía conexión constantemente.
TL;DR;
cortafuegosfue el culpable en mi caso. el ipv6filtrorpLa configuración filtró las solicitudes de vecinos de mi enrutador de subred.
Descúbrelo habilitando el inicio de sesión/etc/firewalld/firewalld.conf
LogDenied=all
lo que resultó en loglines como (MAC y SRC acortados y ofuscados):
kernel: rpfilter_DROP: IN=enp6s0.100 OUT= MAC=XX:…:XX SRC=fe80:…:beaf DST=ff02:0000:0000:0000:0000:0001:ff00:0001 LEN=72 TC=0 HOPLIMIT=255 FLOWLBL=0 PROTO=ICMPv6 TYPE=135 CODE=0
Acabo de desactivar el rpfilter ipv6 hasta que pueda descubrir por qué sucede esto. La configuración es bastante simple y todo me parece bien, pero tal vez sea un problema con la interfaz al ser una VLAN...