Como distinguir um loop de roteamento de uma rota que oscila em sites VPN
Um loop de roteamento e uma rota instável causam a mesma perda intermitente. Três verificações nos gateways os distinguem antes que você mude qualquer coisa.
Dois sites, um túnel e um prefixo remoto que responde por um tempo e depois silencia. O reflexo é chamá-lo de loop de roteamento, e às vezes é exatamente isso. Mas um loop e uma rota instável produzem a mesma queixa e exigem reparos opostos: um é uma decisão de encaminhamento que nunca termina, o outro é um prefixo que não para de sair da tabela. Três observações os separam, e você pode coletar as três na linha de comando do gateway antes de tocar num filtro ou reiniciar um túnel.
Um loop é decidido salto a salto. O site A escolhe B como próximo salto para o destino, B escolhe A para o mesmo destino, e o pacote expira no TTL após duas idas e voltas. Uma oscilação é decidida, em vez disso, pelo protocolo de roteamento: o prefixo é retirado, reinstalado ou substituído por um próximo salto alternativo, de modo que alguns pacotes não têm rota alguma enquanto outros seguem uma perfeitamente boa.
As três verificações que resolvem a questão
Você não precisa de captura de pacotes para a primeira decisão. Precisa do estado do prefixo nas duas pontas, do próximo salto que cada lado escolhe e de uma contagem de saltos que se repete ou não. Se o prefixo continua instalado com o mesmo próximo salto enquanto o tráfego falha, o loop vive no caminho de encaminhamento. Se o prefixo desaparece e volta, a falha está acima do encaminhamento e o reparo pertence ao protocolo de roteamento, não a uma rota estática.
| Observation | Routing loop | Route flapping |
|---|---|---|
| Prefix in the table | Installed, same next hop throughout | Withdrawn and reinstalled, or next hop alternates |
| Hop count | Reaches zero at the same two gateways | Expires only while the prefix is missing |
| Failure shape | Consistent loss for that prefix from every source | Bursts, often after a link or peer event |
| Where the fix belongs | The site that owns the prefix, plus filters on the transit path | Advertisement, hold timers, or the flapping link |
Um aviso antes de começar. Se você lê isto através do túnel que está em loop, sua sessão morre no momento em que você mudar a rota. Abra um console ou um caminho de gestão que não dependa do prefixo que você está prestes a reparar.
Verificação um: o prefixo é estável ou está fervendo
Pergunte ao kernel o que ele instalou, não o que o arquivo de configuração promete. Num gateway Linux, ip route get 10.20.30.40 executa a mesma consulta que o caminho de encaminhamento executa, incluindo as tabelas de políticas, enquanto ip route show 10.20.30.0/24 mostra a própria entrada. ip monitor route transmite cada mudança no momento em que acontece, que é a forma mais rápida de ver um prefixo chegar e sair.
Num roteador com FRR ou BIRD, a tabela de encaminhamento não é a interessante. show ip bgp 10.20.30.0/24 devolve o caminho selecionado e seu tempo de atividade; um tempo de atividade que se reinicia a cada poucos minutos é uma oscilação que você pode nomear, não um loop. show ip bgp summary mostra o estado dos vizinhos e as contagens de prefixos, então um par que cai sem parar tira a culpa do caminho de encaminhamento.
Anote a resposta antes de mudar qualquer coisa. Estável por dez minutos enquanto os pings falhavam, e desaparecido quatro vezes em dez minutos, levam a passos seguintes diferentes. O segundo caso torna irrelevante qualquer teoria de rota estática.
Verificação dois: o próximo salto aponta de volta para o túnel de chegada
Um loop exige que dois gateways concordem. No site que recebe o pacote, olhe a rota que o pacote usará para sair: ip route get 10.20.30.40 from 10.10.5.20 com o endereço de origem real, porque uma regra de política pode responder diferente da tabela principal. Depois repita a consulta no site que o enviou. Se cada lado escolhe o outro como próximo salto para o mesmo prefixo, o loop está provado e nenhuma captura acrescentará nada.
A causa é quase sempre um anúncio que não deveria ter atravessado o túnel. Uma rota padrão redistribuída para dentro do túnel, um agregado que cobre a própria sub-rede do site remoto ou uma rota estática apontando para o par por precaução criam todos o mesmo próximo salto mútuo. O túnel pode estar plenamente estabelecido e ainda assim levar tráfego em círculo; as notas de encaminhamento do strongSwan descrevem o lado de roteamento desse requisito.
O WireGuard merece uma nota própria, porque não há anúncio para culpar. wg show lista os AllowedIPs de cada par, e o kernel só aceita um destino para um par se ele cair dentro desse intervalo. Um loop ali é um intervalo de AllowedIPs sobreposto ou uma rota estática que aponta de volta pela interface, então o reparo vive nesses dois lugares e em nenhum outro.
Verificação três: leia a contagem de saltos, não as estrelas
traceroute -n -I 10.20.30.40 e mtr -n -r -c 20 10.20.30.40 mostram ambos o caminho, e o modo ICMP costuma sobreviver a uma filtragem que come as sondas UDP. Um loop parece uma sequência curta e repetida dos mesmos dois endereços de gateway com o TTL subindo a cada vez. Uma queda parece estrelas depois do último gateway que respondeu, e um único salto silencioso não é prova de nada.
Quando o caminho é ambíguo, leia o TTL no fio. tcpdump -ni any -vv icmp nos dois gateways mostra o TTL de cada pacote e o endereço de origem de cada resposta de tempo excedido. Se um pacote chega ao site remoto com um TTL menor que o número de saltos que o caminho pode conter, algo está acrescentando saltos que o traceroute não mostra, e isso acontece quando o firewall de um site responde às sondas em nome de outro.
Repare o dono do prefixo e depois verifique as duas direções
Decida qual site origina o destino e quais caminhos de trânsito são permitidos, e então mude o anúncio ou a rota estática naquele dono. Corrigir o site receptor é tentador e geralmente errado: esconde o loop para um prefixo e deixa o anúncio ruim no lugar para o próximo. Etiquetas de rota, listas de distribuição e regras de horizonte dividido existem para parar isso na origem, e são mais baratas que um filtro que coincide com um único prefixo.
Depois da mudança, verifique a ida e a volta separadamente, porque um loop pode ser substituído por um buraco negro sem nenhuma melhora visível do sintoma. Execute ip route get das duas pontas, envie tráfego de um host que não seja o gateway, e deixe ip monitor route rodando por pelo menos um temporizador de retenção para que uma oscilação não seja confundida com um reparo.
Antes de mudar qualquer coisa, confirme estes cinco pontos: o prefixo é estável ou está fervendo, o próximo salto nas duas pontas aponta para um túnel, a contagem de saltos se repete ou não, um único site possui o prefixo, e você tem um caminho de gestão que sobrevive à mudança. Se um dos cinco é desconhecido, os outros quatro são suposições.