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.
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.
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.
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:
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.
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:
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.
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.
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.
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).
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.
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:
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.