Failover WAN MikroTik: guia técnico com rota recursiva no RouterOS 7

Failover WAN MikroTik configurado só com check-gateway=ping apontando pro gateway do modem tem um problema silencioso: ele detecta cabo desconectado, mas não detecta operadora com internet fora do ar e CPE ainda respondendo. Neste guia, a configuração recursiva completa no RouterOS 7, testada em campo, com dois erros de configuração explicados com o erro real que eles geram.

O sintoma: CPE vivo, sem internet, e o failover não migra

Esse é o sintoma de uma configuração incompleta de failover WAN MikroTik: o modem da operadora continua ligado, respondendo ping normalmente, mas o backbone dela está fora do ar. Um check-gateway=ping apontado direto pro IP do modem nunca vai detectar isso — ele só confirma que o primeiro salto está de pé.

A solução é testar um host de referência fora da rede local (ex: 8.8.8.8), não o modem. Isso exige rota recursiva — e é exatamente aqui que dois detalhes, se ignorados, fazem tudo ficar silenciosamente inativo.

Passo 1 — Confirmar os gateways das duas operadoras

Resultado esperado: dois clients com status=bound, cada um mostrando o campo gateway — é esse endereço que vai entrar nas rotas dos próximos passos. Neste ambiente: WAN1 com gateway 192.168.2.1, WAN2 com gateway 192.168.10.1.

Passo 2 — Criar as rotas de sonda (host de referência por operadora)

Essas rotas dizem apenas “para chegar em 8.8.8.8, use 192.168.2.1 como próximo salto” — são rotas estáticas auxiliares, com gateway diretamente alcançável pela interface WAN, que vão servir de base para a rota recursiva do próximo passo. O scope=10 marca essa rota como candidata válida para resolver outras rotas.

Passo 3 — Rotas default recursivas com target-scope e check-gateway

Aqui está o núcleo do failover WAN MikroTik: a rota default não aponta pro modem, aponta pro host de referência (8.8.8.8). O RouterOS resolve esse gateway recursivamente através da rota de sonda do Passo 2, e o check-gateway=ping nesta rota — não na de sonda — testa a alcançabilidade real da internet, não apenas do modem.

A distância menor (distance=1) marca a WAN1 como principal; a WAN2 só assume quando a rota de distância 1 for marcada inválida pelo teste de ping.

Passo 4 — Desativar a rota automática do DHCP client

Troque ether1/ether2 pelos nomes reais das interfaces WAN do seu ambiente — o RouterOS gera um nome de identificação para cada DHCP client automaticamente quando ele não é definido explicitamente, então não é seguro presumir client1/client2 como nome fixo; filtrar por interface evita esse problema.

Erro de configuração #1: a rota fica “Inactive” mesmo com tudo aparentemente certo

Primeira tentativa real, sem scope nem target-scope definidos:

Resultado: a rota default nunca sai do estado Is (Inactive) no /ip route print — sem nenhum erro visível na tela. Causa: o RouterOS só aceita resolver uma rota recursiva através de outra rota se scope da rota resolvedora for menor que o target-scope da rota recursiva. Sem especificar nada, os dois ficam no valor padrão (scope=30, target-scope=10) — 30 < 10 é falso, a recursão nunca fecha.

Erro de configuração #2: o failover “funciona”, mas não detecta operadora fora do ar

Segunda tentativa, já com scope=10 corrigido, mas check-gateway na rota errada:

Essa versão até ativa a rota, mas o teste de saúde fica na rota /32 — cujo gateway é o modem local. Na prática, o failover volta a testar apenas o CPE, recriando exatamente o problema que a rota recursiva existe para resolver. A correção é mover o check-gateway=ping para a rota default (Passo 3), nunca para a rota de sonda.

Testando o failover sem desconectar cabo

Desconectar fisicamente o link só prova queda de cabo — o cenário que interessa testar na prática é operadora com backbone degradado e CPE ainda vivo. Para simular isso de verdade:

Isso bloqueia só o ping de teste saindo pela WAN1 — o link físico continua de pé, só o probe de saúde passa a falhar. Depois de 20 a 30 segundos (RouterOS testa a cada 10s, marca indisponível após duas falhas seguidas), a rota de distância 2 assume. Remover a regra depois:

Failover recursivo x Netwatch: quando usar cada um

A documentação oficial da MikroTik trata rota recursiva como o método padrão para failover baseado em alcançabilidade de host externo, usando exatamente a combinação scope/target-scope/check-gateway deste artigo — não é uma solução improvisada, é o modelo de referência do fabricante.

O Netwatch é uma ferramenta separada, expandida de forma relevante a partir do RouterOS 7.4: além de ICMP, suporta sondas TCP, HTTP-GET e HTTPS-GET, com intervalo de checagem configurável por host e scripts próprios disparados em cada transição de estado (up/down). Isso o torna mais flexível quando o requisito vai além de rotear — por exemplo, disparar um alerta, gravar log, ou reagir a um serviço específico ficar fora do ar, não só a conectividade genérica.

Na prática: rota recursiva resolve failover de conectividade puro, roda nativamente no kernel de rotas sem depender de script rodando em segundo plano, e foi a escolha usada neste ambiente porque o requisito era exatamente esse — sem necessidade de alertas automatizados. Netwatch vale a pena quando o cenário pede algo além de troca de rota: notificação, teste em nível de aplicação (HTTP, não só ICMP), ou lógica condicional mais complexa.

Por que vale o esforço: o custo real de operar com um único link

Segundo a pesquisa Hourly Cost of Downtime da ITIC (Information Technology Intelligence Consulting), mais de 90% das empresas de médio e grande porte relatam que uma hora de indisponibilidade custa acima de US$ 300 mil. Em empresas pequenas, o valor absoluto pode ser menor, mas a ITIC observa que elas geralmente dispõem de menos recursos e reservas para absorver essas perdas — e mesmo fora de cenários de ataque, uma queda de operadora sem redundância tem o mesmo efeito prático: sistema fiscal, ERP e e-mail inacessíveis até a operadora normalizar o link, sem prazo definido.

Failover automático não elimina o risco de a operadora cair — elimina o tempo que a empresa fica refém de um único fornecedor de link enquanto o problema não é resolvido.

Perguntas frequentes

Por que minha rota default recursiva no MikroTik fica “Inactive” mesmo depois de configurar tudo?
Isso acontece quando o par scope/target-scope fica incompatível. A regra é: o scope da rota auxiliar (a /32 que resolve o host de referência) precisa ser menor que o target-scope da rota default recursiva. Os valores padrão do RouterOS (scope=30, target-scope=10) não satisfazem essa condição sozinhos — é preciso declarar os dois explicitamente; nesta configuração, use scope=10 e target-scope=11.

Failover com check-gateway resolve sozinho ou eu preciso de Netwatch?
Para trocar a rota default quando um link cai ou perde conectividade real, a rota recursiva com check-gateway já resolve sozinha, sem scripts. Netwatch entra quando o requisito é maior que rotear: alertar por log, testar uma porta/serviço específico, ou disparar um script customizado numa transição de estado.

Rota recursiva detecta se a operadora caiu, mesmo com o modem/CPE ligado?
Sim — esse é justamente o ponto central do método. Como o check-gateway testa um host de referência fora da rede local (ex: 8.8.8.8) e não o gateway do modem, uma falha em qualquer ponto entre o modem e o destino — rede de acesso, backbone da operadora, peering — derruba a rota, mesmo que o modem continue respondendo ping normalmente.

Se sua empresa ainda depende de um único link de internet para operar, vale entender o risco real disso antes que uma queda de operadora pare o expediente inteiro — fale com a gente no WhatsApp e avalie a redundância de internet do seu ambiente.