Mandato traceroute

El mandato traceroute está pensado para su uso en pruebas, medición y gestión de red.

Aunque el mandato ping confirma la accesibilidad de la red IP, no puede identificar y mejorar algunos problemas aislados. Tenga en cuenta la situación siguiente:

Cuando hay muchos saltos (por ejemplo, pasarelas o rutas) entre el sistema y el destino, y parece que hay un problema en algún lugar a lo largo del camino. El sistema de destino puede tener un problema, pero es necesario saber dónde se pierde realmente un paquete.
El mandato ping se cuelga y no le indica las razones de un paquete perdido.

El mandato traceroute puede informarle de dónde se encuentra el paquete y por qué se pierde la ruta. Si los paquetes deben pasar a través de direccionadores y enlaces, que pertenecen a y están gestionados por otras organizaciones o empresas, es difícil comprobar los direccionadores relacionados a través del mandato telnet. El mandato traceroute proporciona un rol suplementario al mandato ping.

Nota: El mandato traceroute debe utilizarse principalmente para el aislamiento manual de errores. Debido a la carga que impone en la red, no utilice el mandato traceroute durante las operaciones típicas o desde scripts automatizados.

Ejemplos de traceroute correctos

El mandato traceroute utiliza paquetes UDP y utiliza la función de informes de errores de ICMP. Envía un paquete UDP tres veces a cada pasarela o direccionador en el camino. Se inicia con la pasarela más cercana y amplía la búsqueda en un salto. Finalmente, la búsqueda llega al sistema de destino. En la salida, verá el nombre de pasarela, la dirección IP de la pasarela y tres tiempos de ida y vuelta para la pasarela. Vea el siguiente ejemplo:

# traceroute aix1
trying to get source for aix1
source should be 10.53.155.187
traceroute to aix1.austin.ibm.com (10.53.153.120) from 10.53.155.187 (10.53.155.187), 30 hops max
outgoing MTU = 1500
 1  10.111.154.1 (10.111.154.1)  5 ms  3 ms  2 ms
 2  aix1 (10.53.153.120)  5 ms  5 ms  5 ms

A continuación figura otro ejemplo:

# traceroute aix1
trying to get source for aix1
source should be 10.53.155.187
traceroute to aix1.austin.ibm.com (10.53.153.120) from 10.53.155.187 (10.53.155.187), 30 hops max
outgoing MTU = 1500
 1  10.111.154.1 (10.111.154.1)  10 ms  2 ms  3 ms
 2  aix1 (10.53.153.120)  8 ms  7 ms  5 ms

Después de que caducara la entrada ARP (protocolo de resolución de direcciones), se ha repetido el mismo mandato. Tenga en cuenta que el primer paquete en cada pasarela o destino ha tomado un tiempo de ida y vuelta más largo. Esto se debe a la sobrecarga causada por el ARP. Si una red de conmutación pública (WAN) está implicada en la ruta, el primer paquete consume mucha memoria debido a un establecimiento de conexión y puede provocar un tiempo de espera excedido. El tiempo de espera predeterminado para cada paquete es de 3 segundos. Puede cambiarlo con la opción -w.

Los primeros 10 ms se deben al ARP entre el sistema de origen (9.53.155.187) y la pasarela 9.111.154.1. El segundo 8 ms se debe al ARP entre la pasarela y el destino final (onda). En este caso, está utilizando DNS y cada vez que el mandato traceroute envía un paquete, se busca en el servidor DNS.

Ejemplos de traceroute fallidos

Para una ruta larga a su destino o rutas de red complejas, es posible que vea muchos problemas con el mandato traceroute. Debido a que hay muchas cosas que dependen de la implementación, la búsqueda del problema solo puede hacerle perder tiempo. Si todos los direccionadores o sistemas implicados están bajo su control, es posible que pueda investigar el problema por completo.

Problema de pasarela (direccionador)

En el ejemplo siguiente, los paquetes se enviaron desde el sistema 9.53.155.187. Hay dos sistemas de direccionador en el camino al puente. La capacidad de direccionamiento se ha eliminado intencionadamente del segundo sistema de direccionador estableciendo la opción ipforwarding del mandato no en 0. Vea el siguiente ejemplo:

# traceroute lamar
trying to get source for lamar
source should be 9.53.155.187
traceroute to lamar.austin.ibm.com (9.3.200.141) from 9.53.155.187 (9.53.155.187), 30 hops max
outgoing MTU = 1500
 1  9.111.154.1 (9.111.154.1)  12 ms  3 ms  2 ms
 2  9.111.154.1 (9.111.154.1)  3 ms !H *  6 ms !H

Si un mensaje de error ICMP, excluyendoTime ExceededyPort Unreachable, se recibe, se muestra de la siguiente manera:

!H: Host no accesible
!N: Red no accesible
!P: Protocolo no accesible
!S: La ruta origen ha fallado
!F: Fragmentación necesaria

Problema del sistema de destino

Cuando el sistema de destino no responde en un intervalo de tiempo de espera de 3 segundos, todas las consultas se sincronizan y los resultados se visualizan con un asterisco (*).

# traceroute chuys
trying to get source for chuys
source should be 9.53.155.187
traceroute to chuys.austin.ibm.com (9.53.155.188) from 9.53.155.187 (9.53.155.187), 30 hops max
outgoing MTU = 1500
 1  * * *
 2  * * *
 3  * * *
^C#

Si cree que el problema se debe a un enlace de comunicación, utilice un periodo de tiempo de espera más largo con el distintivo -w. Aunque es raro, es posible que se hayan utilizado todos los puertos consultados. Puede cambiar los puertos y volver a intentarlo.

Número de "saltos" a destino

Otro ejemplo de salida puede ser el siguiente:

# traceroute mysystem.university.edu (129.2.130.22)
traceroute to mysystem.university.edu (129.2.130.22), 30 hops max
1 helios.ee.lbl.gov (129.3.112.1) 0 ms 0 ms 0 ms
2 lilac-dmc.university.edu (129.2.216.1) 39 ms 19 ms 39 ms
3 lilac-dmc.university.edu (129.2.215.1) 19 ms 39 ms 19 ms
4 ccngw-ner-cc.university.edu (129.2.135.23) 39 ms 40 ms 19 ms
5 ccn-nerif35.university.edu (129.2.167.35) 39 ms 39 ms 39 ms
6 csgw/university.edu (129.2.132.254) 39 ms 59 ms 39 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 rip.university.EDU (129.2.130.22) 59 ms! 39 ms! 39 ms!