Buenas celesfigaredo
Estás mezclando dos cosas completamente diferentes, por un lado el HGU7, por otro lado la tecnología usada. El HGU7 es un Router combo-pon, permite tanto conexiones con GPON como las nuevas conexiones XGSPON. Adquirir un HGU7 no implica ni mucho menos pasar a XGSPON, lo cual si sucede como es lógico si uno va a la conexión de 10Gbit, dado que esta sí requiere operar bajo en XGSPON. Si por cualquiera motivo tu centralita está actualizada y te han cambiado el perfil a XGSPON, no obstante, aunque el HGU7 sí permite usar GPON, no podrás usar otro HGU como es natural, dado que actualmente el único capaz de XGSPON es el HGU7.
En cualquier caso, dudo enormemente que sea un problema en la firmware. Muchos tenemos el mismo Router ya, y no hemos experimentado dicho problema. En tu caso particular incluso te han cambiado la unidad por otra, con lo que probablemente es algún tipo de problema muy específico con tu propia red. Para que te hagas una idea, por curiosidad mal sana, llevo corriendo WinMTR durante un buen rato, va por más de 1000 paquetes y ni un solo paquete perdido, siendo la latencia total totalmente estable, mínima de 0 (realmente no es cero obviamente, es menor de 1ms) y la media igual.
Por otro lado, por curiosidad también, he sacado las estadísticas internas de todas las interfaces del HGU7 después de días de funcionamiento para ver el % de drops/errores que había... y el resultado es de 0 para todas ellas... exceptuando para las interfaces WIFI, lo cual es esperable como es natural por interferencias y otros, y en multicast, lo cual tb es totalmente normal. Todas la demás interfaces (y no son pocas...) dan 0. Te pondría la radiografía pero son unas 160 interfaces, con lo que es bastante tedioso, pero si te interesa con gusto te lo mando por privado.
Mi consejo es que investigues que está pasando en tu red. Si te sucede enviando un ping sostenido desde el equipo A al Router, es el equipo A el que está perdiendo paquetes por algún motivo. Usa un analizador de paquetes y haz un seguimiento para ver que está pasando, si simplemente no llega respuesta, si el Router responde con algún error particular al tráfico. Todo ello siempre con conexión directa al Router, si tienes entre medio otros dispositivos de red propios, tales como AP/Switchs/Router... la cosa se complica bastante más ya que entran en juego muchos otros dispositivos que pueden estar saturando la red de un modo u otro.
----------------
Sí existe en el HGU7 actualmente un problema, al menos yo lo considero un problema, que podría en ciertos escenarios explicar esa "pérdida", aunque no sería una pérdida real de paquetes, sino de las respuestas ICMP.
Cuando haces uso de herramientas tipo winmtr/pingplotter, estas hacen uso en esencia de las bondades del protocolo ICMP, hasta aquí no hay problema. La cuestión es que que un Router o un nodo de red en teoría muestre un % (el que sea) de pérdida de paquetes, no significa automáticamente que sea real, dado que el dispositivo en cuestión podría estar discriminando por cualquier momento las respuestas ICMP. Es más, el Router está configurado para protegerse de peticiones masivas de esto, filtrando las peticiones si superan cierto umbral. Esto lo hacen casi todos los equipos actuales, existe una regla IPtables en ellos, que en esencia evita abusos:
99 2892 RETURN icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8 limit: avg 100/sec burst 5 2 56 DROP icmp -- * * 0.0.0.0/0 0.0.0.0/0 icmptype 8
Fíjate en dicha regla. En esencia dice que el Router va a permitir únicamente uno 100 ping por segundo con un burst de 5, si se cumple se aplica un return, si no se cumple la siguiente regla es un DROP. Desde el punto de vista de la app que hace ping, es un paquete perdido (o varios).
Pero no me refiero a este problema en particular, estas reglas son habituales en casi cualquier Router. El problema en particular es que ahora mismo el HGU7 está bombardeando constantemente toda la red buscando 24/7 dispositivos en la red por medio de ping/ARP. Esto puede provocar un incremento innecesario de ICMP en la red haciendo que sea más... "sencillo" disparar drops en las reglas para ICMP. La buena noticia es que esto no tiene ningún impacto en el tráfico normal, solo en ICMP.
--------
Por otro lado, y con total independencia de ello, un tunel VPN no se cierra o se pierde por perder un paquete de cuando en cuando. Aun cuando la conexión perdiese un 1% de paquetes, ese porcentaje es mínimo para el establecimiento correcto de la VPN. Es más, están preparadas para ello por si ocurre cualquier contingencia. La prueba más simple de esto es WIFI, las conexiones WIFI son muy susceptibles de tener problemas de pérdida de paquetes en la red local por interferencias y saturaciones, a menos que sea algo muy extremo no te va a cortar una VPN. No es casualidad que estas suelan usar UDP, que no requieren siquiera un estado de conexión. El equipo por lo general simplemente reenviará otro paquete igual.
Esto es un efecto habitual que vemos por ejemplo en los WinMTR cuando vemos que en red local existe un % el que ea de pérdida de paquetes, que por raro que parezca no aparece en el siguiente salto. Esto es porque el equipo lo reenvía al Router. Esto no pasa una vez el paquete cruza el Router, ojo, una vez que los paquetes cruzan el Router, si existe pérdida de paqeutes reales, esta será acumulativa y se irá propagando por los diferentes saltos, como la latencia.
----
Mi consejo, revisa el equipo en cuestión, la red en genera. Cualquier ajuste o dispositivo puede estar haciendo de las suyas. Usa un analizador de paquetes para ver que está pasando. Y en cualquier caso esto no tiene que afectar en nada al establecimiento de la VPN, esta se mantiene levantada gracias a los keep-alive, tendría que dar la extremadamente casualidad que siempre se perdiera un paquete keep-alive, y después de varios de estos el servidor VPN cerrase la conexión.
Saludos
