Hola °°INFINITY°°
No hemos tenido respuesta tuya en unos días, entendemos que ya no tienes más consultas. Si no es así, o tienes cualquier duda/incidencia estamos a tu disposición.
Un saludo.
Fernando.
Buenas °°INFINITY°°
Pues si quieres te respondo a todas tus cuestiones sin ningún tipo de problema.
Lo primero, para analizar trazas, usar tracert/tracerouter no es muy adecuado, ya que con solo 3 pruebas no puedes descartar los valores fuera de estadística, que requieren cientos de ellos. Por ello solemos usar herramientas tipo WinMTR, que hace más o menos lo mismo, pero lanza paquetes hasta detener. Esto es necesario, 3 paquetes no nos elimina fluctuaciones puntuales, se requieren como digo al menos 300-400 paquetes para tener lecturas más o menos realistas y estabilizadas con el tiempo
Lo segundo, en tus datos no aparece nada de 10ms en el primer salto, a menos que no te refieras a saltos, porque luego hablas de la puerta de enlace... por lo general la conexión al servidor PPPoE 192.168.144.1 es el segundo salto, pero dependiendo del Router puede o no aparecer. Si hablamos del primer salto, es un problema en tu propia red local, no de la línea, es decir, entre tu equipo y tu Router, que además es un Router propio. Tendrías que asegurarte que está todo bien configurado, que es capaz y un largo etc. En eso no podríamos ayudarte mucho, podría ser cualquier cosa, desde un proceso del Router que se apodera de demasiados ciclos de proceso y aparece la latencia, desde alguna característica con la que le viene grande, con que está mal configurado... o incluso algún dispositivo de tu propia red que está saturando el Router, y no es el Router directamente, sino algún dispositivo que interactúa con él. Si es otro punto al que te refieres, pues ya nos dices, pero por eso los saltos están numerados.
Lo tercero, con respecto a optimizaciones o no de peering, no tiene nada que ver. Hay que partir de la base de que las rutas no son estáticas, son dinámicas, Internet está en cambio constante. Eso quiere decir que el camino entre A y F puede ser hoy A->B-C-F y mañana puede ser A-C-E-F. Es más, puede de pronto ser una ruta mucho más corta o mucho más larga. Esto es bastante habitual. Por otro lado, el ISP no te lleva al destino, el ISP te lleva a la entrada de la siguiente red, nada más, y la otra red a la siguiente, y esa a la siguiente... cada red es operada por una empresa/compañía/entidad diferente. En este caso si no veo mal salta de la red de Movistar a la troncal de Telefónica y de ahí a la red de Amazon en el salto 8, con lo que a partir de ahí tan solo compete a ellos.
La respuesta o no respuesta de los saltos intermedios es una cuestión de manías de algunos y ocultaciones de otros. Manías de unos para evitar carga de tráfico innecesaria suprimiendo las respuestas ICMP que son las que permiten realizar ping/tracert. Esto es muy habitual y no hay nada raro en esto, a veces se hace una supresión total, a veces es una supresión parcial, es decir, a lo mejor solo ignoran o descartan 1 de cada 10 o 5 de cada 10 o... otros bloquean todo siempre, y otros permiten todo siempre.
Para descubrir los nodos intermedios se hace uso del valor especial TTL de los paquetes. Este se disminuye en 1 en cada nodo, si un nodo/router lo disminuye y se queda en cero lo descarta y avisa al origen de esto. Esto es la técnica que permite conocer la IP de los nodos. Se envía un paquete primero con TTL 1 para conocer la IP del salto 1º, luego un paquete con TTL2 para saber la PI del salto 2... así hasta que responde el destino, y con eso tienes la traza. Una vez tienes la IP de cada salto, envías un ping sostenido a cada nodo, que el ping por otro lado no es más que un paquete especial ICMP que hace responder a un nodo u objetivo con la respuesta pertinente.
Pero que pasa si un nodo no responde al tráfico por TTL terminado? Pues el equipo no obtiene respuesta no sabe si hay o no hay algo, así que envía otro con un TTL superior en 1. Si responde el siguiente, sabe que hay en medio uno que no ha respondido, pero sabemos que existe porque ha decrementado el TTL en 1. Imagínate ahora que simplemente dicho nodo no suprime siempre la respuesta ICMP por TTL=0. Si cuando lanzas el tracert/winmtr suprime la respuesta TTL, aparecerá como un nodo sin respuesta, si cuando lo lanzas no suprime en ese momento la respuesta, el nodo aparecerá.
Es cierto que algunas redes hacen un uso extenso de bloquear las respuestas ICMP para evitar que puedas cotillear en sus nodos y así poder echar la culpa a otros, puesto si no ves dentro de la red de ellos nada o muy poco, no puedes ver donde está el problema ;).
Saludos.
Theliel De acuerdo he entendido mayormente el mensaje y muchas gracias por la muy elaborada y argumentada respuesta , la cual te agradezco enormemente .
En cuanto a lo de el router neutro , si así es , he visto que lo has visto y así es porque recientemente adquirí un equipo propio el cual ya sé de antemano que no ofrecéis ningún tipo de soporte ni mucho menos como es obvio pero quitando cualquier tipo de problema de cualquier tipo de configuración y demás porque se de antemano que está a la perfección configurado el fijo e internet (actualmente no tiene soporte para IPTV por la VLAN) comentarte que lo que decía sobre el primer salto no me refiero al primer salto de forma literal que es hacia el propio router como ya sé sino el primer salto hacia el lado de Telefónica me refería o hacia la central como se le conoce a veces que no sé si es un término correcto o literalmente es así que así es en realidad, la central , lo que yo venía comentando es que hay a veces que cuando hago un tracer ese mismo salto me da una latencia altísima y muy variada y a veces como ahora me la da correcta , 1 ms , eso es propio de Telefónica y eso es un nodo de Telefónica no es nada externo ni un punto de intercambio de empresas externas mi última duda que eso normal no es , y no será por carga de tráfico ni nada por el estilo por qué además a veces hago el tracert hacia otros destinos y me da ese primer salto a Telefónica correcto , por cierto ya había escuchado con anterioridad de estas herramientas la cual voy a probar y ver que tal para analizar con más detenimiento la de winMTR comentarte adicionalmente que la central está situada un equipamiento Nokia , que no sé si tendrá algo que ver pero yo ahí lo dejo
Buenas °°INFINITY°°
Da igual el equipamiento que esté al otro lado, tienen varios, Nokia es uno de ellos. Por eso me refería a, ya que está enumerados, usarlos para ello.
La importancia de usar WinMTR o un simple tracert es enorme. Un ejemplo muy sencillo y básico. En cualquier punto siempre puede existir una fluctuación, del tipo que sea. Si haces un tracert que realiza simplemente 3 pruebas seguidas y una de ellas por el motivo que sea da la casualidad se pierde, te dirá que tienes un 33% de pérdida de paquetes, a fin de cuenta de 3 pierde 1. Imagina que envías 100 y pierde 1. Ahora solo es un 1%, y ese mismo paquete podría ser el que captures con la prueba de 3. Con la latencia se aplica la misma lógica. Esto hace imperativo siempre usar una gran cantidad de paquetes para que los valores puedan estabilizarse debido a la propia naturaleza de las redes, y al final lo que nos quedamos siempre y no hay que olvidar, son valores estadísticos, nunca absolutos, así que cuantas más muestras, más fiables pueden ser.
Hola °°INFINITY°°
No hemos tenido respuesta tuya en unos días, entendemos que ya no tienes más consultas. Si no es así, o tienes cualquier duda/incidencia estamos a tu disposición.
Un saludo.
Fernando.
