1. Contexto del problema
En entornos con IPv6 habilitado, los routers MikroTik ejecutan el Router Advertisement Daemon (radvd) para enviar y recibir anuncios de red (RA, Router Advertisements) en las interfaces configuradas. Estos mensajes permiten a los equipos descubrir automáticamente parámetros de red IPv6, como prefijos, puertas de enlace y MTU.
Cuando otro dispositivo de la red (por ejemplo, un servidor Linux o contenedor Docker con IPv6 activo) emite RA con valores no estándar, el MikroTik los registra como advertencias. Un ejemplo típico es:
radvd,warning invalid mtu 4478 on ether1 from fe80::200:5eff:fe00:201
Interpretación técnica
- radvd, warning → el proceso
radvd
detectó un anuncio no conforme. - invalid mtu 4478 → el campo MTU anunciado excede el máximo permitido para Ethernet (1500 bytes).
- from fe80::200:5eff:fe00:201 → dirección IPv6 de enlace local del emisor.
Este mensaje no indica una falla funcional, pero genera ruido en el log, especialmente si se repite con frecuencia.
2. Causa del problema
2.1. Desde el punto de vista teórico
El protocolo ICMPv6 Router Advertisement (RA) define que los routers pueden anunciar parámetros de la red, entre ellos el MTU recomendado. Los clientes deberían adoptar dicho valor, pero algunos dispositivos o stacks IPv6 (como contenedores o bridges virtuales) publican MTU no válidos.
MikroTik valida esos parámetros según el estándar RFC 4861 y reporta cualquier inconsistencia, de ahí el log de warning.
2.2. Desde el punto de vista práctico
El mensaje se produce porque otro host —por ejemplo, una máquina Ubuntu con Docker y IPv6 habilitado— está emitiendo RA con un MTU mayor al permitido. MikroTik lo detecta y lo informa, aunque el paquete se descarta.
El problema no afecta el funcionamiento normal de IPv6 ni del router, pero puede saturar el registro de eventos.
3. Solución: filtrar los mensajes radvd
3.1. Enfoque teórico
El subsistema de logging de RouterOS permite asociar topics (temas) a actions (acciones). Cada mensaje generado por un servicio, como radvd
, puede redirigirse, limitarse o descartarse según las reglas de logging configuradas.
3.2. Solución práctica
Opción 1 — Usar la acción interna discard
discard
En versiones recientes de RouterOS (7.x en adelante):
/system logging add topics=radvd action=discard
👉 Esto descarta todos los mensajes del tema radvd
sin registrarlos en memoria ni en syslog.
Está opción la publique pero tiene que ver cómo se hace la opción 2. Que la cree con el nombre discard.
La solución única propuesta es la 2.
Esta opción se muestra solo con fines históricos.
En las versiones actuales de RouterOS no existe una acción interna llamada discard. Por eso, la solución recomendada y única es la Opción 2 (crear una acción personalizada, que incluso podés llamar “discard” para mantener la coherencia).
Opción 2 — Crear una acción personalizada y asociarla
Para versiones que no soportan discard
, se puede crear una acción vacía:
/system logging action add name=none target=memory memory-lines=1
/system logging add topics=radvd action=none
✅ Con esto, los mensajes radvd
se almacenan en una memoria de una sola línea, que se sobrescribe, evitando acumulación en los logs.
Verificación
/system logging print
/log print where topics~"radvd"
No deberían aparecer nuevas entradas con radvd
.
4. Alternativas adicionales
Desactivar recepción de RA
Si el router no debe recibir anuncios IPv6:
/ipv6 settings set accept-router-advertisements=no
Desactivar publicidad RA por interfaz
Si no debe anunciar prefijos:
/interface ipv6 set ether1 advertise=no
Identificar el origen del anuncio inválido
Si se desea encontrar el dispositivo que genera el mensaje:
/tool sniffer quick interface=ether1 ip-protocol=icmpv6
Luego analizar las direcciones de origen con:
/tool sniffer packet print
5. Conclusión
Los mensajes radvd, warning invalid mtu
se originan por anuncios IPv6 incorrectos provenientes de otros dispositivos. Aunque no afectan la operación del router, ensucian los logs y consumen recursos de registro.
La solución más eficaz es filtrarlos mediante una regla de logging, utilizando la acción discard
o una acción personalizada none
.
Desde el punto de vista teórico, esto se justifica porque el evento no representa una condición anómala de red relevante, sino un simple aviso de cumplimiento de estándar. Desde el punto de vista práctico, mejora la limpieza del log y evita la pérdida de eventos más importantes.
Resumen
- El mensaje proviene del daemon
radvd
(Router Advertisement IPv6). - Causa: anuncios con MTU inválido desde otro host.
- Solución: filtrar o descartar el topic
radvd
mediante reglas de logging. - Efecto: logs más limpios, sin afectar el tráfico ni la conectividad IPv6.