Totalmente comprobado, el problema aparece cuando el ancho de banda no supera 300Mb (tengo la Gráfica de ancho de banda que me ofrece Fortigate), lo que si ocurre es que hay muchos usuarios detrás, pero nada mas.
De hecho con pocos usuarios y haciendo pruebas de velocidad concurrentes (lo que pone la linea al máximo) no hay problema. tengo la impresión de que el problema ocurre por otro sitio.
Si la prueba anterior era el log del HGU, y no había tráfico intenso ni nada raro, puede ser un problema de la centralita, el Router no tiene por qué desconectarse de la sesión PPPoE
No obstante, si eso sucede con tráfico intenso, si es probable que sea por el bufferbloat. La sesión PPPoE requiere de un intercambio constante de paquetes de eco (Keep Alive) para mantener la conexión. Es decir, cada 15 segundos el servidor PPP envía al Router un mensaje de: ¿Sigues vivo? Si al 5º Request que se realiza no llega contestación, se cierra la conexión. Esto mismo lo hace también el cliente PPPoE, el Router, cuando la conexión está en espera. El Router envía un Sigues vivo 5 veces, si no tiene respuesta, corta la conexión.
Esto puede pasar por infinidad de circunstancias. Como he dicho, podría ser un problema de la centralita simplemente, que ahora le da por, directamente, no responder los PPPoE Request porque por lo general quien mantiene la conexión abierta es él.
No obstante, por lo que cuentas, no sucede siempre, solo sucede cuando saturas la línea. Y esto si puede pasar también por el bufferbloat. El bufferbloat retrasa todo el tráfico que sale enormemente, hasta el punto que algunos paquetes se dropean, se descartan en el Router, y cuando hablo de Router siempre me refiero al dispositivo que tiene levantada la sesión PPPoE. El problema que esto tb le pasa a los paquetes de control. El servidor PPP mantiene cada 15 seg mandando sus ¿Sigues Vivo?, pero en un momento dado las respuestas del Router de "Sí, sigo aquí" ya no le llega, porque se están descartando. El Servidor al 4-5 intento corta la conexión por entender que el Router está fuera de línea. Ahora es tu Router el que no recibe noticias del servidor con lo que intenta un PPP request para ver que pasa... pero a la 5º vez que lo intenta y no ha recibido un "sigo Vivo", el Router corta tb la conexión y cierra la sesión PPPoE
----------
Lo raro no es que esto pase, esto puede ser totalmente "normal", lo raro es que suceda cuando el tráfico no es muy intenso. Y con intenso me refiero a que, por lo general la subida, no vaya a un % muy alto de su capacidad, o el Switch interno del propio Router, pero que el Switch interno vaya más saturado es raro, a menos que en al red exista una tormenta de tráfico que ocasiona todo.
Que te miren la centralita por si acaso, pero me da que parece más un asunto local. Desde el punto de vista de la infraestructura de fibra le da igual que establezcas más o menos sesiones. El tráfico si importa, hasta que sale de tu Router, una vez que se pone hacia arriba importa poco, el bufferbloat se sufre a las puertas, no más arriba.
Configura de todos modos QoS si puedes, prioriza como es natural primero todo tipo de tráfico de control, ya sea ICMP, PPP, TCP (SYN, RST, ACK) por poner algunos ejemplos, así como penalizar al tráfico de fondo que suele ser el más pesado, y también menos prioritario, como descargas directas, P2P etc etc.
Hemos seguido haciendo pruebas, poniendo el router en modo multipuesto, para que nuestra infraestructura no influya, y un equipo conectado directamente a el. este es el resultado del WinMTR
Por otro lado, también tengo un Log del propio router donde se ve claramente que la perdida de paquetes se debe a que se desconecta de la red de Movistar tras la perdida de 5 paquetes (he cambiado las direcciones por "X y h") y este log se va repitiendo es decir se conecta y desconecta.
Espero que esto pueda servir de ayuda porque realmente esta situación es desesperante.
8 Jan 19 13:38:49 INFO No response to 5 echo-requests
49 Jan 19 13:38:49 NOTICE Serial link appears to be disconnected.
50 Jan 19 13:38:49 INFO LCP Down,reason:6 (lower down)
51 Jan 19 13:38:49 INFO link_down
52 Jan 19 13:38:49 INFO Down,reason:5 (lower down)
53 Jan 19 13:38:49 INFO update_link_stats remove pppuptime file
54 Jan 19 13:38:49 INFO Connect time 21.8 minutes.
55 Jan 19 13:38:49 INFO Sent 32925288 bytes, received 104942017 bytes.
56 Jan 19 13:38:49 INFO PPP down
57 Jan 19 13:38:49 WARNING Couldn't increase MTU to 1500.
58 Jan 19 13:38:49 ERROR Couldn't increase MRU to 1500
59 Jan 19 13:38:49 INFO LCP down.
60 Jan 19 13:38:51 INFO Internet down
61 Jan 19 13:38:55 NOTICE Connection terminated.
62 Jan 19 13:38:55 WARNING Doing disconnect
63 Jan 19 13:38:55 NOTICE Modem hangup
64 Jan 19 13:38:55 INFO LCP down.
65 Jan 19 13:39:00 INFO main create pppuptime file
66 Jan 19 13:39:00 INFO LCP Starting
67 Jan 19 13:39:00 INFO LCP is allowed to come up.
68 Jan 19 13:39:00 INFO LCP Opening
69 Jan 19 13:39:00 INFO Sending PADI
70 Jan 19 13:39:00 INFO HOST_UNIQ successful match
71 Jan 19 13:39:00 INFO HOST_UNIQ successful match
72 Jan 19 13:39:00 INFO Got connection: 1
73 Jan 19 13:39:00 INFO Connecting PPPoE socket: XX:XX:XX:XX:XX:XX 0001 nas0 0xhhhhhh
74 Jan 19 13:39:00 DEBUG using channel 2
75 Jan 19 13:39:00 INFO Using interface ppp0
76 Jan 19 13:39:00 NOTICE Connect: ppp0 <--> nas0
77 Jan 19 13:39:03 INFO LCP up
78 Jan 19 13:39:03 INFO CHAP authentication succeeded: CHAP authentication success
79 Jan 19 13:39:03 INFO CHAP authentication success
80 Jan 19 13:39:03 NOTICE CHAP authentication succeeded
81 Jan 19 13:39:03 INFO IPCP Opening
82 Jan 19 13:39:03 NOTICE local IP address XX.XX.XX.XX
83 Jan 19 13:39:03 NOTICE remote IP address 192.168.144.1
84 Jan 19 13:39:03 NOTICE primary DNS address 80.58.61.250
85 Jan 19 13:39:03 NOTICE secondary DNS address 80.58.61.254
86 Jan 19 13:39:04 INFO ppp up
87 Jan 19 13:39:04 NOTICE ipcp_up create pppuptime file
Con unos 200-300Mbps no debería de existir bufferbloat, aunque es algo que se puede comprobar, tan sencillo como poner a descargar y subir cualquier cosa a unos 400Mbps fijos, cualquier cliente FTP puede hacerlo, y mientras está en curso realizar un winmtr por ejemplo a ver si se produce, incluso ir jugando con el límite a ver que pasa. Pero como digo por lo general lo que es el bufferbloat aparece cuando se va llegando al límite, sobre todo en subida.
El número de conexiones es importante, pero quiero pensar que el Fortinet que tenéis instalado tiene capacidad para ello. En esto, al tener el HGU en monopuesto, este es totalmente transparente para ello, da igual que sean 5 sesiones o 10.000, no hace ningún consumo de recursos en ello, simplemente coge todo lo que le llega a la interfaz WAN, lo etiqueta y devuelta para la fibra. A día de hoy la mayor carga con mucha diferencia que tiene un Router es el hacer NAT, amén con otros servicios que obviamente se pueden tener hospedados (QoS, VPN, DPI...). Es al hacer NAT donde si juega un papel muy importante el número de sesiones y la RAM del Router, en este caso el fortinet. En esencia cualquier paquete que se envíe desde tu red el Fortinet tiene que modificar uno a uno los paquetes para cambiar al vuelo la IP de origen del equipo, y colocar la IP pública de la sesión PPPoE de este. Y para cada paquete que llega a él lo contrario, modificar la IP de destino que es la IP pública, y cambiarla por la IP privada del dispositivo al que va destinado dicho paquete. Y todo ello manteniendo una tabla interna de seguimiento de conexiones. Es en todo este proceso donde los Router sufren de lo lindo.
Todo eso cuando llega al HGU no tiene mayor problema, no tienen que procesar ni modificar nada de los paquetes, simplemente los etiqueta a todos del mismo modo y valor y reenvía.
Por eso te digo que me extrañaría muy mucho que el Fortinet anduviese de hardware regular y no fuera capaz de mantener lo otro bien. Esto tb se puede comprobar de forma sencilla, si el Fortinet puede verse los recursos usados en cada momento, basta con ver el estado de la CPU y RAM cuando empieza a fallar.
----
Otro problema potencial, es que sencillamente tengas un problema de configuración en el propio Fortinet que te causa el problema. Esto tb es muy simple de comprobar, basta con retirar el fortinet temporalmente, usar el HGU en su modo nominal y ver si funciona mejor o peor o igual. Y en este caos es cierto que dependiendo del HGU que tengas la RAM puede no ser suficiente según en que escenarios.
Muchas gracias por tu respuesta, voy a revisar el tema del QOS, pero tras el router como te comentaba tengo un firewall Fortinet, y me indica que empieza la pérdida de paquetes cuando el ancho de banda utilizado es entre 150-300Mb (tenemos contratado 1Gb simétrico), lo que si existe es multitud de sesiones, ya que detrás del Fortinet hay muchos equipos conectados, con lo que me da la impresión que el problema puede venir de otro sitio.
Las imágenes se pueden ver, pero por protección Movistar requiere que se verifiquen a mano, con lo que si un usuario pone una imagen, esta puede tardar tiempo en que podamos verla.
En lo que respecta a tu problema, parece indicar que el cuello está donde te decía, en la salida del Router hacia afuera. Un más que probable efecto del BufferBloat, configura tu Router con QoS de forma correcta para evitar ese cuello de botella. Esto aparece sobre todo cuando le aprietas en la subida, aunque puede aparecer en menos casos en altas descargas sostenidas. No es un problema de la línea, es comportamiento esperable, tu Router simplemente está descartando el tráfico ascendente de sobra, de ahí que la pérdida se vea en el segundo salto.
Así que tienes dos opciones:
1º. Configuras QoS correctamente para priorizar el tráfico de la red, aunque esto puede ser complejo si no se tienen conocimientos avanzados al respecto
2º. Limitas sobre todo la subida a un % en el que se pueda asegurar que no va a colapsar por el bufferbloat, puedes empezar limitándolo a un 20%, y bajarlo si ves que aguanta.