DHCP MikroTik: reservas, snooping y Option 82

Cuando una red crece, el servidor DHCP MikroTik deja de ser un detalle de configuración y pasa a ser un punto crítico de operación: si el direccionamiento se reparte mal, si un servidor DHCP no autorizado aparece en un puerto de acceso, o si no sabes qué IP tiene cada equipo importante, el troubleshooting en hora peak se vuelve un infierno. En un ISP con cientos de abonados o en una empresa con VLANs segmentadas por área, controlar cómo se entregan las direcciones y cómo se protege ese proceso es tan relevante como el ruteo mismo. En este artículo vemos dos piezas que marcan la diferencia entre un DHCP "que anda" y uno operable: las reservas (leases estáticos) y el DHCP snooping con Option 82.

Cómo trabaja el servidor DHCP MikroTik en RouterOS

En RouterOS el servicio no vive en un solo lugar: se reparte en menús que conviene tener claros antes de tocar nada. El servidor DHCP MikroTik se apoya en tres submenús que trabajan juntos:

• /ip/pool — define el rango de direcciones que se van a repartir.
• /ip/dhcp-server — asocia ese pool a una interfaz (o VLAN) y fija el lease-time.
• /ip/dhcp-server/network — entrega los parámetros de red al cliente: gateway, dns-server, máscara y opciones adicionales.

Un error frecuente es configurar el dhcp-server y olvidar el network: el cliente recibe una IP, pero sin gateway ni DNS, y aparece el clásico "tengo dirección pero no navego". Un despliegue típico con dos VLANs se ve así:

/ip/pool
add name=POOL10 ranges=192.168.10.10-192.168.10.254
add name=POOL20 ranges=192.168.20.10-192.168.20.254

/ip/dhcp-server
add address-pool=POOL10 disabled=no interface=VLAN10 name=DHCP10
add address-pool=POOL20 disabled=no interface=VLAN20 name=DHCP20

/ip/dhcp-server/network
add address=192.168.10.0/24 dns-server=192.168.10.1 gateway=192.168.10.1
add address=192.168.20.0/24 dns-server=192.168.20.1 gateway=192.168.20.1

Una propiedad que vale la pena revisar es add-arp en el dhcp-server. Cuando la usas junto con interfaces configuradas en arp=reply-only, el router solo responde ARP para los clientes que efectivamente tomaron lease del DHCP: una capa simple pero efectiva para que nadie se autoasigne una IP a mano y entre a la red saltándose el control.

Reservas DHCP: leases estáticos que sí puedes operar

Las reservas resuelven un problema concreto: hay equipos que no pueden andar cambiando de IP. Un servidor interno, una impresora de red, un access point administrado, una cámara, el CPE de un cliente corporativo. Con DHCP dinámico puro, esa IP depende del azar del pool; con una reserva, ese MAC recibe siempre la misma dirección, pero manteniendo la gestión centralizada del DHCP en lugar de configurar IP fija equipo por equipo.

En RouterOS las reservas viven en /ip/dhcp-server/lease. Hay dos caminos, y ambos son correctos según el escenario:

1. Convertir un lease dinámico en estático

Es la forma más segura de no equivocarse escribiendo el MAC. Dejas que el equipo tome dirección, verificas en la tabla de leases que sea el correcto y lo fijas con make-static:

/ip/dhcp-server/lease
print
make-static [find where address=192.168.10.50]

El lease deja de tener el flag D (dynamic) y queda persistente aunque el equipo se apague o expire el lease-time.

2. Crear la reserva a mano

Útil cuando planificas el direccionamiento antes de conectar el equipo. Aquí atas explícitamente el MAC a la dirección y al servidor correspondiente:

/ip/dhcp-server/lease
add address=192.168.10.50 mac-address=CC:2D:E0:01:6A:43 server=DHCP10 comment="Servidor-ERP"

Un consejo de operación: usa siempre el campo comment. En una red con cincuenta reservas, la diferencia entre un troubleshooting de dos minutos y uno de dos horas es tener cada lease etiquetado ("cámara-bodega", "AP-piso3", "CPE-cliente-X") en lugar de una lista de MACs anónimos. La reserva bien documentada es parte de la observabilidad de la red, no un lujo.

DHCP Snooping: bloquear el servidor DHCP no autorizado

Aquí está el problema clásico de seguridad de capa 2. Basta que alguien conecte un router con su DHCP activo en una toma de red para que, sin querer, empiece a repartir direcciones con un gateway equivocado. Peor todavía si es intencional: un servidor DHCP falso (rogue) puede entregarse a sí mismo como gateway y montar un ataque man-in-the-middle sobre todo el segmento. El DHCP dinámico no distingue quién responde primero, y ahí es donde entra el DHCP snooping.

En RouterOS el DHCP snooping es una función del bridge, no del servidor DHCP. La idea es simple y potente: marcas como trusted los puertos por donde vive tu servidor DHCP legítimo (uplinks, puerto del router), y dejas como untrusted los puertos de acceso donde se conectan los usuarios. Los mensajes de servidor DHCP que lleguen por un puerto untrusted se descartan: un CPE mal conectado o un rogue simplemente no puede envenenar la red.

/interface/bridge
add name=bridge dhcp-snooping=yes

/interface/bridge/port
add bridge=bridge interface=ether1 trusted=yes
add bridge=bridge interface=ether2 trusted=yes
add bridge=bridge interface=ether3

En este ejemplo ether1 y ether2 son confiables (hacia el DHCP y hacia otro switch de la topología), mientras que ether3 queda como puerto de acceso: si alguien enchufa ahí un servidor DHCP, sus ofertas se botan.

Hay un detalle de rendimiento que debes conocer antes de habilitarlo: activar DHCP snooping apaga el fast-path del bridge, lo que a su vez afecta la capacidad de fasttrack de las conexiones que pasan por ese bridge. En un equipo de borde con mucho tráfico, esto no es trivial. Por eso el snooping se diseña donde corresponde —en la capa de acceso, sobre switches con offload por hardware (los chips Marvell Prestera lo soportan a nivel de hardware)— y no se activa a ciegas en el core. Este tipo de decisión, dónde poner cada control sin degradar el forwarding, es exactamente lo que revisamos en una consultoría de arquitectura de red.

Option 82: identificar al abonado en redes de ISP

Para un ISP o WISP, el DHCP snooping abre una segunda puerta muy valiosa: Option 82. Es información que el equipo de acceso inyecta en los mensajes DHCP para identificar desde qué puerto y VLAN viene cada cliente, mediante dos subopciones: Agent Circuit ID (el puerto/VLAN de origen) y Agent Remote ID (el equipo que agrega la información). Con eso, tu servidor DHCP o RADIUS puede asignar direcciones y aplicar políticas por abonado sabiendo con certeza física de dónde proviene la petición —la base de una gestión de abonados ordenada.

En RouterOS la inserción de Option 82 se habilita en el bridge, junto al snooping, con la propiedad add-dhcp-option82:

/interface/bridge
set bridge dhcp-snooping=yes add-dhcp-option82=yes

Las versiones recientes de RouterOS 7 permiten además dar formato al Circuit ID y al Remote ID con variables predefinidas del bridge, lo que da control fino sobre cómo se identifica cada puerto:

/interface/bridge
set bridge dhcp-snooping=yes add-dhcp-option82=yes \
    dhcp-agent-circuit-id="interface: \$(INTERFACE), vlan: \$(VID)" \
    dhcp-agent-remote-id="identity: \$(HOSTNAME), mac: \$(BRIDGEMAC)"

Las variables disponibles incluyen $(INTERFACE), $(VID), $(HOSTNAME) y $(BRIDGEMAC). Ojo con dos cosas desde la terminal: el signo $ hay que escaparlo con backslash (si no, RouterOS lo interpreta como variable de script), y las subopciones de VLAN solo tienen sentido cuando el bridge corre con vlan-filtering=yes. Y si un puerto va a recibir mensajes que ya traen Option 82 agregada aguas abajo (por ejemplo desde otro switch de acceso), ese puerto debe marcarse como trusted, o los paquetes se descartan.

Errores comunes y buenas prácticas

La mayoría de los incidentes de DHCP que terminan en un ticket no son fallas del servicio, sino de diseño. Estos son los que más vemos en terreno:

Síntoma	Causa habitual	Dónde revisar
Cliente con IP pero sin navegar	Falta el network con gateway/DNS	/ip/dhcp-server/network
Equipos que cambian de IP	Sin reserva; dependen del pool dinámico	/ip/dhcp-server/lease
Direcciones repartidas por un gateway extraño	Servidor DHCP rogue en puerto de acceso	Bridge: dhcp-snooping + puertos trusted
Caída de throughput tras activar snooping	Fast-path/fasttrack deshabilitado en el bridge	Ubicación del snooping en la topología
Pool agotado en hora peak	lease-time demasiado largo para rotación alta	/ip/dhcp-server lease-time

Como regla práctica: reserva todo lo que sea infraestructura (servidores, APs, cámaras, CPEs corporativos), aplica snooping en la capa de acceso y no en el core, ajusta el lease-time según la rotación real del segmento, y documenta cada lease con su comment. Y no olvides que el DHCP no es una isla: convive con tu política de firewall —control de tráfico entre VLANs, protección del propio router— y con el direccionamiento general. Si estás lidiando con un comportamiento raro y no logras aislarlo, nuestro equipo de soporte MikroTik puede ayudarte a diagnosticarlo.

En MikroTik Chile diseñamos, implementamos y operamos redes donde el DHCP, las VLANs, el snooping y el firewall forman un solo esquema coherente, documentado y listo para crecer, no una suma de configuraciones sueltas. Si tienes un despliegue de ISP con Option 82, una segmentación empresarial que se te está desordenando, o simplemente quieres una segunda opinión de ingeniería sobre tu direccionamiento, conversemos tu caso.