modo Bridge en router wifi 6
Buenas, Alguien sabe la solución del router wifi 6 de Movistar al configurarlo en Bridge modo puente, sufro reinicios o cortes y vuelve a sincronizar de nuevo la conexión , pensaba que era el primer router que era defectuoso pero en el siguiente que me ha puesto el técnico también me pasa lo mismo , (con el hgu no me pasaba esto iba perfecto ) alguien me puede iluminar si configurando algo puedo solucionarlo.
Buenas Fide84
Pues me temo que es placebo o cualquier otro problema que puedas tener en tu red/Router, por dos razones fundamentales:
1º. Como te he dicho es exactamente lo mismo, es más, puedes darle a monopuesto, aplicar, y ver los ajustes que ha establecido en el menu avanzados. Lo único que hace es poner en Bridge la interfaz WAN de Interet. Esto no es una cuestión de puntos de vista diferentes, no es algo que pueda o no ser opinable, es que da exactamente igual, es lo mismo.
2º. En el momento que está en monopuesto, la conexión a Internet (solo la de Internet, no VoIP ni IPTV) pasa a gestionarla el Router propio, el HGU es totalmente transparente ante ello. El HGU no induce ninguna latencia (mentira, todo induce, hablamos de menos de 1ms, por ello lo despreciamos.
Es más. Pongamos que pudieses poner el HGU en bridge real, que repito, NO PUEDES, y configuras tu Router propio para configurar las 3 VLAN independientes en tu propio Router. De modo que realmente el HGU únicamente funcionase como ONT, como si tienes por ahí una de las viejas ONT Huawei de Movistar. Bien, el resultado sería igualmente el mismo a nivel de rendimiento/latencia/jitter... ya que en ambos escenarios, en bridge real o en monopuesto, la conexión la gestiona tu propio Router.
Comprobar esto es extremadamente sencillo, tan solo hay que lanzar si se quiere WinMTR y unos 200 paquetes y ver la latencia media que hay al... Router propio? a la IP de enlace de PPPoE? Pongo interrogante porque ni siquiera verás el HGU en dicha traza, aparecerá la IP De tu Router y luego posiblemente la IP del servidor PPPoE (192.168.144.1). Como he dicho, transparente. Pero por supuesto que sea transparente no quiere decir que no pueda inducir latencia TODO induce latencia, pero la latencia que induce es menor a 1ms.
Un WinMTR de unos 200 o 300 paquetes, con un Router propio, sin importar en monopuesto o un bridge real (que repito no puedes hacer), lo que debería de mostrar es:
-Un valor de "0ms" para el primer salto de media (realmente no es 0ms, es un valor menor de 0.5ms y se redondea a cero). Ese salto es tu Router, cualquier latencia que aparezca ahí es únicamente culpa y responsabilidad de tu Router o de la conexión de tu equipo con el Router. Obviamente si se hace por WIFI puedes esperar cualquier valor, y si es por cable y sale más alto, tienes un problema de configuración en tu Router o de tu propia red.
-Un valor entre 0-2ms al siguiente salto, que generalmente es el servidor PPPoE.
Y a partir de ahí la latencia va subiendo poco a poco.
De nuevo, me temo que son muchos mitos y malinfornaciones que uno lee de aquí y de allí aderezado con lo que uno cree o deja de creer. Si quieres puedes usar esta "tabla":
a) Los HGU no tienen un modo Bridge. Tienen un modo llamado monopuesto. Da igual que lo hagas desde un menú o manualmente desde el otro, ambos siguen siendo monopuesto. Para que fuese un Bridge real tendrías que en el menu avanzado borrar todas las interfaces WAN (las 3), y crear una única interfaz WAN de tipo Bridge sin VLANs, y en tu Router propio deberías de configurar 3 VLAN diferente todas ellas etiquetadas. Así que a menos que hagas eso, y no lo estás haciendo, es monopuesto.
b) El modo monopuesto hace indiferente al HGU a partir de ese momento en lo tocante a Internet. Desde ese momento absolutamente TODO, lo bien o mal que funcione Internet, depende únicamente de tu propio Router. Da igual que sea latencia, jitter, bufferbloat... es tu Router y/o tu red/dispositivos, el HGU ha dejado de tener nada que ver en ello.
c) El Bufferbloat es una consecuencia únicamente que parece cuando se satura el canal de subida o bajada (especialmente el de subida). Es decir tan solo aparece si durante un tiempo prologando estás haciendo uso de más del 90% de la línea. Aquí es cierto que sí se puede mejorar o empeorar si se configura un Router de forma adecuada. Se puede configurar un HGU funcionando en modo normal, para no tener Bufferbloat a través de QoS. Del mismo modo que puede hacerse también en otros Router. Eso sí, configurarlo bien, si uno pretende configurar QoS de forma adecuada dándole a dos botones u ordenando una lista de 6-7 apartados como se hace en Asus... pues obviamente estás configurando QoS de forma muy deficiente... que no quiere decir que no de resultados, sino que los resultados que obtienes son muy por debajo de lo que se puede obtener configurando QoS adecuadamente, incluso en el HGU.
d) Y esto va a doler a los "gamer"... no existe un Router gaming, no existe un Router para jugar mejor o peor, no existe un ajuste "raro" en un Router para mejorar la latencia, el jitter y otros. Lo único que realmente sí puede afectar en un Router a la hora de jugar, y sólo en circunstancias extremas, es la correcta configuración de QoS y de la red propia de uno mismo. Y esto sí es importante porque si estamos en la red ejecutando un cliente Torrent 24/7 descargando constantemente a 800Mbps y subiendo a 600Mbps... esto si va a inducir algo de latencia en tu propia red local. Pero si no es el caso, y rara vez lo es, el Router tiene efecto cero en latencia/jitter del juego.
Y repito que esto se puede comprobar de forma sencilla, no hace falta conocimientos de nada. Solo tienes que coger WinMTR, lanzar 200-400 paquetes contra el destino que quieras, el servidor de juegos que más coraje te de, y puedes ver perfectamente donde se acumula la latencia y donde no. Tan solo en el caso donde la latencia se acumule y aparezca en el primer salto, puede estar implicado el Router. Y si así es, no será el Router casi con total seguridad, sino la configuración de tu red o alguna anomalía que tengas en ella, puesto que la única latencia que tu Router va a inducir es menor a 1ms.
Datos de un HGU6 en monopuesto con mi propio Router detrás, sin parar nada que ahora mismo esté haciendo en la red ni otros dispositivos. Algo más de 100 paquetes enviados, el primer salto que es mi Router media de 0ms (menos de 0.5ms). El siguiente salto es la centralita, media de 2 con un mínimo de 1. Hay un pico puntual de 44ms que automáticamente se desprecia por cuestiones estadísticas, es algo habitual cualquier punto.
Mirando el detino final, 8ms de mínima y media de 9ms, eso implica un jitter de 1ms. Todo ello a Google, pero se puede repetir para cualquier destino, lo importante aquí y lo único que tiene relevancia a la hora de tu red es el primer salto.
Ahí no cabe diferencia alguna entre 22ms o 16ms ni mucho menos :). Para que eso fuese real, lo que dices, el segundo salto tendría que tener una diferencia él solito de al menos 8ms consistentes con el resto de la traza, (es decir que el tercer salto tuviese ya más de 8ms tb) y el jitter igualmente fuese mucho más elevado. Es decir, en tu caso la segunda línea debería de ser algo como:
192.168.144.1 Best=3 Avge=9 Worst=54
Es decir, que aunque el mejor valor fuese 3 por ejemplo, la media fuese de unos 9ms, y al existir tal desviación de 3 a 9, sí podríamos intentar concluir que si hay un jitter elevado. Y por supuesto esto verlo reflejado en los saltos siguientes. Bien, pues a menos que veas esos datos o similares, no hay diferencia alguna uses como uses el HGU.
-------------------------
Nota: Si te quieres ahorrar las comprobaciones te las ahorras. ya te contesto de nuevo: No hay bridge en los HGU, el modo monopuesto es el mismo si lo configuras en la interfaz avanzada que en la simple. Y no afecta en nada a la latencia, al jitter ni al bufferbloat, no tiene relación alguna con ello.
Saludos.
