Tutorial de iperf3: Medir el rendimiento de la red en Linux y Windows

iperf3 es una herramienta de línea de comandos para medir el ancho de banda de la red, la fluctuación y la pérdida de paquetes entre dos máquinas. Utiliza un modelo cliente-servidor: una máquina escucha, la otra envía tráfico y se obtienen cifras precisas de rendimiento. Esta guía abarca la instalación, pruebas básicas y avanzadas, y cómo ajustar el sistema para obtener resultados precisos en enlaces de alta velocidad.

Instalación de iperf3

Debian / Ubuntu

sudo apt update
sudo apt install iperf3

Confirma la instalación con iperf3 --version. Instálalo tanto en el servidor como en los equipos cliente.

Fedora / CentOS / Rocky / Alma

En Fedora 22+ o CentOS 8+, Rocky o AlmaLinux:

sudo dnf install iperf3

En CentOS 7, utilice yum en su lugar. Si no encuentra el paquete, habilite primero el repositorio EPEL:

sudo yum install epel-release
sudo yum install iperf3

Si su cortafuegos está activo, abra el puerto 5201:

sudo firewall-cmd --add-port=5201/tcp --permanent
sudo firewall-cmd --reload

Windows

Descarga el ejecutable independiente desde iperf.fr o el repositorio de GitHub ar51an/iperf3-win-builds. Descomprímelo en una carpeta como C:\iperf3, y luego comprueba:

cd C:\iperf3
iperf3.exe -v

Para ejecutar iperf3 desde cualquier directorio, añade la carpeta a la ruta de acceso del sistema (PATH) a través de Propiedades del sistema > Avanzadas > Variables de entorno. También tendrás que crear una regla de firewall de entrada que permita el tráfico TCP en el puerto 5201 en el Firewall de Windows Defender.

Configuración del servidor

Inicie el servidor con:

iperf3 -s

Esto escucha en el puerto TCP 5201 de forma predeterminada. Para ejecutarlo en segundo plano con registro:

iperf3 -s -D --logfile /var/log/iperf3.log

Comprueba que se está ejecutando con ss -tulpn | grep 5201.

Si el puerto 5201 está bloqueado en tu red, utiliza -p para elegir un puerto diferente. Para vincularlo a una interfaz específica, utiliza -B:

iperf3 -s -B 192.168.1.10

Para pruebas puntuales, iperf3 -s -1 gestiona una única conexión de cliente y luego se cierra. En enlaces de gran ancho de banda (40 Gbps+), ejecuta varias instancias del servidor en diferentes puertos para sortear los límites de la CPU de un solo subproceso.

Asegúrate de que tu cortafuegos permite el tráfico en el puerto elegido. En Ubuntu/Debian con UFW:

sudo ufw allow 5201/tcp
sudo ufw allow 5201/udp   # if testing UDP

Realización de pruebas de cliente

Prueba TCP básica

iperf3 -c 192.168.1.10

Esto mide el ancho de banda de subida a través de TCP durante 10 segundos. Amplíe la duración con -t:

iperf3 -c 192.168.1.10 -t 30

En enlaces de 10 Gbps o 25 Gbps, un único flujo TCP suele alcanzar un máximo de 3-5 Gbps debido a las limitaciones de las CPU de un solo núcleo. Utilice flujos paralelos para saturar el enlace:

iperf3 -c 192.168.1.10 -P 8

Interpretación de los resultados

Cada línea de intervalo muestra la transferencia (datos enviados) y la velocidad de bits (rendimiento). Para TCP, fíjate también en:

• Retr (retransmisiones). Las cifras elevadas indican pérdida de paquetes o congestión.
• Cwnd (ventana de congestión). Si es baja o se estanca, los límites del tamaño del búfer o de la ventana están limitando el rendimiento.

En un enlace limpio de 1 Gbps, espere alrededor de 940 Mbps tras la sobrecarga del protocolo. La prueba termina con líneas de resumen del emisor y el receptor. En una red estable, estas deberían coincidir estrechamente.

Para las pruebas UDP (-u flag), la salida añade jitter (variación en la llegada de paquetes) y datagramas perdidos/totales. Un jitter inferior a 1 ms y una pérdida del 0 % son ideales para tráfico en tiempo real como el VoIP.

Indicadores útiles

Pruebas avanzadas

Pruebas bidireccionales

La --bidir opción (iperf3 3.7+) prueba la subida y la descarga simultáneamente:

iperf3 -c 192.168.1.10 --bidir

Ambas conexiones se originan en el cliente, por lo que esto funciona a través de NAT sin necesidad de abrir puertos adicionales. Si los resultados bidireccionales son mucho más bajos que los de las pruebas unidireccionales, es posible que tu router o módem por cable tenga dificultades con el tráfico full-duplex.

Modo inverso

La -R indicador invierte el flujo de datos para que el servidor envíe y el cliente reciba. Esto mide la velocidad de descarga sin intercambiar los roles:

iperf3 -c 192.168.1.10 -t 30 -i 5 -R

Las grandes diferencias entre los resultados de avance y retroceso apuntan a rutas asimétricas, congestión o configuraciones incorrectas del búfer.

Pruebas UDP

Las pruebas UDP revelan fluctuaciones y pérdida de paquetes, que TCP oculta tras las retransmisiones. Establece siempre un ancho de banda objetivo con -b, ya que iperf3 utiliza por defecto 1 Mbps para UDP:

iperf3 -c 192.168.1.10 -u -b 1G

Para simular tráfico VoIP (100 llamadas, paquetes de 200 bytes):

iperf3 -c 192.168.1.10 -u -b 8M -l 200

Puntos de referencia de calidad: una fluctuación inferior a 5 ms es buena para VoIP; por encima de 30 ms se producen problemas audibles. Una pérdida de paquetes superior al 0,1 % degrada notablemente los medios en tiempo real.

Ajuste y resolución de problemas

Problemas comunes

¿Solo obtienes 100 Mbps en un enlace gigabit? Comprueba la velocidad de tu interfaz física con ethtool eth0. La negociación automática a veces falla y reduce la velocidad del enlace.

¿El MSS muestra 536 bytes en Ethernet? Probablemente, Path MTU Discovery esté desactivado. El MSS predeterminado para un MTU de 1500 bytes es de 1460 bytes. Utiliza -m durante las pruebas para comprobarlo. Un MSS de 536 bytes desperdicia ancho de banda y añade sobrecarga.

¿La CPU se satura en enlaces rápidos? Utiliza -Z (zerocopy) para reducir la carga de la CPU. Para velocidades superiores a 40 Gbps, ejecuta varias instancias del servidor en diferentes puertos y distribúyelas entre los núcleos de la CPU.

¿Resultados inconsistentes? Utiliza -O 3 para omitir los primeros segundos mientras la ventana de congestión de TCP se amplía. Deja 30 segundos entre ejecuciones de la prueba para vaciar los búferes de red.

¿El flujo único es mucho más lento que los flujos paralelos combinados? Si un flujo alcanza los 200 Mbps pero ocho flujos combinados llegan a 1,6 Gbps, la ventana TCP o los búferes del sistema operativo están limitando el flujo único. Ajuste los búferes a continuación.

Ajuste del búfer TCP

Empieza calculando el producto ancho de banda-retardo (BDP): ancho de banda x RTT. Un enlace de 10 Gbps con un RTT de 50 ms da un BDP de 62,5 MB. Establece tu búfer máximo en al menos el doble del BDP.

Añádelos a /etc/sysctl.d/99-tcp-tuning.conf y aplícalo con sudo sysctl -p:

Mantén net.ipv4.tcp_moderate_rcvbuf establecido en 1 para que el núcleo realice el ajuste automático dentro de estos rangos. Habilita net.ipv4.tcp_window_scaling (establecer en 1) para ventanas TCP mayores de 64 KB.

También puede cambiar del algoritmo de congestión predeterminado CUBIC al BBR de Google. En enlaces de alta latencia con cierta pérdida de paquetes, BBR ofrece sistemáticamente un mayor rendimiento que CUBIC.

Utiliza el -w en iperf3 para probar tamaños de búfer específicos, pero ten en cuenta que no pueden superar el valor de rmem_max o wmem_max. Empieza con 8 MB para enlaces gigabit y 512 KB para 100 Mbps.

Si está aprovisionando servidores dedicados y desea validar el rendimiento de la red, ejecute pruebas de referencia con iperf3 inmediatamente después de la configuración y tras cualquier cambio en la red para detectar regresiones de forma temprana.

Recomendación de vídeo