Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Resolução de problemas de sessões BGP

Lista de verificação para verificar o protocolo BGP e peers

Propósito

Tabela 1 fornece links e comandos para verificar se o protocolo de gateway de fronteira (BGP) está configurado corretamente em um roteador da Juniper Networks em sua rede, as sessões internas de protocolo de gateway de fronteira (IBGP) e exterior border gateway protocol (EBGP) estão devidamente estabelecidas, as rotas externas são anunciadas e recebidas corretamente, e o processo de seleção de caminho BGP está funcionando corretamente.

Ação

 

Tabela 1: Lista de verificação para verificar o protocolo BGP e peers

Tarefas

Comando ou ação

Verifique os peers do BGP
  1. Verifique o BGP em um roteador interno

show configuration

  1. Verifique o BGP em um roteador de fronteira

show configuration

  1. Verificar rotas BGP anunciadas

show route advertising-protocol bgp neighbor-address

  1. Verifique se uma rota BGP específica é recebida em seu roteador

show route receive-protocol bgp neighbor-address

Examine as rotas e a seleção de rotas do BGP  
  1. Examine a seleção de preferência local

show route destination-prefix < detail >

  1. Examine a seleção de rotas discriminatórias de múltiplas saídas

show route destination-prefix < detail >

  1. Examine o EBGP sobre a Seleção do IBGP

show route destination-prefix < detail >

  1. Examine a seleção de custos do IGP

show route destination-prefix < detail >

Examine as rotas na tabela de encaminhamento

show route forwarding-table

Verifique os peers do BGP

Propósito

Supondo que todos os roteadores estejam configurados corretamente para BGP, você pode verificar se as sessões de IBGP e EBGP estão devidamente estabelecidas, rotas externas são anunciadas e recebidas corretamente, e o processo de seleção de caminhos BGP está funcionando corretamente.

Figura 1 ilustra um exemplo de topologia de rede BGP usada neste tópico.

Figura 1: Topologia de rede BGPTopologia de rede BGP

A rede consiste em duas ASs diretamente conectadas que consistem em pares externos e internos. Os pares externos estão diretamente conectados por meio de uma interface compartilhada e estão executando o EBGP. Os pares internos são conectados por meio de suas interfaces de loopback (lo0por meio do IBGP). COMO o 65001 está executando o OSPF e o AS 65002 está executando o IS-IS como seu IGP subjacente. Os roteadores IBGP não precisam estar diretamente conectados, o IGP subjacente permite que os vizinhos entrem em contato entre si.

Os dois roteadores no AS 65001 contêm cada um um link de EBGP para AS 65002 (R2 e R4) sobre os quais anunciam prefixos agregados: 100.100.1.0 100.100.3.0, 100.100.2.0e 100.100.4.0. Além disso, R1 e R5 estão injetando valores discriminatórios de saída múltipla (MED) de 5 e 10, respectivamente, para algumas rotas.

Os roteadores internos em ambas as ASs estão usando uma topologia IBGP de malha completa. Uma malha completa é necessária porque as redes não estão usando confederações ou refletores de rota, portanto, quaisquer rotas aprendidas através do IBGP não são distribuídas para outros vizinhos internos. Por exemplo, quando R3 aprende uma rota de R2, R3 não distribui essa rota porque R6 a rota é aprendida através do IBGP, por isso R6 deve ter uma conexão BGP direta para R2 aprender a rota.

Em uma topologia de malha completa, apenas o roteador de borda que recebe informações BGP externas distribui essas informações para outros roteadores dentro de seu AS. O roteador receptor não redistribui essas informações para outros roteadores IBGP em seu próprio AS.

Do ponto de vista do AS 65002, as seguintes sessões devem estar ativas:

  • Os quatro roteadores no AS 65002 devem ter sessões de IBGP estabelecidas entre si.

  • R2 deve ter uma sessão de EBGP estabelecida com R1.

  • R4 deve ter uma sessão de EBGP estabelecida com R5.

Para verificar os peers do BGP, siga essas etapas:

Verifique o BGP em um roteador interno

Propósito

Para verificar a configuração BGP de um roteador interno.

Ação

Para verificar a configuração BGP de um roteador interno, insira o seguinte comando de interface de linha de comando (CLI) do Junos OS:

A saída de amostra a seguir é para uma configuração BGP no R3:

Saída de amostra
nome de comando

Significado

A saída de amostra mostra uma configuração BGP básica em roteadores R3 e R6. O AS local (65002) e um grupo (internal) estão configurados em ambos os roteadores. R3 tem três pares internos — 10.0.0.410.0.0.2e 10.0.0.6— incluídos no nível R6 [protocols bgp group group] de hierarquia também tem três pares internos: 10.0.0.2e10.0.0.310.0.0.4... O protocolo IGP subjacente é Sistema Intermediário para Sistema Intermediário (IS-IS), e interfaces relevantes são configuradas para executar IS-IS.

Observe que nesta configuração o ID do roteador está configurado manualmente para evitar qualquer problema de ID de roteador duplicado.

Verifique o BGP em um roteador de fronteira

Propósito

Para verificar a configuração BGP de um roteador de borda.

Ação

Para verificar a configuração BGP de um roteador de borda, insira o seguinte comando de modo operacional Junos OS CLI:

Saída de amostra
nome de comando

A saída de amostra a seguir é para uma configuração BGP em dois roteadores de borda, R2 e R4 a partir de AS 65002:

Significado

A saída de amostra mostra uma configuração BGP básica em roteadores de R2 borda e R4. Ambos os roteadores têm o AS (65002) incluído no nível [routing-options] de hierarquia. Cada roteador tem dois grupos incluídos no nível [protocols bgp group group] de hierarquia. Os pares externos estão incluídos no grupo externo, seja para O1 ou toR5, dependendo do roteador. Os pares internos estão incluídos no internal grupo. O protocolo IGP subjacente é IS-IS em ambos os roteadores, e interfaces relevantes são configuradas para executar o IS-IS.

Observe que na configuração em ambos os roteadores, o ID do roteador é configurado manualmente para evitar problemas de ID de roteador duplicado, e a next-hop-self declaração está incluída para evitar qualquer problema de acessibilidade no próximo salto BGP.

Verificar rotas BGP anunciadas

Propósito

Você pode determinar se uma rota específica que você configurou está sendo anunciada para um vizinho.

Ação

Para verificar as informações de roteamento conforme ela foi preparada para anúncio ao vizinho BGP especificado, insira o seguinte comando de modo operacional Junos OS CLI:

Saída de amostra
nome de comando

Significado

A saída de amostra mostra as rotas BGP anunciadas de R2 seu vizinho, 10.0.0.4 (R4). Do total de 22 rotas na inet.0 tabela de roteamento, 20 são destinos ativos. Nenhuma rota está hidden ou no hold-down estado. As rotas residem no hold-down estado antes de serem declaradas ativas, e rotas recusadas por uma política de roteamento podem ser colocadas no hidden estado. As informações exibidas refletem as rotas que a tabela de roteamento exportou para o protocolo de roteamento BGP.

Verifique se uma rota BGP específica é recebida em seu roteador

Propósito

Exibir as informações de roteamento como elas são recebidas por um vizinho BGP específico e anunciadas pelo roteador local para o vizinho.

Ação

Para verificar se uma determinada rota BGP é recebida em seu roteador, insira o seguinte comando de modo operacional Junos OS CLI:

Saída de amostra
nome de comando

Significado

A saída de amostra mostra quatro rotas BGP de R2 e duas de R4. Das quatro rotas de R2, apenas duas estão ativas na tabela de roteamento, conforme indicado pelo asterisco (*), enquanto ambas as rotas recebidas estão ativas na tabela de R4 roteamento. Todas as rotas BGP passaram pelo AS 65001.

Examine as rotas e a seleção de rotas do BGP

Propósito

Você pode examinar o processo de seleção de caminho BGP para determinar o caminho único e ativo quando o BGP recebe várias rotas para o mesmo prefixo de destino.

Figura 2: Topologia de rede BGPTopologia de rede BGP

A rede mostra Figura 2 isso R1 e R5 anuncia as mesmas rotas agregadas para R2 e R4, que resultam R2 e R4 recebem duas rotas para o mesmo prefixo de destino. O processo de seleção de rotas está ativado R2 e R4 determina quais das duas rotas BGP recebidas estão ativas e anunciadas para os outros roteadores internos (R3 e R6).

Antes que o roteador instale uma rota BGP, ele deve garantir que o atributo BGP next-hop seja acessível. Se o próximo salto BGP não puder ser resolvido, a rota não será instalada. Quando uma rota BGP é instalada na tabela de roteamento, ela deve passar por um processo de seleção de caminhos se existem várias rotas para o mesmo prefixo de destino. O processo de seleção de caminhos BGP prossegue na seguinte ordem:

  1. A preferência por rotas na tabela de roteamento é comparada. Por exemplo, se houver um OSPF e uma rota BGP para um determinado destino, a rota OSPF será selecionada como a rota ativa porque a rota OSPF tem uma preferência padrão de 110, enquanto a rota BGP tem uma preferência padrão de 170.

  2. As rotas são comparadas para a preferência local. A rota com a mais alta preferência local é preferida. Por exemplo, veja Examine a seleção de preferência local.

  3. O atributo de caminho AS é avaliado. O caminho AS mais curto é preferido.

  4. O código de origem é avaliado. O código de origem mais baixo é o preferido ( I (IGP) < E (EGP) < ? (Incomplete)).

  5. O valor do MED é avaliado. Por padrão, se alguma das rotas for anunciada do mesmo AS vizinho, o menor valor de MED é o preferido. A ausência de um valor de MED é interpretada como um MED de 0. Por exemplo, veja Examine a seleção de rotas discriminatórias de múltiplas saídas.

  6. A rota é avaliada sobre se ela é aprendida por EBGP ou IBGP. As rotas aprendidas por EBGP são preferidas para as rotas aprendidas do IBGP. Por exemplo, veja Examine o EBGP sobre a Seleção do IBGP

  7. Se a rota for aprendida com o IBGP, a rota com o menor custo de IGP é preferida. Por exemplo, veja Examine a seleção de custos do IGP. O próximo salto físico para o peer do IBGP é instalado de acordo com as seguintes três regras:

      1. Após o BGP examinar as tabelas e inet.3 o inet.0 roteamento, é usado o próximo salto físico da rota com a menor preferência.

      1. Se os valores de preferência nas inet.0 tabelas de roteamento forem inet.3 um empate, o próximo salto físico da rota na inet.3 tabela de roteamento é usado.

      1. Quando existe um empate de preferência na mesma tabela de roteamento, o próximo salto físico da rota com mais caminhos é instalado.

  8. O atributo da lista de clusters de reflexão de rota é avaliado. A lista de clusters de comprimento mais curto é preferida. Considera-se que rotas sem uma lista de clusters tenham um comprimento de lista de clusters de 0.

  9. A ID do roteador é avaliada. A rota do peer com o ID do roteador mais baixo é preferida (geralmente o endereço loopback).

  10. O valor do endereço peer é analisado. O peer com o endereço IP peer mais baixo é o preferido.

Para determinar o caminho único e ativo quando o BGP receber várias rotas para o mesmo prefixo de destino, insira o seguinte comando de modo operacional Junos OS CLI:

As etapas a seguir ilustram o motivo inativo exibido quando o BGP recebe várias rotas para o mesmo prefixo de destino e uma rota é selecionada como o caminho único e ativo:

Examine a seleção de preferência local

Propósito

Examinar uma rota para determinar se a preferência local é o critério de seleção para o caminho único e ativo.

Ação

Para examinar uma rota para determinar se a preferência local é o critério de seleção para o caminho único e ativo, 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 R4 recebeu duas instâncias da 100.100.1.0 rota: um de 10.0.0.2 (R2) e outro de 10.1.45.2 (R5). R4 selecionou o caminho R2 como seu caminho ativo, conforme indicado pelo asterisco (*). A seleção é baseada no valor de preferência local contido no Localpref campo. O caminho com a mais alta preferência local é o preferido. No exemplo, o caminho com o maior valor de preferência local é o caminho a partir de R2200.

A razão pela qual a rota não R5 está selecionada está em Inactive reason campo, neste caso. Local Preference.

Observe que os dois caminhos são da mesma rede vizinha: COMO 65001.

Examine a seleção de rotas discriminatórias de múltiplas saídas

Propósito

Examinar uma rota para determinar se o MED é o critério de seleção do caminho único e ativo.

Ação

Para examinar uma rota para determinar se o MED é o critério de seleção para o caminho único e ativo, 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 R4 recebeu duas instâncias da 100.100.2.0 rota: um de 10.0.0.2 (R2) e outro de 10.1.45.2 (R5). R4 selecionou o caminho R2 como sua rota ativa, conforme indicado pelo asterisco (*). A seleção é baseada no valor de MED contido no Metric: campo. O caminho com o menor valor de MED é o preferido. No exemplo, o caminho com o menor valor de MED (5) é o caminho de R2. Observe que os dois caminhos são da mesma rede vizinha: COMO 65001.

A razão pela qual o caminho inativo não é selecionado é exibido em Inactive reason: campo, neste caso, Not Best in its group. A redação é usada porque o Junos OS usa o processo de seleção determinística de MED, por padrão.

Examine o EBGP sobre a Seleção do IBGP

Propósito

Examinar uma rota para determinar se o EBGP é selecionado no IBGP como critérios de seleção para o caminho único e ativo.

Ação

Para examinar uma rota para determinar se o EBGP é selecionado no IBGP como critérios de seleção para o caminho único e ativo, 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 R4 recebeu duas instâncias da 100.100.3.0 rota: um de 10.1.45.2 (R5) e outro de 10.0.0.2 (R2). R4 selecionou o caminho R5 como seu caminho ativo, conforme indicado pelo asterisco (*). A seleção é baseada em uma preferência por rotas aprendidas com um peer EBGP sobre rotas aprendidas com um IBGP. R5 é um peer EBGP.

Você pode determinar se um caminho é recebido de um peer EBGP ou IBGP examinando os campos e Peer As os Local As campos. Por exemplo, a rota mostra R5 que o AS local é 65002 e o PEER AS é 65001, indicando que a rota é recebida de um peer EBGP. A rota mostra R2 que tanto o AS local quanto o PEER AS são 65002, indicando que ele é recebido de um peer IBGP.

A razão pela qual o caminho inativo não é selecionado é exibido em Inactive reason campo, neste caso, Interior > Exterior > Exterior via Interior. A redação desse motivo mostra a ordem de preferências aplicada quando a mesma rota é recebida de dois roteadores. A rota recebida de uma fonte estritamente interna (IGP) é a preferida primeiro, a rota recebida de uma fonte externa (EBGP) é preferida em seguida, e qualquer rota que venha de uma fonte externa e seja recebida internamente (IBGP) é a última preferida. Portanto, as rotas de EBGP são selecionadas em rotas de IBGP como o caminho ativo.

Examine a seleção de custos do IGP

Propósito

Examinar uma rota para determinar se o EBGP é selecionado no IBGP como critérios de seleção para o caminho único e ativo.

Ação

Para examinar uma rota para determinar se o EBGP é selecionado no IBGP como critérios de seleção para o caminho único e ativo, 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 R6 recebeu duas instâncias da 100.100.4.0 rota: um de 10.0.0.4 (R4) e outro de 10.0.0.2 (R2). R6 selecionou o caminho R4 como sua rota ativa, conforme indicado pelo asterisco (*). A seleção é baseada na métrica IGP, exibida em Metric2 campo. A rota com a menor métrica de IGP é preferida. No exemplo, o caminho com o menor valor métrica de IGP é o caminho de R4, com um valor métrica de IGP de 10, enquanto o caminho a partir tem uma métrica de R2 IGP de 20. Observe que os dois caminhos são da mesma rede vizinha: COMO 65001.

A razão pela qual o caminho inativo não foi selecionado é exibido em Inactive reason campo, neste caso, IGP metric.

Lista de verificação para verificar a camada BGP

Problema

Descrição

Esta lista de verificação fornece as etapas e comandos para verificar a configuração BGP da rede Multiprotocol Label Switching (MPLS). A lista de verificação oferece links para uma visão geral da configuração do BGP e informações mais detalhadas sobre os comandos usados para configurar o BGP. (Veja Tabela 2.)

Solução

Tabela 2: Lista de verificação para verificar a camada BGP

Tarefas

Comando ou ação

Verificando a camada BGP  
  1. Verifique se o tráfego BGP está usando o LSP

traceroute hostname

  1. Confira as sessões do BGP

show bgp summary

  1. Verifique a configuração do BGP

show configuration

  1. Examine as rotas BGP

show route destination-prefix detail

  1. Verifique as rotas BGP recebidas

show route receive protocol bgp neighbor-address

  1. Tomando as medidas apropriadas para resolver o problema da rede

A sequência de comandos a seguir aborda o problema específico descrito neste tópico:

[edit] edit protocols bgp

[edit protocols bgp] show set local-address 10.0.0.1 delete group internal neighbor 10.1.36.2 show commit

  1. Verifique se o tráfego BGP está usando o LSP novamente

traceroute hostname

Verificando a camada BGP

Propósito

Depois de configurar o caminho comuído por rótulos (LSP) e determinar que ele está ativado, configurou o BGP e determinou que as sessões estão estabelecidas, certifique-se de que o BGP esteja usando o LSP para encaminhar o tráfego.

Figura 3 ilustra a camada BGP do modelo MPLS em camadas.

Figura 3: Verificando a camada BGPVerificando a camada BGP

Ao verificar a camada BGP, verifique se a rota está presente e ativa e, mais importante, você garante que o próximo salto seja o LSP. Não adianta verificar a camada BGP a menos que o LSP esteja estabelecido, porque o BGP usa o MPLS LSP para encaminhar tráfego. Se a rede não estiver funcionando na camada BGP, o LSP não funcionará como configurado.

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

Figura 4: Rede MPLS quebrada na camada BGPRede MPLS quebrada na camada BGP

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.

A cruz mostrada Figura 4 indica onde o BGP não está sendo usado para encaminhar tráfego pelo LSP. Possíveis razões para o LSP não funcionar corretamente é que o endereço IP de destino do LSP não é igual ao próximo salto BGP ou que o BGP não está configurado corretamente.

Para verificar a camada BGP, siga essas etapas:

Verifique se o tráfego BGP está usando o LSP

Propósito

Nesse nível do modelo de solução de problemas, o BGP e o LSP podem estar em alta, no entanto, o tráfego BGP pode não estar usando o LSP para encaminhar tráfego.

Ação

Para verificar se o tráfego BGP está usando o LSP, insira o seguinte comando de modo operacional de interface de linha de comando (CLI) Do roteador de entrada:

Saída de amostra
nome de comando

Significado

A saída de amostra 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 protocolo de gateway interior (IGP) para chegar ao endereço de saída LSP de próximo salto BGP para R6 e R1. O padrão do Junos OS é usar LSPs para tráfego BGP quando o próximo salto BGP for igual ao endereço de saída LSP.

Confira as sessões do BGP

Propósito

Exibir informações sumárias sobre o BGP e seus vizinhos para determinar se as rotas são recebidas de pares no sistema autônomo (AS). Quando uma sessão BGP é estabelecida, os pares estão trocando mensagens de atualização.

Ação

Para verificar se as sessões BGP estão ativas, insira o seguinte comando de modo operacional Junos OS CLI a partir 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 um peer (roteador 10.0.0.6 de saída) não está estabelecido, conforme indicado pelo Down Peers: 1 campo. A última coluna (State|#Active/Received/Damped) mostra que o peer 10.0.0.6 está ativo, indicando que não está estabelecido. Todos os outros pares são estabelecidos conforme indicado pelo número de rotas ativas, recebidas e amortecedas. Por exemplo, 0/0/0 para peer 10.0.0.2 indica que nenhuma rota BGP estava ativa ou recebida na tabela de roteamento, e nenhuma rota BGP foi amortecida; 1/1/0 para peer 10.1.36.2 indica que uma rota BGP estava ativa e recebida na tabela de roteamento, e nenhuma rota BGP estava umedeada.

Se a saída do show bgp summary comando de um roteador de entrada mostrar que um vizinho está desativado, verifique a configuração BGP. Para obter informações sobre como verificar a configuração do BGP, consulte Verificar a configuração do BGP.

A saída de amostra 2 mostra a saída do roteador R1 de entrada após as configurações BGP ativadas e R6 foram corrigidas em Tomar as medidas apropriadas para resolver o problema da rede..R1 Todos os pares BGP estão estabelecidos e uma rota está ativa e recebida. Nenhuma rota BGP foi amorteada.

Se a saída do show bgp summary comando mostrar que um vizinho está funcionando, mas os pacotes não estiverem sendo encaminhados, verifique se há rotas recebidas do roteador de saída. Para obter informações sobre como verificar o roteador de saída para rotas recebidas, consulte Verificar as rotas BGP recebidas.

Verifique a configuração do BGP

Propósito

Para que o BGP seja executado no roteador, você deve definir o número AS local, configurar pelo menos um grupo e incluir informações sobre pelo menos um peer no grupo (endereço IP do peer e número AS). Quando o BGP faz parte de uma rede MPLS, você deve garantir que o LSP esteja configurado com um endereço IP de destino igual ao BGP próximo salto, a fim de que as rotas BGP sejam instaladas com o LSP como o próximo salto para essas rotas.

Ação

Para verificar a configuração BGP, 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 mostra as configurações BGP no roteador R1 de entrada e roteador R6de saída. Ambas as configurações mostram o AS local (65432), um grupo (internal) e seis pares configurados. O protocolo de gateway interior subjacente é IS-IS, e as interfaces relevantes estão configuradas para executar o IS-IS.

Nota:

Nesta configuração, o RID é configurado manualmente para evitar quaisquer problemas RID duplicados, e todas as interfaces configuradas com BGP incluem a family inet declaração no nível [edit interfaces type-fpc/pic/port unit logical-unit-number] de hierarquia.

A saída de amostra para roteador R1 de entrada e roteador R6 de saída mostra que a configuração do protocolo BGP está perdendo a local-address declaração para o grupo interno. Quando a local-address declaração é configurada, os pacotes BGP são encaminhados do endereço de interface de loopback (lo0) do roteador local, que é o endereço ao qual os pares BGP estão peering. Se a local-address declaração não estiver configurada, os pacotes BGP serão encaminhados do endereço de interface de saída, que não corresponde ao endereço ao qual os pares BGP estão peering, e o BGP não aparece.

No roteador de entrada, o endereço IP (10.0.0.1) na local-address declaração deve ser o mesmo que o endereço configurado para o LSP no roteador de saída (R6) na to declaração no nível [edit protocols mpls label-switched-path lsp-path-name] de hierarquia. O BGP usa esse endereço, que é idêntico ao endereço LSP, para encaminhar o tráfego BGP pelo LSP.

Além disso, a configuração BGP inclui R1 dois endereços IP paraR6, um endereço de interface (10.1.36.2) e um endereço de interface de loopback (lo010.0.0.6), resultando no endereço de destino LSP (10.0.0.6) sem combinar com o endereço BGP next-hop (10.1.36.2). A configuração do BGP também R6 inclui dois endereços IP para R1, um endereço de interface (10.1.13.1) e um endereço de interface de loopback (lo0), resultando no endereço de destino LSP reverso (10.0.0.1) sem combinar com o endereço BGP next-hop (10.1.13.1).

Neste caso, como a local-address declaração está ausente nas configurações BGP de ambos os roteadores e o endereço de destino LSP não corresponde ao endereço BGP next-hop, o BGP não está usando o LSP para encaminhar tráfego.

Examine as rotas BGP

Propósito

Você pode examinar o processo de seleção de caminho BGP para determinar o caminho único e ativo quando o BGP recebe várias rotas para o mesmo destino. Nesta etapa, examinamos o LSP R6-to-R1reverso, fazendo R6 o roteador de entrada para esse LSP.

Ação

Para examinar as rotas BGP e a seleção de rotas, 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 que o próximo salto BGP (10.1.13.1) não é igual ao endereço de destino LSP (10.0.0.1) na to declaração no nível [edit protocols mpls label-switched-path label-switched-path-name] de hierarquia quando a configuração BGP R6 é incorreta R1 .

A saída de amostra 2, tirada após a correção das configurações no R1 e R6, mostra que o próximo salto BGP (10.0.0.1) e o endereço de destino LSP (10.0.0.1) são os mesmos, indicando que o BGP pode usar o LSP para encaminhar o tráfego BGP.

Verifique as rotas BGP recebidas

Propósito

Exibir as informações de roteamento recebidas no roteador R6, o roteador de entrada para o LSP reverso R6-to-R1.

Ação

Para verificar se uma determinada rota BGP é recebida no roteador de saída, 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 que o roteador R6 de entrada (LSP R6-to-R1reverso) não recebe nenhuma rota BGP na inet.0 tabela de roteamento quando as configurações do R1 BGP são incorretas R6 .

A saída de amostra 2 mostra uma rota BGP instalada na inet.0 tabela de roteamento após as configurações do BGP e R6 são corrigidas R1 usando a ação apropriada para resolver o problema da rede.

Tomando as medidas apropriadas para resolver o problema da rede

Problema

Descrição

A ação apropriada depende do tipo de problema que você isolou. Neste exemplo, uma rota estática configurada R2 é excluída do nível [routing-options] de hierarquia. Outras ações apropriadas podem incluir:

Solução

  • Verifique a configuração do roteador local e edite-o, se apropriado.

  • Solucione problemas do roteador intermediário.

  • Verifique a configuração remota do host e edite-a, se apropriado.

  • Solucione os protocolos de roteamento.

  • Identificar possíveis causas adicionais.

Para resolver o problema neste exemplo, insira os seguintes comandos CLI do Junos OS:

Saída de amostra

Significado

A saída de amostra mostra a rota estática excluída da hierarquia [routing-options] e da nova configuração comprometida. A saída para o show route comando agora mostra a rota BGP como a rota preferida, como indicado pelo asterisco (*).

Verifique se o tráfego BGP está usando 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 tráfego BGP está usando o LSP e que o problema na camada BGP foi resolvido.

Ação

Para verificar se o tráfego BGP está usando o LSP, insira o seguinte comando de modo operacional Junos OS CLI a partir do roteador de entrada:

Saída de amostra
nome de comando

Significado

A saída de amostra mostra que os rótulos MPLS são usados para encaminhar pacotes pelo LSP. Incluído na saída está um valor de rótulo (MPLS Label=100016), 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), aproximadamente 1.000.000.

O valor de tempo de vida (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 de roteamento 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 na saída de amostra 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 Junos OS por padrão usa LSPs para tráfego BGP quando o próximo salto BGP é igual ao endereço de saída LSP.

Se o próximo salto BGP não for igual ao endereço de saída LSP, o tráfego BGP não usará o LSP e, consequentemente, as etiquetas MPLS não aparecerão na saída para o traceroute comando, conforme indicado na saída de amostra em Check BGP Sessions.

Exibir pacotes BGP enviados ou recebidos

Ação

Para configurar o rastreamento para pacotes de protocolo BGP enviados ou recebidos, siga essas etapas:

  1. No modo de configuração, vá para o seguinte nível de hierarquia:

  2. Configure a bandeira para exibir informações enviadas, recebidas ou enviadas e recebidas:

    ou

    ou

  3. Verifique a configuração:

    Por exemplo:

    ou

    ou

  4. Confirmar a configuração:

  5. Veja o conteúdo do arquivo que contém as mensagens detalhadas:

    Por exemplo:

Entendendo rotas ocultas

Rotas ocultas são rotas que o dispositivo não pode usar por razões como um próximo salto inválido ou uma política de roteamento que rejeita as rotas.

Nota:

Se uma rota for completamente inválida, a rota não será colocada na tabela de roteamento como rota de candidato e nem sequer aparece como oculta.

A seguir, alguns comandos úteis para visualizar e solucionar problemas de rotas ocultas:

As rotas podem ser ocultas pelos seguintes motivos:

  • Uma política de importação rejeita a rota.

  • O próximo salto não pode ser resolvido usando a regra atual de resolução de próximo salto indireto. Como protocolos de roteamento como o BGP interno (IBGP) podem enviar informações de roteamento sobre rotas conectadas indiretamente, o Junos OS conta com rotas de protocolos de roteamento intra-AS (OSPF, IS-IS, RIP e estática) para resolver o melhor próximo salto conectado diretamente. O mecanismo de roteamento executa resolução de rota para determinar o melhor salto próximo conectado diretamente e instala a rota para o Mecanismo de encaminhamento de pacotes.

  • Uma política de amortecimento suprime a rota.

  • O caminho AS contém atributos de confederação ilegais ou inválidos.

  • O próximo endereço de salto é o endereço do dispositivo de roteamento local.

  • O caminho AS contém atributos transitivos ilegais ou inválidos.

  • O caminho AS está vazio. Isso só se aplica ao EBGP. Para o IBGP, um caminho AS vazio é normal.

  • O caminho AS contém um zero.

  • O endereço próximo é um endereço multicast.

  • O próximo endereço de salto é um endereço local de link IPv6.

  • O prefixo de rota ou o próximo salto da rota é um endereço marciano.

  • A sessão de LDP (Protocolo de distribuição de rótulos) falha. As rotas recebidas não estão instaladas na tabela de roteamento até que o roteador peer restabelece a sessão de LDP.

Examine as rotas na tabela de encaminhamento

Propósito

Quando você se depara com problemas, como problemas de conectividade, você pode precisar examinar rotas na tabela de encaminhamento para verificar se o processo de protocolo de roteamento transmitiu as informações corretas para a tabela de encaminhamento.

Ação

Para exibir o conjunto de rotas instaladas na tabela de encaminhamento, insira o seguinte comando de modo operacional Junos OS CLI:

Saída de amostra

nome de comando

Significado

A saída de amostra mostra os prefixos da camada de rede e seus próximos saltos instalados na tabela de encaminhamento. A saída inclui as mesmas informações de próximo salto que no show route detail comando (o endereço de próximo salto e o nome da interface). Informações adicionais incluem o tipo de destino, o tipo de próximo salto, o número de referências a este próximo salto e um índice em um banco de dados interno de próximo salto. (O banco de dados interno contém informações adicionais usadas pelo Mecanismo de encaminhamento de pacotes para garantir o encapsulamento adequado de pacotes enviados por uma interface. Este banco de dados não é acessível ao usuário.

Para obter informações detalhadas sobre os significados das várias bandeiras e tipos de campos, veja as políticas de roteamento, filtros de firewall e guia de usuário dos policiais de tráfego.

Exemplo: Substituindo a política padrão de roteamento BGP em roteadores de transporte de pacotes da Série PTX

Este exemplo mostra como substituir a política de roteamento padrão em roteadores de transporte de pacotes, como os roteadores de transporte de pacotes da Série PTX.

Requisitos

Este exemplo requer o Junos OS Release 12.1 ou posterior.

Visão geral

Por padrão, os roteadores da Série PTX não instalam rotas BGP na tabela de encaminhamento.

Para os roteadores da Série PTX, a configuração da from protocols bgp condição com a ação then accept não tem o resultado habitual que tem em outros dispositivos de roteamento Junos OS. Com a política de roteamento a seguir nos roteadores da Série PTX, as rotas BGP não são instaladas na tabela de encaminhamento.

Nenhuma rota BGP está instalada na tabela de encaminhamento. Esse é o comportamento esperado.

Este exemplo mostra como usar a ação then install-to-fib para substituir efetivamente a política padrão de roteamento BGP.

Configuração

Configuração rápida da CLI

Para configurar este exemplo rapidamente, copie os seguintes comandos, cole-os em um arquivo de texto, remova qualquer quebra de linha, altere os detalhes necessários para combinar com a configuração da sua rede e, em seguida, copie e cole os comandos no CLI no nível de [edit] hierarquia.

Instalação de rotas BGP selecionadas na tabela de encaminhamento

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia de usuário do Junos OS CLI.

Para instalar rotas BGP selecionadas na tabela de encaminhamento:

  1. Configure uma lista de prefixos para instalar na tabela de encaminhamento.

  2. Configure a política de roteamento, aplicando a lista de prefixo como condição.

  3. Aplique a política de roteamento na tabela de encaminhamento.

Resultados

A partir do modo de configuração, confirme sua configuração inserindo os show policy-options comandos e show routing-options os comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.

Se você terminar de configurar o dispositivo, entre no commit modo de configuração.

Verificação

Confirme se a configuração está funcionando corretamente.

Verificando se a rota selecionada está instalada na tabela de encaminhamento

Propósito

Certifique-se de que a política configurada substitui a política padrão.

Ação

A partir do modo operacional, entre no show route forwarding-table comando.

Significado

Essa saída mostra que a rota para 66.0.0.1/32 está instalada na tabela de encaminhamento.

Registre eventos de transição de estado do BGP

Propósito

As transições de estado do Border Gateway Protocol (BGP) indicam um problema de rede e precisam ser registradas e pesquisadas.

Ação

Para registrar eventos de transição de estado BGP para o log do sistema, siga estas etapas:

  1. No modo de configuração, vá para o seguinte nível de hierarquia:

  2. Configure o log do sistema:

  3. Verifique a configuração:

  4. Confirmar a configuração:

Significado

Registrar mensagens de eventos de transição de estado bgp são suficientes para diagnosticar a maioria dos problemas de sessão BGP. Tabela 3 listas e descreve os seis estados de uma sessão BGP.

Tabela 3: Seis estados de uma sessão BGP

Estado do BGP

Descrição

Idle

Este é o primeiro estado de uma conexão. O BGP aguarda o início de um evento iniciado por um administrador. O evento inicial pode ser a criação de uma sessão BGP por meio da configuração do roteador ou da redefinição de uma sessão existente. Após o evento de início, o BGP inicializa seus recursos, reinicia um temporizador de refinação de conexão, inicia uma conexão de transporte TCP e começa a ouvir conexões iniciadas por pares remotos. O BGP então passa para um Connect estado.

Se houver erros, o Idle BGP volta ao estado.

Connect

O BGP aguarda a conclusão da conexão do protocolo de transporte. Se a conexão de transporte TCP for bem sucedida, o estado faz a transição para OpenSent.

Se a conexão de transporte não for bem sucedida, o estado faz a transição para Active.

Se o temporizador de reposição de conexão tiver expirado, o estado permanecerá no Connect estado, o temporizador será reiniciado e uma conexão de transporte será iniciada.

Com qualquer outro evento, o estado volta para Idle.

Active

O BGP tenta adquirir um peer iniciando uma conexão de protocolo de transporte.

Se for bem-sucedido, o estado faz a transição para OpenSent.

Se o temporização de nova tentativa de conexão expirar, o BGP reiniciará o temporização de conexão e cairá de volta ao Connect estado. O BGP continua a ouvir uma conexão que pode ser iniciada a partir de outro peer. O estado pode voltar em Idle caso de outros eventos, como um evento stop.

Em geral, um estado vizinho faz um flip-flopping entre Connect eles e Active é uma indicação de que há um problema com a conexão de transporte TCP. Esse problema pode ser causado por muitas retransmissões de TCP ou pela incapacidade de um vizinho de chegar ao endereço IP de seus pares.

OpenSent

O BGP recebe uma mensagem aberta de seus pares. No estado, o OpenSent BGP compara seu número de sistema autônomo (AS) com o número AS de seus pares e reconhece se o peer pertence ao mesmo COMO (BGP interno) ou a um AS diferente (BGP externo).

A mensagem aberta é verificada para correção. Em caso de erros, como um número de versão ruim de um AS inaceitável, o BGP envia uma mensagem de notificação de erro e volta para Idle.

Para quaisquer outros erros, como a expiração do temporizante de espera ou um evento stop, o BGP envia uma mensagem de notificação com o código de erro correspondente e cai de volta ao Idle estado.

Se não houver erros, o BGP envia mensagens keepalive e reinicia o temporizador keepalive. Neste estado, o tempo de espera é negociado. Se o tempo de espera for 0, os temporizadors de espera e de espera não serão reiniciados.

Quando uma desconexão de transporte de TCP é detectada, o estado cai para Active.

OpenConfirm

O BGP espera por uma mensagem de notificação ou manutenção.

Se um keepalive for recebido, o Estado se tornará Established, e a negociação do vizinho estiver concluída. Se o sistema receber uma atualização ou mensagem keepalive, ele reinicia o temporizador de espera (assumindo que o tempo de espera negociado não é 0).

Se uma mensagem de notificação for recebida, o estado cairá para Idle trás.

O sistema envia mensagens keepalive periódicas na taxa definida pelo temporizante keepalive. Em caso de uma notificação de desconexão de transporte ou em resposta a um evento de parada, o estado recua Idle. Em resposta a outros eventos, o sistema envia uma mensagem de notificação com um código de erro de máquina de estado finito (FSM) e volta para Idle.

Established

Este é o estado final na negociação do vizinho. Neste estado, o BGP troca atualizações de ackets com seus pares e o temporizador de espera é reiniciado ao receber uma atualização ou mensagem keepalive quando ela não estiver definida para zero.

Se o sistema receber uma mensagem de notificação, o estado cairá para Idle.

As mensagens de atualização são verificadas para verificar se há erros, como atributos ausentes, atributos duplicados e assim por diante. Se forem encontrados erros, uma notificação é enviada ao peer e o estado cai para Idle.

O BGP remonta à Idle expiração do tempo de espera, uma notificação de desconexão é recebida do protocolo de transporte, um evento de parada é recebido ou em resposta a qualquer outro evento.

Para obter informações mais detalhadas do pacote de protocolo BGP, configure o rastreamento específico do BGP. Consulte a lista de verificação para rastrear condições de erro para obter mais informações.

Configure opções específicas do BGP

Propósito

Quando eventos ou problemas inesperados ocorrem, ou se você quiser diagnosticar problemas de estabelecimento BGP, você pode visualizar informações mais detalhadas configurando opções específicas para BGP. Você também pode configurar o rastreamento para um grupo de peer ou peer BGP específico. Para obter mais informações, consulte o Guia de configuração básica do sistema Junos.

Exibir informações detalhadas do protocolo BGP

Ação

Para exibir detalhadamente as informações do protocolo BGP, siga essas etapas:

  1. No modo de configuração, vá para o seguinte nível de hierarquia:

  2. Configure a bandeira para exibir mensagens de protocolo BGP detalhadas:

  3. Verifique a configuração:

    Por exemplo:

  4. Confirmar a configuração:

  5. Veja o conteúdo do arquivo que contém as mensagens detalhadas:

    Por exemplo:

Significado

Tabela 4 lista bandeiras de rastreamento específicas do BGP e apresenta saída de exemplo para algumas das bandeiras. Você também pode configurar o rastreamento para um grupo de peer ou peer BGP específico. Para obter mais informações, consulte o Guia de configuração básica do sistema Junos.

Tabela 4: Bandeiras de rastreamento de protocolo BGP

Bandeiras de rastreamento

Descrição

Saída de exemplo

aspath

Operações de expressão regular de caminho AS

Não está disponível.

damping

Operações de amortecimento

Nov 28 17:01:12 bgp_damp_change: Change event Nov 28 17:01:12 bgp_dampen: Damping 10.10.1.0 Nov 28 17:01:12 bgp_damp_change: Change event Nov 28 17:01:12 bgp_dampen: Damping 10.10.2.0 Nov 28 17:01:12 bgp_damp_change: Change event Nov 28 17:01:12 bgp_dampen: Damping 10.10.3.0

keepalive

Mensagens de manutenção BGP

Nov 28 17:09:27 bgp_send: sending 19 bytes to 10.217.5.101 (External AS 65471) Nov 28 17:09:27 Nov 28 17:09:27 BGP SEND 10.217.5.1+179 -> 10.217.5.101+52162 Nov 28 17:09:27 BGP SEND message type 4 (KeepAlive) length 19 Nov 28 17:09:28 Nov 28 17:09:28 BGP RECV 10.217.5.101+52162 -> 10.217.5.1+179 Nov 28 17:09:28 BGP RECV message type 4 (KeepAlive) length 19

open

Pacotes abertos BGP

Nov 28 18:37:42 bgp_send: sending 37 bytes to 10.217.5.101 (External AS 65471) Nov 28 18:37:42 Nov 28 18:37:42 BGP SEND 10.217.5.1+179 -> 10.217.5.101+38135 Nov 28 18:37:42 BGP SEND message type 1 (Open) length 37

packets

Todos os pacotes de protocolo BGP

Sep 27 17:45:31 BGP RECV 10.0.100.108+179 -> 10.0.100.105+1033 Sep 27 17:45:31 BGP RECV message type 4 (KeepAlive) length 19 Sep 27 17:45:31 bgp_send: sending 19 bytes to 10.0.100.108 (Internal AS 100) Sep 27 17:45:31 BGP SEND 10.0.100.105+1033 -> 10.0.100.108+179 Sep 27 17:45:31 BGP SEND message type 4 (KeepAlive) length 19 Sep 27 17:45:31 bgp_read_v4_update: receiving packet(s) from 10.0.100.108 (Internal AS 100)

update

Atualizar pacotes

Nov 28 19:05:24 BGP SEND 10.217.5.1+179 -> 10.217.5.101+55813 Nov 28 19:05:24 BGP SEND message type 2 (Update) length 53 Nov 28 19:05:24 bgp_send: sending 65 bytes to 10.217.5.101 (External AS 65471) Nov 28 19:05:24 Nov 28 19:05:24 BGP SEND 10.217.5.1+179 -> 10.217.5.101+55813 Nov 28 19:05:24 BGP SEND message type 2 (Update) length 65 Nov 28 19:05:24 bgp_send: sending 55 bytes to 10.217.5.101 (External AS 65471)

Diagnosticar problemas de estabelecimento de sessão BGP

Propósito

Para rastrear problemas de estabelecimento de sessão BGP.

Ação

Para rastrear problemas de estabelecimento de sessão BGP, siga essas etapas:

  1. No modo de configuração, vá para o seguinte nível de hierarquia:

  2. Configure mensagens abertas BGP:

  3. Verifique a configuração:

    Por exemplo:

  4. Confirmar a configuração:

  5. Veja o conteúdo do arquivo que contém as mensagens detalhadas:

    Por exemplo:

Configure opções específicas do IS-IS

Propósito

Quando eventos ou problemas inesperados ocorrem, ou se você quiser diagnosticar problemas de estabelecimento de adjacência IS-IS, você pode visualizar informações mais detalhadas configurando opções específicas para o IS-IS.

Para configurar as opções IS-IS, siga essas etapas:

Exibição de informações detalhadas do protocolo IS-IS

Ação

Para rastrear detalhadamente as mensagens IS-IS, siga essas etapas:

  1. Configure a bandeira para exibir mensagens de protocolo IS-IS detalhadas.

  2. Verifique a configuração.

    Por exemplo:

  3. Confirmar a configuração.

  4. Veja o conteúdo do arquivo que contém as mensagens detalhadas.

    Por exemplo:

Significado

Tabela 5 lista bandeiras de rastreamento que podem ser configuradas específicas do IS-IS e apresenta saída de exemplo para algumas das bandeiras.

Tabela 5: Bandeiras de rastreamento de protocolo IS-IS

Bandeiras de rastreamento

Descrição

Saída de exemplo

csn

PDU de número de sequência completo (CSNP)

Nov 28 20:02:48 Sending L2 CSN on interface so-1/1/0.0Nov 28 20:02:48 Sending L2 CSN on interface so-1/1/1.0

Com a opção detail .

Nov 28 20:06:08 Sending L2 CSN on interface so-1/1/1.0Nov 28 20:06:08 LSP abc-core-01.00-00 lifetime 1146Nov 28 20:06:08 sequence 0x1c4f8 checksum 0xa1e9Nov 28 20:06:08 LSP abc-core-02.00-00 lifetime 411Nov 28 20:06:08 sequence 0x7435 checksum 0x5424Nov 28 20:06:08 LSP abc-brdr-01.00-00 lifetime 465Nov 28 20:06:08 sequence 0xf73 checksum 0xab10Nov 28 20:06:08 LSP abc-edge-01.00-00 lifetime 1089Nov 28 20:06:08 sequence 0x1616 checksum 0xdb29Nov 28 20:06:08 LSP abc-edge-02.00-00 lifetime 1103Nov 28 20:06:08 sequence 0x45cc checksum 0x6883

hello

Olá pacote

Nov 28 20:13:50 Sending PTP IIH on so-1/1/1.0Nov 28 20:13:50 Received PTP IIH, source id abc-core-01 on so-1/1/0.0Nov 28 20:13:53 Received PTP IIH, source id abc-core-02 on so-1/1/1.0Nov 28 20:13:57 Sending PTP IIH on so-1/1/0.0Nov 28 20:13:58 Received PTP IIH, source id abc-core-01 on so-1/1/0.0Nov 28 20:13:59 Sending PTP IIH on so-1/1/1.0

lsp

PDUs de estado de enlace (LSPs)

Nov 28 20:15:46 Received L2 LSP abc-edge-01.00-00, interface so-1/1/0.0Nov 28 20:15:46 from abc-core-01Nov 28 20:15:46 sequence 0x1617, checksum 0xd92a, lifetime 1197Nov 28 20:15:46 Updating L2 LSP abc-edge-01.00-00 in TEDNov 28 20:15:47 Received L2 LSP abc-edge-01.00-00, interface so-1/1/1.0Nov 28 20:15:47 from abc-core-02Nov 28 20:15:47 sequence 0x1617, checksum 0xd92a, lifetime 1197

lsp-generation

Pacotes de geração de PDU em estado de enlace

Nov 28 20:21:24 Regenerating L1 LSP abc-edge-03.00-00, old sequence 0x682Nov 28 20:21:27 Rebuilding L1, fragment abc-edge-03.00-00Nov 28 20:21:27 Rebuilt L1 fragment abc-edge-03.00-00, size 59Nov 28 20:31:52 Regenerating L2 LSP abc-edge-03.00-00, old sequence 0x689Nov 28 20:31:54 Rebuilding L2, fragment abc-edge-03.00-00Nov 28 20:31:54 Rebuilt L2 fragment abc-edge-03.00-00, size 256Nov 28 20:34:05 Regenerating L1 LSP abc-edge-03.00-00, old sequence 0x683Nov 28 20:34:08 Rebuilding L1, fragment abc-edge-03.00-00Nov 28 20:34:08 Rebuilt L1 fragment abc-edge-03.00-00, size 59

packets

Todos os pacotes de protocolo IS-IS

Não está disponível.

psn

Pacotes PDU de número de sequência parcial (PSNP)

Nov 28 20:40:39 Received L2 PSN, source abc-core-01, interface so-1/1/0.0Nov 28 20:40:39 Received L2 PSN, source abc-core-02, interface so-1/1/1.0Nov 28 20:41:36 Sending L2 PSN on interface so-1/1/1.0Nov 28 20:41:36 Sending L2 PSN on interface so-1/1/0.0Nov 28 20:42:35 Received L2 PSN, source abc-core-02, interface so-1/1/1.0Nov 28 20:42:35 LSP abc-edge-03.00-00 lifetime 1196Nov 28 20:42:35 sequence 0x68c checksum 0x746dNov 28 20:42:35 Received L2 PSN, source abc-core-01, interface so-1/1/0.0Nov 28 20:42:35 LSP abc-edge-03.00-00 lifetime 1196Nov 28 20:42:35 sequence 0x68c checksum 0x746dNov 28 20:42:49 Sending L2 PSN on interface so-1/1/1.0Nov 28 20:42:49 LSP abc-core-01.00-00 lifetime 1197Nov 28 20:42:49 sequence 0x1c4fb checksum 0x9becNov 28 20:42:49 Sending L2 PSN on interface so-1/1/0.0Nov 28 20:42:49 LSP abc-core-01.00-00 lifetime 1197Nov 28 20:42:49 sequence 0x1c4fb checksum 0x9bec

spf

Cálculos de caminho mais curto em primeiro lugar (SPF)

Nov 28 20:44:01 Scheduling SPF for L1: ReconfigNov 28 20:44:01 Scheduling multicast SPF for L1: ReconfigNov 28 20:44:01 Scheduling SPF for L2: ReconfigNov 28 20:44:01 Scheduling multicast SPF for L2: ReconfigNov 28 20:44:02 Running L1 SPFNov 28 20:44:02 L1 SPF initialization complete: 0.000099s cumulative timeNov 28 20:44:02 L1 SPF primary processing complete: 0.000303s cumulative timeNov 28 20:44:02 L1 SPF result postprocessing complete: 0.000497s cumulative timeNov 28 20:44:02 L1 SPF RIB postprocessing complete: 0.000626s cumulative timeNov 28 20:44:02 L1 SPF routing table postprocessing complete: 0.000736s cumulative time

Exibição de pacotes de protocolo IS-IS enviados ou recebidos

Para configurar o rastreamento apenas para pacotes de protocolo IS-IS enviados ou recebidos, siga essas etapas:

  1. Configure a bandeira para exibir pacotes enviados, recebidos ou enviados e recebidos.

    ou

    ou

  2. Verifique a configuração.

    Por exemplo:

    ou

    ou

  3. Confirmar a configuração.

  4. Veja o conteúdo do arquivo que contém as mensagens detalhadas.

    Por exemplo:

Analisando detalhadamente as PDUs de estado de enlace IS-IS

Para analisar detalhadamente as PDUs de estado de enlace IS-IS, siga estas etapas:

  1. Configure mensagens abertas IS-IS.

  2. Verifique a configuração.

    Por exemplo:

  3. Confirmar a configuração.

  4. Veja o conteúdo do arquivo que contém as mensagens detalhadas.

    Por exemplo:

Configure opções específicas do OSPF

Propósito

Quando eventos ou problemas inesperados ocorrem, ou se você quiser diagnosticar problemas de estabelecimento vizinho osPF, você pode visualizar informações mais detalhadas configurando opções específicas para OSPF.

Para configurar opções de OSPF, siga essas etapas:

Diagnosticar problemas de estabelecimento de sessão osPF

Ação

Para rastrear detalhadamente as mensagens OSPF, siga essas etapas:

  1. No modo de configuração, vá para o seguinte nível de hierarquia:

  2. Configure mensagens de olá do OSPF:

  3. Verifique a configuração:

    Por exemplo:

  4. Confirmar a configuração:

  5. Veja o conteúdo do arquivo que contém as mensagens detalhadas:

    Por exemplo:

Significado

Tabela 6 lista bandeiras de rastreamento OSPF e apresenta saída de exemplo para algumas das bandeiras.

Tabela 6: Bandeiras de rastreamento de protocolo OSPF

Bandeiras de rastreamento

Descrição

Saída de exemplo

database-descripttion

Todos os pacotes de descrição do banco de dados

Dec 2 15:44:51 RPD_OSPF_NBRDOWN: OSPF neighbor 10.10.10.29 (so-1/1/0.0) state changed from Full to Down Dec 2 15:44:51 RPD_OSPF_NBRDOWN: OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Full to Down Dec 2 15:44:55 RPD_OSPF_NBRUP: OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Init to ExStart Dec 2 15:44:55 OSPF sent DbD (2) -> 224.0.0.5 (so-1/1/1.0) Dec 2 15:44:55 Version 2, length 32, ID 10.0.0.6, area 0.0.0.0 Dec 2 15:44:55 checksum 0xf76b, authtype 0 Dec 2 15:44:55 options 0x42, i 1, m 1, ms 1, seq 0xa009eee, mtu 4470 Dec 2 15:44:55 OSPF rcvd DbD 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0) Dec 2 15:44:55 Version 2, length 32, ID 10.10.134.12, area 0.0.0.0 Dec 2 15:44:55 checksum 0x312c, authtype 0 Dec 2 15:44:55 options 0x42, i 1, m 1, ms 1, seq 0x2154, mtu 4470

error

Pacotes com erros de OSPF

Dec 2 15:49:34 OSPF packet ignored: no matching interface from 172.16.120.29 Dec 2 15:49:44 OSPF packet ignored: no matching interface from 172.16.120.29 Dec 2 15:49:54 OSPF packet ignored: no matching interface from 172.16.120.29 Dec 2 15:50:04 OSPF packet ignored: no matching interface from 172.16.120.29 Dec 2 15:50:14 OSPF packet ignored: no matching interface from 172.16.120.29

event

Transições de estado OSPF

Dec 2 15:52:35 OSPF interface ge-2/2/0.0 state changed from DR to DR Dec 2 15:52:35 OSPF interface ge-3/1/0.0 state changed from DR to DR Dec 2 15:52:35 OSPF interface ge-3/2/0.0 state changed from DR to DR Dec 2 15:52:35 OSPF interface ge-4/2/0.0 state changed from DR to DR Dec 2 15:53:21 OSPF neighbor 10.10.10.29 (so-1/1/0.0) state changed from Full to Down Dec 2 15:53:21 RPD_OSPF_NBRDOWN: OSPF neighbor 10.10.10.29 (so-1/1/0.0) state changed from Full to Down Dec 2 15:53:21 OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Full to Down Dec 2 15:53:21 RPD_OSPF_NBRDOWN: OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Full to Down Dec 2 15:53:25 OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Down to Init Dec 2 15:53:25 OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Init to ExStart Dec 2 15:53:25 RPD_OSPF_NBRUP: OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Init to ExStart Dec 2 15:53:25 OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from ExStart to Exchange Dec 2 15:53:25 OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Exchange to Full Dec 2 15:53:25 RPD_OSPF_NBRUP: OSPF neighbor 10.10.10.33 (so-1/1/1.0) state changed from Exchange to Full

flooding

Pacotes de inundação do estado do enlace

Dec 2 15:55:21 OSPF LSA Summary 10.218.0.0 10.0.0.6 flooding on so-1/1/0.0 Dec 2 15:55:21 OSPF LSA Summary 10.218.0.0 10.0.0.6 flooding on so-1/1/1.0 Dec 2 15:55:21 OSPF LSA Summary 10.218.0.0 10.0.0.6 on no so-1/1/2.0 rexmit lists, no flood Dec 2 15:55:21 OSPF LSA Summary 10.218.0.0 10.0.0.6 on no so-1/1/3.0 rexmit lists, no flood

Dec 2 15:55:21 OSPF LSA Summary 10.245.0.1 10.0.0.6 on no so-1/1/2.0 rexmit lists, no flood Dec 2 15:55:21 OSPF LSA Summary 10.245.0.1 10.0.0.6 on no so-1/1/3.0 rexmit lists, no flood

hello

Olá pacotes

Dec 2 15:57:25 OSPF sent Hello (1) -> 224.0.0.5 (ge-3/1/0.0) Dec 2 15:57:25 Version 2, length 44, ID 10.0.0.6, area 2.0.0.0 Dec 2 15:57:25 checksum 0xe43f, authtype 0 Dec 2 15:57:25 mask 255.255.0.0, hello_ivl 10, opts 0x2, prio 128 Dec 2 15:57:25 dead_ivl 40, DR 10.218.0.1, BDR 0.0.0.0 Dec 2 15:57:25 OSPF rcvd Hello 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0) Dec 2 15:57:25 Version 2, length 48, ID 10.10.134.12, area 0.0.0.0 Dec 2 15:57:25 checksum 0x99b8, authtype 0 Dec 2 15:57:25 mask 255.255.255.252, hello_ivl 10, opts 0x2, prio 1 Dec 2 15:57:25 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0 Dec 2 15:57:27 OSPF sent Hello (1) -> 224.0.0.5 (ge-3/2/0.0) Dec 2 15:57:27 Version 2, length 44, ID 10.0.0.6, area 2.0.0.0 Dec 2 15:57:27 checksum 0xe4a5, authtype 0 Dec 2 15:57:27 mask 255.255.0.0, hello_ivl 10, opts 0x2, prio 128 Dec 2 15:57:27 dead_ivl 40, DR 10.116.0.1, BDR 0.0.0.0 Dec 2 15:57:28 OSPF rcvd Hello 10.10.10.1010.29 -> 224.0.0.5 (so-1/1/0.0) Dec 2 15:57:28 Version 2, length 48, ID .134.11, area 0.0.0.0 Dec 2 15:57:28 checksum 0x99b9, authtype 0 Dec 2 15:57:28 mask 255.255.255.252, hello_ivl 10, opts 0x2, prio 1 Dec 2 15:57:28 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0

lsa-ack

Pacotes de reconhecimento de estado de enlace

Dec 2 16:00:11 OSPF rcvd LSAck 10.10.10.29 -> 224.0.0.5 (so-1/1/0.0) Dec 2 16:00:11 Version 2, length 44, ID 10.10.134.11, area 0.0.0.0 Dec 2 16:00:11 checksum 0xcdbf, authtype 0 Dec 2 16:00:11 OSPF rcvd LSAck 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0) Dec 2 16:00:11 Version 2, length 144, ID 10.10.134.12, area 0.0.0.0 Dec 2 16:00:11 checksum 0x73bc, authtype 0 Dec 2 16:00:16 OSPF rcvd LSAck 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0) Dec 2 16:00:16 Version 2, length 44, ID 10.10.134.12, area 0.0.0.0 Dec 2 16:00:16 checksum 0x8180, authtype 0

lsa-request

Pacotes de solicitação de estado do enlace

Dec 2 16:01:38 OSPF rcvd LSReq 10.10.10.29 -> 224.0.0.5 (so-1/1/0.0) Dec 2 16:01:38 Version 2, length 108, ID 10.10.134.11, area 0.0.0.0 Dec 2 16:01:38 checksum 0xe86, authtype 0

lsa-update

Pacotes de atualização do estado do enlace

Dec 2 16:09:12 OSPF built router LSA, area 0.0.0.0 Dec 2 16:09:12 OSPF built router LSA, area 1.0.0.0 Dec 2 16:09:12 OSPF built router LSA, area 2.0.0.0 Dec 2 16:09:13 OSPF sent LSUpdate (4) -> 224.0.0.5 (so-1/1/0.0) Dec 2 16:09:13 Version 2, length 268, ID 10.0.0.6, area 0.0.0.0 Dec 2 16:09:13 checksum 0x8047, authtype 0 Dec 2 16:09:13 adv count 7 Dec 2 16:09:13 OSPF sent LSUpdate (4) -> 224.0.0.5 (so-1/1/1.0) Dec 2 16:09:13 Version 2, length 268, ID 10.0.0.6, area 0.0.0.0 Dec 2 16:09:13 checksum 0x8047, authtype 0 Dec 2 16:09:13 adv count 7

packets

Todos os pacotes OSPF

Não está disponível.

packet-dump

Despeje o conteúdo de tipos de pacotes selecionados

Não está disponível.

spf

Cálculos de SPF

Dec 2 16:08:03 OSPF full SPF refresh scheduled Dec 2 16:08:04 OSPF SPF start, area 1.0.0.0 Dec 2 16:08:04 OSPF add LSA Router 10.0.0.6 distance 0 to SPF list Dec 2 16:08:04 SPF elapsed time 0.000525s Dec 2 16:08:04 Stub elapsed time 0.000263s Dec 2 16:08:04 OSPF SPF start, area 2.0.0.0 Dec 2 16:08:04 OSPF add LSA Router 10.0.0.6 distance 0 to SPF list Dec 2 16:08:04 SPF elapsed time 0.000253s Dec 2 16:08:04 Stub elapsed time 0.000249s Dec 2 16:08:04 OSPF SPF start, area 0.0.0.0 Dec 2 16:08:04 OSPF add LSA Router 10.0.0.6 distance 0 to SPF list Dec 2 16:08:04 OSPF add LSA Router 10.10.10.10134.11 distance 1 to SPF list Dec 2 16:08:04 IP nexthop so-1/1/0.0 0.0.0.0 Dec 2 16:08:04 OSPF add LSA Router .134.12 distance 1 to SPF list Dec 2 16:08:04 IP nexthop so-1/1/1.0 0.0.0.0

Analise detalhadamente os pacotes de anúncios de estado de enlace do OSPF

Ação

Para analisar detalhadamente os pacotes de anúncio de estado de enlace do OSPF, siga estas etapas:

  1. No modo de configuração, vá para o seguinte nível de hierarquia:

  2. Configure os pacotes de estado do enlace OSPF:

  3. Verifique a configuração:

    Por exemplo:

  4. Confirmar a configuração:

  5. Veja o conteúdo do arquivo que contém as mensagens detalhadas:

    Por exemplo: