En este punto, permítanme ante todo una aclaración: la medición de performance está referida inicialmente a la medición de un enlace específico. También podemos medir la performance de una conexión a través de una ruta completa, por ejemplo entre mi terminal y el servidor de Blogger. Pero en este caso el resultado será igual a la performance del enlace de menor capacidad por el cual atraviesa mi ruta hacia Blogger.
Pero entrando específicamente en tema, si vamos a medir performance primero tenemos que aclarar un par de conceptos.
Data Rate y Throughput
Lo primero es tener claro la diferencia entre la tasa de transferencia del enlace (habitualmente denominada "data rate") y la tasa de transferencia efectiva (denominada "throughtput).
El data rate refiere a la capacidad absoluta de un enlace y es función directa de la manera en que modula y codifica la portadora sobre ese enlace. Habitualmente suele medirse en bits/segundo (Mbps, Gbps, etc.).
El data rate establece un límite absoluto para nuestra transmisión: no podemos transmitir mayor cantidad de datos que la definida en el data rate.
El througput en cambio, es la capacidad efectiva de transferencia de datos sobre el enlace. Esta capacidad siempre es menor al data rate ya que en los enlaces, junto con los datos, hay tráfico de negociación, mantenimiento y control del enlace. Esto en sistemas TCP/IP además depende del protocolo de capa de transporte que utiliza la aplicación, que puede ser TCP o UDP. Típicamente una sesión UDP tiene un 20% más de performance que una seción TCP sobre el mismo enlace. En muchos casos (Microsoft, por ejemplo) vamos a encontrar el throughput en Bytes/segundo (KBps, MBps).
Un ejemplo:
En redes inalámbricas (WiFi) solemos encontrar conexiones que están declaradas como de 54 Mbps, sin embargo nunca llegamos a esa cifra cuando realizamos transferencias de archivos.
Esto se debe esencialmente a que el protocolo IEEE 802.11g que implementan las redes WiFi tiene una alta carga de tráfico de management y control, al mismo tiempo que impone tiempos de espera muy altos. A esto súmenle que la mayoría del tráfico que pasa sobre esas redes es TCP.
Si lo vemos en cifras:
- Data rate: 54 Mbps.
- Throughput máximo: Aproximadamente 28 Mbps.
- Throughput de una sesión FTP (TCP): 22,4 Mbps o 2,8 MBps.
¿Cómo medimos el throughput?
A los fines operativos lo que se nos suele requerir es la medición de throughput y para esto lo que necesitamos es generar tráfico sobre el enlace para medir efectivamente cuál es su capacidad.
Existen generadores de tráfico, e incluso podemos configurar un dispositivo (como un router) para que genere tráfico. Pero estas soluciones son costosas y requieren conocimientos avanzados para poder implementarlas.
Hay una solución simple y de muy bajo costo: Iperf.
Se trata de una herramienta open source, muy sencilla de utilizar y que provee la información que habitualmente necesitamos para resolver situaciones en las que la performance es un parámetro que requiere estudio.
Iperf trabaja con una lógica cliente-servidor, por lo que debe ser instalado en terminales que estén en ambos extremos del enlace que se desea medir. Puede generar y medir tanto tráfico TCP como UDP y nos permite definir tamaño de los paquetes, puerto de destino, duración de la medición, etc.
La información que nos brinda es, para la sesión que se está analizando, delay, jitter (variación del delay) y throughput.
Iperf es una herramienta multiplataforma que se ejecuta por línea de comando y nos entrega los resultados en modo texto.
Personalmente prefiero utilizar Jperf. Jperf no es más que un frontend gráfico en Java para facilitar la operación y monitoreo de Iperf. Mi preferencia se debe a que la salida gráfica de los resultados es un elemento útil al momento de tener que presentar informes de performance de los enlaces.
En síntesis: Iperf o Jperf (según los gustos personales, son lo mismo) es una herramienta simple pero poderosa para verificar el throughput, la pérdida de paquetes y el jitter.
Pero una salvedad: La capacidad de generación de tráfico dependerá esencialmente de la CPU y memoria RAM de los equipos que estén corriendo la aplicación. Por eso, es muy eficiente para realizar mediciones sobre enlaces de baja capacidad o inalámbricos. Cuando se trata de medir redes LAN, es posible que la capacidad de las terminales que estemos usando no sea suficiente y debamos buscar equipos con mayor procesamiento.
Recursos
Bibliografía sugerida:
Introducción a Quality of Services - Oscar Gerometta
¿El througput no depende también de la "potencia" del equipo de acceso que transmite? Es decir si yo tengo un acceso por fibra de 100 Mbs y utilizo el 100% no es lo mismo si lo transmito por un equipo de la serie 800 que si lo hago por uno de la serie 3800. ¿No es posible que el equipo más pequeño no tenga capacidad para poder procesar todo el tráfico? Gracias
ResponderBorrarEntiendo que por potencia te referís a capacidad de procesamiento. En términos prácticos en los dispositivos actuales se expresa en capacidad de forwardeo de tráfico en miles (mpps) o millones de paquetes por segundo (Mpps).
ResponderBorrarEsto influye pero de otra forma, ya que depende de la capacidad de procesar la información necesaria para tomar la decisión de forwardeo. Cuando se trata de paquetes pequeños (p.e. tráfico de voz) esto reducirá el volumen total de información reenviada y en este sentido puede impactar en el throughput.
Pero esto es una unidad de medición de la capacidad del equipo, no de los enlaces. Si se satura el equipo, se producirá dropeo de paquetes en la interfaz de entrada; si se satura la capacidad de un enlace se produce dropeo de paquetes en la interfaz de salida.
Son problemas diferentes, si bien ambos están vinculados a la performance que ofrece nuestra red.
Yo lo decía más que nada por ejemplo por este artículo http://librosnetworking.blogspot.com/2011/08/la-familia-de-firewalls-cisco-asa-5500.html Aquí hablas de througput máximo en función del equipo pero no hablas de los enlaces. Sin hablar de los enlaces ya se tiene calculado el límite del equipo.
BorrarDe acuerdo. En ese caso, hablando de equipos, hay un throughput máximo por equipo, ya que se trata de firewalls que pueden hacer inspección de contenido. Por lo que además de la capacidad máxima de cada enlace y la capacidad de forwardeo de paquetes, también hay una capacidad de procesamiento de contenidos cuando se activa la función de inspección que hay que tener presente.
ResponderBorrarPero estamos en lo mismo, se trata de capacidad del equipo y la medición de la que hablo en este post es capacidad de los enlaces.
En equipos de nivel enterprise es de suponer que la capacidad máxima del equipo sea mayor que la de uno de sus enlaces. Aunque puede ocurrir que no alcance a la sumatoria de la capacidad de todos los enlaces posibles, sobre todo cuando tiene muchas interfaces.
De acuerdo, muchas gracias.
ResponderBorrarITG sirve para lo mismo y es muy sencillo
ResponderBorrarMuy buen articulo, como siempre!!
ResponderBorrarHago una consulta, como podemos medir el ancho de banda consumido en un enlace en producción?. Se pueden usar las estadisticas (logs) de los switch de ambos extremos (Total Bytes) en un intervalo de tiempo determindo?
Gracias!!
Para medir tráfico efectivo en interfaces, la solución es implementar NetFlow.
BorrarBuenos días:
ResponderBorrarQuisiera consultarle acerca del throughput que soporta un dispositivo de red:
a. ¿Existe manera de conocer o estimar la cantidad de trafico que fluye a través del equipo? Esto entendiendo porsupuesto que el equipo tiene una capacidad máxima permitida. ¿que sucede con el resto del trafico si hay exceso se descarta?
b.¿ Existen herramientas que para efectos de diseño sirvan para establecer este dimensionamiento?
Estas consultas se las hago en razón de que queremos establecer un plan de capacidades y estos elementos no los tenemos claros.
De antemano muchas gracias...!!!!
Carlos
BorrarLos dispositivos de red de tipo enterprise (la mayoría de ellos) tienen documentada la capacidad máxima de tráfico que están en capacidad de soportar a partir de la ralización de tests de benchmark que son publicados periódicamente y que consta en la hoja técnica de cada equipo.
La capacidad efectiva en una situación real dependerá de la configuración del equipo y por lo tanto debe ser medida en cada caso. Pero en esa situación generalmente medimos la performance de una ruta y no de un dispositivo, ya que en cada caso la capacidad máxima de la ruta dependerá de los potenciales cuellos de botella que se encuentren en su recorrido, y no de la capacidad individual de cada equipo.
Lo que ocurrirá con el tráfico excedente depende también de la configuración de los equipos, ya que en términos generales en muchos equipos es posible hacer buffering del tráfico excedente hasta el límite de memoria, y a partir de allí se descartará. Pero esto dependerá siempre de la configuración.
Finalmente, si, hay herramientas de diseño para estimar el requerimiento de ancho de banda, pero en todos los casos son orientativas. Es fundamental el conocimiento y expertisse del diseñador para estimar de modo que se acerque a la realidad que luego encontrará la red.
Muchas gracias por su pronta respuesta Sr. Oscar:
BorrarAhora quisiera hacerle una consulta adicional. En mi organización tenemos un Firewall cuyas interfaces monitoreamos constantemente por lo cual conocemos el trafico que ingresa y sale de cada interfaz. En razón de eso, como podríamos establecer qué cantidad de tráfico circula por el equipo en un momento dado? Sería sumar el tráfico total de las interfaces?
Saludos y gracias de antemano...!!!
Pues, no.
BorrarUna vez más, depende de lo que estén midiendo y la granularidad de la información con lo que cuenten.
Las interfaces tienen contadores, pero esos contadores suelen contar solamente paquetes sin discriminar a qué tipo de comunicaciones corresponden, por lo que incluyen tráfico que atraviesa el dispositivo (y ese lo cuentan 2 veces, cuando entra y cuando sale), tráfico generado en el equipo y tráfico que tiene como destino el equipo.
Dependiendo del dispositivo, habría que ver qué herramientas adicionales puedes utilizar, por ejemplo, un contador de tráfico por comunicación que atraviesa. Eso sería más cercano a lo que estás buscando.
De nuevo Muchas gracias. En cuanto al comentario final para monitorear las interfaces del equipo, utilizamos PRTG que nos permite ver gráficamente la cantidad de tráfico que entra y sale de la interfaz.En la gráfica aparece el tráfico que entra y el tráfico que sale. Esta herramienta es un colector SNMP simple. La visualización del referido tráfico lo hacemos en el puerto del switch donde están conectadas las interfaces del Firewall.
ResponderBorrarEstimado Oscar, tengo mi red saturadas con tráfico UDP, creo que son aplicaciones masivas como Skype y YouTube. tengo un firewall ASA 5505 y necesito generar los regex para bloquearlas, me puedes ayudar con los procedimientos o sintaxis CLI para copiarlas a mi firewall.... desde agradezco tu apoyo. saludos.
ResponderBorrarAnthony
BorrarLa situación tiene varias soluciones posibles. Una menos drástica sería aplicar QoS para limitar el ancho de banda que utilizan las aplicaciones de UDP.
Si lo que deseas es bloquearlas, es preciso entonces primero determinar claramente qué es lo que se va a bloquear y es conveniente realizar capturas de tráfico para analizar y ser preciso en el bloqueo ya que un riesgo es bloquear tráfico que en realidad debe pasar.
Respecto de la generación de las regular expressions, hay varios manuales disponibles en la página de Cisco, una vez determinados los dominios a bloquear, puedes utilizar cualquiera de ellos. Aquí te dejo los enlaces a dos de ellos:
http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-2/getting_started/configuration/guide/gs42crs/gs42aexp.html
http://www.cisco.com/c/en/us/td/docs/ios/12_2/termserv/configuration/guide/ftersv_c/tcfaapre.html
Hola Oscar, cual es la diferencia entre millones de paquetes por segundo y Mbps.
ResponderBorrarActualmente estoy tratando de dimensionar un NGFW para 5500 usuarios concurrentes.
La cantidad de paquetes por segundo es una métrica utilizada para cuantificar la capacidad de "forwardeo" o procesamiento de dispositivos que operan a alta velocidad. No es una medida de ancho de banda o throughput, sino solamente de capacidad de forwardeo.
BorrarEs muy utilizado en switches, y últimamente se ha extendido a otros dispositivos que implementan mecanismos de reenvío rápido, tales como firewalls y routers.
Otro punto es medir la capacidad de transporte de enlaces e interfaces, lo cual se hace regularmente en bits por segundo, y está vinculado con la velocidad de transmisión de las interfaces y los enlaces.
Buenas sr Oscar, saludos desde venezuela, tengo una duda, vemos muchos equipo por ejemplo radios que usan de medicion data rate, mi pregunta cual seria el porcentaje de perdida 30%? para calcular el throughput,
ResponderBorrarEl data rate o capacidad de los enlaces puede calcularse porque depende de parámetros específicos, el throughput se mide porque es resultado de múltiples variables que incluso pueden modificarse durante una comunicación.
BorrarSi nos ponemos estrictos cada comunicación tiene un throughput posible que es variable porque depende de los protocolos de control y transporte, y de las condiciones del enlace durante la comunicación.
Sólo para que tengas una idea, a nivel de capa de transporte impactan si hay encapsulado de capa 4 o no, si el protocolo de capa 4 es TCP o UDP, del MTU y si hay un protocolo de control, de la negociación de ese protocolo de control.
El throughput se mide.
Muchas gracias estimado,, por la aclaracion.
BorrarPara entenderlo mejor si yo tengo un router con 3 interfaces de giga, 2 de Lan y uno de wan suponiendo que pueda enviar tráfico a la vez por los interfaces de lan el throughput sería en teoría un máximo de 3 gb o de 1 gb o de 2Gb. Es para desde un ejemplo tratar de entenderlo mejor, siempre suponiendo que el equipo tenga capacidad para manejar 3gb o más.
ResponderBorrarNo hay que confundir throughput de los enlaces, con througput de los dispositivos.
BorrarEn este post analizamos solamente la performance de los enlaces.
Si consideramos los dispositivos (cualquiera sea, switch, router, firewall, AP, etc.), el dispositivo tiene en sí mismo una determinada capacidad de reenvío de tráfico que se mide considerando 2 variantes: capacidad de reenvío medida en volumen de tráfico, y capacidad medida en cantidad de paquetes que se reenvían.
No hay para esto una regla fija, sino que es consecuencia de la capacidad del hardware y es un parámetro que está documentado en el data sheet de los dispositivos.
Creo que no me explicado muy bien yo me refería al througput de los enlaces. Por tanto entiendo que througput de una WAN de 1 Gb correpondería a un 1gb menos el 20% si yo tengo 2 enlaces WAN de 1 Gb con balanceo el máximo teórico entiendo serían 2 GB.
BorrarEs este punto debés tener presente las herramientas de medición que estás utilizando y la documentación que consultes.
BorrarCasi universalmente el ancho de banda es medido eh bps (bits por segundo): sea Kbps, Mbps, Gbps, etc.
Pero el throughput, según la herramienta y documentación que utilices, puede que esté expresado en Bps (Bytes por segundo): KBps, MBps, GBps, etc. Y no siempre vas a encontrar que se ha sido cuidadoso en el uso de las mayúculas (bps no es lo mismo que Bps)
En ese caso debés tener presente que 1 Bps son 8 bps.
Gracias Oscar pero como se calcularía el througput en el caso que indico sería la suma del tráfico de las interfaces. Es decir la suma del tráfico de la LAN y de la WAN o solo el tráfico de la WAN ya que es el punto donde confluye todo el tráfico.
BorrarEs que estás intentando valorar el througput de un sistema que considera enlaces LAN y WAN (según entiendo).
BorrarEl punto en el que confluye todo el tráfico (sin importar si es LAN-WAN o WAN-LAN), es el dispositivo. Tu límite entonces será el throughput del dispositivo que estés trabajando.
Eso no se calcula, es un dato técnico provisto por el fabricante, que debe constar en el datasheet del equipo.
Gracias Oscar pero no me refiero al límite total, que está claro que lo marca el fabricante, me refiero a que si yo tengo varias interfaces en un equipo (olvidándonos de la capacidad de conmutación) y por ejemplo en una interfaz me llegan 200 MBs y por otra 300 MBs ¿se podría decir que son 500 MBs de througput de tráfico? suponiendo que tenga a lo mejor un 10 GBs de througput total del equipo, porque a parte de la capacidad de conmutación, ¿el tráfico de las interfaces se tiene en cuenta para el cálculo del througput o no hay forma de calcular el througput que está unsado un equipo es decir si estoy unsado la mitad, la tercera parte, etc? aunque sea solo calcular el througput de tráfico en el equipo olvidándonos del capacidad de conmutación
BorrarEl throughput es el volumen de tráfico que efectivamente circula.
BorrarEl volumen de tráfico que ingresa o sale a través de cada interfaz es contabilizado en los contadores de cada interfaz y puede ser monitoreado desde la CLI o desde diferentes sistemas de gestión que levanten esa información.