Qué es QoS
QoS agrupa mecanismos para clasificar y tratar tráfico de forma diferenciada. No crea ancho de banda; administra cómo se usa un recurso cuando existe competencia.
QoS es el conjunto de mecanismos usados para clasificar y tratar tráfico de manera diferenciada cuando compite por recursos. No aumenta la capacidad física del enlace ni «acelera Internet» por sí sola. Su valor aparece principalmente cuando existe congestión o cuando ciertos flujos tienen requisitos más estrictos.
Una política comienza por objetivos: qué aplicaciones importan, qué latencia/jitter toleran y qué ancho de banda mínimo o máximo necesitan.
Métricas
Latencia, jitter, pérdida y throughput afectan de forma diferente a cada aplicación. Voz interactiva suele ser sensible a latencia y jitter; una transferencia puede tolerar más demora.
Las métricas principales son latencia, jitter, pérdida y throughput. Voz interactiva suele ser sensible a retardo, variación y pérdida; una copia masiva de archivos puede tolerar más latencia pero consumir mucha capacidad.
Diseñar QoS sin medir estas variables puede convertir una política en una colección de marcas sin efecto verificable.
Clasificación
Antes de dar un trato distinto hay que reconocer el tráfico. La clasificación puede usar interfaces, VLAN, direcciones, puertos u otros criterios.
Clasificar significa identificar tráfico según criterios como interfaz, dirección, protocolo, puertos, VLAN, aplicación u otras propiedades disponibles en la plataforma. Después se asigna una acción o clase de servicio.
La clasificación debe ser suficientemente estable y comprensible. Basarse sólo en puertos puede fallar en aplicaciones modernas que comparten transporte o cifran información.
DSCP y DiffServ
RFC 2474 define el campo Differentiated Services. DSCP permite marcar paquetes para indicar clases de tratamiento dentro de una política coherente.
DiffServ define un modelo escalable donde los paquetes se marcan en el campo DS de IP. El DSCP identifica un comportamiento esperado por salto. RFC 2474 define el campo y RFC 2475 la arquitectura.
Una marca no reserva recursos de extremo a extremo. Cada dominio debe mapearla a colas y políticas. Si un proveedor remarca o ignora DSCP, el tratamiento puede cambiar al cruzar su red.
Trust boundary
No se debe confiar ciegamente en cualquier marcado del cliente. El trust boundary define dónde se acepta, reescribe o elimina una marca.
La trust boundary define desde qué punto confías en las marcas recibidas. No es prudente permitir que cualquier endpoint se autoproclame tráfico prioritario. La red puede clasificar o remarcar en el acceso y conservar la política desde ahí.
Elegir el límite correcto simplifica la política y reduce abuso.
Colas
Cuando una interfaz no puede transmitir todo de inmediato, los paquetes esperan en colas. Un scheduler decide qué cola se atiende y con qué frecuencia.
Cuando una interfaz no puede transmitir todo inmediatamente, los paquetes esperan en colas. Los algoritmos de scheduling deciden cuánto servicio recibe cada cola. Una cola prioritaria puede reducir latencia de tráfico crítico, pero necesita límites para evitar dejar sin servicio al resto.
La implementación exacta —número de colas, pesos y algoritmos— depende del equipo. El concepto importante es que la política se manifiesta en la forma de atender congestión.
Policing
Policing aplica un límite y suele descartar o remarcar tráfico que excede el perfil. Es útil para imponer una tasa, pero puede introducir pérdida.
El policing compara tráfico con una tasa/perfil y puede descartar o remarcar excedentes. No necesita almacenar grandes cantidades para suavizar el flujo, por lo que puede introducir pérdida inmediata cuando se supera la política.
Se utiliza para hacer cumplir límites y proteger recursos, especialmente en bordes o contratos de servicio.
Shaping
Shaping suaviza la tasa almacenando temporalmente tráfico para enviarlo después. A diferencia de policing, usa buffering para reducir ráfagas.
El shaping retiene temporalmente tráfico para aproximarlo a una tasa objetivo. Necesita buffer y añade latencia, pero puede reducir ráfagas y adaptar una interfaz rápida a un servicio downstream más lento.
Policing y shaping no son equivalentes: uno suele castigar excedentes; el otro intenta diferirlos dentro de límites.
Congestión
Una cola completamente llena aumenta latencia y termina en descartes. Algunas técnicas de avoidance actúan antes del agotamiento total.
La congestión ocurre donde la demanda instantánea supera la capacidad de salida. Por eso hay que localizar el cuello de botella real. Aplicar QoS en un enlace que nunca se congestiona puede no cambiar nada perceptible.
Los buffers también importan: demasiado poco causa drops; demasiado puede aumentar latencia de forma severa. La política debe observar colas y descarte, no sólo utilización media.
Capa 2 y Capa 3
Ethernet puede transportar información de prioridad y IP utiliza DSCP. Al cruzar dominios pueden existir reglas de mapeo entre marcas.
Existen mecanismos de marcado en Capa 2 y Capa 3. 802.1Q incluye PCP dentro de la etiqueta VLAN; IP utiliza DSCP. Al atravesar dominios diferentes puede ser necesario mapear uno al otro según política.
La coherencia importa más que conservar ciegamente cualquier marca recibida.
Medición
Una política QoS debe validarse con datos: utilización, drops por cola, latencia y comportamiento de aplicaciones. SNMP puede ayudar a observar contadores.
Antes de desplegar QoS, establece un baseline: utilización, drops, latencia y jitter. Después compara con la misma metodología. Observa contadores por clase y cola para confirmar que el tráfico cae donde esperabas.
Sin medición, una política puede estar configurada pero no activarse nunca o clasificar tráfico incorrecto.
Troubleshooting
Confirma congestión real, clase seleccionada, marcado, trust boundary, drops, policing y shaping. Compara con una línea base antes de seguir cambiando.
Comprueba primero si existe congestión. Después valida clasificación, marcado, trust boundary y contadores por clase. Revisa en qué interfaz se aplica la política y en qué dirección. Sigue el paquete a través de cada dominio si las marcas cambian.
Si un flujo prioritario sigue teniendo mala calidad, el problema puede estar fuera del punto donde controlas QoS o deberse a pérdida/latencia previa.
Referencias
RFC 2474 define el campo DS, RFC 2475 la arquitectura DiffServ, RFC 3246 EF y RFC 2597 AF.
RFC 2474 define el Differentiated Services Field y RFC 2475 la arquitectura DiffServ. Los comportamientos por salto y algoritmos concretos tienen documentos adicionales; la configuración exacta depende de la plataforma.
Cómo continuar
SNMP y Syslog · routing · switching.
Relaciona QoS con SNMP y Syslog para medir colas y eventos, con routing para conocer el camino y con switching para políticas de acceso y trunk.
Ejemplo operativo
En una red real, QoS debe documentarse junto con direccionamiento, VLAN, rutas y políticas. El diagnóstico más fiable separa primero conectividad IP de la función del servicio, verifica el camino de ida y vuelta y después revisa la configuración específica. Esta disciplina evita atribuir a QoS fallos que en realidad pertenecen a Capa 2, routing, ACL o resolución de nombres.
También conviene registrar cambios y medir antes y después. Una configuración técnicamente válida puede tener un efecto operativo distinto al esperado si existen dependencias no documentadas o si varios dispositivos aplican políticas diferentes.
Un enlace WAN alcanza el 100 % durante copias de seguridad y las llamadas de voz se degradan. La solución no es marcar todo como prioritario. Se identifica voz, se define una cola de baja latencia con límites apropiados y se trata el backup como tráfico que puede esperar. Después se miden drops, jitter y utilización.
Si el enlace deja de congestionarse al aumentar capacidad, la política puede seguir siendo una protección útil, pero su efecto será menos visible en condiciones normales.