Ir al contenido

Silenciar logs de `radvd` en MikroTik: causa, teoría y solución práctica

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

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.
Etiquetas:

Dejá una respuesta