Buenas Javiruiz27
Me temo que el problema está en como interpretas esos resultados, y que no comprendes bien como funcionan los Tracer y los Ping. Lo he explicado ya en alguna ocasión. Y es un gran problema el no saber interpretar bien los datos, porque por regla general se llegan a conclusiones totalmente erróneas.
La versión corta, sino quieres leer el resto, es que en tu tracer no existe ningún problema, es totalmente normal. La latencia como la pérdida de paquetes real, es acumulativa siempre. Es decir, si en un salto tienes 5ms de pérdida, en el siguiente aproximadamente tendrás como mínimo ese 5ms, y así sucesivamente. La pérdida real de paquetes es igual.
Para la pérdida real de paquetes tienes que fijarte en el primer salto y en el último, en esencia. Si en el primer salto tienes pérdida de paquetes, es derivada seguramente a WIFI o a una saturación en tu propia red. Dependiendo de diferentes configuraciones puede pasar que no se replique hacia abajo, porque los paquetes pueden reenviarse dentro de tu propia red local. y a veces "no traspasa". Por otro lado, en este caso concreto, tan solo hay que miar el destino final para ver que no existe pérdida de paquetes.
Entonces, por qué aparece en esos nodos esas cifras? Simple, se llama discriminación de las respuestas ICMP. Y entender esto implica entender como funciona Ping/Tracer. Aunque su funcionamiento es totalmente diferente porque hacen uso de técnicas diferentes, ambos dependen de su funcionamiento que el nodo de destino o el servidor final en su defecto, RESPONDA con paquetes ICMP concretos a lo que nosotros haciendo ping/tracer queremos obligarles a hacer. El problema es que los nodos de red no tienen por qué responder a esto, o hacerlo de forma totalmente discriminada en función de las reglas que usen internamente. Pero esto no afecta al tráfico que no sea ICMP.
Un ejemplo simple de como funciona ping. Repito que tracer es diferente pero requiere igualmente de respuestas ICMP, explico ping poq es más simple de entender el protocolo.
Cuando tu haces ping a un destino o nodo concreto, como por ejemplo en tu tracer pueda ser el salto 1 (que por cierto, pérdida de paquetes no pero tienes una latencia en tu red bien alta), lo que hace tu equipo es generar un paquete especial usando el protocolo ICMP, ese paquete se llama ICMP "Echo Request". Ese paquete especial tiene la función de "inducir" al nodo/destino que sea a que responda al origen con un paquete especial llamado ICMP "Echo Reply". De este modo el equipo puede cronometrar el tiempo que pasa entre que envía el Echo Request y recibe el Echo Reply ,y ese es el valor de la latencia que nos muestra.
El problema es que muchos asumen que dicho destino/nodo está configurado para responder a los Echo Request que le llegue. Y no es así. Dado que ICMP es un protocolo de usado únicamente para gestión/control/análisis, los nodos pueden desde directamente no responder nada a ese Echo Request (lo verías en un winmtr/pingplotter como host no alcanzable o 100% de pérdida), a simplemente discriminar las respuestas a 1 de cada 5, o 1 de cada 10, o dependiendo del tráfico que haya en la red o... no existe una regla. Simplemente se discrimina. Y es una práctica extremadamente habitual. De echo es muy raro hacer un tracer y no ver que en algún punto no exista un nodo que no responde, con un 100% de pérdida...
Vale, pero entonces... como podemos saber realmente si es una discriminación o que realmente existe dicha pérdida? Pues esto es muy fácil. Un tracert te muestra un camino por el que siguen tus paquetes. Simplemente tienes que aplicar lógica aplastante. Si en un punto de la red pierdes por ejemplo el 100%, simple y llanamente no podrías tener nunca datos del siguiente salto, porque el 100% se han perdido en el salto anterior. Obvio, no?? Como vas a seguir la carretera si existe un corte total en la carretera??
Si realmente existiese en el salto 2-5 esas pérdidas, en el salto 7 veríamos al menos una pérdida aproximada de u 80%!! Y en cambio hay cero. De nuevo, lógica aplastante...
Enviamos 100 paquetes, de los cuales 10 se quedan en un punto, luego solo quedan 90. En el siguiente salto no se pierde ninguno... ¿cuantos pasan por él? 100? No, pasan de media 90, porque 10 se han quedado en el anterior, con lo que si miramos solo ese nodo, tendríamos que ver unos 10 de media. En el salto 6 tenemos un 80%, luego en el salto 7 tendríamos que ver más o menos el mismo valor para que fuese una pérdida real. Y no lo es.
Los valores no suelen ser exactos porque obviamente se debe a factores estadísticos, a fin de cuenta un ping o un tracer tan solo tiene validez en ese mismo instante, el siguiente paquete siempre va a tener un valor diferente, aunque sea de microsegundos. Debido a esto podemos ver a veces datos un tanto extraños como que en un nodo la latencia es de 20 y en el siguiente es de 19! la lógica común diría que es imposible, y de echo lo es, lo que pasa es que esto es totalmente dinámico, a lo mejor el anterior paquete pasó ligeramente más rápido por las condiciones de la red en ese preciso instante. Por eso suele ser bueno enviar tandas de al menos 200-300 paquetes para que los resultados sean lo más normalizados posibles.
Así que como ves, tu lectura es totalmente normal, la única anomalía que existe es que en tu red estás metiendo una latencia enorme, 16ms de media es una barbaridad, pero si dices que usas WIFI... pues blanco y en botella. Pero en lo relativo a pérdida de paquetes real, no existe tal. Si te fijas, tu latencia va subiendo siempre por salto, puede ser incluso la misma en alguno, pero no va a bajar, es acumulativa, la pérdida de paquetes es igual.
Espero que te quede algo más claro de como funcionan ping/tracert. Como digo no funcionan igual, Tracert funciona totalmente diferente pero es que su funcionalidad es diferente, pero sigue haciendo uso del forzar al nodo/destino a responder con un paquete ICMP específico, con lo que realmente la casuística es la misma.
Saludos.
