Buenas chrisparra98
Te lo "traduzco", muchas veces uno tiende a leer mal estas cosas dando por por sentado unas cosillas que luego no son, y te indico por lo general que es lo importante.
Si solo nos interesase la latencia y/o paquetes perdidos reales miramos el final. En este caso el final puede engañar, miramos el último salto con datos. Esto es latencia media final de 33ms y 0% paquetes perdidos. Tanto la latencia como los paquetes perdidos reales son acumulativos siempre. Esto es un camino, si en mitad del camino hay aun agujero que te retrasa 10ms y se caen 3 paquetes, al siguiente punto de control le van a faltar por lo general 3 paquetes y 10ms, y en el siguiente lo mismo o más. A veces los datos pueden discrepar un poco por factores estadísticos, de ahí a que enviar muchos paquetes estabiliza siempre los datos.
33ms y 0% es un gran dato... esto es válido solo para ese destino ojo, otro destino, son otros datos totalmente diferentes y se analizan de otro modo. Pero por lo general hay más coas que ver en un tracert/ping de estos.
El primer salto es tu primer Router... bueno, suele serlo, en tu caso veo el traspaso de dos redes, ergo doble NAT, algo totalmente nefasto en cantidad de escenarios, no sé que te ha movido a ello o necesidades, pero... mal negocio. Si el 1.1 es un HGU, pues básicamente no está en monopuesto, funciona en el modo tradicional y tienes otro Router después de él actuando tb de Router. Esto puede propiciar muchos cuellos de botella, sin contar ya problemas de conexiones (no tanto de retrasos o pérdidas de paquetes ni esas historias).
Los nodos intermedios que ves que son como perdidos, no es que exista ni mucho menos un agujero que se lo come todo. Si fuese así realmente no verías nada más a partir de ahí. Eso sucede por que esos nodos no responden al tráfico ICMP, que es el protocolo especial que usan las utilidades tracert/ping para poder realizar estas pruebas. Un nodo o un destino final no tiene por qué responder a este tráfico. Y claro, al no responder parecen como "muertos". Sabemos que es esto porque dos saltos más adelante ya si hay respuesta. Esto es muy habitual, repito. No podemos obtener datos ni de latencia ni de pérdidas de paquetes ni de IPs de esos nodos, pero sabemos que están ahí gracias al truco que emplea tracert para descubrirlos, sería largo de explicar ahora. Esos dos nodos intermedios son totalmente correctos, pero es cierto que no tenemos datos de lo que pasa dentro. Pero podemos inferirlos por el anterior y el posterior, viendo que hay una escalada normal de latencia en ello.
El final en cambio es y no un problema. Si no pudieses acceder a la misma página/drección/dominio que has puesto en WinMTR, entonces denotaría una rotura de la red a partir del último nodo que hay respuesta. Si puedes acceder a la web/servidor, lo que está pasando es que el servidor final no responde al tráfico ICMP, igual que pasa con los saltos 5 y 6 que hemos visto antes, está pasando lo mismo. La diferencia es que en el salto 7 había otro nodo, y por eso hay respuesta. En este caso lo que estaría pasando es que ya sea el destino final o un nodo muy cerca del final y también el servidor final, no responden al tráfico ICMP. Por eso sigue indefinidamente. WinMTR como no ha llegado a la IP final, aumenta un salto con la esperanza de llegar, y como no hay respuesta otro, y luego otro, y luego otro... y seguramente ese primer no responde del final sea o el servidor final o un nodo anterior al servidor final, pero sea como sea a partir de ese punto HASTA el servidor final, nadie está configurado para responder.
Esto normalmente no implica problemas de conexión, pero si nos oculta información, porque no podemos tener la referencia final. Sí, tenemos la referencia anterior, pero no sabemos la final. Si ese último nodo o incluso el servidor final está dando problemas, no lo podemos ver... al menos por los modos tradicionales.
Esto es un truco que hacen algunas redes/servidores finales. Algunos lo hacen descaradamente para ocultar problemas que tienen en esos puntos finales, ya que tendríamos que hacer uso de herramientas más profundas para analizar el tráfico real que nos llega de ellos y ver latencias o pérdidas reales. Otros no actúan de mala fe, y simplemente, al igual que pasa con otros nodos intermedios, es una cuestión de ahorrar ancho de banda evitando las herramientas de diagnóstico (ping/tracert).
En cualquier caso, el tráfico parece ir bien hasta el salto 12, que es el último que hay información. Si te fijas, en los dos anteriores, en el 10 y el 11 si he contado bien aparece una supuesta pérdida de paquetes, del 11 y el 18 respectivamente. Es fácil saber que no es una pérdida real, porque el salto 9 no denota nada y el salto 12 tampoco. El salto 9 podría estar limpio y existir pérdida real, pero entonces en el 12 lo veríamos también, no tiene por qué ser un 12 exacto, pero rondaría por valores similares, al menos un 15-20. Esto no pasa.
Entonces porque sale eso? Porque igual que un nodo puede bloquear las respuesta ICMP, muchos otros lo que hacen es una discriminación. O dicho de otro modo, en vez de bloquearlo, filtro por ejemplo 1 de cada 10, o la cantidad que sea. Tu propio Router por ejemplo hace algo similar, si detecta en un tiempo breve una serie de paquetes iguales, a lo mejor acepta los 5 primeros, bloquea el resto durante 10 segundos, acepta los 5 siguientes... etc etc etc. Esto es para evitar sobre todo ataques DoS, y por supuesto también para ahorrar ancho de banda. No es que no lleguen los paquetes, es que la respuesta que busca inducir ping/tracert no tiene éxito, porque ese nodo dice algo como: Te voy a contestar solo de vez en cuando.
En la traza completa, en esta en particular no veo nada especialmente raro. Es cierto que a partir del salto 12 uno está ciego y no se puede saber el estado del servidor final o incluso del nodo anterior. Pero hasta ese punto los datos son buenos, 0% pérdida, una latencia media de 33ms y un jitter de unos 3-4ms. En lo tocante a la conexión, quitando repito nodo final o destino final, es correcta.
Nota: Cuidado con Doble NAT, es causa habitual de cuello de botella. El mayor trabajo que realiza un Router es precisamente NATear, y estás enlazando dos, cualquier mínimo retraso en uno, causa un cuello en el otro.
Puedes hacer pruebas para esto es sencillo, puedes por ejemplo ponerte a subir un archivo pesado de esos que que dices que te dan problemas a veces, y a la par, en cuanto te pongas a ello lanzas WinMTR exactamente igual, al mismo servidor donde estés enviando el archivo. De este modo se puede ver perfectamente el comportamiento de toda la ruta en la condición real, es decir, cuando se dan las condiciones que ocasionan los problemas. Es muy probable que los datos fuesen ahora bastante diferentes, pero no solo en tu red ojo, incluso en el resto de nodos/redes
