Contents

Introduction

Prerequisites

Requirements

Componentes Utilizados

Conventions

Comando traceroute normal

Comando traceroute de MPLS

Comando no mpls ip propagate-ttl

Informações Relacionadas

Introduction

Este documento explica a maneira que o comando traceroute funciona em um ambiente de Multiprotocol Label Switching (MPLS).

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

- Conhecimento básico de MPLS

Consulte FAQ do MPLS para iniciantes para obter mais informações.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

Conventions

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Comando traceroute normal

Esta seção descreve como um comando traditional traceroute funciona. Este diagrama mostra uma configuração de provedor de serviços em que Roteador 1 (R1) e Roteador 4 (R4) são roteadores Provider Edge (PE) e Roteador 2 (R2) e Roteador 3 (R3) são os roteadores Provider (P).

Este exemplo conduz a um traceroute para o loopback 14 do R4 a partir de R1. O R1 usa um datagrama do User Datagram Protocol (UDP) com um valor de porta de destino arbitrário superior a 32000. Se você selecionar um valor tão alto para o número da porta, ele garantirá que tal porta não exista no destinatário desejado. Ele coloca esse datagrama em um pacote IP.

Observação: neste documento, sempre que um pacote IP é mencionado, ele é um pacote IP que contém o datagrama UDP.

Esta é uma sequência de eventos para um comando traceroute normal:

1. O R1 envia o pacote IP com um endereço de destino de 14 e um TTL (Time to Live, tempo de vida) de 1 através de sua interface eth1.

2. O R2 recebe o pacote e observa que ele não é o destinatário pretendido e o TTL do pacote é 1. Ele descarta o pacote e envia uma mensagem ICMP (Internet Control Message Protocol) expirada de TTL para R1. O endereço de origem dessa mensagem ICMP é o endereço IP do R2 eth0 (o endereço da interface que recebeu o pacote original).

3. Ao receber a mensagem ICMP, R1 envia outro pacote IP destinado a 14 com um TTL de 2 através de sua interface eth1.

4. O R2 recebe o pacote e observa que ele não é o destinatário pretendido e que o destinatário pretendido pode ser alcançado através de R3. Diminui o TTL (de 2 para 1) e encaminha o pacote para R3. R3 recebe o pacote e vê que ele não é o destinatário pretendido. O TTL é 1. Ele descarta o pacote e envia uma mensagem ICMP expirada por TTL para R1 com seu endereço eth0 como endereço de origem.

5. R1 recebe a mensagem ICMP e envia outro pacote IP para 14 através de sua interface eth1 com um valor TTL de 3. No caminho, R2 e R3 decrementam o TTL e o transmitem para R4. O R4 recebe o pacote, verifica se esse é o destinatário pretendido e tenta se conectar ao valor de porta no datagrama UDP. R4 descobre que essa porta não existe e envia uma mensagem de erro inalcançável de porta ICMP para R1.

Como antes, o endereço origem dessa mensagem ICMP é eth0 de R4. O programa traceroute agora tem todas as mensagens de erro ICMP com os endereços de origem correspondentes e tem a rota completa para o destino.

Comando traceroute de MPLS

Considere esse mesmo cenário detalhado na seção Comando traceroute Normal, exceto que todos os roteadores, de R1 a R4, agora fazem a comutação de rótulo em vez de encaminhamento de IP. A configuração da base de teste é mostrada neste diagrama. Todas as interfaces mostradas na base de teste estão na rede 10.13.0.0.

Para os fins deste documento, suponha que:

- R1 usa um rótulo de 47 para acessar R4 e encaminha pacotes para R2.

- R2 usa um rótulo de 45 para acessar R4 e encaminha pacotes para R3.

- R3 exibe o rótulo e encaminha o pacote para R4.

- O R4 utiliza um rótulo de 28 para alcançar o R1 e encaminha pacotes para o R3.

- R3 usa um rótulo de 26 para acessar R1 e encaminha pacotes para R2.

- R2 abre o rótulo e encaminha o pacote para R1.

Estas etapas mostram a sequência de eventos para conduzir um traceroute de R1 para o loopback R4 10.13.1.51.

1. R1 envia um pacote comutado por rótulo com um rótulo 47 e um TTL 1 para R2. O campo TTL do pacote IP é copiado para o campo TTL do cabeçalho do rótulo.

2. O R2 vê que não é o destinatário pretendido e o TTL é 1. Ele descarta o pacote e cria uma mensagem ICMP expirada por TTL, como faria com um pacote IP regular. Nesse caso, o pacote de mensagem ICMP é gerado por extensões ICMP para MPLS.

3. R2 anexa o rótulo 47 (o rótulo de entrada que expirou) à mensagem ICMP. Ele não envia o pacote diretamente para R1. Em vez disso, consulta sua base de informações de encaminhamento de rótulo (LFIB) e descobre que ela deve usar um rótulo de 45 para pacotes recebidos com um rótulo de 47. Ele coloca um rótulo de 45 no pacote e envia a mensagem ICMP expirada de TTL para R3.

4. O R3 preenche o rótulo e o envia para R4. O R4 identifica que o destino é R1, fornece um rótulo 28 para a mensagem e a envia por meio de R3 e R2 para R1.

5. A mensagem de erro do ICMP viaja até a outra extremidade antes de ser enviada de volta para R1. Este exemplo fornece uma ilustração:

Os pacotes sniffed na interface Ethernet em R4 confirmam as Etapas 1 a 5. Na saída do sniffer, Frame 1 é o pacote de entrada e Frame 2 é o pacote de saída de R4. A saída é formatada para refletir esta discussão e os pontos a serem considerados estão em negrito.

Frame 1 (182 on wire, 182 captured)

Ethernet II

Destination: 00:04:4e:7a:74:00 (Cisco_7a:74:00)

Source: 00:03:fd:1c:86:84 (Cisco_1c:86:84)

Type: IP (0x0800)

Internet Protocol

Version: 4

Header length: 20 bytes

Time to live: 254

Protocol: ICMP (0x01)

Header checksum: 0x1b8e (correct)

Source: 10.13.2.33 (10.13.2.33)

Destination: 10.13.2.34 (10.13.2.34)

Internet Control Message Protocol

Type: 11 (Time-to-live exceeded)

Code: 0 (TTL equals 0 during transit)

Checksum: 0x0c88 (correct)

Data (140 bytes)

04500 001c 9e19 0000 0111 044a 0a0d 0222E..........J..."

100a0d 0133 989d 829a 0008 cd37 0000 0000...3.......7....

200000 0000 0000 0000 0000 0000 0000 0000................

300000 0000 0000 0000 0000 0000 0000 0000................

400000 0000 0000 0000 0000 0000 0000 0000................

500000 0000 0000 0000 0000 0000 0000 0000................

600000 0000 0000 0000 0000 0000 0000 0000................

700000 0000 0000 0000 0000 0000 0000 0000................

802000 edf2 0008 0101 0002 f101...........

Frame 2 (186 on wire, 186 captured)

Ethernet II

Destination: 00:03:fd:1c:86:84 (Cisco_1c:86:84)

Source: 00:04:4e:7a:74:00 (Cisco_7a:74:00)

Type: MPLS label switched packet (0x8847)

MultiProtocol Label Switching Header

MPLS Label: Unknown (28)

MPLS Experimental Bits: 6

MPLS Bottom Of Label Stack: 1

MPLS TTL: 253

Internet Protocol

Version: 4

Header length: 20 bytes

Time to live: 253

Protocol: ICMP (0x01)

Header checksum: 0x1c8e (correct)

Source: 10.13.2.33 (10.13.2.33)

Destination: 10.13.2.34 (10.13.2.34)

Internet Control Message Protocol

Type: 11 (Time-to-live exceeded)

Code: 0 (TTL equals 0 during transit)

Checksum: 0x0c88 (correct)

Data (140 bytes)

04500 001c 9e19 0000 0111 044a 0a0d 0222E..........J..."

100a0d 0133 989d 829a 0008 cd37 0000 0000...3.......7....

200000 0000 0000 0000 0000 0000 0000 0000................

300000 0000 0000 0000 0000 0000 0000 0000................

400000 0000 0000 0000 0000 0000 0000 0000................

500000 0000 0000 0000 0000 0000 0000 0000................

600000 0000 0000 0000 0000 0000 0000 0000................

700000 0000 0000 0000 0000 0000 0000 0000................

802000 edf2 0008 0101 0002 f101...........

No Quadro 1 da saída, o primeiro pacote recebido por R4 é a mensagem ICMP expirada por TTL de R2 (10.13.2.33, a interface na qual o pacote original foi recebido) para R1 (10.13.2.34). Na parte de dados da mensagem ICMP, em bytes 0x89 e no primeiro nibble de 0x8A, o rótulo MPLS (20 bytes) expirou e seu valor é 0x02F ou 47. Esse é o rótulo de entrada do pacote com um TTL de 1. R2 acrescenta esse rótulo na mensagem de erro ICMP.

No Quadro 2 da saída, o tipo é mostrado como MPLS label switched packet, o que significa que é um pacote MPLS. R4 coloca um rótulo de 28 para o Quadro 1 e o encaminha para R1 através do caminho de switching de rótulo. O cabeçalho MPLS no quadro está em negrito. Além disso, se você se refere à parte TTL do pacote, no Quadro 1 seu valor é 254, e no Quadro 2 é 253. R4 reduziu em 1.

6. R1 recebe a mensagem ICMP e envia outro pacote com um rótulo de 47 e um TTL de 2 a R2. O R2 troca os rótulos, diminui o TTL (de 2 para 1) e encaminha para o R3. Como na Etapa 2, R3 envia uma mensagem ICMP expirada em TTL anexada com o rótulo de entrada que expirou para R4, e R4, em seguida, o envia de volta para R1.

A saída do sniffer em R4, mostrada aqui, confirma a Etapa 6:

Frame 3 (182 on wire, 182 captured)

Ethernet II

Destination: 00:04:4e:7a:74:00 (Cisco_7a:74:00)

Source: 00:03:fd:1c:86:84 (Cisco_1c:86:84)

Type: IP (0x0800)

Internet Protocol

Version: 4

Header length: 20 bytes

Time to live: 255

Protocol: ICMP (0x01)

Header checksum: 0x146f (correct)

Source: 10.13.3.134 (10.13.3.134)

Destination: 10.13.2.34 (10.13.2.34)

Internet Control Message Protocol

Type: 11 (Time-to-live exceeded)

Code: 0 (TTL equals 0 during transit)

Checksum: 0x0c88 (correct)

Data (140 bytes)

04500 001c 9e1b 0000 0211 0348 0a0d 0222E..........H..."

100a0d 0133 9292 829b 0008 d341 0000 0000...3.......A....

200000 0000 0000 0000 0000 0000 0000 0000................

300000 0000 0000 0000 0000 0000 0000 0000................

400000 0000 0000 0000 0000 0000 0000 0000................

500000 0000 0000 0000 0000 0000 0000 0000................

600000 0000 0000 0000 0000 0000 0000 0000................

700000 0000 0000 0000 0000 0000 0000 0000................

802000 0df3 0008 0101 0002 d101...........

Frame 4 (186 on wire, 186 captured)

Ethernet II

Destination: 00:03:fd:1c:86:84 (Cisco_1c:86:84)

Source: 00:04:4e:7a:74:00 (Cisco_7a:74:00)

Type: MPLS label switched packet (0x8847)

MultiProtocol Label Switching Header

MPLS Label: Unknown (28)

MPLS Experimental Bits: 6

MPLS Bottom Of Label Stack: 1

MPLS TTL: 254

Internet Protocol

Version: 4

Header length: 20 bytes

Time to live: 254

Protocol: ICMP (0x01)

Header checksum: 0x156f (correct)

Source: 10.13.3.134 (10.13.3.134)

Destination: 10.13.2.34 (10.13.2.34)

Internet Control Message Protocol

Type: 11 (Time-to-live exceeded)

Code: 0 (TTL equals 0 during transit)

Checksum: 0x0c88 (correct)

Data (140 bytes)

04500 001c 9e1b 0000 0211 0348 0a0d 0222E..........H..."

100a0d 0133 9292 829b 0008 d341 0000 0000...3.......A....

200000 0000 0000 0000 0000 0000 0000 0000................

300000 0000 0000 0000 0000 0000 0000 0000................

400000 0000 0000 0000 0000 0000 0000 0000................

500000 0000 0000 0000 0000 0000 0000 0000................

600000 0000 0000 0000 0000 0000 0000 0000................

700000 0000 0000 0000 0000 0000 0000 0000................

802000 0df3 0008 0101 0002 d101...........

Na saída do Quadro 3, você pode determinar que o Quadro 3 é o pacote ICMP de R3 para R1. O endereço de origem (10.13.3.134) é o endereço no qual o pacote original é recebido. A mensagem de erro do ICMP contém as informações sobre o rótulo expirado no final da porção de dados. Seu valor é 0x02d, que é 45. O quadro 4 é o pacote MPLS enviado de R4 para R1.

7. Ao receber a mensagem ICMP, R1 envia outro pacote com um rótulo de 47 e um TTL de 3. A caminho, R2 e R3 decrementam o TTL e encaminham o pacote para R4. O R4 observa que ele é o receptor pretendido e encontra a porta do datagrama de UDP inalcançável. Ele envia uma porta ICMP inalcançável mensagem para R1 através de R3 e R2.

Nesta saída do farejador, os pontos importantes a serem observados estão em negrito:

Frame 5 (60 on wire, 60 captured)

Ethernet II

Destination: 00:04:4e:7a:74:00 (Cisco_7a:74:00)

Source: 00:03:fd:1c:86:84 (Cisco_1c:86:84)

Type: IP (0x0800)

Trailer: 00000000000000000000000000000000...

Internet Protocol

Version: 4

Header length: 20 bytes

Time to live: 1

Protocol: UDP (0x11)

Header checksum: 0x0446 (correct)

Source: 10.13.2.34 (10.13.2.34)

Destination: 10.13.1.51 (10.13.1.51)

User Datagram Protocol

Source port: 37647 (37647)

Destination port: 33436 (33436)

Length: 8

Checksum: 0xd2c3 (correct)

Frame 6 (74 on wire, 74 captured)

Ethernet II

Destination: 00:03:fd:1c:86:84 (Cisco_1c:86:84)

Source: 00:04:4e:7a:74:00 (Cisco_7a:74:00)

Type: MPLS label switched packet (0x8847)

MultiProtocol Label Switching Header

MPLS Label: Unknown (28)

MPLS Experimental Bits: 6

MPLS Bottom Of Label Stack: 1

MPLS TTL: 255

Internet Protocol

Version: 4

Header length: 20 bytes

Time to live: 255

Protocol: ICMP (0x01)

Header checksum: 0x5694 (correct)

Source: 10.13.5.10 (10.13.5.10)

Destination: 10.13.2.34 (10.13.2.34)

Internet Control Message Protocol

Type: 3 (Destination unreachable)

Code: 3 (Port unreachable)

Checksum: 0x1485 (correct)

Data (28 bytes)

04500 001c 9e1d 0000 0111 0446 0a0d 0222E..........F..."

100a0d 0133 930f 829c 0008 d2c3...3........

O Quadro 5 mostra que o datagrama UDP é enviado por R1 para R4. O valor da porta de destino no datagrama UDP é 33436 (maior que 32000), conforme discutido na seção Comando traceroute Normal.

No Quadro 6 , R4 envia um tipo ICMP de destino inalcançável e um código inalcançável de porta para R1. Todas as mensagens ICMP anteriores de R2 e R3 tinham o campo de tipo definido como tempo de vida excedido. A saída do comando extended traceroute é mostrada aqui:

R1#traceroute

Protocol [ip]:

Target IP address: 10.13.1.51

Source address: 10.13.2.34

Numeric display [n]:

Timeout in seconds [3]:

Probe count [3]: 1

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

1 10.13.2.33 [MPLS: Label 47 Exp 0] 0 msec

2 10.13.3.134 [MPLS: Label 45 Exp 0] 0 msec

3 10.13.5.10 4 msec

R1#

Por padrão, o comando traceroute usa três testadores para cada valor TTL. Envia três pacotes com um TTL de 1, três pacotes com um TTL de 2 e assim por diante. Esse comando traceroute é emitido com uma única sonda, portanto, é fácil rastrear e depurar. Como visto na saída, o comando traceroute mostra também o valor do rótulo expirado.

Comando no mpls ip propagate-ttl

Quando você configura o MPLS, um rótulo é imposto pelo roteador do switch de rótulo (LSR) quando um pacote IP é encaminhado para o domínio MPLS. Esse rótulo deve ter um valor no campo TTL. Por padrão, o LSR lê o campo TTL no cabeçalho IP do pacote recebido, diminui-o em 1 e copia o que resta no campo TTL do cabeçalho MPLS. Os LSRs principais só olham para o rótulo mais alto. Se o valor TTL não chegar a 0, o pacote será encaminhado. O LSR da ponta de egresso que mostra o rótulo, copia o que é deixado no campo TTL do rótulo para o campo TTL do cabeçalho IP e, em seguida, encaminha o pacote IP para fora do domínio MPLS.

Esse comportamento pode ser alterado com o comando de configuração no mpls ip propagate-ttl. O LSR de extremidade de ingresso utiliza o valor 255 como o valor TTL no rótulo, ao impô-lo. A extremidade de saída LSR não copia o valor TTL da etiqueta no cabeçalho IP quando a etiqueta é acionada rapidamente. O resultado líquido é que o TTL do cabeçalho IP não reflete os saltos obtidos no núcleo do MPLS; assim, quando os clientes executam um traceroute de um lado da rede para outro, os roteadores na rede central MPLS não aparecem nas informações do traceroute. É importante desativar a propagação TTL nos LSRs de borda de entrada e de saída. Caso contrário, o cabeçalho IP pode ter um valor mais alto quando sai do domínio MPLS do que quando o inseriu.

Isso fornece um exemplo:

C1 executa um traceroute para C2. Com a operação padrão de propagação de TTL IP, o traceroute em C1 se parece com isto:

C1#traceroute C2.cust.com

Tracing the route to C2.cust.com

1 A.provider.net       44 msec  36 msec  32 msec

2 B provider.net      164 msec  132 msec  128 msec

3 C.provider.net 148 msec  156 msec  152 msec

4 C2.cust.com         180 msec  *  181 msec

Essa saída ilustra o comportamento traceroute típico na rede MPLS. Como o cabeçalho do rótulo de um pacote rotulado transporta o valor TTL do pacote IP original, as rotas nos pacotes de descarte do caminho para os quais o TTL é excedido. Assim, traceroute mostra todos os roteadores do caminho. O comportamento é este:

1. O primeiro pacote é um pacote IP com TTL igual a 1. O roteador A diminui o TTL e descarta o pacote porque ele chega a 0. Uma mensagem ICMP TTL excedido é enviada para a origem.

2. O segundo pacote enviado é um pacote IP com TTL igual a 2. O Roteador A diminui o TTL, rotula o pacote e encaminha o pacote ao Roteador B.

3. O roteador B diminui o valor de TTL no cabeçalho do MPLS, descarta o pacote e envia uma mensagem de TTL de ICMP excedido para a origem. Como o que foi cancelado foi um pacote MPLS, o endereço de devolução da mensagem ICMP deve ser derivado do endereço de origem do cabeçalho IP, dentro do pacote MPLS. Mas esse endereço IP na verdade pode não ser conhecido pelo Roteador B, então o Roteador B encaminha as mensagens ICMP ao longo do mesmo caminho comutado por rótulo (LSP) que o pacote descartado estava viajando (na direção do roteador C). No final do LSP, o rótulo é removido e as mensagens ICMP são encaminhadas de acordo com o endereço de destino no cabeçalho IP (em direção ao Roteador C1).

4. O terceiro pacote (TTL é 3) passa por um processamento parecido com o dos pacotes anteriores, exceto que o roteador C é quem está descartando o pacote agora, com base no TTL do cabeçalho IP. O Roteador B, devido ao Penultimate Hop Popping (PHP), removeu anteriormente o rótulo, e o TTL foi copiado no cabeçalho IP.

5. O quarto pacote (TTL é 4) alcança o destino final onde o TTL do cabeçalho IP é examinado.

Se a propagação de TTL IP estiver desabilitada com o comando no mpls ip propagate-ttl no modo de configuração global, o valor de TTL não será copiado no cabeçalho IP e o traceroute em C1 a C2 terá a seguinte aparência:

C1#traceroute C2.cust.com

Tracing the route to C2.cust.com

1 A.provider.net   44 msec  36 msec  32 msec

2 C2.cust.com     180 msec  *  181 msec

Quando o comando traceroute é usado nessa situação, as respostas ICMP são recebidas somente dos roteadores que veem o TTL real armazenado no cabeçalho IP. Nessa situação, o Roteador C1 está executando um comando traceroute (como mostrado), mas os roteadores do núcleo não copiam o TTL de e para o rótulo. Isso resulta nesse comportamento:

1. O primeiro pacote é um pacote IP com TTL igual a 1. O Roteador A diminui o TTL, descarta o pacote e envia uma mensagem ICMP TTL excedido para a origem.

2. O segundo pacote é um pacote IP com TTL igual a 2. O Roteador A diminui o TTL, rotula o pacote e define o TTL no cabeçalho MPLS como 255.

3. O roteador B decota o TTL no cabeçalho MPLS para 254, remove o rótulo MPLS e copia o valor TTL no cabeçalho MPLS para o campo TTL do cabeçalho IP.

4. O Roteador C diminui o TTL IP e envia o pacote ao roteador C2 do próximo salto. O pacote atingiu o destino final.

Informações Relacionadas

- Noções básicas dos comandos ping e traceroute

- Comando mpls ip propagate-ttl

- Página de suporte à tecnologia MPLS

- Suporte Técnico - Cisco Systems