Multi-homing BGP em provedor: por que o failover não funciona quando precisa

Quase todo provedor que contrata o segundo trânsito acredita que acabou de comprar redundância. Na prática, comprou a possibilidade de redundância. O que decide se ela existe ou não é a política de roteamento, e ela costuma ser escrita no dia da instalação, às pressas, e nunca mais revisada.

O teste é simples e quase ninguém faz: derrube o link principal em uma janela combinada e meça quanto tempo o cliente fica sem internet. Se ninguém na empresa sabe responder esse número, a resposta provavelmente não vai agradar.

1. A sessão continua de pé com o link morto

O caso mais frustrante. O enlace físico caiu ou está entregando 90% de perda, mas a sessão BGP continua estabelecida porque o hold timer padrão é de 90 segundos e o roteador ainda não desistiu do vizinho.

Durante esse período, o seu roteador continua mandando tráfego por um caminho que não entrega nada. O cliente sente instabilidade total, não failover.

A correção é BFD. Ele detecta a falha em milissegundos, e não em dezenas de segundos, e derruba a sessão BGP imediatamente:

! exemplo em sintaxe Cisco
router bgp 65000
 neighbor 203.0.113.1 fall-over bfd

interface GigabitEthernet0/0
 bfd interval 300 min_rx 300 multiplier 3

Onde BFD não estiver disponível, reduzir os timers de BGP ajuda, com a ressalva de que timers muito agressivos deixam a sessão sensível a qualquer microcorte.

2. O tráfego sai por um link e volta por outro

Esse é o clássico da assimetria. Você controla como o tráfego sai da sua rede com local preference. Não controla como ele entra: quem decide isso é a rede do outro lado, olhando o que você anuncia.

O resultado é um cenário em que o link A está saturado na saída e ocioso na entrada, enquanto o B faz o inverso. Quando o A cai, metade do tráfego converge rápido e a outra metade depende de quanto tempo o mundo leva para reprocessar os seus anúncios.

As ferramentas para influenciar a entrada são três, em ordem de eficácia real:

• Communities do upstream. A maioria dos trânsitos publica communities que ajustam a local preference deles. É o controle mais preciso que existe, e o mais ignorado.
• AS-path prepend. Funciona, é grosseiro e tem efeito colateral: alguns provedores no caminho ignoram AS-path longo por política própria.
• Desagregação de prefixo. Anunciar blocos mais específicos por link. Funciona bem e polui a tabela global. Use com moderação.

3. O prefixo mais específico entra por onde não devia

Um provedor com /22 que anuncia dois /23 para balancear entrada precisa entender que, se um dos /23 for anunciado só por um link e esse link cair, aquele bloco fica inacessível até o roteamento convergir para o /22 agregado.

A regra é simples e frequentemente esquecida: todo prefixo específico precisa ter o agregado anunciado em todos os links. Assim, quando o específico some, o agregado sustenta o tráfego.

4. O filtro protege contra o vizinho e não contra você mesmo

Filtro de entrada quase todo mundo tem. Filtro de saída é o que evita que o seu AS vire manchete.

Sem prefix-list de saída, um erro de redistribuição pode fazer o seu roteador anunciar rotas aprendidas de um trânsito para o outro. Nesse instante o seu provedor de porte médio se ofereceu como trânsito para a internet inteira, e o link cai sob o peso do tráfego alheio.

O conjunto mínimo:

• Prefix-list de saída permitindo apenas os seus blocos e os dos seus clientes.
• AS-path filter garantindo que só saia o que tem o seu AS na origem.
• Max-prefix em cada sessão, para derrubar o vizinho que começar a anunciar tabela cheia por engano.
• ROA publicado e validação RPKI, que hoje é o que impede sequestro de prefixo de virar problema seu.

Como testar de verdade

Um teste de failover que vale alguma coisa tem quatro etapas:

1. Escolha uma janela e avise a operação. Isso não se testa às escondidas.
2. Deixe um ping contínuo e um MTR rodando de dentro da rede para um destino estável fora dela.
3. Derrube o link principal na interface, não com shutdown da sessão BGP. Simular a queda no lugar errado esconde exatamente o problema do item 1.
4. Meça: quantos pacotes se perderam, em quantos segundos a rota alternativa assumiu e se o caminho de volta acompanhou.

Depois, repita derrubando o secundário. Redundância que só foi testada em um sentido é meia redundância.

O número que você deveria conseguir

Com BFD, filtros corretos e política revisada, a convergência entre trânsitos fica na casa de poucos segundos, e a maior parte dos clientes não percebe. Sem isso, o intervalo entre 30 e 120 segundos é o normal, e é tempo suficiente para derrubar chamada de voz, sessão de jogo e videoconferência de todo mundo ao mesmo tempo.

Se você não sabe qual dos dois cenários é o seu, esse é o primeiro item da consultoria em BGP e peering: ler o que está configurado hoje, testar a queda de forma controlada e entregar o número real por escrito, com a ordem de correção.

Vale olhar junto duas frentes que costumam aparecer no mesmo diagnóstico: um looking glass próprio, que mostra ao peer o que você anuncia sem dar acesso ao roteador, e o monitoramento, para que a próxima queda apareça no alerta antes de aparecer no WhatsApp.