Failover de link no Mikrotik: como configurar saída automática por link secundário

Todo provedor que já passou por uma queda de link de backbone sem ter para onde correr sabe a sensação: o telefone não para de tocar, o grupo de WhatsApp de bairro já está reclamando e não existe nada a fazer além de esperar a operadora de trânsito resolver. Failover de link não elimina o problema de origem, mas evita que uma falha externa — que nem sempre está sob controle do provedor — derrube a operação inteira.

O que é failover, na prática

Failover é a capacidade da rede de detectar que um link principal caiu e redirecionar automaticamente o tráfego para um link secundário, sem depender de alguém perceber a queda e trocar rota manualmente às pressas. No Mikrotik, isso é montado combinando duas ferramentas: rotas com distância administrativa diferente (a rota do link secundário só é usada quando a principal falha) e Netwatch, que monitora um IP de referência e dispara uma ação quando ele para de responder.

Passo a passo básico

1. Cadastre duas rotas padrão (0.0.0.0/0): uma para o link primário com distância menor (ex.: 1) e outra para o secundário com distância maior (ex.: 2). O Mikrotik usa a de menor distância enquanto ela estiver ativa.

2. Configure Netwatch apontando para um IP confiável e estável do lado do link primário (o gateway da operadora, por exemplo), com intervalo de checagem curto o suficiente para detectar a queda rápido, mas não tão curto que gere falso positivo por instabilidade momentânea.

3. No script "down" do Netwatch, desative a rota do link primário (ou aumente sua distância), forçando o tráfego a passar pelo secundário.

4. No script "up", reative a rota original quando o link primário voltar — decida se o retorno deve ser automático ou manual, dependendo de quão instável costuma ser aquele link.

5. Teste de verdade, desconectando fisicamente o link primário em um horário de baixo movimento, antes de confiar no failover em produção.

O que costuma dar errado

O erro mais comum é monitorar um IP que não representa de fato a saúde do link — por exemplo, um IP dentro da própria rede do provedor, que continua respondendo mesmo com o link de trânsito fora do ar. O ponto monitorado precisa estar do outro lado do link, refletindo a conectividade real com a operadora. Outro erro é não testar o retorno (failback): failover que funciona na queda mas trava ou duplica rota na hora de voltar ao link primário causa uma segunda instabilidade em cima da primeira.

Vale a pena para um provedor pequeno?

Failover exige contratar (e pagar por) um segundo link, o que tem custo real e nem sempre cabe no orçamento de quem está começando. A decisão costuma fazer sentido quando o provedor já depende de uma única operadora de trânsito para toda a base e uma queda de algumas horas representa um risco reputacional e financeiro maior do que o custo mensal do link secundário — especialmente à medida que a base cresce e a exposição a esse risco aumenta.

Failover resolve a rede, não o resto da operação

Ter dois links redundantes evita a queda total, mas não avisa automaticamente o time nem documenta o histórico de indisponibilidade para análise depois. O ZISP tem monitoramento SNMP das interfaces de rede com alerta de queda em massa, sinalizando quando um evento afeta um percentual relevante da base — inclusive útil para acompanhar se o failover realmente segurou a operação durante uma queda de link. Para conhecer, acesse sistema.zisp.com.br.