Hola Chris!… respecto a tu pregunta, definitivamente NO… no es lo mismo… el flooding es cuando 1 switch REENVÍA una trama a todos sus puertos… es una trama UNICAST de la cual no se tienen registros en la tabla MAC… y es por eso que se realiza el flooding de la trama. El broadcast es enviar una trama BROADCAST a todos sus puertos para un uso especifico… por ejemplo para el protocolo ARP. Lo clave es tienes que recordar que el flooding es una trama UNICAST reenviada a todos los puertos y el broadcast es una trama BROADCAST enviada a todos los puertos, la trama broadcast es la que llega a todos los dispositivos en una misma red lógica y tiene una dirección de destino en la trama de FF:FF:FF:FF:FF:FF.

Espero que quede claro con esa explicacion! =D

Hola Ricardo! =D

Pregunta:

3. ¿Qué es el proceso de flooding?*

Se da cuando el switch no tiene en su tabla MAC la dirección de destino de la trama
Se da cuando el switch no tiene en su tabla MAC la dirección de origen de la trama
Se da cuando el switch recibe una trama broadcast
Se da cuando el switch recibe una trama multicast
Se da cuando la dirección IP de destino no figura en la tabla MAC
Se da cuando la dirección IP de destino no figura en la tabla de enrutamiento

Respondiendo directamente a tu consulta, no, no tendría 2 respuestas. El proceso de flooding conceptualmente se da cuando un switch recibe una trama unicast y no tiene en su tabla MAC a la dirección MAC de destino de la trama, esto quiere decir que no sabe qué hacer con la trama… por lo tanto «inunda», hace un «flooding» de esa trama unicast a todos sus puertos para encontrar al dispositivo de destino.

Si analizamos las opciones de las respuestas:
– La primera opción es la correcta «Se da cuando el switch no tiene en su tabla MAC la dirección de destino de la trama»

– La segunda opción indica que «Se da cuando el switch no tiene en su tabla MAC la dirección de origen de la trama». Cuando un switch no tiene la dirección de origen de una trama recibida, simplemente añade esa dirección a su tabla MAC con su correspondiente puerto, no realiza un proceso de flooding.

– La tercera opción indica «Se da cuando el switch recibe una trama broadcast». Una trama broadcast tiene en la dirección de destino el valor FF:FF:FF:FF:FF:FF, no es una trama unicast, la trama broadcast se reenvía a todos los puertos, no se está buscando a un dispositivo en particular, eso no es «flooding».

– La cuarta opción indica «Se da cuando el switch recibe una trama multicast». En este caso es lo mismo que en el proceso de broadcast, simplemente que la trama está destinada a una dirección MAC multicast, esto no es flooding.

– Y la quinta y sexta opción, hablan sobre las direcciones IP, los switches analizan las direcciones MAC de las tramas, no analizan las direcciones IP de los paquetes (normalmente), no tiene relación una dirección IP con el proceso de flooding.

Espero que con esta explicación quede más claro! =D

Hola Hebert! =)

Recuerda los conceptos del protocolo ARP.

Antes que se envié una trama a un dispositivo de destino, primero el dispositivo de origen necesita contactar al dispositivo de destino para obtener su dirección MAC. El dispositivo de origen envía el mensaje ARP request broadcast… y el dispositivo de destino debe responder con el mensaje ARP Reply… si no «existe» ese dispositivo de destino, lógicamente nadie responderá al mensaje ARP Request y ninguna trama de datos será enviada por la red. Ahora… lógicamente el dispositivo de origen envía el mensaje broadcast ARP en la red, sin importarle si el dispositivo de destino está o no está disponible en la red (no se cerciora de nada en full dúplex).

Respecto a tu segunda consulta, físicamente un switch hace conmutación de paquetes, recuerda que el medio es compartido, un circuito en un switch NO es dedicado para 1 dispositivo en particular… si 2 dispositivos quieren hacer uso de un puerto en un switch… lo pueden hacer y el switch compartirá el recurso físico entre todos los dispositivos que quieran hacer uso del mismo.

Estoy atento a tus comentarios!

Hola Nicolás! =)

Si le das una mirada al video de la clase, esto lo vemos a partir del minuto 25… cuando 2 switches se interconectan entre sí, los 2 switches aprenden las direcciones MAC de los dispositivos finales que se conectan en ambos switches.

Sí tienes la PC1 (MAC A) en el SW1, y el SW1 está conectado al SW2… y el switch 2 tiene la PC3 (MAC B) y PC4 (MAC C) conectadas a sus puertos… qué va pasar cuando PC3 y PC4 quieran comunicarse con la PC1?… envían sus broadcast no es cierto?… esos broadcast eventualmente llegan al switch 1 a través de un puerto, supongamos el puerto Fastethernet0/1… en el momento que esas tramas ingresen al puerto Fa0/1, el switch 1 asocia ambas direcciones MAC a ese puerto, en la tabla MAC verías que las direcciones MAC A y B pueden alcanzarse a través del puerto Fa0/1.

Es por esto que los switches pueden tener más de una dirección MAC en la tabla MAC asociada a una interface.

Espero que ahora quede más claro.

Saludos cordiales!

De nada! =D

Hola Roberto!

Hemos reemplazado esa opción por una afirmación sobre el «inactivity-timer».

Gracias por la observación.

Hola Edward!

Esta es una pregunta bastante interesante… la verdad no existe una respuesta «oficial» de Cisco del motivo por el que esto es así, sin embargo he visto diferentes argumentos presentados tanto por personal de Cisco como por personal que se dedica a la arquitectura de los dispositivos. Entre las razones tenemos las siguientes:

– En primer lugar, algunos switches «Catalyst» no fueron originalmente diseñados/creados por Cisco, Cisco adquirió a la empresa Crescendo en 1993 que era el fabricante de estos dispositivos Catalyst (switches). Estos dispositivos fabricados por Crescendo no llevaban botón de encendido/ apagado, entonces para seguir con la misma línea de producción y arquitectura, mantuvieron a los switches de esta manera. Sus routers en ese entonces ya llevaban botón de encendido y apagado, por lo tanto esto fue más una decisión de producción y ahorros en los costos de producción.

– Otro argumento es que los dispositivos de red no están diseñados para ser «encendidos y apagados», la idea de un dispositivo de red es mantenerse siempre encendido proporcionando el servicio a los usuarios. Y es por ello que la “mayoría” de los productos de red no llevan este boton.

– Otro argumento histórico (que no aplica hoy en día), es que los routers solían ser los únicos dispositivos a los cuales añadías e introducías tarjetas/módulos, por lo tanto para realizar la instalación tenías que tener un botón a la mano para apagar el dispositivo y realizar los cambios, esto era más adecuado que tener que desenergenizar un dispositivo con el riesgo de que apagues otros dispositivos. Los switches antiguos eran de configuración fija y por lo tanto no había la necesidad de apagarlos/encenderlos.

La razón más “lógica” existente es la primera, simplemente se mantuvo el diseño de los switches que fueron adquiridos en 1993 para evitar un rediseño del producto y un incremento en los costos de producción.

Espero haberte ayudado.

Saludos cordiales.

• Esta respuesta fue modificada hace 5 años, 1 mes por AlvaroM.