Laboratorio 5

Laboratorio 5 - Simuladores de red (NAM)

Hola, esta entrada corresponde al laboratorio 5 de la materia de telecomunicaciones, en esta actividad realizamos una simulación con la ayuda de ns-2 y NAM. 

La simulación incluye nodos, tráfico entre los nodos y medición de desempeño.

Ns es un simulador de eventos discretos destinados a la investigación en red. Ns presta un apoyo sustancial para la simulación de TCP, enrutamiento y protocolos de multidifusión a través de redes de cable e inalámbricas (local y satélite).

Para la simulación yo utilicé ns-2; ns-2 pude ser encontrado en synaptic, solo tecleen ns, y les aparecerá ns-2 y ns-3 para que instalen el que quieran, además ahí mismo pueden encontrar los ejemplos y la domcumentación.

Nam es la parte gráfica para ver las simulaciones ocurridas en ns-2 o en ns-3. Yo descargué la versión 1.15 de NAM desde synaptic.

GNS 3  

GNS3 es un simulador gráfico de redes que permite la simulación de redes complejas. Para proveer estas simulaciones GNS3 está ligado a las siguientes herramientas:

• Dynamips: un emulador del sistema operativo de cisco (CIsco IOS), esto quiere decir que pones la imagen IOS dentro de los routers, de manera que trabajas en el dynamips como si estuvieras en un router físico.
• Qemu: emulador de máquinas genéricas open source, usado para virtualizar computadoras, al igual que en dynamips tu pones la imagen del sistema operativo que vayas a usar, obviamente limitado a ciertos sistemas operativos.
• VirtualBox: un poderoso software de virtualización  

Si se preguntan porque estoy hablando de GNS3 es porque la simulación la realicé con esta herramienta ya que el puto nam siempre se me crasheaba, instalé 2 nam y ninguno funcionó, uno de los mensajes que me tiró era por incompatibilidad entre nam/ns-2 y otro fue cuando corria una simulación de ejemplo, al momento de dar play salía este error:

Decicidí GNS3 porque ya lo había usado antes y cumple con los mismos propósitos que las herramientas antes mencionadas. GNS3 junto con Dynamips los pueden conseguir desde synaptic, GNS3 es solamente la parte gráfica, viene siendo el equivalente a nam, mientras que Dynamips es la parte del simulador (lo más importante), sería el equivalente a ns-2/ns-3, una vez leí que GNS3 fue creado en python :P

Bien una vez instaladas estas 2 herramientas basta con buscar y abrir GNS3, ya que este se linkea automáticamente con Dynamips.

Así es como se ve la ventana de inicio de GNS3:

En la paleta de la izquierda se encuentran todos los dispositivos de red que se pueden usar para la simulación. En este caso solo usaremos routers c7200, y la imagen de ios que usé fue la siguiente:

Bien, una vez montada la imagen en los routers, ahora si se puede ir poniendo cada uno de ellos en el área de trabajo, luego los encendemos y abrimos una consola para configurar o monitorear cada uno de los routers:

La paleta de la derecha de GNS3 muestra el estado de la topología, en este caso solo encendí el router 1 (R1), también tengo abierta la consola del mismo router al cual le configuré un hostname de ITS1; agregaré más routers, les pondré hostname, configuraré ip's a las interfaces, configuraré rutas estáticas y realizaré simulaciones con paquetes de traceroute y ping. 

Simulación. Tres Routers, envío de paquetes ping para medición de tiempos de respuesta

Tablas de ruteo que realicé (hacer click sobre la imagen para ampliarla):

         | Fa0/0           |  Fa0/1
----------------------------------------------------
R1     | 192.168.1.1  |  NA
R2     | 192.168.1.2  |  192.168.2.1
R3     | 192.168.2.2  |  NA

Podemos notar que cuando hacemos ping desde R1 (interface f0/0) hasta R3 (interface f0/0), la ida y vuelta de los intervalos de tiempo para los paquetes enviados es 8/33/64 milisegundos correspondientes al tiempo mínimo, promedio y máximo respectivamente (consola del lado izquierdo de la imagen).

En la consola derecha de la imagen vemos igualmente un envio de paquete ping pero esta vez desde R2 (interface fa0/1) hasta el mismo destino que el anterior, es decir, R3 (interface fa0/0), esta vez la respuesta de ida y vuelta de los intervalos de tiempo es de 4/13/40 milisegundos  correspondientes al mínimo, promedio y máximo respectivamente (los tiempos obviamente son menores porque R2 se encuentra más cerca a R3 compárandolo con R1, por lo tanto los paquetes viajan menor distancia).

Podemos concluir que entre más lejos esté el destino, obviamente serán mayores los tiempos de respuesta, aquí podriamos incluir más routers a la topología, yo incluí 6 pero de 5 en adelante mi máquina se calienta demasiado al grado que se apaga (recordemos que estamos emulando el sistema operativo de los routers Cisco, incluso la línea de comandos de los routers empieza a notarse lenta apartir de 5 routers).

Eso es todo por mi parte.


Cualquier duda o aclaración pueden dejarla en comentarios. 

Saludos a todos!

Laboratorio 4

Laboratorio 4 - Quality of Service

Hola a todos, esta entrada corresponde al laboratorio 4 de la materia de telecomunicacione, el contenido de este post es referente a los aspectos que tomé en cuenta para realizar el experimento de QoS de la clase de la misma materia (http://triana-redes.blogspot.mx/2013/02/tarea-4.html).

Primero listaré los aspectos que tomé en cuenta para medir la calidad de servicio:

• Intervalo de tiempo
• Ancho de banda
• Retardo
• Variación de retardo
• Pérdida de paquetes       

No descarto que existan otras vías para conocer la calidad de servicio de una aplicación, pero estas fueron las que yo utilicé.

Existen herramientas que nos ayudan a verificar o probar el servicio de distintas aplicaciones, unas incluso ya vienen con todas las funciones para probar distintos features de la aplicación. Yo usé un software que mide distintos parámetros, luego de ahí saqué conclusiones.

Entre los parámetros que mide mi sistema está el "ancho de banda", esto lo que nos dice es el capacidad de banda ancha que está consumiendo nuestra aplicación en el lapso de tiempo transcurrido, por ejemplo en todas las pruebas que yo corrí, lo hice con un lapso de tiempo de 10 segundos, pero eso puede ser especificado antes de comenzar la prueba.

Otro parámetro es "el retardo", obviamente entre menos retardo presente la aplicación pues mejor es el comportamiento, esto se refiere al tiempo estimado que se toma recorrer los paquetes desde su origen hasta el destino, esto lo podemos probar fácilmente con un ping, y se puede hacer a cualquier destino que nosotros queramos, en la imagen siguiente se puede ver un ping que le tiré a google:

 

Podemos ver que el tiempos van desde 35 a 36.5 ms, todos a un mismo destino, si la aplicación tiene variaciones de retardo muy considerables, entonces podemos concluir que la aplicación tenderá a fallar con en ciertos momentos, aunque esto depende también de otros factores, como ancho de banda, equipos de transporte del ISP, etc.

El parámetro de "variación de retardo" es el que les comenté anteriormente, se puede ir apreciando conforme pasan los icmp request, estos van desde el 1 hasta el que nosotros hayamos especificado. Cuando notemos que la variación de retardo es bastante considerable, también notaremos que la aplicación empezará a fallar, con algún delay, voz entrecortada (en voz IP), video congelado (en caso de videollamada), etc.

La aplicación que yo usé media el parámetros de variación en automático en un rango de tiempo de 10 segundos de prueba por default, se puede notar en la siguiente imagen:

  

Ahí se ve el Jitter = 0.463 ms, eso es la variación de retardo, vemos que es pequeño, de manera que no afecta significativamente a la llamada que estaba realizando en ese momento.

"Pérdida de paquetes". Esto también es muy significativo en las aplicaciones de telecomunicaciones, es algo a lo que le ponen mucho énfasis los creadores de softphones como Skype, el propio Linphone, etc.

Como lo he comentado en posts pasados de este blog, las aplicaciones de videoconferencias, llamadas en Voz IP, videollamadas, etc, usan el protocolo UDP, debido a que no es orientado a conexión y esto beneficia mucho los tiempos de comunicación, porque evita funciones que TCP realiza.

Peeeero, la otra cara de la moneda es que UDP no usa secuencia de paquetes, es decir en caso de que un paquete se pierda durante la comunicación, no se reenviará, incluso ni siquiera nota la pérdida de paquetes, los paquetes no llevan un número de secuencia, entonces se puede esperar que la pérdida de paquetes sea mayor que en una aplicación donde usen TCP como protocolo de transporte, aunque como lo mencioné antes, la mayoría de estas aplicaciones viajan por UDP.

En la siguiente captura de pantalla que hice cuando realizaba los experimentos en mi tablet, podemos apreciar que la pérdida de paquetes era de 0%, y para realizar esa prueba se enviaron un total de 893 datagramas. Así que felicidades para Linphone :)

Esto es todo por mi parte.

Ya saben, como siempre. Cualquier duda o aclaración pueden dejarla en comentarios.

Saludos a todos!

     

 

Tarea 4

Tarea 4 - Experimentos de calidad de servicio (QoS)

Hola, esta entrada corresponde a la tarea número cuatro de la clase de Telecomunicaciones y consiste en elegir una aplicación en la cual la QoS juega un papel importante. Luego diseñar, realizar, documentar y analizar un experimento para comparar la QoS.

Linphone

Bien, la aplicación que yo usé para realizar el experimento es Linphone, este es un software para realizar llamadas por internet, trabaja con el protocolo SIP y es del gran grupo de software llamados softphone. 

Linphone es multiplataforma inclusive con los dispositivos móviles, aunque es más estable en Linux, es compatible hasta con una lata de verduras, yo lo instalé en un ipod, una tablet y un ubuntu y funcionó a la perfección.

Como la mayoría de los sofphones, este trabaja en el puerto 5060, en ubuntu te da la posibilidad de cambiar de puerto si así lo deseas, en los móviles no vi esa opción.

Los aspectos más relevantes por los que se preocupan los creadores de este tipo de software son el ancho de banda consumido, el retardo que presenta la información que se envía, la variación de retardo (jitter) y la pérdida de paquetes. Estos son los pilares sobre los cuales trabaja este tipo de tecnologías ya que son las principales variables que influyen en la calidad del servicio. Si alguno de ellos falla se pueden presentar errores como voz entrecortada, robotizada, conexiónes sin establecer por exceso de información en buffer o por problemas de socket, etc.

Para realizar la actividad existe bastante diversidad de herramientas (como todo en la informática), sin embargo, hay muchas que no dicen aspectos como la pérdida de paquetes por aplicación (es muy importante que sea por aplicación, sino el experimento está mal hecho), retardo, etc. Para obtener esos datos se realizan estudios de combinación de herramientas, donde se necesita un buen respaldo de teoría de redes y de conocimiento técnico, por ejemplo el autor de un trabajo de fin de carrera (liga al trabajo: upcommons.upc.edu/pfc/bitstream/2099.1/3768/1/54630-1.pdf) menciona que es necesario capturar cada uno de los paquetes, luego desenvolverlo para checar los headers de cada paquete, luego verificar en cada header los tiempos, luego apartir de ahí calcular retardos (esto como quiera se puede realizar con ping), jitter y pérdidas.

Iperf

Yo encontré un muy buen software que realiza estos procedimientos de una manera más sencilla. El programa se llama iperf, iperf se usa para realizar test o pruebas de redes informáticas, y funciona creando flujos de datos ya sea de protocolo TCP o UDP luego mide el rendimiento.

El programa consta de 2 modalidades, una es de server y la otra de client. Existen diversos parámetros para poder realizar pruebas a aplicaciones de puertos en específico, por ejemplo yo hice las pruebas correspondientes al puerto 5060, porque como mencioné antes Linphone trabaja con ese puerto por default.

Por si esto fuera poco, iperf también es compatible con Android.

La siguiente imagen es la pantalla de inicio de Linphone:

Lo relevante de esta imagen es el SIP address, esa la creas en la página de Linphone para poder comunicarte con otro dispositivo.

Yo creé 2 direcciones SIP una para usar mi Linphone en la computadora y otra para realizar las pruebas en una tablet.

Después de instalar Linphone e iperf lo siguiente que hice fue realizar llamadas entre mis dispositivos para probar el servicio y la verdad que la calidad es muy buena.

Lo siguiente a realizar fue poner iperf en la tablet en modo servidor, la manera de realizar esto es muy sencillo, lo pueden hacer con el siguiente comando :

-s -p 5060 -u

De esa manera le estamos diciendo a iPerf que trabaje de modo servidor en el puerto 5060 con el protocolo UDP, al introducir esa instrucción quedará en modo de espera hasta que un client haga un request de información,  la siguiente imagen ilustra esto que acabo de decir (incluso se puede apreciar el iconillo de Linphone en naranja, en la esquina inferior derecha).

Luego en ubuntu puse iPerf en modo cliente, obviamente con los datos que pusimos anteriormente en el iPerf de la tablet.

Todo esto se realiza obviamente haciendo la llamada primero.

La impresión que nos genera iPerf es la siguiente:

El primer intento que ven en pantalla no es exitoso, porque se ve que dice connection refused, es porque no se especificó el protocolo de transporte correcto en el servidor de iPerf, es decir, mientras que los paquetes de Linphone viajan por UDP yo quería escuchar por TCP, lo que hice fue especificar en la tablet (server) que escuchara por el puerto UDP, luego el segundo intento que ven en la imagen ya es exitoso. Con el parámetro -u estamos diciendo que realice la prueba en UDP, la -c quiere decir que seremos el cliente y la dirección IP que vemos es la que pertenece al server (en este caso a la tablet).

Bueno lo relevante que nos dice aquí es el ancho de banda, que nos dice que es 1.05 Mbits/sec, los datagramas enviados, que fueron 893 (esto también es personalizable), esto con el motivo de calcular la pérdida de paquetes, iPerf también nos dice la variación de retardo (Jitter), en este caso es 0.463 ms y por último nos dice la pérdida de paquetes en porcentaje y en datagramas, nosotros podemos apreciar que nos dice que se perdieron 0 y llegaron 893 (los mismos que se enviaron) osea que el porcentaje de pérdida de paquetes es 0.

A continuación les muestro la respuesta que nos entregó el servidor (tablet):

El log final es el bueno, los anteriores que se ven son intentos fallidos, pueden ver que dice listen on TCP port, por eso nunca recibia el request del cliente, para que funcionara solo agregué el parámetro -u al comando y ya se puso a escuchar por el UDP.
Lo relevante es que al final nos dice los mismos datos que le llegaron al cliente: el intervalo de tiempo de prueba (10 segundos), la cantidad transferida (1.25 MBytes), el ancho de banda (1.05 Mbits/sec), jitter (0.463ms) y la pérdida en datagramas y porcentaje(0/893 0%).

Conclusiones:

En general es una aplicación bastante buena, el ancho de banda que consume (1.05MB/s) es lo normal en este tipo de aplicaciones, y cuando se agrega la función de video podría aumentar al doble o triple, me tocó que cuando inicié la llamada si se notó un tanto lento la navegación entre páginas, disminuyó cuando quité la funcionalidad de video. 
La variación de retardo (0.462 ms) que presenta es bastante baja, incluso puede compararse con la variación de retardo de un simple ping a Google.

Acá vemos variaciones de retardo de 1.5 ms osea 3 veces más grandes que en la aplicación Linphone, pero hay que tomar en cuenta que en Linphone se le corrió la prueba en un lapso de 10 segundos, osea hay muchos factores en este tipo de pruebas, puede que durante esos 10 segundos el SO consumía recursos de red que no los consumía cuando tiré el ping, bueno ustedes ya entienden.

Y en el apartado de los paquetes perdidos si me sorprendí, en el lapso transcurrido de la prueba no hubo ningún paquete perdido, se enviaron 893 datagramas y regresaron los mismos, dando un porcentaje de pérdida de paquetes de 0%, como se aprecia en la siguiente imagen (el último dato, de izquierda a derecha, de arriba hacia abajo).

Esto es todo por mi parte.

Bibliografía:

http://linuxaria.com/article/tool-command-line-bandwidth-linux?lang=en
http://bytecoders.net/content/medir-la-red-con-iperf.html

Cualquier duda o aclaración pueden dejarla en comentarios.

Salud a todos!