QoS en MikroTik para redes empresariales

Cuando una red empresarial o de ISP entra en hora peak, el ancho de banda deja de ser el problema: el problema es cómo se reparte. Una descarga masiva, un respaldo mal programado o un puñado de suscriptores saturando el uplink bastan para que la telefonía IP se corte y las sesiones críticas se caigan, aunque el enlace tenga capacidad de sobra. Ahí es donde entra la QoS MikroTik: el conjunto de mecanismos de RouterOS para clasificar, priorizar y limitar tráfico de forma que lo importante siga fluyendo cuando el enlace se llena. En este artículo revisamos cómo implementarla en serio sobre RouterOS v7, con los comandos reales y las decisiones de diseño que separan un shaper que funciona de uno que solo mueve el problema de lugar.

Por qué la QoS importa antes de que se acabe el ancho de banda

El error más común es pensar que la QoS solo sirve cuando falta capacidad. En realidad, su rol central es gestionar la cola cuando hay contención: decidir qué paquete sale primero y cuál espera o se descarta cuando la interfaz de salida está congestionada. Sin control de tráfico, RouterOS atiende en orden de llegada (FIFO), y un flujo TCP agresivo puede acaparar la cola a costa de flujos sensibles a la latencia como voz, videoconferencia, señalización o tráfico de monitoreo.

En una red de ISP el síntoma es clásico: el cliente reclama "internet lento" a las 21:00 aunque el gráfico de tráfico no marque saturación total. Lo que está saturado es el buffer, no el enlace. La QoS bien diseñada ataca justamente eso —bufferbloat, reparto injusto entre suscriptores y falta de prioridad para tráfico crítico— antes de tener que salir a comprar más capacidad.

QoS MikroTik: Simple Queues frente a Queue Tree

RouterOS ofrece dos motores de encolado que comparten la misma base HTB pero se administran distinto. Elegir bien desde el inicio evita rehacer todo cuando la red crece.

• Simple Queues (/queue simple): se configuran por target (una IP, subred o interfaz) con un max-limit de subida/bajada. Se evalúan en orden, de arriba hacia abajo. Ideales para límites por cliente, pruebas rápidas y topologías pequeñas o medianas.
• Queue Tree (/queue tree): jerárquico, sin orden implícito, y trabaja sobre packet marks generados en el firewall mangle. Permite modelar la red como un árbol de prioridades y repartir el ancho de banda sobrante entre hijos. Es el camino para diseños grandes y granulares.

Una diferencia práctica importante: las Simple Queues limitan subida y bajada en una sola regla y se ubican antes que el Queue Tree en el procesamiento. El Queue Tree, en cambio, actúa en un solo sentido por árbol (por eso se suele armar uno para download y otro para upload) y necesita que primero marques el tráfico. Recuerda además la convención de RouterOS: desde el punto de vista del router, rx es la subida del cliente y tx es su bajada.

Criterio	Simple Queues	Queue Tree
Menú	/queue simple	/queue tree
Clasificación	Por target (IP/subred/interfaz)	Por packet-mark del mangle
Orden de evaluación	Secuencial (importa la posición)	Jerárquico (sin orden)
Sentido	Subida y bajada en una regla	Un sentido por árbol
Uso típico	Límite por cliente, redes chicas	Priorización granular, ISP, core

Clasificar el tráfico: mangle antes de encolar

Para el Queue Tree, la potencia está en la clasificación. RouterOS marca tráfico en /ip firewall mangle en dos pasos que conviene respetar por rendimiento: primero marcas la conexión y luego, sobre esa conexión ya marcada, marcas los paquetes. Así evitas que el router reinspeccione capa 4 en cada paquete de un flujo ya conocido.

/ip firewall mangle
add chain=prerouting action=mark-connection connection-mark=no-mark \
    protocol=tcp dst-port=5060 new-connection-mark=voip-con \
    passthrough=yes comment="senializacion SIP"
add chain=prerouting action=mark-packet connection-mark=voip-con \
    new-packet-mark=voip-pkt passthrough=no

/queue tree
add name=download parent=ether1 max-limit=500M
add name=voip parent=download packet-mark=voip-pkt \
    priority=1 limit-at=20M max-limit=50M queue=default-small
add name=resto parent=download packet-mark=no-mark \
    priority=8 max-limit=500M

Dos propiedades cargan todo el peso del diseño. priority toma valores de 1 a 8, donde 1 es la máxima prioridad y 8 la mínima: los hijos con prioridad más alta reciben primero el ancho de banda por sobre su limit-at. Y el par limit-at (garantizado) más max-limit (techo) define el reparto: limit-at es lo que la cola siempre recibe aunque el enlace esté saturado, y max-limit es hasta dónde puede crecer si hay sobrante. Modelar bien estos dos números por cada clase de servicio es el 80% del trabajo.

Si tu red ya transporta marcas DSCP desde el LAN o desde un core MPLS, puedes clasificar directamente contra ese campo en lugar de reinspeccionar puertos, y mantener así una política de QoS coherente extremo a extremo. Es el enfoque que aplicamos cuando integramos la QoS y el traffic shaping con el resto del diseño de red.

PCQ: reparto justo entre cientos de suscriptores

El limitante de las colas por IP aparece cuando tienes cientos o miles de clientes: no vas a escribir una regla por cada uno. Para eso RouterOS trae PCQ (Per Connection Queue), un tipo de cola que subdivide dinámicamente el tráfico en subflujos según un clasificador (por ejemplo dst-address para la bajada y src-address para la subida) y les da un reparto equitativo. RouterOS ya incluye los tipos pcq-upload-default y pcq-download-default listos para usar.

/queue type
add name=pcq-down kind=pcq pcq-classifier=dst-address pcq-rate=0
add name=pcq-up   kind=pcq pcq-classifier=src-address pcq-rate=0

/queue tree
add name=clientes-down parent=ether1 max-limit=800M \
    queue=pcq-down packet-mark=clientes-pkt

Con pcq-rate=0, PCQ divide el ancho de banda disponible en partes iguales entre todos los subflujos activos: si el enlace tiene espacio, cada quien corre libre; si se congestiona, nadie puede aplastar a los demás. Es la herramienta base para que un solo cliente descargando no degrade a toda la red, y encaja de forma natural con la gestión de abonados por PPPoE y con un buen esquema de balanceo de carga y failover, donde el plan de cada usuario se aplica vía perfil con su propio rate-limit.

Diseñar QoS MikroTik para producción, no solo para el lab

Los comandos son la parte fácil. Lo que hace fallar una implementación de QoS en terreno son las decisiones de arquitectura. Estas son las que revisamos en cada proyecto:

• Encola en la interfaz correcta. El shaping efectivo ocurre en el sentido de salida hacia el cuello de botella. Si limitas en el lugar equivocado, RouterOS descarta después de que el paquete ya cruzó el enlace congestionado y no ganas nada.
• Fija el max-limit raíz por debajo de la capacidad real del uplink. Si el enlace es de 500M, encola a ~90-95% para que la cola se forme en tu router y no en el equipo del carrier, donde no tienes control. Esa es la clave contra el bufferbloat.
• Usa el burst con criterio. El formato rate-limit de RouterOS admite burst-rate, burst-threshold y burst-time para dar picos cortos de velocidad sin romper el promedio. Bien calibrado mejora la experiencia percibida; mal calibrado, arruina el reparto.
• Prioriza poco y bien. Reserva la prioridad 1 para voz y señalización, prioridades intermedias para tráfico interactivo, y deja el bulk (respaldos, actualizaciones, descargas grandes) en la prioridad más baja. Si todo es prioritario, nada lo es.
• Mide antes y después. Una política de QoS sin observabilidad es fe, no ingeniería. Los contadores de colas, Traffic Flow y los gráficos por clase de servicio te dicen si el diseño realmente hace lo que crees.

La QoS no es una receta que se copia y pega: depende de tu topología, de tus cuellos de botella reales y del perfil de tráfico de tu operación. Un mismo /queue tree puede ser excelente en una red y contraproducente en otra.

Conversemos sobre tu control de tráfico

En MikroTik Chile diseñamos e implementamos control de tráfico sobre RouterOS para ISPs y empresas con infraestructura de misión crítica: clasificación con mangle, jerarquías de Queue Tree, PCQ para reparto justo y priorización de tráfico crítico, siempre con medición antes y después para validar que la política hace lo que promete. Si la congestión en hora peak o el reparto entre suscriptores te está quitando el sueño, conversemos sobre tu caso en una consultoría técnica y revisemos juntos el diseño de tu QoS.