Agenda: ejercicios-analisis-local.txt

Gestion y Monitoreo de Redes
Analisis Local de su Red

Notas:
------
* Comandos que empiezan con un "$" implica que deberia ejecutar el comando 
  como un usuario general - no como root.
* Comandos que empiezan con un "#" implica que deberia trabajar como el usuario root.
* Comandos con lineas mas especificas (como "GW-RTR>" o "mysql>") implica que esta
  ejecutando el comando en un equipo remoto o dentro otro programa.
* Si una linea termina con un "\" esto indica que el comando sigue en la proxima
  linea y Ud. deberia tratar el comando si como fuera en una sola linea.

Exercicios Parte I
----------------

0. Haz un log in en su PC o abre una ventana de terminal como el usuario sysadmin.


Midiendo el Desempeno de la Red
--------------------------------

1. ping
   ----

ping es una programa que manda un pedido de ICMP de echo a los hosts de objectivo y
que espera una respuesta de ICMP desde aquello host. Dependiendo en el sistema operativo
en que estas usando ping puede ver minimo, maximo and los tiempos de ida y vuelta medianos,
y hasta que, de repente, desviación estándar de la media por las respuestas de ICMP de
host de objectivo. Para mas detalles vea:

http://en.wikipedia.org/wiki/Ping

Bloqueando ping, en general, no es una buena idea.

Con todo esto en mente, intenta de usar ping en algunas formas diferentes:

        $ ping localhost

Apreta ctrl-c para parar el proceso. Abajo es salida tipica por el comanda arriba:

PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.020 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.006 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.006 ms
64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.006 ms
64 bytes from localhost (127.0.0.1): icmp_seq=5 ttl=64 time=0.006 ms
64 bytes from localhost (127.0.0.1): icmp_seq=6 ttl=64 time=0.009 ms
64 bytes from localhost (127.0.0.1): icmp_seq=7 ttl=64 time=0.007 ms
^C
--- localhost ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 5994ms
rtt min/avg/max/mdev = 0.006/0.008/0.020/0.005 ms

Pregunta: Porque demoro 20ms la primera respuesta de ICMP mientras que todo la
demas respuestas demoraban mucho menos? Esto es un tipo de retardo. Que tipo de retardo 
es?

Vamos a hacer un poco atraso/demora de proceso en una forma artificial. En un terminal
tipea:

        $ ping localhost

En otra ventana, en la misma maquina, tipea:

        $ cd
        $ vi cpu.sh
        
Agrega las siguiente lineas al archivo como esto:

        #!/bin/sh
        sh $0
        or in c
        while ( 1 )
        fork(); 

Graba el archivo, y, despues, hazlo ejecutable:

        $ chmod a+x cpu.sh

Ahora corre el escripto:

        $ ./cpu.sh

Deberia ver que las respuestas a ping en la otra ventana empieza de tomar mas tiempo.
Cuando terminas apreta ctrl-c in las dos ventanas de terminal para parar los dos
procesos.


2. traceroute
   ----------

Tal vez ha usado traceroute antes, pero has realmente averiguado que hace traceroute?
si no, lea estos:

http://en.wikipedia.org/wiki/Traceroute
http://es.wikipedia.org/wiki/Traceroute

Ahora intenta:

        $ traceroute nsrc.org

Aqui hay una muestra de salida de un traceroute al nsrc.org:

traceroute to nsrc.org (128.223.157.19), 30 hops max, 60 byte packets
 1  192.168.5.129 (192.168.5.129)  4.291 ms  5.757 ms  6.725 ms
 2  192.168.17.2 (192.168.17.2)  1.933 ms  1.932 ms  2.150 ms
 3  192.168.0.1 (192.168.0.1)  2.140 ms  2.127 ms  2.598 ms
 4  10.0.0.129 (10.0.0.129)  2.586 ms  2.576 ms  4.548 ms
 5   (168.234.72.1)  4.792 ms  4.786 ms  4.750 ms
 6  200.0.204.69 (200.0.204.69)  7.456 ms  5.665 ms  5.890 ms
 7  panama-salvador.core.redclara.net (200.0.204.185)  64.651 ms  64.884 ms  64.870 ms
 8  panama-santiago.core.redclara.net (200.0.204.22)  124.865 ms  124.853 ms  124.841 ms
 9  saopaulo-santiago.core.redclara.net (200.0.204.38)  172.008 ms  171.793 ms  172.019 ms
10  ge-7-1-0.0.rtr.chic.net.internet2.edu (64.57.28.114)  172.006 ms 
    xe-2-2-0.88.rtr.wash.net.internet2.edu (198.32.11.105)  244.441 ms  244.675 ms
11  xe-0-1-0.0.rtr.atla.net.internet2.edu (64.57.28.6)  258.151 ms  258.384 ms  258.618 ms
12  xe-0-0-0.0.rtr.salt.net.internet2.edu (64.57.28.24)  207.383 ms  
    207.602 ms xe-1-0-0.0.rtr.hous.net.internet2.edu (64.57.28.112)  282.040 ms
13  xe-2-0-0.0.rtr.losa.net.internet2.edu (64.57.28.96)  314.004 ms 
    xe-1-0-0.0.rtr.seat.net.internet2.edu (64.57.28.105)  224.293 ms  224.527 ms
14  vl-101.xe-0-0-0.core0-gw.pdx.oregon-gigapop.net (198.32.165.65)  328.948 ms 
    vl-102.xe-1-0-0.core0-gw.pdx.oregon-gigapop.net (198.32.163.69)  227.015 ms 
    vl-101.xe-0-0-0.core0-gw.pdx.oregon-gigapop.net (198.32.165.65)  328.184 ms
15  vl-105.uonet9-gw.eug.oregon-gigapop.net (198.32.165.92)  330.660 ms  330.891 ms  229.940 ms
16  vl-3.uonet2-gw.uoregon.edu (128.223.3.2)  331.359 ms  229.748 ms  229.727 ms
17  nsrc.org (128.223.157.19)  229.458 ms  229.460 ms  330.862 ms

Entiende que significa cada cosa? Si no, vea la pagina de wikipedia y tipea

        $ man traceroute

para mas informacion. Que significa si vea lineas asi?

15  * * *
16  * * *
17  * * *

De nuevo, lea "man traceroute" para mas datos.

Como puede ver traceroute puede estar usado para determinar donde hay problemas entre dos 
puntos de terminacion en una red.


3. mtr
   ---

La herramienta mtr combina ping y traceroute en un solo paquete. Pruebalo:

        $ mtr nsrc.org

La salida del comando se vea diferente en diferente versiones de Linux y UNIX, pero en
general vas a ver un resumen de perdida de paquetes a cada nodo en el camino al nodo
de objectivo (nsrc.org arriba), numero de paquetes de ICMP echo request mandados, ultimo
tiempo de rtt (tiempo de ida y vuelta) al nodo, promedio, mejor y peor rtt y, tambien
la desviacion estandar de los tiempos de rtt.

Mostrando la perdiad de paquetes en esta forma se lo hace mucho mas facil ver donde hay 
problemas en un camino de la Red.


Ejercicios Parte II
-------------------

Analisis de la Red
------------------

1. lsof y netstat
   ----------------

Vea que servicios estan corriendo en tu maquina. Puede usar la presentacion como
referencia.

O, utilizar "man lsof", "man netstat", "lsof -h" y "netstat -h" para ver todo las
opciones disponible (hay muchos!). Recuerda usar "sudo" cuando usa lsof y netstat
para darte los permisos necesarios para ver todo.

* Usando lsof, que servicios de IPv4 estan escuchando en su maquina?

* Usando netstat, que servicios de IPv4 y IPv6 estan escuchando en su maquina?


2. tcpdump y tshark
   ------------------

Para usar tcpdump necesita usar sudo, o sea root. Para usar wireshark necesita
abrir un terminal y usar sudo como un usuario normal (ej: "sysadmin").

Se usa tcpdump como esto:

        $ sudo tcpdump -i lo -A -s1500 -w /tmp/tcpdump.log

Ahora, genera algo de trafico en su interfaz de lo en otro terminal.

Por ejemplo:

        $ ping localhost
        $ ssh localhost
 
etc. Despues se apreta CTRL-C para terminar la sesion de tcpdump.

Nota: ssh genera salida mucho mas "interesante". Ahora vamos a ver la salida de tcpdump
usando wireshark y/o tshark (wireshark = grafico, tshark = en terminal con curses).


        $ sudo wireshark -r /tmp/tcpdump.log 

o, si quieres

        $ sudo tshark -r /tmp/tcpdump.log | less

Que vea? Puede seguir su sesion de SSH?

Ahora intenta algo asi:

        $ sudo rm /tmp/tcpdump.log
        $ sudo tcpdump -i eth0 -A -s1500 -w /tmp/tcpdump.log

En otro terminal haz:

        $ ftp limestone.uoregon.edu
 
        Connected to limestone.uoregon.edu.
        220 FTP Server ready.
        Name (limestone.uoregon.edu:sysadmin): anonymous
        Password: <anything you want>
        ftp> exit

Termina la sesion de tcpdump en otro terminal (CTRL-C). Ahora vea los contenidos de archivo
de log:

        $ sudo wireshark -r /tmp/tcpdump.log

Puede ver su clave? Si tiene mucho trafico en su Red tal vez el archivo de tcpdump.log 
va a ser bastante grande. Puede buscar por su sesion de FTP usando el "Filter:" en wireshark,
o en tshark simplemente buscando usando "/FTP".

Vea si puede encontrar algo asi.

        "FTP Request: PASS PasswordYouTypedIn"

Escuchando por claves no encifrados en los LANs inalambricos es muy facil con una herramienta
como esto.

3. Usando iperf
   ------------

Usa "man iperf" o "iperf -h" por ayuda.

Pide que tu vecino corre:

        $ iperf -s

Conecta a la maquina de su vecino usando:

        $ iperf -c ipVecino

Que rendimiento tiene entre tus maquinas?

Puede considera conectando sus PCs directamente (un cable, no conmutador). No tiene que
cambiar tu direccion de IP mientras que estan en el mismo grupo (Grupo 1 o Grupo 2) por el
hecho que tiene el mismo rango de direccion de IP con el mismo Netmask.

Verifica que puede hacer un ping entre sus maquinas. Ahora repite las pasos previos con su 
connecion nueva y directa. Ha mejorado su rendimiento? Porque?

Si tiene tiempo sigue jugando con las opciones de iperf. Si tiene acceso a una maquina
remoto corriendo UNIX o Linux puede instalar iperf ahi y hacer una prueba de coneccion entre
la sala de este taller y su maquina remoto.

Otras cosas para intentar...

* Prueba TCP usando tamaños de ventanas diferentes (-2)

* Verifica TCP MSS (-m). Como afecta esto a su rendimiento. Que es el "Path MTU Discovery" 
  (Discubrimiento de MTU del Camino).

* Prueba con dos procesos de iperf en paralelo (-P) y compara los totales. Hay diferencia?
  Porque?

* Pruebe con diferente tamaños de paquetes y la opcion de TCP_NODELAY (-N).