Mientras que lo anterior es la forma en que se debe escribir el comando traceroute para que funcione en la línea de comandos, el rendimiento o la salida del comando se puede cambiar especificando uno o más interruptores opcionales.

• -f: Establezca el tiempo de vida inicial utilizado en el primer paquete de sonda saliente.
• -F: Poner el bit «don’t fragment».
• -d: Habilitar la depuración a nivel de socket.
• -g: Especifique una puerta de enlace de ruta de origen suelta (8 máximo).
• -i: Especifique una interfaz de red para obtener la dirección IP de origen de los paquetes de sondeo salientes. Esto normalmente sólo es útil en un host multihomed. (Vea la bandera -s para otra manera de hacer esto.)
• -I: Utilice ICMP ECHO en lugar de datagramas UDP.
• -m: Establezca el tiempo máximo de vida (número máximo de saltos) utilizado en los paquetes de sondeo de salida. El valor predeterminado es 30 saltos (el mismo valor predeterminado utilizado para las conexiones TCP).
• -n: Imprimir direcciones de salto numéricamente en lugar de simbólicamente y numéricamente (guarda una búsqueda de dirección a nombre del servidor de nombres para cada puerta de enlace encontrada en la ruta).
• -p: Configure el número de puerto UDP base utilizado en las sondas (por defecto es 3343434). Traceroute espera que nada esté escuchando en los puertos UDP base to base + nhops – 1 en el host de destino (por lo que se devolverá un mensaje ICMP PORT_UNREACHABLE para terminar el seguimiento de la ruta). Si algo está escuchando en un puerto dentro del rango predeterminado, esta opción se puede utilizar para seleccionar un rango de puertos no utilizado.

• -r: Anula las tablas de enrutamiento normales y envía directamente a un host en una red conectada. Si el host no está en una red conectada directamente, se devuelve un error. Esta opción se puede utilizar para hacer ping a un host local a través de una interfaz que no tiene ninguna ruta a través de ella (por ejemplo, después de que la interfaz fuera soltada por routed(8C)).
• -s: Utilice la siguiente dirección IP (que normalmente se da como un número IP, no como un nombre de host) como dirección de origen en los paquetes de sondeo salientes. En hosts multihomed (aquellos con más de una dirección IP), esta opción puede usarse para forzar que la dirección de origen sea algo diferente a la dirección IP de la interfaz en la que se envía el paquete de sondeo. Si la dirección IP no es una de las direcciones de interfaz de esta máquina, se devuelve un error y no se envía nada. (Vea la bandera -i para otra forma de hacerlo.)
• -t: Establezca el tipo de servicio en los paquetes de sonda en el valor siguiente (valor por defecto cero). El valor debe ser un entero decimal en el rango de 0 a 255. Esta opción se puede utilizar para ver si los diferentes tipos de servicio dan lugar a diferentes rutas. (Si no está ejecutando 4.4bsd, esto puede ser académico, ya que los servicios de red normales como telnet y ftp no le permiten controlar los TOS.) No todos los valores de los TOS son legales o significativos – ver las definiciones en la especificación IP. Los valores útiles son probablemente ` -t 16‘ (bajo retardo) y ` -t 8‘ (alto rendimiento).

• -v: Salida Verbose. Se listan los paquetes ICMP recibidos que no sean TIME_EXCEED y UNREACHABLEs.
• -w: Establezca el tiempo (en segundos) para esperar una respuesta a una sonda (por defecto 5 seg.).
• -x: Alternar sumas de comprobación de IP. Normalmente, esto evita que Traceroute calcule las sumas de comprobación de IP. En algunos casos, el sistema operativo puede sobreescribir partes del paquete saliente pero no recalcular la suma de comprobación; por lo tanto, en algunos casos el valor por defecto es no calcular las sumas de comprobación y usar -x hace que se calculen. Tenga en cuenta que las sumas de comprobación son normalmente necesarias para el último salto cuando se utilizan sondas ICMP ECHO ( -I ), por lo que siempre se calculan cuando se utiliza ICMP.
• -z: Establezca el tiempo (en milisegundos) para hacer una pausa entre sondas (por defecto 0). Algunos sistemas como Solaris y routers de Cisco, limitan la velocidad de los mensajes icmp. Un buen valor para usar con esto es 500 (por ejemplo, 1/2 segundo).

Interpretación de los resultados

Traceroute describe la ruta que sigue un paquete IP a un host de Internet lanzando paquetes de sonda UDP con un pequeño TTL (tiempo de vida) y luego escuchando una respuesta ICMP «time exceeded» (tiempo excedido) desde un gateway. Comenzamos nuestras sondas con un TTL de uno y aumentamos en uno hasta que conseguimos un ICMP «puerto inalcanzable» (lo que significa que el paquete llegó a su destino) o alcanzamos un valor máximo de intentos, que por defecto es de 30 saltos y puede cambiarse con la bandera -m .

Cuando Traceroute se ejecuta, envía tres sondas en cada ajuste de TTL y luego imprime una línea a la consola que muestra el TTL, la dirección de la puerta de enlace y el tiempo de viaje de ida y vuelta de cada sonda. Si las respuestas de la sonda provienen de diferentes puertas de enlace, se imprime la dirección de cada sistema que responde. Si no hay respuesta dentro de un intervalo de tiempo de espera de cinco segundos (cambiado con la bandera -w ), se imprime un asterisco para esa sonda.

Para evitar que el host de destino se vea desbordado por el procesamiento de paquetes de sonda UDP, el puerto de destino se establece en un valor que es improbable que sea utilizado por ese dispositivo. Si una red o servicio en el destino utiliza ese puerto, cambie el valor utilizando el indicador -p .

Un uso y salida de muestra devolverá resultados similares a los de este ejemplo:

[yak 71]% traceroute nis.nsf.net.
traceroute to nis.nsf.net (35.1.1.48), 30 hops max, 38 byte packet
1 helios.ee.lbl.gov (128.3.112.1) 19 ms 19 ms 0 ms
2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms
3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms
4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 39 ms 39 ms
5 ccn-nerif22.Berkeley.EDU (128.32.168.22) 39 ms 39 ms 39 ms 39 ms
6 128.32.197.4 (128.32.197.4) 40 ms 59 ms 59 ms 59 ms
7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 59 ms 59 ms
8 129.140.70.13 (129.140.70.13) 99 ms 99 ms 99 ms 80 ms
9 129.140.71.6 (129.140.71.6) 139 ms 239 ms 319 ms
10 129.140.81.7 (129.140.81.7) 220 ms 199 ms 199 ms 199 ms
11 n.d. (35.1.1.1.48) 239 ms 239 ms 239 ms 239 ms

Nótese que la segunda y tercera línea son las mismas. Este resultado se relaciona con un núcleo de buggy en el segundo sistema de lúpulo -bl-csam.arpa- que reenvía paquetes con un TTL cero (un fallo en la versión distribuida de 4.3 BSD). Debe adivinar qué camino están tomando los paquetes a través del país ya que NSFNet (129.140) no proporciona traducciones de dirección a nombre para sus NSSes.

Un ejemplo más interesante es:

[yak 72]% traceroute allspice.lcs.mit.edu.
[yak 72]%.traceroute to allspice.lcs.mit.edu (18.26.0.115), 30 hops max
1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms 0 ms
2 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 ms 19 ms 19 ms
3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 19 ms 19 ms 19 ms
4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 19 ms 39 ms 39 ms
5 ccn-nerif22.Berkeley.EDU (128.32.168.22) 20 ms 39 ms 39 ms
6 128.32.197.4 (128.32.197.4) 59 ms 119 ms 39 ms
7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 59 ms 39 ms
8 129.140.70.13 (129.140.70.13) 80 ms 79 ms 99 ms
9 129.140.71.6 (129.140.71.6) 139 ms 139 ms 139 ms 159 ms
10 129.140.81.7 (129.140.81.7) 199 ms 180 ms 300 ms
11 129.140.72.17 (129.140.72.17) 300 ms 239 ms 239 ms
12 * * * *
13 128.121.54.72 (128.121.54.72) 259 ms 499 ms 279 ms
14 * * * *
15 * * * *
16 * * * *
17 * * * *
18 ALLSPICE.LCS.MIT.EDU (18.26.0.115) 339 ms 279 ms 279 ms

Tenga en cuenta que las pasarelas a 12, 14, 15, 16 y 17 saltos de distancia no envían mensajes ICMP «tiempo excedido» o los envían con un TTL demasiado pequeño para llegar a nosotros. Las líneas 14 a 17 ejecutan el código del MIT C Gateway que no envía mensajes de «tiempo excedido».

La pasarela silenciosa 12 en el ejemplo anterior puede ser el resultado de un error en el código de red 4.[23]BSD y sus derivados: Las máquinas que ejecutan código 4.3 y anteriores envían un mensaje inalcanzable utilizando cualquier TTL que permanezca en el datagrama original. Dado que, para las pasarelas, el TTL restante es cero, el «tiempo excedido» de ICMP está garantizado para no volver a nosotros. El comportamiento de este fallo es ligeramente más interesante cuando aparece en el sistema de destino:

1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms 0 ms
2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 19 ms 39 ms
3 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 ms 39 ms 19 ms 19 ms
4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 19 ms
5 ccn-nerif35.Berkeley.EDU (128.32.168.35) 39 ms 39 ms 39 ms 39 ms
6 csgw.Berkeley.EDU (128.32.133.254) 39 ms 59 ms 39 ms 39 ms
7 * * * *
8 * * * *
9 * * * *
10 * * * *
11 * * * *
12 * * * *
13 rip.Berkeley.EDU (128.32.131.22) 59 ms! 39 ms! 39 ms!

Observe que hay 12 «gateways» (13 es el destino final), y la última mitad de ellos no están. Lo que realmente está pasando es que el servidor llamado rip (un Sun-3 ejecutando Sun OS 3.5) está usando el TTL de nuestro datagrama de llegada como el TTL en su respuesta ICMP. Por lo tanto, la respuesta se agotará en la ruta de retorno (sin que se envíe un aviso a nadie, ya que las ICMPs no son enviadas para las ICMPs) hasta que sondeemos con un TTL que sea al menos el doble de la longitud de la ruta – en otras palabras, rip está realmente a sólo siete saltos de distancia.

Una respuesta que devuelve con un TTL de 1 es una pista de que este problema existe. Traceroute imprime un «! después del tiempo si el TTL es menor o igual a 1. Dado que los proveedores envían una gran cantidad de software obsoleto (DEC’s Ultrix, Sun 3.x) o no estándar (HPUX), espere ver este problema con frecuencia y tenga cuidado al elegir el host de destino de sus sondas.

Otras posibles anotaciones después de la hora son !H , !N , o !P (host, red o protocolo inalcanzable), !S (source route failed), !F- (fragmentación necesaria – se muestra el valor RFC1191 Path MTU Discovery), !X (comunicación prohibida administrativamente), !V (violación de precedencia del host), !C (corte de precedencia en efecto), o ! (código ICMP inalcanzable). Estos códigos están definidos por el RFC1812, que sustituye al RFC1716. Si casi todas las sondas resultan en algún tipo de host inalcanzable, el traceroute se rendirá y saldrá.

Este programa está diseñado para su uso en pruebas, mediciones y administración de redes. Se debe utilizar principalmente para el aislamiento manual de fallas. Debido a la carga que podría imponer en la red, no es aconsejable utilizar traceroute durante las operaciones normales o desde scripts automatizados.