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.
