Use el comando traceroute en sistemas operativos

Actualizado:16 de octubre de 2023
ID del documento:22826

Lenguaje no discriminatorio

El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.

Acerca de esta traducción

Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).

    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:

    note-icon

    Nota: Los parámetros son configurables. Este ejemplo comienza con n = 1 y termina con n = 3.

    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

    Eltracertcomando 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:

    Network TopologyTopologí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.

    note-icon

    Nota: Usted no ve los sondeos UDP en este resultado de depuración por dos motivos:

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

    note-icon

    Nota: En estos sondeos, TTL=2 (esto no se puede ver con la depuración). El dispositivo 11A disminuye el TTL a 1 y reenvía los paquetes UDP al dispositivo 7A. El dispositivo 7A reduce el TTL a cero y responde con mensajes de tiempo excedido ICMP.

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

    note-icon

    Nota: El dispositivo 7C solo envía dos mensajes de puerto ICMP inalcanzable debido a la limitación de velocidad.

    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
    note-icon

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

    note-icon

    Nota: En estos sondeos, TTL=2 (esto no se puede ver con la depuración). El dispositivo 11A disminuye el TTL a 1 y reenvía los paquetes UDP al dispositivo 7A. El dispositivo 7A reduce el TTL a cero y responde con mensajes de tiempo excedido ICMP.

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

    note-icon

    Nota: El dispositivo 7C sólo envía dos mensajes de puerto ICMP inalcanzable debido a la limitación de velocidad.

    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.

    note-icon

    Nota: En la parte superior, verá las solicitudes de nombre de NETBIOS. Estas solicitudes se consideran paquetes UDP con puertos de origen y destino de 137. Por motivos de claridad, los paquetes NETBIOS se eliminan del resto del resultado de la depuración. Puede utilizar la -d opción del tracert comando para desactivar el comportamiento de NETBIOS.

    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.

    note-icon

    Nota: En estos sondeos, el TTL=2 (esto no se puede ver con la depuración). El dispositivo 11A disminuye el TTL a 1 y reenvía los paquetes UDP al dispositivo 7A. El dispositivo 7A reduce el TTL a cero y responde con mensajes de tiempo excedido ICMP.

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

    note-icon

    Nota: Los mensajes de respuesta de eco ICMP no están limitados por velocidad, ya que los mensajes de puerto ICMP inalcanzable sí lo estaban. En este caso, verá los tres mensajes de respuesta de eco ICMP enviados.

    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

    Historial de revisiones

    Revisión Fecha de publicación Comentarios
    2.0
    16-Oct-2023
    Recertificación
    1.0
    11-Apr-2002
    Versión inicial
    TAC Authored

    Con la colaboración de ingenieros de Cisco

    ¿Resultó útil este documento?

    FeedbackComentarios

    Contacte a Cisco