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
Buenas Theliel ,
Gracias por ayudarme. En cuanto al switch el tema es que lo tengo en una caja estanca en el exterior de la vivienda por donde entra la fibra, donde está la entrada de las antenas de TV, etc. y lo tengo todo cableado por tubos desde el switch a 7 rosetas. Por una de ellas viene la del router y las 6 restantes a cada una de ellas, por lo que simplemente desconectando los cables de las rosetas debería simplificar la red.
Ahora estoy fuera de casa para probar los decos, pero me he conectado remotamente y te copio el pantallazo del switch.
Cuando tenga un rato me conecto al router (edito y pego la configuración)
¿Me recomiendas ponerle firmware Merlin al Asus?
Saludos
Buenas EricSantana
La firmware de Merlin es muy similar a la de Asus, realmente es la misma con algunos cambios, desde mi punto de vista muy bien venidos. De echo Erik "trabaja" codo con codo con Asus multitud de veces, que no quiere decir ni mucho menos que esté en su plantilla, el es totalmente independiente, pero digamos que se lleva "bien" con ellos. En definitiva... que no es una firmware "pirata" o de "sabediosque".
Mirando por otro lado la configuración IGMP del Asus no la veo mal, es cierto que 20 en Query Interval no es nada adecuado, puede dar problemas y además freir la batería de móviles/tablets y otros. El resto no pinta demasiado mal, y no te podría asegurar que el QueryInterval sería el que provocase los problemas, el HGU usa por defecto el mismo valor y lo he criticado multitud de veces, no queremos freir la batería de los móviles!! y créeme que hay diferencia de consumo entre un 10-20% si estan conectados a WIFI todo el tiempo.
Si se pudiese asegurar eso, el resto sería al parecer del Switch. Lo bueno del Asus que puedes capturar tráfico con tcpdump, que es lo mejor para diagnosticar. Un ABC simple sería:
1º. SSH al Asus
tcpdump -i br -w micaptura.cap igmp
Eso debería en principio ser capaz de capturar todo el tráfico IGMP de y desde el Router y lo guardaría en el archivo especificado. Obviamente lanzarlo en una carpeta que podamos tener acceso, por ejemplo en un pen que tengamos conectado o en /tmp y recuperarlo por FTP/SFTP o el modo que se quiera.
Mientras que está corriendo, asegurarse que el deco está encendido, y mientras se captura: Se pone un canal cualquiera, se espera a que se corte. Importante, medir el tiempo que pasa más o menos desde que se pone hasta que se corta. Poner otro canal y volver esperar a que se corte (volver a medir el tiempo aprox). Cortar la captura, sacar el archivo,
2º. Con ese archivo se pude diagnosticar con suerte que pasa. Si lo haces y quieres me lo mandas por privado y le echo un ojo a ver si veo algo que llame la atención, nos debería decir si es el Router o es el Switch, que será lo más probable
Hola de nuevo Theliel ,
Probé a cambiar antes de nada el valor de igmp-query-interval de 20 que estaba a 125 como me habías comentado en la primera respuesta y han empezado a funcionar perfectamente todos los decodificadores conectados al switch, pero el decodificador conectado directamente al router se congela ahora a los pocos segundos de cambiar de canal, antes este era el único que funcionaba bien.
Edito: Al poco tiempo, el decodificador que estaba conectado directamente al router Asus empezó a funcioanr con normalidad hasta el momento. Supongo que no estaba sincronizando bien los datos multicast.
