Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Nesta página
 

Resolução de problemas MPLS

Verifique as interfaces MPLS

Propósito

Se o protocolo MPLS não estiver configurado corretamente nos roteadores de sua rede, as interfaces não poderão realizar comutação MPLS.

Nota:

Para que uma rota rotulada seja resolvida em uma interface, family mpls deve ser configurada no nível de [edit interfaces] hierarquia para que a rota seja resolvida com sucesso. Quando a interface não está configurada, family mplsas rotas rotuladas não são resolvidas.

Ação

Para verificar as interfaces MPLS, insira o seguinte comando de modo operacional de interface de linha de comando (CLI) do Junos OS:

Saída de amostra 1

nome de comando

A saída de amostra a seguir é para todos os roteadores da rede mostrados na topologia de rede MPLS.

Saída de amostra 2

nome de comando

Saída de amostra 3

nome de comando

Significado

A saída de amostra 1 mostra que todas as interfaces MPLS em todos os roteadores da rede estão habilitadas (Up) e podem realizar comutação MPLS. Se você não configurar a interface correta no nível [edit protocols mpls] de hierarquia ou incluir a family mpls declaração no nível [edit interfaces type-fpc/pic/port unit number ] de hierarquia, a interface não poderá executar comutação MPLS e não aparecerá na saída para o show mpls interface comando.

Os grupos administrativos não estão configurados em nenhuma das interfaces mostradas na rede de exemplo na topologia de rede MPLS. No entanto, se fossem, a saída indicaria quais bits de classe de afinidade estão habilitados no roteador.

A saída de amostra 2 mostra que a interface so-0/0/2.0 está ausente e, portanto, pode estar configurada incorretamente. Por exemplo, a interface pode não ser incluída no nível [edit protocols mpls] de hierarquia, ou a family mpls declaração pode não ser incluída no nível [edit interfaces type-fpc/pic/port unit number] de hierarquia. Se a interface estiver configurada corretamente, o RSVP pode não ter sinalizado por essa interface ainda. Para obter mais informações sobre como determinar qual interface está configurada incorretamente, consulte Verificar famílias de protocolo.

A saída de amostra 3 mostra que o protocolo MPLS não está configurado no nível [edit protocols mpls] de hierarquia.

Verificar famílias de protocolo

Propósito

Se uma interface lógica não tiver MPLS habilitada, ela não poderá realizar comutação MPLS. Essa etapa permite determinar rapidamente quais interfaces estão configuradas com MPLS e outras famílias de protocolo.

Ação

Para verificar as famílias de protocolo configuradas nos roteadores de sua rede, insira o seguinte comando de modo operacional Junos OS CLI:

Saída de amostra 1

nome de comando

Saída de amostra 2

nome de comando

Significado

A saída de amostra 1 mostra a interface, o status administrativo do link (Admin), o status da camada de enlace de dados do link (Link), as famílias de protocolo configuradas na interface (Proto) e os endereços locais e remotos na interface.

Todas as interfaces em todas as rotas da rede mostradas na topologia de rede MPLS estão administrativamente habilitadas e funcionando na camada de link de dados com MPLS e IS-IS, e têm um inet endereço. Todos estão configurados com uma família de protocolo IPv4 (inet) e têm as famílias de protocolo IS-IS (iso) e MPLS (mpls) configuradas no nível [edit interfaces type-fpc/pic/port unit number] de hierarquia.

A saída de amostra 2 mostra que a interface so-0/0/2.0 em R6 que não tem a mpls declaração incluída no nível [edit interfaces type-fpc/pic/port unit number] de hierarquia.

Verifique a configuração do MPLS

Propósito

Depois de verificar o trânsito e os roteadores de entrada, use o traceroute comando para verificar o bgp próximo salto e usou o ping comando para verificar o caminho ativo, você pode verificar se há problemas com a configuração MPLS nos níveis de hierarquia e[edit interfaces].[edit protocols mpls]

Nota:

Para que uma rota rotulada seja resolvida em uma interface, family mpls deve ser configurada no nível de [edit interfaces] hierarquia para que a rota seja resolvida com sucesso. Quando a interface não está configurada, family mplsas rotas rotuladas não são resolvidas.

Ação

Para verificar a configuração MPLS, insira os seguintes comandos dos roteadores de entrada, trânsito e saída:

Saída de amostra 1

nome de comando

Saída de amostra 2

nome de comando

Significado

A saída de amostra 1 dos roteadores de entrada, trânsito e saída mostra que a configuração de interfaces no roteador R6 de saída está incorreta. A interface so-0/0/3.0 é incluída como inativa no nível [edit protocols mpls] de hierarquia, quando deve estar ativa porque é a interface pela qual o LSP viaja.

A saída de amostra 2 mostra que as interfaces estão configuradas corretamente para MPLS no roteador R6de saída. As interfaces também estão configuradas corretamente nos roteadores de entrada e trânsito (não mostrados).

Verificando a camada MPLS

Propósito

Depois de configurar o caminho comutada por rótulos (LSP), emitir o show mpls lsp comando e determinar que há um erro, você pode descobrir que o erro não está nas camadas física, link de dados, Protocolo de Internet (IP), protocolo de gateway interior (IGP) ou protocolo de reserva de recursos (RSVP). Continue investigando o problema na camada MPLS da rede.

Figura 1 ilustra a camada MPLS do modelo MPLS em camadas.

Figura 1: Verificando a camada MPLSVerificando a camada MPLS

Com a camada MPLS, você verifica se o LSP está funcionando corretamente. Se a rede não estiver funcionando nesta camada, o LSP não funcionará como configurado.

Figura 2 ilustra a rede MPLS usada neste tópico.

Figura 2: Rede MPLS quebrada na camada MPLSRede MPLS quebrada na camada MPLS

A rede mostrada Figura 2 é uma configuração totalmente malhada onde cada interface diretamente conectada pode receber e enviar pacotes para todas as outras interfaces semelhantes. O LSP nesta rede está configurado para ser executado desde o roteador R1de entrada, pelo roteador R3de trânsito até o roteador R6de saída. Além disso, um LSP reverso é configurado para ser executado de R6 até R3R1, criando tráfego bidirecional.

No entanto, neste exemplo, o LSP reverso está desativado sem um caminho de R6R1.

A cruz mostrada Figura 2 indica onde o LSP está quebrado. Algumas possíveis razões pelas quais o LSP está quebrado podem incluir um protocolo MPLS configurado incorretamente, ou interfaces que estão configuradas incorretamente para MPLS.

Na rede mostrada Figura 2, um erro de configuração no roteador R6 de saída impede o LSP de atravessar a rede como esperado.

Para verificar a camada MPLS, siga essas etapas:

Verifique o LSP

Propósito

Normalmente, você usa o show mpls lsp extensive comando para verificar o LSP. No entanto, para uma verificação rápida do estado LSP, use o show mpls lsp comando. Se o LSP estiver desativado, use a opção extensive (show mpls lsp extensive) como acompanhamento. Se sua rede tiver vários LSPs, você pode considerar especificar o nome do LSP, usando a opção name (show mpls lsp name name ou show mpls lsp name name extensive).

Ação

Para verificar se o LSP está funcionando, insira alguns ou todos os seguintes comandos do roteador de entrada:

Saída de amostra 1
nome de comando
Saída de amostra 2
nome de comando
Saída de amostra 3
nome de comando
Saída de amostra 4
nome de comando

Significado

A saída de amostra 1 mostra uma breve descrição do estado do LSP para os roteadores de entrada, trânsito e saída. A saída do roteador R1 de entrada e do roteador R6 de saída mostra que ambos os LSPs estão desativados R1-to-R6 e R6-toR1. Com os LSPs configurados e R1R6, esperamos sessões de LSP de saída em ambos R1 e R6. Além disso, o roteador R3 de trânsito não tem sessões de trânsito.

A saída de amostra 2 mostra todas as informações sobre os LSPs, incluindo todo o histórico de estado passado e a razão pela qual um LSP falhou. Saída e R1R6 indica que não há rota para o destino porque o algoritmo de caminho mais curto limitado primeiro (CSPF) falhou.

As saídas de amostra 3 e 4 mostram exemplos da saída para o show mpls lsp name comando com a opção extensive . Neste caso, a saída é muito semelhante ao show mpls lsp comando porque apenas um LSP está configurado na rede de exemplo na rede MPLS quebrada na camada MPLS. No entanto, em uma grande rede com muitos LSPs configurados, os resultados seriam bem diferentes entre os dois comandos.

Verifique a rota LSP no roteador de trânsito

Propósito

Se o LSP estiver em funcionamento, a rota LSP deve aparecer na mpls.0 tabela de roteamento. O MPLS mantém uma tabela de roteamento de caminho MPLS (mpls.0), que contém uma lista do próximo roteador comutada por rótulos em cada LSP. Esta tabela de roteamento é usada em roteadores de trânsito para rotear pacotes para o próximo roteador ao longo de um LSP. Se as rotas não estiverem presentes na saída para o roteador de trânsito, verifique a configuração do protocolo MPLS nos roteadores de entrada e saída.

Ação

Para verificar a rota LSP no roteador de trânsito, insira o seguinte comando do roteador de trânsito:

Saída de amostra 1
nome de comando
Saída de amostra 2
nome de comando

Significado

A saída de amostra 1 do roteador R3 de trânsito mostra três entradas de rota na forma de entradas de rótulo MPLS. Esses rótulos MPLS são rótulos MPLS reservados definidos no RFC 3032 e estão sempre presentes na mpls.0 tabela de roteamento, independentemente do estado do LSP. Os rótulos de entrada atribuídos pelo RSVP ao vizinho upstream estão ausentes da saída, indicando que o LSP está desativado. Para obter mais informações sobre as entradas de rótulo MPLS, consulte Checklist para verificar o uso do LSP.

Em contraste, a saída de amostra 2 mostra os rótulos e rotas MPLS para um LSP configurado corretamente. Os três rótulos MPLS reservados estão presentes, e as outras quatro entradas representam os rótulos de entrada atribuídos pelo RSVP ao vizinho upstream. Essas quatro entradas representam duas rotas. Existem duas entradas por rota porque os valores de pilha no cabeçalho MPLS podem ser diferentes. Para cada rota, a segunda entrada 100864 (S=0)100880 (S=0) indica que a profundidade da pilha não é 1, e valores adicionais de rótulo estão incluídos no pacote. Em contraste, a primeira entrada e 100864100880 tem um valor S=1 inferido que indica uma profundidade de pilha de 1 e faz de cada rótulo o último rótulo nesse pacote em particular. As entradas duplas indicam que este é o penúltimo roteador. Para obter mais informações sobre o empilhamento de rótulos MPLS, consulte RFC 3032, codificação MPLS Label Stack.

Verifique a rota LSP no roteador de entrada

Propósito

Verifique se a rota LSP está incluída nas entradas ativas na inet.3 tabela de roteamento para o endereço especificado.

Ação

Para verificar a rota LSP, insira o seguinte comando do roteador de entrada:

Saída de amostra 1
nome de comando
Saída de amostra 2
nome de comando

Significado

A saída de amostra 1 mostra apenas entradas na inet.0 tabela de roteamento. A inet.3 tabela de roteamento está ausente da saída porque o LSP não está funcionando. A inet.0 tabela de roteamento é usada por protocolos de gateway interior (IGPs) e Border Gateway Protocol (BGP) para armazenar informações de roteamento. Neste caso, o IGP é o Sistema Intermediário para Sistema Intermediário (IS-IS). Para obter mais informações sobre a inet.0 tabela de roteamento, consulte o Guia de configuração de aplicativos Junos MPLS.

Se o LSP estivesse funcionando, esperaríamos ver entradas que incluam o LSP na inet.3 tabela de roteamento. A inet.3 tabela de roteamento é usada em roteadores de entrada para rotear pacotes BGP para o roteador de saída de destino. O BGP usa a inet.3 tabela de roteamento no roteador de entrada para ajudar a resolver endereços de próximo salto. O BGP está configurado na rede de exemplo mostrada na rede MPLS quebrada na camada MPLS.

A saída de amostra 2 mostra a saída que você deve receber quando o LSP estiver em alta. A saída mostra as tabelas e inet.3 o inet.0 roteamento, indicando que os LSPs R1-to-R6 estão R6-to-R1 disponíveis.

Verifique as etiquetas MPLS com o comando de traceroute

Propósito

Exibir os pacotes de rota que levam para um destino BGP onde o próximo salto BGP para essa rota é o endereço de saída LSP. Por padrão, o BGP usa as inet.0 tabelas e o inet.3 roteamento para resolver o endereço de próximo salto. Quando o endereço de próximo salto da rota BGP não é o ID do roteador de saída, o tráfego é mapeado para rotas IGP, não para o LSP. Use o traceroute comando como uma ferramenta de depuração para determinar se o LSP está sendo usado para encaminhar tráfego.

Ação

Para verificar as etiquetas MPLS, insira o seguinte comando do roteador de entrada:

Saída de amostra 1
nome de comando
Saída de amostra 2
nome de comando

Significado

A saída de amostra 1 mostra que o tráfego BGP não está usando o LSP, portanto, as etiquetas MPLS não aparecem na saída. Em vez de usar o LSP, o tráfego BGP está usando o IGP (IS-IS, na rede exemplo em MPLS Network Broken at the MPLS Layer) para chegar ao endereço de saída LSP de próximo salto BGP. O comportamento padrão do Junos OS usa LSPs para tráfego BGP quando o próximo salto BGP é igual ao endereço de saída LSP.

A saída de amostra 2 é um exemplo de saída para um LSP configurado corretamente. A saída mostra rótulos MPLS, indicando que o tráfego BGP está usando o LSP para chegar ao BGP no próximo salto.

Verifique as etiquetas MPLS com o comando de ping

Propósito

Ao pingar em um LSP específico, verifique se as solicitações de eco são enviadas pelo LSP como pacotes MPLS.

Ação

Para verificar as etiquetas MPLS, insira o seguinte comando do roteador de entrada para ping no roteador de saída:

Por exemplo:

Saída de amostra 1
nome de comando
Saída de amostra 2
nome de comando

Significado

A saída de amostra 1 mostra que o LSP não tem um caminho ativo para encaminhar solicitações de eco, indicando que o LSP está desativado.

A saída de amostra 2 é um exemplo de saída que você deve receber quando o LSP estiver em funcionamento e encaminhando pacotes.

Tome as medidas apropriadas

Problema

Descrição

Dependendo do erro que você encontrou em sua investigação, você deve tomar as medidas apropriadas para corrigir o problema. Neste exemplo, uma interface está configurada incorretamente no nível [edit protocols mpls] de hierarquia no roteador de saída R6.

Solução

Para corrigir o erro neste exemplo, siga essas etapas:

  1. Ativar a interface na configuração de protocolo MPLS no roteador R6de saída:

  2. Verifique e confirme a configuração:

Saída de amostra
Significado

A saída de amostra mostra que a interface so-0/0/3.0 configurada incorretamente no roteador R6 de saída agora é ativada no nível [edit protocols mpls] de hierarquia. O LSP agora pode surgir.

Verifique o LSP novamente

Propósito

Após tomar as medidas apropriadas para corrigir o erro, o LSP precisa ser verificado novamente para confirmar que o problema na camada BGP foi resolvido.

Ação

Para verificar o LSP novamente, insira o seguinte comando dos roteadores de entrada, trânsito e saída:

Saída de amostra
nome de comando

Significado

A saída de amostra 1 do roteador R1 de entrada mostra que o LSP R1-to-R6 tem uma rota ativa para R6 e o estado está em alta.

A saída de amostra 2 do roteador R3 de trânsito mostra que existem duas sessões de LSP de trânsito, uma de R1 ida e R6 outra de R6 para R1. Ambos os LSPs estão funcionando.

A saída de amostra 3 do roteador R6 de saída mostra que o LSP está ativo e a rota ativa é a rota principal. O LSP agora está atravessando a rede ao longo do caminho esperado, de R1 até R6R3 , e o LSP reverso, de R6 até R1R3 .

Verifique o backup de um a um

Propósito

Você pode verificar se o backup de um a um está estabelecido examinando o roteador de entrada e os outros roteadores da rede.

Ação

Para verificar o backup de um a um, insira os seguintes comandos de modo operacional Junos OS CLI:

Saída de amostra

nome de comando

A saída de amostra a seguir é do roteador R1 de entrada:

Significado

A saída de R1 amostra mostra que o FastReroute desired objeto foi incluído nas mensagens Path para o LSP, permitindo R1 selecionar o caminho ativo para o LSP e estabelecer um caminho de desvio para evitar R2.

Na linha 8, Fast-reroute Detour Up mostra que o desvio está operacional. As linhas 6 e 7 indicam que os roteadores R2 de trânsito e R4 estabeleceram seus caminhos de desvio.

R2, 10.0.12.14inclui (flag=9), indicando que a proteção de nós está disponível para o nó downstream e o link. R4, 10.0.24.2inclui (flag=1), indicando que a proteção de link está disponível para o próximo link downstream. Neste caso, R4 pode proteger apenas o link downstream porque o nó é o roteador R5de saída, que não pode ser protegido. Para obter mais informações sobre bandeiras, consulte o Junos User Guide.

A saída para o show mpls lsp extensive comando não mostra o caminho real do desvio. Para ver os links reais usados pelos caminhos de desvio, você deve usar o show rsvp session ingress detail comando.

Saída de amostra

A saída de amostra a seguir é do roteador R1 de entrada na rede mostrado em desvios de backup de um para um.

Significado

A saída de R1 amostra mostra a sessão de RSVP do LSP principal. O caminho de desvio está estabelecido, Detour is Up. O caminho físico do desvio é exibido em Detour Explct route. O caminho de desvio usa R7 e R9 como roteadores de trânsito para alcançar R5o roteador de saída.

Saída de amostra

A saída de amostra a seguir é do primeiro roteador de trânsito R2 na rede mostrado em desvios de backup de um para um:

Significado

A saída de R2 amostra mostra que o desvio está estabelecido (Detour is Up) e evita R4, e a conexão R4 de enlaces e R5 (10.0.45.2). O caminho de desvio é através R7 (10.0.27.2) e R9 (10.0.79.2) para R5 (10.0.59.1), que é diferente da rota explícita para o desvio de R1. R1 tem o desvio passando pelo 10.0.17.14 link em R7, enquanto R1 está usando o 10.0.27.2 link. Ambos os desvios se fundem através R9 do 10.0.79.2 link para R5 (10.0.59.1).

Saída de amostra

A saída de amostra a seguir é do segundo roteador de trânsito R4 na rede mostrado em desvios de backup de um para um:

Significado

A saída de R4 amostra mostra que o desvio está estabelecido (Detour is Up) e evita a conexão R4 do enlace e R5 (10.0.45.2). O caminho de desvio passa pelo R9 () até R5 (10.0.59.110.0.49.2). Algumas das informações são semelhantes às encontradas na saída para R1 e R2. No entanto, a rota explícita para o desvio é diferente, passando pela conexão R4 do enlace e R9 (so-0/0/3 ou 10.0.49.2.

Saída de amostra

A saída de amostra a seguir é de R7, que é usado no caminho de desvio na rede mostrado em desvios de backup de um para um:

Significado

A saída de amostra mostra as mesmas informações de um roteador de R7 trânsito regular usado no caminho primário do LSP: o endereço de entrada (192.168.1.1), o endereço de saída (192.168.5.1 ) e o nome do LSP (r1-to-r5). Dois caminhos de desvio são exibidos; o primeiro a evitar R4 (192.168.4.1) e o segundo a evitar R2 (192.168.2.1). Porque R7 é usado como um roteador de trânsito por R2 e R4, R7 pode mesclar os caminhos de desvio juntos, conforme indicado pelo valor idêntico Label out (100368) para ambos os caminhos de desvio. Não importa se R7 recebe tráfego R4 com um valor de rótulo de 100736 ou de R2 um valor de rótulo de 100752, R7 encaminha o pacote para R5 com um valor de rótulo de 100368.

Saída de amostra

A saída de amostra a seguir é da R9, que é um roteador usado no caminho de desvio na rede mostrado em desvios de backup de um para um:

Significado

A saída de amostra mostra R9 que R9 é o penúltimo roteador para o caminho de desvio, a rota explícita inclui apenas o endereço de link de saída (10.0.59.1) e o Label out valor (3) indica que R9 realizou o penúltimo salto de rótulo estalando. Além disso, a filial de desvio não inclui informações de 10.0.27.1 caminho porque R7 fundiu os caminhos de desvio de R2 e R4. Observe que o Label out valor na filial de 10.0.17.13 desvio é 100368, o mesmo valor que o Label out valor em R7.

Saída de amostra

A saída de amostra a seguir é do roteador de saída R5 na rede mostrada em desvios de backup de um para um:

Significado

A saída de R5 amostra mostra o LSP principal no Record route campo e os desvios pela rede.

Verifique se o caminho principal está operacional

Propósito

Os caminhos primários devem ser sempre usados na rede se estiverem disponíveis, portanto, um LSP sempre volta para o caminho principal após uma falha, a menos que a configuração seja ajustada. Para obter mais informações sobre como ajustar a configuração para evitar que um caminho primário fracassado seja restabelecido, veja Prevenção do uso de um caminho que falhou anteriormente.

Ação

Para verificar se o caminho principal está operacional, insira os seguintes comandos de modo operacional de interface de linha de comando (CLI) do Junos OS:

Saída de amostra 1

nome de comando

Saída de amostra 2

nome de comando

Significado

A saída de amostra 1 mostra que o LSP está operacional e está usando o caminho primário (via-r2) com R2 (10.0.12.14) e R4 (10.0.24.2) como roteadores de trânsito. Os valores de prioridade são os mesmos para configuração e espera, 6 6. A prioridade 0 é a mais alta (melhor) prioridade e 7 é a menor (pior) prioridade. O padrão do Junos OS para a configuração e a prioridade de espera é 7:0. A menos que alguns LSPs sejam mais importantes do que outros, preservar o padrão é uma boa prática. Configurar uma prioridade de configuração que seja melhor do que a prioridade de espera não é permitida, resultando em um compromisso fracassado, a fim de evitar loops de preempção.

Verifique se o caminho secundário está estabelecido

Propósito

Quando o caminho secundário estiver configurado com a standby declaração, o caminho secundário deve estar ativo , mas não ativo; ele se tornará ativo se o caminho primário falhar. Um caminho secundário configurado sem a standby declaração não surgirá a menos que o caminho primário falhe. Para testar se o caminho secundário está configurado corretamente e surgiria se o caminho principal falhasse, você deve desativar um link ou nó crítico para o caminho primário e, em seguida, emitir o show mpls lsp lsp-path-name extensive comando.

Ação

Para verificar se o caminho secundário está estabelecido, insira o seguinte comando de modo operacional Junos OS CLI:

Saída de amostra

Saída de amostra

nome de comando

A saída de amostra a seguir mostra um caminho secundário configurado corretamente antes e depois de aparecer. No exemplo, a interface fe-0/1/0 é R2 desativada, o que reduz o caminho via-r2principal. O roteador R1 de entrada muda o tráfego para o caminho via-r7secundário.

Significado

A saída de amostra do roteador R1 de saída mostra um caminho secundário de standby configurado corretamente em um estado de baixa porque o caminho primário ainda está em alta. Após a desativação de uma interface (interface fe-0/1/0 on R2) crítica para o caminho primário, o caminho via-r2 primário desce e o caminho via-r7 secundário de espera surge, permitindo R1 mudar o tráfego para o caminho secundário em standby.

Verificando a camada física

Propósito

Depois de configurar o LSP, emitir o show mpls lsp extensive comando e determinar que há um erro, você pode começar a investigar o problema na camada física da rede.

Figura 3 ilustra a camada física do modelo MPLS em camadas.

Figura 3: Verificando a camada físicaVerificando a camada física

Com essa camada, você deve garantir que os roteadores estejam conectados, e que as interfaces estejam ativas e configuradas corretamente nos roteadores de entrada, saída e trânsito.

Se a rede não estiver funcionando nesta camada, o caminho comutada por rótulos (LSP) não funcionará como configurado.

Figura 4 ilustra a rede MPLS e o problema descrito neste tópico.

Figura 4: Rede MPLS quebrada na camada físicaRede MPLS quebrada na camada física

A rede mostrada Figura 4 é uma configuração totalmente malhada onde cada interface diretamente conectada pode receber e enviar pacotes para todas as outras interfaces semelhantes. O LSP nesta rede está configurado para ser executado desde o roteador R1de entrada, pelo roteador R3de trânsito até o roteador R6de saída. Além disso, um LSP reverso é configurado para ser executado de R6 até R3R1, criando tráfego bidirecional.

No entanto, neste exemplo, o tráfego não usa o LSP configurado. Em vez disso, o tráfego usa a rota alternativa de R1 até R2R6, e na direção inversa, de R6 até R5 to R1.

Quando você tomar conhecimento de uma situação em que uma rota alternativa é usada em vez do LSP configurado, verifique se a camada física está funcionando corretamente. Você pode descobrir que os roteadores não estão conectados, ou que as interfaces não estão ativas e configuradas corretamente na entrada, saída ou roteadores de trânsito.

A cruz mostrada Figura 4 indica onde o LSP está quebrado devido a um erro de configuração no roteador R1de entrada.

Para verificar a camada física, siga essas etapas:

Verifique o LSP

Propósito

Normalmente, você usa o show mpls lsp extensive comando para verificar o LSP. No entanto, para uma verificação rápida do estado LSP, use o show mpls lsp comando. Se o LSP estiver desativado, use a opção extensive (show mpls lsp extensive) como acompanhamento. Se sua rede tiver vários LSPs, você pode considerar especificar o nome do LSP, usando a opção name (show mpls lsp name name ou show mpls lsp name name extensive).

Ação

Para determinar se o LSP está funcionando, insira o seguinte comando do roteador de entrada:

Saída de amostra
nome de comando

Significado

A saída de amostra do roteador R1 de entrada mostra que o LSP está usando um caminho alternativo em vez do caminho configurado. O caminho configurado para o LSP é R1 até R3R6, e para o LSP reverso, R6 até R3R1. O caminho alternativo usado pelo LSP é R1 até R2 e para o LSP reverso,para R6 t R5 R1.R6,

Verificar a conexão do roteador

Propósito

Confirme que os roteadores de entrada, trânsito e saída apropriados estão funcionando examinando se os pacotes foram recebidos e transmitidos com perda de pacotes de 0%.

Ação

Para determinar se os roteadores estão conectados, insira o seguinte comando a partir da entrada e dos roteadores de trânsito:

Saída de amostra
nome de comando

Significado

A saída de amostra mostra que o roteador R1 de entrada está recebendo pacotes do roteador R3de trânsito, e que o roteador de trânsito está recebendo pacotes do roteador de saída. Portanto, os roteadores do LSP estão conectados.

Verificar interfaces

Propósito

Confirme se as interfaces estão configuradas corretamente com a family mpls declaração.

Ação

Para determinar se as interfaces relevantes estão ativas e configuradas corretamente, insira os seguintes comandos a partir dos roteadores de entrada, trânsito e saída:

Saída de amostra
nome de comando

Significado

A saída de amostra mostra que a interface so-0/0/2.0 no roteador de entrada não tem a family mpls declaração configurada no nível [edit interfaces type-fpc/pic/port] de hierarquia, indicando que a interface está configurada incorretamente para oferecer suporte ao LSP. O LSP está configurado corretamente no nível [edit protocols mpls] de hierarquia.

A saída dos roteadores de trânsito e saída (não mostrado) mostra que as interfaces nesses roteadores estão configuradas corretamente.

Tome as medidas apropriadas

Problema

Descrição

Dependendo do erro que você encontrou em sua investigação, você deve tomar as medidas apropriadas para corrigir o problema. No exemplo abaixo, a family mpls declaração, que estava ausente, está incluída na configuração do roteador R1de entrada.

Solução

Para corrigir o erro neste exemplo, insira os seguintes comandos:

Saída de amostra
Significado

A saída de amostra do roteador R1 de entrada mostra que a family mpls declaração está configurada corretamente para interface so-0/0/2.0, e que o LSP está funcionando como configurado originalmente.

Verifique o LSP novamente

Propósito

Após tomar as medidas apropriadas para corrigir o erro, o LSP precisa ser verificado novamente para confirmar que o problema na camada física foi resolvido.

Ação

Para verificar se o LSP está funcionando e atravessando a rede como esperado, entre no seguinte comando:

Saída de amostra 1
nome de comando
Saída de amostra 2
nome de comando

Significado

A saída de amostra 1 do roteador R1 de entrada mostra que o LSP está agora atravessando a rede ao longo do caminho esperado, de R1 até R6R3 , e o LSP reverso, de R6 até R3R1.

A saída de amostra 2 do roteador R1 de entrada mostra que o LSP é forçado a tomar o caminho pretendido porque o MPLS é desativado em R1 interfaces so-0/0/0.0 e so-0/0/1.0. Se essas interfaces não fossem desativadas, mesmo que a configuração agora esteja correta, o LSP ainda atravessaria a rede pelo caminho alternativo.

Verificando as camadas de IP e IGP

Problema

Descrição

Depois de configurar o caminho comuto de rótulo (LSP), emitiu o show mpls lsp extensive comando e determinou que há um erro, você pode descobrir que o erro não está nas camadas físicas ou de link de dados. Continue investigando o problema nas camadas IP e IGP da rede.

Figura 7 ilustra as camadas IP e IGP do modelo MPLS em camadas.

Figura 7: Camadas de IP e IGPCamadas de IP e IGP

Solução

Nas camadas IP e IGP, você deve verificar o seguinte:

  • As interfaces têm endereçamento ip correto, e os vizinhos ou adjacências do IGP estão estabelecidos.

  • Os protocolos Open Shortest Path First (OSPF) ou Intermediate System-to-Intermediate System (IS-IS) estão configurados e executados corretamente.

    • Se o protocolo OSPF estiver configurado, verifique a camada DE IP primeiro e depois a configuração do OSPF, certificando-se de que o protocolo, as interfaces e a engenharia de tráfego estejam configurados corretamente.

    • Se o protocolo IS-IS estiver configurado, não importa se você verifica o IS-IS ou o IP primeiro porque ambos os protocolos são independentes um do outro. Verifique se as adjacências IS-IS estão ativas e se as interfaces e o protocolo IS-IS estão configurados corretamente.

      Nota:

      O protocolo IS-IS tem a engenharia de tráfego habilitada por padrão.

Se a rede não estiver funcionando nas camadas IP ou IGP, o LSP não funcionará como configurado.

Figura 8 ilustra a rede MPLS usada neste tópico.

Figura 8: Rede MPLS quebrada nas camadas IP e IGPRede MPLS quebrada nas camadas IP e IGP

A rede mostrada Figura 8 é uma configuração totalmente malhada onde cada interface diretamente conectada pode receber e enviar pacotes para todas as outras interfaces semelhantes. O LSP nesta rede está configurado para ser executado desde o roteador R1de entrada, pelo roteador R3de trânsito até o roteador R6de saída. Além disso, um LSP reverso é configurado para ser executado de R6, por R3, para R1, criando tráfego bidirecional. As cruzes indicam Figura 8 onde o LSP não está funcionando devido aos seguintes problemas na camada IP e IGP:

  • Um endereço IP está configurado incorretamente no roteador de entrada (R1).

  • O protocolo OSPF está configurado com um ID de roteador (RID), mas sem a interface de loopback (lo0) e a engenharia de tráfego está faltando no roteador de trânsito (R3).

  • Os níveis na rede IS-IS são incompatíveis.

Verificando a camada de IP

Propósito

Você pode verificar a camada de IP antes ou depois de verificar a camada de protocolo de gateway interior (IGP), dependendo se você tem OSPF ou IS-IS configurados como IGP. Se sua rede MPLS estiver configurada com o OSPF como IGP, você deve primeiro verificar a camada DE IP, verificar se as interfaces têm endereço IP correto e se os vizinhos OSPF estão estabelecidos antes de verificar a camada OSPF.

Se você tiver o IS-IS configurado como o IGP em sua rede MPLS, você pode verificar a camada de IP ou a camada de protocolo IS-IS primeiro. A ordem em que você verifica a camada IP ou IS-IS não afeta os resultados.

Figura 9: Rede MPLS quebrada na camada de IPRede MPLS quebrada na camada de IP

A cruz Figura 9 indica onde o LSP está quebrado devido à configuração incorreta de um endereço IP no roteador R1de entrada.

Verifique o LSP

Propósito

Após a configuração do LSP, você deve verificar se o LSP está funcionando. Os LSPs podem ser de entrada, trânsito ou saída. Use o show mpls lsp comando para verificação rápida do estado LSP, com a opção extensive (show mpls lsp extensive) como acompanhamento se o LSP estiver desativado. Se sua rede tiver vários LSPs, você pode considerar especificar o nome do LSP, usando a opção name (show mpls lsp name name ou show mpls lsp name name extensive).

Ação

Para verificar se o LSP está funcionando, insira o seguinte comando do roteador de entrada:

Saída de amostra 1
nome de comando

Significado

A saída de amostra do roteador R1 de entrada mostra que ocorreu uma falha na alocação de rótulos MPLS e a falha do algoritmo de caminho mais curto limitado primeiro (CSPF), resultando em nenhuma rota para o destino 10.0.0.6R6.

Verificar a endereçamento de IP

Propósito

Ao investigar a camada IP, você verifica se as interfaces têm endereçamento ip correto e que os vizinhos OSPF ou adjacências IS-IS estão estabelecidos. Neste exemplo, um endereço IP é configurado incorretamente no roteador de entrada (R1).

Ação

Para verificar o endereçamento IP, insira o seguinte comando dos roteadores de entrada, trânsito e saída:

Saída de amostra
nome de comando

Significado

A saída de amostra mostra que os endereços IP para interface so-0/0/2.0 em R1 e interface R3so-0/0/2.0 são idênticos. Os endereços IP de interface em uma rede devem ser exclusivos para que a interface seja identificada corretamente.

Verifique vizinhos ou Adjacências na camada IP

Propósito

Se o endereçamento de IP estiver configurado incorretamente, os vizinhos OSPF ou as adjacências IS-IS precisam ser verificados para determinar se um ou ambos estão estabelecidos.

Ação

Para verificar os vizinhos (OSPF) ou adjacências (IS-IS), insira os seguintes comandos a partir dos roteadores de entrada, trânsito e saída:

Saída de amostra 1
nome de comando
Saída de amostra 2
nome de comando

Significado

A saída de amostra 1 dos roteadores de entrada, trânsito e saída mostra isso R1 e R3 não são vizinhos osPF estabelecidos. Considerando que as duas interfaces so-0/0/2.0 (R1 e R3) estão configuradas com endereços IP idênticos, você esperaria isso. O protocolo OSPF roteia pacotes IP baseados apenas no endereço IP de destino contido no cabeçalho de pacote IP. Portanto, endereços IP idênticos no sistema autônomo (AS) resultam em vizinhos que não estabelecem.

A saída de amostra 2 dos roteadores de entrada, trânsito e saída mostra isso R1 e R3 estabeleceu uma adjacência IS-IS, apesar dos endereços IP idênticos configurados em interfaces so-0/0/2.0R1 e R3. O protocolo IS-IS se comporta de forma diferente do protocolo OSPF porque não depende do IP para estabelecer uma adjacência. No entanto, se o LSP não estiver funcionando, ainda é útil verificar o endereçamento de sub-rede IP caso haja um erro nessa camada. Corrigir o erro de endereçamento pode trazer o LSP de volta.

Tome as medidas apropriadas

Problema

Descrição

Dependendo do erro que você encontrou em sua investigação, você deve tomar as medidas apropriadas para corrigir o problema. Neste exemplo, o endereço IP de uma interface no roteador R2 de trânsito está configurado incorretamente.

Solução

Para corrigir o erro neste exemplo, insira os seguintes comandos:

Saída de amostra
Significado

A saída de amostra mostra que a interface so-0/0/2 no roteador R1 de entrada agora está configurada com o endereço IP correto. Essa correção resulta em endereços IP de sub-rede exclusivos para todas as interfaces da rede MPLS na rede MPLS quebrada nas camadas IP e IGP, e a possibilidade de que o LSP possa surgir.

Verifique o LSP novamente

Propósito

Após tomar as medidas apropriadas para corrigir o erro, o LSP precisa ser verificado novamente para confirmar que o problema no protocolo OSPF foi resolvido.

Ação

Para verificar o LSP novamente, insira o seguinte comando nos roteadores de entrada, trânsito e saída:

Saída de amostra 1
nome de comando
Saída de amostra 2
nome de comando
Saída de amostra 3
nome de comando

Significado

A saída de amostra 1 do roteador R1 de entrada mostra que o LSP R1-to-R6 tem uma rota ativa para R6 e o estado está em alta. A saída mostra que a sessão R6-to-R1 LSP de saída recebeu e enviou um rótulo de recuperação.

A saída de amostra 2 do roteador R3 de trânsito mostra que existem duas sessões de LSP de trânsito, uma de R1 para R6 e outra de R6 ambos R1. os LSPs estão ativas.

A saída de amostra 3 do roteador R6 de saída mostra que o LSP está ativo e a rota ativa é a rota principal. O LSP agora está atravessando a rede ao longo do caminho esperado, de R1 até R6R3 , e o LSP reverso, de R6 até R1R3 .

Verifique o LSP novamente

Propósito

Após tomar as medidas apropriadas para corrigir o erro, o LSP precisa ser verificado novamente para confirmar que o problema no protocolo IS-IS foi resolvido.

Ação

Para verificar se o LSP está funcionando e atravessando a rede como esperado, insira o seguinte comando a partir dos roteadores de entrada, saída e trânsito:

Saída de amostra

nome de comando

Significado

A saída amostral do roteador R1 de entrada e do roteador R6 de saída mostra que o LSP está agora atravessando a rede ao longo do caminho esperado, de R1 até R6R3 , e o LSP reverso, de R6 até R3R1. Além disso, a saída amostral do roteador R3 de trânsito mostra que existem duas sessões de LSP de trânsito, uma de R1 para R6, e a outra de R6 para R1.

Verificando a camada RSVP

Propósito

Depois de configurar o caminho comutada por rótulos (LSP), emitir o show mpls lsp extensive comando e determinar que há um erro, você pode descobrir que o erro não está nas camadas física, de link de dados ou de protocolo de Internet (IP) e de protocolo de gateway interior (IGP). Continue investigando o problema na camada RSVP da rede.

Figura 10 ilustra a camada RSVP do modelo MPLS em camadas.

Figura 10: Verificando a camada RSVPVerificando a camada RSVP

Com essa camada, você verifica se a sinalização RSVP dinâmica está ocorrendo como esperado, os vizinhos estão conectados e as interfaces estão configuradas corretamente para RSVP. Verifique a entrada, a saída e os roteadores de trânsito.

Se a rede não estiver funcionando nesta camada, o LSP não funcionará como configurado.

Figura 11 ilustra a rede MPLS usada neste tópico.

Figura 11: Rede MPLS quebrada na camada RSVPRede MPLS quebrada na camada RSVP

A rede mostrada Figura 11 é uma configuração totalmente malhada onde cada interface diretamente conectada pode receber e enviar pacotes para todas as outras interfaces semelhantes. O LSP nesta rede está configurado para ser executado desde o roteador R1de entrada, pelo roteador R3de trânsito até o roteador R6de saída. Além disso, um LSP reverso é configurado para ser executado de R6 até R3R1, criando tráfego bidirecional.

No entanto, neste exemplo, o LSP está desativado sem um caminho em qualquer direção, de R1 para R6 ou de R6 para R1.

As cruzes mostradas indicam Figura 11 onde o LSP está quebrado. Algumas possíveis razões pelas quais o LSP está quebrado podem incluir que a sinalização RSVP dinâmica não está ocorrendo como esperado, os vizinhos não estão conectados ou as interfaces estão configuradas incorretamente para RSVP.

Na rede em Figura 11, um erro de configuração no roteador R3 de trânsito impede o LSP de atravessar a rede como esperado.

Para verificar a camada RSVP, siga essas etapas:

Verifique o LSP

Propósito

Normalmente, você usa o show mpls lsp extensive comando para verificar o LSP. No entanto, para uma verificação rápida do estado LSP, use o show mpls lsp comando. Se o LSP estiver desativado, use a opção extensive (show mpls lsp extensive) como acompanhamento. Se sua rede tiver vários LSPs, você pode considerar especificar o nome do LSP, usando a opção name (show mpls lsp name name ou show mpls lsp name name extensive).

Ação

Para determinar se o LSP está funcionando, insira o seguinte comando do roteador de entrada:

Saída de amostra 1
nome de comando

Significado

A saída de amostra mostra que o LSP está baixo em ambas as direções, de R1 para R6, e de R6 para R1. A saída mostra R1 que R1 está usando um LSP sem cspf desde que tentou originar a chamada sem conseguir chegar ao destino. A saída R6 mostra que o algoritmo De caminho mais curto limitado primeiro (CSPF) falhou, resultando em nenhuma rota para o destino 10.0.0.1.

Verificar sessões de RSVP

Propósito

Quando uma sessão de RSVP é criada com sucesso, o LSP é configurado ao longo dos caminhos criados pela sessão de RSVP. Se a sessão de RSVP não tiver sucesso, o LSP não funcionará como configurado.

Ação

Para verificar as sessões de RSVP ativas atualmente, insira o seguinte comando a partir dos roteadores de entrada, trânsito e saída:

Saída de amostra 1
nome de comando
Saída de amostra 2
nome de comando

Significado

A saída de amostra 1 de todos os roteadores mostra que nenhuma sessão de RSVP foi criada com sucesso, embora o LSP R6-to-R1 esteja configurado.

Em contraste com a saída de amostra 1e para ilustrar a saída correta, a saída de amostra 2 mostra a saída dos roteadores de entrada, trânsito e saída quando a configuração do RSVP está correta, e o LSP está atravessando a rede conforme configurado. R1 e R6 ambos mostram uma sessão de RSVP de entrada e saída, com o LSP R1-to-R6e o LSP reverso R6-to-R1. O roteador R3 de trânsito mostra duas sessões de RSVP de trânsito.

Verifique os vizinhos do RSVP

Propósito

Exibir uma lista de vizinhos RSVP que foram aprendidos dinamicamente ao trocar pacotes RSVP. Assim que um vizinho é aprendido, ele nunca é removido da lista de vizinhos RSVP a menos que a configuração do RSVP seja removida do roteador.

Ação

Para verificar os vizinhos RSVP, insira o seguinte comando dos roteadores de entrada, trânsito e saída:

Saída de amostra 1
nome de comando
Saída de amostra 2
nome de comando

Significado

A saída de amostra 1 mostra isso R1 e R6 tem um vizinho RSVP cada, R3. No entanto, os valores no Up/Dn campo são diferentes. R1 tem um valor 1/0 e R6 tem um valor de 1/1, indicando que R1 é um vizinho ativo com R3, mas R6 não é. Quando a contagem em alta é uma a mais do que a contagem baixa, o vizinho está ativo; se os valores forem iguais, o vizinho está desativado. Os valores são R6 iguais, 1/1indicando que o vizinho R3 está desativado.

O roteador R3 de trânsito sabe sobre dois vizinhos, R1 e R6. O Up/Dn campo indica que R1 é um vizinho ativo e R6 está desativado. Neste ponto, não é possível determinar se o problema reside R3 ou R6porque ambos os vizinhos não estão ativos.

Em contraste com a saída de amostra 1 e para ilustrar a saída correta, a saída de amostra 2 mostra a relação correta entre o roteador R3 de trânsito e o roteador R6de saída. O Up/Dn campo mostra que a contagem em alta é uma a mais do que a contagem regressiva, 1/0indicando que os vizinhos estão ativos.

Verifique as interfaces RSVP

Propósito

Exibir o status de cada interface em que o RSVP está habilitado para determinar onde ocorreu o erro de configuração.

Ação

Para verificar o status das interfaces RSVP, insira o seguinte comando a partir dos roteadores de entrada, trânsito e saída:

Saída de amostra 1
nome de comando
Saída de amostra 2
nome de comando

Significado

A saída de amostra 1 mostra que, embora cada roteador tenha interfaces ativas e com RSVP ativo, não há reservas (Active resv) em nenhum dos roteadores. Neste exemplo, esperamos pelo menos uma reserva nos roteadores de entrada e saída, e duas reservas no roteador de trânsito.

Além disso, a interface so-0/0/3 no roteador R3 de trânsito não está incluída na configuração. A inclusão dessa interface é fundamental para o sucesso do LSP.

Em contraste com a saída de amostra 1 e para ilustrar a saída correta, a saída de amostra 2 mostra as interfaces relevantes com reservas ativas.

Verifique a configuração do protocolo RSVP

Propósito

Depois de verificar sessões de RSVP, interfaces, vizinhos e determinar que pode haver um erro de configuração, verifique a configuração do protocolo RSVP.

Ação

Para verificar a configuração do RSVP, insira o seguinte comando dos roteadores de entrada, trânsito e saída:

Saída de amostra
nome de comando

Significado

A saída de amostra mostra que R3 falta interface so-0/0/3.0 na configuração do protocolo RSVP. Essa interface é essencial para o funcionamento correto do LSP.

Tome as medidas apropriadas

Problema

Descrição

Dependendo do erro que você encontrou em sua investigação, você deve tomar as medidas apropriadas para corrigir o problema. Neste exemplo, falta uma interface na configuração do roteador R3.

Solução

Para corrigir o erro neste exemplo, siga essas etapas:

  1. Inclua a interface ausente na configuração do roteador de trânsito R3:

  2. Verifique e confirme a configuração:

Saída de amostra
Significado

A saída de amostra mostra que a interface so-0/0/3.0 ausente no roteador R3 de trânsito está agora corretamente incluída no nível [edit protocols rsvp] de hierarquia. Isso resulta na possibilidade de que o LSP possa surgir.

Verifique o LSP novamente

Propósito

Após tomar as medidas apropriadas para corrigir o erro, o LSP precisa ser verificado novamente para confirmar que o problema na camada MPLS foi resolvido.

Ação

Para verificar o LSP novamente, insira o seguinte comando nos roteadores de entrada, trânsito e saída:

Saída de amostra 1
nome de comando
Saída de amostra 2
nome de comando
Saída de amostra 3
nome de comando

Significado

A saída de amostra 1 do roteador R1 de entrada mostra que o LSP R1-to-R6 tem uma rota ativa para R6 e o estado está em alta.

A saída de amostra 2 do roteador R3 de trânsito mostra que existem duas sessões de LSP de trânsito, uma de R1 ida e R6 outra de R6 para R1. Ambos os LSPs estão funcionando.

A saída de amostra 3 do roteador R6 de saída mostra que o LSP está ativo e a rota ativa é a rota principal. O LSP agora está atravessando a rede ao longo do caminho esperado, de R1 até R6R3 , e o LSP reverso, de R6 até R1R3 .

Determinação das estatísticas do LSP

Propósito

Exibir informações detalhadas sobre objetos RSVP para ajudar no diagnóstico de um problema de LSP.

Ação

Para verificar os objetos RSVP, insira o seguinte comando de modo operacional Junos OS CLI:

Saída de amostra

nome de comando

Significado

A saída de amostra mostra que há uma sessão de RSVP de entrada e uma saída. A sessão de entrada tem um endereço fonte de 10.0.0.1 (R1), e a sessão está ativa, com uma rota ativa. O nome LSP é R1-to-R6 e é o caminho principal para o LSP.

O rótulo de recuperação (100064) é enviado por um roteador de reinicialização gracioso para o vizinho para recuperar um estado de encaminhamento. É provavelmente o rótulo antigo que o roteador anunciou antes de cair.

Esta sessão está usando o estilo de reserva de filtro fixo (FFResv style). Como este é um roteador de entrada, não há rótulo de entrada. O rótulo de saída (fornecido pelo próximo roteador downstream) é 100064.

O Time Left campo fornece o número de segundos restantes na sessão RSVP, e o Tspec objeto fornece informações sobre a taxa de carga controlada (rate) e o tamanho máximo de explosão (peak), um valor infinito (Infbps) para a opção de entrega garantida, e a indicação de que pacotes menores que 20 bytes são tratados como 20 bytes, enquanto pacotes maiores que 1500 bytes são tratados como 1500 bytes.

O número de porta é o ID do túnel IPv4, enquanto o número de porta de remetente/receptor é o ID LSP. O ID do túnel IPv4 é único para a vida útil do LSP, enquanto o ID LSP do remetente/receptor pode mudar, por exemplo, com uma reserva de estilo SE.

O PATH rcvfrom campo inclui a origem da mensagem do caminho. Como este é o roteador de entrada, o cliente local originou a mensagem do caminho.

O PATH sentto campo inclui o destino da mensagem de caminho (10.1.13.2) e a interface de saída (so-0/0/2.0). O RESV rcvfrom campo inclui tanto a fonte da mensagem Resv recebida (10.1.13.2) quanto a interface de entrada (so-0/0/2.0).

A rota explícita do RSVP e os valores de registro de rota são idênticos: 10.1.13.2 e 10.1.36.2... Na maioria dos casos, a rota explícita e os valores de rota de registro são idênticos. As diferenças indicam que algum redirecionamento de caminho ocorreu, normalmente durante o Fast-Reroute.

Os Total campos indicam o número total de sessões de RSVP de entrada, saída e trânsito, com o total sendo igual à soma das sessões para cima e para baixo. Neste exemplo, há uma sessão de entrada, uma sessão de saída e nenhuma sessões de RSVP de trânsito.

Verificando o uso de LSP em sua rede

Propósito

Quando você verifica o uso válido de um LSP nos roteadores de entrada e trânsito em sua rede, você pode determinar se há um problema com a comutação de rótulos multiprotocol (MPLS) em sua rede. Figura 12 descreve a rede de exemplo usada neste tópico.

Figura 12: Topologia MPLS para verificar o uso de LSPTopologia MPLS para verificar o uso de LSP

A rede Figura 12 MPLS ilustra uma rede somente de roteador com interfaces SONET que consistem nos seguintes componentes:

  • Uma topologia de protocolo de gateway de borda interior (IBGP) de malha completa, usando AS 65432

  • MPLS e O Protocolo de Reserva de Recursos (RSVP) habilitados em todos os roteadores

  • Uma send-statics política sobre roteadores R1 e R6 que permite que uma nova rota seja anunciada na rede

  • Um LSP entre os roteadores R1 e R6

A rede mostrada Figura 12 é uma rede full-mesh do Border Gateway Protocol (BGP). Como refletores de rota e confederações não são usados para propagar rotas aprendidas no BGP, cada roteador deve ter uma sessão BGP com todos os outros roteadores em execução BGP.

Para verificar o uso de LSP em sua rede, siga estas etapas:

Verificando um LSP no roteador de entrada

Propósito

Você pode verificar a disponibilidade de um LSP quando estiver em funcionamento examinando a inet.3 tabela de roteamento no roteador de entrada. A inet.3 tabela de roteamento contém o endereço de host do roteador de saída de cada LSP. Esta tabela de roteamento é usada em roteadores de entrada para rotear pacotes BGP para o roteador de saída de destino. O BGP usa a inet.3 tabela de roteamento no roteador de entrada para ajudar a resolver endereços de próximo salto.

Ação

Para verificar um LSP em um roteador de entrada, insira o seguinte comando de modo operacional de interface de linha de comando (CLI) do Junos OS:

Saída de amostra
nome de comando

Significado

A saída de amostra mostra a inet.3 tabela de roteamento. Por padrão, apenas as redes virtuais privadas (VPNs) BGP e MPLS podem usar a inet.3 tabela de rotas para resolver informações de próximo salto. Um destino está listado na tabela de rotas, 10.0.0.6. Este destino (10.0.0.6) é sinalizado pelo RSVP, e é o caminho ativo atual, conforme indicado pelo asterisco (*). A preferência do protocolo por esta rota é 7, e a métrica associada a ela é 20. O caminho comutada por rótulos é R1-to-R6, por interface so-0/0/2.0, que é a interface física de trânsito de próximo salto.

Normalmente, o penúltimo roteador do LSP coloca o rótulo do pacote ou altera o rótulo para um valor de 0. Se o penúltimo roteador colocar o rótulo superior e um pacote IPv4 estiver por baixo, o roteador de saída roteia o pacote IPv4, consultando a tabela inet.0 de roteamento IP para determinar como encaminhar o pacote. Se outro tipo de rótulo (como um criado pelo protocolo de distribuição de rótulos (LDP) ou VPNs, mas não o IPv4) estiver sob o rótulo superior, o roteador de saída não examinará a inet.0 tabela de roteamento. Em vez disso, examina a mpls.0 tabela de roteamento para decisões de encaminhamento.

Se o penúltimo roteador mudar o rótulo do pacote para um valor de 0, o roteador de saída tira o rótulo 0, indicando que um pacote IPv4 segue. O pacote é analisado pela inet.0 tabela de roteamento para decisões de encaminhamento.

Quando um roteador de trânsito ou saída recebe um pacote MPLS, as informações na tabela de encaminhamento MPLS são usadas para determinar o próximo roteador de trânsito no LSP ou se este roteador é o roteador de saída.

Quando o BGP resolve um prefixo de próximo salto, ele examina as tabelas e inet.3 o inet.0 roteamento, buscando o próximo salto com a menor preferência; por exemplo, a preferência do RSVP 7 é preferida em relação à preferência dos OSPF 10. O LSP sinalizado pelo RSVP é usado para alcançar o BGP no próximo salto. Este é o padrão quando o próximo salto BGP é igual ao endereço de saída LSP. Assim que o próximo salto BGP for resolvido por um LSP, o tráfego BGP usa o LSP para encaminhar o tráfego de trânsito BGP.

Verificando um LSP em um roteador de trânsito

Propósito

Você pode verificar a disponibilidade de um LSP quando estiver em funcionamento examinando a mpls.0 tabela de roteamento em um roteador de trânsito. O MPLS mantém a mpls.0 tabela de roteamento, que contém uma lista do próximo roteador comutada por rótulos em cada LSP. Esta tabela de roteamento é usada em roteadores de trânsito para rotear pacotes para o próximo roteador ao longo de um LSP.

Ação

Para verificar um LSP em um roteador de trânsito, insira o seguinte comando de modo operacional Junos OS CLI:

Saída de amostra
nome de comando

Significado

A saída de amostra do roteador R3 de trânsito mostra entradas de rota na forma de entradas de rótulo MPLS, indicando que há apenas uma rota ativa, embora existam cinco entradas ativas.

Os três primeiros rótulos MPLS são rótulos MPLS reservados definidos na RFC 3032. Os pacotes recebidos com esses valores de rótulo são enviados ao Mecanismo de Roteamento para processamento. Rótulo 0 é o rótulo nulo explícito IPv4. O rótulo 1 é o equivalente MPLS do rótulo de alerta de roteador IP e o Rótulo 2 é o rótulo nulo explícito IPv6.

As duas entradas com o 100064 rótulo são para o mesmo LSP, R1-to-R6. existem duas entradas porque os valores de pilha no cabeçalho MPLS podem ser diferentes. A segunda entrada 100064 (S=0)indica que a profundidade da pilha não é 1 e os valores adicionais do rótulo estão incluídos no pacote. Em contraste, a primeira entrada tem 100064 um S=1 inferido que indica uma profundidade de pilha de 1 e faz dele o último rótulo no pacote. A dupla entrada indica que este é o penúltimo roteador. Para obter mais informações sobre o empilhamento de rótulos MPLS, consulte RFC 3032, codificação MPLS Label Stack.

O rótulo de entrada é o cabeçalho MPLS do pacote MPLS, e é atribuído pelo RSVP ao vizinho upstream. Os roteadores da Juniper Networks atribuem rótulos dinamicamente para LSPs projetados por tráfego RSVP na faixa de 100.000 a 1.048.575.

O roteador atribui rótulos a partir do rótulo 100.000, em incrementos de 16. A sequência de atribuições de rótulos é de 100.000, 100.016, 100.032, 100.048 e assim por diante. Ao final das etiquetas atribuídas, os números do rótulo começam em 100001, incrementando em unidades de 16. A Juniper Networks reserva rótulos para várias finalidades. Tabela 1 lista as várias alocações de intervalo de rótulos para rótulos de entrada.

Tabela 1: Alocações de faixas de rótulo MPLS

Rótulo de entrada

Estado

0 através 15

Reservado pela IETF

16 através 1023

Reservado para atribuição de LSP estática

1024 através 9999

Reservado para uso interno (por exemplo, rótulos de CCC)

10,000 através 99,999

Reservado para atribuição de LSP estática

100,000 através 1,048,575

Reservado para atribuição dinâmica de rótulos

Verifique se o balanceamento de carga está funcionando

Propósito

Após a configuração do balanceamento de carga, verifique se o tráfego está equilibrado igualmente entre caminhos. Nesta seção, a saída de comando reflete a configuração de balanceamento de carga da rede de exemplo mostrada na topologia de rede de balanceamento de carga. Os clear comandos são usados para redefinir o LSP e os contadores de interface a zero para que os valores reflitam a operação da configuração de balanceamento de carga.

Ação

Para verificar o balanceamento de carga entre interfaces e LSPs, use o seguinte comando no roteador de entrada:

Para verificar o balanceamento de carga entre interfaces e LSPs, use os seguintes comandos em um roteador de trânsito:

Saída de amostra

nome de comando

A saída de amostra a seguir é para a configuração no roteador R1de entrada:

Significado

A saída de amostra para o show configuration comando no roteador R1 de entrada mostra que o balanceamento de carga está configurado corretamente com a declaração de lbpp política. Além disso, a lbpp política é exportada para a tabela de encaminhamento no nível hierárquicos [edit routing-options] .

Saída de amostra

A saída de amostra a seguir é do roteador de trânsito R2:

Significado

A saída de amostra para o show route comando emitido no roteador R2 de trânsito mostra os dois caminhos de custo igual (so-0/0/1 e so-0/0/2) através da rede até o endereço de loopback para R0 (192.168.0.1). Embora o suporte de ângulo reto (>) geralmente indique a rota ativa, neste caso ela não indica, como mostrado nas quatro saídas de amostra a seguir.

Saída de amostra

A saída de amostra a seguir é do roteador de trânsito R2:

Significado

A saída de amostra para o monitor interface traffic comando emitido no roteador R2 de trânsito mostra que o tráfego de saída é distribuído uniformemente pelas duas interfaces so-0/0/1 e so-0/0/2.

Saída de amostra

A saída de amostra a seguir é do roteador de trânsito R2:

Significado

A saída de amostra para o show mpls lsp statistics comando emitido no roteador R2 de trânsito mostra que o tráfego de saída é distribuído uniformemente pelos quatro LSPs configurados no roteador R6de entrada.

Saída de amostra

A saída de amostra a seguir é do roteador de trânsito R2:

Significado

A saída de amostra para o show route forwarding-table destination comando emitido no roteador R2 de trânsito mostra ulst no campo, o que indica que o Type balanceamento de carga está funcionando. Os dois unicast (ucst) entradas em Type campo são os dois próximos saltos para os LSPs.

Saída de amostra

A saída de amostra a seguir é do roteador de trânsito R2:

Significado

A saída de amostra para o show route forwarding-table | find mpls comando emitido no roteador de trânsito R2 mostra a tabela de roteamento MPLS que contém os rótulos recebidos e usados por este roteador para encaminhar pacotes para o roteador de próximo salto. Esta tabela de roteamento é usada principalmente em roteadores de trânsito para rotear pacotes para o próximo roteador ao longo de um LSP. As três primeiras etiquetas da Destination coluna (Rótulo 0, Rótulo 1 e Rótulo 2) são inseridas automaticamente pelo MPLS quando o protocolo é habilitado. Esses rótulos são rótulos MPLS reservados definidos no RFC 3032. Rótulo 0 é o rótulo nulo explícito IPv4. O rótulo 1 é o equivalente MPLS ao rótulo de alerta de roteador IP, e o Label 2 é o rótulo nulo explícito IPv6.

Os cinco rótulos restantes na Destination coluna são rótulos não atendidos que o roteador usa para encaminhar tráfego, e a última coluna Netifmostra as interfaces usadas para enviar o tráfego rotulado. Para rótulos não atendidos, a segunda Type coluna mostra a operação realizada em pacotes correspondentes. Neste exemplo, todos os pacotes não reservados são trocados por rótulos de pacotes de saída. Por exemplo, os pacotes com o rótulo 100112 têm seu rótulo trocado antes de serem empurrados para 100032 fora da interface so-0/0/1.0.

Verifique a operação do balanceamento de carga de largura de banda inigualável

Propósito

Quando um roteador está realizando balanceamento de carga de custo desigual entre caminhos LSPs, o show route detail comando exibe um campo de equilíbrio associado a cada salto seguinte sendo usado.

Ação

Para verificar se um RSVP LSP é desigualmente equilibrado com carga, use os seguintes comandos de modo operacional Junos OS CLI:

Saída de amostra

nome de comando

Significado

A saída de amostra do roteador R1 de entrada mostra que o tráfego é distribuído de acordo com a configuração de largura de banda LSP, conforme indicado pelo Balance: xx% campo. Por exemplo, lsp1 tem 10 Mbps de largura de banda configurados, conforme refletido no Balance: 10% campo.

Use o comando de traceroute para verificar rótulos MPLS

Propósito

Você pode usar o traceroute comando para verificar se os pacotes estão sendo enviados pelo LSP.

Ação

Para verificar as etiquetas MPLS, insira o seguinte comando de modo operacional Junos OS CLI, onde host-name está o endereço IP ou o nome do host remoto:

Saída de amostra 1

nome de comando

Saída de amostra 2

nome de comando

Significado

A saída de amostra 1 mostra que as etiquetas MPLS são usadas para encaminhar pacotes pela rede. Incluído na saída está um valor de rótulo (MPLS Label=100048), o valor de tempo de vida (TTL=1) e o valor de bit de pilha (S=1).

O MPLS Label campo é usado para identificar o pacote para um LSP específico. É um campo de 20 bits, com um valor máximo de (2^^20-1), ou aproximadamente 1.000.000.

O valor de TTL contém um limite no número de saltos que este pacote MPLS pode viajar pela rede (1). Ele é decremente decremente em cada salto, e se o valor de TTL cair abaixo de um, o pacote é descartado.

A parte inferior do valor de bit de pilha (S=1) indica que é o último rótulo na pilha e que este pacote MPLS tem um rótulo associado a ele. A implementação do MPLS no Junos OS oferece suporte a uma profundidade de empilhamento de 3 nos roteadores da série M e até 5 nas plataformas da série T. Para obter mais informações sobre o empilhamento de rótulos MPLS, consulte RFC 3032, codificação MPLS Label Stack.

As etiquetas MPLS aparecem em Sample Output 1 porque o traceroute comando é emitido para um destino BGP onde o próximo salto BGP para essa rota é o endereço de saída LSP. O comportamento padrão do Junos OS usa LSPs para tráfego BGP quando o próximo salto BGP é igual ao endereço de saída LSP.

A saída de amostra 2 mostra que as etiquetas MPLS não aparecem na saída para o traceroute comando. Se o próximo salto BGP não for igual ao endereço de saída LSP ou o destino for uma rota IGP, o tráfego BGP não usará o LSP. Em vez de usar o LSP, o tráfego BGP está usando o IGP (IS-IS, neste caso) para chegar ao endereço de saída (R6).

Resolução de problemas de GMPLS e túnel GRE

Problema

Descrição

O canal de controle lógico para GMPLS deve ser um link de ponto a ponto e deve ter alguma forma de acessibilidade ip. Em interfaces de transmissão ou quando houver vários saltos entre os pares do canal de controle, use um túnel GRE para o canal de controle. Para obter informações mais detalhadas sobre túneis GMPLS e GRE, consulte o Guia de configuração de aplicativos Junos MPLS e o Junos User Guide.

Um PIC de túnel não é necessário para configurar um túnel GRE para o canal de controle GMPLS. Em vez disso, use a interface baseada em gre software, em vez da interface baseada em gr-fpc/pic/port hardware.

CUIDADO:

Devido a restrições à interface baseada em gre software, o canal de controle GMPLS é o único uso suportado da interface baseada em gre software. Qualquer outro uso é expressamente sem suporte e pode causar uma falha no aplicativo.

O exemplo a seguir mostra uma configuração básica gre da interface. Neste caso, a fonte do túnel é o endereço de loopback do roteador local e o endereço de destino é o destino de loopback do roteador remoto. O tráfego que tiver um próximo salto do destino do túnel usará o túnel. O túnel não é usado automaticamente por todo o tráfego que passa pela interface. Apenas tráfego com o destino do túnel enquanto o próximo salto usa o túnel.

Saída de amostra

Saída de amostra

A saída de amostra a seguir para o comando de interfaces de exibição mostra o tipo e cabeçalho de encapsulamento, a velocidade máxima, os pacotes através da interface lógica, do destino e do endereço lógico.

Os requisitos a seguir são diversos quando você configura um LSP GMPLS usando um túnel GRE:

  • O canal de dados deve começar e terminar no mesmo tipo de interface.

  • O canal de controle pode ser um túnel GRE que começa e termina no mesmo tipo de interface ou diferente.

  • O túnel GRE deve ser configurado indiretamente com a peer-interface peer-name declaração no nível de [edit protocol ospf] hierarquia.

  • A interface GRE deve ser desabilitada nos [edit protocols ospf] níveis de [edit protocols rsvp] hierarquia.

  • Os canais de dados e controle devem ser definidos corretamente na configuração de LMP.

  • É opcional desabilitar o caminho mais curto limitado em primeiro lugar (CSPF) com a no-cspf declaração.

Este caso se concentra na configuração incorreta dos endpoints do túnel GRE. No entanto, você pode usar um processo e comandos semelhantes para diagnosticar outros problemas de túnel GRE. Figura 13 ilustra uma topologia de rede com MPLS em tunelamento por uma interface GRE.

Figura 13: Topologia de rede GMPLSTopologia de rede GMPLS

A topologia Figura 13 de rede MPLS mostra roteadores Juniper Networks configurados com um túnel GRE que consiste nos seguintes componentes:

  • Um caminho LSP GMPLS rigoroso desde o roteador de entrada até o roteador de saída.

  • No roteador de entrada, o CSPF desabilitou a no-cspf declaração no nível [edit protocol mpls label-switched-path lsp-name] de hierarquia.

  • Links de engenharia de tráfego e canais de controle dentro da peer declaração no nível de hierarquia emedit protocols link-management todos os roteadores.

  • Engenharia de tráfego OSPF e OSPF configurada em todos os roteadores.

  • Uma referência ao peer-interface OSPF e ao RSVP em todos os roteadores.

  • Um problema do tipo de comutação entreR2.R3

Sintoma

O LSP na rede mostrado Figura 13 está desativado, conforme indicado pela saída do show mpls lsp e show rsvp session comandos, que exibem informações muito semelhantes. O show mpls lsp comando mostra todos os LSPs configurados no roteador, bem como todos os LSPs de trânsito e saída. O show rsvp session comando exibe informações resumidas sobre sessões de RSVP. Você pode usar qualquer comando para verificar o estado do LSP. Neste caso, o LSP gmpls-r1-to-r3 está desativado (Dn).

Saída de amostra

Causa

A causa do problema com o GMPLS LSP é a configuração de diferentes tipos de interface em ambas as extremidades do canal de dados GMPLS.

Comandos de solução de problemas

O Junos OS inclui comandos que são úteis na resolução de problemas. Este tópico fornece uma breve descrição de cada comando, seguido pela saída de amostra e uma discussão sobre a saída em relação ao problema.

Você pode usar os seguintes comandos ao solucionar problemas de GMPLS:

Saída de amostra

Use o comando extensivo mpls lsp no roteador de trânsito R1 para exibir informações detalhadas sobre todos os LSPs que transitam, terminam e configurados no roteador.

Significado

A saída de amostra para o show mpls lsp extensive comando mostra uma mensagem de erro (MPLS label allocation failure) na seção de log da saída. Este evento LSP indica que o protocolo MPLS ou a family mpls declaração não foram configurados corretamente. Quando o evento LSP é precedido por um endereço IP, o endereço é tipicamente o roteador que tem o erro de configuração MPLS. Neste caso, parece que o roteador com o lo0 endereço de (R3) tem um erro de 192.168.4.1 configuração MPLS.

Saída de amostra

Use o comando de detalhes da sessão do rsvp show para exibir informações detalhadas sobre as sessões de RSVP.

Significado

A saída de amostra para o comando mostra que o show rsvp session detail LSP gmpls-r1-to-r3 está desativado (LSPstate: Dn). O registro da rota está incompleto, indicando um problema com a rota 100.100.100.100 93.93.93.93explícita. O endereço 100.100.100.100 é o canal de dados, R2 so-0/0/0e o endereço 93.93.93.93 é o canal de dados em R3.

Saída de amostra

Use o comando peer de gerenciamento de link show para exibir informações de link peer MPLS.

Significado

A saída de amostra de todos os roteadores na rede Figura 13 de exemplo para o show link-management peer comando mostra que todos os canais de controle estão ativos. Uma análise detalhada da saída mostra as seguintes informações:

  • Nome do peer outester3, tester2 que é o mesmo em roteadores vizinhos para facilitar a solução de problemas.

  • Identificador interno para peer, 48428 para tester2 e 48429 para tester3. O identificador interno é uma gama de valores de 0 a 64.000.

  • O estado do peer, que pode ser para cima ou para baixo. Neste caso, todos os pares estão em alta.

  • O endereço ao qual um canal de controle é estabelecido, por exemplo, 10.35.1.5.

  • O estado do canal de controle, que pode ser para cima, para baixo ou ativo.

  • Os links projetados por tráfego que são gerenciados por seus pares, indicando que o canal gre.0 de controle é gerenciado por tester3.

Saída de amostra

Use o comando te-link de gerenciamento de link show para exibir os recursos usados para configurar caminhos de encaminhamento projetados para tráfego multiprotocol Label Switching (MPLS).

Significado

A saída de amostra para o show link-management te-link comando emitido nos três roteadores da rede Figura 13 mostra os recursos alocados para os links te-tester2 projetados em tráfego e te-tester3. Os recursos são as interfaces so-0/0/0 SONET e so-0/0/1. on R1 e R2, tele interfaces SONET são usados para o LSP gmpls-r1-to-r3, como indicado no YesUsed campo.No entanto, a interface so-0/0/1 R3 SONET está baixa (Dn) e não é usada para o LSP (Used No). Uma investigação mais aprofundada é necessária para descobrir por que a interface R3 SONET está inativa.

Saída de amostra

Use o comando de log filename de exibição para exibir o conteúdo do arquivo de log especificado. Neste caso, o arquivo de log rsvp.log está configurado no nível de hierarquia [editar protocolos rsvp traceoptions]. Quando o arquivo de log estiver configurado, você deve emitir o comando de início filename do monitor para começar a registrar mensagens no arquivo.

Nota:

A opção find Error inscrita após o pipe ( | ) pesquisa a saída para uma instância do termo Erro.

Saída de amostra

Significado

A saída de amostra do roteador R3 de saída para o show log rsvp.log comando é um trecho retirado do arquivo de log. O trecho mostra uma solicitação de recursos do Link Management Protocol (LMP) para o LSP gmpls-r1-to-r3. A solicitação tem problemas com o tipo de codificação (SDH/SONET), indicando um possível erro com a conexão R2 da interface SONET e R3. Uma investigação mais aprofundada da configuração do LMP R2R3 é necessária.

Saída de amostra

Use o comando de configuração de exibição statement-path para exibir uma hierarquia de configuração específica; neste caso, o gerenciamento de enlaces.

Significado

A saída de amostra do roteador R2 de trânsito e do roteador R3 de entrada para o show configuration protocols link-management comando mostra que o tipo de interface nos dois roteadores é diferente. O recurso alocado no te-tester3 roteador R2 de trânsito é uma interface SONET, enquanto o recurso alocado te-tester3 no roteador R3 de saída é uma interface ATM. O tipo de interface em cada extremidade dos dados ou canais de controle deve ser do mesmo tipo. Neste caso, ambas as extremidades devem ser SONET ou ATM.

Solução

Solução

A solução para o problema de diferentes tipos de interface ou encapsulamento em ambas as extremidades do GMPLS LSP é garantir que o tipo de interface seja o mesmo em ambas as extremidades. Neste caso, a interface ATM foi excluída da configuração R3de gerenciamento de enlaces, e uma interface SONET foi configurada.

Os comandos a seguir ilustram a configuração e os comandos corretos para verificar se o GMPLS LSP está funcionando e usando o canal de dados:

Saída de amostra

Significado

A saída de amostra para , show protocols link-managementshow mpls lspe show link-management te-link comandos do roteador R3 de entrada mostram que o problema está resolvido. O LMP está configurado corretamente, e o LSP gmpls-r1-to-r3 está funcionando e usando o canal so-0/0/1de dados.

Conclusão

Em conclusão, ambas as extremidades de um canal de dados GMPLS devem ser o mesmo tipo de encapsulamento ou interface. Este caso ilustra a configuração correta do canal de dados. Os princípios são os mesmos para o canal de controle.

Configurações do roteador

Saída que mostra as configurações do roteador de entrada na rede. A opção no-more inserida após o tubo ( | ) impede que a saída seja paginada se a saída for maior do que o comprimento da tela terminal.

Saída de amostra

A saída de amostra a seguir é para o roteador de entrada R1:

Saída de amostra

A saída de amostra a seguir é para o roteador de trânsito R2:

Saída de amostra

A saída de amostra a seguir é para o roteador de saída R3:

Determinando o status do LSP

Exibir informações detalhadas sobre objetos do Protocolo de Reserva de Recursos (RSVP) e o histórico do caminho comuado por rótulos (LSP) para identificar um problema com o LSP.

Figura 14 ilustra a topologia de rede usada neste tópico.

Figura 14: Topologia de rede MPLSTopologia de rede MPLS

Para determinar o estado LSP, siga estas etapas:

Verifique a situação do LSP

Propósito

Exibir o status do pathe comuto de rótulo (LSP).

Ação

Para determinar o status de LSP, no roteador de entrada, insira o seguinte comando de modo operacional de interface de linha de comando (CLI) do Junos OS:

Saída de amostra
nome de comando

Significado

A saída de amostra é do roteador de entrada (R1) e mostra informações de entrada, saída e LSP de trânsito. As informações de entrada são para as sessões que se originam deste roteador, as informações de saída são para sessões que terminam neste roteador, e as informações de trânsito são para sessões que transitam por este roteador.

Há uma rota de entrada de R1 (10.0.0.1) para R6 (10.0.0.6). Essa rota está atualmente ativa e é uma rota ativa instalada na tabela de roteamento ().Rt O LSP R1-to-R6 é o caminho principal (P) em oposição ao caminho secundário, e é indicado por um asterisco (*). A rota para R6 não conter um caminho nomeado (ActivePath).

Há um LSP de saída de R6 .R1 O State está funcionando, sem rotas instaladas na tabela de roteamento. O estilo de reserva de RSVP (Style) consiste em duas partes. O primeiro é o número de reservas ativas (1). O segundo é o estilo de reserva, que é FF (filtro fixo). O estilo de reserva pode ser FF, SE (compartilhado explícito) ou WF (filtro curinga). Há três rótulos de entrada (Labelin) e nenhum rótulo saindo (Labelout) para este LSP.

Não há LSPs de trânsito.

Para obter mais informações sobre como verificar o estado do LSP, consulte Checklist para trabalhar com o modelo de solução de problemas MPLS em camadas.

Exibir status extensivo sobre o LSP

Propósito

Exibir informações extensas sobre LSPs, incluindo todo o histórico de estado passado e as razões pelas quais um LSP pode ter falhado.

Ação

Para exibir informações extensas sobre LSPs, no roteador de entrada, entre no seguinte comando de modo operacional Junos OS CLI:

Saída de amostra
nome de comando

Significado

A saída de amostra é do roteador de entrada (R1), e mostra informações de entrada, saída e trânsito LSP em detalhes, incluindo todo o histórico de estado passado e as razões pelas quais um LSP falhou. As informações de entrada são para sessões que se originam deste roteador, as informações de saída são para sessões que terminam neste roteador, e as informações de trânsito são para sessões que transitam por este roteador.

Há uma rota de entrada de R1 (10.0.0.1) para R6 (10.0.0.6). Esta rota está atualmente ativa (State), com uma rota ativamente usando o LSP, R1-to-R6. O caminho ativo do LSP é o caminho principal. Mesmo que o LSP não contenha uma ou secondary uma primary palavra-chave, o roteador ainda trata o LSP como um LSP primário, indicando que, se o LSP falhar, o roteador tentará sinalizar LSPs inativos em intervalos de 30 segundos, por padrão.

O balanceamento de carga é Random, que é o padrão, indicando que ao selecionar o caminho físico para um LSP, o roteador seleciona aleatoriamente entre caminhos de igual custo que têm uma contagem igual de saltos. Outras opções que você pode configurar são Least-fill e Most-fill. Least-fill coloca o LSP no link menos utilizado dos caminhos de igual custo com contagem igual de saltos. Most-fill coloca o LSP no link mais utilizado dos caminhos de igual custo compartilhando uma contagem igual de saltos. A utilização é baseada na porcentagem de largura de banda disponível.

O Encoding type campo mostra parâmetros de sinalização MPLS (GMPLS) generalizados (Packet)indicando IPv4. O Switching type é Packet, e o identificador de carga geral (GPID) é O IPv4.

O caminho principal é o caminho ativo, como indicado por um asterisco (*). O estado do LSP é Up.

O objeto de rota explícito (ERO) inclui o custo20 de caminho mais curto limitado primeiro (CSPF) para o caminho físico que o LSP segue. A presença da métrica de CSPF indica que se trata de um LSP CSPF. A ausência da métrica de CSPF indica um LSP sem CSPF.

O campo 10.1.13.2 S indica o ERO real. As mensagens de sinalização RSVP foram estritamente 10.1.13.2 (como um salto seguinte) e terminaram 10.1.36.2 estritamente. Todos os endereços ERO são saltos rigorosos quando o LSP é um LSP CSPF. Saltos soltos só podem ser exibidos em um LSP sem CSPF.

O objeto de rota de registro recebido (RRO) tem as seguintes bandeiras de proteção:

  • 0x01— Proteção local disponível. O link downstream deste nó é protegido por um mecanismo de reparo local. Esta bandeira só pode ser definida se a bandeira de proteção local foi definida no objeto SESSION_ATTRIBUTE da mensagem de caminho correspondente.

  • 0x02— Proteção local em uso. Um mecanismo de reparo local está em uso para manter este túnel (geralmente devido a uma interrupção do enlace em que foi roteado anteriormente).

  • 0x04— Proteção de largura de banda. O roteador downstream tem um caminho de backup que oferece a mesma garantia de largura de banda que o LSP protegido para a seção protegida.

  • 0x08— proteção contra nós. O roteador downstream tem um caminho de backup que oferece proteção contra falhas de enlace e nó na seção de caminho correspondente. Se o roteador downstream puder configurar apenas um caminho de backup de proteção de link, o bit "Proteção local disponível" será definido, mas o bit "proteção de nós" será liberado.

  • 0x10— Preemption pendente. O nó de antecipação define essa bandeira se uma preempção pendente estiver em andamento para o LSP projetado para tráfego. Isso indica ao roteador de borda de rótulo de entrada (LER) deste LSP que ele deve ser redirecionado.

Para obter mais informações sobre bandeiras de proteção, consulte os protocolos de roteamento Junos e a referência de comando de políticas.

O campo 10.1.13.2.10.1.36.2 é a rota real de registro recebido (RRO). Observe que os endereços em campo são compatíveis RRO com os de ERO campo. Este é o caso normal para LSPs CSPF. Se os endereços RRO e ERO não corresponderem a um LSP CSPF, o LSP precisa redirecionar ou desviar.

As linhas numeradas de 91 a 42 contêm as 49 entradas mais recentes no log histórico. Cada linha é carimbada. As entradas mais recentes têm o maior número de histórico de log e estão no topo do log, indicando que a linha 91 é a entrada de log mais recente da história. Ao ler o log, comece com a entrada mais antiga (42) para a mais recente (91).

O log de história foi iniciado em 10 de julho, e exibe a seguinte sequência de atividades: um LSP foi selecionado como ativo, foi constatado que estava desativado, a alocação de rótulos MPLS falhou várias vezes, foi excluído várias vezes, foi antecipado por causa de um ResvTear, foi deselecionado como ativo, e foi liberado. No final, o roteador computou um CSPF ERO, sinalizou a chamada, o LSP surgiu com o RRO listado (linha 90), e foi listado como ativo.

Para obter mais informações sobre mensagens de erro, consulte o Junos MPLS Network Operations Guide Log Reference.

O número total de LSPs de entrada exibidos é 1de 1 alta e 0 baixa. O número em Up campo mais o número em Down campo deve ser igual ao total.

Há uma sessão LSP de saída de R6 até R1. O State está funcionando, sem rotas instaladas na tabela de roteamento. O estilo de reserva de RSVP (Style) consiste em duas partes. O primeiro é o número de reservas ativas (1). O segundo é o estilo de reserva, que é FF (filtro fixo). O estilo de reserva pode ser FF, SE (compartilhado explícito) ou WF (filtro curinga). Há três rótulos de entrada (Labelin) e nenhum rótulo saindo (Labelout) para este LSP.

Não há LSPs de trânsito.

Para obter mais informações sobre como verificar o estado do LSP, consulte Checklist para trabalhar com o modelo de solução de problemas MPLS em camadas.

Verificando se as mensagens de caminho do RSVP são enviadas e recebidas

Propósito

A presença ou ausência de várias mensagens RSVP pode ajudar a determinar se há um problema com a comutação de rótulos multiprotocol (MPLS) em sua rede. Por exemplo, se as mensagens de caminho ocorrerem na saída sem mensagens Resv, pode indicar que caminhos comuados por rótulos (LSPs) não estão sendo criados.

Ação

Para verificar se as mensagens RSVP Path são enviadas e recebidas, insira o seguinte comando de modo operacional de interface de linha de comando (CLI) do Junos OS:

Saída de amostra

nome de comando

Significado

A saída de amostra mostra mensagens RSVP enviadas e recebidas. O número total de mensagens RSVP Path é de 11.4532 enviadas e 80.185 recebidas. Nos últimos 5 segundos, nenhuma mensagem foi enviada ou recebida.

Um total de 5 PathErr mensagens foram enviadas e 10 recebidas. Quando ocorrem erros de caminho (geralmente por causa de problemas de parâmetro em uma mensagem de caminho), o roteador envia uma mensagem de PathErr unicast para o remetente que emitiu a mensagem do caminho. Neste caso, R1 enviou pelo menos 10 mensagens de caminho com um erro, conforme indicado pelas 10 mensagens patherr que R1 receberam. O roteador downstream enviou R1 cinco mensagens de caminho com um erro, conforme indicado pelas cinco mensagens do PathErr enviadas R1 . As mensagens do PathErr transmitem na direção oposta às mensagens de caminho.

Um total de 12 PathTear mensagens foram enviadas e 6 recebidas, nenhuma nos últimos 5 segundos. Em contraste com as mensagens do PathErr, as mensagens do PathTear viajam na mesma direção que as mensagens de caminho. Como as mensagens de caminho são enviadas e recebidas, as mensagens do PathTear também são enviadas e recebidas. No entanto, se apenas as mensagens de caminho forem enviadas, apenas as mensagens PathTear que são enviadas aparecem na saída.

Um total de 80.515 mensagens de reserva (Resv) com o estilo de reserva de filtro fixo (FF) foram enviadas e 111.476 recebidas, nenhuma nos últimos 5 segundos. Um FF estilo de reserva indica que, em cada sessão, cada receptor estabelece sua própria reserva com cada remetente upstream, e que todos os remetentes selecionados estão listados. Nenhuma mensagem para o filtro curinga (WF) ou estilos de reserva explícitos compartilhados (SE) são enviados ou recebidos. Para obter mais informações sobre os estilos de reserva do RSVP, consulte o Guia de configuração de aplicativos Junos MPLS.

Outros tipos de mensagem RSVP não são enviados ou recebidos. Para obter informações sobre os tipos de mensagens ResvErr, ResvTear e Resvconf, consulte o Guia de configuração de aplicativos Junos MPLS.

As mensagens de atualização sumária (SRefresh) da Ack e sumária não aparecem na saída. As mensagens de atualização de resumo e Ack são definidas na RFC 2961 e fazem parte das extensões RSVP. As mensagens Ack são usadas para reduzir a quantidade de tráfego de controle de RSVP na rede.

Um total de 915.851 mensagens de olá foram enviadas e 915.881 recebidas, sem nenhuma transmitida ou recebida nos últimos 5 segundos. O intervalo de olá do RSVP é de 9 segundos. Se mais de uma mensagem de olá for enviada ou recebida nos últimos 5 segundos, ela implica que mais de uma interface oferece suporte ao RSVP.

EndtoEnd As mensagens RSVP são mensagens RSVP legadas que não são usadas para engenharia de tráfego RSVP. Esses contadores só aumentam quando o RSVP encaminha mensagens RSVP legadas emitidas por um cliente de rede privada virtual (VPN) para transitar pelo backbone para o outro(s) site(s) na VPN. Elas são chamadas de mensagens de ponta a ponta porque são destinadas ao lado oposto da rede e só têm significado nas duas extremidades da rede do provedor.

A Errors seção da saída mostra estatísticas sobre pacotes RSVP com erros. Um total de 15 PathErr to client pacotes foram enviados ao Mecanismo de Roteamento. O total combina os pacotes enviados e recebidos PathErr .