En las redes de computadoras , una inundación de unidifusión ocurre cuando un conmutador recibe una trama de unidifusión y el conmutador no sabe que el destinatario está en un puerto de conmutador en particular. Dado que el conmutador no tiene información sobre a qué puerto, si corresponde, se puede llegar al destinatario, reenvía la trama a través de todos los puertos excepto aquel a través del cual se recibió la trama.
Unicast se refiere a una transmisión uno a uno de un nodo de una red a otro. Este diagrama ilustra la transmisión unidifusión de una trama de un nodo de red a otro:
Cuando un conmutador recibe una trama de unidifusión con una dirección de destino que no está en la tabla de reenvío del conmutador , la trama se trata como una trama de difusión y se envía a todos los segmentos de red a los que está conectado, excepto aquel del que recibió la trama:
El proceso de aprendizaje del puente transparente requiere que el conmutador reciba una trama de un dispositivo antes de que se le puedan reenviar tramas de unidifusión. Antes de recibir cualquier transmisión de este tipo, se utiliza inundación de unidifusión para garantizar que las transmisiones lleguen a sus destinos previstos. Normalmente, esta es una condición de corta duración, ya que la recepción suele producir una respuesta que completa el proceso de aprendizaje. El proceso ocurre cuando un dispositivo se conecta inicialmente a un segmento de red, o después de que su dirección y su identificador de puerto se eliminan de la base de información de reenvío . Una entrada se elimina cuando el enlace se cae en el puerto original o cuando caduca debido a inactividad (cinco minutos es el valor predeterminado en muchos conmutadores). Es necesario un límite de tiempo porque un conmutador no necesariamente ve ninguna indicación cuando un nodo de red se mueve o desconecta.
Cuando a un puente o conmutador no le queda espacio en su base de información de reenvío y, por lo tanto, no puede agregar una entrada para un nuevo nodo, debe reenviar cualquier trama dirigida a ese nodo a través de todos los puertos excepto aquel en el que se recibió la trama. Este es un problema común en redes con muchos hosts. [1] Menos común es la inundación artificial de tablas de direcciones en un ataque de inundación MAC .
Otra causa común es un host con un tiempo de espera de caché ARP mayor que el tiempo de espera de la base de información de reenvío (FIB) en un conmutador: el conmutador olvida qué puerto se conecta al destino antes de que el host olvide la dirección MAC del destino. [2] Esto se puede evitar configurando el conmutador con un tiempo de espera FIB mayor que los tiempos de espera de la caché ARP de los nodos de su red. Cuando un nodo necesita enviar una trama a un host después de que expire su correspondiente entrada de caché ARP, primero debe enviar una trama de difusión ARP, que el conmutador debe reenviar a través de todos los puertos, para descubrir la dirección MAC (actual) del host.
Las características mal configuradas de las redes también pueden provocar inundaciones de unidifusión. Si hay dos rutas de capa 2 desde el Host A al B y el Host A usa la ruta 1 para comunicarse con el Host B, pero el Host B usa la ruta 2 para responder al Host A, entonces los conmutadores intermedios en la ruta 1 nunca aprenderán la dirección MAC de destino. del Host B y los conmutadores intermedios en la ruta 2 nunca aprenderán la dirección MAC de destino del Host A. [3]
Una última causa de las inundaciones de unidifusión son los cambios de topología. Cuando el estado de un enlace cambia en un puerto de red que participa en un árbol de expansión rápida , la caché de direcciones en ese conmutador se vaciará, lo que provocará que todas las tramas posteriores se inunden en todos los puertos hasta que el conmutador vuelva a aprender las direcciones. [4]
Una función que bloquea las inundaciones de unidifusión está disponible en los conmutadores Cisco, pero no está habilitada de forma predeterminada. Después de asegurarse de que los tiempos de espera y las características de seguridad se hayan configurado para mantener las entradas de la tabla en los puertos de acceso del cliente por más tiempo que los tiempos de espera típicos de la caché ARP del host , este comando se utiliza para silenciar las inundaciones de unidifusión en esos puertos: [5] [6]
Switch(config-if)# bloque de puerto de conmutación unidifusión
Otras técnicas implican aislar hosts en la Capa 2, lo que bloquea la comunicación dentro de la LAN no destinada a nodos específicos que brindan un servicio compartido (por ejemplo, un enrutador). Una herramienta útil para esto son los puertos protegidos (puertos que tienen prohibido comunicarse con otros puertos protegidos), disponibles en conmutadores de gama baja: [7]
Switch(config-if)# puerto de switch protegido
Una solución de conmutación cruzada más sólida que la de "puerto de conmutación protegido" es el uso de VLAN privadas . [8]
Para bloquear la inundación en una máquina Linux lo suficientemente moderna como para tener instalado iproute2 , puede controlar la inundación en el puente del dispositivo ejecutando bridge link set dev phy6 Flood off . Para establecer un tiempo de espera de MAC mayor que el tiempo de espera de ARP, se pueden emitir estos comandos:
configuración brctl br0 330; eco 300 > /proc/sys/net/ipv4/neigh/br0/gc_stale_time
La mayoría de los interruptores modernos, de gama alta y baja, admiten protección contra inundaciones.
Cuando una red experimenta una inundación de unidifusión, el rendimiento de la red se degrada. A continuación se muestra un gráfico de un puente antes y después de ajustar el tamaño de la caché de direcciones del puente: [1]
El 80% de las tramas se inundaron para que la dirección de destino nunca las recibiera, mientras que el 20% era tráfico válido. En redes de gran volumen, el tráfico inundado puede provocar que los puertos se saturen y provoquen pérdida de paquetes y alta latencia.
Otro efecto secundario de las tablas de direcciones agotadas es el compromiso de los datos. Las consideraciones de seguridad se analizan en la inundación de MAC , una de varias causas de inundaciones de unidifusión. Si un usuario final está ejecutando un rastreador de paquetes , los fotogramas inundados podrían capturarse y verse.