IP : Protocolos de routing de IP

Uso del comando traceroute en sistemas operativos

7 Septiembre 2014 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (12 Agosto 2014) | Comentarios


Contenido


Introducción

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

prerrequisitos

Requisitos

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

  • Cisco IOS Software

  • Linux

  • Microsoft Windows

Componentes Utilizados

La información en este documento se aplica a estas versiones de software y hardware:

  • Router Cisco que funciona con el Cisco IOS Software Release 12.2(27)

  • PC que funcionamientos Red Hat Linux versión 9

  • PC que dirige MS Windows 2000

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 la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte las Convenciones de Consejos Técnicos de Cisco.

Funcionamiento general

Si usted ejecuta el comando traceroute ip-address en un dispositivo de origen (tal como un host, o un router que actúa como host), envía los paquetes IP hacia el destino con los valores del Time to Live (TTL) que incrementan hasta el conteo saltos especificado máximo. Éste es 30 por abandono. Típicamente, cada router en la trayectoria hacia el destino decrements el campo de TTL por una unidad mientras que él adelante estos paquetes. Cuando un router en el medio de la trayectoria encuentra un paquete con el TTL=1, responde con un mensaje tiempo excedido del Internet Control Message Protocol (ICMP) a la fuente. Este mensaje deja la fuente saber que el paquete atraviesa ese router determinado como salto

Hay algunas diferencias con la manera que implementan al comando traceroute en los diversos sistemas operativos este documento discute.

Cisco IOS y Linux

TTL para el sondeo del datagrama inicial del User Datagram Protocol (UDP) se fija a 1 (o a TTL mínimo, según lo especificado por el usuario en el comando extended traceroute. El puerto del destino UDP del sondeo del datagrama inicial se fija a 33434 (o como se especifica en el comando extended traceroute hecho salir). El comando extended traceroute es una variación del comando traceroute ordinario que permite los valores predeterminados de los parámetros usados por la operación del traceroute tal como TTL y número de puerto de destino que se modificarán. Para más información sobre cómo utilizar el comando extended traceroute, refiérase usando el ping extendido y los comandos extendedes traceroutes. El puerto de la fuente UDP del sondeo del datagrama inicial se selecciona al azar y tiene el operador lógico O con 0x8000 (asegura un puerto de origen mínimo de 0x8000). Estos pasos ilustran qué sucede cuando se inicia el datagrama de UDP:

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

  1. El datagrama de UDP se envía con el TTL=1, el port= 33434 del destino UDP, y el puerto de origen seleccionado al azar.

  2. Se incrementa el puerto de destino UDP, se selecciona al azar el puerto de la fuente UDP, y se envía el segundo datagrama.

  3. El paso 2 se relanza por hasta tres sondas (o tantas veces como se solicita en un comando extended traceroute hecho salir). Para cada uno de las sondas enviadas, usted recibe “TTL excedió” el mensaje, que se utiliza para construir una trayectoria gradual a la computadora principal de destino.

  4. Se incrementa TTL, y las repeticiones de este ciclo con los números de puerto de destino ampliados, si se recibe el mensaje tiempo excedido ICMP. Usted puede también conseguir uno de estos mensajes:

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

    • “Imposible acceder al host,” la “red inalcanzable,” “TTL máximo excedido,” o un tipo de mensaje del “descanso”, así que él significa que la sonda está vuelta a enviar.

Los routeres Cisco envían los paquetes de sondeo UDP con un puerto del origen aleatorio y un puerto destino ampliado (distinguir las diversas sondas). Los routeres Cisco envían el mensaje ICMP “tiempo excedido” de nuevo a la fuente de donde el paquete UDP/ICMP fue recibido.

El comando linux traceroute es similar a la implementación del router de Cisco. Sin embargo, utiliza un puerto de origen fijo. - La opción n en el comando traceroute se utiliza para evitar una petición a un Servidor de nombres.

Microsoft Windows

El comando tracert de MS Windows utiliza los datagramas de pedido de eco de ICMP en vez de los datagramas de UDP como sondas. Los pedidos de eco ICMP se inician con incrementar TTL, y la misma operación que descrito en el Cisco IOS y Linux ocurre. La significación de usar los datagramas de pedido de eco de ICMP es que el salto final no confía en la respuesta de un mensaje "inalcanzable" ICMP de la computadora principal de destino. Confía en lugar de otro en 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 de comando:

Parámetro Descripción
- d Especifica para no resolver los direccionamientos a los nombres de computadora.
- maximum_hops h Especifica el número máximo de saltos para buscar para una blanco.
- Computadora-lista j Especifica una Source ruta flexible a lo largo de la Computadora-lista.
- descanso w Espera el número de milisegundos especificados por el descanso cada contestación.
target_name Nombre de la computadora de destino.

Limitación de velocidad de ICMP inalcanzables

Los ICMP fuera de alcance se limitan a un paquete por el ms 500 (como protección para los ataques de la negación de servicio (DOS)) en un router Cisco. Del Cisco IOS Software Release 12.1 y Posterior, este valor de velocidad es configurable. El comando introducido es:


ip icmp rate-limit unreachable
 [DF] <1-4294967295 millisecond>
 
no ip icmp rate-limit unreachable [DF] (DF limits rate for code=4) 

Refiera al Id. de bug Cisco CSCdp28161 (clientes registrados solamente) para otros detalles.

Esta limitación está para la velocidad total de todos los ICMP fuera de alcance, pues esta salida muestra. Refiera al RFC 792leavingcisco.com para 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 los pedidos de eco ICMP o los mensajes tiempo excedido ICMP.

Ejemplos

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

/image/gif/paws/22826/traceroute-01.gif

En cada uno de los tres ejemplos, se utiliza un diverso dispositivo A. Del dispositivo A, el comando de 150.1.4.2 del traceroute se ejecuta al dispositivo 7C.

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

Router Cisco con el Cisco IOS Software

Este ejemplo del comando extended traceroute muestra las opciones que usted puede cambiar cuando usted ejecuta un comando traceroute de un router Cisco. En este ejemplo, todo se deja predeterminado:

rp-10c-2611#traceroute
Protocol [ip]: 
Target IP address: 150.1.4.2 
Source address: 150.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 150.1.4.2

1 150.1.1.2 4 msec 0 msec 4 msec
2 150.1.2.2 4 msec 4 msec 0 msec
3 150.1.3.2 0 msec 0 msec 4 msec
4 150.1.4.2 4 msec * 0 msec 


rp-11a-7204#
*Dec 29 13:13:57.060: IP: s=150.1.1.2 (local), d=150.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=150.1.1.2 (local), d=150.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=150.1.1.2 (local), d=150.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 13:13:57.068: ICMP type=11, code=0

En esta salida de los debugs, el dispositivo 11A envía los mensajes tiempo excedido ICMP a la fuente de las sondas (150.1.1.1). Estos mensajes ICMP están en respuesta a las sondas iniciales que tenían un TTL=1. El dispositivo 11A decrements TTL a cero, y responde con los mensajes tiempo excedido.

Nota:  Usted no ve las sondas UDP en esta salida de los debugs por dos razones:

  • El dispositivo 11A no es el destino de las sondas UDP.

  • TTL decremented a cero, y el paquete nunca se rutea. Por lo tanto, el debug nunca reconoce el paquete.

    *Dec 29 13:13:57.068: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
     g=150.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=150.1.2.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
     g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
     g=150.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=150.1.2.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
     g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
     g=150.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=150.1.2.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
     g=150.1.1.1, len 56, forward
    *Dec 29 13:13:57.076: ICMP type=11, code=0

Esta salida de los debugs muestra la sonda UDP de la fuente 150.1.1.1 destinada a 150.1.4.2.

Nota:  En estas sondas el TTL=2 (esto no se puede ver con el debug). El dispositivo 11A decrements TTL a 1 y adelante los paquetes UDP sobre el dispositivo 7A. El dispositivo 7A decrements TTL a cero, y responde con los mensajes tiempo excedido ICMP.

*Dec 29 13:13:57.080: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.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=150.1.3.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.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=150.1.3.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.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=150.1.3.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.1.1.1, len 56, forward
*Dec 29 13:13:57.088: ICMP type=11, code=0

Usted ve las tres sondas siguientes UDP en esta salida de los debugs. TTL para estas sondas es 3. que el dispositivo 11A decrements TTL a 2 y adelante los encendido al dispositivo 7A. El dispositivo 7A decrements TTL a 1 y adelante los paquetes encendido al dispositivo 7B, que decrements TTL a cero y responde con los mensajes tiempo excedido ICMP.

*Dec 29 13:13:57.088: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.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=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.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=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.1.1.1, len 56, forward
*Dec 29 13:14:00.092: ICMP type=3, code=3

Usted puede ver las tres sondas más recientes UDP de esta salida de los debugs. TTL original de estas sondas era 4. TTL decremented a 3 por el dispositivo 11A, después decremented a 2 por el dispositivo 7A, después decremented a 1 por el dispositivo 7B. El dispositivo 7C responde con el mensaje puerto inalcanzable ICMP, puesto que era el destino de las sondas.

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

PC con Linux

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


rp-11a-7204#
*Jan 2 07:17:27.894: IP: s=150.1.1.2 (local), d=150.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=150.1.1.2 (local), d=150.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=150.1.1.2 (local), d=150.1.1.1 (Ethernet4/0),
len 56, sending
*Jan 2 07:17:27.894: ICMP type=11, code=0

En esta salida de los debugs, el dispositivo 11A envía los mensajes tiempo excedido ICMP a la fuente de las sondas (150.1.1.1). Estos mensajes ICMP están en respuesta a las sondas iniciales que tenían un TTL=1. El dispositivo 11A decrements TTL a cero, y responde con los mensajes tiempo excedido.

Nota: Usted no ve las sondas UDP en esta salida de los debugs por dos razones:

  • El dispositivo 11A no es el destino de las sondas UDP.

  • TTL decremented a cero, y el paquete nunca se rutea. Por lo tanto, el debug nunca reconoce el paquete.

    *Jan 2 07:17:27.894: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),
     g=150.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=150.1.2.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),
     g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),
     g=150.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=150.1.2.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),
     g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),
     g=150.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=150.1.2.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),
     g=150.1.1.1, len 56, forward
    *Jan 2 07:17:27.902: ICMP type=11, code=0

Nota: En esta salida de los debugs, usted ahora ve la sonda UDP de la fuente 150.1.1.1 destinada a 150.1.4.2.

Nota: En estas sondas el TTL=2 (esto no se puede ver con el debug). El dispositivo 11A decrements TTL a 1 y adelante los paquetes UDP sobre el dispositivo 7A. El dispositivo 7A decrements TTL a cero, y responde con los mensajes tiempo excedido ICMP.

*Jan 2 07:17:27.902: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),
 g=150.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=150.1.3.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),
 g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),
 g=150.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=150.1.3.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),
 g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),
 g=150.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=150.1.3.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),
 g=150.1.1.1, len 56, forward
*Jan 2 07:17:27.910: ICMP type=11, code=0

Las tres sondas siguientes UDP ahora se consideran en esta salida de los debugs. TTL para estas sondas es 3. que el dispositivo 11A decrements TTL a 2 y adelante los encendido al dispositivo 7A. El dispositivo 7A decrements TTL a 1 y adelante los paquetes encendido al dispositivo 7B, que decrements TTL a cero y responde con los mensajes tiempo excedido ICMP.

*Jan 2 07:17:27.910: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),
 g=150.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=150.1.4.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),
 g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),
 g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2(FastEthernet0/0),
 g=150.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=150.1.4.2 (FastEthernet0/0), d=150.1.1.1(Ethernet4/0),
 g=150.1.1.1, len 56, forward
*Jan 2 07:17:32.914: ICMP type=3, code=3

Esta salida de los debugs muestra las tres sondas más recientes UDP. TTL original de estas sondas era 4. TTL decremented a 3 por el dispositivo 11A, después decremented a 2 por el dispositivo 7A, después decremented a 1 por el dispositivo 7B. El dispositivo 7C entonces responde con el mensaje puerto inalcanzable ICMP, puesto que era el destino de las sondas.

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

PC con MS Windows

C:\>tracert 150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.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=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.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=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.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=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.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=150.1.1.2 (local), d=150.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=150.1.1.2 (local), d=150.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=150.1.1.2 (local), d=150.1.1.1 (Ethernet4/0),
 len 56, sending
*Dec 29 14:02:26.752: ICMP type=11, code=0

En esta salida de los debugs, el dispositivo 11A envía los mensajes tiempo excedido ICMP a la fuente de las sondas (150.1.1.1). Estos mensajes ICMP están en respuesta a las sondas iniciales, que son paquetes de pedido de eco ICMP con un TTL=1. El dispositivo 11A decrements TTL a cero y responde con los mensajes ICMP.

Nota: En el top usted ve las peticiones del nombre de NETBIOS. Estas peticiones se consideran como paquetes UDP con los puertos de origen y de destino de 137. Para mayor clareza las razones, los paquetes NETBIOS se quitan del resto de la salida de los debugs. Usted puede utilizar - la opción d en el comando tracert de inhabilitar el comportamiento NETBIOS.

Nota: Usted no ve las sondas de ICMP en esta salida de los debugs por dos razones:

  • El dispositivo 11A no es el destino de las sondas de ICMP.

  • TTL decremented a cero, y el paquete nunca se rutea. Por lo tanto, el debug nunca reconoce el paquete.

    *Dec 29 14:02:32.256: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
     g=150.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=150.1.2.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
     g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
     g=150.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=150.1.2.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
     g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
     g=150.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=150.1.2.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
     g=150.1.1.1, len 56, forward
    *Dec 29 14:02:32.264: ICMP type=11, code=0

En esta salida de los debugs, usted ahora ve la sonda de ICMP de la fuente 150.1.1.1 destinada a 150.1.4.2.

Nota: En estas sondas, el TTL=2 (esto no se puede ver con el debug). El dispositivo 11A decrements TTL a 1 y adelante los paquetes UDP encendido al dispositivo 7A. El dispositivo 7A decrements TTL a cero, y responde con los mensajes tiempo excedido ICMP.

*Dec 29 14:02:37.776: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.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=150.1.3.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.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=150.1.3.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.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=150.1.3.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.1.1.1, len 56, forward
*Dec 29 14:02:37.784: ICMP type=11, code=0

Usted ve las tres sondas de ICMP siguientes en esta salida de los debugs. TTL para estas sondas es 3. que el dispositivo 11A decrements TTL a 2 y adelante los encendido al dispositivo 7A. El dispositivo 7A decrements TTL a 1 y adelante los paquetes encendido al dispositivo 7B, que decrements TTL a cero y responde con los mensajes tiempo excedido ICMP.

*Dec 29 14:02:43.292: IP: s=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.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=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.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=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.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=150.1.1.1 (Ethernet4/0), d=150.1.4.2 (FastEthernet0/0),
 g=150.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=150.1.4.2 (FastEthernet0/0), d=150.1.1.1 (Ethernet4/0),
 g=150.1.1.1, len 92, forward
*Dec 29 14:02:43.304: ICMP type=0, code=0

Esta salida de los debugs muestra las tres sondas de ICMP más recientes. TTL original de estas sondas era 4. TTL decremented a 3 por el dispositivo 11A, después decremented a 2 por el dispositivo 7A, después decremented a 1 por el dispositivo 7B. El dispositivo 7C entonces responde con los mensajes de respuesta de eco ICMP (type=0, code=0), puesto que era el destino de las sondas.

Nota: Los mensajes de respuesta de eco ICMP no son tarifa limitada como el mensaje puerto inalcanzable ICMP eran. En este caso, usted ve los tres mensajes de respuesta de eco ICMP enviados.

Notas complementarias

En los routeres Cisco, los códigos para una contestación del comando traceroute 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 usted funciona con el comando traceroute de UNIX, observe estos elementos:

  • Usted puede recibir el “traceroute: socket icmp: ” Mensajes negados permiso.

  • El programa Traceoute confía en el Network Interface Tap (NIT) al fisgón en la red. Este dispositivo es solamente accesible por la raíz. Usted debe o funcionar con el programa como raíz, o fije la identificación del usuario para la raíz.

Resumen

Este documento ha demostrado cómo el comando traceroute determina la trayectoria las tomas de un paquete de una fuente dada a un destino determinado con el uso del UDP y de los paquetes icmp. Los tipos posibles de mensajes ICMP en las salidas son:

  • Si el TTL se excede adentro transite, type=11, code=0, después el paquete es devuelto por el router de tránsito en todos los casos donde expira el TTL de los paquetes de sondeo antes de que los paquetes alcancen el destino.

  • Si el puerto es inalcanzable, type=3, code=3, después el paquete se devuelve en respuesta a los paquetes de sondeo UDP cuando alcanzan el destino (la aplicación UDP no se define). Estos paquetes se limitan a un paquete por el ms 500. Esto explica porqué la respuesta del destino (véase las salidas para el router Cisco y Linux) fallado en incluso las respuestas. El dispositivo 7C no genera el mensaje ICMP, y la salida del comando traceroute en las esperas de cada dispositivo para más que el segundo. En el caso de la salida del comando tracert de MS Windows, se genera el mensaje ICMP porque el puerto 137 UDP no existe en un router Cisco.

  • Si hay una generación de eco, type=8, code=0, después el paquete del sondeo de eco es enviado por MS Windows PC.

  • Si hay una Respuesta de eco, type=0, code=0, después una contestación al paquete anterior se envía cuando se alcanza el destino. Esto se aplica solamente al comando tracert de MS Windows.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 22826