Foro
buenas claudioi
El problema de base es una mala interpretación de las aplicaciones tipo pingplotter/tracert/winMTR, pero con gusto te lo explico, y sin siquiera necesidad de ver esos datos, puesto que e algo muy habitual
1º. La pérdida de paquetes real, tal como la latencia es acumulativa. Esto es de sentido común, si de 100 paquetes en un salto pierdes 10, al siguiente van a llegar 90, con lo que en ese siguiente salto también dirá que aproximadamente se han perdido 10. Con la latencia es similar si el primer salto se come 10ms, en el segundo la lectura que tendremos será como poco de aproximadamente 10ms. Los datos no son exactos por que internet es totalmente dinámico, pero más o menos ambas lecturas irían creciendo progresivamente.
2º. Que no responda un nodo es totalmente normal, es habitual. Del mismo modo que pueda aparecer de pronto un 30, un 60... de supuestos paquetes perdidos. No son paquetes perdidos, el problema es entender como funcionan estas herramientas. Estas herramientas se basan en el uso de PING y tracert. Ambos hacen uso del protocolo de control ICMP. Para simplificar, en esencia, el usuario que usa estas herramientas lo que pretende es inducir una respuesta concreta por parte de los nodos intermedios o el servidor final, gracias a respuestas automáticas ICMP. Esto es maravilloso porque nos permite identificar nodos intermedios y la latencia a ellos. Pero no es obligado. Un nodo de red no tiene por qué responder con tráfico ICMP a un Ping o a un error pro TTL (la técnica que hacen uso los tracert). Si un nodo no responde con un mensaje ICMP de TTL excedido, desde el punto de vista de tu aplicación que lanza el tracert ese host dirá que no responde o un 100% de paquetes perdidos. Por qué? Porque el equipo mandó un TTL para que lo rechazase y el simplemente no contestó, al no contestar el equipo no puede obtener la IP de ese nodo intermedio y de ahí que salga el que no responda, no existe...
Esto es similar a cuando aparece un % de paquetes perdidos artificial. El nodo podría estar configurado para responder, pero solo 1 de cada 3 por ejemplo, o uno de cada 6, o permitir sólo 100 cada 5 minutos vengan de quienes vengan. No hay una norma, cada uno lo hace como quiere. Tu propio Router lo hace por ejemplo, tiene protecciones de ese tipo, si alguien te intenta bombardear con ping o conexiones, tu Router automáticamente lo autoregula.
Esto no afecta absolutamente nada al tráfico real, solo al tráfico ICMP que esos nodos responden.
¿Pero entonces... como sabemos si es real o no? Pues por lo que he explicado en el punto 1º. Si fuese real y en ese nodo tuvieses un 100% de paquetes perdidos... no tendrías un salto siguiente, porque ya se ha perdido todo en el anterior. O si se pierde un 30% en el anterior, en el siguiente verías una pérdida parecida (porque obviamente para llegar al siguiente han tenido que pasar previamente por el anterior)... y esto se podría seguir trazando hasta el destino final. Si el destino final dice que la pérdida es de 0% y la latencia es "normal", problema ninguno, simplemente es discriminación de algunos nodos del tráfico ICMP
3º. Direcciones IP aparentemente fuera de España? No. No sé donde lo estás mirando, pero ten cuidado con ello. Una IP no se geolocaliza. Existen bases de datos de terceros que con datos estadísticos que tienen y aplicando lógica, pueden decir que una IP está aquí o allá. Pero eso no es cierto. El único que puede conocer la ubicación real de una IP es el ISP/empresa a la que pertenece. Sí, esas bases de datos aciertan muchas veces... otras veces ni se acercan. El único dato real 100% que puedes obtener de una IP, es mirando en RIPE NCC que es el RIR de nuestra región para saber al operador al que pertenece, cual es el segmento de red, etc etc etc.
Si no te queda claro cualquier cuestión concreta, pregunta sin problema que te lo aclaro, entiendo que son cuestiones un poco técnicas y complejas en un primer momento.
Saludos.