paquet loss desde el viernes

[velocidad]

Desde este viernes (puede que antes, es cuando lo he notado) estoy sufriendo paquet loss a un servidor, no sé si podrán hacer algo. Este es un ping de 1000 paquetes al salto anterior al servidor (no lo hago al servidor, porque ya he comprobado desde el propio servidor que el problema no está ahi):

Estadísticas de ping para 85.25.36.40:
    Paquetes: enviados = 1000, recibidos = 966, perdidos = 34
    (3% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
    Mínimo = 34ms, Máximo = 48ms, Media = 38ms 

[Theliel]

Cuando tenga tiempo voy a escribir un artículo sobre ello, y pedir a Movistar que lo pongan en algún lado visible...

Vamos a ver... ni un ping ni un tracert miden paquetes perdidos, o al menos no como la mayoría quiere interpretar. Para medir realmente paquetes perdidos es necesario hacer un test específico para ello.

Un Ping lo que hace es enviar un paquete ICMP tipo Echo Request, con la esperanza de que el destino al que va dirigido conteste con un ICMP tipo Echo Reply, porque eso es precisamente para lo que se creó y usa este tipo de paquetes especiales.

Pérdida de paquetes es un término muy generalista que la mayoría no entiende. Un equipo no puede medir la cantidad de paquetes perdidos que envía por sí solo, es imposible, porque si esos paquetes realmente se pierden, la única forma de saberlo sería preguntando al destino cuantos le llegaron de todos los que envió, lo cual requeriría... efectivamente, un test especifico para ello. Tampoco puede contar los paquetes perdidos de entrada por sí mismo, como saber cuantos se le enviaron realmente??

Algunos responden: Perfecto, para eso tenemos Ping, lanzo un Echo Request a la espera de un Echo Reply. Si envío 3 Request espero 3 Reply, si uno no llega cuento 1 paquete perdido. Efectivamente, esto es exactamente lo que sucede. Ahora bien, para empezar no podemos saber si esa pérdida es al enviar el paquete (Request) o al responder el servidor (Reply), que ya de por sí podría ser po tanto un problema de una red o de otra. Pero más importante a todo eso, y lo que hace que todo lo anterior carezca un poco de interés, es que un servidor/nodo/dispositivo de red NO TIENE OBLIGACION de responder no sólo a un ICMP Echo Request, sino directamente a ningún tipo de tráfico ICMP.

Es más, precisamente por los abusos que se realizan con estas herramientas, como tú enviando un ping sostenido de 1000 paquetes, los operadores de las redes y encargados en mantenimiento de equipos en general, cada vez más, aplican en dichos dispositivos reglas muy específicas para tratar este tipo de tráfico, que va, no exclusivamente, desde:

-Bloqueo total sólo de algunos tipos de paquetes ICMP, por ejemplo se configuran sólo para no responder los ICMP Request

-Deshabilitación integral de cualquier respuesta ICMP por parte del dispositivo

-Priorización de todo el tráfico ICMP que le llega a lo mínimo, produciendo por tanto que muchas de las peticiones de respuesta que deberiá de enviar no se envían siquiera.

-Limitaciones basadas en origen IP, en redes completas, ya sean limitaciones más grandes o más pequeñas...

-Etc Etc Etc Etc...

Como será, que Google que jamás ha limitado sus infraestructuras, lleva una semana o dos empezando a aplicar este tipo de políticas... por qué?? Precisamente por eso, por el abuso de muchos, que generan un grán tráfico hacia sus redes, y no sólo de ida, sino que como responden, también de vuelta.

Ni que decir tiene que el tráfico ICMP no es identificativo de nada. La herramienta ping y otras efectivamente cuentan los Reply que no llegan en función de los request que lanzó, pero esos reply que no llegan puede ser por miles de causas. Sí, podría ser porque hay un problema real en un punto de toda la red, pero esto es la minoría de los casos.

Por último, y por si todo eso fuese poco, ninguna conexón es perfecta, y la pérdida de paquetes (la real, no la que dice el tráfico ICMP), sucede constantemente. Es cierto que el % de paquetes perdidos (repito, perdidos realmente) con el paso de los años va descendiendo enormemente por la cada vez mejora en todas las redes, pero a día de hoy en casi cualquier transmisión importante de datos hay pérdida. En tu prueba, incluso si fuese un 3%  REAL, aun siendo un valor alto para pérdida de paquetes, estaría dentro de lo asumible. Y digo alto, porque a día de hoy lo normal es encontrar % muy por debajo de ese valor de forma habitual.

Eso nos lleva de vuelta a lo primero... no tienes un 3% de paquetes perdidos, tienes un 3% de paquetes Echo Reply que tu equipo no recibió por parte del nodo que fuese. Dado que es un % muy pequeño para limitaciones habituales de los nodos para el tráfico ICMP (los valores de pérdida suelen ser mayores), casi con toda seguridad ese nodo aplica una política no de limitación, sino de priorización minima, es decir... manda todo el tráfico de este tipo a la cola, atrás del todo, a ese tipo de tráfico que no se puede garantizar que sea entregado... vamos, que ni se preocupa de si se manda o no

Y esto se repite una y otra y otra...

Si quieres ver realmente si existe pérdida de paquetes en una conexión, tienes q hacer test específicos para ello, por ejemplo este:

https://www.measurementlab.net/tools/ndt/

Además, en cualquier caso, de existir el % que sea de paquetes perdidos, fuese real o no, mientras que fuese en un nodo fuera del ISP sería igualmente una pérdida de tiempo, porque el problema lo tendría que solucionar los administradores de dicho nodo.

[velocidad]

Todo esto está muy bien, sobre todo para el que no lo conozca.

Pero cuando reporto un problema es porque lo hay, y aunque bien es verdad todo lo que comentas, ya me he encargado de comprobar que el problema no sólo es de pérdida de paquetes iCMP, lo he notado por otro sitio y lo he corroborado con:

ping desde mi maquina al servidor = pérdida de paquetes

ping desde mi maquina a rediris.es = 0 pérdida

ping desde el servidor a mi maquina = pérdida de paquetes

ping desde el servidor a rediris.es =0 pérdida

MTR desde mi maquina al servidor = pérdida de paquetes en telefonica y en los saltos finales

MTR desde el servidor a mi maquina = pérdida de los primeros saltos y en telefonica

Podría poner todas estas pruebas aquí, pero me parece un poco pérdida de tiempo, dado que movistar tiene mejores herramientas que yo.

Y aunque el enlace que has puesto es útil, solo me sirbe para mi maquina, porque el servidor no tiene escritorio y no puedo abrir páginas web, si sabes de otra herramienta que se pueda usar desde una consola de Linux estaría bien conocerla.

PD: puede que la gente esté todo el día haciendo pings sostenidos de 1000 o más paquetes, en mi caso, solo lo hago cuando tengo un problema.

[Theliel]

Buenas @velocidad

Pues si sabes realmente como funciona el tráfico ICMP y como es gestionado... me darías entonces la razon.

Da igual las pruebas de pint/tracer que hagas, como las de MTR que a fin de cuenta es lo mismo, miden lo que miden, tráfico ICMP, El problema es muy simple, no es fiable de ningun modo, da igual el origen que sea, sea tu línea, sea la del vecino, sea desde otro servidor... es totalmente indiferente, el resultado siempre es el mismo, y tu mismo lo has dicho: llega a ciertos nodos donde aparecen esas "pérdidas". Es más, como digo siempre, si la pérdida fuese real, sería como la latencia, acumulativa desde el salto 1 hasta el último, y estoy seguro que no es así...

a caso el último salto, el del servidor final, muestra aproximadamente cuando se realiza un tracert/ping, una pérdida aproximada de la suma de todos los saltos anteriores??? Si por el motivo que sea hay un fallo digamos en el salto 3, el salto 4 debería de mostrar al menos un % similar, y el salto 5 lo mismo, y el 6º lo mismo.... y si en el 7º existiese otra pérdida de paquetes apreciable, el 8º tendría como mínimo la suma de unos y otros.

Al igual que medimos la latencia en principio al punto final, y luego con tracert para ver en que nodo se está llevando las tajadas, sabemos que la latencia final no deja de ser acumulativa, y cada salto anterior repercute en el siguiente, y el avegare de cualquier salto superio siempre es mayor que el de cualquier salto inferior... aquí ocurre lo mismo, y eso sí podría sonar la alarma de nodos con problemas, y como digo seguro que no es el caso, pon un tracer completo sino, y lo vemos claramente, o pingplotter o MTR o el que prefieras.

La discriminación del tráfico ICMP que haga un servidor o nodo puede ser desde totalmente clara a totalmente arbitraria, no esta en contra de la neutralidad de la red por ser un tráfico solo "de control". Como si quieren bloquear todo el tráfico ICMP sólo de las IPs españolas o de uan red completa, da igual, no hay nada que protestar o que arreglar.

No digo que te lleves todo el día haciendo ping sostenidos, creo que se ha entendido bastante bien lo que quería decir. Se lleva abusando años de ICMP, y mientras que muchos lo usamos como herramienta diaria de forma "adecuada" y con fines de trabajo o de mantenimiento real o de... lo cierto es que por cada persona que le da un uso debido, hay 1000 que lo hacen de forma indebida, y lo peor, como todo, no es el uso, es el abuso. Llevo años diciéndolo, y al final pasa lo que pasa... pero que esto no es nuevo, y seguirá pasando, y cada vez más servidores y nodos intermedios discriminarán aun más el tráfico ICMP.

Como digo el último ha sido el todo poderoso Google, que por ahora al menos no lo ha bloqueado del todo y solo de forma parcial, sobre todo hacia sus servidores DNS... esperemos que sea solo un experimento o algo temporal, dicho sea de paso.

Sobre el test.... es de código abierto, se puede descargar desde github

https://github.com/ndt-project/ndt/

Existe multitud de herramientas, pero casi todas por desgracia hacen lo mismo... ping/tracert. Una lectura fiable requiere que tanto emisor como receptor realicen una tansferencia acordada de X, e informar luego uno al otro de que han recibido por su parte... de lo contrario... el test aun así no es muy fiable por ejemplo para medir la velocidad, pero si da estadísticas relativamente acertadas en cuanto a la calidad de la conexión realizada. Por ejemplo, en mi caso, ahora mismo:

TCP receive window: 335360 current, 1948416 maximum
0.00 % of packets lost during test
Round trip time: 25 msec (minimum), 153 msec (maximum), 32 msec (average)
Jitter: -
0.00 seconds spend waiting following a timeout
TCP time-out counter: 230
129 selective acknowledgement packets received

No duplex mismatch condition was detected.
The test did not detect a cable fault.
No network congestion was detected.

0.9641 % of the time was not spent in a receiver limited or sender limited state.
0.0004 % of the time the connection is limited by the client machine's receive buffer.
Optimal receive buffer: - bytes
Bottleneck link: -
121 duplicate ACKs set

Un 0% es muy raro de ver en cualquier caso, como digo la pérdida de paquetes es algo normal en pequeñas cantidad, entorno al 0.5%, aunque por lo general es mucho menor, sobre todo a día de hoy (siempre conexiones cable, WIFI es otro cantar)

En mi caso lo que si veo son ACKs duplicados en cantidad, posiblemente provocados por Firefox, por mandar un ACK antes de recibir la confirmación por parte del server, lo ideal sería también minimizarlos, pero bueno, gajes de cada navegador, OS, Router y tantos otros.

[velocidad]

Gracias por la respuesta y por la herramienta.

De todos modos si escribo aquí es, y aunque queda claro todo lo del ICMP (eso lo he usado para corroborar el problema, como bien has dicho más de un 0.5% es raro), porque parece que existe un problema. Movistar tiene las herramientas para detectar si lo que digo es verdad o no, y en el caso (como bien has puntualizado) de que el problema esté en la parte de su red solucionar o no el problema.

Aún así discrepo un poco con lo que has dicho de la discriminación de paquetes ICMP, en muchos casos es verdad que se discrimina este tráfico por abuso del mismo (yo también he visto este comportamiento), pero en muchos otros es lo primero que se discrimina cuando hay una saturación. Es decir, que en la gran mayoría de los casos se discrimina no porque los usuarios abusen del ping/tracert, sino más bien por usar equipos y redes infradimensionadas, y como es lógico lo primero que se discrimina es lo "menos" importante.

[Theliel]

Buenas @velocidad

En realidad Movistar sólo tiene herramientas para ver el estado de su red, no del resto. Dudo mucho que le den acceso a la monitorización de una red del vecindario, pero eso es sólo suposición. Todo lo que sea dentro de su propia red, por supuesto.

"..pero en muchos otros es lo primero que se discrimina cuando hay una saturación"

Por supuesto que se hace!! Esta dentro del largo etc etc etc!! No se hace sólo ante un tráfico masivo ICMP, no me referecía a eso, me refería que el tráfico ICMP es el primero que se tira a la basura, y es evidente que cuanto más carga pueda tener un nodo/servidor, más probabilidad habrá de esto. Pero eso no quiere decir que suceda lo mismo con otro tipo de tráfico, ojo, lo que quiere decir es que de las primeras medidas que se hacen ante una carga más importante, es empezar a filtrar todo tipo de tráfico que es "inutil".

Pero eso no significa que te corten la conexión, hay que entender lo que significa. Otro ejemplo simple que no es ICMP. Cuando usamos tráfico que consideramos de tiempo real, como VoIP/videollamadas por ejemplo, no importa tanto en un momento dado que se pierdan paquetes, lo que más importa es la prioridad de estos, una baja latencia para poder tener una conversación fluida. Es otro tipo de tráfico que por lo general sí tiene un % de paquetes mas altos, pero porque se trata de oro modo, porque lo más importante no es que exista algo de ruído en la conversación, por encima de todo lo más importante es que la latencia sea mínima.

[velocidad]

Pues sinceramente espero que lo miren, esto de esta misma tarde:

 mtr -o "LSDNABWV" -w -r -c100 80.39.161.230
Start: Sun Oct 16 16:30:15 2016
HOST: XXXXXX Loss% Snt Drop Last Avg Best Wrst StDev
1.|-- static-ip-85-25-36-40.inaddr.ip-pool.com 0.0% 100 0 0.1 0.1 0.1 0.2 0.0
2.|-- te0-0-0-1.nr14.b015623-2.sxb01.atlas.cogentco.com 0.0% 100 0 1.0 0.9 0.7 3.2 0.2
3.|-- be2781.rcr21.sxb01.atlas.cogentco.com 0.0% 100 0 1.5 1.3 1.0 1.6 0.0
4.|-- be2246.ccr41.par01.atlas.cogentco.com 1.0% 100 1 7.9 8.0 7.8 9.3 0.1
5.|-- be2424.rcr21.par05.atlas.cogentco.com 2.0% 100 2 8.5 8.6 8.2 9.9 0.2
6.|-- 213.140.52.133 8.0% 100 8 87.4 26.7 8.5 111.1 30.5
7.|-- xe7-0-2-0-grtmadno1.net.telefonicaglobalsolutions.com 4.0% 100 4 94.6 53.3 43.1 128.3 17.9
8.|-- 213.140.50.86 6.0% 100 6 89.7 55.6 43.1 170.6 26.8
9.|-- 178.red-80-58-87.staticip.rima-tde.net 1.0% 100 1 40.6 41.2 36.5 50.8 2.9
10.|-- 85.red-81-46-8.customer.static.ccgg.telefonica.net 34.0% 100 34 40.4 39.0 35.5 81.3 5.6
11.|-- 226.red-81-46-2.customer.static.ccgg.telefonica.net 1.0% 100 1 40.1 38.0 34.9 48.8 2.4
12.|-- 162.red-80-58-78.staticip.rima-tde.net 1.0% 100 1 39.1 38.6 34.9 79.3 5.5
13.|-- 230.red-80-39-161.dynamicip.rima-tde.net 2.0% 100 2 38.4 42.9 38.0 51.4 4.3

Y el problema por lo que estamos comprobando es que no es solo de esta ruta, es como si se estuviera produciendo un ataque masivo a la red (uno más masivo de los habituales), y esta no estuviera aguantando.

[Theliel · Accepted solution]

Buenas @velocidad

Tal como te dije antes... todo es correcto en principio tu mismo puedes verlo salto a salto.

Voy a eliminar de tus datos todo lo "no relevante" para que tengas una visión más general de lo que te digo, a ver si así se ve mejor, voy a dejar solo % "perdido", numero de salto y avg de la latencia:

1. 0.0% - 0.1
2. 0.0% - 0.9
3. 0.0% - 1.3
4. 1.0% - 8.0
5. 2.0% - 8.6
6. 8.0% - 26.7
7. 4.0% - 53.3
8. 6.0% - 55.6
9. 1.0% - 41.2
10. 34.0% - 39.0
11. 1.0% - 38.0
12. 1.0% - 38.6
13. 2.0% - 42.9

Puesto así, ves más claro lo que te decía antes??

Primero, recordemos que es una sucesión temporal, es decir... primero se mandan paquetes al salto 1, luego al salto 2, luego al salto 3... cuando se mandan paquetes al salto 4 pasan antes por 1, 2 y 3... Y todo ello nos cuenta una historia, bastante clara. Te voy a explicar como se lee todo esto, como se interpreta esos resultados:

Primero, analicemos latencia, la tercera columna, y luego por separado la de paeutes perdidos:

Latencia

Saltos 1-6: Todo correcto, la latencia media va aumentando con cada salto. Por qué?? Porque cada salto, cada metro de cable recorrido aumenta la latencia. Así pues la latencia en el salto 2 es evidentemente mayor a la del salto 1, y así con todos.

Salto 7: Este nodo es muy variable, encontramos latencia desdede 17.9 hasta 128.3, posiblemente alta carga en el nodo, por su nombre debe de ser un peering de Telefónica con gran carga, de ahí las grandes oscilaciones, que se mantienen relativamentes a un nivel de latencia alto hasta que, temporalmente, se empiezan a enviar paquetes por el salto10-11.

Salto 8: La latencia sigue subiendo... todo normal

Salto 9-11: ¿¿La latencia baja?? Sí, el nodo 7 se debió de estabilizar por un pico que debió tener, así que a medida que se estabiliza la latencia vuelve a un nivel más realista

Salto 12-13: La latencia sigue subiendo de forma normal.

Respecto a la latencia, todo es normal, con la única salvedad de que se puede apreciar que durante unos segundos, mientras se realizaba la prueba que recorrían los nodos del 7 al 8, , el nodo 7 perteneciente a Movistar registraba picos debido posiblemente a una mayor carga, y en el tiempo que el test recorría los nodos 9-11 esta carga se estabilizaba en el nodo 7.

La latencia final, mirando el último salto, un average de 42.9, consistente con todos los datos anteriores y con la lectura de la latencia.

"% Paquetes perdidos"

En principio el comportamiento REAL de paquetes perdidos debería de comportarse igual a como se comporta la latencia. Pero vemos que no, que no cuenta la misma historia, de echo la historia que cuenta es precisamente que los nodos discrominan el tráfico ICMP como les da la gana, contestando cuando quieran:

Saltos 1-6: En principio, si fuera una pérdida real, veríamos un comportamiento adecuado, cada salto que da va aumentando la pérdida de paquetes. Es normal, si se pierde un 1% en el salto 4, en el salto 5 efecivamente pirede lo que se pueda perder en el salto anterior, y la suya propia. Esto es correcto, en principio repito, hasta el salto 6, que llega supuestamente hasta una pérdida de un increible 8%. Veremos que no es real

Salto 7-8: Primera incoherencia, pese a ir subiendo vemos un bajón a un 4%, pero no podemos sacar nada en claro, podría ser algo similar a lo que vimos en la latencia, y podría ser que fuese una fluctuación temporal, vamos a tomarlo como "cierto" que fuese una fluctuación temporal, y el salto 8 empieza a subir de forma "normal"

Salto 9: 1%... no hablamos de una pequeña bajada, hablamos de perder 1 paquete de 100 enviados, a un 8% que se estaba... primera incoherencia total que demuestra que en los saltos 1-8 no ha existido pérdidas tales, y que sólo ha sido discriminación de tráfico. De lo contrario veríamos de nuevo una cifra alrededor del 8%. Otra variación temporal?? Va a ser que no.

Salto 10: De nuevo choca diametralmente con los datos, ahora saltamos de 1 a 34?? Bien, vale, podría ser, vamos a admitir que sucede... que ya te digo que no, vamos a seguir leyendo...

Salto 11-12: 1%... Bien, está claro que esa "pérdida de 34% en el salto 10 es falsa, así como se confirma de nuevo que los saltos 1-8 estaban bien, sin pérdidas, o con pérdida despreciable.

Salto 13: Sube ligeralmente.

Al igual que la latencia, esto nos cuenta una historia. Desde el Salto 4, nodo de cogetco aparece el primer drop de paquetes, al menos en teoría. No podemos saber seguro si fue discriminación de tráfico o no, pero si miramos la pérdida final que dice estar en un 2%, podemos decir que en algún punto entre el salto 4 y el salto 13 si ha podido existir alguna pérdida real de paquetes.

No obstante podemos acotar esto... si miramos los saltos 6, 8 y 9 que se sitúa en el 1% de nuevo, y que ese 1% lo verifica también los saltos 11-12, podemos decir de forma relativamente segura que todo ese tramo que consuderas "malo", es correcto, que no ha existido ninguna pérdida de paquetes relevante. Sí, parece que de los 100 enviados hay 1 que se ha perdido en algún punto que no podemos precisar, aunque por los datos yo me inclino a pensar que sucede en el nodo 3-4.

Evidentemente los datos del nodo 10 no son reales, quedan totalmente invalidados por los consiguientes saltos. Y con no ser reales me refiero a que no existe tal pérdida, es simplemente discriminación de tráfico ICMP, no existe tal pérdida, no hay nada que arreglar, todo es correcto, y los consiguientes saltos lo confirman

-------------------------------------

Espero que así quede mucho más claro :). No hay problema en el nodo 10, simplemente el nodo 10 te está discriminando el tráfico ICMP como le da la gana, es más, viendo las latencias y otros, ni siquiera el nodo 10 es problemático en carga, el cual parece ser que sería el nodo 7 el más pesado de todos ellos.

Todo es más o menos correcto, nada que solucionar ni que mirar.

[velocidad]

 mtr -o "LSDNABWV" -w -r -c100 80.39.161.230
Start: Sun Oct 16 22:43:25 2016
HOST: XXXXXXXXXX                                              Loss%   Snt Drop  Last   Avg  Best  Wrst StDev
  1.|-- static-ip-85-25-36-40.inaddr.ip-pool.com             0.0%   100    0   0.1   0.1   0.0   0.4   0.0
  2.|-- te0-0-0-1.nr14.b015623-2.sxb01.atlas.cogentco.com    0.0%   100    0   0.7   0.9   0.7   3.1   0.2
  3.|-- be2781.rcr21.sxb01.atlas.cogentco.com                0.0%   100    0   1.4   1.3   1.0   1.7   0.0
  4.|-- be2246.ccr41.par01.atlas.cogentco.com                0.0%   100    0   8.0   8.0   7.8   9.2   0.1
  5.|-- be2424.rcr21.par05.atlas.cogentco.com                1.0%   100    1   8.5   8.5   8.3  10.1   0.2
  6.|-- 213.140.52.133                                       4.0%   100    4   9.1  20.1   8.0 102.2  22.5
  7.|-- 213.140.49.237                                       3.0%   100    3  43.3  53.2  43.3 130.9  17.7
  8.|-- 213.140.50.86                                        5.0%   100    5  47.1  50.0  43.2 153.4  17.1
  9.|-- 178.red-80-58-87.staticip.rima-tde.net               3.0%   100    3  40.2  40.6  36.4  52.5   2.8
 10.|-- 85.red-81-46-8.customer.static.ccgg.telefonica.net   4.0%   100    4  35.4  38.9  35.4  94.8   6.7
 11.|-- 226.red-81-46-2.customer.static.ccgg.telefonica.net  4.0%   100    4  35.0  37.6  35.0  44.1   2.1
 12.|-- 162.red-80-58-78.staticip.rima-tde.net               2.0%   100    2  39.2  39.8  35.0  76.5   8.2
 13.|-- 230.red-80-39-161.dynamicip.rima-tde.net             7.0%   100    7  38.4  42.9  37.9  51.2   4.4

 

  1.|-- 0.0%   0.1
  2.|-- 0.0%   0.9
  3.|-- 0.0%   1.3
  4.|-- 0.0%   8.0
  5.|-- 1.0%   8.5
  6.|-- 4.0%   20.1

  7.|-- 3.0%   53.2
  8.|-- 5.0%   50.0
  9.|-- 3.0%   40.6
 10.|-- 4.0%   38.9
 11.|-- 4.0%   37.6

 12.|-- 2.0%   39.8
 13.|-- 7.0%   42.9

[Theliel]

Más de lo mismo :), aunque menos descarado que antes 😉

Haciéndolo a la inversa desde mi línea a la dirección de tu salto 1: 85.25.36.40

Host	%	Sent	Recv	Best	Avrg	Wrst	Last
router.asus.com	0	100	100	0	0	3	0
192.168.144.1	0	100	100	2	5	47	3
No response from host	100	21	0	0	0	0	0
125.red-81-46-1.customer.static.ccgg.telefonica.net	0	100	100	7	14	105	36
213.140.50.218	0	100	100	8	10	23	11
te0-4-0-9-grtlontlw1.net.telefonicaglobalsolutions.com	0	100	100	42	44	47	45
be12956.rcr21.b023101-0.lon01.atlas.cogentco.com	0	100	100	43	43	46	43
be2949.ccr21.lon01.atlas.cogentco.com	0	100	100	42	43	46	42
be2868.ccr41.lon13.atlas.cogentco.com	0	100	100	43	43	46	44
be12497.ccr41.par01.atlas.cogentco.com	0	100	100	34	36	41	35
be2246.rcr21.sxb01.atlas.cogentco.com	0	100	100	41	42	45	42
be2780.nr13.b015623-2.sxb01.atlas.cogentco.com	0	100	100	45	45	49	45
xe-2-0-1.SXB1-RR-1-2-F8-3.core.heg.com	4	89	86	42	43	73	43
static-ip-85-25-36-40.inaddr.ip-pool.com	5	85	81	42	44	49	46

Mira, en mi caso 0 en todos menos en los dos últimos ;). Y no, no saco como conclusión de que esos dos puntos estén perdiendo mis paquetes, casi con toda seguridad simplemente estén discriminando el tráfico ICMP. Eso sí, los nodos intermedios en mi caso por los que pasa le tráfico son distintos. Misma redes, distindos nodos

[JulioC-Movistar]

El que un equipo no responda a un ping o a un tracert no implica que ese equipo no funcione adecuadamente, simplemente desechan paquetes dirigidos a ellos, paquetes que no tienen obligación de contestar, pero esta pérdida no afecta a su capacidad para reenviar el tráfico que no está dirigido a ellos que es el trabajo que tienen que hacer -y hacen- de forma eficaz.

El motivo de esa perdida puede ser variado, pero en cualquier caso es soberanía del nodo decidir si contesta o no, en que cantidad y a quienes contesta o no. 

Como muy bien ha explicado @Theliel la perdida de pines no es una herramienta fiable en ningún caso.

¿Cuál es el problema inicial que ha motivado tus pruebas de ping?

[velocidad]

Pués hemos contratado un servidor privado y para probarlo a fondo, hemos instalado un juego que conocemos bien su funcionamiento. Aunque bien es verdad que casi siempre va bien, hemos notado lag. Al hacer pruebas (dentro del juego) hemos visto que en esos momentos de lag el ping sube de de 30 a 110 y en casi todos esos casos no solo es una subida de ping, si no que además se pierden paquetes, nos tira del server en 7 de cada 10 subidas de esas.

Al ver este comportamiento, hemos hecho las otras pruebas que ya he comentado.

Como comprenderas a mi que se pierdan paquetes ICMP no es que me importe demasiado, pero si hemos contratado un servicio y no puedo disfrutarlo del todo por fallos, ahí si me importa, que es el caso.

PD: cuando contratamos el servicio, las primeras dos semanas fue bien, hasta que de repente empezamos a notar esto. Pensando que puedira ser alguna clase de mantenimiento no le dimos mayor importancia, pero esto se repite en el tiempo,, así que no parece que sea un mantenimiento.

[Theliel]

Buenas @velocidad

Totalmente al margen de discriminación de trafico ICMP y otros, la mayoría de todos los nodos que por lo general recorren los datos de un usuario no están en su ISP siquiera. Claro que en Internet hay cuellos de latencias, pérdias de paquetes y mil cosas más, y eso es a diariio y en cualquier servicio, y es normal, incluso ojo, dentro dela red del propio ISP.

Ahora bien... un problema es todo aquello que excede un comportamiento normal, o dentro de unos parámetros que podemos considerar normal, y repito esto se aplica al ISP y a cualquier otra red. Una fluctuación de latencia, de 40 a 100 o incluso a 200, podrá ser malo para jugar, pero igualmente está dentro de parámetros normales y asumibles.

Las pérdidas de paquetes lo mismo, es casi imposible en un tráfico X relativamente constante q no existan pérdida de paquetes. Es más, los propios protocolos y sisteas que se usan, gracias a esto, pueden también asegurar estabilidad. Como puse de ejemplo antes, el trafico entiempo real como juegos, videollaadas, VoIP... importa más que sea entregado con baja latencia a que algunos paquetes se pierdan, con lo que los servidores que manejan estos servicios se configuraon por lo generalpara esto, si hay que primar una de las cosas, se prima la baja latencia. Del mismo modo, otro tipo de servicios como puedan ser protocolso de seguridad o integridad, es al contrario, importa sobre todo la seguridad y fiabilidad de los datos que se mandan y llegan, sin importar si llegan algo antes o algo más tarde.

Todo esto se pondera y los servidores actuan en función a esto, priorizando de modos muy diferentes el tráfico

Como digo, esto pasa constantemente. Mientras estemos en días buenos donde las redes están rápidas y le tráfico es ligero, no es necesario que los sistemas de control siquiera actuen de un modo destacable, pq hay capacidad para todo y de sobra, pero en momentos que la cosa esta mas apretada, hay que actuar para que todo funcione del mejor modo

Dices que hay latencia picos de ella en ese juego... me lo creo perfectamente, y puede estar en la red de Movistar o no, no lo sabemos no tnemos datos para saberlo, al igual de que exista un % de paquetes reales perdidos, claro que me lo creo, yolos tengo a diario!! pero de ahí tampco se puede extrapolar ni un problema, ni aputar a alguienen particular, al menos con esos datos

Por supuesto, los técnicos, @JulioC-Movistar mismo podrá posiblemente verificar si hay un problema o constancia de algún problema conocido en algunos nodos de ellos, y por supuesto, como ha pasado las veces que se detecta un problema, se puede solucionar.

ahora bien, también mejor que nadie podrá decirte si que se sepa al menos, existe un problema en su red que pueda ocasionar lo que dices, o si por el contrario hay mil y una otra explicación posible, cmo es el caso.

Saludos compi

[JulioC-Movistar]

Si tenéis un servidor externo me imagino que podéis lanzar tracert y ping desde él a tu dirección IP y desde tu dirección IP hacia él, te ruego que hagas esa prueba, lanza 50 pines en los dos sentidos y un tracert en los dos sentidos, pásame los resultados en modo texto por un privado.

[velocidad]

enviado

[JulioC-Movistar]

Recibido, veo el destino, intentaré que uno de mis compañeros pruebe esta noche a lanzar una batería de ping contra ese destino sobre las 21:45 que en principio es vuestra hora conflictiva. Te cuento mañana

[PedroMP-Movistar]

Buenas noches@velocidad.

   Estos son los resultados de las pruebas realizadas:

ct@GNULinux:~$ mtr -o "LSDNABWV" -w -r -c1000 XX.XX.XXX.69

Start: Wed Oct 19 21:44:21 2016

HOST: GNULinux                                           Loss%   Snt Drop  Last   Avg  Best  Wrst StDev

  1.|-- gateway                                             0.0%  1000    0   0.3   0.3   0.2  66.5   2.8

  2.|-- 192.168.144.1                                       0.0%  1000    0   6.8   4.9   1.5  78.7   8.3

  3.|-- ???                                                100.0  1000 1000   0.0   0.0   0.0   0.0   0.0

  4.|-- 89.red-81-46-7.customer.static.ccgg.telefonica.net  0.0%  1000    0  13.6  13.6  11.0  78.8   4.1

  5.|-- 213.140.50.246                                      0.3%  1000    3  11.2  14.9   9.9 129.8  10.3

  6.|-- 213.140.49.118                                      0.0%  1000    0  47.4  45.6  43.4 103.3   3.5

  7.|-- be12956.rcr21.b023101-0.lon01.atlas.cogentco.com    0.0%  1000    0  44.7  44.1  43.1  96.4   2.4

  8.|-- be2949.ccr21.lon01.atlas.cogentco.com               0.0%  1000    0  44.6  44.7  43.8  78.7   1.6

  9.|-- be2871.ccr42.lon13.atlas.cogentco.com               0.0%  1000    0  44.1  44.2  43.7 109.6   3.0

 10.|-- be12489.ccr42.par01.atlas.cogentco.com              0.0%  1000    0  51.8  51.6  50.8 103.8   2.2

 11.|-- be2247.rcr21.sxb01.atlas.cogentco.com               0.0%  1000    0  58.6  58.6  58.3 127.2   2.7

 12.|-- be2780.nr13.b015623-2.sxb01.atlas.cogentco.com      0.0%  1000    0  58.9  59.1  58.3 103.7   2.2

 13.|-- xe-2-0-1.SXB1-RR-1-2-F8-3.core.heg.com              2.7%  1000   27  58.8  59.9  58.0 111.8   5.1

 14.|-- static-ip-85-25-36-40.inaddr.ip-pool.com            2.1%  1000   21  59.4  59.2  58.1 115.6   2.7

 15.|-- XXXXXXXXXXXXXXXXXXXXXXXXX                        1.6%  1000   16  59.5  59.1  57.5  91.1   1.7

ct@GNULinux:~$ mtr -o "LSDNABWV" -w -r -c1000 XXX.XXX.XXX.176

Start: Wed Oct 19 22:06:55 2016

HOST: GNULinux                                                Loss%   Snt Drop  Last   Avg  Best  Wrst StDev

  1.|-- gateway                                                  0.0%  1000    0   0.3   0.3   0.2  59.2   2.2

  2.|-- 192.168.144.1                                            0.0%  1000    0   2.2   4.7   1.2  64.7   7.9

  3.|-- ???                                                     100.0  1000 1000   0.0   0.0   0.0   0.0   0.0

  4.|-- 138.red-80-58-88.staticip.rima-tde.net                   0.1%  1000    1  15.0  14.6  11.2  35.1   3.6

  5.|-- et3-0-0-400-grtbcntb1.net.telefonicaglobalsolutions.com  0.6%  1000    6  10.8  13.9  10.2 126.1   8.1

  6.|-- xe1-1-0-0-grtpareq2.net.telefonicaglobalsolutions.com    0.0%  1000    0  37.2  38.5  36.7  84.6   4.2

  7.|-- xe4-0-4-0-grtwaseq6.net.telefonicaglobalsolutions.com    0.7%  1000    7 119.3 120.1 118.4 182.5   3.7

  8.|-- 192.205.36.53                                            0.0%  1000    0 117.0 115.3 112.6 175.7   3.1

  9.|-- cr2.wswdc.ip.att.net                                     0.0%  1000    0 154.7 157.3 151.4 203.9   4.0

 10.|-- cr1.attga.ip.att.net                                     0.0%  1000    0 167.7 166.9 164.2 230.2   4.4

 11.|-- ggr1.attga.ip.att.net                                    0.0%  1000    0 151.7 151.6 150.7 214.6   3.1

 12.|-- ???                                                     100.0  1000 1000   0.0   0.0   0.0   0.0   0.0

   Saludos

[PedroMP-Movistar]

Buenos días @velocidad.

   Espero que tu duda o problema haya quedado resuelto.

   Si no recibimos otro aviso por tu parte, daremos por solucionado el hilo y lo cerraremos en unos el lunes. Si posteriormente quieres ponerte de nuevo en contacto con nosotros, puedes hacerlo en Soporte Técnico de Fibra Óptica.

   Si consideras que alguna de las respuestas es la solución a tu duda o problema, te agradecería que la marques pulsando en el botón "Aceptar como solución". Con esa acción ayudarás a otros usuarios que puedan tener el mismo problema.

   Un saludo

[velocidad]

Ya está solucionado. Al final vamos a dejar el servicio, porque el problema está en sus servidores y no nos dan una solución.

Gracias por la ayuda, aportaciones.

[PedroMP-Movistar]

Buenos días @velocidad.

   Ni en nuestras pruebas, ni en las tuyas, detectamos un comportamiento anormal de la línea.

   Saludos