Estou perdendo o juízo, então qualquer ajuda será apreciada.
Eu tenho um host IPv6 (Linux 4.15.1-gentoo SMP x86_64) que para aleatoriamente de enviar anúncios de vizinhos. A execução do tcpdump mostra muitas solicitações de solicitação de vizinhos e quase nenhuma reação a essas solicitações. Ocasionalmente, o host ainda enviará NA, mas somente depois de algumas dúzias de solicitações NS ignoradas. Obviamente, isso quebra completamente a conectividade IPv6.
Não sei se é relevante, mas o IPv6 está configurado em uma interface de ponte (alguns contêineres lxc também estão sendo executados nessa ponte). A ponte é uma ponte brctl típica com STP desativado.
O IPv6 é configurado estaticamente (host e gateway).
Inundar manualmente a rede com anúncios de vizinhos não solicitados (usando ndsendfrom, vzctlpor exemplo) pode atenuar um pouco o problema, mas obviamente não é uma solução.
O que é ainda mais estranho, desabilitar e reativar o ipv6 na interface via procfs ( /proc/sys/net/ipv6/conf/br0/disable_ipv6) e reconfigurá-lo ( ip -6 addr add, etc) "corrige" temporariamente o problema. Acontece novamente em um ou dois dias.
Para fins de integridade, há um firewall nftables em execução no host, mas permite explicitamente todo o tráfego icmpv6 (via ip6 nexthdr ipv6-icmp acceptqualquer lugar). Desativar o firewall quando o problema se manifesta não muda nada.
Então, aqui está a pergunta: o que posso fazer para identificar o problema subjacente?
ATUALIZAR: Para mim, o problema desapareceu após algumas atualizações do kernel, mas há relatos de problemas semelhantes em versões posteriores do kernel, particularmente com grandes tabelas de roteamento e/ou um grande número de vizinhos. Alegadamente, um possível culpado aqui é o pequeno limite no tamanho do cache da rota/vizinho IPv6 no kernel. Se você estiver tendo problemas semelhantes, tente aumentar net.ipv6.route.max_sizeo parâmetro sysctl para um valor relativamente grande (por exemplo, 1048576), por exemplo, executando sysctl -w net.ipv6.route.max_size=1048576e/ou editando /etc/sysctl.conf. Você provavelmente também desejará aumentar net.ipv6.route.gc_threshpara evitar executar o coletor de lixo com muita frequência. Além disso, verifique net.ipv6.neigh.default.gc_thresh1se
net.ipv6.neigh.default.gc_thresh2você
net.ipv6.neigh.default.gc_thresh3possui muitos registros no cache vizinho. Verhttps://www.kernel.org/doc/Documentation/networking/ip-sysctl.txtpara saber o que todas essas opções fazem.
Responder1
Acabei de descobrir que há um bug no multicast_snooping em pontes com reconhecimento de vlan do Linux. Ele não afetará os anúncios do roteador, mas bloqueará a descoberta de vizinhos mesmo se o multicast_flooding estiver ativado. O que acontece é que na inicialização de um sistema ele fará o pai, e esse pai permanecerá no banco de dados de encaminhamento multicast. Mas isso expira depois de 200 ou 300s. Depois disso, qualquer pacote multicast de descoberta de vizinho será descartado nessa porta. Isso só acontece com a descoberta de vizinhos, não com a publicidade do roteador. Você pode testemunhar isso fazendo:
bridge mdb show
Se mostrar entradas, o multicast_snooping estará ativado. E você pode/irá experimentar o bug. No meu caso, cerca de 80% dos sistemas que configurei começaram a bloquear apenas o multicast de descoberta de vizinhos. Qualquer outro multicast é inundado ou espionado corretamente.
A solução por enquanto é desligar o multicast_snooping:
echo 0 > /sys/net/devicename/bridge/multicast_snooping
Quando tiver tempo farei uma configuração de teste. Esse bug está me afetando há 2 anos e finalmente tive tempo durante a manutenção de emergência para compreender completamente o problema.
Responder2
Eu estava tendo o mesmo problema com um kernel 4.16.2-gentoo. Mas, no meu caso, acabou não tendo nenhuma relação com o kernel.
A caixa em questão servia como VPN-Gateway ipv6 e estava com conexão estável. Até mesmo o roteador de sub-rede por trás dele estava perfeitamente bem, apenas a própria sub-rede roteada perdia constantemente a conexão.
DR;
firewalldfoi o culpado no meu caso. O ipv6filtro rpconfiguração filtrou as solicitações de vizinhos do meu roteador de sub-rede.
Descobri isso ativando o login/etc/firewalld/firewalld.conf
LogDenied=all
o que resultou em loglines como (MAC e SRC encurtados e 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
Acabei de desabilitar o rpfilter ipv6 até descobrir por que isso está acontecendo. A configuração é bastante simples e tudo parece bem para mim, mas talvez seja um problema com a interface ser uma vlan...