RADIUS MikroTik: gestión centralizada de abonados PPPoE

Cuando una red PPPoE pasa de decenas a miles de abonados, mantener las credenciales en el secret local de cada BNG deja de escalar: cada alta, baja o cambio de plan obliga a tocar el router, no hay una fuente única de verdad y auditar quién está conectado se vuelve un dolor. La respuesta que usan los ISP serios es centralizar la autenticación, autorización y contabilidad (AAA) en un servidor externo, y ahí RADIUS MikroTik es la pieza que conecta tu concentrador RouterOS con esa base de datos central. En este artículo revisamos, con comandos reales de RouterOS, cómo integrar RADIUS con PPPoE para gestionar abonados de forma ordenada, con perfiles dinámicos, accounting y cortes de sesión remotos.

Por qué RADIUS MikroTik cambia la gestión de abonados

Sin RADIUS, cada usuario PPPoE vive como un secret en /ppp secret dentro del router. Funciona para un laboratorio, pero en producción significa que el plan, la IP fija, el rate-limit y el estado del abonado están dispersos en el equipamiento, no en tu sistema de gestión. Con RADIUS el flujo se invierte: cuando un abonado levanta su sesión PPPoE, el BNG reenvía las credenciales al servidor RADIUS, que responde con un Access-Accept más los atributos que definen el servicio (velocidad, dirección, pool, filtros). El router deja de ser el dueño de los datos y pasa a ser el ejecutor de una política que vive en tu backend.

Esto habilita lo que un operador realmente necesita: dar de alta a un cliente desde tu plataforma de facturación, cambiar su plan sin entrar al router, suspenderlo por no pago en segundos y saber en todo momento cuánto tráfico consumió cada sesión. RouterOS puede consultar RADIUS para los servicios ppp, hotspot, login, dhcp, wireless, ipsec y dot1x; para gestión de abonados de banda ancha, el que nos interesa es ppp.

Anatomía de la integración: /radius y /ppp aaa

La configuración base tiene dos partes. Primero registras el servidor RADIUS y le declaras que atenderá el servicio ppp; luego le dices al subsistema PPP que use RADIUS como fuente de autenticación. Con dos bloques queda operativo:

/radius
add service=ppp address=10.0.0.10 secret=UnSecretoLargoYAleatorio \
    authentication-port=1812 accounting-port=1813 \
    called-id=isp-pppoe timeout=300ms src-address=10.0.0.1

/ppp aaa
set use-radius=yes accounting=yes interim-update=5m

Algunos detalles que marcan diferencia en operación:

• use-radius=yes: si el abonado no existe en el secret local, RouterOS lo autentica contra RADIUS. Esto te permite dejar una cuenta local de emergencia y delegar el resto.
• timeout (por defecto 1100 ms): en un BNG con miles de sesiones conviene ajustarlo. Un timeout alto retrasa la detección de un servidor caído; uno muy bajo genera reenvíos innecesarios sobre una red congestionada.
• called-id: para PPPoE corresponde al service name, útil para diferenciar servidores o realms en el lado RADIUS.
• src-address: fija la IP origen de los paquetes RADIUS, importante cuando el servidor filtra por cliente o cuando el BNG tiene varias interfaces.

Puedes agregar más de una entrada /radius para el mismo servicio: RouterOS las consulta en orden, lo que te da un mecanismo simple de redundancia si el primario no responde dentro del timeout.

Perfiles PPP y rate-limit: autorización desde RADIUS

Autenticar es solo la mitad. La autorización —qué recibe el abonado— se resuelve combinando el /ppp profile local con atributos que llegan desde RADIUS en el Access-Accept. El perfil define el marco común (direccionamiento, DNS, filtros), y RADIUS sobrescribe lo específico de cada cliente:

/ppp profile
add name=plan-base local-address=100.64.0.1 remote-address=pool-clientes \
    dns-server=1.1.1.1,8.8.8.8 only-one=yes \
    incoming-filter=abonados outgoing-filter=abonados

La velocidad de cada plan no se codifica en el router: se envía como el atributo vendor-specific Mikrotik-Rate-Limit desde RADIUS, y RouterOS crea una queue dinámica por sesión. Ojo con la convención: desde el punto de vista del router, rx es la subida del cliente y tx su bajada. Así, cambiar a un abonado de 100 a 300 Mbps es un cambio en tu backend, no en el BNG.

Un par de advertencias reales de RouterOS que conviene tener presentes: el parámetro only-one del perfil se ignora cuando se usa autenticación RADIUS (el control de sesión única debe hacerlo el servidor), y el atributo Framed-MTU no se aplica porque llega después de la negociación LCP. Para las cadenas de firewall incoming-filter/outgoing-filter necesitas haber creado antes la cadena ppp con reglas action=jump jump-target=ppp; de lo contrario los filtros no tienen efecto.

Accounting: saber quién consume qué

El accounting de RADIUS es lo que transforma la red en algo medible. Con accounting=yes el BNG envía un Accounting-Start al conectar la sesión, mensajes Interim-Update periódicos (definidos por interim-update) y un Accounting-Stop al cerrar, con los contadores de bytes y tiempo de la sesión. Esto alimenta reportes de consumo, control de cuotas y trazabilidad para requerimientos legales.

Si necesitas separar el consumo IPv4 del IPv6 —cada vez más habitual con despliegue de IPv6 en el last mile— RouterOS lo soporta con enable-ipv6-accounting=yes en /ppp aaa. Por defecto PPP suma capa 2, IPv4 e IPv6 en un solo contador; activando esta opción se reportan estadísticas IPv6 separadas, siempre que el prefijo se asigne por PPP y exista rate-limit.

Mensaje	Cuándo se envía	Para qué sirve
Accounting-Start	Al establecer la sesión PPPoE	Registrar inicio, IP asignada, NAS-Port
Interim-Update	Cada interim-update (ej. 5m)	Contadores parciales, control de cuota en vivo
Accounting-Stop	Al caer o cerrar la sesión	Consumo total y duración final

Cortar sesiones desde RADIUS: Disconnect-Messages

Suspender a un abonado moroso o forzar la reconexión tras un cambio de plan no debería requerir entrar al router. RADIUS resuelve esto con mensajes no solicitados desde el servidor hacia el BNG. En RouterOS se habilita el submenú /radius incoming:

/radius incoming
set accept=yes port=1700

Con esto el router escucha Disconnect-Messages (DM), que terminan de inmediato la sesión indicada. Un detalle importante y muy concreto de RouterOS: soporta Disconnect-Messages pero no PoD (Packet of Disconnect), así que tu servidor RADIUS debe estar configurado para emitir DM. El puerto por defecto de escucha es 1700 y puedes fijar el vrf si el plano de gestión está segmentado. Este mecanismo es la base de un ciclo de suspensión y reactivación automatizado desde tu plataforma de facturación, algo que encaja naturalmente con proyectos de automatización de RouterOS vía API y scripting.

Seguridad, alta disponibilidad y puesta en producción

El tráfico RADIUS clásico viaja sobre UDP y protege los atributos con el shared secret y MD5, lo que es aceptable dentro de una red de gestión controlada, pero débil si cruza enlaces públicos. Para esos casos RouterOS soporta RadSec, que encapsula RADIUS sobre TLS:

/radius
add service=ppp address=10.0.0.10 protocol=radsec \
    certificate=cliente.crt secret=radsec

Con RadSec activo RouterOS fuerza el secret al valor literal radsec y usa el puerto TCP 2083, por lo que tu servidor debe usar exactamente ese secret para descifrar correctamente. Además, desde versiones recientes RouterOS exige el atributo Message-Authenticator (require-message-auth=yes-for-request-resp por defecto), un endurecimiento frente a ataques conocidos sobre RADIUS que conviene mantener.

Para la disponibilidad, más allá de declarar varios servidores, la práctica sana es: un timeout ajustado a tu RTT real, monitoreo activo del servicio RADIUS y una cuenta local de contingencia en el BNG para no perder acceso de administración si el AAA cae. Si además operas el servidor sobre el paquete User Manager de MikroTik, mantienes todo el stack dentro del ecosistema RouterOS, con la ventaja de una sola plataforma para diseñar y auditar.

Levantar /radius y /ppp aaa es la parte mecánica. El diseño que sostiene miles de abonados es lo que agrega valor: dimensionar el BNG, definir el esquema de pools y direccionamiento (muchas veces con CGNAT), estructurar los planes como atributos RADIUS, ordenar el accounting para facturación y cerrar el ciclo de suspensión automática sin intervención manual. Cada una de esas decisiones impacta la estabilidad en hora peak y la capacidad de crecer sin rehacer la red.

En MikroTik Chile diseñamos e implementamos gestión de abonados PPPoE con RADIUS para ISP y empresas, integrada a facturación, accounting y automatización, sobre infraestructura RouterOS documentada y lista para operar. Si estás evaluando migrar de secrets locales a un AAA centralizado, o tu esquema actual ya no escala, conversemos: revisa nuestra consultoría de ingeniería de redes y cuéntanos tu caso.