Tengo un programa que envía un paquete de multidifusión IPv6 (a ff12::2:0:8afb:382b:c053:85f%en1) cada 50 ms. Lo tengo ejecutándose en una LAN muy simple para una sola computadora (Mac mini <-wifi-> enrutador wifi Linksys <-cat5-> módem DSL <-> Internet). En mi prueba no hay computadoras unidas a este grupo de multidifusión (es decir, nadie está escuchando estos paquetes)
Mi problema es que cuando se ejecuta este programa, el rendimiento WiFi de la Mac cae en más del 50%. Presumiblemente, el problema es que todos estos paquetes de multidifusión están consumiendo gran parte de mi ancho de banda WiFi y causando congestión... pero no entiendo por qué los paquetes se transmiten. Tenía entendido que la multidifusión utiliza un algoritmo de árbol de expansión para garantizar que los paquetes de multidifusión sólo se enruten a hosts que realmente estén interesados en recibirlos. Si eso es cierto, y dado que no hay otras computadoras en mi LAN unidas a esta dirección de multidifusión, ¿no debería mi Mac darse cuenta de eso y no enviar ningún paquete a menos/hasta que algún otro host se una al grupo de multidifusión? ¿O la selección del árbol de expansión solo se implementa en el conmutador y no por los propios hosts?
Respuesta1
La multidifusión es algo complicado.Enrutadoresson los que arbitran los paquetes de multidifusión, y los conmutadores inteligentes a veces pueden garantizar que los paquetes no lleguen a donde se supone que no deben ir. Sin embargo, si no hay un enrutador entre el multicaster y sus estaciones cliente (y no lo hay, si estoy leyendo bien), entonces la multidifusión se comportará exactamente como las transmisiones en esa subred.
Respuesta2
Para agregar a la respuesta de @ sysadmin1138 (este comentario fue demasiado largo para el cuadro de comentarios)...
Sería bueno tener en cuenta que 802.11 aumenta el problema aquí de dos maneras: retransmisión intra-BSS y bajas tasas de multidifusión.
En 802.11, las tramas de inalámbrico a inalámbrico en el mismo AP deben ser retransmitidas de forma inalámbrica por el AP en caso de que el remitente original no esté dentro del alcance de radio del destinatario previsto. Este proceso se llama "retransmisión intra-BSS" y resuelve lo que se conoce como el "problema de nodo oculto", donde dos nodos inalámbricos pueden estar dentro del alcance del AP, pero no dentro del alcance (ocultos) entre sí. Por lo tanto, cada trama que proviene de un cliente inalámbrico del AP y que puede necesitar ir a otro cliente inalámbrico del AP (nota: esto incluye todas las multidifusiones y difusiones) se transmite a través del mismo canal dos veces. Primeroael AP (esto se conoce como Al sistema de distribución o "ToDS") y luego nuevamentedeel AP ("FromDS"), como parte de la retransmisión intra-BSS.
El tramo "ToDS" del viaje tiene la velocidad de datos más alta a la que el cliente puede comunicarse exitosamente con el AP. Entonces, si se trata de un cliente y AP 3x3 N moderno que utiliza canales de 40 MHz con intervalos de guardia cortos, esto puede ser 450 Mbps.
Desafortunadamente, para el tramo "FromDS" del viaje, la trama debe enviarse a una velocidad de datos lo suficientemente baja para que todos los clientes de ese AP la reciban de manera confiable. Esto se debe a que las multidifusión no reciben confirmación en la capa 802.11, ya que provocaría una tormenta de confirmación en respuesta a cada multidifusión.
Algunos AP le permiten configurar explícitamente la velocidad de multidifusión. Otros le permiten definir su conjunto de tarifas "básico" o "requerido", y luego el AP elige la tarifa de multidifusión entre las tarifas básicas. Otros simplemente le permiten configurar su modo de compatibilidad b/g/n (o a/n) y tener una tasa básica predefinida y una tasa de multidifusión basada en eso. Muchos AP utilizan de forma predeterminada el modo de compatibilidad total desde velocidades de datos DSSS 802.11-1997 de 1 y 2 mbps (antes de que 802.11b añadiera 5,5 y 11 mbps). Esto significa que su velocidad de multidifusión podría ser tan baja como 1 mbps.
Entonces, en el peor de los casos, sus multidifusiones podrían estar consumiendo 451vecesel tiempo aire del canal que ocuparía una trama de unidifusión inalámbrica a cableada (o cableada a inalámbrica) del mismo tamaño.
Tenga en cuenta también que en algunos diseños, la retransmisión intra-BSS se realiza mediante microcódigo en la NIC 802.11 del AP, por lo que en esas arquitecturas, estas tramas no pasan a través del procesador host del AP antes de ser retransmitidas. Entonces, incluso si el AP fuera un conmutador "inteligente" que pudiera violar el modelo de capas y realizar espionaje IGMP de capa 3 para podar el árbol de multidifusión, no tendría la oportunidad de hacerlo antes de que la tarjeta de radio ya hubiera hecho intra-BSS. Relé en el marco.
Respuesta3
La multidifusión tiene como valor predeterminado el comportamiento de transmisión cuando no es totalmente compatible con el enrutador local (no con el conmutador). Como tal, tiende a propagarse a todos los nodos conocidos dentro de un segmento de LAN.
Los enrutadores SoHo no son muy conocidos por admitir MultiCast total o correctamente. Muchos dependen de enrutadores ascendentes y sólo esperan clientes a nivel de LAN. Puedes intentar ajustar la configuración de tu enrutador, pero si tu grupo de multidifusión no tiene suscriptores, ¿por qué no desactivarlo en la fuente?