En las redes de computadoras , una inundación de unidifusión es cuando un conmutador recibe una trama de unidifusión y la trata como una trama de difusión, inundando la trama a todos los demás puertos del conmutador.
Fondo
El término unidifusión se refiere a una transmisión uno a uno desde un punto de la red a otro punto. Convencionalmente, la unidifusión se considera más segura porque la trama se entrega únicamente al destinatario previsto y no a varios hosts. Este diagrama ilustra la transmisión unicast de una trama de un host 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 hosts de una red:
Causas
El proceso de aprendizaje del puente transparente requiere que el conmutador reciba una trama de un dispositivo antes de que las tramas de unidifusión se le puedan reenviar. Antes de que se reciba dicha transmisión, se utiliza la inundación de unidifusión para asegurar que la transmisión llegue a su destino previsto. Esta es normalmente una condición de corta duración, ya que la recepción normalmente produce una respuesta que completa el proceso de aprendizaje. El proceso ocurre cuando un dispositivo se conecta inicialmente a una red, se mueve de un puerto a otro o después de 5 minutos de inactividad [ cita requerida ] cuando el dispositivo generalmente se elimina de la tabla de reenvío.
Un conmutador al que no le queda espacio en su caché de direcciones inundará la trama hacia todos los puertos. Este es un problema común en redes con muchos hosts. Menos común es la inundación artificial de tablas de direcciones; esto se denomina inundación MAC .
Otra causa común son los hosts con temporizadores ARP más largos que el tiempo de espera de la caché de direcciones en los switches; el switch olvida qué puerto se conecta al host. [1] La solución para evitar esto es configurar el switch con un tiempo de espera de dirección MAC mayor que el tiempo de espera de ARP. Por ejemplo, establezca el tiempo de espera de MAC en 360 segundos y el tiempo de espera de ARP en 300 segundos.
Los dispositivos que no sean conmutadores también pueden crear inundaciones de unidifusión. Un enrutador que tiene una interfaz de puente pero no tiene la dirección de la trama de destino en la caché del puente inundará la trama a todos los miembros del puente. [2]
Las características mal configuradas de las redes también pueden provocar una inundación 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 hablar 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 de El host B y los conmutadores intermedios en la ruta 2 nunca aprenderán la dirección MAC de destino del host A. [3]
Una causa final 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ápido , la caché de direcciones de ese conmutador se vaciará, lo que provocará que todas las tramas subsiguientes se desborden de todos los puertos hasta que el conmutador aprenda las direcciones. [4]
Remedios
Bloquear inundaciones de unidifusión en un conmutador de Cisco es fácil de hacer, pero no está habilitado de forma predeterminada. Después de asegurarse de que los tiempos de espera y / o características de seguridad se han configurado para mantener entradas de la tabla de puertos de acceso de cliente más larga que típicos de host de caché ARP tiempos de espera, este comando se utiliza para acallar las inundaciones unicast en esos puertos: [5]
Switch (config-if) # unidifusión de bloque de switchport
Otras técnicas implican aislar hosts en la Capa 2, lo que bloquea la comunicación dentro de la LAN que no está 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 extremo inferior: [6]
Switch (config-if) # switchport protegido
Una solución de conmutador cruzado más robusta que la 'protección de puerto de conmutador' es el uso de VLAN privadas . [7]
Para bloquear la inundación en una máquina Linux lo suficientemente moderna como para tener iproute2 instalado, puede controlar la inundación en el puente de dispositivos 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:
brctl setageing br0 330; echo 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.
Efectos en las redes
Cuando una red experimenta una inundación de unidifusión, el rendimiento de la red se degrada. Aquí hay un gráfico de un puente antes y después de ajustar el tamaño de la caché de direcciones del puente: [2]
El 80% de las tramas se desbordaron para nunca ser recibidas por la dirección de destino, mientras que el 20% era tráfico válido. En redes de alto volumen, el tráfico inundado puede hacer que los puertos se saturen y provoquen la pérdida de paquetes y una 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 las varias causas de las inundaciones de unidifusión. Si un usuario final está ejecutando un rastreador de paquetes , las tramas inundadas podrían capturarse y visualizarse.
Ver también
Referencias
- ↑ Steven King (17 de junio de 2009). "Inundación unicast" . Consultado el 27 de enero de 2012 .
- ^ a b Rudy Rucker (27 de enero de 2012). "Arreglo para inundaciones de unidifusión" . Consultado el 8 de marzo de 2021 .
- ^ "Eliminación de reenvío asimétrico y unicast Flooding" . Cisco Systems Inc . Consultado el 27 de enero de 2012 .
- ^ Balaji Sivasubramanian (10 de septiembre de 2004). "Solución de problemas de inundación de unidifusión debido a la topología" . Prensa de Cisco . Consultado el 27 de enero de 2012 .
- ^ Jeremy Stretch (4 de junio de 2010). "Bloqueo de inundaciones de unidifusión desconocidas" . PacketLife.net . Consultado el 27 de enero de 2012 .
- ^ Petr Lapukhov (14 de julio de 2008). "VLAN privadas revisadas" . Consultado el 7 de abril de 2012 .
- ^ "Configuración de VLAN privadas" . Cisco . Consultado el 7 de abril de 2012 .