Mostrando entradas con la etiqueta Prácticas de laboratorio. Mostrar todas las entradas
Mostrando entradas con la etiqueta Prácticas de laboratorio. Mostrar todas las entradas

Configuración de Enlaces Troncales y VLANs (Práctica con Packet Tracer)

Objetivo:

Implementar VLANs y enlaces troncales (Trunks) en una topología de red con múltiples switches para permitir la comunicación eficiente entre departamentos segmentados a través de un único cable físico.

Escenario:

  • Redes / VLANs: VLAN 10 (Administración - 192.168.10.0/24), VLAN 20 (Gestión - 192.168.20.0/24), VLAN 30 (Invitados - 192.168.30.0/24).
  • Puertos de Acceso: Conectados a dispositivos finales (PCs). Pertenecen a una sola VLAN y entregan los datos limpios (sin etiquetas).
  • Puertos Troncales (Trunks): Conectan los switches entre sí permitiendo el paso de múltiples VLANs mediante el estándar 802.1Q, el cual añade una etiqueta identificadora a cada trama.

Instrucciones:

Fase 1: Creación de VLANs y Puertos de Acceso en Switches de Acceso

En cada switch de acceso, crea las VLANs y asigna los puertos correspondientes para las computadoras:

Switch> enable
Switch# configure terminal
Switch(config)# vlan 10
Switch(config-vlan)# name Administracion
Switch(config)# vlan 20
Switch(config-vlan)# name Gestion
Switch(config)# vlan 30
Switch(config-vlan)# name Invitados
Switch(config)# exit
Asignación de puertos de acceso: 
Switch(config)# interface fastEthernet 0/1
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 10
Switch(config-if)# exit

Switch(config)# interface fastEthernet 0/2
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 20
Switch(config-if)# exit

Switch(config)# interface fastEthernet 0/3
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 30
Switch(config-if)# exit

Fase 2: Configuración de Enlaces Troncales (Trunks)

Configura los puertos que conectan los switches de acceso hacia el switch principal en modo troncal:

Switch(config)# interface gigabitEthernet 0/1
Switch(config-if)# switchport mode trunk
Switch(config-if)# exit

Fase 3: Configuración del Switch Principal (Distribución)

En el switch central, es indispensable crear las mismas VLANs para que reconozca el tráfico etiquetado, y configurar los puertos de enlace en bloque mediante rangos:

Switch(config)# vlan 10
Switch(config)# vlan 20
Switch(config)# vlan 30
Switch(config)# exit
Configurar múltiples puertos troncales en rango: 
Switch(config)# interface range fastEthernet 0/1 - 3
Switch(config-if-range)# switchport mode trunk
Switch(config-if-range)# exit

Verificación:

  • Usa el comando show vlan brief para comprobar la correcta asignación de puertos a las VLANs.
  • Usa el comando show interfaces trunk para verificar los enlaces troncales activos bajo el protocolo 802.1Q.
  • Comprueba la conectividad mediante ping entre PCs que pertenezcan a la misma VLAN en diferentes switches.

Preguntas de reflexión:

  1. ¿Por qué es necesario crear las VLANs también en el switch principal de distribución si las PCs están conectadas a los switches de acceso?
  2. ¿Cuál es la función principal del estándar 802.1Q al viajar múltiples VLANs a través de un solo enlace troncal?
  3. ¿Qué ocurriría con el tráfico de las VLANs si intentas conectar un switch a otro utilizando un puerto configurado en modo de acceso en lugar de modo troncal?
Haz clic aquí para ver las soluciones y explicaciones

1. ¿Por qué es necesario crear las VLANs también en el switch principal de distribución?

Porque si el switch principal no tiene registradas las VLANs en su base de datos local, no sabrá qué hacer con las tramas etiquetadas que recibe a través del enlace troncal y simplemente descartará el tráfico.

2. ¿Cuál es la función principal del estándar 802.1Q?

Actúa como un identificador o "etiqueta" que se le adjunta a cada trama de datos antes de cruzar por el enlace troncal. Esto permite que el switch receptor sepa exactamente a qué VLAN pertenece cada paquete sin que se mezclen los departamentos.

3. ¿Qué ocurriría si configuras los puertos de interconexión en modo de acceso en lugar de troncal?

El enlace solo permitiría el paso del tráfico perteneciente a una única VLAN (por defecto la VLAN 1), bloqueando o filtrando el tráfico de las demás redes y rompiendo la segmentación multicapa prevista en la topología.

Análisis del Protocolo ARP (Práctica con Wireshark)

Objetivo:

Analizar mediante Wireshark el funcionamiento de las tramas Ethernet y el Protocolo ARP (Address Resolution Protocol) a nivel de la capa de enlace de datos, examinando las direcciones MAC de origen y destino, así como los procesos de resolución de direcciones IP.

Escenario:

  • Herramientas: Wireshark, Navegador web.
  • Protocolos analizados: Ethernet II, ARP (Address Resolution Protocol), IP, TCP, HTTP.
  • Proceso clave: Limpieza de caché del navegador, captura de tráfico al acceder a una página web y filtrado de tramas de enlace y resolución de direcciones.



Instrucciones:

Fase 1: Preparación del entorno y limpieza de caché:

  • Acceder a la configuración del navegador web y proceder a borrar los datos de navegación y caché (imágenes y archivos almacenados temporalmente) para forzar peticiones de red reales.
  • Abrir Wireshark, seleccionar la interfaz de red activa y comenzar la captura de paquetes.
  • Introducir la URL de prueba o acceder a un sitio web de referencia para generar tráfico HTTP y de resolución de red.

Fase 2: Filtrado y análisis de tramas Ethernet II:

  • Filtrar la captura en Wireshark utilizando el protocolo http para localizar la petición enviada.
  • Expandir la sección Ethernet II en los detalles del paquete para examinar las direcciones físicas de la capa de enlace:
    • Source (Origen): Dirección MAC física de la tarjeta de red del equipo local (a menudo una dirección administrada localmente).
    • Destination (Destino): Dirección MAC del router o pasarela predeterminada (perteneciente a un bloque globalmente único).
  • Inspeccionar los metadatos globales del paquete (Frame), observando la longitud de la trama, el tiempo de llegada (Arrival Time) y los protocolos encapsulados.

Fase 3: Análisis de mensajes y tablas ARP (Address Resolution Protocol):

  • Filtrar la traza introduciendo arp en la barra de búsqueda de Wireshark para aislar los paquetes de resolución de direcciones.
  • Examinar los campos internos de una trama ARP de solicitud o respuesta:
    • Hardware Type y Protocol Type: Indican el tipo de red física (Ethernet) y el protocolo de capa superior (IPv4).
    • Opcode (Código de operación): Especifica si se trata de una solicitud (Request, valor 1) o de una respuesta (Reply).
    • Sender / Target MAC & IP Addresses: Muestran las asociaciones entre las direcciones IP y las direcciones físicas MAC tanto del emisor como del objetivo.

Verificación:

  • Comprobar mediante los detalles de Ethernet que las direcciones MAC de origen y destino se identifican correctamente en cada trama.
  • Verificar el intercambio de tramas ARP previas a la comunicación IP cuando se requiere asociar una IP con una dirección física.

Preguntas de reflexión:

  1. ¿En qué capa del modelo de red operan Ethernet y el protocolo ARP, y cuál es su función principal frente a las capas superiores?
  2. ¿Qué diferencia existe entre la dirección MAC de origen (física) y la dirección MAC de destino que aparecen en una trama Ethernet capturada?
  3. ¿Por qué es necesario vaciar la caché del navegador antes de realizar una captura destinada a analizar tramas de red y peticiones HTTP iniciales?
  4. ¿Qué es el protocolo ARP (Address Resolution Protocol) y para qué se utiliza en una red de área local?
  5. ¿Qué información aporta el campo Opcode dentro de un paquete ARP y qué valor numérico indica una petición de resolución?
Haz clic aquí para ver las soluciones y explicaciones

1. ¿En qué capa del modelo de red operan Ethernet y el protocolo ARP, y cuál es su función principal frente a las capas superiores?

Ethernet y ARP operan en la capa de enlace de datos (Data Link Layer), encargándose del direccionamiento físico local y de la transferencia fiable de tramas a través del medio físico compartido entre dispositivos adyacentes [00:00:06], [00:04:56].

2. ¿Qué diferencia existe entre la dirección MAC de origen (física) y la dirección MAC de destino que aparecen en una trama Ethernet capturada?

La dirección MAC de origen corresponde al identificador físico único de la interfaz de red del equipo emisor, mientras que la dirección MAC de destino corresponde a la interfaz del siguiente salto físico en la red local (por lo general, el router o pasarela) [00:02:11].

3. ¿Por qué es necesario vaciar la caché del navegador antes de realizar una captura destinada a analizar tramas de red y peticiones HTTP iniciales?

Se limpia la caché para asegurar que el navegador no recupere elementos almacenados localmente, obligándolo a realizar una petición real a través de la red y permitiendo capturar todo el flujo de intercambio de paquetes desde cero [00:00:39].

4. ¿Qué es el protocolo ARP (Address Resolution Protocol) y para qué se utiliza en una red de área local?

ARP es un protocolo de soporte de red utilizado para traducir o resolver direcciones de capa de red (direcciones IP) en direcciones físicas de hardware (direcciones MAC) dentro de una red de área local [00:04:56].

5. ¿Qué información aporta el campo Opcode dentro de un paquete ARP y qué valor numérico indica una petición de resolución?

El campo Opcode define el tipo de operación que realiza el mensaje ARP dentro de la red. Habitualmente, el valor numérico 1 se utiliza para identificar una solicitud (ARP Request) [00:05:29].





Ficha de Laboratorio: Análisis de Ethernet y ARP con Wireshark

Instrucciones de entrega:

  1. Rellena los campos de texto y responde a las cuestiones directamente en este formulario desde tu navegador.
  2. Una vez completada la ficha, pulsa el botón de imprimir que aparece al final.
  3. En el cuadro de diálogo de impresión, selecciona la opción "Guardar como PDF" o "Imprimir a PDF".
  4. Entrega el archivo PDF resultante a través de la plataforma del aula virtual.

Alumno/a:      Fecha:      Grupo / Clase:

1. Identificación del Entorno de Pruebas

Indica los detalles de la interfaz monitorizada y los filtros de Wireshark:

2. Cuestionario de Análisis de Enlace

  1. ¿Qué representa la capa de enlace de datos y qué rol desempeñan protocolos como Ethernet en la comunicación local?
  2. Explica el propósito de vaciar la caché del navegador antes de realizar una captura de tráfico enfocada en el análisis de peticiones web y tramas asociadas.
  3. ¿Cómo funciona el protocolo ARP y qué relación establece entre las direcciones IP y las direcciones físicas MAC?

3. Registro de Direcciones Físicas Observadas

Indica los parámetros de direccionamiento físico obtenidos en las trazas:

Análisis del protocolo ICMP (Práctica con Wireshark)

Objetivo:

Analizar mediante Wireshark y la ejecución del comando ping el funcionamiento del protocolo ICMP (Internet Control Message Protocol), identificando las peticiones de eco (Echo Request), las respuestas (Echo Reply) y los códigos de error en la red.

Escenario:

  • Herramientas: Wireshark, Línea de comandos.
  • Protocolos analizados: ICMP (Internet Control Message Protocol), IP.
  • Proceso clave: Envío de mensajes de sondeo mediante el comando ping hacia destinos externos y captura de tramas de solicitud y respuesta.



Instrucciones:

Fase 1: Preparación de la captura en Wireshark y ejecución de comandos ping:

  • Abrir Wireshark y seleccionar la interfaz de red activa para iniciar la captura de tráfico.
  • Abrir la consola de comandos en el sistema operativo y ejecutar una prueba de conectividad enviando múltiples paquetes de eco (ej. ping -n 10 spsu.edu.in o hacia un dominio de referencia).
  • Observar la recepción de los paquetes de respuesta y comprobar si se producen pérdidas de paquetes (request timed out).

Fase 2: Filtrado y análisis de mensajes ICMP en Wireshark:

  • Detener la captura en Wireshark e introducir el filtro icmp en la barra de búsqueda para aislar exclusivamente las tramas de control ICMP.
  • Identificar en las trazas los pares de mensajes correspondientes a la solicitud de eco (Echo Request) y a la respuesta de eco (Echo Reply).

Fase 3: Inspección de los campos de la cabecera ICMP:

Al expandir la capa ICMP de un paquete capturado en Wireshark, se examinan los siguientes elementos de control:

  • Type (Tipo): Indica la clase de mensaje ICMP (por ejemplo, tipo 8 para petición de eco o tipo 0 para respuesta de eco).
  • Code (Código): Especifica información adicional o subcategorías del tipo de mensaje (habitualmente con valor 0 en piques estándar).
  • Checksum: Campo de verificación de errores para asegurar la integridad de la cabecera y los datos del mensaje.
  • Identifier y Sequence Number: Parámetros utilizados para emparejar las solicitudes salientes con sus respectivas respuestas entrantes.
  • Data (Datos): Carga útil o bloque de bytes de datos enviados en la solicitud de eco (ej. bloques de 32 bytes).

Verificación:

  • Comprobar mediante el filtro icmp que las tramas muestran un estado de checksum correcto (good).
  • Verificar el intercambio fluido de peticiones y respuestas entre la dirección IP de origen local y el destino remoto.

Preguntas de reflexión:

  1. ¿Qué es el protocolo ICMP y en qué capa del modelo OSI/TCP-IP opera principalmente?
  2. ¿Cuáles son las dos funciones principales para las que se utiliza el protocolo ICMP en una red de ordenadores?
  3. ¿Cómo utiliza el comando ping los mensajes de tipo Echo Request y Echo Reply para comprobar la alcanzabilidad de un host remoto?
  4. ¿Qué información aporta el campo Type dentro de la cabecera ICMP y qué valores numéricos representan normalmente la solicitud y la respuesta de eco?
  5. ¿Qué utilidad tienen los campos Identifier y Sequence Number en los datagramas ICMP durante una prueba de red?
Haz clic aquí para ver las soluciones y explicaciones

1. ¿Qué es el protocolo ICMP y en qué capa del modelo OSI/TCP-IP opera principalmente?

ICMP (Internet Control Message Protocol) es un protocolo de capa de red (Capa 3) utilizado principalmente para el reporte de errores y la transmisión de información operativa en arquitecturas IP [00:00:08].

2. ¿Cuáles son las dos funciones principales para las que se utiliza el protocolo ICMP en una red de ordenadores?

Sus funciones principales son la gestión de la red para la transferencia de mensajes de control y el reporte de errores de conectividad (diagnóstico) [00:00:16], [00:01:07].

3. ¿Cómo utiliza el comando ping los mensajes de tipo Echo Request y Echo Reply para comprobar la alcanzabilidad de un host remoto?

El comando genera un mensaje de solicitud de eco (Echo Request) que se envía hacia el host de destino; si el nodo está activo y accesible, este responde devolviendo un paquete de respuesta de eco (Echo Reply) [00:00:30].

4. ¿Qué información aporta el campo Type dentro de la cabecera ICMP y qué valores numéricos representan normalmente la solicitud y la respuesta de eco?

El campo Type define la categoría del mensaje ICMP [00:01:16]. Por regla general, el tipo 8 se emplea para identificar las peticiones de eco (ping request) y el tipo 0 se utiliza para las respuestas de eco (ping reply) [00:03:59], [00:04:37].

5. ¿Qué utilidad tienen los campos Identifier y Sequence Number en los datagramas ICMP durante una prueba de red?

Sirven para identificar de forma unívoca la sesión de sondeo y llevar un control secuencial de cada paquete enviado y recibido, permitiendo asociar de manera correcta cada respuesta con su respectiva petición [00:04:18].





Ficha de Laboratorio: Análisis del Protocolo ICMP con Wireshark

Instrucciones de entrega:

  1. Rellena los campos de texto y responde a las cuestiones directamente en este formulario desde tu navegador.
  2. Una vez completada la ficha, pulsa el botón de imprimir que aparece al final.
  3. En el cuadro de diálogo de impresión, selecciona la opción "Guardar como PDF" o "Imprimir a PDF".
  4. Entrega el archivo PDF resultante a través de la plataforma del aula virtual.

Alumno/a:      Fecha:      Grupo / Clase:

1. Identificación del Entorno de Pruebas

Indica los parámetros de ejecución del comando ping y la interfaz capturada:

2. Cuestionario de Análisis ICMP

  1. ¿Qué función desempeña el protocolo ICMP dentro de la arquitectura de red y en qué se diferencia de los protocolos de transporte como TCP o UDP?
  2. Explica qué representan los valores de los campos Type y Code al inspeccionar una trama ICMP de solicitud y respuesta de eco en Wireshark.
  3. ¿Por qué es importante verificar el estado del campo Checksum al analizar paquetes de diagnóstico de red?

3. Registro de Datos de Paquetes Capturados

Indica los valores observados en las tramas analizadas:

Análisis del protocolo NAT (Práctica con Wireshark)

Objetivo:

Analizar mediante archivos de trazas en Wireshark el funcionamiento del protocolo NAT (Network Address Translation), observando cómo un router perimetral traduce las direcciones IP privadas de una red local a direcciones públicas y cómo gestiona los puertos (PAT).

Escenario:

  • Herramientas: Wireshark.
  • Protocolos analizados: NAT (Network Address Translation), TCP/IP, HTTP.
  • Archivos de trazas de referencia: Ficheros de captura correspondientes al lado de la red doméstica (Home Site) y al lado del ISP (ISP Site).



Instrucciones:

Fase 1: Configuración de columnas y análisis inicial en el lado local (Home Site):

  • Abrir el archivo de trazas del lado doméstico en Wireshark.
  • Personalizar las vistas haciendo clic derecho sobre la cabecera de las columnas, seleccionando Column Preferences y añadiendo una columna de tiempo con el formato específico requerido.
  • Aplicar el filtro http combinado con la dirección IP pública de destino (por ejemplo, el servidor de Google) para localizar el momento exacto en el que se realiza una petición HTTP GET y su respuesta correspondiente.
  • Anotar la dirección IP privada de origen, la dirección IP de destino y el puerto de origen local (ej. puerto TCP 4335).

Fase 2: Comparación de trazas en el lado del ISP (ISP Site):

  • Abrir el archivo de trazas correspondiente al lado del proveedor de servicios de Internet (ISP) en Wireshark para observar los paquetes tal y como viajan hacia la red externa.
  • Localizar el paquete equivalente buscando la marca de tiempo aproximada de la solicitud.
  • Comprobar cómo la dirección IP privada local ha sido reemplazada en la cabecera IP por una dirección IP pública unificada perteneciente al router NAT.

Fase 3: Análisis de la traducción de puertos (PAT - Port Address Translation):

  • Inspeccionar las capas de transporte (TCP) en ambos lados de la comunicación.
  • Verificar que, aunque múltiples dispositivos de la red local utilicen la misma IP pública de salida proporcionada por el NAT, el router asigna un puerto único de salida (ej. puerto TCP 4337) a cada conexión para identificar inequívocamente al dispositivo emisor original.

Verificación:

  • Comprobar la correspondencia de tiempos y peticiones HTTP entre el archivo local y el de ISP.
  • Verificar el cambio dinámico de las direcciones IP de origen y los puertos TCP en las trazas analizadas.

Preguntas de reflexión:

  1. ¿Qué es el protocolo NAT (Network Address Translation) y por qué es fundamental para la seguridad y el ahorro de direcciones IPv4 [00:00:06]?
  2. ¿Cuál es la diferencia principal entre utilizar direcciones IP privadas en una red local y exponer una dirección IP pública a través del router NAT [00:00:30]?
  3. ¿Cómo utiliza el router NAT la tabla de traducción de direcciones y puertos (PAT) para diferenciar el tráfico de varios equipos locales que acceden al mismo servicio externo [00:01:08]?
  4. Al comparar las trazas de Wireshark del lado Home Site frente al lado ISP Site, ¿qué cambios se aprecian exactamente en las cabeceras de los paquetes IP [00:05:59]?
  5. ¿Qué ocurre con el número de puerto de origen (Source Port) cuando el paquete atraviesa el router NAT hacia la red exterior [00:08:30]?
Haz clic aquí para ver las soluciones y explicaciones

1. ¿Qué es el protocolo NAT (Network Address Translation) y por qué es fundamental para la seguridad y el ahorro de direcciones IPv4?

NAT es un método utilizado para modificar la información de direcciones de red en las cabeceras de los paquetes mientras transitan por un router [00:00:06]. Permite que toda una red local utilice un conjunto de direcciones IP privadas ocultas al exterior, mejorando la seguridad y mitigando el agotamiento de direcciones IPv4 [00:00:38].

2. ¿Cuál es la diferencia principal entre utilizar direcciones IP privadas en una red local y exponer una dirección IP pública a través del router NAT?

Las direcciones privadas no son enrutable en Internet y solo tienen validez dentro de la red de área local (LAN), lo que impide que equipos externos accedan directamente a los dispositivos internos. El router NAT actúa como pasarela traduciendo esas direcciones privadas a una única IP pública asignada por el ISP [00:00:56].

3. ¿Cómo utiliza el router NAT la tabla de traducción de direcciones y puertos (PAT) para diferenciar el tráfico de varios equipos locales que acceden al mismo servicio externo?

El router mantiene una tabla de traducción donde asocia la combinación de IP privada y puerto de origen del equipo local con la IP pública de salida y un puerto específico asignado por el router, permitiendo reenviar correctamente la respuesta al equipo correcto cuando esta regresa [00:01:08].

4. Al comparar las trazas de Wireshark del lado Home Site frente al lado ISP Site, ¿qué cambios se aprecian exactamente en las cabeceras de los paquetes IP?

En el lado doméstico se visualiza la dirección IP privada original del host local (ej. rango 192.168.x.x), mientras que en el lado del ISP dicha dirección IP de origen es modificada y reemplazada por la dirección IP pública del router NAT [00:05:59].

5. ¿Qué ocurre con el número de puerto de origen (Source Port) cuando el paquete atraviesa el router NAT hacia la red exterior?

El puerto de origen suele ser modificado o reasignado por el router NAT (por ejemplo, pasando de un puerto local a un puerto único de salida como el 4337) para asegurar que las conexiones de diferentes clientes locales no entren en conflicto al compartir la misma IP pública [00:08:30].





Ficha de Laboratorio: Análisis del Protocolo NAT con Wireshark

Instrucciones de entrega:

  1. Rellena los campos de texto y responde a las cuestiones directamente en este formulario desde tu navegador.
  2. Una vez completada la ficha, pulsa el botón de imprimir que aparece al final.
  3. En el cuadro de diálogo de impresión, selecciona la opción "Guardar como PDF" o "Imprimir a PDF".
  4. Entrega el archivo PDF resultante a través de la plataforma del aula virtual.

Alumno/a:      Fecha:      Grupo / Clase:

1. Identificación del Entorno de Análisis

Indica los ficheros de trazas utilizados y los filtros aplicados en Wireshark:

2. Cuestionario de Análisis de Traducción

  1. ¿Qué función principal realiza el router NAT al interconectar una red local privada con Internet y por qué modifica las cabeceras de los paquetes?
  2. Explica qué diferencias has encontrado al analizar una misma petición HTTP en el archivo Home Site frente al archivo ISP Site.
  3. ¿Cómo interviene el control de puertos (PAT) en la traducción de direcciones para evitar conflictos entre múltiples equipos de la red local?

3. Registro de Parámetros de Red Observados

Indica los valores de IP y puertos anotados durante la práctica:

Análisis del funcionamiento del protocolo IP (Práctica con Wireshark)

Objetivo:

Analizar con Wireshark y herramientas de diagnóstico de red el funcionamiento del protocolo IP (Internet Protocol), el uso de mensajes ICMP, el mecanismo de ruta con Traceroute/Ping Plotter (TTL) y el proceso de fragmentación de paquetes.

Escenario:

  • Herramientas: Wireshark, Ping Plotter (o comando traceroute).
  • Protocolos analizados: IP (Internet Protocol), ICMP (Internet Control Message Protocol).
  • Proceso clave: Trazado de ruta de red, inspección de la cabecera IP, control de TTL (Time to Live) y análisis de fragmentación de datagramas.



Instrucciones:

Fase 1: Preparación del entorno y captura ICMP:

  • Abrir Wireshark y seleccionar la interfaz de red activa para iniciar la captura de paquetes.
  • Introducir el filtro icmp en la barra de filtros de Wireshark para aislar únicamente los mensajes de control.
  • Abrir la herramienta Ping Plotter (o utilizar el comando tracert / traceroute en la terminal) e introducir un dominio o dirección IP de destino para generar tráfico de sondeo en red.

Fase 2: Análisis del funcionamiento del TTL (Time to Live) y saltos intermedios:

  • Observar en Ping Plotter cómo se listan los routers o nodos intermedios (saltos u hops) que atraviesa el paquete hasta llegar al destino final, midiendo la latencia y la pérdida de paquetes.
  • Identificar en Wireshark cómo los mensajes ICMP devuelven avisos de tiempo excedido cuando el valor de TTL expira en los routers intermedios.
  • Comprobar cómo al modificar o limitar el TTL (ej. TTL=1), el paquete solo alcanza el primer enrutador y rebota de vuelta generando un mensaje de aviso.

Fase 3: Inspección de la cabecera IP en Wireshark:

Al expandir un paquete capturado en Wireshark y revisar la sección Internet Protocol Version 4 (IPv4), se analizan los siguientes campos clave:

  • Versión y Longitud de Cabecera (Header Length): Indica la versión del protocolo IP (ej. IPv4) y el tamaño de su cabecera.
  • Servicios Diferenciados (Differentiated Services): Utilizado para la priorización de tráfico (QoS).
  • Identificación, Flags y Fragment Offset: Campos críticos encargados de gestionar la fragmentación y el reensamblaje cuando un datagrama supera la MTU (Unidad Máxima de Transmisión) de la red.
  • Tiempo de Vida (TTL - Time to Live): Contador de saltos que evita bucles infinitos en la red, decrementándose en cada router.
  • Protocolo de Capa Superior: Indica qué protocolo viaja encapsulado dentro de la carga útil IP (por ejemplo, ICMP con valor 1 o TCP/UDP).
  • Direcciones IP de Origen y Destino: Identifican inequívocamente el host emisor y el receptor final.

Fase 4: Análisis de fragmentación IP:

  • Comprobar mediante trazas de ejemplo (o enviando datagramas de gran tamaño) cómo los paquetes que superan la unidad máxima de transmisión (MTU) se dividen en fragmentos más pequeños.
  • Analizar los identificadores de fragmento en Wireshark para verificar cómo el host receptor reconstruye el paquete original utilizando los campos de desplazamiento (fragment offset).

Verificación:

  • Comprobar mediante el filtro de Wireshark el intercambio correcto de tramas ICMP asociadas al diagnóstico de ruta.
  • Verificar el valor del campo TTL y los campos de direccionamiento IP en los detalles del paquete.

Preguntas de reflexión:

  1. ¿Qué es el protocolo ICMP y con qué propósito principal se utiliza en redes junto con el protocolo IP?
  2. ¿Cómo funciona el campo TTL (Time to Live) dentro de la cabecera IP y qué ocurre exactamente cuando su valor llega a cero?
  3. ¿Qué función cumple la herramienta Traceroute (o Ping Plotter) y cómo se apoya en los mensajes ICMP y el TTL para mapear una ruta de red?
  4. ¿Por qué es necesario el proceso de fragmentación a nivel de IP y qué campos de la cabecera IPv4 intervienen en él?
  5. ¿Qué indica el campo "Protocol" dentro de la cabecera IP y qué valor numérico suele mostrar cuando transporta mensajes ICMP?
Haz clic aquí para ver las soluciones y explicaciones

1. ¿Qué es el protocolo ICMP y con qué propósito principal se utiliza en redes junto con el protocolo IP?

ICMP (Internet Control Message Protocol) es un protocolo de control y gestión de errores utilizado por los dispositivos de red para enviar mensajes de diagnóstico (como informes de errores cuando un servicio no está disponible o avisos de control de ruta) complementando la entrega de paquetes IP [00:04:10].

2. ¿Cómo funciona el campo TTL (Time to Live) dentro de la cabecera IP y qué ocurre exactamente cuando su valor llega a cero?

El TTL es un contador de saltos que se decrementa en uno cada vez que un paquete pasa por un enrutador [00:08:44]. Si el contador llega a cero antes de alcanzar el destino, el router descarta el paquete y devuelve un mensaje ICMP de "Tiempo de Vida Excedido" (*Time-to-Live Exceeded*) al origen [00:06:07].

3. ¿Qué función cumple la herramienta Traceroute (o Ping Plotter) y cómo se apoya en los mensajes ICMP y el TTL para mapear una ruta de red?

Traceroute envía paquetes incrementando deliberadamente el valor del TTL (comenzando en 1) [00:05:45]. De este modo, fuerza a que cada router sucesivo en la ruta rechace el paquete por TTL agotado y devuelva un mensaje ICMP, permitiendo registrar la dirección IP de cada salto intermedio [00:01:30].

4. ¿Por qué es necesario el proceso de fragmentación a nivel de IP y qué campos de la cabecera IPv4 intervienen en él?

La fragmentación es necesaria cuando un datagrama IP es mayor que la Unidad Máxima de Transmisión (MTU) permitida por la interfaz de red por la que debe salir [00:06:38]. Intervienen campos como la Identificación, los Flags (banderas de división) y el Fragment Offset (desplazamiento) para permitir su correcto reensamblaje en destino.

5. ¿Qué indica el campo "Protocol" dentro de la cabecera IP y qué valor numérico suele mostrar cuando transporta mensajes ICMP?

El campo de protocolo indica qué protocolo de nivel superior encapsula los datos dentro del paquete IP [00:04:13]. Cuando transporta tráfico ICMP, este campo muestra el valor numérico 1.





Ficha de Laboratorio: Análisis de Protocolo IP, ICMP y TTL con Wireshark

Instrucciones de entrega:

  1. Rellena los campos de texto y responde a las cuestiones directamente en este formulario desde tu navegador.
  2. Una vez completada la ficha, pulsa el botón de imprimir que aparece al final.
  3. En el cuadro de diálogo de impresión, selecciona la opción "Guardar como PDF" o "Imprimir a PDF".
  4. Entrega el archivo PDF resultante a través de la plataforma del aula virtual.

Alumno/a:      Fecha:      Grupo / Clase:

1. Identificación del Entorno

Indica la interfaz de red utilizada y la herramienta de diagnóstico ejecutada:

2. Cuestionario de Análisis en Wireshark

  1. ¿Qué filtro has aplicado en Wireshark para aislar el tráfico analizado y qué tipo de mensajes ICMP se generan al realizar un seguimiento de ruta?
  2. Explica qué función cumple el campo TTL (Time to Live) en la cabecera IP y cómo reacciona un router intermedio cuando este llega a cero.
  3. ¿Qué campos principales componen la sección IPv4 al inspeccionar los detalles de un paquete capturado en Wireshark?

3. Verificación de Cabecera IP y Direccionamiento

Indica los parámetros de red observados en un paquete analizado:

Análisis del protocolo UDP (Práctica con Wireshark)

Objetivo:

Analizar con Wireshark el funcionamiento del protocolo UDP (User Datagram Protocol), su simplicidad frente a TCP, la estructura de su cabecera sin conexión y su uso en aplicaciones de streaming modernas como YouTube mediante el protocolo QUIC.

Escenario:

  • Herramientas: Wireshark, navegador web (para generar tráfico de streaming).
  • Protocolo analizado: UDP (User Datagram Protocol) y QUIC (Quick UDP Internet Connections).
  • Proceso clave: Captura de datagramas UDP, inspección de puertos de origen/destino, longitud, checksum y análisis de protocolos de capa superior basados en UDP.



Instrucciones:

Fase 1: Preparación y captura de tráfico UDP:

  • Abrir Wireshark y seleccionar la interfaz de red activa (por ejemplo, Wi-Fi o eth0) para iniciar la captura de paquetes.
  • Introducir el filtro udp en la barra de filtros de Wireshark para aislar únicamente los datagramas UDP.
  • Observar cómo fluyen datagramas UDP de manera desordenada y sin establecimiento previo de conexión (sin handshake).

Fase 2: Generación de tráfico de streaming y protocolo QUIC:

  • Dado que el tráfico UDP genérico puede no ser constante, abrir un navegador web y reproducir un vídeo en streaming (por ejemplo, en YouTube).
  • Detener la captura en Wireshark y buscar datagramas UDP asociados a servicios de vídeo.
  • Identificar el protocolo de capa superior encapsulado sobre UDP, concretamente el protocolo QUIC (QUIC UDP Internet Connections) estandarizado por el IETF.
  • Analizar por qué YouTube utiliza QUIC sobre UDP: para multiplexar múltiples streams de datos y mejorar el rendimiento web, la seguridad y la privacidad en tiempo real.

Fase 3: Análisis de la cabecera UDP en Wireshark:

Al expandir un paquete UDP en el panel de detalles de Wireshark, se examinan los campos mínimos de su cabecera:

  • Puerto de Origen (Source Port): Identifica el puerto lógico del proceso emisor en el host cliente o servidor.
  • Puerto de Destino (Destination Port): Identifica el puerto lógico del servicio receptor (ej. SNMP, DNS, QUIC, etc.).
  • Longitud (Length): Indica la longitud total en bytes del datagrama UDP, incluyendo la cabecera (8 bytes) y los datos de la carga útil (payload).
  • Sumas de Verificación (Checksum): Campo opcional en IPv4 (obligatorio en IPv6) utilizado para la detección de errores básicos en la cabecera y los datos.

Fase 4: Comparación entre UDP y protocolos con control de flujo:

  • Comprobar que a diferencia de TCP, UDP no utiliza números de secuencia, acuses de recibo (ACKs) ni retransmisiones automáticas en su capa de transporte pura.
  • Reflexionar sobre cómo los protocolos modernos de streaming (como QUIC sobre UDP) añaden sus propios mecanismos de control de pérdida y reensamblaje a nivel de aplicación para compensar la simplicidad de UDP.

Verificación:

  • Comprobar mediante el filtro de Wireshark la presencia de datagramas UDP y su relación con protocolos avanzados como QUIC.
  • Verificar los cuatro campos principales de la cabecera UDP (Puertos, Longitud y Checksum).

Preguntas de reflexión:

  1. ¿Por qué se define a UDP como un protocolo "sin conexión" (connectionless) y qué implicaciones tiene esto en comparación con TCP?
  2. ¿Cuáles son los cuatro campos fundamentales que componen la cabecera de un paquete UDP?
  3. ¿Qué es el protocolo QUIC (IETF) y por qué se ejecuta sobre UDP en lugar de TCP para plataformas de streaming como YouTube?
  4. Si UDP no incluye números de secuencia ni control de flujo nativo, ¿cómo consiguen las aplicaciones de vídeo reensamblar los paquetes correctamente?
  5. ¿En qué escenarios de red resulta más ventajoso utilizar UDP frente a TCP a pesar de su falta de fiabilidad garantizada?
Haz clic aquí para ver las soluciones y explicaciones

1. ¿Por qué se define a UDP como un protocolo "sin conexión" (connectionless) y qué implicaciones tiene esto en comparación con TCP?

Se define como sin conexión porque el emisor y el receptor no establecen ningún circuito ni apretón de manos previo (como el three-way handshake de TCP) antes de empezar a transmitir datos [00:02:20]. Las implicaciones son una menor sobrecarga de red y mayor velocidad, pero sin garantía de entrega, orden ni control de flujo nativo.

2. ¿Cuáles son los cuatro campos fundamentales que componen la cabecera de un paquete UDP?

La cabecera UDP es muy ligera (8 bytes en total) y consta exclusivamente de:

  • Puerto de origen: Identifica el puerto del proceso emisor [00:03:29].
  • Puerto de destino: Identifica el puerto del proceso receptor [00:03:29].
  • Longitud: Tamaño total del datagrama UDP en bytes (cabecera + datos) [00:03:29].
  • Checksum (Suma de verificación): Campo para comprobar la integridad básica del paquete [00:03:29].

3. ¿Qué es el protocolo QUIC (IETF) y por qué se ejecuta sobre UDP en lugar de TCP para plataformas de streaming como YouTube?

QUIC es un protocolo de transporte moderno desarrollado por el IETF basado en UDP que mejora el rendimiento web, la seguridad (cifrado integrado) y la privacidad [00:03:00]. Se utiliza sobre UDP porque permite multiplexar múltiples streams de datos de forma independiente, evitando el bloqueo de cabecera (head-of-line blocking) típico de TCP [00:03:11].

4. Si UDP no incluye números de secuencia ni control de flujo nativo, ¿cómo consiguen las aplicaciones de vídeo reensamblar los paquetes correctamente?

Para lograrlo, las aplicaciones implementan protocolos de capa superior (como QUIC) sobre UDP que incorporan información de reensamblaje, gestión de streams y control de pérdida a nivel de aplicación, permitiendo ordenar los fragmentos multimedia sin depender de TCP [00:02:39].

5. ¿En qué escenarios de red resulta más ventajoso utilizar UDP frente a TCP a pesar de su falta de fiabilidad garantizada?

Resulta ventajoso en aplicaciones en tiempo real donde la velocidad y la baja latencia son críticas y una pérdida puntual de paquetes es preferible a un retraso por retransmisión (por ejemplo: streaming de vídeo, VoIP, juegos online, consultas DNS y SNMP) [00:04:10].





Ficha de Laboratorio: Análisis de UDP y QUIC con Wireshark

Instrucciones de entrega:

  1. Rellena los campos de texto y responde a las cuestiones directamente en este formulario desde tu navegador.
  2. Una vez completada la ficha, pulsa el botón de imprimir que aparece al final.
  3. En el cuadro de diálogo de impresión, selecciona la opción "Guardar como PDF" o "Imprimir a PDF".
  4. Entrega el archivo PDF resultante a través de la plataforma del aula virtual.

Alumno/a:      Fecha:      Grupo / Clase:

1. Identificación del Entorno

Indica la interfaz de red utilizada para realizar la captura de tráfico UDP:

2. Cuestionario de Análisis en Wireshark

  1. ¿Qué filtro has utilizado en Wireshark para aislar el tráfico UDP y qué características visuales diferencian un datagrama UDP de un segmento TCP en la traza?
  2. Indica los cuatro campos principales que muestra Wireshark al inspeccionar la cabecera de un paquete UDP:
  3. Al reproducir un vídeo en YouTube, ¿qué protocolo de capa superior has identificado encapsulado sobre UDP y cuál es su función principal según el análisis?

3. Verificación de Puertos y Cabecera

Indica un ejemplo real observado en tu captura de un puerto de origen y destino UDP:

Simulación de topologías de red (Práctica con Packet Tracer)

En el diseño de infraestructuras locales, la forma en que interconectamos los dispositivos define tanto el rendimiento como la tolerancia a fallos de la red. Esta organización puede ser física (cómo se distribuye el cableado real) o lógica (cómo viajan los datos a través de los componentes).

En esta práctica de laboratorio, utilizaremos Cisco Packet Tracer para construir y analizar las cinco topologías clásicas de redes de datos: Estrella, Bus, Árbol, Anillo y Mixta.

Objetivo:

  • Implementar y diferenciar las principales topologías de red en un entorno simulado.
  • Configurar direccionamiento IP estático básico en hosts y entornos de enrutamiento.
  • Analizar la propagación de paquetes (difusión vs. conmutación) en modo simulación.

Material y herramientas necesarias:

  • Software Cisco Packet Tracer instalado.

Instrucciones:

  1. Fase 1: Topología en Estrella (La más común en redes LAN actuales)
    • Despliega 5 PCs genéricos en el espacio de trabajo.
    • Añade un Switch Cisco 2950-24 en el centro.
    • Conecta cada PC a un puerto del Switch usando cable directo de cobre (Copper Straight-Through).
    • Asigna direcciones IP estáticas consecutivas en la pestaña Desktop -> IP Configuration (desde 192.168.1.100 hasta 192.168.1.104 con máscara 255.255.255.0).
    • Prueba la conectividad enviando mensajes (PDU) entre los equipos y verifica que el estado sea Successful.
  2. Fase 2: Topología en Bus (Estructura histórica en desuso)
    • Elimina el Switch central de la fase anterior conservando los PCs configurados.
    • Añade un dispositivo Hub por cada ordenador para emular la línea de transmisión troncal (bus común).
    • Interconecta los Hubs entre sí de forma lineal y, posteriormente, conecta cada ordenador a su Hub correspondiente.
    • Lanza un ping entre ordenadores y comprueba que la comunicación sigue funcionando de manera satisfactoria.
  3. Fase 3: Topología en Árbol (Jerárquica)
    • Elimina todos los Hubs del escenario.
    • Organiza una estructura de Switches en cascada (de arriba hacia abajo) simulando una raíz y sus ramas.
    • Conecta los terminales (PCs) a las hojas o extremos finales de los switches.
    • Cambia al Modo Simulación, envía un paquete entre el primer y el último equipo de la jerarquía, y observa de forma interactiva cómo los paquetes se duplican o descartan en los nodos intermedios.
  4. Fase 4: Topología en Anillo (Cierre de bucle y Capa 3)
    • Despliega 4 Switches nuevos e interconéctalos formando una estructura circular.
    • Si intentas cerrar el anillo con un quinto switch no va a funcionar, ya que marcará un conflicto (error de bucle).
    • Para cerrar el bucle de la infraestructura sin provocar conflictos de conmutación en capa 2, añade un Router genérico que conecte el principio y el fin del anillo.
    • Configura las interfaces del Router con subredes lógicas diferentes (ej. 192.168.1.1 en Fa0/0 y 192.168.2.1 en Fa1/0) y enciende sus puertos (No Shutdown).
    • Traslada los equipos informáticos hacia el anillo, reconfigura sus puertas de enlace y valida el correcto envío de paquetes.
  5. Fase 5: Topología Mixta o Híbrida
    • Conecta mediante un cable de red el switch principal de la estructura en anillo con el switch raíz de tu topología en árbol.
    • Comprueba la convergencia completa del escenario realizando test de conectividad cruzados entre ambas zonas de la red.

Preguntas de reflexión:

  1. ¿Qué diferencia técnica observaste en el comportamiento de la red al enviar tráfico en la topología de Bus (con Hubs) frente a la de Árbol (con Switches)?
  2. En la topología en Anillo, ¿por qué se introduce un Router de Capa 3 para cerrar la estructura en lugar de conectar directamente el quinto Switch en bucle?
  3. Si el Switch central de la topología en Estrella sufre una avería eléctrica total, ¿qué le ocurre al resto de los componentes de la red? ¿Y si ocurriera lo mismo con un Hub intermedio de la topología en Bus?
Haz clic aquí para ver la solución

1. ¿Qué diferencia técnica observaste en el comportamiento de la red al enviar tráfico en la topología de Bus (con Hubs) frente a la de Árbol (con Switches)?

La diferencia radica en el dispositivo de interconexión y la gestión de los dominios de colisión. El Hub es un dispositivo de Capa 1 que no lee las direcciones MAC; por tanto, cuando recibe un paquete por un puerto, lo repite por inundación (broadcast físico) a todos los demás puertos instalados. Esto satura el canal y puede generar colisiones de bits.

Por el contrario, el Switch (Capa 2) almacena las direcciones físicas en su tabla CAM. Durante la simulación en el árbol, la primera vez puede enviar inundación, pero una vez aprendida la ubicación del destino, conmuta el tráfico de forma directa y exclusiva (unicast) al destinatario, optimizando drásticamente el ancho de banda global.

2. En la topología en Anillo, ¿por qué se introduce un Router de Capa 3 para cerrar la estructura en lugar de conectar directamente el quinto Switch en bucle?

Si conectáramos los cinco switches formando un círculo cerrado perfecto sin ninguna configuración adicional de seguridad, provocaríamos un fallo crítico conocido como bucle de enrutamiento o tormenta de broadcast en la Capa 2 del modelo OSI. Cualquier paquete de difusión daría vueltas de manera indefinida por el anillo de switches, duplicándose y consumiendo los recursos de procesamiento hasta colapsar los dispositivos de la red local.

Al introducir un Router (Capa 3), este actúa como una barrera natural contra el broadcast. El router segmenta el bucle físico en dos subredes lógicas totalmente independientes, permitiendo que la información fluya de manera circular controlada mediante el direccionamiento IP y las tablas de enrutamiento lógico.

3. Si el Switch central de la topología en Estrella sufre una avería eléctrica total, ¿qué le ocurre al resto de los componentes de la red? ¿Y si ocurriera lo mismo con un Hub intermedio de la topología en Bus?

En la topología en Estrella, el nodo central representa un punto único de fallo. Si el switch se apaga o se rompe, la red completa cae de forma inmediata y ningún ordenador podrá comunicarse con los demás, aunque sus tarjetas de red y cables individuales estén en perfecto estado.

En la topología en Bus lineal, si un Hub central o intermedio de la línea troncal falla, la red no cae por completo, sino que se fragmenta o divide en dos segmentos aislados. Los ordenadores que se encuentran a la izquierda del fallo podrán seguir comunicándose entre sí, y los de la derecha harán lo propio, pero habrá una pérdida total de conectividad interconectada entre ambos lados del canal físico cortado.









Relay Agent Configurar un servidor DHCP para dos routers (Práctica con Packet Tracer)

En esta práctica avanzada de Packet Tracer, aprenderemos a configurar un servidor DHCP centralizado para gestionar direcciones IP en múltiples redes conectadas a través de diferentes routers. Este escenario es fundamental para entender cómo escalan los servicios de red en entornos empresariales.

Objetivo:

Implementar un servidor DHCP único capaz de asignar direcciones IP de forma dinámica a hosts situados en diferentes subredes, utilizando el comando ip helper-address en los routers para retransmitir las solicitudes DHCP al servidor central.

Escenario:

  • Dos Routers interconectados (vía serial).
  • Dos redes locales (LAN) independientes conectadas a cada router.
  • Un Servidor Genérico actuando como servidor DHCP central.
  • Protocolo de enrutamiento RIP para permitir la comunicación entre redes.

Instrucciones:

  1. Diseño de la topología: Montar el esquema con los dos routers, sus respectivas redes locales y el servidor central conectado a uno de ellos.
    • Los routers de Cisco en Packet Tracer vienen vacíos de fábrica (sin puertos seriales). Por defecto, sólo traen puertos GigabitEthernet. Si intentas conectar un cable serial, el simulador lo rechaza porque no hay ninguna "ranura" física donde pincharlo. Para poder conectar los routers mediante cable serie primero debes añadir un módulo.
    • Entra en la parte física del Router0, apágalo y arrastra el módulo NIM-2T. Después vuelve a encender el router.
    • Haz lo mismo con el otro router (Router1).
    • Ya podrás conectar los dos routers mediante un cable serie.
    • Conecta el resto de los dispositivos utilizando cable de par trenzado directo (Cooper Straight-Through).
  2. Configurar IP a cada router:
    • Entra en el Router0: 
    • Si sale el error ROMMON mode es porque se interrumpió el proceso de arranque al cargar el módulo físico. Entra en la CLI y escribe boot para cargar el sistema operativo. Comenzarán a aparecer muchas almohadillas (#) en pantalla. Una vez que finalice podrás ir a Config --> Interface --> GigabitEthernet0/0/0
    • Escribe la IP (192.168.10.1) deja la máscara de red por defecto (255.255.255.0) y enciende el puerto: ON
    • Haz lo mismo en el Router1 pero poniendo la IP correspondiente (192.168.20.1)
  3. Comunicar los routers:
    • Ya tenemos configurada la IP de cada router. Ahora vamos a configurar la comunicación entre los routers
    • Entra en el Router0: Config --> Serial0/1/0
    • Introduce la IP correspondiente (192.168.30.1) y enciende el puerto.
    • Haz lo mismo con el Router1 introduciendo la IP correspondiente (192.168.30.2).
    • Observa que las conexiones están en verde.
    • Ahora vamos a configurar el RIP:
    • Entra en Router0: Config --> RIP
    • Añade las tres redes:
      • 192.168.10.0 --> Add
      • 192.168.20.0 --> Add
      • 192.168.30.0 --> Add
    • Haz lo mismo para el Router1.
    • Los dos routers deben tener configuradas las tres redes en el RIP para asegurar que todas las redes se vean entre sí.
  4. Configuración del Servidor DHCP:
    • Entra en el Servidor: Desktop --> IP Configuration
    • Configura su IP (192.168.10.2) deja la máscara por defecto
    • Configura la Gateway del Router al que está conectado (192.168.10.1)
    • Una vez hecho eso ve a Services --> DHCP
    • Enciende el servicio: ON
    • Crea un Server Pool:
      • Gateway: 192.168.10.1 (el del router al que está conectado)
      • Primera IP: 192.168.10.50
      • Guarda la configuración: Save
    • Este Server Pool que acabamos de crear solamente servirá para los PC0 y PC1, ya que son los que están conectados al router configurado en el Gateway. Este Pool no sirve para PC2 y PC3, que están en otra red.
    • Vamos a comprobar que el servicio DHCP funciona correctamente para PC0 y PC1.
    • Entra en PC0: Desktop --> IP Configuration
    • Activa DHCP y observa cómo se le asigna una IP dentro del rango.
    • Haz lo mismo con PC1.
    • Intenta hacer lo mismo con PC2 y PC3 y verás que no asigna ninguna IP.
    • Para que el servidor DHCP asigne IPs a los PCs de la sgunda red tenemos que crea otro server Pool.
    • Entra en el Servidor: Services --> DHCP
    • Crea un nuevo server Pool:
      • Pool Name: serverPool2
      • Gateway: 192.168.20.1 (la IP del router donde están conectados PC2 y PC3)
      • Primera IP: 192.168.20.50 (para que asigne IPs dentro de la segunda red)
      • Añade la server Pool: Add
      • Guarda los cambios: Save
    • Ya hemos creado un segundo server Pool, pero el segundo router no está conectado directamente al servidor DHCP. hora tenemos que configurar que el segundo router se conecte al servidor DHCP.
  5. Configuración del Relay Agent (Agente de retransmisión o intermediario):
    • En el router que NO está conectado directamente al servidor, acceder a la interfaz de la LAN: Config --> Interface --> GigabitEthernet0/0/0
    • En línea de comandos CLI: ip helper-address 192.168.10.2
    • Entra en PC2: Desktop --> IP Configuration y activa DHCP
    • Verás que recibe una IP dentro del rango asignado.
    • Haz lo mismo con PC3.

ROUTERS:





SERVIDOR DHCP:





Verificación

  1. Cambiar los PCs de cada red a configuración DHCP. Deberán recibir automáticamente una IP, máscara y puerta de enlace correspondiente a su segmento de red, a pesar de que el servidor está en una red distinta.
  2. El servidor DHCP funciona para las dos redes.
  3. Realiza varios ping entre los PCs de distintas redes y comprueba la conectividad.

Preguntas de reflexión:

  1. ¿Por qué los PC2 y PC3 fallan al intentar obtener una IP por DHCP antes de configurar el comando ip helper-address en el Router1?
  2. ¿Cómo sabe el Servidor DHCP que debe asignar una IP del rango 192.168.20.X (del serverPool2) y no del primer pool si la petición le llega a la misma tarjeta de red?
  3. ¿Qué ocurriría con el servicio DHCP en la segunda red (LAN de Router1) si el protocolo de enrutamiento RIP dejara de funcionar o estuviera mal configurado?
Haz clic aquí para ver la solución

1. ¿Por qué los PC2 y PC3 fallan al intentar obtener una IP por DHCP antes de configurar el comando ip helper-address en el Router1?

El proceso de solicitud DHCP (mensaje DHCP Discover) se envía mediante difusión (broadcast) a nivel de Capa 2 y Capa 3, ya que el cliente aún no tiene una IP propia ni conoce la IP del servidor.

Por diseño y seguridad, los routers no reenvían paquetes de broadcast hacia otras redes; los descartan de inmediato para evitar tormentas de tráfico en la red global. Como el Servidor DHCP se encuentra en una red remota diferente, las solicitudes de PC2 y PC3 mueren en la interfaz GigabitEthernet del Router1. Al no recibir respuesta, los PCs sufren un fallo de asignación y se configuran temporalmente con una dirección IP privada automática (APIPA) del rango 169.254.X.X.

2. ¿Cómo sabe el Servidor DHCP que debe asignar una IP del rango 192.168.20.X (del serverPool2) y no del primer pool si la petición le llega a la misma tarjeta de red?

Cuando configuras el comando ip helper-address 192.168.10.2 en la interfaz GigabitEthernet0/0/0 del Router1, transformas al router en un Agente de Retransmisión DHCP (DHCP Relay Agent).

Al recibir el broadcast del PC, el router lo encapsula en un paquete de envío directo o unicast dirigido a la IP del Servidor. Dentro de los campos internos de este nuevo paquete DHCP, el router añade obligatoriamente un parámetro llamado Gateway IP Address (GIADDR) rellenándolo con su propia dirección IP local (la 192.168.20.1). Al recibir el paquete, el Servidor DHCP examina el campo GIADDR, se da cuenta de que la petición proviene de la subred 192.168.20.0 y busca en su base de datos el pool cuya puerta de enlace coincida con esa subred (serverPool2), ignorando el pool principal de la red local.

3. ¿Qué ocurriría con el servicio DHCP en la segunda red (LAN de Router1) si el protocolo de enrutamiento RIP dejara de funcionar o estuviera mal configurado?

Si el protocolo RIP falla o no está configurado, las redes remotas dejarán de conocer las rutas para llegar entre sí, rompiendo la conectividad básica de la infraestructura. Esto afectaría al DHCP de la siguiente manera:

  • El Router1 sabrá enviar la petición: El Router1 tiene una conexión directa con la red serial 192.168.30.0, por lo que podrá transformar el broadcast en unicast y enviárselo al Router0 para que este se lo entregue al servidor.
  • El Servidor no podrá responder: El Servidor generará el mensaje de respuesta (DHCP Offer), pero al enviarlo de vuelta a la IP 192.168.20.1 (Router1), su router local (Router0) revisará su tabla de enrutamiento y, al no tener RIP activo, no sabrá cómo llegar a la red 192.168.20.0. El paquete de respuesta se descartará en el Router0, haciendo que PC2 y PC3 nunca reciban su dirección IP.








Suscribirse a: Entradas (Atom)