MikroTik PCC: balanceamento e failover entre dois links

Quando a empresa contrata um segundo link de internet, o erro mais comum é configurá-lo
só como backup manual: alguém troca o cabo quando o principal cai. O Per
Connection Classifier (PCC) do MikroTik RouterOS resolve isso de forma automática,
distribuindo as conexões novas entre os dois provedores e trocando de rota sozinho quando um
deles para de responder — sem intervenção manual e sem downtime perceptível para o usuário.

Este guia configura um RouterOS 7.24.5 (versão estável atual) com duas interfaces WAN, cada
uma em um provedor diferente, usando PCC para balancear e rotas recursivas com
check-gateway para o failover.

Por que PCC em vez de ECMP simples

O RouterOS também permite balancear com rotas de mesmo custo (ECMP), mas isso distribui
pacote a pacote: uma mesma sessão TCP pode trocar de provedor no meio da
conexão, o que derruba acessos sensíveis a IP de origem — internet banking, WhatsApp Web,
VPN corporativa, chamadas de vídeo. O PCC resolve isso com hash sobre endereço de origem e
destino: a conexão inteira fica presa a um único link do início ao fim, e só a
próxima conexão nova é que pode cair no outro provedor.

É por isso que o PCC é o método recomendado pela própria comunidade MikroTik para
balanceamento de WAN em ambiente comercial, mesmo sendo mais trabalhoso de configurar que o
ECMP.

Pré-requisitos

• RouterBoard ou CHR com RouterOS 7.x (os comandos abaixo usam a sintaxe v7; em v6 os nomes
  de rota mudam, mas a lógica é a mesma).
• Dois links de internet já funcionando separadamente, cada um com IP e gateway do provedor
  anotados.
• Uma interface de WAN em cada provedor (ether1 e ether2 neste exemplo) e uma rede local na
  ether3.

Topologia de exemplo usada no restante do guia — ajuste os IPs para os do seu provedor:

• ISP 1: ether1, IP 200.200.1.2/30, gateway 200.200.1.1
• ISP 2: ether2, IP 200.200.2.2/30, gateway 200.200.2.1
• LAN: ether3, rede 192.168.88.0/24

Passo a passo

1. Crie as duas tabelas de roteamento, uma para cada provedor:

   /routing table
   add name=to-ISP1 fib
   add name=to-ISP2 fib

2. Marque as conexões novas vindas da LAN com o PCC, dividindo pelo hash de
   endereço de origem e destino:

   /ip firewall mangle
   add chain=prerouting in-interface=ether3 connection-state=new per-connection-classifier=both-addresses:2/0 action=mark-connection new-connection-mark=isp1-conn passthrough=yes
   add chain=prerouting in-interface=ether3 connection-state=new per-connection-classifier=both-addresses:2/1 action=mark-connection new-connection-mark=isp2-conn passthrough=yes

   O 2/0 e 2/1 dizem ao RouterOS para dividir as conexões em 2 grupos
   e pegar o resto 0 ou o resto 1 do hash — é isso que faz a divisão ficar equilibrada entre os
   dois links sem precisar contar conexão por conexão.

3. Associe cada marca de conexão à tabela de roteamento correspondente:

   /ip firewall mangle
   add chain=prerouting connection-mark=isp1-conn action=mark-routing new-routing-mark=to-ISP1 passthrough=yes
   add chain=prerouting connection-mark=isp2-conn action=mark-routing new-routing-mark=to-ISP2 passthrough=yes

4. Crie as rotas com verificação de gateway. O check-gateway=ping
   é o que detecta a queda do link — o RouterOS envia pings periódicos ao gateway do provedor e
   desativa a rota automaticamente se parar de responder:

   /ip route
   add dst-address=0.0.0.0/0 gateway=200.200.1.1 routing-table=to-ISP1 check-gateway=ping distance=1
   add dst-address=0.0.0.0/0 gateway=200.200.2.1 routing-table=to-ISP2 check-gateway=ping distance=1

   Essas duas rotas garantem que o tráfego já marcado para um provedor saiba por onde sair.
   Agora as rotas da tabela principal, que cobrem o failover de verdade — se o link 1 cair, o
   tráfego que estava marcado para ele também precisa de um caminho alternativo:

   /ip route
   add dst-address=0.0.0.0/0 gateway=200.200.1.1 check-gateway=ping distance=1
   add dst-address=0.0.0.0/0 gateway=200.200.2.1 check-gateway=ping distance=2

   Com distância 1 e 2, o provedor 1 é o preferido na tabela principal; se ele cair, a rota some
   da tabela de roteamento e o RouterOS passa a usar o gateway de distância 2 automaticamente.

5. Configure o NAT de saída para cada link — sem isso, o retorno do tráfego
   não bate com o IP público correto e a conexão não fecha:

   /ip firewall nat
   add chain=srcnat out-interface=ether1 action=masquerade
   add chain=srcnat out-interface=ether2 action=masquerade

6. Teste o failover. Desligue fisicamente (ou desative a interface de) um dos
   links e acompanhe em tempo real:

   /ip route print where check-gateway=ping

   A rota do link derrubado aparece marcada como inativa em poucos segundos — o intervalo padrão
   de ping do check-gateway é curto o suficiente para o corte ser quase imperceptível
   numa navegação comum. Reative a interface e confirme que a rota volta a ficar ativa sozinha.

Erros comuns

• Esquecer o NAT por interface — sem marcar o masquerade em cada link, o
  tráfego sai pelo provedor certo mas o retorno se perde, e a navegação trava de forma
  intermitente.
• Usar check-gateway=ping num gateway que não responde ping —
  alguns provedores bloqueam ICMP no gateway de borda. Nesse caso, aponte o
  check-gateway para um IP confiável atrás do provedor (como o DNS dele) em vez do
  gateway direto, ou use check-gateway=arp quando o gateway estiver na mesma
  sub-rede.
• Misturar as marcas de rota com regras de mangle antigas — se o roteador já
  tinha outras regras de mangle, posicione as novas regras de PCC antes de qualquer
  accept genérico na chain prerouting, senão elas nunca são
  alcançadas.

Perguntas frequentes

O PCC divide o tráfego exatamente 50/50 entre os dois links?
Não por volume de dados — por número de conexões novas. Se um usuário abrir uma transferência
grande num link e vários acessos pequenos no outro, o consumo de banda fica desbalanceado
mesmo com a divisão de conexões equilibrada. Para links de capacidades diferentes, é possível
ajustar a proporção trocando 2/0 e 2/1 por uma divisão maior, como
3/0, 3/1 e 3/2, direcionando mais fatias para o link mais
rápido.

O que acontece se os dois links caírem ao mesmo tempo?
Nenhuma rota de WAN fica ativa e a rede local perde saída para a internet, mas o tráfego interno
continua funcionando normalmente — o PCC e o failover só atuam sobre o que sai para fora.

Funciona com mais de dois provedores?
Sim. O mesmo padrão se estende para três ou mais links, bastando criar uma tabela de roteamento
e um par de regras de mangle para cada provedor adicional, e ajustar a divisão do PCC de
2/X para N/X, onde N é o número total de links.

Preciso de IP fixo dos provedores para isso funcionar?
Não é obrigatório — funciona com IP dinâmico também, mas é preciso então usar o nome da interface
WAN como referência nas rotas em vez do IP fixo do gateway, já que ele pode mudar.

Dá para priorizar um site ou serviço específico sempre pelo mesmo link?
Sim, criando uma regra de mangle específica para o IP ou porta de destino antes das regras de
PCC, marcando a rota diretamente para a tabela do provedor desejado — essa regra, por estar
antes, tem prioridade sobre a divisão automática.

Conclusão

Com PCC e rotas recursivas, o segundo link de internet deixa de ser um seguro que só funciona
quando alguém percebe a queda do principal e passa a agir como balanceamento ativo o tempo todo,
com failover automático em segundos. O próximo ajuste natural depois desse, em redes com tráfego
mais sensível, é diferenciar o tipo de tráfego por regra de mangle — por exemplo, mantendo VoIP
sempre no link de menor latência medido.