Explicando el Comando Traceroute

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.

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.

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 ).

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.

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ó.

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.

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.

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.

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.

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.

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.