Buenas jadalisa
Pues me temo que, como es habitual, instan a culpar a todos menos a ellos mismos. Por suerte tus capturas son prueba de de que no existe problema alguno por parte del ISP. Es más, en sus propias contestaciones se pueden ver perfectamente como en igualdad de condiciones culpan a unos pero no a ellos. Y ahora te desgrano todo esto, obviamente. A diferencia de, a mi me gusta explicar las cosas.
En primer lugar, y más importante, es que la latencia o la pérdida de paquetes real es acumulativa. Esto es de sentido común, si en el primer salto se pierden 5 paquetes de los 10 que se envían, en el segundo salto solo podrán pasar 5 como mucho (porque se perdieron ya 5 en el primero), y si en ese seguro se pierden otros 3, en el tercer salto solo podrán llegar 2. Eso implica que en el primer salto veríamos una pérdida de un 50%, en el segundo veríamos una pérdida de un 80%, el tercer salto aparecería una pérdida del 80%.
La latencia es similar, es acumulativa, si en el primer salto existe un retraso de 5ms de media, en el segundo salto veremos como mínimo un retraso de 5ms, que es el retraso que ya se aplicó en el primer salto. Esto es totalmente obvio.
Es cierto que dado que una red es un ente dinámico y que es imposible enviar infinitos paquetes en un tiempo finito, no podemos tener una estadística perfecta, y a veces hay algunos saltos que puedan parecer que tienen ligeramente más latencia que otros, pero es solo debido a la imposibilidad estadística. Pero a groso modo, se ve perfectamente una tendencia.
Dicho esto, si no te importa, analizo tu tracert, empiezo por el primero, pero realmente es similar al segundo:
Lo primero que hacemos siempre es mirar el salto final, para ver la latencia media y la pérdida de paquetes, si existe. Tenemos el servidor de RIOT 162.249.72.1.
¿Problema? Que dicho servidor no está configurado para responder al tráfico ICMP, ni a los Echo Ping ni a la respuesta ICMP por TTL excedido, que es lo que usan las herramientas ping/tracert. Es por este motivo por el que aparece un 100% de pérdida y no hay latencia. Eso no significa que ese host no exista, es totalmente legítimo que un nodo quiera evitar responder a este tipo de tráfico, aunque a veces es cuanto menos sospechoso, sobre todo si es un punto final, dado que no podemos ver nada más allá de ese punto, no podemos saber nada más.
Dado que no podemos sacar información del servidor final porque RIOT no los impide, sólo podemos miar el nodo anterior, en este caso con IP 176.52.248.251, que pertenece a la red de Telefónica. En este nodo lo que tenemos es una latencia media de 6.2ms y una pérdida de paquetes de 0%.
Dicho de otro modo, antes de entrar en la red de RIOT, no existen pérdidas de paquetes reales ni una latencia elevada. Sin más. Aquí podríamos concluir el análisis. Pero como he dicho que me gusta explicar las cosas, voy a explicarte porque existen nodos intermedios en los que aparentemente existen supuestas pérdidas de paquetes, aunque la respuesta ya la he dado anteriormente al explicar por qué el nodo de RIOT lo hace.
Un nodo no tiene por qué responder con tráfico ICMP. Y sin esas respuestas no podemos hacer nada. Muchos nodos directamente las bloquean, como podemos ver en los saltos 4/5/8, algunos nodos pueden no bloquearla y solo discriminar el tráfico ICMP, con el nodo 3. Pero... ¿como podemos estar seguro de que dichos nodos realmente no hay una pérdida de paquetes reales? Simple, si realmente existiese una pérdida de 85% en el nodo 3, o de un 100% en el nodo 4, no habría más tracert, la conexión se quedaría ahí, porque se habrían perdido todos los paquetes, no habría nada más. Sabemos que esto no es así porque en el salto 6 y 7 no existe tal pérdida. Eso quiere decir simple y llanamente que en el resto de nodos simplemente hay o un bloqueo completo o parcial, exactamente igual que hace el nodo de RIOT.
Es interesante como en la contestación que hace riot dice:
"Hay una pérdida visible de paquetes en los saltos 3,4 y 5..." en cambio no hace mención al salto 8, donde siguiendo su propia lectura existe una pérdida igualmente del 100%. ¿No te parece? Su 100% es menos válido que el 100% de otros nodos?
Obviamente no es así, y ellos los saben... o quiero pensar que lo saben claro está, sino sería aun más preocupante :).
--------
Respecto a segundo tracer es exactamente lo mismo, de nuevo el último nodo, el de RIOT bloquea toda comunicación, con lo que es imposible saber que pasa más allá. Si te das cuenta hay otros nodos con 100% de pérdidas, pero luego hay otros saltos después de ellos que podemos conocer, que sabemos que existen... el tráfico realmente está fluyendo. En cambio cuando vemos un 100% de pérdida en un punto final nos puede indicar diferentes cosas:
a) Que realmente en dicho punto se esté perdiendo el 100% del tráfico
b) Que dicho nodo bloquee las respuestas ICMP como ya he dicho
c) Que dicho nodo no sea el final, sino que existan otros nodos e incluso un servidor final que son invisibles a nosotros, son invisibles porque ninguno responde al tráfico ICMP.
En este caso particular es casi con total certeza la opción C. RIOT está ocultando de forma deliberada todo el tráfico que pasa a su red. Y esto lo digo porque si nos damos cuenta es el primer nodo de RIOT. El primer nodo de RIOT te aseguro que no es el servidor final, con lo que es sólo un nodo intermedio de ellos, a saber de cuantos más entremedias. Igual es un tracer aun más grande, no lo sé, lo digo simplemente basándome en el destino que has marcado como final, y desde luego ese nodo no puede ser el destino final real.
Esto no es nuevo, no es la primera vez que vemos a RIOT ocultando sus huellas. El problema es que al hacerlo no tenemos ninguna herramienta que nos diga como de mal es el problema, y en que punto real está dentro de la red de RIOT. Pero si sabemos algo claro y obvio, que justo a la entrada de la red de RIOT el tráfico era correcta, no existía pérdida de paquetes ni existía problema de latencia.
-----------
Así que, siento decirte, que los amigos de RIOT no están haciendo otra cosa que echar balones fuera, poniendo además de excusa (y esto es algo que me muestra la mala voluntad que hay por su parte) algo que ellos mismos aplican a su red, pero que por supuesto no señalan.
Hay dos opciones. O realmente saben lo que está pasando y prefieren culpar a otro y actúan de mala fe, o realmente no tienen mucha idea de como se lee un tracer realmente, y/o como funciona el protocolo ICMP a la hora de realizar pings o las respuestas ICMP por TTL.
Si te queda cualquier duda, dímelo, que con gusto te lo explico sin ningún problema.
Saludos.
Buenas de nuevo jadalisa
No respondo ni atiendo a mensajes privados como pongo en mi firma, me parece totalmente descortés para el resto de los usuarios del foro, puesto que lo que se dice en privado, queda en privado, y no suelo tener nada que ocultar :). Tan solo uso la mensajería privada aquí para cuestiones personales o muy concretas. Por otro lado, no pertenezco a Movistar ni tengo ninguna relación con ellos, soy un cliente al igual que tú.
Dicho todo ello, si quieres, te explico un poco más todo, no me importa en absoluto.
Aunque antes de ello, decirte que en este caso concreto Movistar no tiene que hacer absolutamente nada, ni contactar con nadie que no seas tú como su cliente. No existe ningún problema en su red a fin de cuentas. ¿Te imaginas una multinacional de tal magnitud yendo detrás de otras empresas para solucionarle los problemas a ellos? Movistar/Telefónica ya tiene sus propios problemas y asuntos, como para ir contactando con otras empresas para solucionar los problemas que tengan. Si esperas alguna actuación por ese lado, ya te digo que puedes esperar sentado, da igual que termines yéndote a otro ISP o no, es una cuestión mucho más sencilla que todo eso: No hay ningún indicio en los datos mostrados que indique un problema en su red. Y si esto lo veo yo como usuario y con las herramientas que tenemos a disposición, cuanto más podrán ellos saberlo 🙂
-----------------------------------
Dicho todo esto, lo único que puedo si quieres es explicarte mejor todo, al menos para que unos y otros no te tomen por tonto, y perdóname por la expresión, ya que no tienes ningún tipo de necesidad de tener que saber de estas cosas. Por desgracia muchos se aprovechan del desconocimiento técnico de la inmensa mayoría para decir/hacer lo que quieran.
Voy a tratar de explicarte de forma sencilla y escueta (dentro de lo posible) los dos o tres conceptos importantes aquí. Latencia y Paquetes perdidos, Ping y Tracert.
La latencia en las redes es ni más ni menos lo que llamamos el RTT, siglas inglesas, lo que viene a ser el tiempo de ida y vuelta (Si, el de vuelta también, la suma de todo). Es decir, desde que pulsas una tecla en tu teclado hasta que esa pulsación viaja por tu teclado, tu PC, el cableado de tu casa, el Router, la red de Movistar, las redes Intermedias, el servidor final, el procesado de dicha pulsación y todo el camino de vuelta.
Los paquetes perdidos por otro lado es un poco más ambiguo, y hay que especificar bien a que nos referimos. Podemos hablar de paquete perdido real cuando enviamos un paquete de datos y este se pierde en el camino (de ida o de vuelta), ya sea por un cable roto, ya sea porque un dispositivo lo descarta o cualquier otra anomalía. En cambio, la mayoría de aplicaciones/utilidades no pueden detectar esto, y llaman paquete perdido a otra cosa. ¿En un mensaje de solo ida... como puedes saber si un paquete ha llegado? No puedes saberlo, porque si no esperas contestación, ha podido llegar o no. Así que se ingenian sistemas en el que se envía una "pregunta" para forzar una "respuesta". Así si la respuesta nos llega podemos decir que no se ha perdido el paquete, puesto que la respuesta ha llegado. Si la pregunta o la respuesta se perdiese en la ida o en la vuelta, tú no recibirías respuesta, ¿cierto? Pues así se asume estas herramientas y sistemas que hay una pérdida de paquetes. Pero realmente si te das cuenta no implica que se pierda un paquete, lo que miran es si llega o no llega la respuesta, que es bien diferente como ahora veremos.
--------------------
Si entiendes bien estos dos conceptos, podemos explicar que es el "ping" o un "tracert".
Ping es una utilidad/herramienta para medir la latencia entre un origen y un destino en redes. Su funcionamiento depende íntegramente en un protocolo llamado ICMP, que es usado para el diagnóstico de redes. Cuando lanzamos un PING lo que hacemos es enviar a un destino un paquete especial ICMP llamado "Echo Request", que lo que hace es que induce al destino a responder con un "Echo Reply" al origen. funciona así porque el protocolo ICMP es así. De este modo un equipo puede medir el tiempo desde que envía el Echo Request hasta que le llega el Echo Reply. Y magia!! Esa es la latencia, es el tiempo que ha tardado el paquete ICMP en ir y volver. El funcionamiento es más sencillo que un chupo. Solo tiene una pega. El destino usado para el "Echo Request" no tiene por qué estar configurado para responder con un "Echo Reply". Que entienda el protocolo ICMP no implica que tenga que contestar. Si quieres un ejemplo más visual de esto piensa en el teléfono móvil. El Echo Request sucede cuando te llaman por teléfono, el Echo Reply cuando respondes la llamada. Pero... tu puedes no coger el teléfono, ¿cierto? Pues aquí pasa lo mismo. Si no descuelgas el teléfono, la otra persona no puede medir el tiempo que has tardado en descolgar, porque no has descolgado.
Tracert es otra utilidad para el diagnóstico de redes.En este caso Tracert se usa para conocer los nodos intermedios por los que transcurre los paquetes de datos desde el origen hasta el final. Esto es importante porque los datos no van de origen a destino directamente, en Internet pasan por multiples redes y nodos intermedios. Tracert nos permite intentar descubrir todos esos nodos intermedios, e incluso conocer la IP de ellos!!. Es increíble el ingenio detrás de esto. En este caso no se hace uso de un protocolo especial concreto, se puede realizar un tracert usando paquetes ICMP, paquetes TCP, paquetes UDP... la magia viene en otro lado. Un tracert explota un campo de la cabecera del protocolo IP llamado TTL. El protocolo IP es en esencia los que nos hace movernos por Internet. Este campo, TTL (Time to Live) existe para evitar que un paquete de datos pueda estar eternamente circulando por Internet. Parece una tontería, pero imagínate que existe por error un bucle en una red... el campo TTL lo evita. El campo TTL es un contador ni más ni menos, que decrece en 1 por cada nodo/salto por el que pasa. Los dispositivos de red están configurados para que si un paquete llega a TTL 0, se descarta. Por regla general, cuando un nodo descarta un paquete porque el TTL ha llegado a cero, informa al origen del paquete con un mensaje que dice algo así como "Paquete descartado por TTL excedido", y lo hace, sorpresa, a través del protocolo ICMP con "Time Exceded"
Entonces, como funciona un Tracert? Bien, se aprovecha del campo TTL. Dado que cuando el TTL es excedido por lo general el nodo va a responder con un mensaje al origen ICMP, lo que se hace es envíar al destino un paquete con:
TTL 1: El Router le restará 1, como es cero lo descarta e informa a tu equipo que lo ha descartado, tu equipo ya tiene la 1º IP, la de tu Router.
TTL 2: El Router le resta 1, no es cero, lo pone en circulación. El siguiente nodo (posiblemente la centralita en este caso le resta 1, es cero, TTL excedido, envía mensaje ICMP al origen. Tu equipo ya tiene el salto 2, la centralita, y su IP.
TTL 3+:... el proceso se repite indefinidamente hasta que la respuesta de TTL excedido le llega desde la misma IP de destino a la que lo estaba enviando. En este punto ya tiene todos los nodos intermedios.
¿Todos los nodos? Bueno, tendrá todos los nodos si todos ellos han respondido con el mensaje ICMP de TTL Excedido, si alguno de ellos no ha respondido porque no está configurado para hacerlo, para el equipo habrá un "agujero" del que no tendrá la IP ni datos. Y por qué sabemos que existe ese agujero? Simple, porque aunque no nos responda, cuando usamos el siguiente paquete con un TTL de +1, el siguiente si nos envía el mensaje, con lo que sabemos que hay un nodo ahí "oculto".
-------------------------------------------------
Pues bien, hasta aquí lo complicado. Si eso lo hemos entendido solo hay que sumar ambas herramientas, que es lo que hace WinMTR y otras herramientas (pingplotter por ejemplo).
Primero se realiza un tracert para conocer todos los nodos intermedios, y una vez tenemos las IPs de dichos nodos, podemos usar ping hacia ellos para conocer la latencia.
Por qué existen "agujeros" o supuestas pérdidas de paquetes que no lo son y otros datos "confusos"? Realmente no son datos confusos, los datos son lo que son, el problema es una mala interpretación. Si el tracert no tiene respuesta por ejemplo de conocer el salto 5, no puede enviar ningún ping a él, así que la aplicación te muestra esto como un 100% de pérdida. No es que dicha pérdida exista, es que ni siquiera ha podido conectar con él. A veces si tenemos información del nodo y de su IP gracias al tracert, pero por el contrario el nodo bloquea las respuestas ICMP Echo Reply, completamente (de nuevo tendríamos un 100% de pérdida de paquetes) o parcialmente.
En cambio, en ambos supuestos anteriores, no sería una pérdida de paquetes real, puesto que no se ha perdido ningún paquete. Más bien el nodo en cuestión no nos ha respondido intencionadamente, aunque los paquetes hayan llegado.
Una pérdida de paquetes real es aquella en la que tus paquetes son como decíamos descartados o perdidos en la ida o en la vuelta. SI te das cuenta nada tiene que ver con lo otro, donde los paquetes sí llegan, y no se pierden a la vuelta, simplemente no se responde...
Análogamente, como decía con la llamada de teléfono, no puedes asumir que la persona al otro lado del teléfono no lo coge porque está hablando con otro. Uno podría decir que es fácil saberlo porque si está hablando con otro te sale comunicando, ¿cierto? Sí, normalmente a lo mejor, pero ¿y si habilitas la llamada en espera? Quien llama no lo sabe, para el que llama tan solo aprecia que no le cogen el teléfono (paquete perdido), cuando a lo mejor simplemente tiene puesta llamada en espera y está por teléfono con otra persona.
------------
Como podemos saber entonces si la pérdida de paquetes o la latencia es real? Pues ya lo he dicho, es muy simple.
Una carrera de obstáculos con 10 puntos de control en los que van cronometrando a los que van llegando. Tu sólo estás cronometrando en la salida sin ver que pasa en el resto de puntos de control, pero por radio cada punto de control te dice los tiempos de todos los que han pasado. Preparados, listos... ya!! Salen 100 participantes.
Te van llamando los puntos de control por los que van pasando, y te informan de los 100 tiempos de cada uno, todo va bien, primer punto de control, segundo punto de control... Vaya!! En el tercer punto de control tan solo te dan 50 tiempos, que ha pasado con el resto de corredores? No lo sabemos aun... obviamente esperas a ver que pasa en el cuarto. En el cuarto punto de control te llegan ahora sí 100 tiempos de nuevo.. ¿Que es lo que piensas?
a) Hay 50 corredores que hicieron trampa y se teletransportaron hasta el control 4
b) En el control 3 metieron la pata y bien, miraron para otro lado...
Sabemos que los corredores han llegado al punto 4, con lo que no se han perdido ni les ha pasado nada, así que obviamente la opción lógica es la b, algo pasó en el punto 3 y no los contaron por cualquier motivo.
Seguimos avanzando, control 5 bien, control 6... en el control 7 en cambio nos llegan solo 90 tiempos, faltan 10. Por supuesto pensamos que pueda pasar lo mismo que en el punto 3, esperamos el punto control 8, pero al llegar al 8 nos vuelven a mandar 90. Que está pasando?
a) Doble descuido por parte del punto de control? Es posible, doble error, pero es posible
b) Se nos han caído 10 concursantes en el camino
Nos llegan los datos del punto 9 y ahora solo son 70, y en la meta tan solo logran contabilizar de nuevo 70.
Bien, llegado a este punto damos por supuesto que en algún punto entre el control 7 y el 8 10 corredores mordieron el polvo, y que entre el 8 y el 9 se cayeron otros 20.
Salieron 100, llegaron 70. Tú que estás en la linea de salida no puedes miar la meta, no sabes realmente cuantos llegaron, solo tienes los tiempos recabados de cada punto de control. Del mismo modo que en el control 3 das por sentado que se contó mal, en los controles anteriores parece ser que si que se cayeron, puesto que en el recuento final tampoco aparecían.
-------
La pérdida de paquetes real es igual. Si existiese una pérdida de paquetes reales donde indicas, esta se vería reflejada en todos los demás puntos, al igual que los puntos de control de los corredores. Si en uno de los puntos aparecen todos los paquetes, es que obviamente en algunos puntos anteriores no se ha contado bien, los paquetes como los corredores no pueden teletransportarse 🙂
Más absurdo aun, cuando vemos el 100%, si existiese realmente un 100%, el tráfico se acabaría ahí, no habría más nodo ni más nada.
Siento el tocho y espero que lo entiendas un poquito mejor, y que veas lo absurdo que te diga el supuesto servicio técnico de RIOT que es que hay cierta pérdida en ciertos puntos del ISP... cuando en el de ellos pone un 100% de pérdida (que tampoco es real que tengan un 100% de pérdida o no tendrías conexión directamente con ellos)
Saludos.
