Usando o comando traceroute nos sistemas operacionais

Opções de download

PDF (175.9 KB)
Ver no Adobe Reader em vários dispositivos
ePub (93.6 KB)
Ver em vários aplicativos no iPhone, iPad, Android, Sony Reader ou Windows Phone
Mobi (Kindle) (107.9 KB)
Ver no dispositivo Kindle ou no aplicativo Kindle em vários dispositivos

Atualizado:10 de Agosto de 2005

ID do documento:22826

Linguagem imparcial

O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.

Sobre esta tradução

A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.

Introduction

Prerequisites

Requirements

Componentes Utilizados

Conventions

Operação geral

Cisco IOS e Linux

Microsoft Windows

Limitação da taxa de mensagens que não chegam ao seu destino do ICMP

Examples

Roteador Cisco com software Cisco IOS

PC com Linux

PC com MS Windows

Notas adicionais

Summary

Informações Relacionadas

Introduction

O comando traceroute permite que você determine o caminho que um pacote toma apara chegar a um destino de uma determinada origem, retornando a sequência de saltos que o pacote atravessou. Este utilitário vem com o sistema operacional de host, por exemplo: Linux ou Microsoft (MS) Windows, assim como com o Cisco IOS® Software.

Prerequisites

Requirements

Os leitores deste documento devem ter conhecimento básico de um destes sistemas operacionais:

Cisco IOS Software
Linux
Microsoft Windows

Componentes Utilizados

As informações neste documento se aplicam a estas versões de software e hardware:

Roteador Cisco que executa o Software Cisco IOS versão 12.2(27)
PC com Red Hat Linux versão 9
PC com MS Windows 2000

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

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

Operação geral

Se você executar o comando traceroute ip-address em um dispositivo de origem (como um host, ou um roteador atuando como um host), ele enviará pacotes IP para o destino com valores Time To Live (TTL) que aumentam até a contagem máxima de saltos especificada. Por padrão, é 30. Normalmente, cada roteador no caminho para o destino diminui o campo TTL em uma unidade enquanto encaminha esses pacotes. Quando um roteador no meio do caminho encontra um pacote com TTL = 1, ele responde com uma mensagem de "tempo excedido" do Internet Control Message Protocol (ICMP) para a origem. Essa mensagem permite que a origem saiba que o pacote atravessa aquele roteador específico como um salto

Há algumas diferenças na maneira como o comando traceroute é implementado nos vários sistemas operacionais discutidos neste documento.

Cisco IOS e Linux

O TTL para a prova inicial de datagrama do User Datagram Protocol (UDP) é definido como 1 (ou o TTL mínimo, conforme especificado pelo usuário no comando extended traceroute. A porta UDP de destino da prova de datagrama inicial é definida como 33434 (ou como especificado na saída do comando extended traceroute). O comando traceroute estendido é uma variação do comando traceroute comum que permite modificar os valores padrão dos parâmetros usados pela operação traceroute, como TTL e número de porta de destino. Para obter mais informações sobre como usar o comando extended traceroute, consulte Usando os Comandos Extended ping e Extended traceroute. A porta UDP de origem da prova de datagrama inicial é randomizada e tem operador lógico OU com 0x8000 (garante uma porta de origem mínima de 0x8000). Estes passos ilustram o que acontece quando o datagrama UDP é iniciado:

Observação: os parâmetros são configuráveis. Este exemplo começa com n = 1 e termina com n = 3.

O datagrama UDP é despachado com TTL = 1, porta UDP de destino= 33434 e porta de origem aleatória.
A porta de destino UDP é incrementada, a porta UDP de origem é randomizada e o segundo datagrama é enviado.
A etapa 2 é repetida para até três testadores (ou tantas vezes como solicitado em uma saída estendida do comando traceroute). Para cada um dos testadores enviados, você recebe uma mensagem "TTL excedido", usada para criar um caminho passo a passo para o host de destino.
O TTL é incrementado e esse ciclo se repete com números de porta de destino incrementais, se a mensagem ICMP de "tempo excedido" for recebida. Você também pode receber uma destas mensagens:
- Uma mensagem ICMP tipo 3, código 3 ("destino inalcançável", "porta inalcançável"), que indica que um host foi alcançado.
- Um "host inalcançável", "net inalcançável", "TTL máximo excedido" ou um tipo de mensagem de "timeout", o que significa que a sonda está sendo enviada novamente.

Os roteadores Cisco enviam pacotes de prova UDP com uma porta de origem aleatória e uma porta de destino incremental (para distinguir os diferentes testadores). Os roteadores Cisco enviam a mensagem ICMP "time excedido" de volta à origem de onde o pacote UDP/ICMP foi recebido.

O traceroute do Linux é semelhante à implementação do roteador Cisco. No entanto, ele usa uma porta de origem fixa. A opção -n do comando traceroute é usada para evitar uma solicitação a um servidor de nome.

Microsoft Windows

O comando MS Windows tracert usa datagramas ICMP echo request em vez de datagramas UDP como sondas. As solicitações de eco ICMP são iniciadas com TTL incrementado e a mesma operação descrita no Cisco IOS e no Linux ocorre. O significado do uso de datagramas de solicitação de eco ICMP é que o salto final não depende da resposta de uma mensagem ICMP "inalcançável" do host de destino. Ele se baseia em uma mensagem de resposta de eco ICMP.

A sintaxe do comando é:

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

Esta tabela explica os parâmetros do comando:

Parâmetro	Descrição
-d	Especifica não resolver endereços para nomes de computador.
-h maximum_hops	Especifica o número máximo de saltos para procurar um destino.
-j lista de computadores	Especifica uma rota de origem livre ao longo de uma lista de computadores.
-w timeout	Aguarda o número de milissegundos especificados pelo tempo limite para cada resposta.
nome_alvo	Nome do computador de destino.

Limitação da taxa de mensagens que não chegam ao seu destino do ICMP

Os inalcançáveis ICMP são limitados a um pacote por 500 ms (como proteção para ataques de negação de serviço (DoS) em um roteador Cisco. No Cisco IOS Software Release 12.1 e Mais Recente, esse valor de taxa é configurável. O comando introduzido é:


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

Consulte o bug da Cisco ID CSCdp28161 (somente clientes registrados) para obter mais detalhes.

Essa limitação é para a taxa agregada de todos os ICMP inalcançáveis, como mostrado nesta saída. Consulte o RFC 792 para obter mais informações.

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.

Essa limitação não afeta outros pacotes, como solicitações de eco ICMP ou mensagens de "tempo excedido" ICMP.

Examples

Essa topologia de rede é usada para os exemplos:

Em cada um dos três exemplos, um dispositivo A diferente é usado. No dispositivo A, o comando traceroute 150.1.4.2 é executado no dispositivo 7C.

Em cada um dos exemplos, o comando debug ip packet detail é executado no dispositivo 11A.

Roteador Cisco com software Cisco IOS

Este exemplo de comando traceroute estendido mostra as opções que você pode alterar ao executar um comando traceroute de um roteador Cisco. Neste exemplo, tudo é deixado como padrão:

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

Nesta saída de depuração, o dispositivo 11A envia mensagens ICMP de "tempo excedido" à origem dos testadores (150.1.1.1). Essas mensagens ICMP estão em resposta aos testes iniciais que tinham um TTL=1. O dispositivo 11A diminui o TTL para zero e responde com as mensagens de "tempo excedido".

Observação: você não vê os testadores UDP nesta saída de depuração por dois motivos:

O dispositivo 11A não é o destino dos testadores UDP.

O TTL é reduzido para zero e o pacote nunca é roteado. Portanto, a depuração nunca reconhece o pacote.

*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 saída de depuração mostra a prova UDP da origem 150.1.1.1 destinada a 150.1.4.2.

Observação: nesses testes, o TTL=2 (isso não pode ser visto com debug). O dispositivo 11A diminui o TTL para 1 e encaminha os pacotes UDP para o dispositivo 7A. O dispositivo 7A diminui o TTL para zero e responde com mensagens ICMP de "tempo excedido".

*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

Você verá os próximos três testadores UDP nesta saída de depuração. O TTL para essas sondas é 3. O dispositivo 11A diminui o TTL para 2 e o encaminha para o dispositivo 7A. O dispositivo 7A diminui o TTL para 1 e encaminha os pacotes para o dispositivo 7B, que diminui o TTL para zero e responde com mensagens ICMP de "tempo excedido".

*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

Você pode ver os últimos três testadores UDP nesta saída de depuração. O TTL original dessas sondas era 4. O TTL foi decrementado para 3 pelo dispositivo 11A, depois decrementado para 2 pelo dispositivo 7A e depois decrementado para 1 pelo dispositivo 7B. O dispositivo 7C responde com mensagens ICMP "port unreachable", já que era o destino dos testadores.

Observação: o dispositivo 7C envia apenas duas mensagens ICMP "port unreachable" devido à limitação de taxa.

PC com 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

Observação: você não vê os testadores UDP nesta saída de depuração por dois motivos:

O dispositivo 11A não é o destino dos testadores UDP.

O TTL é reduzido para zero e o pacote nunca é roteado. Portanto, a depuração nunca reconhece o pacote.

*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

Observação: nesta saída de depuração, você agora vê a prova UDP da origem 150.1.1.1 destinada a 150.1.4.2.

*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

Os próximos três testadores UDP são vistos agora nesta saída de depuração. O TTL para essas sondas é 3. O dispositivo 11A diminui o TTL para 2 e o encaminha para o dispositivo 7A. O dispositivo 7A diminui o TTL para 1 e encaminha os pacotes para o dispositivo 7B, que diminui o TTL para zero e responde com mensagens ICMP de "tempo excedido".

*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 saída de depuração mostra os últimos três testadores UDP. O TTL original dessas sondas era 4. O TTL foi decrementado para 3 pelo dispositivo 11A, depois decrementado para 2 pelo dispositivo 7A e depois decrementado para 1 pelo dispositivo 7B. O dispositivo 7C, então, responde com mensagens ICMP "port unreachable", já que era o destino dos testadores.

Observação: o dispositivo 7C envia apenas duas mensagens ICMP "port unreachable" devido ao limite de taxa.

PC com 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

Nesta saída de depuração, o dispositivo 11A envia mensagens ICMP de "tempo excedido" à origem dos testadores (150.1.1.1). Essas mensagens ICMP estão em resposta aos testes iniciais, que são pacotes de solicitação de eco ICMP com um TTL=1. O dispositivo 11A diminui o TTL para zero e responde com as mensagens ICMP.

Observação: na parte superior, você vê as solicitações de nome NETBIOS. Essas solicitações são vistas como pacotes UDP com portas de origem e destino de 137. Por razões de clareza, os pacotes NETBIOS são removidos do restante da saída de depuração. Você pode usar a opção -d no comando tracert para desativar o comportamento do NETBIOS.

Observação: você não vê os testadores ICMP nesta saída de depuração por dois motivos:

O dispositivo 11A não é o destino dos testadores ICMP.

O TTL é reduzido para zero e o pacote nunca é roteado. Portanto, a depuração nunca reconhece o pacote.

*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

Nessa saída de depuração, você agora vê a prova ICMP da origem 150.1.1.1 destinada a 150.1.4.2.

*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

Você verá os próximos três testadores ICMP nesta saída de depuração. O TTL para essas sondas é 3. O dispositivo 11A diminui o TTL para 2 e o encaminha para o dispositivo 7A. O dispositivo 7A diminui o TTL para 1 e encaminha os pacotes para o dispositivo 7B, que diminui o TTL para zero e responde com mensagens ICMP de "tempo excedido".

*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 saída de depuração mostra as três últimas sondas ICMP. O TTL original dessas sondas era 4. O TTL foi decrementado para 3 pelo dispositivo 11A, depois decrementado para 2 pelo dispositivo 7A e depois decrementado para 1 pelo dispositivo 7B. O dispositivo 7C, então, responde com mensagens de resposta de eco ICMP (type=0, code=0), pois era o destino dos testadores.

Observação: as mensagens de resposta de eco ICMP não são limitadas por taxa, pois as mensagens ICMP "port unreachable" eram. Nesse caso, você verá as três mensagens de resposta de eco ICMP enviadas.

Notas adicionais

Nos roteadores Cisco, os códigos para uma resposta de comando traceroute são:

! -- 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)

Se você executar o comando traceroute do UNIX, observe estes itens:

Você pode receber "traceroute: soquete ICMP: Permissão negada".
O programa traceroute depende da Network Interface Tap (NIT) para rastrear na rede. Este dispositivo só pode ser acessado pela raiz. Você deve executar o programa como raiz ou definir a ID de usuário para raiz.

Summary

Este documento demonstrou como o comando traceroute determina o caminho que um pacote toma de uma determinada origem para um determinado destino com o uso de pacotes UDP e ICMP. Os possíveis tipos de mensagens ICMP nas saídas são:

Se o TTL for excedido em trânsito, digite=11, code=0, o pacote será enviado de volta pelo roteador de trânsito em todos os casos em que o TTL dos pacotes de sonda expira antes que os pacotes cheguem ao destino.
Se a porta estiver inalcançável, digite=3, code=3, o pacote será enviado de volta em resposta aos pacotes de prova UDP quando eles chegarem ao destino (a aplicação UDP não está definida). Esses pacotes são limitados a um pacote por 500 ms. Isso explica por que a resposta do destino (consulte as saídas para o roteador Cisco e Linux) falhou nas respostas pares. O dispositivo 7C não gera a mensagem ICMP e a saída do comando traceroute em cada dispositivo espera mais de um segundo. No caso da saída do comando tracert do MS Windows, a mensagem ICMP é gerada porque a porta 137 do UDP não existe em um roteador Cisco.
Se houver um eco, digite=8, code=0, o pacote de prova de eco será enviado pelo PC MS Windows.
Se houver uma resposta de eco, digite=0, code=0 e uma resposta para o pacote anterior será enviada quando o destino for alcançado. Isso se aplica somente ao comando tracert do MS Windows.

Informações Relacionadas

Suporte Técnico e Documentação - Cisco Systems

Histórico de revisões

Revisão	Data de publicação	Comentários
1.0	10-Aug-2005	Versão inicial

Usando o comando traceroute nos sistemas operacionais

Opções de download

Linguagem imparcial

Sobre esta tradução

Contents

Histórico de revisões

Este documento lhe foi útil?

Contate a Cisco

Este documento se refere a estes produtos