En la resolución de problemas de red, a veces es necesario observar el comportamiento del tráfico de manera directa. Generar tráfico parecería una tarea simple: transfiera un archivo muy grande de un lugar a otro o abra un video en el navegador. Sin embargo, generar tráfico con ciertas condiciones a veces no es tan fácil, por ejemplo generar cierta cantidad de ancho de banda (p. ej.: 1Mbps), o generarlo durante cierta cantidad de tiempo. Peor aún, si queremos saber cuántos paquetes se envían y cuántos llegan, como sabemos TCP o las aplicaciones se encargan de que no perdamos información, por ende saber exactamente qué pasa con los paquetes es un poco más complejo. Cuando estudiamos o trabajamos en redes a veces es necesario generar tráfico. En ésta entrada les voy a dar un par de ideas al respecto, sin embargo, me enfocaré en una herramienta gratuita de fácil uso llamada IPerf. Disfrútenlo.
Introducción: pruebas de entrega de servicios
En el estudio de redes, sobre todo al principio, hay muchos conceptos que no son claros: ancho de banda, QoS, pérdidas, encolamiento y descarte de paquetes, etc.. A veces, a la hora de hacer disgnóstico de fallos (troubleshooting) también nos gustaría generar tráfico para poder observar cómo está pasando por la red y qué está pasando desde el punto de vista de los dispositivos finales. Existen dos alternativas para atacar estos problemas, nosotros como ingenieros podemos probar fácilmente con algunas herramientas como la que describo en esta entrada, de otro lado para los jefes o quienes contratan es más común hacer pruebas estrictas con costosos equipos de medición que certifiquen los resultados.
Antes de revisar la herramienta hablemos un poco de herramientas profesionales. Entregar un servicio implica certificar que sí cumple con las características que el cliente contrató, es decir, ancho de banda, QoS, tiempos de respuesta (delay, jitter), pérdida de paquetes, etc.. Los carriers, que son los operadores de redes físicas metropolitanas están acostumbrados a hacer este tipo de pruebas de entrega, a ellos se les piden circuitos de un punto a otro de la ciudad/región y ellos lo configuran usando sus fibras y equipos de transporte al estilo de lo que solíamos llamar una leased-line, hoy en día las llamamos E-LINE, Pseudowire o E-LAN dependiendo del tipo de servicio. Una vez configurado y seleccionados los medios de los extremos (tipo de fibra, conectores, etc), se ofrece una prueba de desempeño. Éstas pruebas usualmente se les llama RFC, en realidad es la prueba RFC2544 o alguna variante. Esta prueba ya está un poquito en desuso dado que es un poco rústica y poco granular. En ella se inyecta tráfico de un extremo al otro del circuito, una de las dos puntas refleja el tráfico inyectado y el equipo de medición imprime las estadísticas en un informe que da cuenta del estado del enlace y si se ajusta o no al SLA contratado. La prueba RFC hace generalmente cuatro pruebas básicas: ancho de banda máximo, pérdida de paquetes, jitter/delay y una prueba llamada back-to-back. La sucesora de facto de la prueba RFC2544 es la EtherSAM (service activation methodology) o Y1564. Como ven en la prueba RFC2544 sólo se inyecta tráfico en un sólo flujo y se hacen mediciones básicas como si el circuito fuera sólo un tubo, actualmente los servicios que se transportan son más importantes y pueden ser diferenciados. La prueba Y1564 permite inyectar varios flujos y configurar sus características de puertos y banderas de QoS, de esa manera la evaluación incluirá en una sola prueba diferentes servicios.
Para realizar las mediciones descritas en el párrafo anterior se utilizan unos equipos de medición muy sofisticados y costosos. Yo generalmente he usado la marca JDSU actualmente llamada VIAVI pero existen muchos fabricantes. La marca mencionada es la más común aunque también es una de las más costosas. Hacer una prueba RFC parecería fácil pero en la práctica es un poco complejo dado que se tienen que cumplir características físicas como el tipo de conector, fibra, potencia de los haces de luz cuando se hace con fibra óptica; luego se deben cumplir condiciones del enlace como la autonegociación, que el circuito levante a nivel de capa dos contra el equipo de medición, puede ser necesario hacer un loop físico en el otro extremo, se puede hacer lógico y hay que saber configurarlo, etc. Adicionalmente también es necesario que al despliegue del servicio ya haya sido coordinado, es decir, que el puerto origen y destino sí tengan la configuración necesaria para transportar transparentemente el tráfico de extremo a extremo de la red. A mí me pasó cuando me pidieron una prueba RFC que no tenía ni idea qué querían y aún hoy sudo petróleo cuando me ponen a hacer una de esas porque el circuito puede ser complejo y tiene que servir estrictamente como un enlace capa 2. En teoría quien ejecuta la prueba puede (y debería) ser sólo un técnico y las condiciones del servicio y configuraciones deben estar ya configuradas y a cargo de un ingeniero de soporte de nivel superior, pero a veces no es así porque requieren alguien que conozca varias capas del servicio y que coordine mejor las actividades.
En la entrega del servicio se podría usar IPerf, pero ésta no es una herramienta profesional y no serviría para certificar la respuesta del circuito. Ya en un contexto más relajado, nuestro estudio, iPerf es una excelente herramienta para generar tráfico y observar la respuesta de la red.
¿Qué es IPerf?
IPerf es un pequeño programa generador de tráfico a nivel de capa 3 y 4 de la capa OSI, es decir, genera segmentos TCP o datagramas UDP entre dos hosts (tenemos que tener control sobre ambos y conocer sus IP). Es tan simple como generar un flujo de datos de cualquier tipo entre dos extremos.
El programa en cuestión funciona en la línea de comando de Windows o Linux (no lo he probado en otras plataformas). Los dos extremos deben contar con el ejecutable que es un programa muy pequeño, de un lado se inicia con una bandera de «servidor» que sólo refleja los paquetes recibidos y muestra las estadísticas, del otro lado se ejecuta el «cliente» que es quien realmente genera el tráfico, en ambos casos el programa es el mismo, sólo se ejecuta con diferentes opciones. La aplicación permite variar parámetros de la comunicación: ancho de banda enviado, duración de la prueba, protocolo de capa 4 (tcp/udp), incluso se le pueden establecer banderas de QoS o de fragmentación, lo cual puede ser muy útil para casos complejos de diagnóstico.
¿Cómo se usa?
Dependiendo de la plataforma que usemos descargamos el binario de https://iperf.fr/iperf-download.php. Como les he mencionado es un programa muy pequeño que se ejecuta en línea de comandos. En el caso de Linux se requieren permisos administrativos dado que todas las versiones son paquetes instaladores, es decir, son RPM o pkg o la utilidad de paquetería que tenga la distribución. En el caso de Windows con sólo descomprimirlo basta.
Cuando usamos IPerf hay que tener claros varios conceptos. Recuerden que UDP es un protocolo no confiable, lo cual significa que no hay retransmisión de paquetes y el ancho de banda enviado es constante. De otro lado TCP es un protocolo muy sofisticado que tiene el mecanismo de ventana deslizante, por lo tanto la tasa de transferencia intenta adaptarse a la capacidad del medio, de hecho el mecanismo de adaptación de TCP cuenta con que se pierdan paquetes para encontrar la capacidad disponible. Estas dos grandes diferencias hacen que los protocolos se usen de manera diferente en cada prueba. Una prueba de ancho de banda debería usar paquetes UDP dado que éste envía de manera constante los paquetes sin variar la tasa de envío. Si una candidad de paquetes se envía exitosamente, sin pérdidas, se intenta un valor mayor y así sucesivamente hasta que se empiecen a perder paquetes. La medición seguramente reflejará un valor fiel del ancho de banda del medio. Algunas veces las pruebas con UDP quedan filtradas en firewalls o en algún punto de la red, por lo que no siempre son exitosas a menos que conozcamos perfectamente la red o esté bajo nuestro control.
Como mencioné en párrafos anteriores, en uno de los extremos de la red se ejecuta como servidor, lo cual significa que cuando el cliente se conecte y empiece a enviar tráfico el servidor va a contar los paquetes y sus características y los enviará de regreso si ese es el caso. En windows debes ubicarte donde esté el ejecutable y ejecutar el comando iperf3 -s, Windows sacará la advertencia de que éste programa quiere acceder a la red y debes permitirlo. Para salir del servidor se oprime DOS VECES Ctrl-C. Otra alternativa es usar servidores públicos de iperf, en el caso de América están iperf.scottlinux.com y iperf.he.net, ambos en California, Estados Unidos. Usar los servidores públicos tiene dos problemas: 1) necesitamos acceso a Internet, 2) estos servidores no parecen ser muy robustos y la prueba no se puede realizar con frecuencia.
Para hacer una prueba rápida, ejecuten el comando iperf3 -c iperf.scottlinux.com –get-server-output, el resultado sería el siguiente:
Como se puede observar en la tabla, está dividida por intervalos de 1 segundo y muestra la transferencia en BYTES y el ancho de banda en BITS, entonces el segundo es aproximadamente el primero por 8. El nro de paquetes enviados en cada intervalo depende del tamaño de la ventana. Como mencioné anteriormente, TCP es un protocolo complejo que va a variar el tamaño de la ventana para adaptarse al ancho de banda del medio, por eso vemos la gran variación de principio a fin. Al final, parece que mi enlace tiene 10Mbps dado que eso fue lo que encontró finalmente TCP. Ese comportamiento depende del tamaño de los búferes de los routers en el camino: cuándo se llenan, cuándo descartan un paquete, etc. y ésto va a ocurrir por cada sesión, es decir, teniendo en cuenta direcciones y puertos IP origen/destino. Si repetimos el ejercicio rápidamente la adaptación va a ser más rápida porque los enrutadores en el camino ya tienen un búfer establecido para ésta conexión.
La misma prueba se puede hacer entre dos PC o laptops conectados a un Switch o router. En uno se ejecutaría iperf3 -s y en el otro los comandos descritos anteriormente pero cambiando el nombre de los servidores por la IP del dispositivo que corre el servidor. En mi caso la prueba con udp se queda en el camino, por lo que no les puedo mostrar resultados, pero en el caso de una red simple la prueba udp debería reflejar el ancho de banda exacto del medio.
Una buena forma de observar cómo funciona tcp es generando tráfico mediante IPerf y haciendo una captura con Wireshark (ejecutar como administrador). Como ésta excelente utilidad tiene capacidades de análisis de flujos y filtros para ver sólo cierta conversación de la red, podríamos comparar la cantidad de paquetes generados, observar los paquetes tcp ack y revisar el tamaño de las ventanas durante toda la generación del tráfico. IPerf tiene otras opciones interesantes, como establecer el tamaño de la ventana.
Conclusiones
Aunque empezamos hablando de entrega de servicios, ésta no es una aplicación profesional pero puede servir para entrega de servicios en una red pequeña o para diagnóstico de fallos cuando tengamos que comprobar cómo está funcionando la red desde el punto de vista del usuario. Espero que sea de utilidad y próximamente escribiré más sobre generadores de tráfico. Gracias por leer y por favor comenta y comparte!