Buenas pitxanegra
Con gusto contesto a tus puntos, la mayoría de ellos sin ningún tipo de fundamento:
1. Gestión de DNS y soberanía de red:
Esto no es correcto. De ninguna manera. Yo mismo uso un servidor PiHole en local, y jamás he tenido un solo problema con ningún HGU, ni en Monopuesto ni en modo nominal. Es cierto que Movistar tiene un servicio de Seguridad Integrada (deshabilitado por defecto) que puede interceptar peticiones DNS para filtrados DNS básicos de toda la vida (seguridad, contenido, etc). Pero quitando esto, y que repito no está habilitado por defecto ni use usa, ni Movistar ni el Router interceptan ninguna petición DNS. Puedes usar sin la menor complicación el servidor DNS que te de la gana, sea un servidor externo, sea un servidor interno (PiHole), puedes modificar tanto las DNS del propio Router como las que asigna por DHCP.
2. Imposibilidad de Modo Bridge / Módem Puro (Punto Crítico):
Creo que lo había explicado, pero por si se me quedó en el tintero, te respondo con gusto. Dudo enormemente que Movistar vaya a implementar algo que ya tiene implementado de un modo mucho más lógico y coherente. No tendría ningún tipo de sentido permitir por un lado un modo "Monopuesto" y por otro lado un modo Bridge Real. La razón de que Movistar optase por el modo Monopuesto, como ya he dicho, es precisamente para poder permitir que el usuario pudiese usar prácticamente cualquier Router que quisiese. Si Movistar implementase un modo Bridge real, el número de usuarios que se beneficiarían sería dentro del 5% que a lo mejor usa su propio Router, un 10% de ese 5% o menos. Si pones todo ello en la balance es obvio que sistema escoges: Monopuesto. ¿Por qué? Porque no tiene ninguna limitación con respecto al Bridge real, y permite en esencia usar el 99% de los Router del mercado. Dices, y cito textualmente:
"No permite ... que delegue la gestión de la sesión PPPoE, el NAT y el enrutamiento a un firewall/router profesional de terceros"
Totalmente falso, el modo Monopuesto lo hace. En Monopuesto delegas la sesión PPPoE, la gestión de Internet pasa de forma integral a tu propio Router, que doy por sentado que hará NAT a su vez. Lo único que hace es quitar la necesidad de tener que lidiar con tres interfaces etiquetadas por VLAN.
Por otro lado esgrimes:
"El modo "monopuesto" de estos equipos sigue manteniendo una tabla de NAT activa, y una capa de software que degrada el rendimiento de la línea de 10Gbps .... Para un entorno de alto rendimiento, el HGU7 actúa como un "cuello de botella" propietario..."
De nuevo, totalmente falso e infundado. Sí, claro que el HGU sigue manteniendo una tabla NAT, dado que la red del HGU no desaparece. El no-problema de esto es que dicha tabla NAT no tiene absolutamente nada que ver con tu conexión a Internet que has delegado, no degrada absolutamente en nada al rendimiento de la línea, no es ningún cuello de botella, no hay ningún software/demonio interno que te esté de un modo u otro afectando a la línea/conexión. No existe ningún tipo de inestabilidad en el modo Monopuesto, ni problema de velocidad. Llevo usando el Modo monopuesto desde el primer HGU que salió, y lo tengo configurado ahora mismo en el HGU7 del mismo modo... cero problemas. Cero cuellos, cero inestabilidades, cero limitaciones, cero problemas de velocidad... Lo que quizás no termina de calar aquí, es que cuando usas el modo monopuesto, es tu Router el que pasa a gestionar TODA la conexión, internamente, el HGU actúa sobre la VLAN6 en esencia lo mismo en monopuesto que si fuese un bridge real, lo único que hace es quitarle/añadirle el etiquetado para que puedas usarlo... y no, esto no causa ningún problema ni cuello. Te podría poner montones de métricas tanto en Monopuesto como en modo Nominal, incluso como Bridge real (accediendo a la Shell interna y a mano), para que vieses el impacto que tiene: Cero.
3. WIFI7 y MLO:
No es ninguna falacia de autoridad. Si me preguntas a mí personalmente, te diría que prefiero un Router que me de control total de cada parámetro posible, lo que son cientos de ellos, y parametrizarlo absolutamente todo, como hago con mis equipos. Eso no tiene absolutamente nada que ver cuando tienes que tomar en cuenta al usuario medio. Como puse en mi "review" (puedes leerla, está en el foro), soy el primero que critiqué a Movistar por no incluir la posibilidad de deshabilitar el SSID único aun a expensas de no poder usar MLO. Como dice en aquel post, aquí se ha primado por intentar maximizar el rendimiento WIFI "bruto" forzando las capacidades estrellas de WIFI7, como por ejemplo forzar el ancho a 160MHz, y no la estabilidad general. Es un problema únicamente de márketing, del mismo modo cuando los fabricantes hace ya años (aunque algunos aun lo hacen) configuran el Router en la banda de 2.4GHz para emitir en 40MHz. Eso no quiere decir ni mucho menos que creo que Movistar sí debería de permitir de forma más amigable la deshabilitación de esto, de hecho a nivel interno es trivial y la firmware está preparado para ello, únicamente hay que poner un botón/switch y listo. A pesar de ello, se puede usar de mientras el "parche" especificado.
4. Seguridad WPA y protocolos de legado
Como te dije en la primera ocasión, no tengo idea de que problemas hablas... La interfaz web ya permite todos los modos que consideramos normales a día de hoy: OWE, WPA2-PSK AES, WPA2/WP3 y WPA3-SAE. Hasta la fecha no he encontrado un solo dispositivo con problemas. Y ojo, me creo que pueda aparecer cualquier tipo de incompatibilidad con algún dispositivo en concreto, como es natural es imposible ver el comportamiento real del 100% de dispositivos del mercado. En los escenarios que he podido probarlo (en varios domicilios por cierto), no he visto ningún comportamiento anómalo en el modo Mixto
Sobre lo que dices de SSH en este punto, no tengo tampoco claro a que te refieres... sí, puedes hacerlo por SSH, pero... ¿con que objetivo? puedes configurarlo desde la interfaz Web sin ningún tipo de problema. De hechola interfaz SSH existente es, precisamente, para usuarios avanzados que pueden necesitar algún ajuste fino adicional que la interfaz Web no permite, es de suponer que esas necesidades las va a tener un usuario avanzado, y que por ende para él no es ningún problema el uso de SSH
5. Gestión de Canales y DFS
De hecho, una de las características mejores que tiene este HGU7, es que posee una antena dedicada únicamente para monitorizar el espectro de 5GHz, y así evitar el tiempo requerido y obligado para CAC. El algoritmo que provoca el salto, no tiene en cuenta únicamente el ruido que pueda existir en los bloques disponibles, sino que igualmente requiere por obligación, como es lógico, no saltar a ningún canal que esté en uso por radar/estaciones. El único bloque no DFS es el primer bloque, y es sólo de 80MHz. Si lo que quieres es evitar que salte, es la única forma de hacerlo, cualquier otro canal va a saltar, antes o después. La única diferencia es que gracias a la antena dedicada, el salto es cuasi-instantáneo. Obviamente es un salto, pero es que ese salto se va a dar, no se puede evitar, a menos que uses precisamente MLO o conexión simultánea. Antes de saltar, el Router por medio de 802.11h avisa a los dispositivos conectados del salto y el canal destino... pero aun así la "reconexión" es obligada, lo que en esencia se va a traducir en un micro-corte
Por cierto, como bien dices, los usuarios llamemos "avanzados" que requieren de unas altas prestaciones y fiabilidad, sobre todo si se dedican o hacen de forma extensa sesiones de streaming y gaming... no usan WIFI :), no es una decisión muy inteligente... ¿te imaginas servidores a los servidores de Google, Netflix, bancos.... que usasen Wi-Fi entre ellos? Y ya no por una cuestión únicamente de caudal, obviamente, en esencia es que la información es demasiado valiosa para dejarla en manos de una onda de radio que se muere, porque el vecino ha encendido el microondas. Simple como eso.
La única queja real que tengo en este punto con Movistar, y que ya expresé, es que como sucede con MLO y el SSID único, obligan a usar por defecto un ancho de 160MHz, y ahora mismo la interfaz web no permite establecerlo en 80Mhz, cosa que sí puede hacerse por SSH, y que espero que veamos en futuras actualizaciones.
6. Estabilidad de Firmware y Calor
Estás usando una falacia lógica. Sí, técnicamente el calor como es lógico degrada los componentes electrónicos de cualquier dispositivo, igual que podemos decir que cualquier movimiento mecánico va a causar igualmente un desgaste físico, por pequeño que sea. Y esto técnicamente es cierto. Ahora bien, en la práctica, y por lo general el tiempo de vida que usamos los equipos, va a ser que no. Esos Router que nombras de "alto rendimiento" propios que podemos encontrar en el mercado, sufren exactamente del mismo comportamiento. No tienen problema alguna en llegar a los 70ºC por tiempos prolongados, hasta el punto que algunas unidades pueden hasta quemar al tocarlas. Tengo por aquí un Ubiquiti que podría dar buena cuenta de ello. Esto no se puede evitar, a menos que quieras pagar el precio de una refrigeración activa, lo que implica ruido y punto de fallo. Coge cualquier Router del mercado con prestaciones similares, y mira la temperatura que alcanza.
Sí, el calor no perdona, es obvio, el thermal throttling está presente a día de hoy en prácticamente cualquier silicio, y ya nos enseñó el amigo Arrhenius lo que a la larga pasa. Pero como dije en su momento... ¿como lo hacemos? Porque no hay opción mágica. ¿Prefieres en tu caso particular meter refrigeración activa y que en 2-3 años el ventilador muerta y tengas que cambiarlo, además del ruído?? Oye, lo respeto, para gustos colores. ¿Prefieres en vez de eso optar por beneficiarte de la mayor tecnología de integración lo que ayuda a disipar mejor el calor pero sin aumentar los transistores? Perfecto también, sin ningún problema, tienes un hardware con componentes nuevos con un rendimiento de hace 3-4 años, pero que se calienta y consume mucho menos. Puede hacerse.. pero no es rentable para prácticamente ningún fabricante, a menos que sean dispositivos de nicho donde el consumo es esencial. No puedes meter un Switch con dos puertos 10GEthernet, una ONT Combo-PON, WIFI6/7... y pretender que con ventilación pasiva no se caliente.
Por cierto... culpar al calor generado por un Router de alto rendimiento por su efecto en el jitter... me parece una excusa un poco pobre teniendo en cuenta la de infinidad de factores y mucho más importantes y predominantes que afectan al Jitter. Sí, es totalmente posible que ante una carga descomunal, un flujo constante y severo durante un largos período, pueda hacer saltar el thermal throttling, y esto a su vez degradar de forma temporal el rendimiento del Router, lo que podría dar lugar también a aumentar la latencia o provocar un salto en el jitter, más aun si se está usando WIFI. Esto técnicamente es cierto... el problema es que en dicho escenario el Jitter por calor debería de ser lo último en preocuparnos, ya que el bufferbloat tendría un impacto mucho mayor por la carga en curso, ya sea directmaente por el bufferbloat, o indirectamente por las interrupciones que requiere realizar el Router. Y aun así en este caso, tenemos aceleración hardware con diferentes hilos de la NPU interna para lidiar con ello. ¿Esto hace que sea imposible sufrir este tipo de problemas? No, no es imposible sufrirlos, pueden llegar a pasar eventualmente... lo que pasa es que precisamente dado que requieren condiciones muy muy concretas para que se dispare un thermal throttling, cuando se dispara el efecto real que tendrá en el usuario será en esencia invisible. Yo al menos no conozco a nadie que esté descargando a una tasa de 10Gbit sostenida durante largo tiempo y al mismo tiempo jugando o haciendo uso de streaming por WIFI (donde se apreciaría aun más). Y repito, sí, puede llegar a pasar... con este Router y cualquiera de los que has mencionado... a menos que optes como digo por equipos profesionales, con disipación activa, flujos de aire dirigidos y otros.
7. Desdén técnico sobre el Filtrado MAC:
Me da la sensación de que no has leído lo que puse. Copio y pego de nuevo, puesto que o no lo leíste, o simplemente fueron las prisas:
"Movistar prefirió, y en este caso lo aplaudo, a usarlo de un modo alternativo, a modo de un control parental simple. Ahí sí tiene cierto sentido su uso. Y para ello es necesario una interfaz más visual, que sea sencillo seleccionar un dispositivo para bloquearlo temporalmente, permitirlo etc etc. Y no soy fan de la App, ni tampoco creo que sea un buen modo de control parental teniendo otras opciones mucho mejores, pero entiendo que pueda tener cierta utilidad"
Dicho de otro modo, ya expliqué que el filtrado MAC no tiene absolutamente ningún valor como seguridad, y es por ello por lo que Movistar prefirió usarlo a modo de "control parental". Según tus argumentos:
"Evitar la asociación automática de dispositivos conocidos pero no deseados en bandas específicas:"
Por un lado, al principio del todo alegabas la necesidad imperiosa (y la comparto) de poder separar las bandas... yo al menos lo prefiero, me da mayor control. No obstante, ahora parece que te contradices al decir que puedes evitar la asociación automática... ese problema no debería de existir por dos razones:
A) SI tienes bandas separadas, no se va a conectar a la otra, sin más.
B) Cualquier dispositivo decente, permite configurar la preferencia de banda
"Servir como inventario de activos autorizado (White List), algo esencial cuando se gestionan más de 30-40 nodos IoT."
Esto me parece aun más... "peligroso" si cabe. Es que directamente no vas a tener una red WIFI eficiente con 30-40 nodos IoT. Eso en esencia es un oxímoron. WIFI no se creó para eso, simplemente. Para eso tenemos tecnologías específicas para ello, como Zigbee por ejemplo, que ni siquiera es un protocolo IP, y aunque opera en la banda de 2.4GHz no se pisa ni interfiere el 99% de las veces, donde puedes convivir sin problema alguno 40, 50 y 100 dispositivos interconectados con un impacto de cero sobre tu red.
Por otro lado, aun con todo, si quieres realizar un "inventariado" autorizado, me parece mucho más práctico y menos problemático una hoja de Excel donde apuntarlos. Eso sin contar el sobre-esfuerzo que requiere el SoC de un Router en estar recorriendo constantemente la lista interna... pero eso es otra cuestión totalmente diferente, en equipos modernos debería de ser menos perceptible, pero si lo que realmente te importa es el rendimiento de la red... no es el camino.
"Eliminar... bajo el pretexto de "seguridad falsa" es, en realidad, una claudicación del fabricante por no querer gestionar tablas de direcciones en memoria. Sustituirlo por una App móvil es trasladar el control del hardware local a la nube de Movistar, algo que vulnera la autonomía técnica del cliente. Otra cagada mas."
Me temo que no es así, y denotas de nuevo en este punto una falta total y absoluta de como funciona el HGU. Siento decirte que, para tu información, la información de dispositivos bloqueados/pausados, o como tu las llamas esas "tablas de direcciones en memoria", se guarda de forma íntegra en el Router, exactamente igual que en cualquier otro Router que puedas encontrar en el mercado. Movistar no guarda ni gestiona nada en su nube, esos datos no los guarda Movistar, si reseteas el Router, los ajustes relativos a ello se pierden. La App no es más que una interfaz visual simple para el usuario medio, que a su vez interacciona de forma indirecta con el Router, para bloquear, pausar, permitir... un dispositivo. Es el Router quien, a través de las listas blancas/negras de toda la vida se gestiona todo. Es más, por SSH se pueden ver, listar, añadir, eliminar... Así que siento decirte que no, no es otra cagada más, ni vulnera ningún tipo de autonomía técnica ni otras historias.
--------
Como final:
Los equipos de Movistar, como los de cualquier otro ISP van, como es lógico, orientado a la inmensa mayoría de usuarios, los que representan más del 95%. Precisamente para los que por el motivo que sea quieren usar su propio Router, pueden usarlo sin ningún tipo de problema, limitación, cuellos... Esa obligación Movistar la cumple y de sobras. Repito, desde que apareció el HGU5 hasta el HGU7 uso mis propios Router, jamás he tenido un solo problema, ni a 100M, ni a 10G. Pero es que aun así, ojo, aun con todo, Movistar tampoco te obliga a usar su HGU, al igual que eres libre de usar tu propio Router, eres igualmente libre de usar tu propia ONT. Del mismo modo que asumes los inconvenientes de usar tu propio Router, asumes los mismos inconvenientes de usar tu propia ONT.
Con todo ello, entenderás el motivo por el cual tus dos exigencias chocan de bruces con tu propio argumentariado. Dices que lo que quieres es, o poder usar un bridge real en el HGU para poder usar tu propio Router, o que te den una ONT para que puedas conectar tu propio Router. ¿No es eso un poco ilógico?
Movistar te permite sin problema alguno usar tus propios dispositivos, ya sea Router o ya sea ONT. Obviamente el usuario es el que tendrá que lidiar en cada caso con sus propios dispositivos. Es más, Movistar a diferencia de otros ISP no esconde parámetros exóticos ni raros, todas las configuraciones necesarias son globalmente conocidas, de modo que cualquiera con el hardware adecuado y conocimientos adecuados puede usar su propio Router, su propia ONT o ambos.
Aun así, Movistar facilita el uso del Router propio con el modo Monopuesto, mucho más coherente y sencillo de lidiar que con un bridge completo, y pese a lo dicho, no, no tiene limitaciones ni supone ningún cuello de botella... si quieres te puedo poner capturas y métricas usando mis propios equipos conectado el HGU7 en monopuesto. Cero problemas.
Si tenemos en cuenta que soy el primer crítico con Movistar en muchos aspectos, y que por descontado aun tienen que mejorar la firmware del HGU7 y aun así es como pienso y veo las cosas... francamente dudo enormemente que siquiera se puedan plantear ninguna de las dos opciones que te gustaría.
La primera, porque es el sistema que escogió hace mucho Movistar y es el que mejor resultado ha dado, porque implementar un bridge real limitaría enormemente a los usuarios, y porque para ese escenario lo más práctico es que el propio usuario usase su propia ONT.
Con respecto a la segunda, carece aun más de sentido, Movistar te entrega dispositivos adecuados para su uso en condiciones nominales que cubren a más del 95% de los usuarios, para ese 5% restante, Movistar no obliga a usarlos, si no te gusta el modo monopuesto del HGU por el motivo que sea, usa tu propia ONT y te apañas con ella, puede hacerse, Movistar no lo prohíbe, del mismo modo que usas (o quieres usar) tu propio Router.
----------
Como nota final:
Obviamente el HGU7 no es perfecto, nunca lo va a ser, ni este ni ningún otro Router que puedas encontrar en el mercado. El HGU es un equipo de un ISP, que tiene que bregar y ser bueno para todo en las condiciones del 95% de los usuarios. Yo soy el primero que uso mi propio Router!! No es por problemas de rendimiento, no es por problemas "mayores" de cuellos/jitter/ping/cortes.... ni nada de eso. Es por una cuestión de ecosistema propio (no me refiero a un ecosistema de un fabricante) de gestión y control, así como de funcionalidades que para mi son esenciales. Aun así, en mi configuración actual (que aquí si entiendo es un poco más... "especial" y no aplicable a nadie más), sigo usando el HGU7 en modo nominal aun estando en monopuesto, lo cual me permite aun más versatilidad para algunas cuestiones concretas. Podría usar una ONT propia?? Sin duda, tengo alguna por ahí y funciona sin problemas, simplemente es innecesario no podría asegurar nunca una robustez como la que necesito, y además el modo "dual" que tengo ahora me ofrece beneficios que para tenerlos tendría que añadir más hardware de red.
-Perfecto? No, ni mucho menos. Decente? Sin duda. tiene aun bugs que solucionar? Por supuesto, y más que saldrán.
-Movistar implementando un bridge real?? Lo dudo enorme enormemente. Suministrarte una ONT ellos mismos en vez del HGU? Lo dudo aun más.
-¿No estás conforme? ¿Tantos problemas te da? Usa el modo Monopuesto e instala el Router que te de la gana, no tiene limitación alguna ni problema conocido de nada. ¿Tampoco? usa tu propia ONT y Router, y así ya cualquier problema que puedas tener del tipo que sea no lo podrás achacar en modo alguno al hardware de Movistar (Realmente de Askey/Mitrastar). Yo desde luego es lo que haría, no te quepa la menor duda! Es lo que he hecho en el pasado y seguiré haciendo: si tengo una necesidad real que cubrir, nunca cojo atajos. lo estudio y lo soluciono de forma sencilla, práctica y sostenible.
Saludos.
