Contents

Introduction

Informações de Apoio

Traceroute ICMP na rede MPLS

Rastreamento ICMP disparado de PE para PE remoto

Rastreamento ICMP disparado de CE para CE remoto

Traceroute de LSP MPLS na rede MPLS

Rastreamento LSP disparado do PE para o PE remoto

Rastreamento LSP disparado de CE para CE remoto

Informações Relacionadas

Introduction

Este documento descreve o comportamento de traceroute do Internet Control Message Protocol (ICMP) na rede Multiprotocol Label Switching (MPLS) e uma comparação rápida com o rastreamento LSP.

Informações de Apoio

No ambiente IP, qualquer nó quando receber um pacote e se o Time To Live (TTL) expirar, é esperado que gere a mensagem de erro ICMP "TTL Exceeded" (Tipo=11, Código=0) e a envie para o endereço de origem do pacote. Esse conceito é aproveitado para rastrear o caminho IP da origem ao destino, enviando o pacote UDP com TTL iniciando sequencialmente a partir de 1. Observe que os requisitos básicos para essa funcionalidade são:

- O endereço de origem do pacote pode ser alcançado dos nós de trânsito

- O ICMP não é filtrado ao longo do caminho

No ambiente MPLS, um provedor de transporte LSR pode nem sempre ter acesso ao endereço de origem e precisar de algumas melhorias para o tratamento de ICMP no domínio MPLS.

Traceroute ICMP na rede MPLS

O comportamento padrão de qualquer LSR ao receber um pacote com TTL=1 no rótulo superior segue o comportamento de IP tradicional de descartar o pacote e disparar a mensagem de erro ICMP. Para rotear a mensagem ICMP para a origem, o LSR executará isto:

- Colocar em buffer a pilha de rótulos do pacote recebido (o pacote recebido com TTL=1)

- Gerar mensagem de erro ICMP com origem como seu próprio endereço e destino como endereço origem do pacote recebido.

- Acrescente todos os rótulos da parte inferior da pilha de rótulos (que foi colocada no buffer antes na etapa 1) com TTL=255, exceto o superior.

- Obtenha o rótulo superior da pilha de rótulos armazenada em buffer e execute a pesquisa de LFIB local para que o rótulo seja trocado e o próximo salto associado.

- Acrescente o novo rótulo à parte superior da pilha com TTL=255 e envie.

Com essa abordagem, a mensagem de erro ICMP passa do LSR de trânsito para o LER de saída e, em seguida, volta para o LER de entrada para a origem real.

Rastreamento ICMP disparado de PE para PE remoto

Aqui está um exemplo simples que explica o comportamento quando o rastreamento ICMP é disparado de PE para PE remoto dentro do mesmo domínio MPLS:

Nessa topologia, quando o traceroute ICMP é disparado de R2 para 10.1.4.4, o primeiro pacote é enviado com TTL de 1. O R3 ao receber o pacote decrementará o TTL para 0 e acionará o mecanismo de geração de ICMP.

R3 armazenará em buffer a pilha de rótulos e gerará mensagens de erro ICMP e incluirá a pilha de rótulos de entrada do buffer no payload ICMP. Preenche ainda mais o cabeçalho IP com o endereço de origem da interface de entrada do pacote rotulado, o endereço de destino como a origem do pacote rotulado. O TTL está definido como 255. Agora, ele empurra a pilha de rótulos do buffer e consulta a tabela LFIB para encaminhar a ação no rótulo superior. Nesta topologia, a pilha de rótulos recebida é 17. Ao executar uma pesquisa na tabela LFIB, o rótulo 17 é trocado pelo rótulo 16 e encaminhado para o próximo R6. O R6, por sua vez, colocará o rótulo superior e encaminhará para o R4, que encaminhará o pacote de volta para o R2.

Como poderia ser observado na saída do traceroute em R2, o rótulo de entrada será listado por cada salto ao longo do caminho.

Rastreamento ICMP disparado de CE para CE remoto

Aqui está um exemplo simples que explica o comportamento quando o rastreamento ICMP é disparado de CE para CE remoto sobre domínio MPLS:

Nessa topologia, quando o traceroute ICMP é disparado de R1 (CE) para 192.168.5.5 (CE remoto), o primeiro pacote é enviado com TTL de 1. Esse é o pacote IP normal e, portanto, o R2 segue o comportamento tradicional de gerar ICMP e enviar diretamente para R1. O segundo pacote enviado com TTL=2 expirará em R3.

R3 armazenará em buffer a pilha de rótulos e gerará mensagens de erro ICMP e incluirá a pilha de rótulos de entrada do buffer no payload ICMP. Preenche ainda mais o cabeçalho IP com o endereço de origem da interface de entrada do pacote rotulado, o endereço de destino como a origem do pacote rotulado. O TTL está definido como 255. Agora, ele empurra a pilha de rótulos do buffer e consulta a tabela LFIB para encaminhar a ação no rótulo superior. Na topologia acima, a pilha de rótulos recebida é {17, 18}. Ao executar uma pesquisa na tabela LFIB para o rótulo superior, 17 serão trocados pelo rótulo 16 e encaminhados para o próximo R6. O R6, por sua vez, pop a etiqueta superior e encaminhará para o R4. O R4 usará o rótulo do VRF para identificar o VRF e encaminhar o pacote de volta para R1.

Como poderia ser observado na saída do traceroute em R1, a pilha de rótulos de entrada é listada por cada salto ao longo do caminho.

Traceroute de LSP MPLS na rede MPLS

Diferentemente do traceroute baseado em ICMP, o traceroute de LSP usa o maquinário definido em RFC4379. Ele usa o encapsulamento IP/UDP com o endereço de destino da solicitação definido como endereço de loopback (intervalo 127.0.0.0/8). Espera-se que o Ping LSP seja disparado dentro do mesmo domínio MPLS e, portanto, a resposta será enviada diretamente ao iniciador.

Quando o traceroute de LSP ("traceroute mpls ipv4 <FEC>") é disparado de qualquer LSR, os detalhes sobre o FEC a ser validado serão incluídos em um TLV como "Pilha de FEC de Destino" na Solicitação de Eco de MPLS. Essa mensagem será enviada com TTL na pilha de rótulos, iniciando sequencialmente a partir de 1. Qualquer LSR de trânsito ao receber o pacote e se o TTL expirar processará o pacote IP, pois o endereço de destino é o endereço de loopback. e aponte para CPU para processamento MPLS OAM.

Opcionalmente, o respondedor executará a validação de FEC buscando os rótulos da pilha de rótulos da solicitação de eco MPLS recebida e detalhes de FEC do TLV da pilha FEC de destino para validar o mesmo em relação às informações do plano de controle local. Em caso de rastreamento, o Respondedor incluirá as informações de downstream, como a etiqueta de saída e o endereço de vizinho de downstream, etc. em um TLV como TLV de mapeamento de downstream (DSMAP). (O DSMAP será substituído pelo DDMAP, pois é mais flexível que o DSMAP).

Rastreamento LSP disparado do PE para o PE remoto

Nessa topologia, o rastreamento de LSP é disparado de R2 para validar o LSP para o prefixo 10.1.4.4/32. O TTL no rótulo será definido a partir de 1. O R3 ao recebê-lo apontará para a CPU para o processamento do OAM.

R3 responderá ao R2 com Resposta de Eco MPLS com TLV de DSMAP transportando a etiqueta de saída 16 e informações adicionais como detalhes do vizinho de downstream. Diferentemente das mensagens ICMP, a resposta de eco MPLS será encaminhada diretamente do respondente R3 para o iniciador R2.

Como poderia ser observado na saída do traceroute de LSP em R2, a pilha de rótulos de saída será listada por cada salto ao longo do caminho. Isso é diferente do traceroute baseado em ICMP, onde o rótulo listado na saída será a pilha de rótulos de entrada.

Rastreamento LSP disparado de CE para CE remoto

Isso se aplica em cenários como o CSC em que o MPLS está ativado entre PE-CE. Há dois desafios na execução do rastreamento de LSP de CE para CE remoto sobre domínio MPLS da operadora, como abaixo:

- A resposta de eco LSP será enviada diretamente ao iniciador. Então o respondente DEVE ter acesso ao iniciador. Na topologia acima, R3 pode não ter alcance para R1 como está no VRF.

- Para cada rótulo na pilha de rótulos, deve haver detalhes FEC relevantes incluídos na Pilha FEC de Destino para validação. O FEC incluído pelo iniciador será 1 enquanto o PE enviará duas etiquetas. Na topologia acima, R1 envia solicitação de eco MPLS com FEC={192.168.5.5/32} e inclui o rótulo 28 na pilha. Já que R2 troca o rótulo 28 com {17, 27}, R3 receberá a Solicitação com 2 rótulo na pilha enquanto 1 FEC no TLV confunde a validação de FEC.

O RFC6424 define o conceito de "TLV de alteração de pilha FEC" para lidar com o problema 2. Este TLV será incluído na resposta com FEC relevante como PUSH/POP que pode ser incluído pelo iniciador na solicitação de eco subsequente.

draft-ietf-mpls-lsp-ping-relay-reply define o conceito de pilha de endereço de nó de transmissão em TLV que pode ser usado pelo Respondente para retransmitir a resposta, mesmo que não tenha alcance para o Iniciador.

Esses 2 problemas não são suportados no momento no Cisco IOS® e, portanto, o rastreamento de LSP do CE para CE remoto listará apenas o PE de entrada e o CE remoto. Isso está incluído apenas para ser completo.

Informações Relacionadas

- RFC 3032

- RFC 4379

- RFC 6424