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: 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).