PRELABORATORIO
1. ¿Por qué el hub aumenta el dominio de colisión en una red?
El uso de un hub en una red puede generar varios problemas debido a las colisiones. Cuando dos dispositivos envían sus mensajes
simultáneamente, se produce una colisión, lo que obliga a retransmitir los mensajes de forma individual. Este fenómeno es especialmente
relevante en el modo half-duplex (Tanenbaum & Wetherall, 2011). Las colisiones son frecuentes en un entorno de hub porque todos los
puertos del hub comparten el mismo dominio de colisión. En una red que utiliza un hub, todos los dispositivos están conectados al
mismo segmento de red y compiten por el acceso al medio de transmisión. Esto significa que, si varios dispositivos intentan enviar
señales al mismo tiempo, se producirán colisiones, lo que disminuirá el rendimiento de la red (Stallings, 2013). Por lo tanto, el dominio
de colisión se incrementa en una red con un hub, ya que cualquier colisión afecta a todos los dispositivos conectados al hub, mientras
más equipos se conecten al HUB y que todos estos equipos quieran utilizar el canal, hay más probabilidad de que haya colisión, y eso
genera retraso en la transmisión y perdidas de paquetes. Si se necesitan conectar más de dos dispositivos en una misma red necesitaremos
un hub o un switch.
2. Se ha decidido transmitir un archivo de 407KB de una PC1 a PC2 a través de una red Ethernet clásica (la red está
conformada por 5 PC y usa tecnología 100Base-TX), responder las siguientes preguntas:
a. Considere que durante la transmisión el campo de datos de todas las tramas Ethernet tienen un tamaño de 1272 bytes,
¿Cuántas tramas se deben generar para completar la transmisión? ¿Cuál es el tamaño real de cada trama Ethernet?
Primero sabemos que su velocidad de transmisión es de 100Mbps Para realizar los cálculos debemos convertir 407KB = 407 * 1024
bytes = 416,768 bytes el cual será el tamaño total del archivo, sabemos que el tamaño del campo de datos de cada trama es de 1272
bytes, entonces:
• Cantidad de tramas = Tamaño total del archivo / Tamaño del campo de datos de cada trama
• Cantidad de tramas = 416,768 bytes / 1272 bytes = 327.65
Dado que no se pueden tener fracciones de tramas, redondearemos al número entero más cercano. Por lo tanto, se deben generar
328 tramas para completar la transmisión. 327 tramas van a tener 1272 bytes de datos (cada trama) y 0.65 que restan va a tener
827 bytes. bytes. Tamaño real de cada trama Ethernet: Una trama Ethernet tiene una estructura que incluye más que solo el campo
de datos. Las secciones de una trama Ethernet clásica son: Preámbulo (La trama Ethernet comienza con el campo preámbulo de 8
bytes), Dirección de destino/Dirección de origen (estos campos contienen las direcciones del adaptador de destino y del adaptador
origen), tipo (Este campo de 2 bytes identifica el protocolo de capa superior que creó el paquete que esta encapsulado en la trama),
datos (Este campo transporta el paquete IP) y CRC (Permite que el adaptador de recepción detecte los errores de bits de la trama).
8 bytes (Preámbulo) + 6 bytes (Dirección de destino) + 6 bytes (Dirección de origen) + 2 bytes (Tipo) + 1272 bytes (Datos) + 4 bytes
(CRC) = 1298 bytes es el tamaño real de cada trama Ethernet.
b. ¿De cuánto es el resultado total, del tiempo entre tramas, durante toda la transmisión?
Entra cada trama hay un tiempo en el que se encuentra apagada para inicializar y finalizar la trama. El tiempo trama se mide entre cada
trama, si tenemos 328 tramas hay 327 pasos (Número de intervalos entre tramas). Para Ethernet clásica 100BaseTX, el tiempo de espera
entre tramas o Interframe Gap (IFG) es de 0.96 µs según el Estándar 802.3 sección1.
Por lo tanto: 327* 0.96 µs = 313.92 µs (Tiempo entre tramas
durante toda la transmisión)
c. ¿Cuántos bytes de cabecera se han generados durante toda
la transmisión sin tomar en cuenta el preámbulo?
Ya sabemos que se requieren 328 tramas para transmitir el archivo. Por
lo tanto, el número total de bytes de cabecera generados durante toda la
transmisión será: Cabecera sin preámbulo * Tramas = (6 + 6 + 2 + 4)
* 328 = 5904 bytes
d. ¿Cuándo se generaron la solicitud y respuesta ARP? y ¿por qué?
Solicitud ARP (ARP Request): Se genera cuando un dispositivo (por ejemplo, PC1) necesita comunicarse con otro dispositivo (por
ejemplo, PC2) en la misma red local, pero solo conoce la dirección IP de ese dispositivo. La solicitud ARP se envía como un broadcast
(difusión) en la red, preguntando "¿Quién tiene la dirección IP X.X.X.X? Dime tu dirección MAC".
Respuesta ARP (ARP Reply): Se genera cuando el dispositivo que tiene la dirección IP solicitada recibe la solicitud ARP. Este
dispositivo (PC2, en este caso) responde con un unicast (transmisión a un solo destinatario) a la dirección MAC del dispositivo que hizo
la solicitud, proporcionando su dirección MAC correspondiente.
¿Por qué se generan?: Propósito de la comunicación, es decir, Antes de que un dispositivo pueda enviar datos a otro en una red, necesita
saber la dirección MAC del dispositivo de destino. Dado que la comunicación en una red Ethernet se basa en direcciones MAC, es
necesario resolver la dirección IP en la dirección MAC correspondiente. El protocolo ARP permite que los dispositivos descubran
dinámicamente la dirección MAC asociada a una dirección IP sin necesidad de configuraciones manuales o tablas estáticas. Esto hace
que la red sea más flexible y fácil de gestionar.
e. Durante la transmisión anterior la PC4 de la red ha decidido transmitir un archivo a la PC5, ¿qué debería de suceder?
Cuando PC4 decide transmitir un archivo a PC5 en una red Ethernet 100Base-TX mientras la transmisión entre PC1 y PC2 está en
curso, varias cosas pueden suceder:
Colisión: En una red con un hub, todas las PCs comparten el mismo dominio de colisión. Si PC4 y PC1 intentan transmitir al mismo
tiempo, se produce una colisión. Esto causa que ambas PCs dejen de transmitir y vuelvan a intentarlo después de un tiempo aleatorio,
según el algoritmo de retroceso exponencial utilizado en Ethernet (CSMA/CD).
Retransmisión: Debido a la colisión, ambas PCs intentarán retransmitir sus datos después de esperar un período aleatorio. Este proceso
continúa hasta que ambas transmisiones se completen sin colisiones.
Reducción del rendimiento: Las colisiones y retransmisiones frecuentes pueden disminuir el rendimiento de la red, aumentando el
tiempo total necesario para completar la transmisión de archivos.
LABORATORIO
Parte 1: Simulación en Packet Tracer
Abrimos el programa Packet Tracer y comenzamos la práctica configuramos la topología dada la cual consistió en una red con dos
hubs interconectados, cada uno conectado a cinco maquinas, los hubs los conectamos a las PCs utilizando el cable "Copper Straight-
through" (Cable Directo) y los hubs se interconectaron con un cable "Copper Crossover" (Cable Cruzado). Procedimos a configurar las
IPs de las maquinas con la dirección de red 192.168.19.X donde X va del 1-12 ya que son 12 maquinas conectadas con la mascada /24
(255.255.255.0).
Parte 2: Conectividad entre las PCs y funcionamiento del Hub
Al tener las conexiones listas, con el comando ping se verifico la conectividad entre las máquinas de diferentes hubs. Aquí pudimos
ver cómo se enviaron y recibieron 4 paquetes exitosamente como se muestra en la figura 1. Probamos conectividad entre varias PC
para garantizar que su red funciona y verificamos la tabla arp de su PC0 con el comando arp –a. Como observamos que la tabla tiene
algunas entradas procedimos a eliminarlas con el comando arp –d y volvimos a verificar el paso anterior.
Respondiendo preguntas: ¿Por qué la dirección MAC destino de na trama de solicitud ARP es FF:FF:FF:FF:FF:FF?, ¿Por qué la
dirección MAC de destino de una trama de respuesta arp no es FF:FF:FF:FF:FF:FF? ¿Cómo se identifica una solicitud y una respuesta
arp?, ¿En dónde se encapsulan la solicitud y respuesta arp?
Para identificar una solicitud y una respuesta ARP, se utiliza el campo "Tipo de operación" del paquete ARP. En una solicitud ARP,
este campo tendrá el valor de 1, mientras que en una respuesta ARP, el valor será 2. Las solicitudes y respuestas ARP se encapsulan en
una trama Ethernet para su transmisión a través de la red. Esto permite que los datos se transmitan correctamente entre dispositivos en
una red Ethernet. (Stallings, 2013).
En cambio, la dirección MAC de destino en una trama de respuesta ARP no es FF:FF:FF:FF:FF:FF porque la respuesta ARP se envía
solo al dispositivo que hizo la solicitud original. Por lo tanto, la dirección MAC de destino en la trama de respuesta ARP es la dirección
MAC del dispositivo que envió la solicitud ARP. Esto asegura que la información correcta llegue al solicitante sin inundar toda la red.
(Tanenbaum & Wetherall, 2011).
Para identificar una solicitud y una respuesta ARP, se utiliza el campo "Tipo de operación" del paquete ARP. En una solicitud ARP,
este campo tendrá el valor de 1, mientras que en una respuesta ARP, el valor será 2. Esto permite que los dispositivos en la red procesen
correctamente los mensajes ARP según su tipo. (Kurose & Ross, 2016).
Las solicitudes y respuestas ARP se encapsulan en una trama Ethernet para su transmisión a través de la red. Este encapsulamiento
permite que los datos se transmitan correctamente entre dispositivos en una red Ethernet. La trama Ethernet proporciona el medio físico
a través del cual los paquetes ARP se envían de un dispositivo a otro (Forouzan, 2016). Durante la simulación se seleccionó un paquete
y visualizamos la información correspondiente a la trama Ethernet y además estaba presente la información sobre el paquete ARP,
Donde vemos que, dentro de la trama Ethernet, el tipo de protocolo especificado en el campo de datos es 0x0800. Este valor indica que
la trama Ethernet contiene un paquete IPv4. El proceso de encapsulación en este punto implica que se está añadiendo una capa adicional
de información al paquete original, para su transporte a través de una red Ethernet. En este caso, el paquete IPv4 se encapsula dentro de
la trama Ethernet. podemos apreciar los detalles en la siguiente imagen:
Preámbulo: AAAA:AAAA:AAAA:AAAA:AAAA:AAAA:AAAA Tipo: 08:00
Dirección MAC de Origen: 00:E0:8F:19:65:43 Dirección MAC de Destino: 00:00:00:00:00:00
Datos: Datos ICMP CRC: No especificada en el PDU
El término [Datos ICMP] se refiere al paquete ICMP que se transmite, mientras que [CRC] es el código destinado a la detección de
errores. Estos elementos pueden variar conforme al contenido específico del paquete ICMP y al cálculo del CRC. El cálculo del CRC,
crucial para la integridad de los datos, es un proceso técnico que exige un firme conocimiento de matemáticas y teoría de la información.
Los datos enviados en un ping pueden cambiar en función de diversos factores como el sistema operativo, la configuración de red, y las
condiciones del tráfico. Es fundamental entender cómo estas variables impactan la transmisión para garantizar una comunicación eficaz
y segura. Sin embargo, Packet Tracer no proporciona una funcionalidad para calcular o mostrar el CRC en sus simulaciones.
Cuando una PC envía una solicitud ARP, no conoce la dirección MAC del destino, por eso la dirección MAC de destino (Target MAC)
se muestra como 0000.0000.0000. La solicitud ARP se envía a todos los dispositivos en la red (broadcast) para preguntar: "¿Quién tiene
esta dirección IP?" hasta que el dispositivo con la IP correspondiente responda con su dirección MAC.
El hecho de que el inbound DPU sea igual al outbound DPU durante una solicitud ARP tiene sentido, porque la información esencial
en ambos casos es la misma: el dispositivo está enviando la solicitud y esperando una respuesta. En otras palabras, la estructura de los
datos (DPU - Data Protocol Unit) no cambia entre la solicitud y la recepción de esa solicitud.
Parte 3: Continuando con la práctica, procedimos a realizar los mismos pasos anteriores con los equipos de laboratorio donde la mitad
de los alumnos conectan sus maquitas al HUB 1 y la otra mitad al HUB 2. Comenzamos modificando las IPs de las maquinas utilizando
192.168.101.X donde X representa el numero de la computadora asignada, en mi caso 192.168.101.7. Luego procedimos a hacer ping
con las computadoras del laboratorio que estuvieran en uso, lo cual fue satisfactorio ya que los paquetes llegaron a todos los pings de
todas las maquinas como se muestra a continuación donde se muestran algunos pings y una tabla arp;
Como paso final, intentamos hacer colisión con todas las maquinas
haciendo ping a una de ellas lo cual pudimos ver los resultados en
wireshark ya que pudimos ver como en el request aparece "no respond
found" pero vuelve a mandar el request hasta que llegue a la máquina.
Podemos concluir que: En una red con hubs, todos los dispositivos conectados comparten el mismo dominio de colisión. Esto significa
que cuando varios dispositivos intentan comunicarse simultáneamente, las colisiones son inevitables. En nuestro experimento, las
colisiones se detectaron claramente al hacer ping simultáneamente a una máquina y observar los paquetes en Wireshark.Cada colisión
implica que los paquetes deben ser retransmitidos, aumentando el tiempo de transmisión y reduciendo la eficiencia global de la red.
Este fenómeno es menos común en redes modernas que utilizan switches, que operan en dominios de colisión separados.
La práctica demostró las limitaciones inherentes de los hubs en la gestión de tráfico de red. Debido a su naturaleza de operar en un
único dominio de colisión, los hubs son propensos a causar colisiones frecuentes en redes con tráfico simultáneo, lo que disminuye la
eficiencia y el rendimiento de la red. En resumen, aunque los hubs pueden ser adecuados para redes pequeñas y de bajo tráfico, su uso
puede presentar limitaciones en términos de velocidad, eficiencia y confiabilidad. Para redes más grandes y exigentes, se recomienda
considerar alternativas como los switches, que dividen la red en dominios de colisión separados y mejoran el rendimiento general al
proporcionar un ancho de banda dedicado a cada máquina. Sin embargo, es importante asegurarse de utilizar cables de buena calidad y
mantener las conexiones adecuadas independientemente del dispositivo utilizado para evitar posibles fallas de conexión.
REFERENCIAS
Tanenbaum, A. S., & Wetherall, D. J. (2011). Redes de computadoras (5ª ed.). Pearson Educación.
Stallings, W. (2013). Data and Computer Communications (10ª ed.). Pearson.
Forouzan, B. A. (2016). Data Communications and Networking (5ª ed.). McGraw-Hill Education.
Kurose, J. F., & Ross, K. W. (2016). Computer Networking: A Top-Down Approach (7ª ed.). Pearson.
