Como criar failover automático em dual-WAN com BGP local

Por que o failover tradicional falha em ambientes críticos

Quando uma empresa depende de conexões de internet ininterruptas, confiar apenas no balanceamento básico de carga ou em scripts simples de ping costuma gerar dores de cabeça. Na prática, isso significa que se a operadora principal perder a conexão com o restante do mundo, mas o cabo continuar plugado no seu roteador, um teste cego de cabo ligado pode achar que está tudo bem e manter o tráfego indo para o buraco negro. Para resolver isso em redes corporativas exigentes, precisamos recorrer a protocolos de roteamento dinâmico que conversam diretamente com a infraestrutura das operadoras ou que gerenciam políticas locais rígidas.

O BGP (Border Gateway Protocol, o protocolo que gerencia como os dados viajam entre diferentes redes na internet) costuma ser associado apenas a grandes provedores de trânsito. No entanto, usá-lo de forma local nos roteadores de borda da sua própria empresa muda completamente o cenário de resiliência. Antes de aprofundar na configuração, vale lembrar que gerenciar gargalos de infraestrutura não se restringe à rede, exigindo atenção também a outros subsistemas, como detalhamos no artigo sobre como diagnosticar gargalos de IOPS no Linux para manter o armazenamento estável sob estresse operacional.

Como funciona o BGP local na borda da rede

O BGP local atua como um mensageiro inteligente entre o seu roteador principal e os modems ou roteadores de borda fornecidos pelas suas duas operadoras de internet. Em vez de simplesmente mandar todo o tráfego para um gateway padrão fixo, o roteador conversa via BGP com cada operadora para descobrir quais rotas estão realmente ativas e eficientes naquele momento. Na prática, se o circuito da Operadora A apresentar lentidão extrema ou perda severa de pacotes, o protocolo percebe a mudança de estado e desvia o fluxo de dados para a Operadora B em questão de segundos, sem que os usuários percebam a oscilação.

Para colocar essa arquitetura de pé, o equipamento de borda precisa suportar sessões eBGP (External BGP) com os roteadores de borda de cada ISP (Provedor de Serviços de Internet). Cada operadora fornece um número de AS (Autonomous System, o identificador numérico único que cada rede usa na internet) privado para a sessão local. O grande segredo dessa abordagem é que a decisão de failover deixa de depender de um script frágil rodando no sistema operacional e passa a ser uma decisão nativa do plano de controle do roteador, baseada em políticas determinísticas.

Configurando a redundância e os atributos de caminho

A configuração prática exige definir qual link será o preferencial e qual atuará estritamente como backup. Para fazer isso no BGP, utilizamos atributos de caminho, sendo o AS-Path Prepend o mecanismo mais comum e acessível. Na prática, injetar repetições do seu próprio número de AS no anúncio enviado para a operadora secundária faz com que aquele caminho pareça mais longo e menos atraente para o tráfego que retorna, garantindo que a Operadora A seja sempre a via principal enquanto estiver saudável.

Além de ajustar a saída, precisamos monitorar a entrada de forma rigorosa. Caso você já domine a estruturação de tráfego interno, vale conferir também como configurar VLANs e roteamento inter-VLAN no switch para isolar corretamente o tráfego da borda antes que ele chegue ao núcleo da rede. Abaixo, veja um exemplo simplificado de configuração em um roteador de borda utilizando sintaxe estilo FRRouting ou roteadores baseados em Linux:

router bgp 65000
  bgp router-id 192.168.100.1
  neighbor 203.0.113.1 remote-as 65001
  neighbor 198.51.100.1 remote-as 65002
  !
  address-family ipv4 unicast
    network 192.0.2.0/24
    neighbor 203.0.113.1 activate
    neighbor 203.0.113.1 route-map PREFER-ISP1 in
    neighbor 198.51.100.1 activate
    neighbor 198.51.100.1 route-map BACKUP-ISP2 in
  exit-address-family
!
ip prefix-list PL-LOCAL permit 192.0.2.0/24
route-map PREFER-ISP1 permit 10
  set local-preference 200
route-map BACKUP-ISP2 permit 10
  set local-preference 100
  set as-path prepend 65000 65000

Validando a convergência e testando o failover na prática

Após aplicar a configuração, o momento mais importante é simular a falha real para garantir que o sistema reaja exatamente como planejado. Desconectar o cabo físico da operadora principal é o teste de fogo definitivo. Na prática, você deve observar o tempo que o roteador leva para derrubar a sessão BGP por falta de Keepalives e assumir completamente o link secundário. Se esse tempo passar de trinta segundos, os usuários de serviços em tempo real, como chamadas de vídeo ou sistemas VoIP, notarão quedas incômodas.

Para mitigar atrasos na detecção de falhas onde o cabo continua conectado mas a operadora perdeu conectividade upstream, ativamos o BFD (Bidirectional Forwarding Detection). O BFD dispara pacotes ultrarrápidos de teste de enlace a cada milissegundo, avisando o BGP imediatamente sobre qualquer anomalia física ou lógica. Dessa forma, a transição entre links deixa de ser um evento demorado e passa a ser imperceptível para as aplicações corporativas hospedadas no ambiente local.

Considerações finais sobre resiliência de borda

Criar uma arquitetura de alta disponibilidade com dual-WAN e BGP local transforma a estabilidade de uma operação que antes sofria com quedas repentinas de link. Embora exija equipamentos com maior capacidade de processamento e conhecimento técnico refinado na equipe de infraestrutura, os ganhos operacionais compensam o esforço inicial. Manter redundâncias ativas e testadas regularmente garante que o negócio continue rodando sem interrupções indesejadas, blindando a empresa contra falhas imprevisíveis das operadoras de telecomunicações.