Gracias taker59 como siempre, tendréis que conformaos los que tengáis TV con modificar el tiempo de los query, si con 60 como dije va bien... puede ser el punto de partida
Theliel escribió:Gracias @taker59 como siempre, tendréis que conformaos los que tengáis TV con modificar el tiempo de los query, si con 60 como dije va bien... puede ser el punto de partida
He colocado los ajustes del comtrend vg-8050 y he visto que la actividad del led wifi a disminuido considerablemente.Tengo puestos estos.....:
<IGMPproxy> <Entry Enabled="Yes" Robustness="2" QueryInterval="125"
QueryResInterval="10" LastMemQueryInterval="10" StartQueryInterval="10"
StartQueryCount="2" MaxGroups="25" UnsolicitedReportInterval="1"
SSMEnable="true" ProxyVersion="IGMPv3" />
</IGMPproxy>
Por cierto,seria conveniente crear una nueva entrada con MLDproxy (igmp ipv6) para el que tenga ipv6 activado? Mas o menos seria como esta arriba ,pero....con MLDproxy.
<MLDproxy> <Entry Enabled="Yes"......
</MLDproxy>
P.d:No hagais un copy&paste del ejemplo de arriba,que la podeis liar en el backup.
buenas taker59
Por lo que se ve el vg-8050 usa por defecto 125segundos (creo que es el tiempo por defecto del estándar), y el Mitrastar como dije 10segundos inexplicablemente, de ahí el gran trafico IGMP que se estaba produciendo.En un principio dije 60 por probar, si con 125 va bien... 125 me parece aun mejor ;), gracias taker59. Lo que sigo sin entender por qué si incluso en otros modelos se usan valores "lógicos" en el Mitrastar se ha optado por tal burrada, normal que muchos que tenían tele no notasen tanta mejoría.
El uso de IGMPv3 o 2 puede tener un impacto menor, pero si el router es compatible perfecto (y presupongo que sí porque ya lo has probado), tiene algunas características algo mejores respecto a IGMPv2, nada demasiado importante para el caso que nos atañe, pero siempre debería de ir mejor.
Sobre IPv6, yo es que personalmente lo desactivaría de forma global. Para que tener habilitado IPv6 ahora mismo... genera más tráfico y no vamos a disfrutar hoy por hoy de ello.
A ver si los que teneis tele lo probáis unos días y si funciona bien lo añadimos, seguro que hace feliz a muchos usuarios que tienen tele.
Hola Theliel. Acabo de ver tu solución de subir el IGMP proxy query interval al estándar de 125 s para lo del consumo de batería de los dispositivos Wi-Fi.
A mí me pusieron un Mitrastar, pero en cuanto pude lo reemplacé por un MikroTik hEX (que sí aguanta descargas a 300 Mbps sin que se le sature la CPU a causa del PPPoE). Precisamente durante mis pruebas con el MikroTik tenía problemas con la tele, ya que sólo veía los canales durante unos segundos y luego se congelaba la imagen. El IGMP proxy de MikroTik usa por defecto 125 s para el query interval y 10 s para el query response (los valores estándar). Entonces mirando la configuración del Mitrastar descubrí que tenía puestos 10 s y 9 s respectivamente (imagino que los 9 s del query response interval se deben a que siempre debe ser inferior al query interval). Al configurar esos mismos valores en mi MikroTik mis problemas con la tele desaparecieron.
La razón por la que creo que tenía problemas con los valores estándar (y por defecto en el MikroTik) de esos intervalos del IGMP proxy es que yo tengo el deco conectado a un AP+switch. Resulta que tengo un cable Ethernet desde donde tengo el router hacia el salón, y allí tengo una AirPort Extreme 802.11ac de Apple funcionando en modo "bridge", es decir, como AP y no como router. La AirPort Extreme incluye también un switch Ethernet de cuatro puertos, a uno de los cuales tengo conectado el deco (y otros cachivaches a los otros puertos).
El caso es que tengo activado el IGMP snooping en la AirPort Extreme. Hay que decir que su implementación es un poco bruta, porque de entrada corta TODO el tráfico multicast hacia la inalámbrica, sin contemplaciones. Pero en la parte Ethernet (el switch) sí que va registrando qué clientes IGMP se registran en el proxy y desde qué puertos, cortando el tráfico multicast hacia los puertos para los que es innecesario. Pues bien, mi teoría es que con el IGMP proxy query interval de 125 s la AirPort Extreme (es decir, su IGMP snooping) "se olvida" de los registros IGMP, es decir, caducan por timeout, y la consecuencia era que los canales se me quedaban congelados.
Te explico todo esto para que sepas que la solución de elevar el IGMP proxy query interval a su valor estándar de 125 s puede causar problemas en caso de tener el deco conectado a un switch con IGMP snooping activado. No digo que los cause siempre; es posible que dependa del modelo concreto de switch. Desde luego con la AirPort Extreme 802.11ac hay problemas.
Un saludo y gracias por la ayuda que estás prestando a las "víctimas" del Mitrastar. ;)
Buennas BOFH, gracias por tus apuntes, y como comentario rápido... efectivamente es algo que se debe de tener en cuenta, aunque a efectos prácticos no debería de ser un problema (por lo que se ve en tu AE podría serlo)
Es complicado, porque depende en última instancia de como se implementa en este caso IGMP Snooping (IS) en cada dispositivo, y cada cual hace un poco lo que cree oportuno en este aspecto.
Efectivamente para que IS funcione correctamente el Swich/Router en el que se está aplicando tiene que mantener una tabla con los clientes asociados a cada grupo multicast, y estas tablas son restrictivas, es decir... si no estás en la lista, no hay tráfico, no al revés. El funcionamiento es muy sencillo, pero por tanto para que IS funcione necesita conocer estos dispositivos, es decir, quien entra, quien sale. Para que el router/switch pueda conocer esto (construir su tabla) necesita hacerlo de algún modo, y aquí entra ya cada implementación.
Algunos IS implementan su propio Query, no dependen de un Router que les facilite la información, ellos solitos envían preguntas IGMP a sus clientes sobre a que grupo pertenecen, y así construyen sus tablas. Otros en cambio usan al Router de "Querier", y van interceptando los mensajes que envía/recive el router para mantener actualizada su tabla.. el problema en este caso es que dependes totalmente del Router, y eso implica ademeás que los query del router son transmitidos a toda la red sin excepción, o estos podrían no llegar. Y existen otras implementaciones aun más... intrigantes.
IGMP Proxy no se implementa/activa en Movistar por defecto para ser usado de querier, sino para que el tráfico multicast pueda ser efectivamente "cambiado" desde la VLAN desde la que llega a la LAN. Pero al estar habilitado en cualquier caso, como efecto secundario también efectivamente sirve de "Querier" a la red.
Si el Switch/s que está debajo requiere en su implementación un querier (usando en este caso el router principal para ello), efectivamente hay que tener en cuenta que si el tiempo de query es muy alto el Switch IS termine perdiendo su tabla y por ende cortando todo el tráfico.
Pero es un caso extremo, dado que por lo general, al igual que un querier de 10 segundos es una barbaridad, un TimeOut de IS menor a 125 lo es. Por regla general el estandar es de 260s, que en el caso concreto del Mitrastar en este caso sí es el que usa. Esto tiene además una explicación muy lógica, si por defecto se usan queries de 125, no tendría lógica usar timeout en IS menores a este valor.
Al final es una cuestión de como se implementen las cosas, cada fabricante, programador... ajusta sus dispositivos como le parece, a veces de forma acertada a veces no. En el Comtrend anterior usaban 125, en el Mitrastar 10... en tu microtik dices que también 125 poo defecto. En ambos un timeout para su propio Snooping de 260, pero en tu AE parece que el Snooping es bastante más puñetero, no funcionando a nivel WIFI y por lo que se ve con un TimeOut bastante menor.
Teniendo en cuenta las políticas de Apple no creo que puedas configurar ese TimeOut, pero sí podrias encontrar el valor al que está establecido. Dado que debe de ser menor a 125, presupongo que estará a 60s o 120s.
Otros Switch ni siquiera se tienen que preocupar por esto porque no dependen de un Querier, por eso digo que es un asunto... "complejo".
En cuestiones de dispositivos de red, la mayoría de las veces no es algo negro o blanco, a veces son sencillamente decisiones que se hacen pensando en una cosa haciendo que otra pueda salir mal, o de forma más incorrecta.
En equipos destinados a uso residencial, la mayoría de parámetros no son visibles al usuario, que dolor de cabeza sería para estos!! Así que se ajustan como mejor se cree/quiere. Existen estándares más o menos que se ciñen por lo general al buen uso en la mayoría de los casos, pero eso no garantiza primero que uno pueda saltarse esas "normas" (Apple por lo general escucha poco y hace lo que le da la gana), y tampoco garantiza que los ajustes que vienen preestablecidos puedan satisfacer nuestros escenarios específicos.
Es por eso que existen equipamientos realmente potentes con otro tipo de usos en mente, los cuales puedes ajustar totlamente a tus necesidades... pero esto no lo vas a ver en equipos residenciales por lo general, a menos claro que uses firmwares de terceros que sí permiten ajustes mucho más finos o dispositivos más especificos y orientados a la versatilidad.
No noto nada de v2 a v3,lo puse por poner.Respecto a los 125s,pues en media hora he visto con el cpu spy (android) que el movil ha estado 20 minutos en reposo ,unos 4 en 300Mhz y los demas repartidos.Un cambio brutal :smileyvery-happy:
no hay nada como cortarle el pienso al Router ;)
Router silencioso, dispositivos felices.
