QoS: prioriza el tráfico crítico de tu red

En una red corporativa sin mecanismos de calidad de servicio (QoS), todos los paquetes son iguales. Una descarga masiva de actualizaciones de Windows, una llamada de voz sobre IP y una consulta de base de datos del ERP compiten por el mismo ancho de banda en igualdad de condiciones. El resultado previsible es que la llamada de voz suena entrecortada, la videoconferencia se congela y los usuarios se quejan de que 'la red va lenta', mientras el equipo de TI se esfuerza en encontrar una causa que en realidad no es técnica sino de política de priorización.

QoS (Quality of Service) es el conjunto de mecanismos que permite a los dispositivos de red —switches, routers, firewalls, appliances SD-WAN— tratar los distintos flujos de tráfico de forma diferenciada según su criticidad para el negocio. No aumenta el ancho de banda disponible, pero gestiona eficazmente la congestión, garantizando que cuando el recurso escasea, los flujos más importantes tienen preferencia.

Este artículo explica los modelos de QoS, los mecanismos de clasificación y marcado, las colas de servicio, la gestión de la congestión y cómo diseñar e implementar una política QoS eficaz en una red empresarial moderna, con referencias a entornos con SD-WAN, enlaces MPLS y redes de campus.

Por qué QoS es crítico hoy más que nunca

La importancia de QoS ha aumentado, paradójicamente, a medida que el ancho de banda disponible ha crecido. Con conexiones de fibra de varios cientos de megabits o incluso gigabits en las sedes, podría pensarse que la congestión ya no es un problema. Pero hay varios factores que mantienen QoS como una necesidad real. El primero es la latencia: las aplicaciones de voz y video son extremadamente sensibles a la latencia y el jitter (variación de latencia). Aumentar el ancho de banda no reduce la latencia; solo la gestión de colas lo hace.

El segundo factor es la asimetría del tráfico en tiempo real: una videoconferencia genera ráfagas de tráfico en tiempo real que compiten con transferencias de datos de gran volumen. Sin priorización, las ráfagas de un backup o de actualizaciones pueden generar microcongestiones que duran milisegundos pero son suficientes para degradar la calidad de voz perceptiblemente. El tercer factor es el crecimiento del tráfico IoT y de aplicaciones de fondo (analytics, replicación de datos, actualizaciones automáticas) que consumen banda sin beneficio directo para el usuario final.

Modelos de QoS: IntServ y DiffServ

Históricamente han coexistido dos modelos de QoS en las redes IP. El primero es IntServ (Integrated Services), basado en la reserva explícita de recursos para cada flujo mediante el protocolo RSVP. Cada aplicación negocia con la red una garantía de ancho de banda y latencia. El modelo ofrece garantías absolutas pero es prácticamente inescalable en redes grandes, ya que cada router debe mantener estado por flujo.

El modelo dominante en entornos empresariales es DiffServ (Differentiated Services), que agrupa el tráfico en clases y aplica políticas por clase. Los paquetes se marcan en el campo DSCP (Differentiated Services Code Point, 6 bits del campo DS del encabezado IP) con un valor que indica la clase de servicio a la que pertenecen. Cada dispositivo de red toma decisiones de reenvío basándose en ese marcado, sin necesidad de estado por flujo. DiffServ es escalable, sencillo de implementar y es el estándar en redes empresariales y de operador.

DSCP: valores, clases y buenas prácticas

El campo DSCP permite hasta 64 valores de marcado diferentes. En la práctica, se usan un subconjunto estandarizado de PHBs (Per-Hop Behaviors) que definen cómo debe tratarse el tráfico en cada salto de la red:

• EF (Expedited Forwarding, DSCP 46): máxima prioridad, latencia y jitter mínimos garantizados. Reservado para tráfico de voz (RTP de VoIP).
• CS5 (DSCP 40) y AF41 (DSCP 34): señalización de voz (SIP, H.323) y vídeo interactivo (videoconferencias).
• AF31-AF33 (DSCP 26-30): aplicaciones críticas de negocio (ERP, CRM, transacciones financieras).
• AF21-AF23 (DSCP 18-22): aplicaciones importantes pero no críticas (correo corporativo, colaboración).
• CS0 / BE (DSCP 0): Best Effort, tráfico por defecto sin marcado específico.
• CS1 / AF11-AF13: tráfico de baja prioridad (actualizaciones, backups, analytics). En algunos diseños se usa también DSCP 8 (CS1) para tráfico 'scavenger' que solo usa banda disponible.

Una práctica importante es la confianza de marcado (trust boundary): los dispositivos de red solo deben confiar en el marcado DSCP de fuentes autorizadas. Los endpoints de usuario (PCs, smartphones) no deben tener confianza por defecto; el marcado debe hacerse o revalidarse en el switch de acceso o en el firewall. Los teléfonos IP de Cisco o de otros fabricantes certificados sí deben marcarse en el origen, pero ese marcado debe validarse en el primer switch.

Mecanismos de cola y scheduling

El marcado DSCP por sí solo no hace nada: necesita mecanismos de cola y scheduling en los dispositivos de red que actúen sobre ese marcado cuando hay congestión. Los principales mecanismos son:

Priority Queuing (PQ) y Low Latency Queuing (LLQ)

Priority Queuing asigna el tráfico a colas con diferentes niveles de prioridad absoluta. La cola de mayor prioridad siempre se sirve primero antes de atender las colas inferiores. El riesgo es el starvation: si la cola de alta prioridad siempre tiene tráfico, las colas inferiores nunca se sirven. LLQ (Low Latency Queuing), el mecanismo estándar en Cisco IOS, combina una cola de prioridad estricta para el tráfico EF (voz) con CBWFQ (Class-Based Weighted Fair Queuing) para el resto de clases, garantizando que el tráfico de voz siempre tenga servicio inmediato mientras el resto comparte el ancho de banda de forma proporcional.

CBWFQ: Class-Based Weighted Fair Queuing

CBWFQ asigna a cada clase de tráfico un porcentaje mínimo garantizado del ancho de banda del enlace. Si la clase no usa todo su porcentaje asignado, el excedente está disponible para otras clases. Es el mecanismo más usado para garantizar ancho de banda mínimo a aplicaciones críticas sin desperdiciar capacidad cuando el tráfico es bajo.

Gestión activa de colas: WRED y tail drop

Cuando una cola se llena, los paquetes nuevos deben descartarse. Tail drop es el mecanismo más simple: se descartan los paquetes que llegan cuando la cola está al 100% de capacidad. El problema de tail drop es que puede provocar TCP global synchronization: todos los flujos TCP detectan la pérdida simultáneamente, reducen su ventana de congestión al mismo tiempo y luego la aumentan al mismo tiempo, creando un patrón oscilatorio que infrautiliza el enlace.

WRED (Weighted Random Early Detection) resuelve esto descartando paquetes de forma probabilística antes de que la cola se llene completamente. La probabilidad de descarte aumenta a medida que la cola se acerca al límite, y el peso del descarte es mayor para clases de menor prioridad (por ejemplo, BE) que para clases de alta prioridad (AF41). Esto previene la sincronización TCP y mantiene mayor utilización del enlace con menor latencia promedio.

Traffic shaping y policing

Traffic shaping y policing son dos mecanismos complementarios para controlar el volumen de tráfico de una clase. El shaping retarda los paquetes que exceden la tasa definida, almacenándolos en un buffer y enviándolos cuando hay capacidad disponible. El resultado es una tasa de salida suavizada. El policing, en cambio, descarta (o re-marca) los paquetes que exceden la tasa definida sin buffering adicional. Policing es apropiado en los bordes de la red (como en el ingreso desde el proveedor) para forzar el cumplimiento del contrato de tráfico; shaping es más adecuado dentro de la red para suavizar ráfagas.

En entornos SD-WAN, el shaping es especialmente relevante para el tráfico saliente hacia los circuitos WAN, donde la sobre-suscripción es frecuente. La mayoría de las soluciones SD-WAN tienen mecanismos integrados de shaping y policing por clase de tráfico que sustituyen o complementan los mecanismos tradicionales de QoS del router.

QoS en redes de campus: switches y acceso inalámbrico

La QoS no es solo una preocupación del router WAN. En redes de campus modernas con alta densidad de aplicaciones real-time, la QoS debe implementarse en toda la pila, desde el switch de acceso hasta el router de salida. En los switches de acceso, el marcado DSCP de los endpoints autorizados (teléfonos IP) se confía directamente; el resto se reclasifica según el puerto o mediante ACLs. En los switches de distribución y core, las colas garantizan que el tráfico de voz tenga latencia predecible incluso en momentos de alta carga.

En redes Wi-Fi empresariales, QoS se implementa mediante WMM (Wi-Fi Multimedia), que mapea las clases DSCP a cuatro colas de acceso en la radio: VO (Voice), VI (Video), BE (Best Effort) y BK (Background). Los access points modernos implementan EDCA (Enhanced Distributed Channel Access) para que los frames de alta prioridad tengan ventaja estadística en el acceso al medio inalámbrico.

Diseño de una política QoS empresarial

Diseñar una política QoS eficaz requiere un proceso estructurado. El punto de partida es el inventario de aplicaciones y sus requisitos: identifica qué aplicaciones usa tu organización y clasifícalas por criticidad y sensibilidad a la latencia/jitter.

1. Inventaria y clasifica las aplicaciones: voz y video en tiempo real, aplicaciones transaccionales críticas, aplicaciones colaborativas, transferencias de datos y tráfico de gestión.
2. Define el número de clases QoS: lo habitual en entornos empresariales es 6-8 clases. Más clases aumentan la complejidad sin beneficio adicional significativo.
3. Asigna valores DSCP a cada clase y define los porcentajes de ancho de banda mínimo garantizado para cada cola.
4. Establece la trust boundary: decide qué dispositivos pueden hacer marcado de confianza (teléfonos IP, endpoints gestionados con agente) y dónde se re-marca el tráfico.
5. Implementa y valida con tráfico real: usa herramientas de generación de tráfico (iperf3, IXIA) para verificar que las políticas funcionan correctamente bajo carga.
6. Documenta la política y revisala periódicamente: las necesidades de las aplicaciones cambian y la política QoS debe actualizarse.

QoS en entornos con Microsoft Teams y plataformas UCaaS

La proliferación de plataformas UCaaS (Unified Communications as a Service) como Microsoft Teams, Zoom o Cisco Webex ha añadido nuevas complejidades al diseño QoS. Microsoft publica documentación detallada de los rangos de puertos y valores DSCP recomendados para Teams: audio en DSCP 46 (EF), vídeo en DSCP 34 (AF41) y compartición de pantalla en DSCP 18 (AF21). Configurar los endpoints Windows mediante GPO y los routers/firewalls para confiar y enrutar ese marcado es un paso crítico para garantizar la calidad de las comunicaciones unificadas.

Un error frecuente es aplicar políticas QoS en la LAN interna pero ignorar el tráfico hacia Internet o hacia los PoPs del proveedor UCaaS. Para tráfico saliente hacia SaaS, el marcado DSCP puede o no ser respetado por el ISP (en Internet público no está garantizado). Aquí es donde SD-WAN añade valor: puede aplicar políticas de priorización end-to-end sobre cualquier transporte mediante tunneling con marcado propio.

Herramientas de monitorización y validación de QoS

Implementar QoS sin monitorización continua es como configurar un semáforo y no comprobar si los coches lo respetan. Las herramientas más útiles para validar QoS son:

• NBAR2 (Network-Based Application Recognition): disponible en Cisco IOS/IOS-XE, clasifica el tráfico en tiempo real y genera estadísticas por aplicación.
• NetFlow/IPFIX y Sflow: exportan datos de flujo a colectores como ntopng, Elastic Stack o Grafana para análisis de distribución de tráfico por clase.
• IP SLA (Cisco) o equivalentes de otros fabricantes: generan tráfico de prueba sintético para medir latencia, jitter y pérdida de paquetes de extremo a extremo.
• iperf3: herramienta de código abierto para pruebas de ancho de banda y QoS. Permite generar tráfico UDP con tasa fija para simular flujos de voz y medir jitter.
• Wireshark con filtros DSCP: útil para verificar que los paquetes lleguen con el marcado correcto en puntos específicos de la red.

QoS no resuelve problemas de falta de ancho de banda: resuelve problemas de distribución injusta del ancho de banda disponible. Si el enlace está al 100% de utilización de forma sostenida, la solución es ampliar la capacidad, no solo priorizar.

Errores comunes en implementaciones QoS

• Implementar QoS solo en los routers WAN e ignorar los switches de acceso y distribución.
• No definir trust boundaries: confiar en el marcado DSCP de todos los endpoints permite que un usuario malicioso marque su tráfico como EF.
• Asignar demasiado ancho de banda a la cola de voz: si la cola EF supera el 33% del ancho de banda del enlace, puede degradar otras clases críticas.
• No validar con tráfico real: la configuración puede ser sintácticamente correcta pero comportarse diferente bajo carga.
• Olvidar el tráfico de control de red (OSPF, BGP, ICMP, STP): debe protegerse con CS6 o CS7 para que los problemas de routing no afecten a la QoS del plano de datos.

Conclusión

QoS es una de esas capacidades de red que pasan desapercibidas cuando funcionan bien y generan frustración constante cuando no existen o están mal configuradas. Implementarla correctamente requiere un análisis previo de las aplicaciones, una política clara de clases y marcado, y validación con tráfico real. El tiempo invertido en este diseño se recupera con creces en menos incidencias de voz y video, mayor satisfacción de usuarios y un equipo de TI que no tiene que apagar fuegos constantemente.

Si estás empezando desde cero, el mejor enfoque es comenzar con un modelo simplificado de 4-6 clases bien definidas y expandirlo gradualmente. Utiliza las guías de QoS publicadas por Cisco (SRND), Microsoft (para Teams) y los fabricantes de tu equipamiento como referencia, y ajusta basándote en mediciones reales de tu tráfico.