Buenas JorgeBoix
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.
Saludos.
Hola Theliel,
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.
Un saludo
Buenas JorgeBoix
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 tus comentarios Theliel .
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.
Buenas JorgeBoix
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.
