Comprenda cómo evaluar el rendimiento de redes mediante latencia, jitter, pérdida, throughput, goodput, utilización, colas, capacidad y comportamiento de las aplicaciones, con criterios de diseño, medición y aceptación.
¡Descúbrelo!
El rendimiento de las redes de computadoras es la capacidad de la infraestructura para transportar los flujos necesarios con tasa útil, retardo, variación del retardo, pérdida y disponibilidad compatibles con las aplicaciones. No basta con que una interfaz opere a 1, 10 o 100 Gb/s: la experiencia efectiva depende de la ruta completa, las colas, la carga concurrente, el tamaño de los paquetes, la arquitectura física y lógica, los hosts y el comportamiento de los protocolos.
Una red puede tener un ancho de banda nominal elevado y, aun así, presentar bajo throughput, retransmisiones, jitter o latencia creciente bajo carga. Por ello, el rendimiento debe tratarse como una disciplina de ingeniería: los requisitos deben definirse antes del diseño, medirse con una metodología reproducible y verificarse durante la operación y la aceptación.
El objetivo de este artículo es establecer esa base: qué medir, por qué las métricas se relacionan, cómo la arquitectura influye en el resultado y cómo transformar el rendimiento en un requisito verificable. El diagnóstico de una red que ya presenta lentitud o inestabilidad es un problema complementario, pero distinto.
¿Qué Define el Rendimiento de una Red?
El rendimiento percibido por una aplicación resulta de la interacción entre origen, destino y todos los elementos de la ruta. Entre dos hosts puede haber switches, routers, firewalls, controladores Wi-Fi, enlaces WAN, túneles, balanceadores, servicios cloud y colas independientes. Cada elemento puede añadir retardo, imponer una capacidad máxima, descartar paquetes o modificar la forma en que los flujos compiten por recursos.
Por ello, el análisis no debe reducirse a la pregunta «¿cuál es la velocidad del enlace?». Es necesario distinguir capacidad nominal, utilización, throughput, goodput, latência, jitter, perda, retransmisiones y disponibilidad.
La arquitectura también debe considerar el comportamiento del Tráfico de Red: flujos, carga, broadcast, multicast y capacidad, porque un enlace rara vez transporta un único servicio aislado.
Capacidad, Ancho de Banda y Utilización
La capacidad de un enlace representa la tasa nominal soportada por el medio y la tecnología. La utilización representa cuánto de esa capacidad se demanda en un intervalo determinado. Un enlace de alta capacidad puede presentar congestión durante intervalos breves incluso cuando el promedio de cinco minutos parece bajo.
Esto ocurre porque el tráfico de red es variable. Backups, transferencias, actualizaciones, streams de video, sincronizaciones y respuestas simultáneas pueden formar microbursts que ocupan buffers y producen descartes antes de que el promedio agregado revele saturación.
Por lo tanto, la medición de capacidad debe considerar la ventana temporal, la dirección del tráfico y el punto exacto de la ruta observada.
Throughput y Goodput
Throughput es la tasa efectivamente transferida a lo largo de la ruta en un intervalo determinado. Puede ser inferior a la velocidad nominal debido al overhead de protocolos, contención, pérdida, retransmisión, limitaciones del host, ventana de transporte, procesamiento de firewall u otras restricciones.
Goodput representa la parte realmente útil entregada a la aplicación, excluyendo retransmisiones y overhead que no forman parte del dato útil. Esta distinción es importante porque un enlace puede estar muy ocupado y, aun así, aportar poco valor a la aplicación si una parte relevante de la capacidad se consume en retransmisiones o tráfico innecesario.
Latencia y RTT
La latencia es el retardo entre origen y destino. Dependiendo del método, puede medirse el retardo en un sentido o el round-trip time (RTT). El RTT incluye la ida, la vuelta y los tiempos de procesamiento encontrados en la ruta.
Los componentes del retardo incluyen:
- propagación en el medio físico;
- serialización de bits en el enlace;
- procesamiento en hosts y equipos;
- encolamiento;
- inspección por firewalls o funciones de seguridad;
- túneles, proxies y servicios intermedios;
- distancia y arquitectura WAN o cloud.
La parte más variable en redes congestionadas suele ser el retardo de cola. Por ello, una red puede presentar un RTT estable con baja carga y aumentarlo significativamente cuando los enlaces se acercan a la saturación.
Jitter o Variación del Retardo
El jitter es la variación temporal del retardo entre paquetes. Las aplicaciones interactivas y los flujos en tiempo real son especialmente sensibles a esta variación porque necesitan reproducir audio, video o señales de control con una cadencia previsible.
Los buffers de reproducción pueden absorber parte de la variación, pero añaden retardo. Por lo tanto, no existe una optimización sin compromisos: aumentar el buffer puede reducir fallas perceptibles de reproducción, pero también aumenta la latencia de extremo a extremo.
Pérdida de Paquetes y Retransmisión
Los paquetes pueden descartarse por colas llenas, errores físicos, políticas, problemas de radiofrecuencia, fallas de interfaz u otros mecanismos. El efecto de la pérdida depende del protocolo y de la aplicación.
En TCP, la pérdida puede provocar retransmisiones y reducción de la tasa de envío conforme a los mecanismos de control de congestión. En UDP, la red no retransmite automáticamente el datagrama perdido; la aplicación decide si lo recupera, lo oculta o simplemente acepta la pérdida.
Por ello, «1% de pérdida» no tiene el mismo impacto en todas las aplicaciones. El requisito debe derivar del servicio y del comportamiento del protocolo, no de un número genérico aplicado a toda la red.
Métricas que Deben Evaluarse en Conjunto
Ninguna métrica aislada describe el rendimiento completo. Una medición coherente combina indicadores del enlace, la ruta, el transporte y la aplicación.
| Métrica | Qué representa | Qué puede revelar |
| capacidade nominal | límite tecnológico del enlace | techo teórico del segmento |
| utilização | parte de la capacidad demandada | saturación sostenida o picos |
| throughput | tasa efectivamente transferida | capacidad práctica de la ruta |
| goodput | dato útil entregado a la aplicación | eficiencia real de la transferencia |
| latencia/RTT | tiempo de tránsito y retorno | distancia, colas y procesamiento |
| jitter | variación del retardo | inestabilidad temporal de las colas |
| pérdida | paquetes no entregados | congestión, errores o políticas |
| retransmisiones TCP | datos reenviados | pérdida, reordenamiento o timeout |
| errores/discards de interfaz | fallas registradas en el equipo | capa física, cola o configuración |
| CPU/memoria | recurso de procesamiento | posible limitación del equipo |
| colas/queue drops | ocupación y descarte por clase | contención y QoS |
| airtime y retries Wi-Fi | uso del medio y reintentos | interferencia, cobertura o densidad |
El Monitoreo de Red proporciona la capa continua de métricas; NetFlow y el análisis de flujos ayudan a explicar quién está consumiendo la ruta; y la Gestión de Redes basada en FCAPS organiza el rendimiento como parte de la operación.
Congestión, Colas y Buffers
La congestión ocurre cuando la demanda de tráfico de un determinado recurso supera la capacidad disponible en ese instante. Ese recurso puede ser una interfaz física, una cola de salida, un firewall, un túnel, una radio Wi-Fi, una CPU o un enlace WAN.
Cuando los paquetes llegan más rápido de lo que pueden transmitirse, entran en cola. Si la cola crece, la latencia aumenta. Si el buffer se agota, los paquetes se descartan. Por lo tanto, una latencia creciente bajo carga puede ser una señal de congestión antes de que aparezca la pérdida.
El Buffer No Es Capacidad
Los buffers absorben diferencias temporales entre la tasa de llegada y la tasa de salida. Son necesarios, pero no convierten un enlace lento en uno rápido. Los buffers excesivos pueden permitir colas muy largas, aumentando la latencia de aplicaciones interactivas durante grandes transferencias — fenómeno frecuentemente asociado con bufferbloat.
La arquitectura de colas debe analizarse junto con QoS, el comportamiento del transporte y el perfil de los flujos.
Microbursts
Los microbursts son picos de tráfico muy breves. Pueden saturar una interfaz durante milisegundos o menos, provocar descartes y desaparecer antes de que herramientas con intervalos de recolección espaciados registren una utilización media alta.
Esta es una de las razones por las que el troubleshooting de rendimiento no debe depender exclusivamente de gráficos agregados. Contadores de descarte, telemetría de alta frecuencia, captura de paquetes y análisis del patrón de flujos pueden revelar fenómenos invisibles en el promedio.
Desequilibrio entre Interfaces y Oversubscription
Cuando múltiples puertos de acceso convergen en uplinks de menor capacidad agregada, existe oversubscription. Esto no es necesariamente un error: las redes se diseñan considerando que no todos los usuarios transmiten al máximo simultáneamente. El problema surge cuando la relación de agregación no corresponde al comportamiento real de las aplicaciones.
Un desequilibrio simple, como tráfico procedente de varios enlaces rápidos hacia una única salida más lenta, crea un punto de contención previsible. El análisis debe realizarse por dirección y según el peor escenario plausible de simultaneidad.
Packet Rate, Tamaño de Paquete y Capacidad de los Equipos
Evaluar únicamente gigabits por segundo puede ocultar otra limitación: paquetes por segundo (pps). Un equipo procesa muchos más encabezados para transportar la misma cantidad de bits cuando los paquetes son pequeños.
Switches, routers y firewalls pueden tener límites distintos de throughput en bits, tasa de reenvío, sesiones simultáneas, nuevas conexiones por segundo, tamaño de tablas, inspección criptográfica y funciones habilitadas. Un datasheet debe interpretarse en el contexto de la función que desempeñará el equipo.
Funciones como ACL, NAT, VPN, IDS/IPS, inspección L7, telemetría y QoS pueden modificar el rendimiento efectivo según la arquitectura de la plataforma. Por ello, el dimensionamiento debe considerar la configuración real prevista y no solo la cifra comercial más alta publicada.
Throughput TCP, RTT y Bandwidth-Delay Product
El rendimiento de una transferencia TCP depende de la interacción entre la capacidad de la ruta, RTT, pérdida, ventana de recepción, congestion control y capacidad de los hosts.
El Bandwidth-Delay Product (BDP) expresa la cantidad de datos que puede estar «en vuelo» en una ruta: aproximadamente la capacidad de la ruta multiplicada por el RTT. En enlaces de alta capacidad y gran RTT, una ventana pequeña puede impedir que una única sesión utilice todo el ancho de banda disponible.
Esto explica por qué una prueba entre dos hosts cercanos puede saturar un enlace, mientras la misma aplicación entre continentes entrega una tasa mucho menor incluso sin congestión local.
La RFC 6349 propone una estructura específica para pruebas de throughput TCP y refuerza que evaluar únicamente la capacidad nominal no es suficiente.
QoS: la Prioridad No Crea Ancho de Banda
Quality of Service organiza el tratamiento del tráfico cuando existe contención. Clasificación, marcado, colas, scheduling, policing y shaping permiten diferenciar flujos según los requisitos.
El artículo ¿Qué Es QoS? profundiza en los mecanismos, pero un principio debe quedar claro: QoS no crea capacidad adicional. Decide cómo se distribuirá la capacidad limitada durante los períodos de competencia.
Clasificación y Marcado
La política debe identificar clases con significado operativo. Voz, video interactivo, aplicaciones de control, tráfico corporativo, backup y actualizaciones no deben clasificarse únicamente por conveniencia técnica; la clasificación debe reflejar requisitos de servicio.
El campo DSCP puede transportar una marca, pero esta solo produce efecto si los equipos de la ruta confían en ella y tienen un comportamiento de colas configurado de forma coherente.
Policing y Shaping
Policing limita la tasa y puede descartar o remarcar excedentes. Shaping controla la tasa de salida y normalmente utiliza una cola para suavizar el envío. Son mecanismos diferentes y pueden producir efectos distintos sobre latencia y pérdida.
QoS Debe Validarse Bajo Contención
Probar QoS sin generar competencia entre clases demuestra poco. El escenario de aceptación debe crear carga suficiente para activar las colas y confirmar si el tráfico crítico recibe el tratamiento previsto sin provocar efectos inesperados en las demás clases.
Arquitectura Física y Rendimiento
Una red lógica bien diseñada no compensa deficiencias de la infraestructura física. La capa física debe proporcionar margen, integridad de señal, enlaces compatibles y alimentación estable.
Cableado Estructurado
Deficiencias de instalación, conectores, diafonía, pérdida de retorno, longitud inadecuada, curvatura o interferencia pueden introducir errores y retransmisiones. Un enlace Ethernet que «sube» no queda automáticamente validado para la categoría y aplicación previstas.
La certificación del cableado debe demostrar los parámetros aplicables al enlace. La infraestructura también debe organizarse para permitir identificación, mantenimiento y expansión sin intervenciones improvisadas.
Fibra Óptica y Uplinks
En backbones, el diseño debe considerar la capacidad actual, crecimiento, tipo de óptica, presupuesto de potencia, distancia, redundancia y posibilidad de expansión. Un backbone subdimensionado se convierte en un cuello de botella compartido por todos los servicios conectados a él.
Alimentación, UPS y Protección
La calidad de energía no modifica directamente el throughput, pero influye en la estabilidad operativa de los equipos. Reinicios, fuentes degradadas, fallas intermitentes o pérdida de equipos de distribución pueden ser percibidos por los usuarios como problemas de red.
En entornos críticos, la alimentación redundante, UPS, protección contra sobretensiones, puesta a tierra y supervisión deben formar parte del análisis de disponibilidad de la infraestructura.
Wi-Fi: el Rendimiento Depende del Airtime
En Ethernet full-duplex conmutada, cada enlace dispone de capacidad dedicada según su tecnología. En Wi-Fi, múltiples clientes comparten el medio radioeléctrico. Por ello, la velocidad de asociación mostrada por un cliente no representa el throughput disponible para todos los usuarios.
El diseño debe considerar cobertura, SNR, interferencia, reutilización de canales, ancho de canal, cantidad de clientes, airtime, retries, roaming y perfil de las aplicaciones.
Un Cliente Lento Puede Consumir Tiempo de Radio
Un cliente que opera con una modulación más robusta y una tasa física menor puede necesitar más airtime para transmitir la misma cantidad de datos. Por ello, el rendimiento Wi-Fi debe analizarse como la utilización de un recurso compartido en el tiempo, no solo como «cuántos Mbps soporta el AP».
Más Potencia No Significa una Mejor Red
Aumentar indiscriminadamente la potencia puede ampliar la superposición de celdas y la interferencia co-canal. El diseño debe equilibrar AP y cliente, geometría de las celdas y reutilización espectral.
La capa inalámbrica debe dimensionarse a partir de la demanda y no únicamente de la existencia de señal.
Segmentación, Broadcast y Multicast
La segmentación mediante VLAN y subredes reduce dominios de broadcast, separa funciones y crea límites para las políticas. Sin embargo, crear demasiadas VLAN o hacerlo sin una arquitectura también aumenta la complejidad de operación y enrutamiento.
El artículo sobre Segmentación de Red aborda los criterios de aislamiento. Para el rendimiento, el punto central es garantizar que cada dominio tenga tamaño, tráfico y rutas coherentes con su función.
El broadcast innecesario puede consumir recursos de hosts y enlaces. El multicast, por su parte, puede ser extremadamente eficiente cuando está bien diseñado, pero puede producir flooding si mecanismos como IGMP snooping y el enrutamiento multicast aplicable no son coherentes con la topología.
Los entornos con videovigilancia, AV over IP, descubrimiento de dispositivos, IoT o automatización deben mapear estos flujos explícitamente.
Enrutamiento, Redundancia y Convergencia
La redundancia lógica influye en el rendimiento durante condiciones normales y, especialmente, durante fallas. El diseño de OSPF y BGP debe considerar no solo reachability, sino también política, convergencia, rutas alternativas y capacidad residual después de la pérdida de un enlace.
Una red puede operar con un 40% de utilización en cada una de dos rutas y alcanzar un 80% o más cuando una falla. Por lo tanto, la capacidad en escenario degradado debe analizarse antes de afirmar que la arquitectura es redundante.
El artículo sobre Estructuras de Direccionamiento y Enrutamiento en Redes IP profundiza en sumarización, gateways, ECMP, enrutamiento asimétrico y criterios de diseño.
El Papel de los Hosts y las Aplicaciones
No todas las limitaciones están en la red. El host puede limitar el rendimiento por CPU, memoria, storage, driver, NIC, interrupciones, offload, buffers o configuración del sistema operativo.
En la capa de aplicación, sesiones cortas, baja concurrencia, polling excesivo, serialización de operaciones, cifrado, una base de datos lenta o un servidor saturado pueden producir «lentitud» incluso cuando la red entrega baja latencia y ausencia de pérdida.
Por ello, las pruebas deben separar al menos tres hipótesis:
- la ruta de red está limitando la transferencia;
- el host o servidor está limitando la transferencia;
- la aplicación está limitando la experiencia percibida.
Una medición sintética de red entre endpoints controlados ayuda a separar estas capas.
Sobrecarga Sincrónica y Eventos Masivos
Algunos eventos generan demanda simultánea a gran escala. Tras el restablecimiento de la energía, por ejemplo, cientos de dispositivos pueden reiniciarse, solicitar DHCP, resolver DNS, autenticarse, sincronizar la hora, descargar configuración, reconectarse a servidores e iniciar actualizaciones casi al mismo tiempo.
Del mismo modo, una tarea programada puede iniciar backups o actualizaciones en gran cantidad de hosts en el mismo minuto. Este comportamiento produce una carga muy diferente del promedio diario.
El diseño debe considerar simultaneidad, no solo el consumo medio. La distribución temporal, caché, limitación de tasa y programación de tareas pueden reducir picos evitables.
Las tormentas de broadcast también pertenecen a esta categoría de eventos amplificados. Mecanismos como storm control, segmentación y protección de capa 2 ayudan a limitar el radio de impacto.
Baseline: Medir Antes de Cambiar
El baseline registra cómo se comporta la red en una condición conocida. Sin una referencia anterior, resulta difícil determinar si una determinada latencia, utilización o volumen de errores es nuevo o estructural.
Un baseline útil registra diferentes períodos y condiciones:
- horarios pico y valle;
- días hábiles y ventanas de mantenimiento;
- tráfico por enlace y por clase;
- RTT entre puntos representativos;
- pérdida y jitter;
- errores y descartes de interfaz;
- CPU y memoria de los equipos;
- utilización de WAN e internet;
- comportamiento de Wi-Fi;
- principales flujos y aplicaciones.
El baseline no es una fotografía permanente. Cambios de usuarios, aplicaciones, cloud, cámaras, telefonía, backups e integraciones modifican la demanda y exigen actualizar las referencias.
Antes de aumentar el ancho de banda, sustituir equipos o modificar políticas, es necesario establecer el estado real de la red y separar las limitaciones estructurales de eventos puntuales.
La Due Diligence Técnica consolida inventario, topología, capacidad, baseline, dependencias y evidencias para orientar decisiones de modernización basadas en datos.
Medición Pasiva, Activa y Captura de Paquetes
Los métodos de observación responden preguntas diferentes.
| Método | Ejemplo | Ventaja | Limitación |
| pasivo | SNMP, telemetría, logs | observa la producción de forma continua | puede tener baja granularidad temporal |
| flujo | NetFlow/IPFIX | identifica conversaciones y volumen | no muestra todo el contenido del paquete |
| activo | ping, probes, pruebas sintéticas | mide la ruta de forma controlada | genera tráfico de prueba |
| throughput | iperf o método equivalente | mide la capacidad práctica entre endpoints | depende de los hosts y parámetros de la prueba |
| captura | packet capture | detalla sesiones, retransmisiones y timing | requiere un punto de captura correcto y análisis especializado |
El método debe elegirse según la hipótesis investigada. No tiene valor capturar millones de paquetes sin saber qué comportamiento se desea demostrar.
Cómo Estructurar una Prueba de Throughput
Una prueba de throughput debe registrar premisas suficientes para poder reproducirse. Un resultado sin contexto tiene poco valor de ingeniería.
Deben definirse:
- endpoints y capacidad de sus interfaces;
- ruta física y lógica;
- dirección de la prueba;
- cantidad de flujos simultáneos;
- protocolo de transporte;
- duración;
- carga concurrente existente;
- MTU y parámetros relevantes;
- CPU y recursos de los hosts;
- métricas observadas en los equipos intermedios;
- criterio de aceptación.
En TCP, RTT, ventana y pérdida influyen fuertemente en el resultado. En UDP, es necesario observar la tasa ofrecida, la efectivamente recibida, jitter y pérdida.
La RFC 2544 es históricamente importante para benchmarking de dispositivos de interconexión, mientras que la RFC 6349 proporciona una estructura orientada a pruebas de throughput TCP. El método elegido debe corresponder al objeto de la prueba; no debe aplicarse un procedimiento de laboratorio a una red de producción sin adaptar premisas y riesgos.
Las mediciones de rendimiento deben planificarse con endpoints, método, carga, duración y criterios de aceptación definidos antes de la ejecución.
Los Ensayos y Pruebas Técnicas transforman estas premisas en procedimientos reproducibles y evidencias comparables para diagnóstico, validación y aceptación.
Rendimiento en Escenario Normal y de Falla
Aceptar una red únicamente en condiciones normales puede ocultar insuficiencia de capacidad. Los sistemas redundantes también deben probarse tras la pérdida controlada de elementos previstos en el diseño.
Ejemplos:
- pérdida de un uplink agregado;
- falla de un miembro LACP;
- indisponibilidad de un switch de distribución;
- failover de firewall;
- cambio de gateway activo;
- pérdida del enlace WAN principal;
- reconvergencia de enrutamiento;
- transferencia de servicios entre nodos.
El requisito debe indicar qué servicio debe continuar, con qué capacidad mínima y qué degradación es aceptable. «Tener redundancia» es una descripción arquitectónica, no un criterio de rendimiento.
Arquitectura de Red de Alto Rendimiento
Los ajustes puntuales pueden mejorar una red existente, pero no compensan indefinidamente una arquitectura subdimensionada. El rendimiento sostenible es el resultado de decisiones coordinadas sobre capacidad, topología, segmentación, enrutamiento, QoS, redundancia y operación.
El rendimiento sostenible debe definirse en el diseño: capacidad, rutas, QoS, redundancia, crecimiento y comportamiento ante fallas deben partir de requisitos medibles.
El Diseño de Red Lógica transforma estas premisas en arquitectura y criterios técnicos de aceptación.
Conozca el servicio de Diseño de Red Lógica y Redes Corporativas
Dimensionar la Ruta, No Solo el Puerto de Acceso
Si los usuarios disponen de puertos de 1 Gb/s, eso no significa que cada usuario necesite 1 Gb/s simultáneo hasta internet. Tampoco significa que un uplink de 1 Gb/s sea suficiente para decenas de puertos simplemente porque «nadie usa todo».
El dimensionamiento debe modelar agregación y simultaneidad según el perfil real de tráfico. La videovigilancia continua, storage, backup, voz, navegación y aplicaciones SaaS presentan comportamientos distintos.
Capacidad de Crecimiento
La reserva de capacidad debe considerar crecimiento y escenarios de cambio. Una arquitectura que opera permanentemente cerca del límite tiene poco margen para fallas, nuevos sistemas o picos no previstos.
El margen adecuado depende de la criticidad y de la facilidad de expansión, por lo que debe definirse como una decisión de diseño y no como un porcentaje universal.
Documentación Técnica y Rendimiento
La documentación reduce el tiempo de diagnóstico porque convierte la red en un sistema comprensible. El Diagrama de Red debe mostrar rutas y dependencias relevantes para el análisis de rendimiento.
Según el tamaño, el paquete documental debe incluir:
- diagramas físicos y lógicos;
- capacidad nominal de los enlaces;
- matriz de uplinks y agregaciones;
- VLAN, subredes y gateways;
- política de enrutamiento;
- clases y políticas de QoS;
- redundancia y escenarios de failover;
- inventario de activos e interfaces;
- baseline y criterios de rendimiento;
- puntos de medición;
- resultados de pruebas y evidencias;
- estado As-Built.
Sin esta base, una modificación aparentemente simple puede trasladar el cuello de botella a otro punto o eliminar la redundancia sin que el equipo lo advierta.
Rendimiento vs. Estabilidad: Cómo Separar los Objetivos
Rendimiento pregunta si la red entrega la capacidad y la calidad necesarias bajo condiciones definidas. Estabilidad pregunta si ese comportamiento se mantiene en el tiempo sin fallas, flaps, caídas o variaciones anormales.
Cuando el problema ya existe y el objetivo es localizar la causa de lentitud, pérdida, Wi-Fi inestable, uplink saturado o falla intermitente, el contenido complementario es Estabilidad y Rendimiento de Red: diagnóstico, causas y corrección. Aquí, el foco permanece en la ingeniería de métricas, capacidad y criterios de diseño.
Errores Comunes en Ingeniería de Rendimiento
| Error | Consecuencia |
| considerar la velocidad del puerto como rendimiento de extremo a extremo | expectativa incompatible con la ruta real |
| observar únicamente el promedio de utilización | los microbursts y descartes pueden quedar invisibles |
| medir throughput sin registrar RTT, pérdida y parámetros | resultado no reproducible |
| probar únicamente condiciones normales | la capacidad insuficiente durante una falla queda oculta |
| aplicar QoS sin una política de extremo a extremo | las marcas y colas no producen el comportamiento esperado |
| ignorar pps y tamaño de los paquetes | el equipo puede saturarse antes del límite en bit/s |
| tratar Wi-Fi como Ethernet inalámbrica | airtime, retries e interferencia quedan fuera del diseño |
| culpar a la red sin aislar host y aplicación | cambio de infraestructura sin resolver la causa |
| operar sin baseline | no existe referencia para comparar la degradación |
| aceptar redundancia por inspección visual | el failover puede existir en el diagrama y fallar en producción |
Criterios de Aceptación de Rendimiento
Los criterios de aceptación deben ser objetivos, medibles y vinculados a las aplicaciones. En lugar de «red de alto rendimiento», el diseño debe definir qué se medirá, entre qué puntos, en qué condición y qué resultado es aceptable.
Una matriz de aceptación puede adoptar la siguiente estructura:
| Requisito | Método | Escenario | Evidencia |
| throughput entre puntos críticos | prueba activa controlada | carga normal | informe de prueba e interfaces |
| latencia/RTT | probe sintética | normal y pico | serie temporal |
| jitter y pérdida | prueba activa | flujo sensible | resultado por dirección |
| capacidad del uplink | telemetría + carga | pico previsto | utilización, colas y drops |
| QoS | tráfico concurrente por clases | contención | colas, marcas y pérdida por clase |
| failover | retirada controlada de un elemento | falla prevista | tiempo y comportamiento de la aplicación |
| Wi-Fi | survey y prueba de capacidad | ocupación representativa | cobertura, retries, airtime y throughput |
Los valores numéricos no deben copiarse de una tabla genérica. Deben derivar de los requisitos de voz, video, control, sistemas corporativos, storage, cloud y demás servicios efectivamente utilizados.
Puesta en Marcha y Evidencia de Rendimiento
La puesta en marcha transforma los requisitos en evidencia de que la instalación entregada funciona conforme al diseño. En el contexto de redes, esto implica más que hacer ping a gateways.
El plan puede combinar:
- certificación de la capa física;
- verificación de topología y configuraciones;
- pruebas de throughput;
- medición de retardo, jitter y pérdida;
- validación de QoS;
- prueba de multicast cuando corresponda;
- failover y convergencia;
- operación en condición degradada;
- verificación del monitoreo y las alarmas;
- registro del baseline de entrega;
- actualización del As-Built.
La red debe pasar del diseño a la operación con criterios, documentación y métricas que permitan comparar el rendimiento futuro con el estado aceptado.
La aceptación de rendimiento debe demostrar el comportamiento de la red en condiciones normales y en los escenarios de falla previstos, con resultados trazables y repetibles.
La Puesta en Marcha de Ingeniería integra pruebas, evidencias, pendientes y documentación As-Built antes de la entrada definitiva en operación.
Consideraciones Finales
El rendimiento de red no es sinónimo de un enlace rápido. Es el resultado medible de la interacción entre capacidad, colas, protocolos, arquitectura física y lógica, hosts y aplicaciones.
Una buena ingeniería comienza por los requisitos de servicio, convierte esos requisitos en capacidad y comportamiento esperados, mide la ruta con métodos reproducibles y prueba escenarios normales y degradados. Throughput, latencia, jitter y pérdida dejan de ser cifras aisladas y pasan a formar parte de los criterios de decisión y aceptación.
Cuando baseline, observabilidad, diseño y puesta en marcha permanecen conectados, la organización puede distinguir crecimiento legítimo de la demanda, cuellos de botella estructurales, fallas de configuración y limitaciones de la propia aplicación — y puede planificar la expansión antes de que se deteriore la experiencia del usuario.
Referencias Técnicas
[1] IETF. RFC 2544 — Benchmarking Methodology for Network Interconnect Devices. Disponible en: [https://www.rfc-editor.org/rfc/rfc2544](https://www.rfc-editor.org/rfc/rfc2544).
[2] IETF. RFC 2681 — A Round-trip Delay Metric for IPPM. Disponible en: [https://www.rfc-editor.org/rfc/rfc2681](https://www.rfc-editor.org/rfc/rfc2681).
[3] IETF. RFC 3393 — IP Packet Delay Variation Metric for IP Performance Metrics (IPPM). Disponible en: [https://www.rfc-editor.org/rfc/rfc3393](https://www.rfc-editor.org/rfc/rfc3393).
[4] IETF. RFC 6349 — Framework for TCP Throughput Testing. Disponible en: [https://www.rfc-editor.org/rfc/rfc6349](https://www.rfc-editor.org/rfc/rfc6349).
[5] IETF. RFC 9293 — Transmission Control Protocol (TCP). Disponible en: [https://www.rfc-editor.org/rfc/rfc9293](https://www.rfc-editor.org/rfc/rfc9293).
[6] IETF. RFC 2474 — Definition of the Differentiated Services Field in the IPv4 and IPv6 Headers. Disponible en: [https://www.rfc-editor.org/rfc/rfc2474](https://www.rfc-editor.org/rfc/rfc2474).
[7] IETF. RFC 3246 — An Expedited Forwarding PHB (Per-Hop Behavior). Disponible en: [https://www.rfc-editor.org/rfc/rfc3246](https://www.rfc-editor.org/rfc/rfc3246).
[8] ITU-T. Y.1540 — Internet protocol data communication service — IP packet transfer and availability performance parameters. Disponible en: [https://www.itu.int/rec/T-REC-Y.1540/en](https://www.itu.int/rec/T-REC-Y.1540/en).
[9] ITU-T. Y.1541 — Network performance objectives for IP-based services. Disponible en: [https://www.itu.int/rec/T-REC-Y.1541/en](https://www.itu.int/rec/T-REC-Y.1541/en).
Preguntas Frecuentes
Bandwidth, o capacidad nominal, representa el límite tecnológico del enlace. Throughput es la tasa efectivamente transferida en la ruta y puede ser menor por overhead, contención, pérdida, retransmisión, limitaciones del host o procesamiento intermedio.
Throughput contabiliza el volumen efectivamente transportado. Goodput considera únicamente los datos útiles entregados a la aplicación, excluyendo retransmisiones y overhead que no forman parte del contenido útil.
No. La latencia mide retardo; el jitter mide la variación de ese retardo a lo largo del tiempo. Una red puede presentar una latencia media aceptable y aun así perjudicar aplicaciones en tiempo real si la variación es elevada.
Sí. Los microbursts pueden saturar una interfaz durante períodos muy breves y provocar colas o descartes sin aparecer en promedios agregados de varios minutos.
No. QoS organiza cómo se distribuye la capacidad disponible durante la contención. Puede proteger tráfico sensible, pero no crea ancho de banda adicional.
RTT, pérdida, ventana de transporte y mecanismos de congestion control influyen en la tasa. En rutas con alto bandwidth-delay product, una única sesión puede no llenar el enlace si las ventanas y el comportamiento del transporte no son adecuados.
Defina endpoints, ruta, dirección, protocolo, duración, carga concurrente, parámetros de prueba y criterio de aceptación. Correlacione throughput con latencia, pérdida, colas, recursos de los hosts y métricas de los equipos intermedios.
No. El rendimiento evalúa capacidad y calidad bajo condiciones definidas. La estabilidad evalúa si ese comportamiento se mantiene a lo largo del tiempo sin fallas, flaps o variaciones anormales.
Materiales Técnicos Complementarios
Servicios Relacionados
- Diseño de Red Lógica y Redes Corporativas
- Due Diligence Técnica de Ingeniería
- Ensayos y Pruebas Técnicas
- Puesta en Marcha de Ingeniería
Contenidos Principales sobre el Tema
- Tráfico de Red: flujos, carga, broadcast, multicast y capacidad
- Monitoreo de Red: métricas, disponibilidad, rendimiento y observabilidad
- NetFlow: qué es, cómo funciona y cómo analizar tráfico de red
- Gestión de Redes: FCAPS, SNMP, configuración, rendimiento y seguridad
- Estabilidad y Rendimiento de Red: diagnóstico, causas y corrección
Contenidos Técnicos Relacionados
- Red Lógica: VLAN, IP, enrutamiento, segmentación y diseño
- Segmentación de Red: fundamentos, modelos, buenas prácticas y cuándo utilizarla
- Estructuras de Direccionamiento y Enrutamiento en Redes IP
- Diagrama de Red: tipos, arquitectura lógica y física y documentación técnica
- Guía Completa sobre Arquitectura de Redes
- NetBox como Fuente de Verdad para Infraestructura, Redes, IPAM, DCIM y Automatización
