Failover Inteligente com BGP e Mikrotik CHR

A implementação de uma infraestrutura de rede moderna exige não apenas conectividade, mas inteligência na gestão do tráfego. Para provedores de serviços de internet (ISPs), empresas com múltiplas conexões de alta velocidade e data centers, o failover inteligente deixa de ser um luxo e torna-se uma necessidade crítica. O protocolo BGP (Border Gateway Protocol) é o padrão ouro para roteamento entre sistemas autônomos, oferecendo a flexibilidade necessária para distribuir prefixes de forma granular e eficiente.

Neste tutorial, exploraremos como configurar o MikroTik CHR (Cloud Hosted Router) como um roteador BGP inteligente. Utilizaremos o CHR por sua versatilidade em ambientes cloud e on-premise, permitindo que você gerencie múltiplas WANs (Multi-WAN) com lógica de failover baseada em saúde de link, peso (weight) e preferência (preference), além de anunciar seus próprios endereços IP para a internet.

Pré-requisitos e Topologia Lógica

Antes de tocar na configuração, é fundamental entender a topologia. Para este cenário, assumiremos que você possui:

• Dois provedores de internet (ISP A e ISP B) com links de banda larga ou fibra dedicadas.
• Duas linhas públicas (public IPs) atribuídas por cada ISP, ou um bloco /29 ou maior para anúncio BGP.
• Um servidor MikroTik CHR rodando em uma máquina virtual na nuvem (AWS, Azure, GCP, DigitalOcean ou VPS dedicado).
• Conhecimento básico de IP e roteamento estático.

O objetivo é que o tráfego de saída utilize sempre o link com melhor latência ou custo, e que, em caso de queda de um ISP, todo o tráfego seja desviado automaticamente para o outro, mantendo a conectividade dos seus serviços online.

Passo 1: Configuração Básica da Interface no CHR

O primeiro passo é garantir que as interfaces de rede do CHR estejam corretamente mapeadas e configuradas com os IPs fornecidos pelos seus ISPs. No MikroTik, a interface que se conecta ao gateway do seu provedor geralmente é chamada de wan1, wan2, etc., ou ether1, ether2.

Acesse o WinBox ou o terminal do CHR e defina os endereços IP. É crucial adicionar a flag route-distance=1 para garantir que as rotas estáticas tenham prioridade máxima sobre outras rotas dinâmicas, se necessário, e definir corretamente o gateway padrão.

/ip address
add interface=wlan-isp-a address=203.0.113.5/30
add interface=wlan-isp-b address=198.51.100.5/30

/ip route
add dst-address=0.0.0.0/0 gateway=203.0.113.1 routing-mark=default distance=1
add dst-address=0.0.0.0/0 gateway=198.51.100.1 routing-mark=default distance=1

Atenção: Em muitos casos de BGP, não se deve usar o gateway padrão (0.0.0.0/0) diretamente para o roteamento do sistema operacional do roteador se você estiver fazendo NAT ou encaminhamento complexo. No entanto, para fins de teste de conectividade e inicialização, isso serve. A lógica real será tratada pelas rotas BGP e políticas de roteamento.

Passo 2: Ativação do Roteamento IP

O MikroTik precisa saber que ele atuará como um roteador, encaminhando pacotes entre interfaces. Verifique se o roteamento está habilitado:

/ip settings
set enable-arp=yes max-neighbour-entries=8192 send-trun-c-icmp-error=yes use-ip-forward=yes

Além disso, certifique-se de que a regra de NAT (masquerade) esteja configurada para os clientes ou redes internas que utilizarão esses links, caso você não esteja apenas roteando prefixes públicos via BGP.

Passo 3: Configuração do Protocolo BGP

Agora entramos no coração da configuração. O BGP requer a definição de um ASN (Autonomous System Number). Você pode usar um ASN privado (ex: 64500) se estiver em um ambiente lab, mas para anúncios públicos na internet, você precisará de um ASN público atribuído pela LACNIC, ARIN, etc.

Vamos configurar o grupo BGP e as sessões com os dois ISPs. Suponha que seus peers BGP sejam 203.0.113.1 (ISP A) e 198.51.100.1 (ISP B).

/routing bgp group
add name=upstream-a template=default-external
add name=upstream-b template=default-external

/routing bgp connection
add name=to-isp-a remote-address=203.0.113.1 remote-as=12345 (ASN do ISP A) group=upstream-a template=default
add name=to-isp-b remote-address=198.51.100.1 remote-as=67890 (ASN do ISP B) group=upstream-b template=default

O parâmetro template=default herda configurações padrão, mas você pode criar templates customizados para definir timers de keepalive e hold-time específicos.

Passo 4: Anúncio de Prefixos (Outbound)

Para que o BGP funcione como uma ferramenta de alta disponibilidade, você precisa anunciar seus prefixes. Se você tem um bloco /24 (ex: 192.0.2.0/24) e quer que ele seja acessível via ambos os links, deve anunciá-lo para ambos os peers.

/routing bgp network
add network=192.0.2.0/24 comment="Meu Bloco IP"

/routing filter
add chain=output-bgp out-interface-type=all action=accept route-type=bgp

No entanto, apenas anunciar não garante o failover inteligente. Precisamos influenciar a rota escolhida pelos ISPs e, internamente, pelo próprio CHR para gerenciar o tráfego de retorno se houver assimetria.

Passo 5: Implementação do Failover Inteligente com Route-Maps

Aqui está a diferença entre um roteador básico e um MikroTik CHR profissional. Utilizaremos routing filter para modificar atributos BGP, como BGP-Path-Attributes, especificamente o Local Preference (local-pref) e o Weight.

A estratégia é:

1. Definir uma rota de fallback estática com alta distância.
2. Usar scripts ou monitoramento de link (IP Ping/Health Check) para remover a rota ativa do ISP primário se ele cair.
3. Anunciar o prefixo apenas quando o link estiver saudável, ou usar atributos BGP para indicar preferência.

Uma abordagem robusta no MikroTik é usar Route-Maps ou filtros de rota baseados em routing-mark.

/ip route
add dst-address=192.0.2.0/24 gateway=203.0.113.1 routing-mark=primary-link distance=1
add dst-address=192.0.2.0/24 gateway=198.51.100.1 routing-mark=backup-link distance=10

Neste exemplo, se o link primário (ISP A) estiver ativo, o tráfego local do roteador e as rotas BGP aprendidas preferirão o gateway do ISP A devido à distance=1 versus distance=10.

Para o anúncio externo, queremos garantir que, se o link primário cair, o prefixo seja anunciado via ISP B. Isso pode ser feito dinamicamente com scripts:

/system script
add name="BGP-Announce-Failover" source="
:local status [/ip route get [find dst-address=192.0.2.0/24 routing-mark=primary-link] value-as-string];
:if (\$status !~ \"active\") do={
    /routing bgp network set [find comment=\"Meu Bloco IP\"] disabled=no;
    # Se quiser anunciar preferencialmente via B, ajuste o local-pref ou weight aqui
}
"

No entanto, a maneira mais elegante e nativa de lidar com isso no MikroTik moderno é utilizando BGP Templates com network-import-check. Isso faz com que o BGP só anuncie um prefixo se ele existir na tabela de roteamento principal.

/routing bgp template
add name=with-import-check network-import-check=yes

Se você configurar a rota estática do prefixo para apontar para o ISP A, e remover essa rota (ou torná-la inativa) quando o link cair, o BGP automaticamente deixará de anunciar esse prefixo via ISP A. Se houver uma rota secundária ativa via ISP B, o BGP pode aprender ou anunciar conforme a política.

Passo 6: Monitoramento de Saúde do Link (IP Ping)

O failover inteligente depende da detecção rápida de falhas. O MikroTik possui um sistema poderoso de monitoramento integrado. Não dependa apenas da detecção física da interface; o cabo pode estar conectado, mas a internet pode estar fora.

/ip ping
add address=8.8.8.8 interface=wlan-isp-a count=4 interval=5s destination-timeout=10s

Você pode vincular este ping à remoção de rotas ou ao disparo de scripts. Uma prática comum é usar route monitoring:

/ip route monitor
add route-id=1 interval=30s script=":put \"ISP A está offline\""

Integre isso com um script que altera a distância da rota ou remove a rota ativa, forçando o sistema a usar o ISP B.

Passo 7: Otimização de Performance no CHR

O MikroTik CHR roda em hardware virtual. Para garantir que o roteamento BGP e o failover não consumam todos os recursos da CPU, otimize as configurações:

• Disable ARP para WANs públicas: Se você está apenas roteando tráfego de backbone e não faz NAT/Proxy ARP nas interfaces WAN, desative o ARP para reduzir overhead.

/ip arp
set [find interface=wlan-isp-a] disabled=yes mode=disabled

/ip settings
set tcp-syncookies=yes tcp-max-retrans=5 tcp-syn-retries=3

Passo 8: Testes e Validação

Após aplicar a configuração, valide cada componente:

1. Verifique a sessão BGP: Use /routing bgp connection print para garantir que o estado é "established".
2. Verifique as rotas anunciadas: No terminal do CHR, use /routing bgp network print e verifique se os prefixes estão ativos.
3. Simule uma falha: Desative a interface WAN 1 ou remova o gateway. Observe se a rota BGP via ISP A é retirada da tabela de roteamento local e se o tráfego flui pelo ISP B.
4. Verifique a propagação: Use ferramentas como bgp.he.net (Hurricane Electric) ou looking-glass dos seus ISPs para confirmar que seu prefixo está sendo anunciado e qual caminho está sendo preferido.

Considerações Finais sobre Alta Disponibilidade

A configuração de BGP com MikroTik CHR oferece um nível de controle granular que roteadores domésticos ou empresariais básicos não proporcionam. Ao combinar multi-WAN, monitoramento ativo de saúde do link e políticas de roteamento dinâmicas, você cria uma infraestrutura resiliente.

Lembre-se sempre de manter backups da configuração (/system backup save) e documentar as mudanças. Em ambientes críticos, considere a redundância ativa-ativa, onde o tráfego é balanceado entre os links (ECMP - Equal Cost Multi-Path), desde que seus ISPs permitam isso e sua aplicação suporte conexões multipath sem perda de estado.

A inteligência do BGP reside na capacidade de adaptar-se a mudanças de topologia em tempo real. Com a configuração correta no MikroTik, você transforma simples conexões de internet em uma infraestrutura robusta, pronta para suportar as demandas de serviços críticos e aplicações de alta disponibilidade.