Buenas EricSantana
Bueno efectivamente lo primero y principal es simplificar todo, el tráfico IGMP puede ser muy puñetero, así que mejor partir del escenario simple, y cuando ese va perfectamente, se puede seguir escalando poco a poco. Así que centrémosno en el escenario simple, es decir, Asus, Switch y Deco al Switch, nada más.
A ver, IGMP Snooping es imperativo para evitar que la red se inunde con tráfico Multicast a destino que no lo solicitan, eso es esencial. Pero en realidad eso solo es la mitad del problema, y a veces incluso (si no se hace bien) causa de otros problemas. Todo es debido a como funciona IGMP, que es el protocolo que usa Multicast.
Simplificado a su máximo exponente, hay un emisor Multicast (Router en este caso), y diferentes "clientes" que quieren acceder al contenido Multicast. Cuando cualquier dispositivo quiere acceder a dicho contenido envía una petición IGMP de unión a un grupo multicast concreto, el Router recibe dicha petición y empieza a emitir dicho stream a toda la red. Cuando el equipo en cuestión desea dejar de recibirlo se puede por lo general enviar una solicitud de salida. Dicho así parece muy simple. IGMP Snooping en este escenario lo que haría sería escuchar esas peticiones IGMP, para que el Router solo envíe físicamente el tráfico a la dirección física correspondiente, y todos felices.
Pero si te das cuenta todo eso funciona bien por los mensajes IGMP, y es donde está la madre del cordero. Si el síntoma clásico de saturación de Switch/Router son las luces parpadeando como locas, rendimiento muy bajo por red/wifi, pixelaciones... cuando es un problema asociado a IGMP (al protocolo en sí), lo más típico es eso... que ves un canal durante X segundos y se te corta, si lo pones de nuevo funciona perfectamente hasta que vuelve a cortarse.
IGMP requiere de unos cuantos parámetros muy importantes, que van a determinar en esencia el buen flujo de esos... "mensajes".El ejemplo anterior no es real, en un escenario real el Router cada X segundos pregunta a TODA la red, quienes siguen unidos a que grupos multicast, y esto es esencial porque si el Router no recibe respuesta, va a cortar el stream. Es decir, que los dispositivos no solo tienen que enviar peticiones de unión, sino que cada X tienen que responder al Router que siguen unidos a dicho grupo, para que el Router le siga enviando el tráfico. Un problema muy habitual es esto, el Deco pide ver un stream y empieza a verlo, pero después de que el Router pregunte quienes siguen, por problemas de "tiempos" no recibe contestación, o no la recibe a tiempo, y corta el stream. Esto puede ser un fallo d configuración del Router, del Switch o del propio dispositivo.
Así que es esencial habilitar IGMP Snooping, pero es esencial que los parámetros del querier IGMP (en este caso sería el Router), esté bien configurado, y que el Switch a su vez no esté filtrando los paquetes IGMP.
Mi consejo.
De memoria no me sé que demonio IGMP Proxy/Snooping usará el AC86U, depende de la firmware y del modelo. Asus cambió esto hace relativamente poco, de memoria no te lo puedo decir. En cualquier caso habría que entrar por Shell y sacar los parámetros por defecto que el Router aplica a IGMP, esto es esencial. En los equipos de Movistar de echo se pueden modificar en la interfaz Web... es lógico, Movistar requiere un buen funcionamiento IGMP, pues es normal que dichos ajustes se expongan. Asus con la firmware por defecto no puedes cambiarlos pero podrías consultarlos, con Merlin podrías tb modificarlos.
Dentro de poder modificarlos, que es importante?? Pues yo usaría IGMPv3, 125 seg como tiempo de Query, 10 segundos de timeout de respuesta como parámetros más importantes, porque son los que más problemas dan en experiencia. Por ejemplo, muchos por fallo de software usan un timeout de respuesta de 1seg, eso significa que el Router cada 125seg va a preguntar a todos que grupos están usando, y solo da 1 seg para que les llegue la respuesta, y si no corta. En ese ejemplo con 125 de tiempo de query y 1seg en tiempo de respuesta, a menos que el d eco conteste muy rápido cada 125seg, o se acabó.
Otros usan un intervalo de Query muy elevado... realmente el problema no es que sea mucho o poco, el problema es que Querier, Switchs intermedios y cliente tienen que entenderse. Si el Router pregunta cada 125seg que es el estándar, pero el Switch internamente borra la lista de Snooping cada 60seg, para cuando el Router vuelve a solicitar los grupos el Switch ya ha eliminado la lista y puede filtrar el tráfico. Pasa lo mismo en el cliente final, si el cliente final requiere refrescarse cada 100seg, si usas un valor superior tendrás problema. Este fallo es extremadamente común en dispositivos de Apple por ejemplo, es lo que pasa cuando juegas fuera de estándar. Tampoco es bueno usar un valor muy bajo, es bueno porque fuerzas actualizaciones constantes, pero generas un tráfico en la red muy alto, que en esencia mata la batería de móviles y otros.
Cuando interpones un Switch en medio el problema se multiplicas, porque el Switch con Snooping depende al 100% del tráfico IGMP, es como construye las tablas de Snooping. Si hay un problema de tiempos o de algún parámetro, puede empezar a filtrar más de la cuenta y bloquear el tráfico.
Así que volviendo a mi consejo:
1º. Simplifica la red al máximo, cuando funcione bien, la escalas.
2º. Revisa la configuración IGMP del Rotuer Asus, puedes verla por SSH, el archivo de configuración, y hablo de memoria, es "/var/mcpd.conf" ó "/var/igmpproxy.conf", como digo depende de Router/Firmware
3º. No tengo a mano dicho Switch, si sacas pantallazo de los ajustes IGMP del Switch podríamos echar un ojo
