QoS en redes: qué es, cómo funciona y para qué sirve
Una guía práctica para entender latencia, jitter, colas y marcado de paquetes en entornos reales.
QoS, o Quality of Service, no hace que una red lenta se vuelva rápida por arte de magia. Su objetivo es más concreto: decidir qué paquetes deben recibir mejor trato cuando hay congestión. Es una forma de ordenar el tráfico para que las aplicaciones sensibles, como voz, vídeo interactivo o sistemas críticos, sufran menos retraso, variación o pérdida cuando el enlace empieza a llenarse.
1) ¿Qué es QoS (Quality of Service) en redes?
QoS es el conjunto de técnicas que permiten clasificar, marcar, encolar, priorizar, limitar o descartar tráfico de red siguiendo una política. Dicho de forma sencilla: cuando todos los paquetes caben, QoS apenas se nota; cuando no caben, QoS decide quién pasa primero, quién espera y quién puede perderse antes.
Conviene separar tres ideas. La primera es la clasificación: identificar qué tráfico es voz, backup, navegación, replicación, gestión o cualquier otra categoría relevante. La segunda es el marcado: escribir esa intención en el paquete, por ejemplo usando DSCP en la cabecera IP. La tercera es el tratamiento: aplicar colas, prioridad, shaping, policing o descarte según esa marca y según la capacidad real del enlace.
La clave es entender que QoS no aumenta el ancho de banda. Si un enlace tiene 100 Mbps, seguirá teniendo 100 Mbps. Lo que sí puede hacer es evitar que una copia masiva, una sincronización o una descarga degraden una llamada de voz o una sesión de administración crítica.
2) ¿Por qué es importante implementar QoS en una red?
En una red de laboratorio, muchas veces todo parece funcionar porque no hay presión. En producción, la realidad cambia: usuarios en videollamada, copias de seguridad, replicación entre sedes, actualizaciones, escritorios remotos, tráfico SaaS, túneles VPN y monitorización compiten por los mismos enlaces.
Cuando aparece congestión, los síntomas no siempre se ven como “la red está caída”. A veces la red responde, pero la experiencia es mala: llamadas con cortes, vídeo congelado, escritorios remotos con retardo, sesiones SSH que se sienten pesadas o aplicaciones que tienen picos de latencia. Ahí QoS ayuda a proteger lo importante.
También importa porque muchas aplicaciones no sufren igual. Una transferencia de archivos puede tardar unos segundos más y seguir siendo útil. Una llamada de voz, en cambio, tolera mal la variación de retardo. TCP suele recuperarse ante pérdida reduciendo velocidad y retransmitiendo; UDP, usado en muchos flujos en tiempo real, normalmente no tiene esa corrección integrada a nivel de transporte. Por eso tratar todo igual suele parecer justo, pero no siempre es operativo.
3) ¿Cómo funciona QoS paso a paso?
El flujo típico de QoS puede explicarse en cinco pasos.
Primero, se define la política. No se empieza configurando comandos, sino preguntando qué aplicaciones importan, qué enlaces se congestionan y qué tráfico puede esperar. Una política simple y mantenible suele ser mejor que una matriz enorme que nadie entiende.
Segundo, se clasifica el tráfico cerca del origen o en el primer punto de control fiable. Puede hacerse por subred, puerto, protocolo, aplicación, interfaz, VLAN o marca existente. En redes modernas, esta parte exige cuidado porque mucho tráfico va cifrado y no siempre es realista inspeccionar aplicación por aplicación.
Tercero, se marca. El campo DSCP permite indicar una clase de servicio dentro del paquete IP. Por ejemplo, en muchos diseños la voz se marca como EF, asociado al valor decimal 46. Otros tipos de tráfico pueden usar clases AF o valores menos prioritarios. Lo importante no es memorizar todos los códigos, sino mantener coherencia extremo a extremo.
Cuarto, cada equipo decide si confía o no en esa marca. Este punto es crítico: si cualquier dispositivo puede marcarse como prioritario, todo el mundo podría intentar entrar en la cola rápida. Por eso se suelen definir límites de confianza en switches de acceso, routers de borde o firewalls.
Quinto, se aplica el tratamiento en los puntos donde hay congestión, especialmente en enlaces WAN, VPN, accesos a Internet, uplinks saturables o interfaces de menor velocidad. Ahí entran las colas de prioridad, reservas de ancho de banda, shaping para suavizar ráfagas y policing para cortar tráfico que excede lo permitido.
4) Ejemplo práctico de configuración de QoS en una red
Imaginemos una sede con un enlace de 100 Mbps hacia un datacenter. Por ese enlace viajan tres tipos de tráfico: telefonía IP, acceso a una aplicación interna y copias de seguridad nocturnas. Sin QoS, una copia puede llenar el enlace y provocar cortes en las llamadas.
Una política sencilla podría ser:
- Voz: prioridad estricta, hasta 10 Mbps.
- Aplicación interna: clase preferente, mínimo 40 Mbps si hay congestión.
- Backup: mejor esfuerzo, puede usar lo que sobre, pero sin desplazar lo crítico.
En pseudo-configuración, la idea se vería así:
class VOZ
match dscp ef
class APP-INTERNA
match subnet 10.20.30.0/24
class BACKUP
match subnet 10.50.0.0/16
policy WAN-SALIDA
priority VOZ limit 10m
bandwidth APP-INTERNA 40m
default BACKUP best-effort
interface wan0
service-policy output WAN-SALIDA
No tomes esta pseudo-configuración como sintaxis de un fabricante. Es el modelo mental: reconocer tráfico, asignarlo a clases y aplicar una política donde realmente se forma la cola. Si el cuello de botella está en la salida WAN, aplicar QoS en un switch interno que no se congestiona probablemente no resolverá el problema.
Un detalle importante: si el proveedor entrega un enlace de 100 Mbps pero el puerto físico negocia a 1 Gbps, el router puede enviar ráfagas a 1 Gbps hacia un servicio que en realidad limita a 100 Mbps más adelante. En esos casos, configurar shaping a una velocidad ligeramente inferior a la capacidad contratada puede ayudar a que la cola se forme en tu equipo, donde sí puedes ordenar los paquetes.
5) Errores comunes al configurar QoS y cómo evitarlos
El primer error es creer que QoS arregla falta crónica de capacidad. Si todos los días el enlace está al 95 % durante horas y todo es importante, la política solo repartirá dolor. QoS compra control, no ancho de banda infinito.
El segundo error es marcar demasiado tráfico como prioritario. Si la cola de prioridad contiene voz, vídeo, backups, escritorios remotos, navegación y actualizaciones, deja de ser prioritaria. La prioridad debe reservarse para tráfico muy sensible y con límites claros.
El tercer error es no aplicar QoS en el cuello de botella real. Las colas importan donde hay congestión. Si el problema está en el túnel VPN, en el firewall de salida o en el enlace del operador, ahí hay que mirar. Configurar diez puntos intermedios puede añadir complejidad sin beneficio.
El cuarto error es confiar ciegamente en las marcas entrantes. En redes corporativas conviene decidir qué marcas se aceptan, cuáles se reescriben y dónde empieza el dominio de confianza. Esto evita que un equipo mal configurado o una aplicación oportunista capture prioridad indebida.
El quinto error es no medir antes y después. Una política de QoS sin métricas se convierte en una opinión. Hay que observar utilización, descartes por clase, latencia, jitter, retransmisiones, calidad de llamadas y comportamiento en horas punta.
6) Checklist para implementar QoS correctamente en una red
Empieza identificando el enlace o interfaz donde realmente aparece congestión. Sin cuello de botella, QoS será difícil de demostrar.
Define pocas clases. Para muchos entornos basta con voz o tiempo real, negocio crítico, gestión, datos normales y tráfico masivo o diferible.
Marca cerca del origen, pero valida en el borde. No todo lo que llega marcado debe ser aceptado sin control.
Limita la cola de prioridad. La prioridad estricta debe tener techo para evitar que deje sin servicio al resto.
Usa shaping cuando el límite real esté por debajo de la velocidad física de la interfaz.
Documenta la política en lenguaje humano: qué entra en cada clase, por qué, dónde se aplica y quién puede pedir cambios.
Mide con datos reales. Revisa contadores de cola, drops, latencia y experiencia de usuario antes de tocar más parámetros.
Mantén la política simple. QoS compleja, sin dueño y sin documentación, suele degradarse con el tiempo.
Conclusión: cómo utilizar QoS para mejorar el rendimiento de la red
QoS es una herramienta de diseño, no una casilla mágica. Funciona mejor cuando se parte de una pregunta concreta: ¿qué tráfico debe sobrevivir mejor cuando la red se llena? A partir de ahí, la técnica consiste en clasificar bien, marcar con coherencia, confiar solo donde toca y aplicar colas en el punto exacto de congestión.
Bien usada, QoS no se nota porque todo fluye con normalidad incluso en momentos de presión. Mal usada, puede crear falsas expectativas o esconder un problema de capacidad. La diferencia está en tratarla como una política operativa, no como una receta de comandos.