MikroTik RouterOS para ISPs: configuração correta de gestão de assinantes com RADIUS e PPPoE
O MikroTik RouterOS é, sem exagero, a espinha dorsal dos ISPs pequenos e médios da América Latina. Em qualquer cidade média da Argentina, Chile, Colômbia ou Peru, há pelo menos três ISPs que começaram com um RB450G na sala de servidores e hoje têm centenas ou milhares de clientes conectados através dessa mesma plataforma (agora com hardware mais moderno, mas a lógica operacional é a mesma).
O problema não é o MikroTik. O problema é que as configurações que se aprendem nos primeiros anos de operação, que funcionam perfeitamente em pequena escala, não escalam bem. E quando falham, fazem isso de formas que nem sempre são óbvias: desempenho degradado que parece problema do cliente, faturamento incorreto porque o accounting não está bem configurado, ou um core router que processa filas por software e degrada a experiência de todos os assinantes quando há congestionamento.
Este artigo foi escrito para engenheiros de ISPs médios que já sabem usar RouterOS e querem entender onde estão os limites e como superá-los corretamente.
Por que o MikroTik domina os ISPs da Latam
A resposta curta é: preço, funcionalidade e comunidade.
Um CHR (Cloud Hosted Router) ou um CCR (Cloud Core Router) oferecem funcionalidades que em hardware de outros vendors custariam de cinco a dez vezes mais. PPPoE server, RADIUS client, firewall stateful, roteamento dinâmico (OSPF, BGP, IS-IS), MPLS, bonding, túneis GRE/IPIP/L2TP: tudo vem incluído na licença do RouterOS, sem módulos adicionais.
A comunidade também é um fator real. O fórum do MikroTik tem décadas de configurações documentadas. Há grupos de WhatsApp e Telegram de engenheiros de ISPs em quase todos os países da região onde se compartilham configurações, diagnosticam problemas e anunciam vulnerabilidades antes que os CVEs oficiais cheguem. Esse ecossistema informal tem um valor operacional enorme para equipes pequenas sem acesso a suporte de vendor de primeiro nível.
A consequência dessa acessibilidade, no entanto, é que muitos ISPs operam com configurações que foram copiadas de um tutorial de 2015 e nunca revisadas. Funcionam. Até que não funcionam.
O problema: o que escala com 100 clientes quebra com 5.000
Quando um ISP tem 100 assinantes PPPoE, quase qualquer configuração funciona. O roteador tem capacidade de sobra, os tempos de autenticação são toleráveis mesmo com o servidor RADIUS local (Hotspot Manager ou User Manager), e as filas são processadas em microssegundos.
Aos 5.000 assinantes, essas mesmas configurações geram problemas sistêmicos:
A autenticação local não escala. O User Manager do RouterOS não foi projetado para lidar com a base de dados de um ISP médio, nem para se integrar com um sistema de billing externo de forma confiável. À medida que a base de clientes cresce, os tempos de autenticação aumentam, as mudanças de perfil (upgrades de plano, suspensões) requerem intervenção manual no roteador, e o processo de auditoria de conexões ativas se torna manual e impreciso.
Simple Queue em um roteador de núcleo mata o desempenho. Cada Simple Queue no RouterOS consome ciclos de CPU no processo de enfileiramento. Com 5.000 assinantes ativos, esse processo pode saturar um núcleo completo do processador, degradando o desempenho geral do roteador mesmo que o uplink tenha capacidade disponível.
Sem accounting, o billing é uma estimativa. Se os dados de sessão (início, fim, bytes transferidos) não estão sendo registrados corretamente em um sistema de billing, você está faturando com dados imprecisos. Isso é um problema operacional e, em muitas jurisdições, um problema regulatório.
A solução para esses três problemas tem um nome: PPPoE + RADIUS externo.
PPPoE + RADIUS: o esquema correto
FreeRADIUS vs Hotspot local
O Hotspot do RouterOS (que inclui o portal cativo e autenticação local) foi projetado para ambientes de acesso Wi-Fi com uma base de usuários moderada e sem necessidade de integração com sistemas externos. Para um ISP com assinantes em contratos, planos diferenciados e um sistema de billing, o Hotspot local não é a ferramenta correta.
O FreeRADIUS é o padrão da indústria para autenticação RADIUS em ISPs de qualquer porte. É software livre, tem módulos de integração com bancos de dados SQL (MySQL, PostgreSQL) e suporta todos os atributos que o RouterOS precisa para aplicar políticas por assinante. A maioria dos sistemas de billing ISP do mercado (ISPFY, Visp, Splynx, Powercode) tem integração nativa com FreeRADIUS.
A arquitetura recomendada para um ISP médio:
[Assinante PPPoE] --> [BNG/NAS RouterOS] --> [FreeRADIUS] --> [Base de dados billing]
|
--> [Accounting DB] --> [Dashboard / Faturamento]
Configuração do servidor PPPoE no RouterOS
A configuração do servidor PPPoE no RouterOS tem vários parâmetros que impactam diretamente na estabilidade e no desempenho:
# Criar o pool de IPs para assinantes
/ip pool
add name=pool-pppoe ranges=100.64.0.0/22
# Perfil PPPoE base (os rate-limits são aplicados pelo RADIUS, não aqui)
/ppp profile
add name=isp-suscriptores \
local-address=100.64.0.1 \
remote-address=pool-pppoe \
use-compression=no \
use-encryption=no \
use-mpls=no \
only-one=yes \
session-timeout=0 \
dns-server=8.8.8.8,1.1.1.1
# Servidor PPPoE na interface de acesso
/interface pppoe-server server
add service-name=isp-pppoe \
interface=ether2 \
default-profile=isp-suscriptores \
authentication=chap,mschap2 \
keepalive-timeout=30 \
max-sessions=5000 \
max-mru=1480 \
max-mtu=1480 \
mrru=1600 \
one-session-per-host=yes
O parâmetro one-session-per-host=yes é importante: evita que um cliente estabeleça múltiplas sessões PPPoE a partir do mesmo equipamento, o que pode gerar duplicação no billing.
Configuração do cliente RADIUS no RouterOS
/radius
add address=10.0.0.10 \
secret=clave-radius-segura \
service=ppp \
authentication-port=1812 \
accounting-port=1813 \
timeout=3000 \
authentication-protocol=pap,chap,mschap2
/radius incoming
set accept=yes port=3799
A porta 3799 habilita o RADIUS Change of Authorization (CoA), que permite que o servidor RADIUS envie comandos ao roteador para modificar sessões ativas sem desconectá-las. É isso que permite que quando um cliente faz upgrade de plano pelo portal web, a velocidade mude em segundos sem reiniciar a sessão.
Atributos RADIUS para QoS: rate-limit por perfil
O RouterOS suporta o atributo vendor-specific Mikrotik-Rate-Limit (vendor ID 14988, atributo 8) para aplicar limites de velocidade por sessão diretamente a partir do RADIUS:
# No FreeRADIUS (arquivo users ou base de dados SQL)
# Plano 50 Mbps / 25 Mbps (download/upload)
Mikrotik-Rate-Limit = "50M/25M"
# Com burst (para melhorar a experiência percebida do assinante)
Mikrotik-Rate-Limit = "50M/25M 100M/50M 75M/37M 30 50M/25M"
# Formato: CIR/CIR BurstLimit/BurstLimit BurstThreshold/BurstThreshold BurstTime GuaranteedRate/GuaranteedRate
O burst é um detalhe que melhora significativamente a experiência do assinante: permite velocidades acima do plano contratado durante rajadas curtas (tipicamente 30 a 60 segundos), fazendo com que a navegação web e os downloads pequenos sejam percebidos como mais ágeis mesmo quando o plano base é modesto.
Accounting para billing
# No RouterOS, o accounting é habilitado por padrão quando o RADIUS é configurado
# Verificar que os Accounting-Request estão sendo enviados:
/log
add topics=radius action=memory
# No FreeRADIUS (radiusd.conf), verificar que o módulo SQL está ativo
# para persistir os Accounting-Start, Accounting-Stop e Accounting-Interim-Update
Os Interim-Update são críticos para o billing em tempo real: se uma sessão cai abruptamente (sem Accounting-Stop), o sistema de billing sabe até quando contar o consumo. O intervalo recomendado é 300 segundos (5 minutos).
Queues e bandwidth management: Simple Queue vs Queue Tree
Por que a Simple Queue não escala
A Simple Queue no RouterOS é conveniente para configurações simples: um cliente, uma regra, uma velocidade. Mas internamente, o RouterOS processa as Simple Queues de forma sequencial. Com 5.000 regras ativas, esse processamento consome CPU de maneira significativa.
A regra prática: se você tem mais de 200-300 clientes ativos simultâneos em um roteador, migre o bandwidth management para Queue Tree com Mangle.
PCQ (Per Connection Queue) para fair sharing
O PCQ (Per-Connection Queue) é o mecanismo do RouterOS para distribuir equitativamente a largura de banda disponível entre múltiplos fluxos. É especialmente útil no uplink para evitar que um assinante que baixa na velocidade máxima sature o enlace e afete todos os demais:
/queue type
add name=pcq-bajada \
kind=pcq \
pcq-classifier=dst-address \
pcq-rate=0 \
pcq-limit=50 \
pcq-total-limit=2000
add name=pcq-subida \
kind=pcq \
pcq-classifier=src-address \
pcq-rate=0 \
pcq-limit=50 \
pcq-total-limit=2000
Mangle + Queue Tree para QoS por cliente
O esquema correto para QoS em escala no RouterOS combina Mangle (para marcar o tráfego) com Queue Tree (para aplicar as filas de forma eficiente):
# Mangle: marcar conexões PPPoE com o rate-limit atribuído pelo RADIUS
# O RouterOS aplica automaticamente os rate-limits do RADIUS às interfaces PPPoE
# Para controle adicional, marcar pacotes por interface PPPoE:
/ip firewall mangle
add chain=forward \
in-interface=<pppoe-interface> \
action=mark-packet \
new-packet-mark=trafico-suscriptor \
passthrough=no
# Queue Tree: fila pai sobre o uplink
/queue tree
add name=uplink-total \
parent=ether1 \
max-limit=1G \
queue=default
add name=bajada-suscriptores \
parent=uplink-total \
queue=pcq-bajada \
max-limit=950M
Com os rate-limits aplicados pelo RADIUS (atributo Mikrotik-Rate-Limit), o RouterOS cria automaticamente filas dinâmicas por sessão PPPoE sem necessidade de configuração manual adicional. Este é o equilíbrio correto entre controle granular e carga operacional.
Erros clássicos que vemos em campo
Rate limits aplicados ao roteador em vez de ao cliente
O erro mais frequente: configurar um rate-limit no perfil PPPoE do roteador (/ppp profile) em vez de aplicá-lo a partir do RADIUS por assinante. O efeito é que todos os assinantes compartilham o mesmo perfil de velocidade, ou que as mudanças de plano requerem modificar o perfil no roteador (operação manual, propensa a erros, sem rastreabilidade).
A velocidade deve vir sempre do servidor RADIUS. O perfil PPPoE no roteador é apenas um template base.
Microbursts sem shaping que saturam o uplink
Um ISP com 500 clientes de 50 Mbps não tem 25 Gbps de uplink. O modelo de negócio do ISP se baseia em oversubscription: a probabilidade de todos os clientes usarem sua velocidade máxima simultaneamente é baixa. Mas sem shaping adequado, quando um evento gera picos de tráfego simultâneos (um jogo de futebol, o lançamento de uma atualização de software massiva), os microbursts não controlados podem saturar o uplink em rajadas de milissegundos que o monitoramento médio não captura, mas que o assinante sente como latência alta e perda de pacotes.
A solução é implementar traffic shaping no uplink com Queue Tree e um máximo configurado em 90-95% da capacidade real do enlace (deixando margem para o tráfego de gestão e protocolos de rede).
Logs desativados por desempenho (erro crítico)
O ajuste mais contraproducente que vemos regularmente: um ISP desativa o logging do RouterOS (ou reduz apenas a erros críticos) porque “consome recursos”. O resultado é que quando há um incidente, não há informação para diagnosticá-lo. Pior ainda, não há registro das mudanças de configuração realizadas.
O RouterOS tem um sistema de logging flexível que permite enviar logs a um servidor remoto (syslog) sem impacto significativo no roteador:
/system logging action
add name=syslog-remoto \
target=remote \
remote=10.0.0.20 \
remote-port=514 \
src-address=0.0.0.0 \
bsd-syslog=yes
/system logging
add topics=ppp action=syslog-remoto
add topics=radius action=syslog-remoto
add topics=system action=syslog-remoto
add topics=firewall action=syslog-remoto
Os logs de PPP e RADIUS em particular são inestimáveis para diagnosticar problemas de autenticação e de sessão.
RouterOS 7 vs 6: o que mudou para ISPs
O RouterOS 7 trouxe melhorias relevantes para ISPs que vale a pena mencionar:
Melhor suporte para hardware multi-core. O RouterOS 7 melhorou o uso de múltiplos núcleos para o processamento de pacotes (fasttrack, firewall, queues). Em hardware CCR2004, CCR2116 e CCR2216, o impacto no throughput é significativo comparado com o RouterOS 6.
WireGuard nativo. Para ISPs que oferecem VPN a assinantes ou precisam de túneis de gestão seguros para CPEs, o WireGuard integrado no RouterOS 7 simplifica a arquitetura.
Melhorias no BGP. A stack BGP foi reescrita no RouterOS 7 com melhor desempenho e suporte para políticas mais granulares. Para ISPs com ASN próprio, o RouterOS 7 é uma melhoria real.
Aviso: O RouterOS 7 não é um upgrade trivial a partir do RouterOS 6. Alguns parâmetros de configuração mudaram de nome ou estrutura, e certas funcionalidades (especialmente em roteamento avançado) têm comportamentos diferentes. Testar em laboratório antes de migrar a produção é obrigatório.
Monitoramento: SNMP, The Dude e Zabbix
Um ISP sem monitoramento ativo não está operando sua rede: está reagindo a chamadas de clientes. As três ferramentas principais no ecossistema MikroTik:
SNMP: O RouterOS implementa SNMP v2c e v3. Habilitar SNMP com uma community string segura (não “public”) e um ACL restritivo é o ponto de partida para qualquer sistema de monitoramento:
/snmp community
add name=isp-monitoreo \
addresses=10.0.0.0/24 \
read-access=yes \
write-access=no
/snmp
set enabled=yes \
contact="[email protected]" \
location="NOC Principal" \
engine-id=autogenerate
The Dude: A ferramenta de monitoramento proprietária da MikroTik. Simples de implementar, com auto-discovery de rede, e muito usada em ISPs pequenos. Sua limitação é que não escala bem para redes grandes e os alertas são básicos comparados com ferramentas enterprise.
Zabbix: O padrão para monitoramento sério em ISPs médios. A MikroTik mantém templates oficiais de Zabbix para RouterOS que incluem métricas de CPU, memória, interfaces, sessões PPPoE ativas e estado dos túneis. Combinado com alertas via Telegram ou PagerDuty, o Zabbix permite um NOC proativo onde os engenheiros ficam sabendo dos problemas antes dos clientes.
CAPsMAN: menção para ISPs com wireless
Para ISPs que proveem serviços de última milha sem fio (Wi-Fi em edifícios, redes comunitárias, hotspots), o CAPsMAN (Controlled Access Point system Manager) permite centralizar a configuração e gestão de múltiplos Access Points MikroTik a partir de um controlador central.
O CAPsMAN não substitui um controlador Wi-Fi enterprise em implantações de alta densidade, mas para ISPs que precisam gerenciar dezenas ou centenas de APs com configuração uniforme, autenticação centralizada e visibilidade dos clientes conectados, é uma ferramenta com boa relação funcionalidade/custo.
O ponto de integração relevante: o CAPsMAN pode delegar a autenticação de clientes wireless ao mesmo servidor RADIUS que gerencia o PPPoE, unificando a gestão de assinantes em uma única plataforma.
Nossa experiência em campo
Os ISPs que melhor operam o RouterOS em escala não são os que têm a configuração mais complexa. São os que separaram claramente as responsabilidades: o RouterOS gerencia o plano de dados (encaminhamento de pacotes, aplicação de políticas de QoS) e sistemas externos gerenciam o plano de controle (autenticação, autorização, billing, monitoramento).
FreeRADIUS com uma base de dados SQL bem mantida, logs centralizados em um servidor syslog, e Zabbix para alertas ativos: essa combinação permite que uma equipe pequena opere milhares de assinantes com visibilidade completa e sem depender de intervenção manual para cada mudança de plano ou suspensão de serviço.
O assinante não sabe nada de RADIUS nem de Queue Tree. O que ele sabe é se o serviço funciona, se a velocidade corresponde ao plano que contratou, e se quando liga para o suporte técnico alguém consegue diagnosticar o problema em minutos ao invés de horas. Isso é o que uma configuração correta torna possível.
Quer revisar a configuração da sua rede MikroTik?
Na Ayuda.LA trabalhamos com ISPs da América Latina para auditar e otimizar infraestruturas MikroTik RouterOS: desde a arquitetura PPPoE/RADIUS até o bandwidth management e a integração com sistemas de billing.
Se já sabe o que precisa e quer falar com um engenheiro diretamente:
Tem perguntas sobre a sua configuração MikroTik específica? Escreva para [email protected]