MikroTik RouterOS para ISPs: configuración correcta de gestión de suscriptores con RADIUS y PPPoE
MikroTik RouterOS es, sin exageración, la columna vertebral de los ISPs pequeños y medianos de Latinoamérica. En cualquier ciudad mediana de Argentina, Chile, Colombia o Perú, hay al menos tres ISPs que arrancaron con un RB450G en el cuarto de servidores y hoy tienen cientos o miles de clientes conectados a través de esa misma plataforma (ahora con hardware más moderno, pero la lógica operativa es la misma).
El problema no es MikroTik. El problema es que las configuraciones que se aprenden en los primeros años de operación, que funcionan perfectamente a escala pequeña, no escalan bien. Y cuando fallan, lo hacen de formas que no siempre son obvias: rendimiento degradado que parece problema del cliente, facturación incorrecta porque el accounting no está bien configurado, o un core router que procesa colas por software y degrada la experiencia de todos los suscriptores cuando hay congestión.
Este artículo está escrito para ingenieros de ISPs medianos que ya saben usar RouterOS y quieren entender dónde están los límites y cómo superarlos correctamente.
Por qué MikroTik domina los ISPs de Latam
La respuesta corta es: precio, funcionalidad y comunidad.
Un CHR (Cloud Hosted Router) o un CCR (Cloud Core Router) ofrecen funcionalidades que en hardware de otros vendors costarían cinco a diez veces más. PPPoE server, RADIUS client, firewall stateful, routing dinámico (OSPF, BGP, IS-IS), MPLS, bonding, túneles GRE/IPIP/L2TP: todo viene incluido en la licencia de RouterOS, sin módulos adicionales.
La comunidad también es un factor real. El foro de MikroTik tiene décadas de configuraciones documentadas. Hay grupos de WhatsApp y Telegram de ingenieros de ISPs en casi todos los países de la región donde se comparten configuraciones, se diagnostican problemas y se anuncian vulnerabilidades antes de que lleguen los CVEs oficiales. Ese ecosistema informal tiene un valor operativo enorme para equipos pequeños sin acceso a soporte de vendor de primer nivel.
La consecuencia de esa accesibilidad, sin embargo, es que muchos ISPs operan con configuraciones que fueron copiadas de un tutorial de 2015 y nunca revisadas. Funcionan. Hasta que no funcionan.
El problema: lo que escala con 100 clientes se rompe con 5.000
Cuando un ISP tiene 100 suscriptores PPPoE, casi cualquier configuración funciona. El router tiene capacidad de sobra, los tiempos de autenticación son tolerables incluso con el servidor RADIUS local (Hotspot Manager o User Manager), y las colas se procesan en microsegundos.
A los 5.000 suscriptores, esas mismas configuraciones generan problemas sistémicos:
Autenticación local no escala. El User Manager de RouterOS no está diseñado para manejar la base de datos de un ISP mediano, ni para integrarse con un sistema de billing externo de manera confiable. A medida que crece la base de clientes, los tiempos de autenticación aumentan, las modificaciones de perfil (upgrades de plan, suspensiones) requieren intervención manual en el router, y el proceso de auditoría de conexiones activas se vuelve manual e impreciso.
Simple Queue en un router de núcleo mata el rendimiento. Cada Simple Queue en RouterOS consume ciclos de CPU en el proceso de encolamiento. Con 5.000 suscriptores activos, ese proceso puede saturar un núcleo completo del procesador, degradando el rendimiento general del router aunque el enlace de uplink tenga capacidad disponible.
Sin accounting, el billing es una estimación. Si los datos de sesión (inicio, fin, bytes transferidos) no se están registrando correctamente en un sistema de billing, estás facturando con datos imprecisos. Eso es un problema operativo y, en muchas jurisdicciones, un problema regulatorio.
La solución a estos tres problemas tiene un nombre: PPPoE + RADIUS externo.
PPPoE + RADIUS: el esquema correcto
FreeRADIUS vs Hotspot local
El Hotspot de RouterOS (que incluye el portal cautivo y autenticación local) está diseñado para entornos de acceso Wi-Fi con una base de usuarios moderada y sin necesidad de integración con sistemas externos. Para un ISP con suscriptores en contratos, planes diferenciados, y un sistema de billing, el Hotspot local no es la herramienta correcta.
FreeRADIUS es el estándar de la industria para autenticación RADIUS en ISPs de cualquier tamaño. Es software libre, tiene módulos de integración con bases de datos SQL (MySQL, PostgreSQL), y soporta todos los atributos que RouterOS necesita para aplicar políticas por suscriptor. La mayoría de los sistemas de billing ISP del mercado (ISPFY, Visp, Splynx, Powercode) tienen integración nativa con FreeRADIUS.
La arquitectura recomendada para un ISP mediano:
[Suscriptor PPPoE] --> [BNG/NAS RouterOS] --> [FreeRADIUS] --> [Base de datos billing]
|
--> [Accounting DB] --> [Dashboard / Facturación]
Configuración del PPPoE server en RouterOS
La configuración del servidor PPPoE en RouterOS tiene varios parámetros que impactan directamente en la estabilidad y el rendimiento:
# Crear el pool de IPs para suscriptores
/ip pool
add name=pool-pppoe ranges=100.64.0.0/22
# Perfil PPPoE base (los rate-limits se aplican desde RADIUS, no aquí)
/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 en la interfaz de acceso
/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
El parámetro one-session-per-host=yes es importante: evita que un cliente establezca múltiples sesiones PPPoE desde el mismo equipo, lo que puede generar duplicación en el billing.
Configuración del cliente RADIUS en 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
El puerto 3799 habilita RADIUS Change of Authorization (CoA), que permite que el servidor RADIUS envíe comandos al router para modificar sesiones activas sin desconectarlas. Esto es lo que permite que cuando un cliente hace un upgrade de plan desde el portal web, la velocidad cambie en segundos sin reiniciar la sesión.
RADIUS attributes para QoS: rate-limit por perfil
RouterOS soporta el atributo vendor-specific Mikrotik-Rate-Limit (vendor ID 14988, atributo 8) para aplicar límites de velocidad por sesión directamente desde RADIUS:
# En FreeRADIUS (archivo users o base de datos SQL)
# Plan 50 Mbps / 25 Mbps (bajada/subida)
Mikrotik-Rate-Limit = "50M/25M"
# Con burst (para mejorar la experiencia percibida del suscriptor)
Mikrotik-Rate-Limit = "50M/25M 100M/50M 75M/37M 30 50M/25M"
# Formato: CIR/CIR BurstLimit/BurstLimit BurstThreshold/BurstThreshold BurstTime GuaranteedRate/GuaranteedRate
El burst es un detalle que mejora significativamente la experiencia del suscriptor: permite velocidades superiores al plan contratado durante ráfagas cortas (típicamente 30 a 60 segundos), lo que hace que la navegación web y las descargas pequeñas se sientan más ágiles aunque el plan base sea modesto.
Accounting para billing
# En RouterOS, el accounting está habilitado por defecto cuando se configura RADIUS
# Verificar que los Accounting-Request se estén enviando:
/log
add topics=radius action=memory
# En FreeRADIUS (radiusd.conf), verificar que el módulo SQL esté activo
# para persistir los Accounting-Start, Accounting-Stop y Accounting-Interim-Update
Los Interim-Update son críticos para el billing en tiempo real: si una sesión cae abruptamente (sin Accounting-Stop), el sistema de billing sabe hasta cuándo contar el consumo. El intervalo recomendado es 300 segundos (5 minutos).
Queues y bandwidth management: Simple Queue vs Queue Tree
Por qué Simple Queue no escala
Simple Queue en RouterOS es conveniente para configuraciones simples: un cliente, una regla, una velocidad. Pero internamente, RouterOS procesa las Simple Queues de manera secuencial. Con 5.000 reglas activas, ese procesamiento consume CPU de manera significativa.
La regla práctica: si tenés más de 200-300 clientes activos simultáneos en un router, migrá el bandwidth management a Queue Tree con Mangle.
PCQ (Per Connection Queue) para fair sharing
PCQ (Per-Connection Queue) es el mecanismo de RouterOS para distribuir equitativamente el ancho de banda disponible entre múltiples flujos. Es especialmente útil en el uplink para evitar que un suscriptor que descarga a máxima velocidad sature el enlace y afecte a todos los demás:
/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
El esquema correcto para QoS a escala en RouterOS combina Mangle (para marcar el tráfico) con Queue Tree (para aplicar las colas de manera eficiente):
# Mangle: marcar conexiones PPPoE con el rate-limit asignado desde RADIUS
# RouterOS aplica automáticamente los rate-limits de RADIUS a las interfaces PPPoE
# Para control adicional, marcar paquetes por interfaz PPPoE:
/ip firewall mangle
add chain=forward \
in-interface=<pppoe-interface> \
action=mark-packet \
new-packet-mark=trafico-suscriptor \
passthrough=no
# Queue Tree: cola padre sobre el 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
Con los rate-limits aplicados desde RADIUS (atributo Mikrotik-Rate-Limit), RouterOS crea automáticamente colas dinámicas por sesión PPPoE sin necesidad de configuración manual adicional. Esto es el balance correcto entre control granular y carga operativa.
Errores clásicos que vemos en campo
Rate limits aplicados al router en vez de al cliente
El error más frecuente: configurar un rate-limit en el perfil PPPoE del router (/ppp profile) en lugar de aplicarlo desde RADIUS por suscriptor. El efecto es que todos los suscriptores comparten el mismo perfil de velocidad, o que los cambios de plan requieren modificar el perfil en el router (operación manual, propensa a errores, sin trazabilidad).
La velocidad debe venir siempre del servidor RADIUS. El perfil PPPoE en el router es solo una plantilla base.
Microbursts sin shape que saturan el uplink
Un ISP con 500 clientes de 50 Mbps no tiene 25 Gbps de uplink. El modelo de negocio del ISP se basa en oversubscription: la probabilidad de que todos los clientes usen su velocidad máxima simultáneamente es baja. Pero sin shaping adecuado, cuando hay un evento que genera picos de tráfico simultáneos (un partido de fútbol, el lanzamiento de una actualización de software masiva), los microbursts no controlados pueden saturar el uplink en ráfagas de milisegundos que el monitoreo promedio no captura, pero que el suscriptor siente como latencia alta y pérdida de paquetes.
La solución es implementar traffic shaping en el uplink con Queue Tree y un máximo configurado al 90-95% de la capacidad real del enlace (dejando margen para el tráfico de gestión y protocolos de red).
Logs desactivados por rendimiento (error crítico)
El ajuste más contraproducente que vemos regularmente: un ISP desactiva el logging de RouterOS (o lo reduce a errores críticos solamente) porque “consume recursos”. El resultado es que cuando hay un incidente, no hay información para diagnosticarlo. Peor aún, no hay registro de los cambios de configuración realizados.
RouterOS tiene un sistema de logging flexible que permite enviar logs a un servidor remoto (syslog) sin impacto significativo en el router:
/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
Los logs de PPP y RADIUS en particular son invaluables para diagnosticar problemas de autenticación y de sesión.
RouterOS 7 vs 6: qué cambió para ISPs
RouterOS 7 trajo mejoras relevantes para ISPs que vale la pena mencionar:
Mejor soporte para hardware multi-core. RouterOS 7 mejoró el uso de múltiples núcleos para el procesamiento de paquetes (fasttrack, firewall, queues). En hardware CCR2004, CCR2116 y CCR2216, el impacto en throughput es significativo comparado con RouterOS 6.
WireGuard nativo. Para ISPs que ofrecen VPN a suscriptores o necesitan túneles de gestión seguros hacia CPEs, WireGuard integrado en RouterOS 7 simplifica la arquitectura.
Mejoras en BGP. El stack BGP fue reescrito en RouterOS 7 con mejor performance y soporte para políticas más granulares. Para ISPs con ASN propio, RouterOS 7 es una mejora real.
Advertencia: RouterOS 7 no es un upgrade trivial desde RouterOS 6. Algunos parámetros de configuración cambiaron de nombre o estructura, y ciertas funcionalidades (especialmente en routing avanzado) tienen comportamientos diferentes. Testear en lab antes de migrar producción es obligatorio.
Monitoring: SNMP, The Dude y Zabbix
Un ISP sin monitoreo activo no está operando su red, está reaccionando a llamados de clientes. Las tres herramientas principales en el ecosistema MikroTik:
SNMP: RouterOS implementa SNMP v2c y v3. Habilitar SNMP con una community string segura (no “public”) y un ACL restrictivo es el punto de partida para cualquier sistema de monitoreo:
/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: La herramienta de monitoreo propietaria de MikroTik. Simple de implementar, con auto-discovery de red, y muy usada en ISPs pequeños. Su limitación es que no escala bien a redes grandes y las alertas son básicas comparadas con herramientas enterprise.
Zabbix: El estándar para monitoreo serio en ISPs medianos. MikroTik mantiene templates oficiales de Zabbix para RouterOS que incluyen métricas de CPU, memoria, interfaces, sesiones PPPoE activas, y estado de los túneles. Combinado con alertas vía Telegram o PagerDuty, Zabbix permite un NOC proactivo donde los ingenieros se enteran de los problemas antes que los clientes.
CAPsMAN: mención para ISPs con wireless
Para ISPs que proveen servicios de última milla inalámbrica (Wi-Fi en edificios, redes comunitarias, hotspots), CAPsMAN (Controlled Access Point system Manager) permite centralizar la configuración y gestión de múltiples Access Points MikroTik desde un controlador central.
CAPsMAN no reemplaza a un controlador Wi-Fi enterprise en despliegues de alta densidad, pero para ISPs que necesitan gestionar decenas o cientos de APs con configuración uniforme, autenticación centralizada y visibilidad de clientes conectados, es una herramienta con buena relación funcionalidad/costo.
El punto de integración relevante: CAPsMAN puede delegar la autenticación de clientes inalámbricos al mismo servidor RADIUS que maneja PPPoE, unificando la gestión de suscriptores en una sola plataforma.
Nuestra experiencia en campo
Los ISPs que mejor operan RouterOS a escala no son los que tienen la configuración más compleja. Son los que separaron claramente las responsabilidades: RouterOS maneja el plano de datos (reenvío de paquetes, aplicación de políticas de QoS) y sistemas externos manejan el plano de control (autenticación, autorización, billing, monitoreo).
FreeRADIUS con una base de datos SQL bien mantenida, logs centralizados en un servidor syslog, y Zabbix para alertas activas: esa combinación permite que un equipo pequeño opere miles de suscriptores con visibilidad completa y sin depender de intervención manual para cada cambio de plan o suspensión de servicio.
El suscriptor no sabe nada de RADIUS ni de Queue Tree. Lo que sabe es si su servicio funciona, si su velocidad corresponde al plan que contrató, y si cuando llama al soporte técnico alguien puede diagnosticar su problema en minutos en lugar de horas. Eso es lo que una configuración correcta hace posible.
¿Querés revisar la configuración de tu red MikroTik?
En Ayuda.LA trabajamos con ISPs de Latinoamérica para auditar y optimizar infraestructuras MikroTik RouterOS: desde la arquitectura PPPoE/RADIUS hasta el bandwidth management y la integración con sistemas de billing.
Si ya sabés lo que necesitás y querés hablar con un ingeniero directamente:
¿Tenés preguntas sobre tu configuración MikroTik específica? Escribinos a [email protected]