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.
Como no había leído antes este hilo lo he seguido repasando con interés. Tengo que decir que hay una de tus recomendaciones con la que no estoy de acuerdo: el uso de canales anchos (40 MHz) en la banda de 2,4 GHz.
Salvo que en nuestra zona haya muy pocas Wi-Fis cercanas, el uso de canales anchos provoca más problemas que beneficios. Utilizando canales normales de 22 MHz sólo caben cuatro redes sin solapamiento (canales 1, 5, 9 y 13) en la banda de 2,4 GHz, que tiene un total de 84 MHz. Usando canales anchos de 40 MHz sólo caben DOS redes sin solapamiento en los canales 3 y 11.
Desgraciadamente en zonas urbanas lo normal es que haya un porrón de redes inalámbricas a nuestro alrededor, ubicadas en canales sin orden ni concierto, y por tanto con un alto grado de solapamiento. Y el problema empeora si utilizamos canales anchos. Ojo, aunque nuestra inalámbrica sea la ÚNICA que use canales anchos en la zona, también será peor porque nos estarán interfiriendo más redes. En un área con alta densidad de inalámbricas la mejor opción es usar canales de 20 MHz y buscar cuál es el canal en el que haya menos interferencias para mejorar la relación señal/ruido (que al final es lo único que importa). Otro gallo cantaría si habitásemos en una zona con muy pocas redes inalámbricas; en ese caso el uso de canales anchos si nos puede beneficiar; pero en una zona urbana, edificio de viviendas... va a ser perjudicial seguro.
Obviamente la mejor opción es utilizar la banda de 5 GHz, pero ésta tiene el inconveniente de tener menor alcance (aunque también es una ventaja, ya que recibiremos menos interferencias de otras redes en esa misma banda). Lo mejor es usar 802.11ac en 5 GHz gracias a la tecnología de beamforming, con la que básicamente los dispositivos pueden concentrar la energía de la señal en la dirección adecuada. El problema, claro está, es que tengamos dispositivos capaces de trabajar en la banda de 5 GHz, y además que soporten 802.11ac.
Edito para añadir la referencia a una página de la Wikipedia donde se explica la distribución de los canales y bandas usados en redes inalámbricas.
Esta mañana, a las 14:00h, justo después de un corte de comunicación con el router que tuve de 1 minuto, decidí activar un programa de monitorización de la red.
La configuración que tengo, es
Durante el día, he tenido 2 cortes:
En ambos cortes, pierdo la conexión con el Mitrastar y con Google, pero no la pierdo con el Huawei.
He mirado al uptime del router y va por 4 dias y 14 horas, así aún perdiendo 5 minutos la conexión esta tarde, se recupera sólo...
Así que, como esto me parece muy extraño, me ha dado por pensar que lo mismo (en mi caso particular), no es el router el que me está fallando, porque si se quedara bloqueado, supongo que MovistarTV también se quedaría bloqueado... (a no ser que tenga una caché de varios minutos, que creo que no)...
Así que, empiezo a pensar que lo mismo es el PLC el que me está produciendo los cortes...
A ver si vuelvo a cazar algún corte estando delante y en ese momento, me conecto directamente a la wifi del Mitrastar a ver si sigue funcionando o no...
Un saludo.
P.D: Mientras escribía esto, acabo de tener otro... aunque han sido 15 segundos, así que no me ha dado tiempo... :smileymad:
Los PLC son muy muy susceptibles de tener problemas, cortes e inestabilidades, es muy posible que sean estos los que te estén fastidiando
Buenos dias!
Otro dia de pruebas con las baterias de los moviles (S6, S4, S3, Tablet ASUS ) que tenemos enlazados a la red de Movistar y todos los consumos por fin son razonables, entre un 5-8% en reposo desde las 22:00 hasta hoy a las 09:00.
Lo que si hemos hecho al final para alcanzar velocidades mas acordes con lo que tenemos contratado ha sido incluir a la red un Linksys WRT320N que teniamos aqui cogiendo polvo XDD
Al incorporar doble banda, los test que hemos realizado sobre los 5Ghz en los dispositivos, casi todos han rozado los 100Mb de descarga y como siempre los 30 casi clavaos de subida.
Lo que no he conseguido es que por cable desde ese Router superara los 150Mb de descarga, he mirao parametros pero no he visto nada, los cables son Cat6 el Router supuestamente los cinco puertos lan son Gigabyte y la Tarjeta de red tambien funciona perfectamente con los 300Mb
Salu2!
