Ir al contenido principal
Traceroute puede ser una herramienta invaluable cuando se trata de diagnosticar problemas de conexión a los hosts de otras redes. Sin embargo, para ser usado de manera efectiva tienes que entender cómo funciona y qué significa la salida.

 

Traceroute funciona manipulando el valor de Tiempo de Vida (TTL) en el encabezado IP (figura 1). Como tuve que hacer mis ejemplos usando la red interna de Stratus , he sacado la representación hexadecimal de la dirección IP en los trazos del paquete y traducido todos los octetos en cualquier notación decimal punteada a un código único de letras de la A a la W. El número de letras representa el número de dígitos del octeto. Es decir, AAA representa un número de 3 dígitos mientras que J representa un número de 1 dígito.

 

Xmit IP Ver/HL 45, ToS 0, Len 5c, ID 5447, Flg/Frg 0, TTL 3c, Prtl 1
Cksum e90c, Src XXXXXXXX, Dst XXXXXXXX
ICMP from AAA.BBB.CC.DDD to EEE.FFF.GGG.HHH echo
Figura 1 - Marco del monitor de paquetes con TTL de alta luminosidad
Cada enrutador que procese el paquete disminuirá el valor TTL en 1 y si el valor TTL es mayor que 0 pasará el paquete al siguiente enrutador o al destino final. Si el valor TTL es 0 el enrutador descartará el paquete y *puede* enviar un mensaje de excedencia de tiempo ICMP de vuelta al remitente. La clave es *puede*, algunos enrutadores no devolverán el mensaje de tiempo excedido o lo harán sólo si no están ocupados. Además, algunos firewalls bloquearán el mensaje ICMP, de modo que incluso si el router envía el mensaje de tiempo excedido, el host que está ejecutando el traceroute puede que nunca lo vea.
Traceroute comienza enviando un mensaje al destino con un valor TTL de 1. Calcula el tiempo que tarda desde que envía el mensaje hasta que recibe una respuesta.

 

17:07:07.797 Xmit IP Ver/HL 45, ToS 0, Len 28, ID 1, Flg/Frg 0, TTL 1, Prtl 11
Cksum 78CC, Src XXXXXXXX, Dst XXXXXXXX
UDP from AAA.BBB.CC.DDD.34611 to EEE.FFF.GGG.HHH.33435 Cksum 0000, 20 data bytes.
17:07:07.799 Rcvd IP Ver/HL 45, ToS c0, Len 38, ID 4a39, Flg/Frg 0, TTL 80, Prtl 1
Cksum 0d1a, Src aXXXXXXXX, Dst XXXXXXXX
ICMP from AAA.BBB.II.J to AAA.BBB.CC.DDD time excdd

 

Figura 2 - marco de seguimiento del monitor de paquetes y respuesta
Por defecto, el comando traceroute envía tres mensajes con un TTL de 1 e informa las tres veces y el nombre y/o dirección IP del router que envió la respuesta. Siempre utilizo el argumento -numérico para no tener que esperar a la resolución del nombre (figura 3). Entonces el router incrementa el TTL en 1 y lo hace de nuevo. Continuará incrementando el TTL hasta que obtenga una respuesta del destino o se alcance algún límite, 30 (por defecto). Puede encontrar documentación sobre todos los argumentos de traceroute en el manual de OpenVOS STREAMS TCP/IP Administrator's Guide (R419 ).

 

traceroute -numeric EEE.FFF.GGG.HHH
traceroute to EEE.FFF.GGG.HHH (EEE.FFF.GGG.HHH), 30 hops max, 40 byte packets
1 AAA.BBB.II.LLL 2 ms 1 ms 1 ms
2 AAA.BBB.II.J 1 ms 1 ms 1 ms
3 AAA.BBB.MM.NN 12 ms 5 ms 6 ms
4 BBB.OOO.PPP.QQQ 76 ms 76 ms 76 ms
5 BBB.RRR.SSS.TTT 80 ms 80 ms 80 ms
6 BBB.RRR.SSS.UUU 87 ms 82 ms 79 ms
7 EEE.FFF.V.J 89 ms 89 ms 86 ms
8 EEE.FFF.GGG.HHH 82 ms 87 ms 80 ms
ready 15:19:12

 

Figura 3 - salida del trazador
Es de esperar que a medida que aumente el TTL los tiempos aumenten y así suele ser, aunque no siempre, comparar los terceros tiempos reportados del salto 6 (79 ms) y del salto 5 (80 ms) en la figura 3. Hay varias razones para ello. En primer lugar, la red no es determinista, a veces sólo tarda más tiempo. En segundo lugar, el enrutador del salto N-1 puede estar más ocupado que el del salto N y tarda más en llegar a enviar el mensaje ICMP. Por último, el camino de retorno del enrutador N puede ser más rápido que el camino de retorno del enrutador N-1. Por ejemplo, no es necesario que el enrutador 4 envíe su respuesta de vuelta a la fuente a través de los enrutadores 3, 2 y 1. Podría enviar su respuesta directamente al enrutador 1, lo que podría ser significativamente más rápido. Esto significa que, aunque el traceroute es muy bueno para informar de la ruta que toma un paquete desde el host de envío hasta el host de destino, no se puede confiar en que un paquete enviado desde el host de destino al host de envío tome la misma ruta sólo en sentido inverso. Esto se conoce como enrutamiento asimétrico.

 

Traceroute puede añadir una bandera a una hora que indique que recibió algo distinto al mensaje de tiempo excedido esperado. Las banderas son:
H - huésped inalcanzable
Red inalcanzable.
Protocolo inalcanzable.
Por ejemplo, en la figura 4 se muestra que el primer encaminador no sabe cómo llegar a la red de destino, por lo que devuelve un mensaje de red no alcanzable y el encaminador termina en ese punto.

 

traceroute EEE.FFF.GGG.HHH -numeric
traceroute to EEE.FFF.GGG.HHH (EEE.FFF.GGG.HHH), 30 hops max, 40 byte packets
1 AAA.BBB.CC.KKK 2 ms !N 0 ms !N 1 ms !N
ready 15:40:03

 

Figura 4 red de mensajes inalcanzables
Un asterisco (*) en el lugar de una hora indica que el trazador no recibió una respuesta. Como he dicho antes, puede ser que el enrutador no envíe un mensaje de tiempo excedido ICMP, puede ser que un cortafuegos haya bloqueado el mensaje de tiempo excedido en su camino de regreso o que un cortafuegos haya bloqueado el mensaje saliente. También podría ser que la red haya dejado caer el mensaje saliente o el mensaje de regreso.

 

Un solo o incluso dos tiempos muertos en un salto (figura 5) probablemente indica que el enrutador no envió el mensaje porque estaba ocupado o que la red estaba dejando caer paquetes (o ambos). Observe el octavo salto en la figura 5, el asterisco antes de la dirección IP significa que el primer mensaje del conjunto se agotó.

 

traceroute to EEE.FFF.GGG.HHH (EEE.FFF.GGG.HHH), 30 hops max, 40 byte packets
1 AAA.BBB.II.LLL 1 ms 0 ms *
2 AAA.BBB.II.J 1 ms 1 ms 1 ms
3 AAA.BBB.MM.NN 1 ms * 1 ms
4 BBB.OOO.PPP.QQQ 7 ms 8 ms 8 ms
5 BBB.RRR.SSS.TTT 76 ms 76 ms 75 ms
6 BBB.RRR.SSS.UUU 79 ms 77 ms 77 ms
7 EEE.FFF.V.J 79 ms * *
8 * EEE.FFF.W.253 79 ms 79 ms
9 EEE.FFF.GGG.HHH 80 ms 80 ms 80 ms
ready 14:43:16

 

Figura 5 - enrutador ocupado o paquetes perdidos
Si los tres mensajes expiran pero los saltos subsiguientes reportan tiempos (figura 6) es probable que el enrutador de ese salto no envíe mensajes de tiempo excedido de ICMP.

 

traceroute to EEE.FFF.GGG.HHH (EEE.FFF.GGG.HHH), 30 hops max, 40 byte packets
1 AAA.BBB.II.LLL 1 ms 0 ms 1 ms
2 AAA.BBB.II.J 1 ms 1 ms 1 ms
3 AAA.BBB.MM.NN 1 ms 1 ms 1 ms
4 BBB.OOO.PPP.QQQ 7 ms 8 ms 8 ms
5 BBB.RRR.SSS.TTT 76 ms 76 ms 75 ms
6 BBB.RRR.SSS.UUU 79 ms 77 ms 77 ms
7 * * *
8 * * *
9 EEE.FFF.GGG.HHH 80 ms 80 ms 80 ms
ready 14:47:01

 

Figura 6 - enrutador(es) que no responden
Si todos los saltos pasan de un cierto punto de tiempo muerto (figura 7) es probable que haya un cortafuegos que bloquee los mensajes salientes o de retorno.

 

traceroute to EEE.FFF.GGG.HHH (EEE.FFF.GGG.HHH), 30 hops max, 40 byte packets
1 AAA.BBB.II.LLL 1 ms 0 ms 0 ms
2 AAA.BBB.II.J 1 ms 1 ms 1 ms
3 AAA.BBB.MM.NN 1 ms 1 ms 1 ms
4 BBB.OOO.PPP.QQQ 7 ms 6 ms 8 ms
5 * * *
6 * * *
7 * * *
8 * * *
. . . .
29 * * *
30 * * *
ready 14:51:05

 

Figura 7 - Bloqueo del cortafuegos
Hay otra razón por la que todo lo que pasa de un cierto punto se acaba. Es cuando el objetivo no responde. No todos los objetivos responderán y cuando eso ocurre tienes algo que se parece a la figura 8. La diferencia entre las figuras 7 y 8 es que en la figura 8 el último enrutador en enviar una respuesta es el enrutador que está localizado en el objetivo. ¿Cómo puedes saber que esto es así? A veces el direccionamiento lo hace obvio, por ejemplo el objetivo es 192.168.1.12 y 192.168.1.1 es el último router en responder. No es tan obvio en la figura 9, EEE.FFF.W.XXX puede ser el último enrutador antes de EEE.FFF.GGG.HHH, tienen los primeros 16 bits en común. Pero sin conocer el esquema de subredes utilizado por la red del objetivo no hay forma de estar seguro sin preguntar.

 

traceroute to EEE.FFF.GGG.HHH (EEE.FFF.GGG.HHH), 30 hops max, 40 byte packets
1 AAA.BBB.II.LLL 1 ms * 0 ms
2 AAA.BBB.II.J 1 ms 1 ms 1 ms
3 AAA.BBB.MM.NN 1 ms 1 ms 0 ms
4 BBB.OOO.PPP.QQQ 10 ms 7 ms 6 ms
5 BBB.RRR.SSS.TTT 77 ms 76 ms 75 ms
6 BBB.RRR.SSS.UUU 79 ms 80 ms 81 ms
7 EEE.FFF.V.J 82 ms 78 ms 79 ms
8 EEE.FFF.W.XXX 78 ms 95 ms 77 ms
9 * * *
. . . .
29 * * *
30 * * *
ready 15:00:20

 

Figura 8 - el objetivo no responde
También es posible obtener respuestas de dos o más encaminadores para el mismo salto (figura 9). Esto puede suceder si los enrutadores están equilibrando la carga o la red es inestable y las rutas están cambiando o, como en el caso de la figura 9, el enrutador AAA.BBB.CC.KKK no era el enrutador óptimo y después de reenviar el paquete a AAA.BBB.II.J envió un mensaje de redireccionamiento de vuelta a la fuente para cambiar su tabla de enrutamiento.

 

traceroute EEE.FFF.GGG.HHH -numeric
traceroute to EEE.FFF.GGG.HHH (EEE.FFF.GGG.HHH), 30 hops max, 40 byte packets
1 AAA.BBB.CC.KKK 7 ms 1 ms 0 ms
2 AAA.BBB.II.J 1 ms AAA.BBB.MM.NN 1 ms 1 ms
3 BBB.OOO.PPP.QQQ 9 ms 8 ms 8 ms
4 BBB.RRR.SSS.TTT 81 ms 81 ms 77 ms
5 BBB.RRR.SSS.UUU 80 ms 79 ms 78 ms
6 EEE.FFF.V.J 81 ms 77 ms 77 ms
7 EEE.FFF.W.253 78 ms 80 ms 80 ms
8 EEE.FFF.GGG.HHH 84 ms 83 ms 80 ms
ready 15:47:51

 

Figura 9 - dos respuestas para el mismo salto
Hay dos tipos de comandos de rastreo que se distinguen por el tipo de mensaje que envían. Algunos traceroutes, como el que se encuentra en los sistemas de Microsoft Windows envían mensajes de solicitud de eco ICMP (ping); otros como el que se ejecuta en STCP envían mensajes UDP. Conocer el tipo de traceroute que se utiliza es importante si se necesita configurar los firewalls para permitir el paso de paquetes o escribir filtros de analizador de protocolos. También la respuesta del objetivo será diferente. Si el objetivo recibe una petición de ping, devolverá una respuesta de ping; si recibe un mensaje UDP, entonces la respuesta depende del número de puerto. Si el puerto está en uso, la aplicación de escucha probablemente descartará el paquete porque no cumple con los requisitos de la estructura de mensajes de la aplicación. Si el puerto no está en uso, el host *puede* enviar un mensaje ICMP de puerto de destino inalcanzable de vuelta. Por esa razón traceroute selecciona los puertos que típicamente no se utilizan.

 

El número de puerto que ve el huésped objetivo dependerá de cuántos saltos se necesitan para llegar a él. Traceroute inicia el puerto de destino en 33435 (por defecto) e incrementa el número de puerto para cada mensaje (figura 10). Por lo tanto, el destinatario ve 3 puertos diferentes, lo más probable es que los tres no estén en uso. El puerto de origen se basa en el ID del proceso de envío. Un proceso determinado utilizará siempre el mismo puerto de origen.

 

dir len proto source destination src port dst port
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33435
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33436
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33437
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33438
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33439
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33440
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33441
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33442
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33443
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33444
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33445
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33446
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33447
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33448
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33449
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33450
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33451
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33452
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33453
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33454
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33455
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33456
R 28 ICMP EEE.FFF.GGG.HHH AAA.BBB.CC.DDD unreach
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33457
R 28 ICMP EEE.FFF.GGG.HHH AAA.BBB.CC.DDD unreach
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33458
R 28 ICMP EEE.FFF.GGG.HHH AAA.BBB.CC.DDD unreach

 

Figure 10 - (edited) packet traces showing port number changes
Por último, a menos que haya un problema con el primer salto, probablemente no haya mucho que puedas hacer para solucionar el problema. Una vez que STCP (o cualquier pila de red del host) envía un paquete al enrutador local está fuera de sus manos (y de las tuyas). Sin embargo, si conoce la dirección IP del último salto que responde o el salto en el que comienzan a producirse repentinamente los tiempos muertos, tendrá una idea de dónde se encuentra el problema y podrá ponerse en contacto con el grupo correcto de administradores de red para resolverlo.