Buenas javivanco
El problema es el mismo, aunque técnicamente es factible, es encadenar muchos "y si..." juntos, cuando muy probablemente cualquiera que tenga la necesidad lo solventaría de modos mucho más sencillos. Por supuesto puedes crear un Router virtual con proxmox, pero lo mismo puedes hacer (de forma más sencilla y barata) con una rasp para convertirla en un Router. Pero en cualquiera de los escenarios, hablamos exactamente de lo mismo: Un dispositivo "que hace de ONT" que en este caso es el HGU, y otro dispositivo que hace de Router. Ese dispositivo que hace de Router puede ser un Router, un dispositivo virtual, un DIY...
Dicho de otro modo... aun cuando tuviese un proxmox ya preparado para otras labores y que se diese dicho escenario como probable, no lo usaría como Router tampoco, usaría un dispositivo dedicado para ello, con independencia de poder usar o no el HGU. Por supuesto es mi opinión personal, como te digo te agradezco que compartas experimentos, pensamientos y todo lo que sea darle una vuelta de tuerca al asunto.
--------------------------
Con retroalimentación me refiero a que tienes que volver a conectar el HGU con el otro dispositivo. Es decir, requieres al menos de dos conexiones desde el HGU, una para WAN, y otra para el AP, que incluso a las malas se puede hacer lo mismo sin siquiera usar grouping, aprovechándose del comportamiento de "falso Switch". En lo tocante a Grouping, como te digo es una función muy específica de algunos de los HGU. De los que he usado o tenido acceso, tan solo el Askey RTF3505 que recuerde ahora mismo.
todos los HGU son linux, la opción de Grouping lo que hace en esencia es sacar del bridge principal las interfaces que se marquen, creando así dos bridge internos. Problema... la interfaz no permite crear enmascaramientos y otras reglas potenciales que permita configurar de una forma más interesante los diferentes bridge. En el caso que propones, esto no debería de ser un gran problema ya que como dices estarías conectando el otro bridge independiente por otro lado.
Todo ello, de nuevo, dejando a un lado todo lo relativo a VoIP/IPTV, que es esencial para el 99% de los clientes de Movistar, donde de echo la mayoría de problemas que tienen los usuarios que pasan aquí al usar su propio Router es precisamente por querer configurar bien estos servicios.
Como ya decía, puestos a toquetear, infinitamente más práctico es simplemente seguir usando el HGU aun estando en monopuesto, devolviéndole la conectividad de Internet, sin más. Sin necesidad de retroalimentación, sin grouping y sin nada.
------------------------------------------
En lo que respecta a WIFI, eso es lo que dice la teoría, la práctica no tiene absolutamente nada que ver con ello. (Nota: Los HGU5 y 6 son todos 4x4, exceptuando un modelo concreto de HGU6, el GPT2841, que sí es 5x5)
En teoría, gracias a OFDMA y MUMIMO podemos tener entornos donde varios dispositivos puedan transferir de forma simultánea aprovechando las antenas adicionales libres. Esto de nuevo, en teoría, debería de mejorar la latencia y estabilidad general de la red. No obstante, esto en la práctica no ocurre. Bueno, más correctamente es muy muy raro encontrar un escenario real donde tenga algún impacto. Y esto se debe a muchos motivos:
1º. Como bien dices, la mayoría de dispositivos actuales de consumo como móviles, tablet o PCs, suelen tener adaptadores 2x2. Aun en el mejor de los casos donde todos los dispositivos de la red fuesen compatibles y tuviesen internamente habilitado MUMIMO+OFDMA, la masificación que se hace a día de hoy por los usuarios de WIFI, hace que la ganancia de eficiencia (que es real), sería marginal. De echo lo vemos aquí cada día.
2º. Incluso a día de hoy, soporte reducido. Aunque pueda parecer mentira, y aunque sea mandatario para 802.11ax, si aleatoriamente escoges una casa al azar y comprobases los dispositivos que son compatibles con MUMIMO y OFDMA, la mayoría se llevaría una sorpresa desagradable... sobre todo con OFDMA. MUMIMO es algo más habitual verlo dado que realmente su adopción fue en 802.11ac. En cualquier caso, a lo que voy, aun cuando el Router implementase de forma adecuada OFDMA+MUMIMO (cosa por cierto raro de ver, y los HGU no son excepción de ello, algunos lo tienen deshabilitado internamente), el soporte en los dispositivos es aun marginal. Y con marginal me refiero al grueso de la red. Eso no hace ni mucho menos que sean tecnologías inservibles, todo lo contrario, en escenarios donde el usuario se ha tomado la molestia de maximizar la red, cableando de forma correcta, teniendo cuidado en los dispositivos que instala y como los configura... por supuesto que OFDMA+MUMIMO tienen un impacto muy positivo. Pero a día de hoy esto es un escenario de nicho, no realista por desgracia. Lo cierto es que aun , a día de hoy, la inmensa mayoría de dispositivos IoT/domóticos llevan adaptadores 802.11n, y los que son 802.11ax, incluyendo teléfonos y tablets, muchos de ellos no soportan OFDMA o lo tienen deshabilitado internamente.
3º. Beamforming... otra de las maravillas que se implementaron en 802.11ac y que a día de hoy sigue siendo recomendable en la mayoría de los casos deshabilitarlo. Sí, la lógica y física detrás de ello es innegable, y sí, de nuevo como el punto 2º, en escenarios muy concretos puede tener un impacto beneficioso. No obstante, cuando se ha llevado al terreno doméstico, no laboratorio, las cosas han sido muy muy diferentes. Aquí el problema es múltiple, algunos de ellos se han ido solucionando con el tiempo otros no:
a) Soporte. De nuevo, a pesar de que Beamforming está presente desde 802.11ac, el soporte es marginal, sobre todo en dispositivos portátiles. Y aun en los dipsositivos que lo soportan, es raro ver una implementación realmente adecuada. Esto hace que no sea raro ver que si el SoC es del mismo fabricante funcione mejor
b) Aun se pelean con las implementaciones del Beamforming implícito y explícito. La mayoría de dispositivos no permiten siquiera modificar nada, el dispositivo trae el adaptador que sea y punto, como mucho en un PC de sobremesa podemos configurar el Driver y alguna cosilla más, quizás incluso el Router... pero en cualquier caso es muy habitual problemas con ellos.
c) Dispositivos portátiles. Por su propia naturaleza, Beamforming tiene problemas importantes en dispositivos móviles, especialmente móviles, tablets. Esto es por sentido común, conformar de forma correcta el haz implica conocer la ubicación del dispositivo, lo que implica que no se mueva... si se mueve, no solo no se gana en eficiencia, sino que es habitual que aparezcan cortes y otros problemas.
d) Mobiliario. Beamforming depende enormemente de la geometría y mobiliario de la casa. En una casa puede funcionar bien, en otra con los mismos dispositivos puede ser un infierno.
Todo ello, y otras razones, hacen que por desgracia Beamforming sea una de las primeras características a deshabilitar cuando se tienen problemas. Y repito que llevamos con ello desde WIFI5, estamos ya en WIFI7.
----------------------------------
A lo que voy, aunque técnicamente es cierto que a mayor número de streams y por supuesto estándar WIFI se debería de traducir con una mayor eficiencia general, a efectos prácticos esto generalmente no se ve. Solo tienes que pasarte por foros de cualquier ISP o foros generalistas donde se debate WIFI, y siempre son los mismos problemas WIFI, sea el Router que sea y la generación que sea. Y esto es debido a que, aunque los estándares WIFI obviamente mejoran sustancialmente, para poder aprovechar realmente dichas mejoras se requieren escenarios que a día de hoy se consideran ideales y poco realistas. Muchas veces por culpa del propio usuario, cuando masifica su propia red WIFI con decenas de dispositivos, usa domótica/IoT por WIFI pudiendo hacer uso de tecnologías como Zigbee... incluso algo tan sencillo que es primordial, que es la correcta ubicación del Router en la casa, te darías cuenta si haces una encuesta que más del 90% lo tienen en un mal sitio :): En el salón, al lado de la TV (si es que no está detrás de ella), y que además por lo general suele estar en un lado de la casa.
c'est la vie
Saludos.
