L9028

157.88.128.93e0:69:95:f4:d3:0300:0c:29:df:d1:7a

157.88.128.64 Dirección de subred: 157.88.128.0Máscara de subred: 255.255.255.0

Dirección de subred: 157.88.129.0Máscara de subred: 255.255.255.0 157.88.129.84

00:0c:29:df:d1:84

157.88.128.250157.88.128.251

157.88.129.250157.88.129.251

Balbas

Informe de la práctica 2: La capa de redIng. de Protocolos en Redes Telemáticas, Grado en Ing.de Tecnologías de Telecomunicación

E.T.S. de Ingenieros de Telecomunicación, Universidad de ValladolidCurso 2012-2013

Grupo iprtx15 Fco. Javier Vaquero CaballeroRubén Sánchez de la Rosa

P1 (7pp) P2 (5pp) P3 (7pp) P4 (7pp) P5 (5pp) P6 (7pp) P7 (5pp) P8 (7pp)

P9 (5pp) P10 (5pp) P11 (7pp) P12 (5pp) P13 (7pp) P14 (5pp) P15 (7pp) P16(7pp)

P1. Dibuja una topología lógica (i.e. cada dominio de colisión como un bus Ethernet) de las subredes a las que se encuentra conectado balbas incluyendo una representación de dicha máquina, tu máquina del laboratorio y el router que une esas subredes. Incluye en el dibujo las direcciones IP y máscaras correspondientes a cada subred así como las direcciones de las interfaces de las máquinas mencionadas que conectan con esas subredes.

P2. Muestra los detalles no expandidos de la captura del tráfico generado cuando utilizaste el comando ping para enviar un único mensaje ICMP de petición de eco a una máquina que se encuentre fuera de la Universidad de Valladolid y su correspondiente respuesta.

No. Time Source Destination Protocol Length Info39 4.867385 157.88.128.93 173.194.34.248 ICMP 98 Echo (ping) request id=0x0ea2, seq=1/256, ttl=64

Frame 39: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)Ethernet II, Src: Pegatron_f4:d3:03 (e0:69:95:f4:d3:03), Dst: All-HSRP-routers_00 (00:00:0c:07:ac:00)Internet Protocol Version 4, Src: 157.88.128.93 (157.88.128.93), Dst: 173.194.34.248 (173.194.34.248)Internet Control Message Protocol

40 4.871993 173.194.34.248 157.88.128.93 ICMP 98 Echo (ping) reply id=0x0ea2, seq=1/256, ttl=57

Frame 40: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)Ethernet II, Src: Cisco_54:e3:00 (00:0c:85:54:e3:00), Dst: Pegatron_f4:d3:03 (e0:69:95:f4:d3:03)Internet Protocol Version 4, Src: 173.194.34.248 (173.194.34.248), Dst: 157.88.128.93 (157.88.128.93)Internet Control Message Protocol

1

P3. ¿A qué máquina pertenece la dirección de origen del datagrama IP que encapsula el mensaje de petición de eco en la captura anterior?¿Y la de destino? ¿A qué máquina pertenece la dirección de origen de la trama Ethernet que encapsula el mensaje de petición de eco en la captura anterior?¿Y la de destino?

La dirección IP origen es: 157.88.128.93 y pertenece a nuestra máquina de laboratorio.La dirección IP destino es: 173.194.34.248 y pertenece a Google.La dirección Ethernet origen es: e0:69:95:f4:d3:03 y pertenece a nuestra máquina de laboratorio.La dirección Ethernet destino es: 00:00:0c:07:ac:00 y pertenece al vendedor All-HSRP-routers, por lo tanto se trata de la interfaz del router de la red 157.88.128.00. Con el comando arp se comprueba esta deducción: 157.88.128.250 ether 00:00:0c:07:ac:00 C eth0

P4. El mensaje ICMP de petición de eco de tu máquina a la dirección IP 157.88.129.84 sigue una ruta distinta al mensaje de respuesta de dicha petición. ¿Por qué?

Hemos forzado al mensaje ICMP a tomar la ruta más larga (mandamos el ping a la otra interfaz de balbas: ver dibujo), teniendo que atravesar el router. Una vez el mensaje ha llegado a Balbas, este tiene libertad para decidir sobre qué camino manda la respuesta y elige la ruta más rápida evitando atravesar el router.

P5. Muestra las líneas de resumen de la captura de tráfico realizada para el estudio del proceso de fragmentación en IP

No. Time Source Destination Protocol Length Info21 3.908660 157.88.128.93 157.88.128.92 IPv4 1514 Fragmented IP protocol (proto=ICMP 0x01, off=0, ID=3e55) [Reassembled in #22]

22 3.908671 157.88.128.93 157.88.128.92 ICMP 362 Echo (ping) request id=0x113b, seq=1/256, ttl=64

23 3.910024 157.88.128.92 157.88.128.93 IPv4 1514 Fragmented IP protocol (proto=ICMP 0x01, off=0, ID=480e) [Reassembled in #24]

24 3.910039 157.88.128.92 157.88.128.93 ICMP 362 Echo (ping) reply id=0x113b, seq=1/256, ttl=64

P6. ¿Qué campos de la cabecera IP permiten llevar a cabo el reensamblado de los fragmentos? ¿Cuál es el valor de esos campos en el caso de los fragmentos del datagrama IP que encapsula la petición de eco?

La petición se divide en dos paquetes IP fragmentados que contienen los campos: - Offset: que nos permite averiguar a qué longitud (byte) del paquete del nivel superior

hemos segmentado. - Identification: Nos permite diferenciar conexiones.

- More fragments: se trata de un flag que se pone a 1 mientras no se trate del último fragmento del paquete.Valores que observamos: (1º paquete, 2º paquete)Offset=( 0 , 1480), Id = 0x480e (no cambia) , More fragments= (1, 0 )

P7. Muestra los detalles no expandidos de la captura de tráfico realizada para el estudio del funcionamiento normal de ARP.

No. Time Source Destination Protocol Length Info

2

8 1.445693 Pegatron_f4:d3:03 Broadcast ARP 42 Who has 157.88.128.91? Tell 157.88.128.93

Frame 8: 42 bytes on wire (336 bits), 42 bytes captured (336 bits)Ethernet II, Src: Pegatron_f4:d3:03 (e0:69:95:f4:d3:03), Dst: Broadcast (ff:ff:ff:ff:ff:ff)Address Resolution Protocol (request)

9 1.446378 Pegatron_f4:d2:9c Pegatron_f4:d3:03 ARP 60 157.88.128.91 is at e0:69:95:f4:d2:9c

Frame 9: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)Ethernet II, Src: Pegatron_f4:d2:9c (e0:69:95:f4:d2:9c), Dst: Pegatron_f4:d3:03 (e0:69:95:f4:d3:03)Address Resolution Protocol (reply)

10 1.446391 157.88.128.93 157.88.128.91 ICMP 98 Echo (ping) request id=0x0e6f, seq=1/256, ttl=64

Frame 10: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)Ethernet II, Src: Pegatron_f4:d3:03 (e0:69:95:f4:d3:03), Dst: Pegatron_f4:d2:9c (e0:69:95:f4:d2:9c)Internet Protocol Version 4, Src: 157.88.128.93 (157.88.128.93), Dst: 157.88.128.91 (157.88.128.91)Internet Control Message Protocol

11 1.447098 157.88.128.91 157.88.128.93 ICMP 98 Echo (ping) reply id=0x0e6f, seq=1/256, ttl=64

Frame 11: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)Ethernet II, Src: Pegatron_f4:d2:9c (e0:69:95:f4:d2:9c), Dst: Pegatron_f4:d3:03 (e0:69:95:f4:d3:03)Internet Protocol Version 4, Src: 157.88.128.91 (157.88.128.91), Dst: 157.88.128.93 (157.88.128.93)Internet Control Message Protocol

14 2.444228 157.88.128.93 157.88.128.91 ICMP 98 Echo (ping) request id=0x0e6f, seq=2/512, ttl=64

Frame 14: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)Ethernet II, Src: Pegatron_f4:d3:03 (e0:69:95:f4:d3:03), Dst: Pegatron_f4:d2:9c (e0:69:95:f4:d2:9c)Internet Protocol Version 4, Src: 157.88.128.93 (157.88.128.93), Dst: 157.88.128.91 (157.88.128.91)Internet Control Message Protocol

15 2.444904 157.88.128.91 157.88.128.93 ICMP 98 Echo (ping) reply id=0x0e6f, seq=2/512, ttl=64

Frame 15: 98 bytes on wire (784 bits), 98 bytes captured (784 bits)Ethernet II, Src: Pegatron_f4:d2:9c (e0:69:95:f4:d2:9c), Dst: Pegatron_f4:d3:03 (e0:69:95:f4:d3:03)Internet Protocol Version 4, Src: 157.88.128.91 (157.88.128.91), Dst: 157.88.128.93 (157.88.128.93)Internet Control Message Protocol

3

P8. ¿Por qué la máquina que realiza las peticiones de eco envía una petición ARP antes que el datagrama que encapsula la primera petición de eco? ¿Cuántas máquinas reciben esa petición? ¿Cuántas responden? ¿Por qué la máquina que realiza las peticiones de eco no envía una petición ARP antes que el datagrama que encapsula la segunda petición de eco? ¿Por qué la máquina que recibe las peticiones de eco no envía ninguna petición ARP?

Inicialmente desconoce la dirección Mac, por lo tanto necesita el protocolo ARP para obtenerla a partir de la IP. La petición ARP se realiza en Broadcast, todas las máquinas de la red reciben dicha petición aunque solo contesta la máquina cuya dirección concuerda con la de la petición. En la segunda petición la maquina origen tiene en la cache la correspondencia IP – MAC, por lo tanto directamente envía la respuesta. Las peticiones ICMP van encapsuladas sobre IP en cuya cabecera se encuentran las direcciones de origen y destino IP y en un nivel inferior las MAC, conoce dichas direcciones y no necesita preguntarlo.

P9. ¿En qué momento se producen cambios en la caché ARP de la máquina que envía las peticiones de eco? ¿Qué cambios se producen? ¿Y en el caso de la máquina que recibe las peticiones de eco?

En la máquina que envía las peticiones de eco (la nuestra), la caché ARP cambia cuando se recibe la ARP reply de la máquina con la que queremos contactar. Estos cambios se traducen como la actualización de la caché ARP: Antes: Address HWtype HWaddress Flags Mask Iface

rueda.tel.uva.es ether 00:0c:29:7c:45:b3 C eth0 balbas.tel.uva.es ether 00:0c:29:df:d1:7a C eth0 157.88.128.250 ether 00:00:0c:07:ac:00 C eth0

Después: Address HWtype HWaddress Flags Mask Iface L9027.tel.uva.es ether e0:69:95:f4:d3:48 C eth0 rueda.tel.uva.es ether 00:0c:29:7c:45:b3 C eth0 balbas.tel.uva.es ether 00:0c:29:df:d1:7a C eth0 157.88.128.250 ether 00:00:0c:07:ac:00 C eth0La máquina que recibe las peticiones de eco cambia su caché ARP cuando recibe la ARP request.

P10. Muestra las líneas de resumen de la captura de tráfico realizada para el estudio de la herramienta ping.

No. Time Source Destination Protocol Length Info22 3.908671 157.88.128.93 157.88.128.92 ICMP 362 Echo (ping) request id=0x113b, seq=1/256, ttl=64

24 3.910039 157.88.128.92 157.88.128.93 ICMP 362 Echo (ping) reply id=0x113b, seq=1/256, ttl=64

P11. Explica el funcionamiento de la herramienta ping a partir de la captura anterior.

La herramienta ping forma parte del protocolo ICMP (tipo 8 y 0) que se encapsula a su vez en IP versión 4. Se utiliza para mandar peticiones de eco y recibir sus respectivas respuestas de eco.Hay una larga lista de opciones para poder realizar diferentes tareas, como por ejemplo: aumentar el tamaño de los paquetes, hacer los ecos audibles, ver la ruta que siguen…Como podemos ver en la captura de tráfico se asigna un id a cada flujo de ecos, de esta manera pueden diferenciarse los tres primeros ecos de los tres siguientes. Cada flujo tendrá un id distinto, pero los ecos de un mismo flujo llevarán el mismo id.También observamos que los ecos llevan un identificador seq (secuencia) del estilo 1/256. El primer número es el seq number BE, mientras que el segundo es el LE. Estos identificadores se utilizan para diferenciar los ecos dentro de un mismo flujo.Además se utilizan marcas de tiempo para saber cuánto tardan en llegar.

4

P12. Muestra líneas de resumen de la captura de tráfico realizada para el estudio de la herramienta traceroute.

No. Time Source Destination Protocol Length Info15 0.883535 157.88.128.251 157.88.128.93 ICMP 70 Time-to-live exceeded (Time to live exceeded in transit)

16 0.883776 157.88.128.251 157.88.128.93 ICMP 70 Time-to-live exceeded (Time to live exceeded in transit)

17 0.884094 157.88.128.251 157.88.128.93 ICMP 70 Time-to-live exceeded (Time to live exceeded in transit)

P13. Explica el funcionamiento de la herramienta traceroute a partir de la captura anterior

Traceroute se basa en ICMP para averiguar la ruta por la que pasan los paquetes. Puede verse que el uso que hace de ICMP es bien simple: modifica el campo TTL de los paquetes IP aumentando este campo de uno en uno, así que cuando pasan por un nodo este reportará que el campo TTL se ha agotado con un mensaje ICMP. Repitiendo esto podemos saber exactamente por qué nodos pasa nuestro paquete.

P14. Muestra las líneas de resumen de la captura del tráfico generado para el estudio de IPv6 e ICMPv6

No. Time Source Destination Protocol Length Info6083 82.253094 fe80::e269:95ff:fef4:d348 ff02::1:fff4:d303 ICMPv6 86 Neighbor Solicitation for fe80::e269:95ff:fef4:d303 from e0:69:95:f4:d3:48

6084 82.253131 fe80::e269:95ff:fef4:d303 fe80::e269:95ff:fef4:d348 ICMPv6 86 Neighbor Advertisement fe80::e269:95ff:fef4:d303 (sol, ovr) is at e0:69:95:f4:d3:03

6085 82.253856 fe80::e269:95ff:fef4:d348 fe80::e269:95ff:fef4:d303 ICMPv6 118 Echo (ping) request id=0x0f1f, seq=1

6086 82.253880 fe80::e269:95ff:fef4:d303 fe80::e269:95ff:fef4:d348 ICMPv6 118 Echo (ping) reply id=0x0f1f, seq=1

6114 87.252020 fe80::e269:95ff:fef4:d303 fe80::e269:95ff:fef4:d348 ICMPv6 86 Neighbor Solicitation for fe80::e269:95ff:fef4:d348 from e0:69:95:f4:d3:03

6115 87.252703 fe80::e269:95ff:fef4:d348 fe80::e269:95ff:fef4:d303 ICMPv6 78 Neighbor Advertisement fe80::e269:95ff:fef4:d348 (sol)

P15. ¿Por qué la máquina que realiza la petición de eco envía un mensaje de solicitud de vecino antes que el datagrama que encapsula dicha petición de eco? ¿Cuántas máquinas reciben la solicitud de mensaje que envía la máquina que realiza la petición de eco? ¿Cuántas responden? ¿Por qué la máquina que recibe la petición de eco envía un mensaje de solicitud de vecino?

Como la caché de vecinos no contiene la correspondencia IPv6-MAC de la máquina con la que se quiere contactar es necesario el mensaje de solicitud de vecino (NS). Este NS tiene dirección MAC destino multicast (empieza por 33:33 seguido por los 32 bits menos significativos de la dirección IPv6 de destino), por lo tanto las máquinas que recibirán el mensaje serán aquellas que pertenezcan al grupo multicast de esa dirección Ethernet.

5

La única máquina que responderá será aquella que además de pertenecer a los grupos multicast Ethernet e IPv6, tenga la IPv6 que se indica en el campo Target Address.

Después de la resolución de direcciones IPv6 ambas máquinas actualizarán sus cachés de vecinos y mandarán los ecos. La máquina que recibe la petición de eco, manda su respuesta y espera pasando la correspondencia IPv6-MAC a estado DELAY. Como es obvio, la otra máquina (la que desde un principio quería mandar los ecos) no volverá a mandar nada a la máquina receptora ya que todo lo que se le había pedido era mandar una petición de eco. Por eso la receptora agota el timeout: DELAY_FIRST_PRBE_TIME, y pasa al estado PROBE, en el cual manda una nueva solicitud de vecino a la máquina cuya relación IPv6-MAC está en duda. Cuando recibe la respuesta (es interesante resaltar que esta respuesta tiene el bit de “override” a cero), vuelve al estado STALE (donde permanecerá hasta que se agote el timeout o reciba nueva información de la otra máquina o se le solicite que mande información a la otra máquina).

P16. ¿En qué momento se producen cambios en la caché de vecinos de la máquina que envía la petición de eco? ¿Qué cambios se producen? ¿Y en el caso de la máquina que recibe la petición de eco?

Los cambios en la caché de vecinos de la máquina que envía la petición de eco se producen al enviar la NS (crea un espacio en la caché de vecinos con la ipv6 de la máquina que quiere saberse su correspondencia y con el estado INCOMPLETE), y cuando recibe la respuesta de esa misma solicitud de vecino (incluye la correspondencia ipv6-MAC y pasa al estado REACHABLE). También cambiará cuando se acabe el timeout y pase al estado STALE.

En el caso de la otra máquina, cambiará su caché cuando reciba el NS (incluyendo una entrada en su caché de vecinos con la dirección ipv6 y su correspondiente MAC), pasará al estado DELAY al mandar el eco de respuesta, y pasará por el estado PROBE cuando se acabe el timeout de DELAY. Posteriormente cuando recibe el anuncio de vecino vuelve a pasar a REACHABLE, después a STALE, y se borrará de la caché después de un tiempo.

6