El MikroTik Cloud Core Router (CCR) es uno de los equipos más utilizados por operadores de Internet (ISP y WISP) gracias a su enorme capacidad de procesamiento, su excelente rendimiento y la flexibilidad que ofrece RouterOS. Sin embargo, antes de comenzar a configurar servicios como PPPoE, BGP, OSPF, VLAN o QoS, es imprescindible realizar una configuración inicial correcta.

Esta primera configuración será la base sobre la que se apoyará toda la infraestructura del operador. Una mala configuración inicial puede derivar en problemas de seguridad, dificultades de administración, pérdida de rendimiento o incluso interrupciones del servicio.

En este artículo aprenderás cómo realizar la configuración inicial de un MikroTik CCR para un operador de Internet, explicando cada apartado, su importancia y las mejores prácticas recomendadas.

¿Por qué es tan importante la configuración inicial?

Cuando un CCR sale de fábrica únicamente dispone de una configuración básica o incluso completamente vacía, dependiendo del modelo y del tipo de instalación.

Antes de poner el equipo en producción es recomendable:

Actualizar el sistema operativo.
Actualizar el firmware interno.
Configurar correctamente la fecha y la hora.
Crear usuarios seguros.
Endurecer el acceso remoto.
Configurar DNS y sincronización horaria.
Deshabilitar servicios innecesarios.

Todo ello reduce considerablemente la superficie de ataque y facilita el mantenimiento futuro.

Nos conectamos a una red para realizar la configuraciones básicas.

Actualizar RouterOS

El primer paso siempre debe ser instalar la versión más reciente y estable de RouterOS.

Las nuevas versiones incluyen:

Corrección de vulnerabilidades.
Mejoras de rendimiento.
Compatibilidad con nuevos módulos SFP.
Optimización del enrutamiento.
Mejoras en BGP, OSPF, WireGuard y otras funciones.
Corrección de errores.

Comprobar la versión instalada, comprobar actualizaciones e instalarlas:

Una vez finalizada, el router se reiniciará automáticamente.

Recomendación: en un operador es aconsejable utilizar siempre la rama Stable, evitando versiones Testing salvo en entornos de laboratorio.

Actualizar RouterBOOT

Muchos administradores actualizan RouterOS pero olvidan actualizar el firmware interno del equipo.

RouterBOOT controla:

Inicialización del hardware.
Arranque del sistema.
Detección de memoria.
Detección de interfaces.
Compatibilidad con nuevos módulos.

Comprobar la versión, actualizar y reiniciar el equipo:

Después del reinicio conviene verificar nuevamente que ambas versiones coinciden.

Resetear el equipo

Reseteamos el equipo para que no tenga ninguna configuración.

Configurar correctamente la MTU

Uno de los parámetros más importantes de cualquier interfaz es la MTU.

La MTU determina el tamaño máximo de los paquetes que podrán circular sin fragmentación.

Una configuración incorrecta puede provocar:

Pérdida de rendimiento.
Fragmentación.
Problemas con VPN.
Problemas con PPPoE.
Baja velocidad.
Cortes intermitentes.

Desde las propiedades de cada interfaz podemos modificar este valor cuando el diseño de la red lo requiera.

En operadores FTTH resulta habitual utilizar valores específicos dependiendo de si el tráfico transporta VLAN, QinQ, MPLS o PPPoE.

En este caso podemos cambiarla de todas las interfaces con el siguientes script, para nuestro caso será 1596 para el L2 MTU.

:foreach i in=[/interface ethernet find] do={
    /interface ethernet set $i l2mtu=1596
}

La MTU afecta al tamaño máximo del paquete IP, La L2MTU hace referencia al tamaño máximo permitido a nivel de Ethernet.

Bridge

En cualquier red profesional de un ISP o WISP, el Bridge constituye uno de los elementos fundamentales de la infraestructura. Aunque pueda parecer una configuración sencilla, sobre él se apoyan posteriormente funciones tan importantes como VLAN, DHCP Snooping, IGMP Snooping, filtrado de tráfico, STP/RSTP, hardware offloading y muchas otras características de RouterOS 7.

En MikroTik, un Bridge funciona como un switch virtual de nivel 2, permitiendo unir varias interfaces Ethernet, SFP, VLAN o incluso interfaces inalámbricas para que formen un único dominio de broadcast.

En un operador de Internet, lo habitual es disponer de un único Bridge principal donde se conectan todas las interfaces LAN, dejando las interfaces WAN completamente fuera del mismo.

¿Qué es un Bridge?

Un Bridge permite que varias interfaces físicas trabajen como si pertenecieran al mismo switch.

Por ejemplo:

ether2
ether3
ether4
sfp-sfpplus1

Todas ellas pueden pertenecer al mismo Bridge denominado bridge-LAN.

Los equipos conectados a cualquiera de esos puertos podrán comunicarse directamente sin necesidad de realizar routing.

El Bridge aprende automáticamente las direcciones MAC conectadas en cada puerto y reenvía únicamente las tramas necesarias, exactamente igual que un switch Ethernet profesional.

¿Por qué utilizar un Bridge en un ISP?

En una red doméstica normalmente se utiliza un Bridge simplemente para unir los puertos LAN.

Sin embargo, en un operador de Internet el Bridge sirve además como base para:

Redes FTTH
Redes GPON
Redes WISP
Redes de distribución
VLAN de clientes
VLAN de gestión
Servidores DHCP
PPPoE
Hotspot
MPLS
QoS
IGMP para IPTV

Toda la infraestructura de capa 2 suele apoyarse sobre un único Bridge principal.

Creación del bridge

Crearemos nuestro bridge con un nombre identificativo.

Añadimos los puertos que queramos que formen parte de este bridge, haciéndolo de uno en uno.

Hardware Offloading activo (solo funciona en nuevos equipos CCR o CRS)

Esto permite que el tráfico entre puertos sea procesado por el switch interno en lugar de por la CPU, aumentando enormemente el rendimiento. Si la plataforma y la configuración lo permiten, RouterOS usa este mecanismo para conmutar tráfico a nivel de hardware.

Asignamos las IP que necesitemos al bridge.

Configurar la identidad del equipo

Cuando una red dispone de varios routers resulta imprescindible identificar claramente cada dispositivo.

Por ejemplo:

CCR-Core
CCR-BGP
CCR-Principal
CCR-ISP-Madrid
CCR-POP-Jaen

Configuración:

Una nomenclatura coherente facilita enormemente el trabajo en herramientas como:

The Dude
LibreNMS
Zabbix
Grafana
Graylog

Configurar fecha y zona horaria

Muchos problemas de diagnóstico provienen de tener una hora incorrecta.

Los registros del sistema dependen completamente de la hora del router.

Configurar la zona horaria:

Esto permitirá que:

Los logs sean correctos.
Los certificados tengan fechas válidas.
Funcionen correctamente los scripts programados.
Los informes de monitorización sean fiables.

Nunca debe configurarse la hora manualmente.

Lo recomendable es utilizar servidores NTP públicos o servidores internos del operador.

Algunas ventajas:

Sincronización automática.
Registros precisos.
Funcionamiento correcto de certificados.
Eventos correctamente fechados.

Configurar DNS

Aunque un operador normalmente utiliza resolvers propios o servidores externos, el propio CCR necesita resolver nombres.

Opcionalmente:

allow-remote-requests=no

En un router de cabecera normalmente no interesa que el propio CCR actúe como servidor DNS para los clientes.

Desactivar servicios

RouterOS activa varios servicios de administración.

Es recomendable mantener únicamente los necesarios y cambiar los puertos de acceso

Los que son dinamicos no podremos desactivarlos.

Mantener únicamente:

SSH
Winbox
API SSL (si realmente se utiliza)

Crear nuevos usuarios

Nunca debe utilizarse el usuario admin para la administración diaria, una vez creados los otros usuarios este se desactiva para evitar ataques.

Crear grupos personalizados

No todos los técnicos necesitan acceso completo.

Una buena práctica consiste en crear grupos según responsabilidades:

Operadores NOC
Soporte Nivel 1
Soporte Nivel 2
Ingeniería
Monitorización
Solo lectura

Esto permite aplicar el principio de mínimo privilegio, reduciendo el riesgo de cambios accidentales o no autorizados.

Permiso	NOC	Nivel 1	Nivel 2	Ingeniería	Monitorización	Solo lectura
local	✅	✅	✅	✅	❌	✅
ssh	✅	✅	✅	✅	❌	✅
web	✅	❌	❌	✅	❌	❌
read	✅	✅	✅	✅	✅	✅
write	✅	❌	✅	✅	❌	❌
reboot	✅	❌	✅	✅	❌	❌
test	✅	✅	✅	✅	❌	❌
sniff	❌	❌	❌	✅	❌	❌
sensitive	❌	❌	❌	✅	❌	❌
policy	❌	❌	❌	Opcional	❌	❌
password	❌	❌	❌	Opcional	❌	❌
api	❌	❌	❌	Opcional	✅	❌
rest-api	❌	❌	❌	Opcional	✅	❌
romon	Opcional	❌	Opcional	Opcional	❌	❌
ftp	❌	❌	❌	❌	❌	❌
telnet	❌	❌	❌	❌	❌	❌

En un operador de Internet (ISP/WISP), la división por niveles y departamentos permite que cada equipo tenga responsabilidades bien definidas. Un esquema habitual sería el siguiente:

Grupo	Función principal
Operadores NOC	Supervisar y operar la red 24×7.
Soporte Nivel 1	Atender incidencias básicas y realizar el primer diagnóstico.
Soporte Nivel 2	Resolver incidencias técnicas que requieren conocimientos avanzados.
Ingeniería	Diseñar, implantar y evolucionar la infraestructura de red.
Monitorización	Vigilar continuamente el estado de la red y generar alertas.
Solo lectura	Auditorías, formación, clientes o personal que únicamente necesita consultar información.

Además de estos grupos, es una buena práctica disponer de un grupo adicional, Administradores (Administración de Red) Este grupo sería el único con todos los permisos, incluidos:

policy
password
sensitive

Sería el equivalente al usuario full de MikroTik y debería estar reservado para un número muy reducido de administradores. El personal de Ingeniería puede trabajar con un grupo sin policy ni password y utilizar una cuenta de administrador únicamente cuando sea necesario realizar tareas de gestión de usuarios o cambios de seguridad críticos. Esto reduce significativamente el riesgo de modificaciones accidentales o de comprometer la seguridad de toda la infraestructura.

Configurar autenticación mediante claves SSH

Las contraseñas pueden ser objeto de ataques por fuerza bruta.

Siempre que sea posible es recomendable utilizar autenticación mediante claves públicas.

Ventajas:

Mayor seguridad.
Eliminación de ataques por diccionario.
Acceso automatizado mediante scripts.
Integración con sistemas de gestión.

Configuración email

Configuraremos el email para el envío de mensajes, ya sea de alarmas, copias de seguridad, etc. Una vez configurado nos mandaremos un email para confirmar que esta todo correcto.

Guardar una copia de seguridad inicial

Una vez terminada toda la configuración inicial es conveniente guardar dos tipos de copia:

Backup binario

Permite restaurar exactamente el mismo equipo.

/system backup save name=Configuracion-Inicial

Export en texto

Mucho más útil para documentar y migrar configuraciones.

/export file=Configuracion-Inicial

Lo recomendable es almacenar ambas copias en un servidor externo o sistema de copias de seguridad.

Por email, probado en la versión 7.23.2:

:local destinatario "email@empresa.com"

:local router [/system identity get name]
:local modelo [/system resource get board-name]
:local serie [/system routerboard get serial-number]
:local version [/system resource get version]
:local fecha [/system clock get date]
:local hora [/system clock get time]

:local horaArchivo ([:pick $hora 0 2] . "-" . [:pick $hora 3 5] . "-" . [:pick $hora 6 8])
:local nombre ($router . "_" . $fecha . "_" . $horaArchivo)

:local archivoBackup ($nombre . ".backup")
:local archivoExport ($nombre . ".rsc")

:log warning ("BACKUP: Inicio del proceso: " . $nombre)

:log info "BACKUP: Generando archivo .backup"
/system backup save name=$nombre

:log info "BACKUP: Generando archivo .rsc"
/export file=$nombre

:delay 10s

:if ([:len [/file find where name=$archivoBackup]] = 0) do={
    :log error ("BACKUP: No se encuentra " . $archivoBackup)
    :error "No se ha generado el archivo backup"
}

:if ([:len [/file find where name=$archivoExport]] = 0) do={
    :log error ("BACKUP: No se encuentra " . $archivoExport)
    :error "No se ha generado el archivo export"
}

:log info "BACKUP: Ambos archivos generados correctamente"

:log info ("BACKUP: Enviando correo a " . $destinatario)

/tool e-mail send \
to=$destinatario \
subject=("Backup MikroTik - " . $router) \
body=("Se adjuntan las copias de seguridad del router." . \
"\r\n\r\nNombre: " . $router . \
"\r\nModelo: " . $modelo . \
"\r\nNumero de serie: " . $serie . \
"\r\nVersion RouterOS: " . $version . \
"\r\nFecha: " . $fecha . \
"\r\nHora: " . $hora) \
file=($archivoBackup . "," . $archivoExport)

:log warning "BACKUP: Correo enviado correctamente"

:delay 10s

/file remove ($nombre.".backup")
/file remove ($nombre.".rsc")

Nos llegara algo similar a esto:

Podemos automatizarlo creando un Schedule y un Script:

DNS dinámico

Con el DNS dinámico podemos tener un dominio si necesidad de que nuestra IP publica sea fija, cada MikroTik cuenta con uno por equipo gratuito:

También con un Script podemos poner también de empresas como NO-IP.


:local noipUser "usuario@correo.com"
:local noipPass "TuContraseña"
:local hostname "mihost.ddns.net"

:local resultado [/tool fetch \
    url=("https://dynupdate.no-ip.com/nic/update?hostname=".$hostname) \
    user=$noipUser \
    password=$noipPass \
    as-value \
    output=user \
    keep-result=no \
    check-certificate=no]

:log info ("No-IP: " . ($resultado->"data"))

En el log verás algo parecido a:

No-IP: good 80.25.xxx.xxx

No-IP: nochg 80.25.xxx.xxx

Ambas respuestas significan que el servicio está funcionando correctamente.

Ping WatchDog

Para que el equipo se reinicie si pierde la conexión se reinicie el equipo, con este ejemplo se reinicia a los 10 min y después cada hora:

Servidor PPPoE

Si el MikroTik va a actuar como servidor PPPoE (Access Concentrator) para un ISP/WISP, la configuración debe realizarse siguiendo un orden lógico. Esto facilita posteriormente la integración con RADIUS, perfiles de velocidad, QoS o sistemas de facturación como FreeRADIUS, User Manager, Splynx, UISP o Powercode.

La configuración en RouterOS 7 se basa en cuatro elementos principales:

Pool de direcciones IP.
Perfiles PPP.
Usuarios (Secrets) o autenticación RADIUS.
Servidor PPPoE.

Requisitos previos

Antes de comenzar debes tener configurado:

Router con salida a Internet.
Bridge o interfaz donde estarán conectados los clientes.
Firewall básico.
NAT (si no utilizas direccionamiento público).

En este ejemplo:

Parámetro	Valor
Bridge clientes	bridge-clientes
Gateway PPPoE	172.16.100.1
Red clientes	172.16.100.0/24
Pool clientes	172.16.100.10-172.16.100.254
Servicio	ISP-PPPoE

Asignar IP Bridge

Asignamos una puerta de enlace al bridge con la que será el Gateway para los clientes PPPoE.

Crear el Pool de direcciones

Este pool será utilizado para asignar automáticamente una IP a cada abonado, si no se le asigna una de forma manual.

Crear los perfiles PPP

Los perfiles son uno de los elementos más importantes, en un ISP normalmente no existe un único perfil, se crean varios según la velocidad contratada.

Todos heredan la misma configuración básica cambiando únicamente el límite de velocidad. Los perfiles definen valores por defecto para los usuarios PPP y pueden establecer direcciones, colas, DNS, filtros y otros parámetros.

Configuramos el apartado general, en este caso es un perfil de 30 Mbps, pero podemos crear uno por defecto para radius y que este se encargue de la velocidad:

En los protocolos es según lo que necesitemos, en este caso como va a ser una red WiMax me interesa usar la encriptación para que los PTP con antenas lleven menos trafico. Y la encriptación no es necesario porque ya los propios clientes ya cifran con las diferentes plataformas su conexión, esto nos ahorra CPU.

En el limite estableceremos la velocidad y que solo se pueda conectar un cliente con cada usuario, esto nos evitara tener duplicados.

El apartado Queue de los perfiles PPP determina el tipo de cola que utilizará RouterOS cuando cree automáticamente una Simple Queue dinámica para cada cliente que se conecte al servidor PPPoE. Esta cola es la encargada de aplicar el límite de velocidad configurado mediante el parámetro Rate Limit, ya sea definido directamente en el perfil o recibido desde un servidor RADIUS.

Aunque RouterOS ofrece diferentes tipos de cola, no todos están pensados para el mismo escenario. Por ejemplo, wireless-default está diseñado para interfaces inalámbricas gestionadas directamente por RouterOS. Si la infraestructura WiFi está administrada por otro fabricante o el router únicamente actúa como servidor PPPoE y router de cabecera, este tipo de cola no aporta ninguna ventaja, ya que el router no participa en la gestión del medio radio.

Por este motivo se recomienda utilizar default-small/default-small como tipo de cola en los perfiles PPP. Se trata de una configuración muy equilibrada que ofrece un bajo consumo de CPU y memoria, una excelente estabilidad y una buena capacidad de escalado cuando existen un gran número de clientes conectados simultáneamente.

Otra de sus ventajas es que utiliza una cola de pequeño tamaño, lo que evita que los paquetes permanezcan almacenados durante demasiado tiempo cuando un cliente alcanza el límite de velocidad contratado. Esto ayuda a reducir la latencia y el fenómeno conocido como bufferbloat, mejorando la experiencia en aplicaciones sensibles al retardo como navegación web, juegos en línea, VoIP o videoconferencias.

No suele ser necesario utilizar algoritmos más complejos como PCQ dentro de los perfiles PPP, ya que cada cliente dispone de su propia Simple Queue dinámica creada automáticamente por RouterOS. Añadir una capa adicional de reparto de tráfico dentro de una cola que ya es individual incrementa el procesamiento del router sin aportar beneficios significativos en la mayoría de despliegues.

Asimismo, cuando se utiliza Rate Limit para controlar el ancho de banda de los clientes, no es recomendable habilitar FastTrack, ya que este mecanismo omite gran parte del procesamiento del firewall y de las colas, impidiendo que las limitaciones de velocidad se apliquen correctamente.

En definitiva, la combinación de Rate Limit junto con default-small/default-small constituye una de las configuraciones más recomendables para servidores PPPoE en MikroTik. Proporciona un funcionamiento estable, un consumo reducido de recursos, una baja latencia y una administración sencilla, siendo adecuada tanto para pequeñas instalaciones como para redes con un elevado número de abonados.

En versión 6 el recomendable es default-small.

Crearemos otro perfil para que sea el de por defecto para el PPPoE, para que en el caso de que no se asigne en Radius o en Secret, este sea el regule el usuario y tenga un perfil de velocidad.

Crear usuarios PPP

Crearemos los usuarios en el Secrts para que se conecten los clientes, posteriormente podemos conectar radius para que se conecten con nuestro programa ERP.

Crear el Servidor PPPoE

Crearemos el servidor PPPoE para que se conecten los usuarios.

Para el MTU y el MRU 1480 es una configuración segura; 1492 es una optimización pequeña y técnicamente correcta si las pruebas confirman que todo el camino lo admite.

Es recomendable deshabilitar PAP y MSCHAPv1 por motivos de seguridad cuando todos los clientes sean compatibles.

MAC WinBox, MAC Server y descubrimiento

Estas opciones son muy importantes en la seguridad de un MikroTik, especialmente en un ISP o WISP. Su función es limitar el acceso por capa 2 (Ethernet), es decir, impedir que alguien pueda administrar el router aunque no tenga una dirección IP válida.

El MAC Server permite acceder al router utilizando su dirección MAC en lugar de una dirección IP.

Es el protocolo que utiliza WinBox cuando aparece la pestaña Neighbors y haces doble clic sobre un equipo aunque no tenga IP configurada.

Si no se restringe, cualquier dispositivo conectado a cualquier interfaz del router podría intentar acceder mediante MAC. Podemos incluir una interfaz o una lista de interfaces que solo se tenga acceso desde ellas.

El MAC WixBox parecido al anterior, pero únicamente afecta al protocolo específico que utiliza WinBox.

WinBox puede conectarse de dos formas:

por IP
por MAC

Esta opción controla únicamente la segunda.

Sin ella, alguien conectado físicamente podría abrir WinBox y acceder mediante MAC aunque no exista conectividad IP.

Para ello crearemos una lista para el acceso al equipo y la añadiremos al las interfaces:

El Neighbor Discovery es una opción controla si el router anuncia su presencia mediante protocolos de descubrimiento.

Entre ellos:

LLDP (Link Layer Discovery Protocol)
MNDP (MikroTik Neighbor Discovery Protocol)
CDP (Cisco)

Cuando WinBox abre la pestaña Neighbors, todos esos equipos aparecen gracias a este servicio, podrán ver:

nombre del router
versión RouterOS
modelo
uptime
dirección MAC
plataforma
identidad

Eso proporciona mucha información útil para un posible atacante.

Por eso normalmente se limita a la red de gestión.

Graphing

La herramienta Graphing de MikroTik permite registrar y consultar gráficas históricas del funcionamiento del router. Puede monitorizar:

Uso de CPU, memoria RAM y almacenamiento.
Tráfico de las interfaces.
Tráfico gestionado por las Simple Queues.

Las gráficas pueden consultarse directamente desde WinBox o mediante un navegador web. Graphing está desactivado de forma predeterminada y debe habilitarse expresamente. Documentación oficial de MikroTik sobre Graphing.

Buenas prácticas adicionales

Además de los pasos anteriores, en un entorno profesional conviene seguir estas recomendaciones:

Utilizar únicamente versiones estables de RouterOS.
Documentar todos los cambios realizados.
Aplicar una política de nombres consistente.
Configurar un servidor Syslog remoto desde el primer día.
Restringir el acceso administrativo mediante firewall.
Permitir la administración únicamente desde una VLAN de gestión.
Evitar acceder al CCR directamente desde Internet.
Utilizar VPN para todas las tareas de administración remota.
Automatizar las copias de seguridad mediante Scheduler.
Revisar periódicamente las actualizaciones de seguridad publicadas por MikroTik.

Errores habituales durante la configuración inicial

Entre los fallos más frecuentes destacan:

Mantener el usuario admin activo.
No actualizar RouterBOOT.
No sincronizar la hora mediante NTP.
Dejar abiertos servicios como Telnet o FTP.
Utilizar contraseñas débiles.
Administrar el router directamente desde Internet.
No realizar una copia de seguridad inicial.
No documentar la configuración.

Evitar estos errores desde el primer momento simplifica enormemente la gestión futura de la infraestructura.

Conclusión

La configuración inicial de un MikroTik CCR para un operador de Internet es mucho más que un simple ajuste previo. Constituye la base sobre la que se construirá toda la red del operador, desde los servicios de autenticación PPPoE hasta el enrutamiento BGP, la monitorización, la alta disponibilidad y la seguridad.

Invertir tiempo en una configuración inicial bien planificada proporciona importantes ventajas: mejora la estabilidad de la red, reduce riesgos de seguridad, facilita las tareas de mantenimiento y simplifica el crecimiento de la infraestructura a medida que aumenta el número de clientes.

En próximos artículos abordaremos el siguiente paso de esta serie: la configuración de interfaces, bridges, bonding y VLAN en un MikroTik CCR para operadores de Internet, donde comenzaremos a construir la arquitectura física y lógica sobre la que funcionará toda la red.