stringtranslate.com

Inundación de unidifusión

En las redes informáticas , una inundación de unidifusión se produce cuando un conmutador recibe una trama de unidifusión y no sabe que el destinatario está en un puerto de conmutador en particular. Dado que el conmutador no tiene información sobre qué puerto, si es que hay alguno, puede utilizarse para llegar al destinatario, reenvía la trama a través de todos los puertos excepto por el que se recibió.

Fondo

Unicast se refiere a una transmisión uno a uno de un nodo de una red a otro. Este diagrama ilustra la transmisión unicast 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 desde el que recibió la trama:

Causas

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 una transmisión de este tipo, se utiliza una inundación de unidifusión para garantizar que las transmisiones lleguen a sus destinos previstos. Esta es normalmente una condición de corta duración, ya que la recepción suele producir una respuesta que completa el proceso de aprendizaje. El proceso se produce cuando un dispositivo se conecta inicialmente a un segmento de red o después de que su dirección e 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 la 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 se desconecta.

Cuando un puente o conmutador no tiene espacio libre 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 las 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 más largo 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 de FIB más largo que los tiempos de espera de caché ARP de los nodos en su red. Cuando un nodo necesita enviar una trama a un host después de que caduque su entrada de caché ARP correspondiente, 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 host B y el host A utiliza la ruta 1 para comunicarse con el host B, pero el host B utiliza la ruta 2 para responder al host A, 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 causa final de las inundaciones de unidifusión son los cambios de topología. Cuando cambia el estado de un enlace en un puerto de red que participa en un árbol de expansión rápido , la caché de direcciones de ese conmutador se vacía, lo que hace que todos los marcos posteriores se inunden de todos los puertos hasta que el conmutador vuelva a aprender las direcciones. [4]

Remedios

Los conmutadores Cisco cuentan con una función que bloquea las inundaciones de unidifusión, pero no está habilitada de manera predeterminada. Después de asegurarse de que se hayan configurado los tiempos de espera y las funciones de seguridad para mantener las entradas de la tabla en los puertos de acceso de cliente por más tiempo que los tiempos de espera típicos de la caché ARP del host , se utiliza este comando para silenciar las inundaciones de unidifusión en esos puertos: [5] [6]

Switch(config-if)# switchport bloque unicast

Otras técnicas implican aislar hosts en la capa 2. Los puertos configurados como puertos protegidos [7] tienen prohibido comunicarse con otros puertos protegidos. [8] Las VLAN privadas implementan el aislamiento de puertos de manera que los miembros de la VLAN solo pueden comunicarse a través de un enlace ascendente designado y no pueden hablar con otros miembros de la VLAN. [9]

Efectos sobre las redes

Cuando una red sufre una inundación de unidifusión, el rendimiento de la red puede verse afectado. 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 los marcos se desbordaron y nunca fueron recibidos por la dirección de destino, mientras que el 20% era tráfico válido. En redes de gran volumen, el tráfico desbordado puede provocar la saturación de los puertos, lo que genera 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 el caso de las inundaciones de MAC , una de las diversas causas de las inundaciones de unidifusión. Si un usuario final está ejecutando un analizador de paquetes , los marcos inundados se pueden capturar y visualizar.

Véase también

Referencias

  1. ^ de Rudy Rucker (27 de enero de 2012). "Solución para inundaciones de unidifusión" . Consultado el 8 de marzo de 2021 .
  2. ^ Steven King (17 de junio de 2009). «Unicast Flooding» ( Inundación de unidifusión) . Consultado el 27 de enero de 2012 .
  3. ^ "Eliminación del reenvío asimétrico y las inundaciones de unidifusión". Cisco Systems Inc. Consultado el 27 de enero de 2012 .
  4. ^ Balaji Sivasubramanian (10 de septiembre de 2004). "Resolución de problemas de inundación de unidifusión debido a la topología". Cisco Press . Consultado el 27 de enero de 2012 .
  5. ^ Jeremy Stretch (4 de junio de 2010). "Bloqueo de inundaciones de unidifusión desconocidas". PacketLife.net . Consultado el 27 de enero de 2012 .
  6. ^ "Bloqueo de inundaciones de unidifusión y multidifusión de puertos" (PDF) . Consultado el 9 de julio de 2024 .
  7. ^ "Configuración de puerto protegido" . Consultado el 10 de agosto de 2024 .
  8. ^ Petr Lapukhov (14 de julio de 2008). "Revisión de las VLAN privadas" . Consultado el 7 de abril de 2012 .
  9. ^ "Configuración de VLAN privadas". Cisco . Consultado el 7 de abril de 2012 .