Use el comando traceroute en sistemas operativos

Introducción

Este documento describe cómo funciona el traceroute comando en diferentes sistemas.

Prerequisites

Requirements

Los lectores de este documento deben tener conocimientos básicos de uno de estos sistemas operativos:

• Software Cisco IOS®

• Linux

• Microsoft Windows

Componentes Utilizados

La información de este documento aplica a las siguientes versiones de software y hardware:

• Router de Cisco que ejecuta la versión 12 del software Cisco IOS

• PC que ejecuta Red Hat Linux

• PC que ejecuta MS Windows 

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Convenciones

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Antecedentes

El traceroute comando le permite determinar la trayectoria que toma un paquete para llegar a un destino desde un origen determinado devolviendo la secuencia de saltos que el paquete ha atravesado. Esta utilidad viene con el sistema operativo del host (por ejemplo, Linux o Microsoft (MS) Windows), así como con el software Cisco IOS.

Funcionamiento general

Si ejecuta el traceroute ip-address en un dispositivo de origen (como un host o un router que actúa como un host), envía paquetes IP hacia el destino con valores de Tiempo de vida (TTL) que aumentan hasta el número máximo de saltos especificado. Es 30 de manera predeterminada. Por lo general, cada router en la ruta hacia el destino disminuye el campo TTL en una unidad mientras reenvía estos paquetes. Cuando un router en el medio de la ruta encuentra un paquete con TTL = 1, responde con el mensaje "Tiempo excedido" del Protocolo de mensajes de control de Internet (ICMP) al origen. Este mensaje informa al origen que el paquete atraviesa ese router en particular como un salto

Existen algunas diferencias con la forma en que se implementa el traceroute comando en los diversos sistemas operativos que se describen en este documento.

Cisco IOS y Linux

El TTL para la sonda de datagrama UDP (Protocolo de datagramas de usuario) inicial se establece en 1 (o el TTL mínimo, según lo especificado por el usuario en el traceroute comando extendido. El puerto UDP de destino de la sonda de datagrama inicial se establece en 33434 (o como se especifica en el resultado del traceroute comando extendido). El comando extendido traceroute es una variación del comando ordinario traceroute que permite modificar los valores predeterminados de los parámetros utilizados por la traceroute operación como TTL y el número de puerto de destino. Para obtener más información sobre cómo utilizar el traceroute comando extended, consulte Comprensión de los Comandos Extended ping y Extended traceroute. El puerto UDP de origen del sondeo de datagramas inicial es aleatorio y tiene el operador lógico OR con 0x8000 (garantiza un puerto de origen mínimo de 0x8000). Estos pasos ilustran lo que sucede cuando se inicia el datagrama UDP:

1. El datagrama UDP se envía con TTL = 1, puerto UDP de destino = 33434 y el puerto de origen es aleatorio.

2. Se incrementa el puerto de destino UDP, se aleatoriza el puerto UDP de origen y se envía el segundo datagrama.

3. El paso 2 se repite hasta para tres sondeos (o tantas veces como se solicite en un resultado de traceroute comando extendido). Para cada una de los sondeos enviados, recibirá un mensaje de "TTL excedido", que se utiliza para crear una ruta paso a paso hacia el host de destino.

4. El TTL se incrementa y este ciclo se repite con los números de puerto de destino incrementales, si se recibe el mensaje ICMP time exceeded. También puede obtener uno de estos mensajes:

   • Un mensaje ICMP tipo 3, código 3 (destino inalcanzable, puerto inalcanzable), que indica que se ha alcanzado un host.

   • Un host inalcanzable, net inalcanzable, se excedió el TTL máximo o un tipo de mensaje de tiempo de espera, lo que significa que la sonda está reenviada.

Los routers Cisco envían paquetes de sondeos UDP con un puerto de origen aleatorio y un puerto de destino incremental (para distinguir las diferentes sondas). Los routers de Cisco envían el tiempo de mensaje ICMP excedido de vuelta al origen desde donde se recibió el paquete UDP/ICMP.

El comando Linux traceroute es similar a la implementación del router de Cisco. Sin embargo, utiliza un puerto de origen fijo. -n en el traceroute comando se utiliza para evitar una solicitud a un servidor de nombres.

Microsoft Windows

El tracert   comando MS Windows utiliza datagramas de solicitud de eco ICMP en lugar de datagramas UDP como sondeos. Las solicitudes de eco ICMP se inician con TTL incremental y se produce la misma operación que se describe en Cisco IOS y Linux. La importancia de utilizar datagramas de solicitud de eco ICMP es que el salto final no depende de la respuesta de un mensaje de ICMP inalcanzable del host de destino. En cambio, depende de un mensaje de respuesta de eco ICMP.

La sintaxis del comando es la siguiente:

tracert [-d] [-h maximum_hops] [-j computer-list] [-w timeout] target_name

Esta tabla explica los parámetros del comando:

Parámetro	Descripción
-d	Especifica que no se resuelvan direcciones a nombres de PC.
-h maximum_hops	Especifica la cantidad máxima de saltos para buscar un objetivo.
-j computer-list	Especifica una ruta de origen flexible a lo largo de la lista de la PC.
-w timeout	Espera la cantidad de milisegundos especificada por el tiempo de espera para cada respuesta.
target_name	Nombre de la PC de destino.

Limitación de velocidad de ICMP inalcanzables

Los ICRE inalcanzables se limitan a un paquete por cada 500 ms (como protección para ataques de denegación de servicio (DoS) en un router Cisco. Desde la versión de software Cisco IOS 12.1 y posteriores, este valor de velocidad es configurable. El comando introducido es:

Router(config)#ip icmp rate-limit unreachable ?
  <1-4294967295>  Once per milliseconds
  DF              code 4, fragmentation needed and DF set

Esta limitación es para la velocidad agregada de todos los ICMP inalcanzables, como se muestra en este resultado. Consulte RFC 792 para obtener más información.

type = 3, code 
0 = net unreachable; 
1 = host unreachable; 
2 = protocol unreachable; 
3 = port unreachable; 
4 = fragmentation needed and DF set; 
5 = source route failed.

Esta limitación no afecta a otros paquetes como las solicitudes de eco ICMP o los mensajes de tiempo excedido ICMP.

Examples

Esta topología de red se utiliza para los ejemplos:

Topología de red

En cada uno de los tres ejemplos, se utiliza un dispositivo A diferente. Desde el Dispositivo A, el traceroute 10.1.4.2 comando se ejecuta en el Dispositivo 7C.

En cada uno de los ejemplos, el debug ip packet detail se ejecuta en el dispositivo 11A.

Router Cisco con software Cisco IOS

Este ejemplo de traceroute comando extendido muestra las opciones que puede cambiar cuando ejecuta un traceroute comando desde un router Cisco. En este ejemplo, todo queda predeterminado:

rp-10c-2611#traceroute
Protocol [ip]: 
Target IP address: 10.1.4.2 
Source address: 10.1.1.1 
Numeric display [n]: 
Timeout in seconds [3]: 
Probe count [3]: 
Minimum Time to Live [1]: 
Maximum Time to Live [30]: 
Port Number [33434]: 
Loose, Strict, Record, Timestamp, Verbose[none]: 
Type escape sequence to abort.
Tracing the route to 10.1.4.2

1 10.1.1.2 4 msec 0 msec 4 msec
2 10.1.2.2 4 msec 4 msec 0 msec
3 10.1.3.2 0 msec 0 msec 4 msec
4 10.1.4.2 4 msec * 0 msec 


rp-11a-7204#
*Dec 29 13:13:57.060: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 13:13:57.060: ICMP type=11, code=0
*Dec 29 13:13:57.064: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 13:13:57.064: ICMP type=11, code=0
*Dec 29 13:13:57.064: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 13:13:57.068: ICMP type=11, code=0

En esta salida de depuración, el dispositivo 11A envía mensajes de tiempo excedido ICMP al origen de los sondeos (10.1.1.1). Estos mensajes de ICMP responden a los sondeos iniciales que tenían un TTL=1. El dispositivo 11A reduce el TTL a cero y responde con los mensajes de tiempo excedido.

• El dispositivo 11A no es el destino de los sondeos UDP.

• El TTL se reduce a cero y el paquete nunca se enruta. Por lo tanto, la depuración nunca reconoce el paquete.

  *Dec 29 13:13:57.068: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
   g=10.1.2.2, len 28, forward
  *Dec 29 13:13:57.068: UDP src=40309, dst=33437
  *Dec 29 13:13:57.068: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
   g=10.1.1.1, len 56, forward
  *Dec 29 13:13:57.068: ICMP type=11, code=0
  *Dec 29 13:13:57.072: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
   g=10.1.2.2, len 28, forward
  *Dec 29 13:13:57.072: UDP src=37277, dst=33438
  *Dec 29 13:13:57.072: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
   g=10.1.1.1, len 56, forward
  *Dec 29 13:13:57.072: ICMP type=11, code=0
  *Dec 29 13:13:57.076: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
   g=10.1.2.2, len 28, forward
  *Dec 29 13:13:57.076: UDP src=36884, dst=33439
  *Dec 29 13:13:57.076: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
   g=10.1.1.1, len 56, forward
  *Dec 29 13:13:57.076: ICMP type=11, code=0

Este resultado de depuración muestra el sondeo UDP de origen 10.1.1.1 destinado a 10.1.4.2.

*Dec 29 13:13:57.080: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.080: UDP src=37479, dst=33440
*Dec 29 13:13:57.080: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 13:13:57.080: ICMP type=11, code=0
*Dec 29 13:13:57.084: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.084: UDP src=40631, dst=33441
*Dec 29 13:13:57.084: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 13:13:57.084: ICMP type=11, code=0
*Dec 29 13:13:57.084: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.088: UDP src=39881, dst=33442
*Dec 29 13:13:57.088: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 13:13:57.088: ICMP type=11, code=0

Verá los siguientes tres sondeos UDP en este resultado de depuración. El TTL para estos sondeos es 3. El dispositivo 11A disminuye el TTL a 2 y los reenvía al dispositivo 7A. El dispositivo 7A reduce el TTL a 1 y reenvía los paquetes al dispositivo 7B, lo que reduce el TTL a cero y responde con mensajes de tiempo excedido ICMP.

*Dec 29 13:13:57.088: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.088: UDP src=39217, dst=33443
*Dec 29 13:13:57.092: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 13:13:57.092: ICMP type=3, code=3
*Dec 29 13:13:57.092: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 28, forward
*Dec 29 13:13:57.096: UDP src=34357, dst=33444
*Dec 29 13:14:00.092: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 28, forward
*Dec 29 13:14:00.092: UDP src=39587, dst=33445
*Dec 29 13:14:00.092: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 13:14:00.092: ICMP type=3, code=3

Puede ver los últimos tres sondeos UDP en este resultado de depuración. El TTL original de estos sondeos era 4. El TTL se redujo a 3 por el dispositivo 11A, luego se redujo a 2 por el dispositivo 7A, y luego se redujo a 1 por el dispositivo 7B. El dispositivo 7C responde con mensajes de puerto ICMP inalcanzable, ya que era el destino de los sondeos.

PC con Linux

[root#linux-pc]#traceroute -n 10.1.4.2
traceroute to 10.1.4.2 (10.1.4.2), 30 hops max, 40 byte packets
1. 10.1.1.2 1.140 ms 0.793 ms 0.778 ms
2. 10.1.2.2 2.213 ms 2.105 ms 3.491 ms
1. 10.1.3.2 3.146 ms 2.314 ms 2.347 ms
1. 10.1.4.2 3.579 ms * 2.954 ms 


rp-11a-7204#
*Jan 2 07:17:27.894: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
len 56, sending
*Jan 2 07:17:27.894: ICMP type=11, code=0
*Jan 2 07:17:27.894: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
len 56, sending
*Jan 2 07:17:27.894: ICMP type=11, code=0
*Jan 2 07:17:27.894: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
len 56, sending
*Jan 2 07:17:27.894: ICMP type=11, code=0

En esta salida de depuración, el dispositivo 11A envía mensajes de tiempo excedido ICMP al origen de los sondeos (10.1.1.1). Estos mensajes de ICMP responden a los sondeos iniciales que tenían un TTL=1. El dispositivo 11A reduce el TTL a cero y responde con los mensajes de tiempo excedido.

No ve los sondeos UDP en esta salida de depuración por dos razones:

1. El dispositivo 11A no es el destino de los sondeos UDP.

2. El TTL se reduce a cero y el paquete nunca se enruta. Por lo tanto, la depuración nunca reconoce el paquete.

*Jan 2 07:17:27.894: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.894: UDP src=33302, dst=33438
*Jan 2 07:17:27.898: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.898: ICMP type=11, code=0
*Jan 2 07:17:27.898: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.898: UDP src=33302, dst=33439
*Jan 2 07:17:27.898: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.898: ICMP type=11, code=0
*Jan 2 07:17:27.898: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.898: UDP src=33302, dst=33440
*Jan 2 07:17:27.902: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.902: ICMP type=11, code=0

*Jan 2 07:17:27.902: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.902: UDP src=33302, dst=33441
*Jan 2 07:17:27.906: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.906: ICMP type=11, code=0
*Jan 2 07:17:27.906: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.906: UDP src=33302, dst=33442
*Jan 2 07:17:27.910: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.910: ICMP type=11, code=0
*Jan 2 07:17:27.910: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.910: UDP src=33302, dst=33443
*Jan 2 07:17:27.910: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.910: ICMP type=11, code=0

Los siguientes tres sondeos UDP ahora se ven en este resultado de depuración. El TTL para estos sondeos es 3. El dispositivo 11A disminuye el TTL a 2 y los reenvía al dispositivo 7A. El dispositivo 7A reduce el TTL a 1 y reenvía los paquetes al dispositivo 7B, lo que reduce el TTL a cero y responde con mensajes de tiempo excedido ICMP.

*Jan 2 07:17:27.910: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.910: UDP src=33302, dst=33444
*Jan 2 07:17:27.914: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Jan 2 07:17:27.914: ICMP type=3, code=3
*Jan 2 07:17:27.914: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:27.914: UDP src=33302, dst=33445
*Jan 2 07:17:32.910: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2(FastEthernet0/0),
 g=10.1.2.2, len 40, forward
*Jan 2 07:17:32.910: UDP src=33302, dst=33446
*Jan 2 07:17:32.914: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1(Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Jan 2 07:17:32.914: ICMP type=3, code=3

Este resultado de depuración muestra los últimos tres sondeos UDP. El TTL original de estos sondeos era 4. El TTL se redujo a 3 por el dispositivo 11A, luego se redujo a 2 por el dispositivo 7A, y luego se redujo a 1 por el dispositivo 7B.

El dispositivo 7C responde entonces con mensajes de puerto ICMP inalcanzable, ya que era el destino de los sondeos.

PC con MS Windows

C:\>tracert 10.1.4.2 

1 <10 ms <10 ms <10 ms 10.1.1.2
1 <10 ms <10 ms <10 ms 10.1.2.2
1 <10 ms <10 ms <10 ms 10.1.3.2
1 <10 ms 10 ms 10 ms 10.1.4.2

Trace complete

rp-11a-7204#
*Dec 29 14:02:22.236: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 78, forward
*Dec 29 14:02:22.236: UDP src=137, dst=137
*Dec 29 14:02:22.240: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:22.240: ICMP type=3, code=3
*Dec 29 14:02:23.732: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 78, forward
*Dec 29 14:02:23.732: UDP src=137, dst=137
*Dec 29 14:02:23.736: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:23.736: ICMP type=3, code=3
*Dec 29 14:02:25.236: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 78, forward
*Dec 29 14:02:25.236: UDP src=137, dst=137
*Dec 29 14:02:25.236: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:25.240: ICMP type=3, code=3
*Dec 29 14:02:26.748: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 14:02:26.748: ICMP type=11, code=0
*Dec 29 14:02:26.752: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 14:02:26.752: ICMP type=11, code=0
*Dec 29 14:02:26.752: IP: s=10.1.1.2 (local), d=10.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 14:02:26.752: ICMP type=11, code=0

En esta salida de depuración, el dispositivo 11A envía mensajes de tiempo excedido ICMP al origen de los sondeos (10.1.1.1). Estos mensajes de ICMP responden a los sondeos iniciales que representan paquetes de solicitud de eco ICMP con un TTL=1. El dispositivo 11A disminuye el TTL a cero y responde con los mensajes ICMP.

No ve los sondeos ICMP en esta salida de depuración por dos razones:

1. El dispositivo 11A no es el destino de los sondeos ICMP.

2. El TTL se reduce a cero y el paquete nunca se enruta. Por lo tanto, la depuración nunca reconoce el paquete.

*Dec 29 14:02:32.256: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:32.256: ICMP type=8, code=0
*Dec 29 14:02:32.260: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:32.260: ICMP type=11, code=0
*Dec 29 14:02:32.260: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:32.260: ICMP type=8, code=0
*Dec 29 14:02:32.260: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:32.260: ICMP type=11, code=0
*Dec 29 14:02:32.264: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:32.264: ICMP type=8, code=0
*Dec 29 14:02:32.264: IP: s=10.1.2.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:32.264: ICMP type=11, code=0

En este resultado de depuración, ahora verá el sondeo ICMP de origen 10.1.1.1 destinado a 10.1.4.2.

*Dec 29 14:02:37.776: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:37.776: ICMP type=8, code=0
*Dec 29 14:02:37.776: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:37.776: ICMP type=11, code=0
*Dec 29 14:02:37.780: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:37.780: ICMP type=8, code=0
*Dec 29 14:02:37.780: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:37.780: ICMP type=11, code=0
*Dec 29 14:02:37.780: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:37.780: ICMP type=8, code=0
*Dec 29 14:02:37.784: IP: s=10.1.3.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 56, forward
*Dec 29 14:02:37.784: ICMP type=11, code=0

Verá los siguientes tres sondeos ICMP en este resultado de depuración. El TTL para estos sondeos es 3. El dispositivo 11A disminuye el TTL a 2 y los reenvía al dispositivo 7A. El dispositivo 7A reduce el TTL a 1 y reenvía los paquetes al dispositivo 7B, lo que reduce el TTL a cero y responde con mensajes de tiempo excedido ICMP.

*Dec 29 14:02:43.292: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:43.292: ICMP type=8, code=0
*Dec 29 14:02:43.296: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 92, forward
*Dec 29 14:02:43.296: ICMP type=0, code=0
*Dec 29 14:02:43.296: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:43.296: ICMP type=8, code=0
*Dec 29 14:02:43.300: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 92, forward
*Dec 29 14:02:43.300: ICMP type=0, code=0
*Dec 29 14:02:43.300: IP: s=10.1.1.1 (Ethernet4/0), d=10.1.4.2 (FastEthernet0/0),
 g=10.1.2.2, len 92, forward
*Dec 29 14:02:43.300: ICMP type=8, code=0
*Dec 29 14:02:43.304: IP: s=10.1.4.2 (FastEthernet0/0), d=10.1.1.1 (Ethernet4/0),
 g=10.1.1.1, len 92, forward
*Dec 29 14:02:43.304: ICMP type=0, code=0

Este resultado de depuración muestra los últimos tres sondeos ICMP. El TTL original de estos sondeos era 4. El TTL se redujo a 3 por el dispositivo 11A, luego se redujo a 2 por el dispositivo 7A, y luego se redujo a 1 por el dispositivo 7B. El dispositivo 7C luego responde con mensajes de respuesta de eco de ICMP (tipo=0, código=0), ya que era el destino de los sondeos.

Notas complementarias

En los routers de Cisco, los códigos para una traceroute respuesta de comando son:

! -- success
* -- time out
N -- network unreachable
H -- host unreachable
P -- protocol unreachable
A -- admin denied
Q -- source quench received (congestion)
? -- unknown (any other ICMP message)

Si ejecuta el traceroute comando desde UNIX, tenga en cuenta estos elementos:

• Puede recibir traceroute: icmp socket: Permission denied mensajes.

• El traceroute programa se basa en Network Interface Tap (NIT) para buscar en la red. Este dispositivo solo es accesible desde la raíz. Debe ejecutar el programa como raíz o establecer el ID de usuario para la raíz.

Summary

Este documento ha demostrado cómo el traceroute comando determina la trayectoria que un paquete toma de un origen determinado a un destino determinado con el uso de paquetes UDP e ICMP. Los tipos posibles de mensajes ICMP en las salidas son:

• Si se supera el TTL en tránsito, tipo=11, código=0, el router de tránsito devuelve el paquete en todos los casos en los que el TTL de los paquetes del sondeo caduca antes de que lleguen al destino.

• Si el puerto es inalcanzable, tipo=3, código=3, entonces el paquete se devuelve en respuesta a los paquetes de sondeo UDP cuando llegan al destino (la aplicación UDP no está definida). Estos paquetes están limitados a un paquete por cada 500 ms. Esto explica por qué la respuesta del destino (consulte las salidas para el router Cisco y Linux) falló en las respuestas pares. El dispositivo 7C no genera el mensaje ICMP y el traceroute La salida del comando en cada dispositivo espera más de un segundo. En el caso de MS Windows tracert , el mensaje ICMP se genera porque el puerto UDP 137 no existe en un router Cisco.

• Si hay un eco, tipo=8, código=0, la PC de MS Windows envía el paquete de sondeo de eco.

• Si hay una respuesta de eco, tipo=0, código=0, se envía una respuesta al paquete anterior cuando se llega al destino. Esto solo se aplica a MS Windows tracert comando.

Información Relacionada

• Soporte técnico y descargas de Cisco