Tutorial de herramientas básicas de monitorización y diagnostico de errores en un entorno de red IP.  Las prácticas que se describen en este turorial se han realizado sobre un sitema tipo Unix como es Linux.

 ifconfig.

• Comando ifconfig.
• Ejercios.
• Ejercicio 1.
• Ejercicio 2.

[Índice]

Comando ifconfig.

Ifconfig (interface configuration) es el comando utilizado para configurar la interfaz o interfaces de red durante la fase de arranque del sistema. Cuando se ejecuta sin argumentos (Ej.: $ ifconfig) muestra el estado de los interfaces de red disponibles. Si al ejecutarse se da como argumento el nombre de alguno de los interfaces de red disponibles
(Ej.: $ ifconfig eth0) sólo se muestra información sobre esta interfaz.

Información que se proporciona a cerca de cada interfaz:

Ejercicios.

Ejercicio 1) Ejecutar el comando ifconfig (Ej.: $ ifconfig). ¿Cuántos interfaces de red están activos? ¿Cuáles son sus nombres?.

Tendria que verse algo como:
 
 

lo      Link encap:Local Loopback           inet addr:127.0.0.1  Bcast:127.255.255.255  Mask:255.0.0.0           UP BROADCAST LOOPBACK RUNNING  MTU:2000  Metric:1           RX packets:0 errors:0 dropped:0 overruns:0           TX packets:12 errors:0 dropped:0 overruns:0 eth0   Link encap:10Mbps Ethernet  HWaddr 00:40:90:80:00:6F            inet addr:138.100.58.51  Bcast:138.100.59.255            Mask:255.255.252.0            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1            RX packets:16103 errors:0 dropped:0 overruns:0            TX packets:21 errors:0 dropped:0 overruns:0            Interrupt:5 Base address:0x300

Ejercicio 2) Visualizar sólo información sobre el estado de la interfaz de red eth0. ¿ Cuál es su dirección Ethernet? ¿ Y su dirección IP? ¿Cuál es el número de paquetes enviados? ¿ Y recibidos?.

Tendria que verse algo como:
 
 

eth0      Link encap:10Mbps Ethernet  HWaddr 00:40:90:80:00:6F                inet addr:138.100.58.51  Bcast:138.100.59.255               Mask:255.255.252.0               UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1               RX packets:16004 errors:0 dropped:0 overruns:0               TX packets:19 errors:0 dropped:0 overruns:0               Interrupt:5 Base address:0x300

Ejecutar el comando ping 138.100.56.1. interrumpir la ejecución de ping con Ctrl+C. Volver a visualizar el estado de la interfaz eth0. ¿  Cuál con Ctrl+C. Volver a visualizar el estado de la interfaz eth0. ¿  Cuál es ahora el número de paquetes recibidos y enviados ?
 
 

eth0      Link encap:10Mbps Ethernet  HWaddr 00:40:90:80:00:6F                inet addr:138.100.58.51  Bcast:138.100.59.255 Mask:255.255.252.0               UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1               RX packets:16387 errors:0 dropped:0 overruns:0               TX packets:26 errors:0 dropped:0 overruns:0               Interrupt:5 Base address:0x300

[Indice] [ifconfig].

Netstat.

• Comando netstat.
• Ejercicios.
• Ejercicio 1.
• Ejercicio 2.
• Ejercicio 3.

[Índice]

Comando netstat.

Comando mediante el que se puede obtener el estado de las conexiones activas de red. Utilizando este comando también es posible ver la tabla de rutas del equipo sobre el que se ejecuta e  información sobre las interfaces de red.

Ejercicios.

Ejercicio 1)  Ver el estado de todos los sockets activos mediante el  comando netstat con el parámetro -a.

Muestra por una parte una tabla con todas las conexiones activas abiertas a través de  internet. Para cada entrada  se especifica el protocolo empleado (tcp, udp, raw...), el número de paquetes recibidos , el número de paquetes enviados, dirección origen ,  dirección destino, estado del interfaz (LISTEN, ESTABLISHED ...) y finalmente el usuario que ha abierto el  socket.

A continuación de la primera tabla se muestra una segunda con información sobre los sockets abiertos por el sistema para su uso interno.

Ejercicio 2) Obtener información sobre el estado de los interfaces del sistema mediante netstat - i. ¿ Cuál es el tamaño máximo de la unidad de transmisión de datos para la interfaz lo? ¿ Y para la eth0?.

Tendria que verse algo parecido a:

Ejercicio 3) Obtener la tabla de rutas del sistema mediante netstat -r. Repetir la operación pero añadiendo además el  parámetro -n (Ej.: netstat -rn). ¿ Cuál es la diferencia respecto al caso anterior ( sin el parámetro -n)?.

Primer Caso:

Segundo Caso:

[Índice] [Netstat]

Ping.

• Comando ping.
• Ejercicios.
• Ejercicio 1.
• Ejercicio 2.
• Ejercicio 3.
• Ejercicio 4


[Índice]

Comando ping.

El comando ping se suele utilizar para comprobar de forma rápida si se puede establecer conexión entre dos equipos. Su nombre se ha tomado de la operación de sonar que consiste en localizar un objeto y el programa fue escrito por Mike Muuss. El comando ping se basa en una funcionalidad, llamada echo, que proporciona el protocolo ICMP (Internet Control Message Protocol).

La funcionalidad echo de ICMP consiste en que una entidad ICMP emisora envíe un pequeño paquete de datos a un determinado equipo, cuando la entidad ICMP correspondiente al equipo de destino recibe el paquete simplemente se lo reenvía a la entidad emisora.

El valor del campo Tipo del mensaje ICMP será 0 para un mensaje echo request ( petición de echo) o 8 para un mensaje echo response ( respuesta de echo). En los dos casos el valor del campo Código  será 0. En las implementaciones de ping sobre sistemas UNIX ( como Linux ) el campo Identificador de la cabecera ICMP corresponde al ID del proceso emisor. El Número de Secuencia comienza desde 0 y se va incrementando en uno por cada nueva petición de echo.

La primera línea de información que nos muestra el comando ping proporciona el nombre y la dirección IP del equipo hacia el que se a hecho un ping, además de la cantidad de bytes de datos que se envían en cada paquete, que suelen ser 56.  Cada una de las líneas que se van sucediendo después de la primera corresponden a cada uno de los paquetes que se reciben en respuesta a cada uno de los paquetes ICMP enviados.

La implementación de ping con la que estamos trabajando envía una petición de echo (ICMP echo request) cada segundo, cuando llega la correspondiente respuesta (ICMP echo reply) se genera un línea con la siguiente información; longitud en bytes del paquete ICMP recibido (64 = 8 bytes de cabecera ICMP + 56 de datos), la dirección IP del equipo emisor, el valor del campo Número de Secuencia del paquete ICMP recibido, el valor del campo TTL de la cabecera IP y el tiempo transcurrido desde la emisión del paquete de petición correspondiente.

Por último, la ejecución del comando ping se interrumpe con la secuencia de teclas Ctrl+C,  el programa termina mostrando una pequeña estadística sobre el número de paquetes enviados y recibidos durante la sesión.

Ejercicios.

Ejercicio 1) Realizar un ping hacia alguno de los equipos del curso (EJ.: $ping lm0xy). Observar el retardo y el valor del campo TTL.

Saldria algo como:
 
 

lm002:~> ping lm000 PING lm000.lab.it.uc3m.es (163.117.144.129): 56 data bytes 64 bytes from 163.117.144.129: icmp_seq=0 ttl=64 time=0.4 ms 64 bytes from 163.117.144.129: icmp_seq=1 ttl=64 time=0.3 ms 64 bytes from 163.117.144.129: icmp_seq=2 ttl=64 time=0.3 ms 64 bytes from 163.117.144.129: icmp_seq=3 ttl=64 time=0.3 ms 64 bytes from 163.117.144.129: icmp_seq=4 ttl=64 time=0.3 ms --- lm000.lab.it.uc3m.es ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 0.3/0.3/0.4 ms

Ejercicio 2) Realizar un ping a  arpa.it.uc3m.es (Ej.: ping  arpa.it.uc3m.es). ¿Se observa un cambio apreciable en los retardos de los paquetes que se reciben?.

Saldria algo como:
 
 

lm002:~> ping arpa.it.uc3m.es PING arpa.it.uc3m.es (163.117.139.120): 56 data bytes 64 bytes from 163.117.139.120: icmp_seq=0 ttl=63 time=1.4 ms 64 bytes from 163.117.139.120: icmp_seq=1 ttl=63 time=1.2 ms 64 bytes from 163.117.139.120: icmp_seq=2 ttl=63 time=1.5 ms 64 bytes from 163.117.139.120: icmp_seq=3 ttl=63 time=3.8 ms --- arpa.it.uc3m.es ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 1.2/1.9/3.8 ms

Ejercicio 3) Realizar un ping a switchL1.uc3m.es (Ej.: ping switchL1.uc3m.es). ¿Se observa un aumento de los tiempos de respuesta? ¿El campo TTL a experimentado algún cambio?.

Saldria algo como:
 
 

lm002:~> ping switchL1.uc3m.es PING switchL1.uc3m.es (163.117.30.102): 56 data bytes 64 bytes from 163.117.30.102: icmp_seq=0 ttl=254 time=6.8 ms 64 bytes from 163.117.30.102: icmp_seq=1 ttl=254 time=2.9 ms 64 bytes from 163.117.30.102: icmp_seq=2 ttl=254 time=118.8 ms 64 bytes from 163.117.30.102: icmp_seq=3 ttl=254 time=9.9 ms 64 bytes from 163.117.30.102: icmp_seq=4 ttl=254 time=2.5 ms 64 bytes from 163.117.30.102: icmp_seq=5 ttl=254 time=3.6 ms --- switchL1.uc3m.es ping statistics --- 6 packets transmitted, 6 packets received, 0% packet loss round-trip min/avg/max = 2.5/24.0/118.8 ms

Ejercicio 4) Realizar un ping a www.yahoo.com (Ej.: ping www.yahoo.com). Observar los cambios en los tiempos de respuesta y en el valor del campo TTL. ¿ Cuál ha sido el tiempo de retardo mínimo? ¿ Cuál ha sido el tiempo de retardo máximo? ¿ Cuál  ha sido el tiempo medio de retardo ? ¿ Se ha perdido algún paquete?

Tendria que verse algo como:
 
 

lm002:~> ping www.yahoo.com PING www.yahoo.com (204.71.200.68): 56 data bytes 64 bytes from 204.71.200.68: icmp_seq=0 ttl=231 time=541.9 ms 64 bytes from 204.71.200.68: icmp_seq=2 ttl=231 time=567.8 ms 64 bytes from 204.71.200.68: icmp_seq=5 ttl=231 time=524.7 ms 64 bytes from 204.71.200.68: icmp_seq=6 ttl=231 time=482.7 ms 64 bytes from 204.71.200.68: icmp_seq=7 ttl=231 time=563.9 ms 64 bytes from 204.71.200.68: icmp_seq=8 ttl=231 time=488.7 ms --- www.yahoo.com ping statistics --- 10 packets transmitted, 6 packets received, 40% packet loss round-trip min/avg/max = 482.7/528.2/567.8 ms

[Índice] [ping]

 Nslookup.

• Comando Nslookup.
• Servidores de Nombres.
• Ejercicios.
• Ejercicio 1.
• Ejercicio 2.
• Ejercicio 3.
• Ejercicio 4.
• Ejercicio 5.
• Ejercicio 6.

[Índice]

Comando Nslookup.

Este comando permite realizar consultas sobre los nombres lógicos de determinadas máquinas (Se entiende  por nombre lógico de una máquina cosas como arpa.it.uc3m.es , gabon.eui.upm.es ...) dirigidas al servidor de nombres. También permite obtener información sobre el servidor o servidores de nombres activos en un dominio determinado ( el dominio de la Universidad Carlos III sería uc3m.es).
 

Servidores de Nombres.

El servicio DNS (Domain Name Server) es el encargado de traducir en Internet los nombres de los recursos por direcciones IP, traduce la direcciones lógicas en formato canónico (rondo.eui.upm.es) a direcciones numéricas en formato IP (138.100.58.18) .

El funcionamiento es el siguiente, dentro de la máquina del usuario de la red existe un agente local , llamado Resolver, que se encarga de obtener la información asociada a los dominios. El agente local obtiene la información asociada a los dominios. El agente local o Resolver utiliza el servicio DNS, formado por un conjunto de servidores de nombres, para dar al usuario del sistema la información solicitada.

Si por ejemplo, desde nuestra máquina local queremos acceder alservidor web www.yahoo.com entonces se suceden la siguiente serie de acciones:

1. La aplicación de usuario (Ej: Netscape) pide al agente local Resolver que le de la dirección IP que corresponde al nombre www.yahoo.com.
2. Resolver consulta su caché, donde guarda el resultado de las últimas consultas, por si esa petición ya se hubiera realizado.
3. Si no estuviera  en la caché, Resolver empezaría a realizar consultas a los servidores de nombres hasta encontrar el servidor del dominio yahoo.com.
4. Una vez localizado el servidor de nombres para el dominio yahoo.com, el agente local le solicita la dirección IP del equipo cuyo nombre es www.yahoo.com.
5. El servidor de nombres consulta sus ficheros maestros y si la consulta es positiva devuelve la dirección IP correspondiente.
6. Por último el agente Resolver contesta a la aplicación de usuario que a solicitado al dirección IP.

Cada  dominio tiene que tener al menos dos servidores de nombres uno primario y otro secundario que respalda al primero en caso de fallo. Sobre el servidor de nombres secundario se mantiene una copia de los registros de recursos del primario,  esta información  es actualizada periódicamente.

Los ficheros maestros  que mantiene los servidores de nombres están formados por Registros de Recursos (RR). Cada Registro de Recurso contiene información sobres los recursos asociados a un determinado dominio. Hay varios tipos de Registros de Recursos (A, CNAME, HINFO, MX, NS, PTR, SOA):

SOA (Start of Authority), Indica cual es la autoridad que rige un dominio determinado. Es el registro que contiene información sobre el dominio, como el nombre del servidor de nombres o la dirección de correo del administrador del  dominio,  el resto de datos son parámetros de coordinación entre el servidor primario y el secundario:

• Numero de Serie; se incrementa cada vez que se cambia algo en el servidor de nombres primario, de modo que el servidor secundario sepa cuando debe actualizar su configuración.
• Refresco; indica cada cuantos segundos el servidor secundario ha de actualizarse con los datos del servidor primario.
• Reintento; indica cada cuantos segundos el servidor secundario debe intentar reconectarse al primario para actualizar los datos en caso de error.
• Expira; determina cuanto tiempo ha de pasar para que el servidor secundario deseche toda la información que tenía del primario, en el caso de fallo del primario.
• TTL Mínimo; indica el tiempo de vida de los registros que no lo indiquen explícitamente.

A (Address), cada registro de tipo A contienen la asociación entre una dirección IP y el nombre de un recurso (Ej.: rondo.eui.upm.es  => dirección IP y el nombre de un recurso (Ej.: rondo.eui.upm.es  => 138.100.58.18).

CNAME (Canonical Name), cada registro de este tipo indica un alias de un recurso del dominio.

NS (Name Server), indica cual es el servidor de nombres para el dominio que se está describiendo.

MX (Mail Exchanger), contiene el nombre de un servidor de correo para el dominio. Puede haber más de un servidor de correo asociado, cada uno de los cuales tiene asignado un valor numérico que indica el nivel de  prioridad ( cuanto más pequeño mayor prioridad ) , de modo que si el servidor de correo con mayor prioridad esta ocupado se pasa al siguiente en orden de prioridad.

HINFO (Host Information), permite describir el equipo sobre el que corre el servidor de nombres.

PTR (Pointer), asocia direcciones de dominio a nombres de máquinas.
 

Ejercicios.

Ejercicio 1) Buscar la dirección IP de sobrino.eui.upm.es . Para ello ejecutar nslookup sobrino.eui.upm.es desde el intérprete de comandos (Ej.: $ nslookup sobrino.eui.upm.es). También es posible ejecutar nslookup sin parámetros para sobrino.eui.upm.es). También es posible ejecutar nslookup sin parámetros para entras en el entorno de la aplicación y desde éste dar el nombre del equipo cuya dirección IP queremos conocer.

Se veria como:
 
 

> nslookup sobrino.eui.upm.es Server:  localhost.it.uc3m.es Address:  127.0.0.1 Name:    fenix.eui.upm.es Address:  138.100.56.25 Aliases:  sobrino.eui.upm.es

En ambos casos la salida que se genera se compone en primer lugar del nombre simbólico junto con la dirección IP del servidor de nombres utilizado (Ej.:  Server: fenix.eui.upm.es Address: 138.100.56.25) y en segundo lugar el nombre simbólico objeto de consulta  y de su dirección IP correspondiente. Observar que una misma dirección IP puede tener asociada más de un nombre simbólico.

 
Realizar ahora una consulta sobre la dirección IP de www.yahoo.com.
 
 

> nslookup www.yahoo.com Server:  localhost.it.uc3m.es Address:  127.0.0.1 Name:    www.yahoo.com Addresses:  204.71.200.75, 204.71.200.74, 204.71.200.67, 204.71.200.68

Ejercicio 2) Buscar la dirección IP de ntred.dit.upm.es y de news.upm.es.

Observar que tanto ntred.dit.upm.es como news.upm.es tienen la misma dirección IP.¿ Como se justificaría esto?.

Ejercicio 3) Buscar los servidores de nombres que funcionan para el dominio eui.upm.es. Para ello ejecutar nslookup para entrar en el entorno de esta aplicación (Ej.: $ nslookup). Una vez en el entorno de la aplicación nslookup ejecutar la sentencia set type=NS (con lo que se cambia el modo de consulta). En este momento ejecutar eui.upm.es.

Se veria como:
 
 

> nslookup  Default Server:  localhost.it.uc3m.es Address:  127.0.0.1 > set type=NS > eui.upm.es Server:  localhost.it.uc3m.es Address:  127.0.0.1 Non-authoritative answer: eui.upm.es      nameserver = genio.eui.upm.es eui.upm.es      nameserver = quijote.eui.upm.es eui.upm.es      nameserver = concerto.eui.upm.es eui.upm.es      nameserver = galileo.ccupm.upm.es eui.upm.es      nameserver = artemis.ibernet.es eui.upm.es      nameserver = fenix.eui.upm.es Authoritative answers can be found from: genio.eui.upm.es        internet address = 138.100.56.26 genio.eui.upm.es        internet address = 138.100.56.26 quijote.eui.upm.es      internet address = 138.100.56.28 concerto.eui.upm.es     internet address = 138.100.58.31 galileo.ccupm.upm.es    internet address = 138.100.4.4 artemis.ibernet.es      internet address = 194.179.3.157 artemis.ibernet.es      internet address = 194.179.3.158 artemis.ibernet.es      internet address = 194.179.1.101 artemis.ibernet.es      internet address = 194.179.3.156 fenix.eui.upm.es        internet address = 138.100.56.25

La información que obtenemos empieza como antes con el nombre y la dirección IP del servidor de nombres utilizado por defecto. Después una lista de los nombres de todos los servidores de nombres asociados al dominio dado. Por último las direcciones IP de todos estos servidores de nombres.

Ejercicio 4) Obtener las características del servidor de nombres asociado al dominio eui.upm.es. Entrar en el entorno de la aplicación nslookup (Ej.: $ nslookup). Cambiar el modo de consulta a SOA (Ej.: > set type=SOA). Ejecutar eui.upm.es.

¿ Cuál es el servidor de nombres principal?  ¿ Cuál es el tiempo de vida por defecto de los registros del dominio?.

Ejercicio 5) Entrar en el entorno de la aplicación nslookup (Ej.: $nslookup). Cambiar el modo de consulta a CNAME (Ej.: > set type=CNAME). Realizar consultas sobre los siguientes nombres www.eui.upm.es, ftp.eui.upm.es, www.it.uc3m.es, news.upm.es.

¿ Cuál es el nombre de la máquina sobre la que corre el servidor web de la escuela de informática? ¿ y el servidor web del area de telemática de la Universidad Carlos III? ¿ sobre que máquina corre el servidor ftp de la escuela de informatica ? ¿ Que máquina da servicio de news de la politecnica?.

Consultar sobre el nombre de la máquina que funciona como servidor web de la Universidad Carlos III de Madrid, www.uc3m.es.
 
 
 

> www.uc3m.es Server:  localhost.it.uc3m.es Address:  127.0.0.1 www.uc3m.es     canonical name = lince.uc3m.es uc3m.es nameserver = vorteX.uc3m.es uc3m.es nameserver = saruman.uc3m.es uc3m.es nameserver = chico.rediris.es uc3m.es nameserver = sun.rediris.es vorteX.uc3m.es  internet address = 163.117.131.31 saruman.uc3m.es internet address = 163.117.131.43 chico.rediris.es        internet address = 130.206.1.3 sun.rediris.es  internet address = 130.206.1.2

Ejercicio 6) Entrar en el entorno de la aplicación nslookup (Ej.: $ nslookup). Cambiar el modo de consulta a MX (Ej.: > set type=MX). Obtener los servidores de correo asociados a los  dominios upm.es y uc3m.es.
 
 

> set type=MX > upm.es Server:  localhost.it.uc3m.es Address:  127.0.0.1 upm.es  preference = 10, mail exchanger = einstein.ccupm.upm.es upm.es  nameserver = vec.ccupm.upm.es upm.es  nameserver = galileo.ccupm.upm.es upm.es  nameserver = sanson.dit.upm.es upm.es  nameserver = dir.etsit.upm.es upm.es  nameserver = sun.rediris.es upm.es  nameserver = chico.rediris.es einstein.ccupm.upm.es   internet address = 138.100.4.8 vec.ccupm.upm.es        internet address = 138.100.1.2 galileo.ccupm.upm.es    internet address = 138.100.4.4 sanson.dit.upm.es       internet address = 138.4.2.10 dir.etsit.upm.es        internet address = 138.100.17.10 sun.rediris.es  internet address = 130.206.1.2 chico.rediris.es        internet address = 130.206.1.3 > uc3m.es Server:  localhost.it.uc3m.es Address:  127.0.0.1 uc3m.es preference = 5, mail exchanger = mail.rediris.es uc3m.es preference = 1, mail exchanger = elrond.uc3m.es uc3m.es nameserver = vorteX.uc3m.es uc3m.es nameserver = saruman.uc3m.es uc3m.es nameserver = chico.rediris.es uc3m.es nameserver = sun.rediris.es mail.rediris.es internet address = 130.206.1.2 elrond.uc3m.es  internet address = 163.117.136.62 vorteX.uc3m.es  internet address = 163.117.131.31 saruman.uc3m.es internet address = 163.117.131.43 chico.rediris.es        internet address = 130.206.1.3 sun.rediris.es  internet address = 130.206.1.2

¿ Cuáles son los servidores de correo para estos dominios? ¿ Para el dominio uc3m.es cuál es el servidor de correo más prioritario?.

[Índice] [Nslookup]

Traceroute.

• Comando traceroute.
• Ejercicios.
• Ejercicio 1.
• Ejercicio 2.
• Ejercicio 3.

[Índice]

Comando traceroute.

Mediante este comando se puede ver la ruta que siguen los paquetes IP para llegar a un determinado equipo.

Traceroute utiliza tanto el protocolo ICMP como el contenido del campo TTL de la cabecera de los datagramas IP, y funciona de la siguiente forma:

1. Lo primero que hace es enviar, al equipo destino, un datagrama IP  con el campo TTL a 1. El primer router por el que pase el datagrama restará 1 al campo TTL, quedándose el campo a cero, con lo que el datagrama será descartado. Además de descartar el datagrama el router enviará un mensaje ICMP de tipo "tiempo superado" (time exceeded)  dirigido al equipo de origen. Mediante el mensaje ICMP recibido  se puede identificar al primer router que forma parte de la ruta.
2. A continuación se envía un segundo datagrama IP  con TTL igual a 2 para identificar al segundo router.  A sí sucesivamente hasta que se llegue al equipo de destino.
3. Cada datagrama IP enviado por indicación del programa traceroute encapsula un paquete UDP. El puerto de destino de éste paquete UDP corresponde a un identificador de puerto que es muy poco probable que se utilice ( mayor que 30.000). Cuando un paquete UDP va dirigido a un puerto que no esta activo la entidad UDP del equipo destino genera un mensaje ICMP de tipo puerto no disponible ( destination unrechable, codigo = 3) dirigido al equipo de origen. Cuando se recibe un mensaje ICMP de tipo puerto no disponible quiere decir que se ha llegado al equipo de destino.

El formato del comando traceroute es traceroute nombre del equipo o dirección IP del equipo que queremos estudiar (Ej.: $ traceroute uganda o $ traceroute 138.100.58.247). La información que proporciona es la siguiente:

Una primera línea con el nombre y la dirección  IP del equipo de destino, número máximo de saltos a realizar y tamaño del paquete que se envía (40 bytes = 20 cabecera IP + 8 cabecera UDP + 12 datos de usuario).

Cada línea de las que aparezcan a continuación de la primera representa un salto realizado para llegar al equipo destino y la información que se muestra en cada una de esta líneas es número de salto (TTL), nombre y dirección IP del equipo al que se llega después de ese salto y a continuación tres muestras de los tiempos de retardo  empleados en llegar a ese equipo. Por cada salto se envían tres paquetes UDP con el mismo TTL.

Ejercicios.

Ejercicio 1) Realizar un traceroute a lm000 (Ej.: $ traceroute lm000). ¿ Cuantos saltos son necesarios para llegar a lm000? ¿Por cuantos equipos pasan los paquetes enviados desde nuestro equipo antes de llegar a lm000?.
 
 

lm002:~> traceroute lm000 traceroute to lm000.lab.it.uc3m.es (163.117.144.129), 30 hops max, 40 byte packets  1  lm000.lab.it.uc3m.es (163.117.144.129)  1.913 ms  1.191 ms  1.276 ms

Ejercicio 2) Realizar un traceroute a switchL1.uc3m.es (Ej.: $traceroute switchL1.uc3m.es). ¿ Cuantos saltos son necesarios para llegar a switchL1.uc3m.es? ¿Por cuantos equipos pasan los paquetes enviados desde nuestro equipo antes de llegar a switch.uc3m.es?.

Realizar un ping a switchL1.uc3m.es (Ej.: $ ping switchL1.uc3m.es). ¿Cuál es el valor del campo TTL que muestran las líneas de información que da como salida el comando ping?. Justifica el valor de  TTL con los datos obtenidos mediante la operación de traceroute a switchL1.uc3m.es.

Ejercicio 3) Realizar un traceroute a www.yahoo.com (Ej.: $ traceroute www.yahoo.com). ¿ Cuantos saltos son necesarios para llegar a www.yahoo.com? ¿Por cuantos equipos pasan los paquetes enviados desde nuestro equipo antes de llegar a www.yahoo.com?.
 
 

[Indice] [Traceroute]
 

TTCP

• Descripción.
• Ejercicios.
• Ejercicio 1.
• Ejercicio 2.

[Indice]

Descripción.

Para la siguiente serie de ejercicios se va a utilizar el programa de test ttcp. El programa ttcp contabiliza el tiempo de transmisión y recepción  de  datos entre dos sistemas que usan los protocolos UDP o TCP.  Si no se dispone de una copia de esta utilidad se puede obtener una versión a través de alguno de los siguientes enlaces:

Fuentes en formato tar.gz:  ttcp-1.4-src.tar.gz
Binarios precompilados con libc6 en formato .tar.gz : ttcp-1.4-bin.tar.gz
Binarios para libc6 en formato .deb  ( debian ): ttcp-1.4-19990717.deb

Para realizar los test se ha de lanzar un proceso ttcp en modo de recepción, esto se hace lanzando el programa ttcp con las siguientes opciones:

ttcp -r -s -pport

Donde -r indica que el programa se lanza en modo de recepción, -s  los datos recibidos se deshechan (sin esta opción los datos recibidos se mostrarían por la salida estandar) y con -p se indica el puerto en el que va a poner a la escucha el programa.  Ejemplo de ejecución:
 
 

bash-2.01$ ttcp -r -s -p5000 ttcp-r: buflen=8192, nbuf=2048, align=16384/+0, port=5000  tcp ttcp-r: socket

Una vez lanzado el comando ttcp en modo de recepción, el programa se queda a la espera  de datos a través del puerto especificado (port=5000). Por defecto el programa se lanza con los siguientes parámetros:

Protocolo TCP, para seleccionar el protocolo UDP se debe utilizar la opción -u.

Tamaño de buffer 8192 bytes de datos. Este valor se puede modificar con el parámetro -l length. En el caso de udp este parámetro indica el tamaño del campo de datos de los paquetes udp, el tamaño máximo de  cada paquete udp esta limitado por el sistema, en algunos sistemas este tamaño se puede modificar con la opción -b size.

Número de buffers 2048. Este valor se puede modificar con la opción -n numbufs.

Alineación del comienzo de los buffers 16384. Este valor se puede modificar con la opción -A align.

Desplazamiento respecto del comienzo del buffer 0. Para modificar este valor se utiliza la opción -O offset.

Desde otro equipo se lanzara otro proceso ttcp en modo de envio, de la siguiente forma:

ttcp -t -s -pport host

Donde  -t indica que ttcp se lanza en modo de transmisión, -s impide que los datos a enviar se tomen de la entrada estandar (se envian los datos contenidos en el buffer), con -pport se especifica el puerto de la máquina remota a la que se envian los datos y con host se indica el nombre del equipo de destino. Ejemplo de ejecución:
 
 

bash-2.01$ ttcp -t -s -p5000 anakin ttcp-t: buflen=8192, nbuf=2048, align=16384/+0, port=5000  tcp  -> anakin ttcp-t: socket ttcp-t: connect ttcp-t: 16777216 bytes in 0.36 real seconds = 45145.06 KB/sec +++ ttcp-t: 2048 I/O calls, msec/call = 0.18, calls/sec = 5643.13 ttcp-t: 0.0user 0.1sys 0:00real 50% 0i+0d 0maxrss 0+2pf 0+0csw

En la salida que se genera se indica si se ha abierto un socket en el sistema (ttcp-t: socket), si se ha establecido conexión (ttcp-t: connect, en el caso de TCP), el número de bytes de datos transmitidos (8192 x 2048 = 16777216 bytes),  el tiempo de transmisión (  0.36 seg ) y la velocidad de transmisión o throughput resultante (  45145.06 KB/sec ) por defecto se muesta en Kilobytes por segundo, pero el formato de este parámetro se puede modificar con la opción -f format , donde format  puede ser alguno de los siguientes carácteres:
 

k - kilobit/seg.
K - kilobytes/seg.
m - megabits/seg.
M - megabytes/seg.
g  - gigabits/seg.
G - gigabytes/seg.

En la siguiente linea muestra el número de llamadas de entrada salida al sistema (2048 I/O calls, una por cada buffer) también se representa el tiempo utilicado para cada llamada (msec/call = 0.18 en milisegundos) y el número de llamadas por segundo (calls/sec = 5643.13).

La última de las lineas muestra información sobre los recursos del sistema utilizados en relación con el proceso ttcp lanzado. Los datos que se muestran pueden variar de un sistema a otro pero suelen ser los siguientes:
 

Tiempo en procesos de usuario ( 0.0user).

Tiempo en procesos del sistema ( 0.1sys  como llamadas al sistema).

Tiempo real transcurrido desde el comienzo de la ejecución del proceso hasta su finalización (0:00real).

Tanto por ciento del tiempo real empleado por el proceso ttcp (50%).

Memoria compartida y de datos no compartida solizitada a lo largo de la ejecución del proceso (0i+0d), sin contar con memoria de pila.

Cantidad máxima de memoria utilizada ( 0maxrss ).

Número de faltas de página y peticiones de página (0+2pf).

Número de cambios de contexto voluntarios y forzados (0+0csw).

 En recepción el resultado es el siguiente:
 
 

bash-2.01$ ttcp -r -s -p5000 ttcp-r: buflen=8192, nbuf=2048, align=16384/+0, port=5000  tcp ttcp-r: socket ttcp-r: accept from 127.0.0.1 ttcp-r: 16777216 bytes in 0.38 real seconds = 42749.72 KB/sec +++ ttcp-r: 2049 I/O calls, msec/call = 0.19, calls/sec = 5346.32 ttcp-r: 0.0user 0.1sys 0:00real 34% 0i+0d 0maxrss 0+2pf 0+0csw

Ejercicios.

Ejercicio 1) Lanzar ttcp con los siguientes parámetros:
 

ttcp -r -s -n10000  -l10000 -p5000

y

ttcp -t -s -n10000 -l10000 -p5000  host
 

Donde host  es el nombre de la máquina sobre la que se a lanzado el primer proceso ttcp en modo de recepción. El resultado tendria que ser algo parecido a:
 
 

bash-2.01$ ttcp -r -s -n10000  -l100000 -p5000 ttcp-r: buflen=100000, nbuf=10000, align=16384/0, port=5000  tcp ttcp-r: socket ttcp-r: accept from 127.0.0.1 ttcp-r: 1000000000 bytes in 17.72 real seconds = 55125.56 KB/sec +++ ttcp-r: 18649 I/O calls, msec/call = 0.97, calls/sec = 1052.71 ttcp-r: 0.0user 9.9sys 0:17real 56% 0i+0d 0maxrss 0+15pf 0+0csw

 

bash-2.01$ ttcp -t -s -n10000 -l100000 -p5000  anakin ttcp-t: buflen=100000, nbuf=10000, align=16384/0, port=5000  tcp  -> anakin ttcp-t: socket ttcp-t: connect ttcp-t: 1000000000 bytes in 17.70 real seconds = 55183.89 KB/sec +++ ttcp-t: 10000 I/O calls, msec/call = 1.81, calls/sec = 565.08 ttcp-t: 0.0user 7.0sys 0:17real 39% 0i+0d 0maxrss 0+25pf 0+0csw

Observar la relación entre el número de llamadas al sistema y el número de buffers de información a enviar, observar el aumento en el tiempo de transmisión en relación con el aumento del tamaño de los buffers y del número de estos. Por último observar que la mayor parte del tiempo de proceso corresponde a llamadas al sistema.
 

Ejercicio 2) Monitorizar el intercambio de datagramas UDP:

1. Lanzar tcpdump con un filtro mediante el que sólo se muestren los datagramas UDP que se intercambien entre nuestra máquina y otra cualquiera (Ej.: $ tcpdump -xev " host senegal and host uganda and udp").
2. Lanzar el programa ttcp  en las dos máquinas, en una en modo de  recepción y en otra en modo de envio (Ej.: uganda:~> ttcp -r -u  -s -n1 -l500 -p5000  y  senegal:~>ttcp -t -u -s -n1 -l500 -p5000 uganda).

Los 20 primeros bytes del campo de datos de las tramas Ethernet corresponden a la cabecera IP,  los 8 siguientes a la cabecera UDP  y los siguientes al paquete de datos que intercambia la aplicación ttcp.
 

Ejemplo de captura:

[Indice] [Ttcp]

Tcpdump.

• Comando Tcpdump.
• Ejercicios.
• Ejercicio 1.
• Ejercicio 2..


[Índice]

Comando Tcpdump.

Tcpdump es una herramienta que permite monitorizar el tráfico de paquetes sobre la red. El formato básico es:

tcpdump [-evx] [-i interface] [-s longPaq] [expresion]

-e Muestra la cabecera a nivel de enlace de cada trama recibida.

-v Muestra información adicional sobre los paquetes que se capturan.

-x Muestra datos de los paquetes capturados sobre Nivel de Transporte (TCP/UDP), Nivel de Red (IP, ICMP...).

-i interfaz Con este parámetro se puede especificar la interfaz de red a través del cual queremos realizar la captura de paquetes.

-s longPaq Se utiliza para especificar cuantos bytes de los paquetes capturados queremos que nos muestre. Por defecto se muestran 68 bytes.

expresion Es una expresión booleana que representa las condiciones quedeben cumplir los paquetes que queremos monitorizar. Si no se especifica ninguna expresión se nos mostrarán todos los paquetes que se capturen a través del interfaz de red. No es obligatorio pero es conveniente delimitar los términos que forman la expresión mediante comillas (Ej.: "expresión").

Si dadas las características de un paquete la expresión se evalúa como verdadera el contenido de ese paquete es mostrado. La expresión esta compuesta de un identificador (id) precedido de uno o más cuantificadores:

Type - Indica a que corresponde el identificador que le sigue y puede ser uno de los siguientes:

• host   El identificador corresponde a un equipo (Ej.: host gabon)
• net  El identificador corresponde a una red (Ej.: 138.100).
• port  El identificador es un puerto (port 5000).

Si no se especifica ninguno se toma host por defecto.

Dir - Especifica la dirección de la transferencia de datos que nos interesa monitorizar, desde o hacia un determinado equipo. Posibles valores:

• src   Cual tiene que ser la fuente (Ej.: src gabon).
• dst   Cual tiene que ser el destino (Ej.: dst net 138.100).
• src or dst  Fuente o destino (Ej.: src or dst  gabon).
• dst and src  Destino y fuente (Ej.: dst and src port 5000).

Por defecto se toma src or dst.

Proto - Especifica un protocolo (ether, fddi, ip, arp, tcp, udp ...).

Si no se especifica, todo protocolo que mantenga correspondencia con el tipo de identificador es válido.

Otras palabras claves que pueden formar parte de una expresión son:

• gateway.
• broadcast.
• less

Es posible componer expresiones mediante palabras como:

• and
• or
• not

En la composición de expresiones boolenas complejas es posible el uso de paréntesis que determinen el orden de evaluación de los componentes de la expresión (Ej.: $ tcpdump " (host uganda and gabon and ip) or arp").

Ejercicios.

Ejercicio 1)  Se pretende monitorizar  el  tráfico de paquetes entre dos equipos A y B cualesquiera:

Para conseguir este fin se utilizaría el comando tcpdump indicando dentro de la expresión booleana el nombre de los equipos cuyo intercambio de datos queremos monitorizar (Ej.: $ tcpdump "host A and host B"). Por defecto se escucharía en la interfaz eth0. A y B se tomarían como identificadores de equipos. Se capturarían todos los paquetes de datos procedentes o dirigidos  al equipo A y procedentes o dirigidos al equipo B.

a) Hacer la prueba monitorizando el tráfico entre vuestro equipo y otro cualquiera, por ejemplo, uno de los equipos contiguos (Ej.: $ tcpdump "host lm002 and  host lm000".  Para asegurar que se produce algún intercambio de información abrir otra ventana y realizar un ping desde el equipo propio hacia el elegido (Ej: $ping lm000).
 
 

lm002:~> /usr/local/sbin/tcpdump "host lm002 and host lm000" tcpdump: listening on eth0 11:56:40.054676 lm002.lab.it.uc3m.es.123590730 > lm000.lab.it.uc3m.es.nfs: 112 lookup [|nfs] 11:56:40.064676 lm002.lab.it.uc3m.es > lm000.lab.it.uc3m.es: icmp: echo request 11:56:40.064676 lm000.lab.it.uc3m.es > lm002.lab.it.uc3m.es: icmp: echo reply 11:56:41.064676 lm002.lab.it.uc3m.es > lm000.lab.it.uc3m.es: icmp: echo request 11:56:41.064676 lm000.lab.it.uc3m.es > lm002.lab.it.uc3m.es: icmp: echo reply 11:56:42.064676 lm002.lab.it.uc3m.es > lm000.lab.it.uc3m.es: icmp: echo request 11:56:42.064676 lm000.lab.it.uc3m.es > lm002.lab.it.uc3m.es: icmp: echo reply 11:56:43.064676 lm002.lab.it.uc3m.es > lm000.lab.it.uc3m.es: icmp: echo request 11:56:43.064676 lm000.lab.it.uc3m.es > lm002.lab.it.uc3m.es: icmp: echo reply 11:56:43.954676 lm002.lab.it.uc3m.es.679 > lm000.lab.it.uc3m.es.987: udp 76 11:56:44.194676 lm002.lab.it.uc3m.es.685 > lm000.lab.it.uc3m.es.987: udp 76 11 packets received by filter 0 packets dropped by kernel

b) Especificar ahora que se muestre información sobre la cabecera del protocolo de nivel de enlace de cada paquete (Ej.: $ tcpdump -e "lm002 and lm000"). En nuestro caso la cabecera de nivel de enlace corresponderá al protocolo
802.3 o Ethernet. Realizar un ping hacia el equipo cuyo tráfico queremos monitorizar (Ej.: ping lm000).

Como parte de la información de nivel de enlace se muestra la dirección Ethernet de origen y destino así como el protocolo de nivel superior que se encapsula en las tramas Ethernet ( ip en este caso). ¿ Cuál es la dirección Ethernet de nuestro equipo?.

c) Indicar ahora que se nos muestre más información complementaria sobre los paquetes capturados (Ej.: $ tcpdump -ev "host lm002 and host lm000"). Nuevamente lanzar un ping (Ej.: $ ping lm000). ¿ Cuáles son los nuevos datos mostrados con respecto a la captura anterior?.

d) Ahora vamos a obtener la información que transportan los paquetes de nivel de enlace, Ethernet en nuestro caso. Para ello se utiliza laopción -x (Ej.: $ tcpdump -evx "host lm002 and host lm000"). Los datos se muestran en formato hexadecimal. Nuevamente tras lanzar la sesión de tcpdump realizar un  ping.

Por defecto se muestran los primeros 68 bytes del campo datos de las tramas Ethernet capturadas. Para aumentar el número de bytes que queremos ver podemos utilizar el parámetro -s seguido del número de bytes de datos a mostrar (Ej.: $ tcpdump -evx -s 100 "host uganda and host gabon").

Ejercicio 2) Monitorizar el tráfico de paquetes IP y ARP entre dos másquinas. Como en el ejercicio anterior lanzaremos una sesión de tcpdump desde nuestra máquina. Definir un filtro (expresión booleana) que sólo muestre  los paquetes ip que se intercambian  entre nuestro equipo y otro cualquiera (Ej.:  lm0xy  ). Al igual que en los casos anteriores lanzar un ping al equipo elegido (Ej.: $ping lm0xy).
 
 
 
 

a) ¿ A qué protocolo pertenecen las tramas encapsuladas en los datagramas IP que intercambian los equipos? .Observar que por cada tramas "echo reques" que se emite desde nuestro equipo el equipo receptor nos devuelve un "echo reply" .
 
 

Protocolo ARP.

El protocolo de resolución de direcciones proporciona una correspondencia (mapa) entre las direcciones IP de 32 bits y cualquier tipo de direccionamiento usado por los protocolos de nivel de enlace. ARP proporciona un mapeo dinámico de las direcciones IP con las correspondientes direcciones hardware. Mapeo dinámico quiere decir que este proceso se realiza automáticamente, normalmente sin la intervención del administrador.

Toda máquina sobre la que funcione el protocolo ARP tiene que mantener una zona de memoria donde se almacenará el mapa de direcciones (tabla ARP). En algunas publicaciones esta zona de memoria se llama cache ARP.

Los campos que contempla un paquete ARP son:

 

El campo Hard Type (TH) ocupa 2 bytes y con él se especifica el tipo de dirección hardware. Para direcciones Ethernet (o 802.3) el valor de este dirección hardware. Para direcciones Ethernet (o 802.3) el valor de este campo será 1.

Proto Type (TP) es el campo mediante el que se especifica el tipo de dirección de protocolo que va ha ser mapeada. Al igual que el campo TH tiene una longitud de 2 bytes y el código correspondiente a las direcciones IP es 2048 (800 en hexadecimal).

El campo Hard Size (LH) tiene un tamaño de 1 byte. El contenido del campo LH corresponderá al tamaño en bytes de la dirección hardware (Ethernet o 802.3) que para direcciones Ethernet será de 6 bytes.

Proto Size (LP) también ocupa un byte. La finalidad de este campo es la misma que la del campo LH, pero esta vez para especificar el tamaño de la dirección que utilice el protocolo de nivel de red (dirección IP ), para direcciones IP el valor de este campo va ha ser 4 bytes.

Mediante el campo Operation (OP), que ocupa 2 bytes, se especifica cuando el paquete corresponde a una petición o respuesta ARP. Los códigos válidos para este campo son los mostrados en la siguiente tabla:
 

Código	Operación
1	Petición ARP
2	Respuesta ARP
3	Petición RARP
4	Respuesta RARP

Actualmente los únicos códigos que se utilizan son los correspondientes al protocolo ARP. Para realizar consultas sobre el protocolo RARP (Reverse Address Resolution Protocol) consultar la publicación " TCP/IP Illustrated Volume I " .

Los campos Sender Ethernet Address (DIR. ETHERNET FUENTE) y  TargetEthernet Address (DIR ETHERNET DESTINO)  tienen una longitud de 6 bytes y corresponden a las direcciones Ethernet de los equipos origen y destino.

Por último, los campos Sender IP Address (DIR IP FUENTE) y Target IP Address (DIR IP DESTINO) ocupan 4 byte cada uno. Estos campos corresponden a las direcciones IP origen y destino respectivamente.

La tabla ARP que se mantiene en una máquina se actualiza a partir de la información que se obtiene del intercambio de tramas ARP. El funcionamiento del protocolo ARP es bastante sencillo y se describe mediante el siguiente ejemplo:

Suponemos que tenemos tres equipos en el mismo segmento Ethernet (A, B y C), en un determinado momento la entidad ARP que corre en el equipo A quiere conocer cual es la dirección Ethernet que corresponde a la dirección IP 138.100.52.25, para ello emite una trama ARP consultando a los demás equipos sobre a quien pertenece dicha dirección IP. Para que la trama ARP de petición llegue a todos los equipos del segmento Ethernet, está va a ir encapsulada en una trama Ethernet de tipo broadcast.

En el caso en el que alguno de los equipos tenga la dirección IP 138.100.52.25 este va a contestar emitiendo una trama ARP de respuesta, notificando cual es su dirección Ethernet. En este ejemplo el equipo C responde a A diciéndole que su dirección Ethernet es c4:04:fd:a5:10:40.

NOTA:  El comando arp permite  visualizar el contenido  de la  tabla ARP ( Address Resolution Protocol), en la que se mantienen las correspondencias entre direcciones físicas (Ej.:  direcciones Ethernet) y direcciones lógicas o de Red (Ej.: direcciones IP).

b) Cambiar el filtro para que sólo se muestren paquetes ARP (Ej.: tcpdump -exv "host lm0xy and arp". A continuación realizar un ping a cualquier otro equipo del laboratorio lm0xy. Describir mediante un cronograma el intercambio de paquetes ARP. ¿ Cuál es la dirección Ethernet que corresponde a la dirección IP de lm0xy ?. Ejecutar un ping a un equipo del laboratorio de telematica it0xy ¿ Cuál es la direccion Ethernet que corresponde a la dirección IP de it0xy ?.

El resultado seria algo como:
 
 

lm002:~> /usr/local/sbin/tcpdump "host lm002 and arp" tcpdump: listening on eth0 00:28:30.905096 arp who-has lm005.lab.it.uc3m.es tell lm002.lab.it.uc3m.es 00:28:30.905096 arp reply lm005.lab.it.uc3m.es is-at 0:60:97:ba:bf:de 00:28:51.105096 arp who-has it005.lab.it.uc3m.es tell lm002.lab.it.uc3m.es 00:28:51.105096 arp reply it005.lab.it.uc3m.es is-at 0:10:5a:56:b7:1d

 

[Índice] [Tcpdump]