Laboratorio 5

Reconocimiento Información Formatos: Trama, datagrama y protocolos de

red
Rafael Ivan Rincon Fonseca, ririnconf@unal.edu.co
Angel Andrés Joya Quintero, aajoyaq@unal.edu.co
Jorge Daniel Gallo Sanabria, jdgallos@unal.edu.co
Hector Alejandro Acevedo Sotelo, haacevedos@unal.edu.co

1. Asignación direccionamiento IP
Se realizara la conexión de tres redes de diferente clase, por lo cual se asignan las direcciones IP a cada host con su respectiva
mascara de subred y la dirección de su puerta de enlace como se muestra a continuación:
Host Clase IP Mascara Gateway
1 A 10.1.0.2 255.0.0.0 10.1.0.1
2 B 128.168.0.2 255.255.0.0 128.168.0.1
3 C 192.168.0.2 255.255.255.0 192.168.0.1
Para configurar la IP de cada host, únicamente se requiere cambiar en la configuración del adaptador de red (Ethernet) las propie-
dades del protocolo de Internet versión 4 (IPv4). Lo anterior se mnuestra en la figura 1.

Figura 1: Configración de la dirección IPv4 de un host (Clase A)

Las direcciones IP de cada subinterfaz del Router terminan en 1, mientras que las direcciones de las LANs virtuales del switch
(VLANs) terminan en 3.

1
2. Configuración Router-Switch-Host
2.1. Aseguramiento equipos de networking
Para cada equipo de networking, router y switch se procede a asignar un nombre al equipo, contraseñas de seguridad y la
encripcion de estas contraseñas.

Equipo Nombre Clave usuario Clave usuario privilegiado

Switch SW-LAB5 switch lab5
Router RT-LAB5 router lab5

Se muestra a continuación los códigos empleados en PacketTracer para cada dispositivo.

(a) Configuración switch (b) Configuración router

Figura 2: Capturas de pantalla con la configuración de aseguramiento de cada dispositivo

Para validar la configuración

2.2. Configuración interfaces LAN

2.2.1. Switch
Se deben emplear interfaces vlan para la conexion de cada red, el primer paso es asignar un nombre a cada vlan, se utilizan
a partir de la vlan 2 ya que la vlan 1 se encuentra reservada. Luego de asignar los nombres se identifica la interface a la que esta
conectada cada red y se procede a asignar una vlan a cada una de ellas, finalmente se les asigna una dirección IP dependiendo a la
red a la que pertenecen. Resta configurar la interface hacia el router como trunk ya que por ahi se transmitirán todas las vlan.

Vlan Nombre Puerto Interface IP

2 classA Access Fa 0/2 10.1.0.3
3 classB Access Fa 0/3 128.168.0.3
4 classC Access Fa 0/4 192.168.0.3
- - Trunk Fa 0/1 -

2
 (a) Asignación nombres (b) Selección de interfaces y puerto

(d) Configuración trunk

(c) Asignación IPs

Figura 3

Para validar la configuración realizada se ejecuta el comando show vlan y show running-config observando que los nombres,
direcciones y numeros de vlan sean los correctos.

(b) show running-config

(a) show running-config

(c) show vlan

Figura 4

3
2.2.2. Router
En el router ya que existe una única conexión fı́sica con el switch, se deben crear sub-interfaces para poder realizar la comu-
nicación, es decir, la interfaces fastEthernet se divide en 3 sub-interfaces, a cada una de ellas se les configura una dirección IP que
corresponda a la puerta de enlace de cada red con su respectiva mascara de subred. Adicionalmente se deben encapsular los datos
en cada vlan ya que son diferentes redes, con el comando encapsulation con el protocolo dot1Q. Por buenas practicas el numero
de la sub-interface corresponde con el numero de la vlan.

(a) Configuración router

(b) show running-config

Figura 5

2.3. Prueba de Conectividad

2.3.1. Packet-Tracer
Una vez configurado los dispositivos de networking y asignadas las IP a cada host, se tiene el esquema de conexión de la
figura 6a. Para la prueba de conexión se puede realizar de dos formas: hacer un ping desde cada host hacia los otros host o utilizar
la herramienta de enviar un simple PDU desde cada host a los demas, por practicidad se muestra el resultado implementando el
ultimo método en la figura 6b

(b) Prueba de conectividad

(a) Diagrama de conexión

Figura 6

2.3.2. Montaje fisico

La verificación de conectividad entre los equipos conectados a la red se puede ver en las figuras 7, 8, y 9. En cada una de estas
se observa el comando ping hacia los otros dos host, los cuales tienen diracciones IP de clases distintas.

4
Figura 7: Prueba de conectividad host con dirección IP clase A y switch

Figura 8: Prueba de conectividad host con dirección IP clase B y switch

5
 Figura 9: Prueba de conectividad host con dirección IP clase C y switch

2.4. Captura de trama haciendo uso de WireShark

Para realizar la captura de trama se instaló el software WireShark, este software permite capturar y analizar los segmentos de
red que pasan a través de las diferentes interfaces del host. En el caso del switch fue necesario re dirigir los paquetes que pasaban a
través de las interfaces del mismo hacia la interfaz donde estaba conectado el equipo de monitoreo, esto se debe a que WireShark
sólo captura los segmentos de data que pasan por la interfaz escogida, para solucionar este problema se hizo mirroring en cada
uno de las interfaces FastEthernet hacia la interfaz que tenı́a conectado el host de monitoreo de la siguiente forma:

Switch(config)# no monitor session 1

Switch(config)# monitor session 1 source interface fastEthernet0/2
Switch(config)# monitor session 1 destination interface fastEthernet0/1 encapsulation dot1q
Switch(config)# end

Una vez se aseguró que los paquetes del switch estaban pasando también por la interfaz del host de monitoreo se procedió a
realizar la captura de tramas con WireShark a través de la interfaz Ethernet.

2.5. Análisis de ICMP, ping de origen y destino, captura de trama, datagrama ip.
2.5.1. Análisis de trama ICMP y Ping entre origen y destino::
El ICMP o Internet Control Message Protocol se utiliza para enviar mensajes de error, en este caso particular de nuestro interés
indicando que el destino deseado no fue alcanzado. En el caso del laboratorio realizado, se utilizó el comando ping y cuando no
hubo una respuesta del Host buscado (al hacer una solicitud de ping entre 10.1.0.1 y 10.1.0.2) se obtuvo este tipo de protocolo
como respuesta:

6
 Figura 10: Captura de protocolos ICMP

Lo que nos interesa en este momento particular del paquete capturado son los bits de Identificador provenientes del header del
protocolo ICMP, estos bits nos permiten ver por qué el protocolo ICMP se hace presente. Estos bits a su vez están divididos en
dos grupos de 8 bits, uno para el tipo, que identifica exactamente el tipo de error que se presentó y 8 bits para el Código, estos 8
bits de código identifican con más detalle el tipo de error que se presentó. Según wireshark como se aprecia en la figura 10, el tipo
es 3, lo cual quiere decir Destination Unreachable y un código 1 que denota que el host no fue alcanzado por la solicitud. Este es
el comportamiento que se espera obtener en el primer paquete enviado del ping donde generalmente no hay una dirección MAC
guardada para la IP correspondiente. Si analizamos el header del datagrama podremos observar la siguiente información:

Figura 11: Analisis de Header para ICMP

Se muestra claramente que el protocolo ICMP cuenta también con un header de 20 bytes proveniente del protocolo Ethernet,
en este header podemos encontrar el identificador del tipo de protocolo, el tiempo de vida del paquete (255 en este caso como es
posible apreciar), la IP de origen, la IP de destino, la longitud del paquete y la versión de IP a utilizar.

Cuando el ping es exitoso se obtiene lo siguiente:

7
 Como se puede ver, el header del protocolo Ethernet se mantiene intacto puesto que el direccionamiento IP no cambia, lo
que cambia es el header del protocolo ICMP puesto que los bits de tipo y código tendrán un valor de cero, es decir, el código
correspondiente a un ping exitoso.

2.6. Escenario para la captura de ARP y RARP

Para crear la captura de ARP y RARP (además de haber configurado los puertos del switch en mirroring como se mencionó
anteriormente), se debı́a asegurar preferiblemente que las direcciones MAC fueran desconocidas por el dispositivo de capa 2, es
decir, el switch. Para hacer esto simplemente se guardó la configuración en la NVRAM y se reinició el switch. Una vez hecho
esto, se mandó una solicitud de ping entre dos host, al ser la primera vez que pasaba, el switch iba a tener que hacer una solicitud
ARP para buscar la dirección MAC necesaria. El paquete capturado es el siguiente:

Figura 12: Solicitud ARP vista en Wireshark

Como se conoce por la teorı́a, la solicitud ARP inicial debe ser enviada en broadcast por el switch con una dirección de destino
”FF FF FF FF FF FF.en la cual el dispositivo de capa 2 busca la dirección MAC asociada a la IP solicitada, esto es exactamente lo
que observamos en la trama capturada que se muestra en la figura 12.

En el encabezado del ARP podemos ver varios bytes, sin embargo los más importantes son la dirección MAC e IP del dispo-
sitivo que está haciendo el llamado para la solicitud ARP y las direcciónes MAC e IP de objetivo, encontrar esta dirección MAC
de objetivo es la razón de ser del ARP y hasta que no se encuentre la MAC asociada a la IP en cuestión, aparecerá representada
como 6 bytes repletos de ceros como se ve a continuación:

8
 Figura 13: Solicitud ARP vista en Wireshark

A nivel de estructura y encabezado, el RARP es muy similar al ARP, es más, WireShark los enmarca a ambos dentro del
formato ARP. Existen solamente dos diferencias principales, la primera es que el RARP se envı́a en unicast hacia el dispositivo
que hizo la solicitud ARP y que ya no se muestra la dirección MAC de objetivo como un conjunto de bytes repletos de ceros, la
RARP envı́a la dirección MAC puntual asociada a la IP de objetivo inicial. En otras palabras, el RARP le informa al dispositivo
que hizo la solicitud que esta ha sido exitosa, que el dispositivo ha sido encontrado y cual es su MAC.

Figura 14: Captura de un RARP en Wireshark

2.7. Configuración servidor TFTP

Para la configuracion de un servidor TFTP, en primer lugar se conecta al switch y se le asigna una IP en una red distinta
en este caso se opto por una direccion 192.168.1.4/24 con una puerta de enlace 192.168.1.1 como se agrega otra red, se tiene
que configurar una nueva vlan para el servidor en el switch con el mismo procedimiento con el cual se configuraron los hosts,
adicionalmente se debe crear la sub-interface en el router.
Para validar la configuracion se envia el archivo de configuracion del router al servidor TFTP como se muestra a continuacion
la transferencia del archivo es exitosa, apareciendo el archivo en la lista del servidor.

9
 (a) Envio de archivo de configuracion (b) Validacion de transferencia

Figura 15

Para la prueba en el laboratorio, se utilizo un computador adicional como servidor y se realizo el proceso de configuración
anteriormente mencionado. Se utilizo el programa Tftpd32 para generar el servidor y el cliente. Se debe habilitar la caracterı́stica
de Windows de los computadores de Cliente TFTP para poder realizar la transferencia. Enseguida se transfirió un archivo del Host
de claseB hacia el servidor, obteniendo la captura de trafico mostrada a continuación donde se evidencia las direcciones IP de
fuente y destino ası́ como el tipo de protocolo UDP según lo esperado.

Figura 16: Captura UDP servidor TFTP

2.8. Aseguramiento equipos de networking

En este caso, únicamente se requiere configurar el router, ya que el Host no requiere ninguna configuración adicional (su
función es únicamente replicar todas las señales por todos los puertos). Para este caso nuevamente se utiliza la configuración del
router mostrada en la sección 2.1, utilizando los mismos nombres y las mismas claves. El código empleado se muestra en la Figura
2b y en la Figura 17.

10
 Figura 17: Archivo .log de PuTTY para la configuración del Router

2.9. Configuración interfaces LAN

Para este caso, la configuración de interfaces LAN, únicamente se configura una sola interface del router que tendrá la capaci-
dad de empaquetar para cada IP diferente.

Figura 18: Archivo .log de PuTTY para la configuración de las IP del Router

11
2.10. Prueba de Conectividad
Para hacer la prueba de conectividad en PacketTracer existı́a un problema, debido a que el programa no funciona bien con este
tipo de configuración :

Figura 19: Simulación de la red

Sin embargo, se hicieron ping entre los dos terminales y hubo una respuesta correctamente. Se ve lo mismo que en la primera
parte cuando se probó la conectividad con la anterior red.

2.11. Captura de trama haciendo uso de WireShark

En esta oportunidad no hubo necesidad de hacer mirroring para que la interfaz que era utilizada por Wireshark fuera capaz
de recibir las tramas resultantes de la comunicación entre los dispositivos de la red. Esto se debió principalmente a que el HUB
por su misma naturaleza se encarga de replicar los paquetes que lleguen por alguna de sus interfaces hacia los demás dispositivos
conectados a él, esto quiere decir que el host que harı́a el monitoreo con Wireshark iba a estar recibiendo cualquier comunicación
que ocurriera en la red.

2.12. Análisis de ICMP, ping de origen y destino, captura de trama, datagrama ip.
2.12.1. Análisis de trama ICMP y Ping entre origen y destino::
El En el caso las tramas de protocolo ICMP no variaron respecto a lo que se encontró en el switch, nuevamente el header ICMP
contenı́a un tipo 3 que hacı́a referencia a un destino inalcanzable y un código 1 para hacer la aclaración de que esto se debı́a a un
Host Inalcanzable. Igualmente, el encabezado de IP contenı́a la IP de origen, la de destino y el tipo de IP.

12
 Figura 20: Captura de protocolos ICMP en la red con el HUB

Igualmente, cuando se trata de una solicitud de ping exitosa encontramos nuevamente un encabezado de IP igual a una solicitud
fallida y en el header de ICMP el tipo y el código son iguales a cero, lo cual quiere indicar que la solicitud fue llevada a cabo con
éxito.

Figura 21: ICMP de un ping exitoso en la red con Hub

2.13. Escenario para la captura de ARP y RARP

Como el HUB no guarda las direcciones MAC de los dispositivos conectados a sus interfaces, se optó simplemente por hacer
una limpieza de las tablas MAC de los host para que estos emitieran una solicitud ARP. La única diferencia sustancial que se
encontró es que la solicitud ARP no serı́a hecha por el switch sino por uno de los host. Esta solicitud ARP se hizo igualmente en
bradcast y con todos los bytes de dirección objetivo iguales a cero.

13
 Figura 22: Solicitud ARP vista en Wireshark

En el caso del RARP tampoco se encontró ningún cambio sustancial, como era de esperarse el RARP fue enviado en unicast
en dirección del Host que habı́a hecho la solicitud.

Figura 23: Captura RARP Hub

3. Conclusiones
Haciendo una correcta configuración de los equipos de networking, en este caso Switch, Hub y Router, se evidenció el
funcionamiento de la red la cual requerı́a hosts con diferentes clases de diracción IP. Por un lado se tiene el uso se interfaces
virtuales del switch y su correcto uso de los modos de acceso de cada uno de los puertos. Por otro lado se tiene la configu-
ración de subinterfaces ethernet del router con el fin de enrutar adecuadamente la información de los host. En el otro caso
no se hizo necesaria una configuración del Hub, pero si se realizó una configuración diferente al router, utilizando diracción
IP secundaria para una interfaz ethernet.

14
Se evidencia la importancia de la configuración adecuada del host. En este caso la asignación de dirección IP estática con la
cual se requieren conceptos de IP addressing, subneting, y establecimiento de default gateway para cada uno de los equipos.

Se debe configurar correctamente el router porque es el que encapsula la información antes de ser enviada a otro segmento
de red, independiente del dispositivo intermedio entre el router y los hosts.

15