Nesta página
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
Tarefas |
Comando ou ação |
|---|---|
| Verifique os peers do BGP | |
|
|
|
|
|
|
|
|
| Examine as rotas e a seleção de rotas do BGP | |
|
|
|
|
|
|
|
|
| Examine as rotas na tabela de encaminhamento |
|
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.
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.
R2deve ter uma sessão de EBGP estabelecida comR1.R4deve ter uma sessão de EBGP estabelecida comR5.
Para verificar os peers do BGP, siga essas etapas:
- Verifique o BGP em um roteador interno
- Verifique o BGP em um roteador de fronteira
- Verificar rotas BGP anunciadas
- Verifique se uma rota BGP específica é recebida em seu roteador
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:
user@host> show configuration
A saída de amostra a seguir é para uma configuração BGP no R3:
Saída de amostra
nome de comando
user@R3> show configuration
[...Output truncated...]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
address 10.1.23.2/30;
}
family iso;
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.1.36.1/30;
}
family iso;
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.3/32;
}
family iso {
address 49.0002.1000.0000.0003.00;
}
}
}
}
routing-options {
[...Output truncated...]
router-id 10.0.0.3;
autonomous-system 65002;
}
protocols {
bgp {
group internal {
type internal;
local-address 10.0.0.3;
neighbor 10.0.0.2;
neighbor 10.0.0.4;
neighbor 10.0.0.6;
}
}
isis {
level 1 disable;
interface all {
level 2 metric 10;
}
interface lo0.0;
}
}
user@R6> show configuration |
[Output truncated...]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
address 10.1.46.2/30;
}
family iso;
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.1.36.2/30;
}
family iso;
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.6/32;
}
family iso {
address 49.0003.1000.0000.0006.00;
}
}
}
}
routing-options {
[Output truncated...]
router-id 10.0.0.6;
autonomous-system 65002;
}
protocols {
bgp {
group internal {
type internal;
local-address 10.0.0.6;
neighbor 10.0.0.2;
neighbor 10.0.0.3;
neighbor 10.0.0.4;
}
}
isis {
level 1 disable;
interface all {
level 2 metric 10;
}
interface lo0.0;
}
}
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:
user@host> show configuration
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:
user@R2> show configuration
[...Output truncated...]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.1.12.2/30;
}
family iso;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.1.23.1/30;
}
family iso;
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.1.24.1/30;
}
family iso;
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.2/32;
}
family iso {
address 49.0002.1000.0000.0002.00;
}
}
}
}
routing-options {
[...Output truncated...]
router-id 10.0.0.2;
autonomous-system 65002;
}
protocols {
bgp {
group internal {
type internal;
export next-hop-self;
neighbor 10.0.0.3;
neighbor 10.0.0.4;
neighbor 10.0.0.6;
}
group toR1 {
type external;
import import-toR1;
peer-as 65001;
neighbor 10.1.12.1;
}
}
isis {
level 1 disable;
interface all {
level 2 metric 10;
}
interface lo0.0;
}
}
policy-options {
policy-statement next-hop-self {
term change-next-hop {
from neighbor 10.1.12.1;
then {
next-hop self;
}
}
}
policy-statement import-toR1 {
term 1 {
from {
route-filter 100.100.1.0/24 exact;
}
then {
local-preference 200;
}
}
}
user@R4> show configuration
[...Output truncated...]
interfaces {
so-0/0/1 {
unit 0 {
family inet {
address 10.1.46.1/30;
}
family iso;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.1.45.1/30;
}
family iso;
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.1.24.2/30;
}
family iso;
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.4/32;
}
family iso {
address 49.0001.1000.0000.0004.00;
}
}
}
}
routing-options {
[...Output truncated...]
router-id 10.0.0.4;
autonomous-system 65002;
}
protocols {
bgp {
group internal {
type internal;
local-address 10.0.0.4;
export next-hop-self;
neighbor 10.0.0.2;
neighbor 10.0.0.3;
neighbor 10.0.0.6;
}
group toR5 {
type external;
peer-as 65001;
neighbor 10.1.45.2;
}
}
isis {
level 1 disable;
interface all {
level 2 metric 10;
}
interface lo0.0;
}
}
policy-options {
policy-statement next-hop-self {
term change-next-hop {
from neighbor 10.1.45.2;
then {
next-hop self;
}
}
}
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:
user@host> show route advertising-protocol bgp neighbor-address
Saída de amostra
nome de comando
user@R2> show route advertising-protocol bgp 10.0.0.4\ inet.0: 20 destinations, 22 routes (20 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 100.100.1.0/24 Self 5 200 65001 I * 100.100.2.0/24 Self 5 100 65001 I * 100.100.3.0/24 Self 100 65001 I * 100.100.4.0/24 Self 100 65001 I
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:
user@host> show route receive-protocol bgp neighbor-address
Saída de amostra
nome de comando
user@R6> show route receive-protocol bgp 10.0.0.2 inet.0: 18 destinations, 20 routes (18 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 100.100.1.0/24 10.0.0.2 5 200 65001 I * 100.100.2.0/24 10.0.0.2 5 100 65001 I 100.100.3.0/24 10.0.0.2 100 65001 I 100.100.4.0/24 10.0.0.2 100 65001 I iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) user@R6> show route receive-protocol bgp 10.0.0.4 inet.0: 18 destinations, 20 routes (18 active, 0 holddown, 0 hidden) Prefix Nexthop MED Lclpref AS path * 100.100.3.0/24 10.0.0.4 100 65001 I * 100.100.4.0/24 10.0.0.4 100 65001 I iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
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.
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:
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.
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.
O atributo de caminho AS é avaliado. O caminho AS mais curto é preferido.
O código de origem é avaliado. O código de origem mais baixo é o preferido (
I (IGP) < E (EGP) < ? (Incomplete)).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.
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
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:
Após o BGP examinar as tabelas e
inet.3oinet.0roteamento, é usado o próximo salto físico da rota com a menor preferência.
Se os valores de preferência nas
inet.0tabelas de roteamento foreminet.3um empate, o próximo salto físico da rota nainet.3tabela de roteamento é usado.
Quando existe um empate de preferência na mesma tabela de roteamento, o próximo salto físico da rota com mais caminhos é instalado.
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.
A ID do roteador é avaliada. A rota do peer com o ID do roteador mais baixo é preferida (geralmente o endereço loopback).
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:
user@host> show route destination-prefix < detail >
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
- Examine a seleção de rotas discriminatórias de múltiplas saídas
- Examine o EBGP sobre a Seleção do IBGP
- Examine a seleção de custos do IGP
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:
user@host> show route destination-prefix < detail >
Saída de amostra
nome de comando
user@R4> show route 100.100.1.0 detail
inet.0: 20 destinations, 24 routes (20 active, 0 holddown, 0 hidden)
100.100.1.0/24 (2 entries, 1 announced)
*BGP Preference: 170/-201
Source: 10.0.0.2
Next hop: 10.1.24.1 via so-0/0/3.0, selected
Protocol next hop: 10.0.0.2 Indirect next hop: 8644000 277
State: <Active Int Ext>
Local AS: 65002 Peer AS: 65002
Age: 2:22:34 Metric: 5 Metric2: 10
Task: BGP_65002.10.0.0.2+179
Announcement bits (3): 0-KRT 3-BGP.0.0.0.0+179 4-Resolve inet.0
AS path: 65001 I
Localpref: 200
Router ID: 10.0.0.2
BGP Preference: 170/-101
Source: 10.1.45.2
Next hop: 10.1.45.2 via so-0/0/2.0, selected
State: <Ext>
Inactive reason: Local Preference
Local AS: 65002 Peer AS: 65001
Age: 2w0d 1:28:31 Metric: 10
Task: BGP_65001.10.1.45.2+179
AS path: 65001 I
Localpref: 100
Router ID: 10.0.0.5
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:
user@host> show route destination-prefix < detail >
Saída de amostra
nome de comando
user@R4> show route 100.100.2.0 detail
inet.0: 20 destinations, 24 routes (20 active, 0 holddown, 0 hidden)
100.100.2.0/24 (2 entries, 1 announced)
*BGP Preference: 170/-101
Source: 10.0.0.2
Next hop: 10.1.24.1 via so-0/0/3.0, selected
Protocol next hop: 10.0.0.2 Indirect next hop: 8644000 277
State: <Active Int Ext>
Local AS: 65002 Peer AS: 65002
Age: 2:32:01 Metric: 5 Metric2: 10
Task: BGP_65002.10.0.0.2+179
Announcement bits (3): 0-KRT 3-BGP.0.0.0.0+179 4-Resolve inet.0
AS path: 65001 I
Localpref: 100
Router ID: 10.0.0.2
BGP Preference: 170/-101
Source: 10.1.45.2
Next hop: 10.1.45.2 via so-0/0/2.0, selected
State: <NotBest Ext>
Inactive reason: Not Best in its group
Local AS: 65002 Peer AS: 65001
Age: 2w0d 1:37:58 Metric: 10
Task: BGP_65001.10.1.45.2+179
AS path: 65001 I
Localpref: 100
Router ID: 10.0.0.5
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:
user@host> show route destination-prefix < detail >
Saída de amostra
nome de comando
user@R4> show route 100.100.3.0 detail
inet.0: 20 destinations, 24 routes (20 active, 0 holddown, 0 hidden)
100.100.3.0/24 (2 entries, 1 announced)
*BGP Preference: 170/-101
Source: 10.1.45.2
Next hop: 10.1.45.2 via so-0/0/2.0, selected
State: <Active Ext>
Local AS: 65002 Peer AS: 65001
Age: 5d 0:31:25
Task: BGP_65001.10.1.45.2+179
Announcement bits (3): 0-KRT 3-BGP.0.0.0.0+179 4-Resolve inet.0
AS path: 65001 I
Localpref: 100
Router ID: 10.0.0.5
BGP Preference: 170/-101
Source: 10.0.0.2
Next hop: 10.1.24.1 via so-0/0/3.0, selected
Protocol next hop: 10.0.0.2 Indirect next hop: 8644000 277
State: <NotBest Int Ext>
Inactive reason: Interior > Exterior > Exterior via Interior
Local AS: 65002 Peer AS: 65002
Age: 2:48:18 Metric2: 10
Task: BGP_65002.10.0.0.2+179
AS path: 65001 I
Localpref: 100
Router ID: 10.0.0.2
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:
user@host> show route destination-prefix < detail >
Saída de amostra
nome de comando
user@R6> show route 100.100.4.0 detail
inet.0: 18 destinations, 20 routes (18 active, 0 holddown, 0 hidden)
100.100.4.0/24 (2 entries, 1 announced)
*BGP Preference: 170/-101
Source: 10.0.0.4
Next hop: 10.1.46.1 via so-0/0/1.0, selected
Protocol next hop: 10.0.0.4 Indirect next hop: 864c000 276
State: <Active Int Ext>
Local AS: 65002 Peer AS: 65002
Age: 2:16:11 Metric2: 10
Task: BGP_65002.10.0.0.4+4120
Announcement bits (2): 0-KRT 4-Resolve inet.0
AS path: 65001 I
Localpref: 100
Router ID: 10.0.0.4
BGP Preference: 170/-101
Source: 10.0.0.2
Next hop: 10.1.46.1 via so-0/0/1.0, selected
Next hop: 10.1.36.1 via so-0/0/3.0
Protocol next hop: 10.0.0.2 Indirect next hop: 864c0b0 278
State: <NotBest Int Ext>
Inactive reason: IGP metric
Local AS: 65002 Peer AS: 65002
Age: 2:16:03 Metric2: 20
Task: BGP_65002.10.0.0.2+179
AS path: 65001 I
Localpref: 100
Router ID: 10.0.0.2
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
Tarefas |
Comando ou ação |
|---|---|
| Verificando a camada BGP | |
|
|
|
|
|
|
|
|
|
|
A sequência de comandos a seguir aborda o problema específico descrito neste tópico:
|
|
|
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.
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.
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
- Confira as sessões do BGP
- Verifique a configuração do BGP
- Examine as rotas BGP
- Verifique as rotas BGP recebidas
- Tomando as medidas apropriadas para resolver o problema da rede
- Verifique se o tráfego BGP está usando o LSP novamente
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:
user@host> traceroute hostname
Saída de amostra
nome de comando
user@R1> traceroute 100.100.6.1 traceroute to 100.100.6.1 (100.100.6.1), 30 hops max, 40 byte packets 1 10.1.13.2 (10.1.13.2) 0.653 ms 0.590 ms 0.543 ms 2 10.1.36.2 (10.1.36.2) 0.553 ms !N 0.552 ms !N 0.537 ms !N user@R6> traceroute 100.100.1.1 traceroute to 100.100.1.1 (100.100.1.1), 30 hops max, 40 byte packets 1 10.1.36.1 (10.1.36.1) 0.660 ms 0.551 ms 0.526 ms 2 10.1.13.1 (10.1.13.1) 0.568 ms !N 0.553 ms !N 0.536 ms !N
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:
user@host> show bgp summary
Saída de amostra 1
nome de comando
user@R1> show bgp summary Groups: 1 Peers: 6 Down peers: 1 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 1 1 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped... 10.0.0.2 65432 11257 11259 0 0 3d 21:49:57 0/0/0 0/0/0 10.0.0.3 65432 11257 11259 0 0 3d 21:49:57 0/0/0 0/0/0 10.0.0.4 65432 11257 11259 0 0 3d 21:49:57 0/0/0 0/0/0 10.0.0.5 65432 11257 11260 0 0 3d 21:49:57 0/0/0 0/0/0 10.0.0.6 65432 4 4572 0 1 3d 21:46:59 Active 10.1.36.2 65432 11252 11257 0 0 3d 21:46:49 1/1/0 0/0/0
Saída de amostra 2
nome de comando
user@R1> show bgp summary Groups: 1 Peers: 5 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 1 1 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Damped... 10.0.0.2 65432 64 68 0 0 32:18 0/0/0 0/0/0 10.0.0.3 65432 64 67 0 0 32:02 0/0/0 0/0/0 10.0.0.4 65432 64 67 0 0 32:10 0/0/0 0/0/0 10.0.0.5 65432 64 67 0 0 32:14 0/0/0 0/0/0 10.0.0.6 65432 38 39 0 1 18:02 1/1/0 0/0/0
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:
user@host> show configuration
Saída de amostra 1
nome de comando
user@R1> show configuration
[...Output truncated...]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.1.12.1/30;
}
family iso;
family mpls;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.1.15.1/30;
}
family iso;
family mpls;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.1.13.1/30;
}
family iso;
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.143/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.1/32;
}
family iso {
address 49.0004.1000.0000.0001.00;
}
}
}
}
routing-options {
[...Output truncated...]
route 100.100.1.0/24 reject;
}
router-id 10.0.0.1;
autonomous-system 65432;
}
protocols {
rsvp {
interface so-0/0/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface fxp0.0 {
disable;
}
}
mpls {
label-switched-path R1-to-R6 {
to 10.0.0.6; <<< destination address of the LSP
}
inactive: interface so-0/0/0.0;
inactive: interface so-0/0/1.0;
interface so-0/0/2.0;
interface fxp0.0 {
disable;
}
}
bgp {
export send-statics; <<< missing local-address statement
group internal {
type internal;
neighbor 10.0.0.2;
neighbor 10.0.0.5;
neighbor 10.0.0.4;
neighbor 10.0.0.6;
neighbor 10.0.0.3;
neighbor 10.1.36.2; <<< incorrect interface address
}
}
isis {
level 1 disable;
interface so-0/0/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface all {
level 2 metric 10;
}
interface fxp0.0 {
disable;
}
interface lo0.0 {
passive;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface so-0/0/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface lo0.0; {
passive
}
}
}
}
policy-options {
policy-statement send-statics {
term statics {
from {
route-filter 100.100.1.0/24 exact;
}
then accept;
}
}
}
Saída de amostra 2
nome de comando
user@R6> show configuration
[...Output truncated...]
interfaces {
so-0/0/0 {
unit 0 {
family inet {
address 10.1.56.2/30;
}
family iso;
family mpls;
}
}
so-0/0/1 {
unit 0 {
family inet {
address 10.1.46.2/30;
}
family iso;
family mpls;
}
}
so-0/0/2 {
unit 0 {
family inet {
address 10.1.26.2/30;
}
family iso;
family mpls;
}
}
so-0/0/3 {
unit 0 {
family inet {
address 10.1.36.2/30;
}
family iso;
family mpls;
}
}
fxp0 {
unit 0 {
family inet {
address 192.168.70.148/21;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.0.0.6/32;
address 127.0.0.1/32;
}
family iso {
address 49.0004.1000.0000.0006.00;
}
}
}
}
routing-options {
[...Output truncated...]
route 100.100.6.0/24 reject;
}
router-id 10.0.0.6;
autonomous-system 65432;
}
protocols {
rsvp {
interface so-0/0/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface so-0/0/3.0;
interface fxp0.0 {
disable;
}
}
mpls {
label-switched-path R6-to-R1 {
to 10.0.0.1; <<< destination address of the reverse LSP
}
inactive: interface so-0/0/0.0;
inactive: interface so-0/0/1.0;
inactive: interface so-0/0/2.0;
interface so-0/0/3.0;
}
bgp {
group internal {
type internal;
export send-statics; <<< missing local-address statement
neighbor 10.0.0.2;
neighbor 10.0.0.3;
neighbor 10.0.0.4;
neighbor 10.0.0.5;
neighbor 10.0.0.1;
neighbor 10.1.13.1; <<< incorrect interface address
}
}
isis {
level 1 disable;
interface all {
level 2 metric 10;
}
interface fxp0.0 {
disable;
}
interface lo0.0 {
passive;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface so-0/0/0.0;
interface so-0/0/1.0;
interface so-0/0/2.0;
interface so-0/0/3.0;
interface lo0.0 {
passive;
}
}
}
}
policy-options {
policy-statement send-statics {
term statics {
from {
route-filter 100.100.6.0/24 exact;
}
then accept;
}
}
}
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.
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:
user@host> show route destination-prefix detail
Saída de amostra 1
nome de comando
user@R6> show route 100.100.1.1 detail
inet.0: 30 destinations, 46 routes (29 active, 0 holddown, 1 hidden)
100.100.1.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Source: 10.1.13.1
Next hop: via so-0/0/3.0, selected
Protocol next hop: 10.1.13.1 Indirect next hop: 8671594 304
State: <Active Int Ext>
Local AS: 65432 Peer AS: 65432
Age: 4d 5:15:39 Metric2: 2
Task: BGP_65432.10.1.13.1+3048
Announcement bits (2): 0-KRT 4-Resolve inet.0
AS path: I
Localpref: 100
Router ID: 10.0.0.1
Saída de amostra 2
nome de comando
user@R6> show route 100.100.1.1 detail
inet.0: 30 destinations, 46 routes (29 active, 0 holddown, 1 hidden)
100.100.1.0/24 (1 entry, 1 announced)
*BGP Preference: 170/-101
Source: 10.0.0.1
Next hop: via so-0/0/3.0 weight 1, selected
Label-switched-path R6-to-R1
Label operation: Push 100000
Protocol next hop: 10.0.0.1 Indirect next hop: 8671330 301
State: <Active Int Ext>
Local AS: 65432 Peer AS: 65432
Age: 24:35 Metric2: 2
Task: BGP_65432.10.0.0.1+179
Announcement bits (2): 0-KRT 4-Resolve inet.0
AS path: I
Localpref: 100
Router ID: 10.0.0.1
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:
user@host> show route receive protocol bgp neighbor-address
Saída de amostra 1
nome de comando
user@R6> show route receive-protocol bgp 10.0.0.1 inet.0: 30 destinations, 46 routes (29 active, 0 holddown, 1 hidden) <<< missing route inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) mpls.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) __juniper_private1__.inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
Saída de amostra 2
nome de comando
user@R6> show route receive-protocol bgp 10.0.0.1 inet.0: 30 destinations, 46 routes (29 active, 0 holddown, 1 hidden) Prefix Nexthop MED Lclpref AS path * 100.100.1.0/24 10.0.0.1 100 I inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) iso.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden) mpls.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden) __juniper_private1__.inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
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:
[edit]
user@R2# delete routing-options static route destination-prefix
user@R2# commit and-quit
user@R2# show route destination-prefix
Saída de amostra
[edit]
user@R2# delete routing-options static route 10.0.0.5/32
[edit]
user@R2# commit and-quit
commit complete
Exiting configuration mode
user@R2> show route 10.0.0.5
inet.0: 22 destinations, 24 routes (22 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.5/32 *[BGP/170] 3d 20:26:17, MED 5, localpref 100
AS path: 65001 I
> to 10.1.12.1 via so-0/0/0.0
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:
user@host> traceroute hostname
Saída de amostra
nome de comando
user@R1> traceroute 100.100.6.1
traceroute to 100.100.6.1 (100.100.6.1), 30 hops max, 40 byte packets
1 10.1.13.2 (10.1.13.2) 0.858 ms 0.740 ms 0.714 ms
MPLS Label=100016 CoS=0 TTL=1 S=1
2 10.1.36.2 (10.1.36.2) 0.592 ms !N 0.564 ms !N 0.548 ms !N
user@R6> traceroute 100.100.1.1
traceroute to 100.100.1.1 (100.100.1.1), 30 hops max, 40 byte packets
1 10.1.36.1 (10.1.36.1) 0.817 ms 0.697 ms 0.771 ms
MPLS Label=100000 CoS=0 TTL=1 S=1
2 10.1.13.1 (10.1.13.1) 0.581 ms !N 0.567 ms !N 0.544 ms !N
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:
No modo de configuração, vá para o seguinte nível de hierarquia:
[edit] user@host# edit protocol bgp traceoptions
Configure a bandeira para exibir informações enviadas, recebidas ou enviadas e recebidas:
[edit protocols bgp traceoptions] user@host# set flag update sendou
[edit protocols bgp traceoptions] user@host# set flag update receive
ou
[edit protocols bgp traceoptions] user@host# set flag update
Verifique a configuração:
user@host# show
Por exemplo:
[edit protocols bgp traceoptions] user@host# show file bgplog size 10k files 10; flag update send;
ou
[edit protocols bgp traceoptions] user@host# show file bgplog size 10k files 10; flag update receive;
ou
[edit protocols bgp traceoptions] user@host# show file bgplog size 10k files 10; flag update send receive;
Confirmar a configuração:
user@host# commit
Veja o conteúdo do arquivo que contém as mensagens detalhadas:
user@host# run show log filenamePor exemplo:
[edit protocols bgp traceoptions] user@host# run show log bgplog Sep 13 12:58:23 trace_on: Tracing to "/var/log/bgplog" started Sep 13 12:58:23 BGP RECV flags 0x40 code ASPath(2): <null> Sep 13 12:58:23 BGP RECV flags 0x40 code LocalPref(5): 100 Sep 13 12:58:23 BGP RECV flags 0xc0 code Extended Communities(16): 2:10458:3 [...Output truncated...]
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:
user@host> show route forwarding-table
Saída de amostra
nome de comando
user@R2> show route forwarding-table Routing table: inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 10 1 10.0.0.2/32 intf 0 10.0.0.2 locl 256 1 10.0.0.3/32 user 1 10.1.23.0 ucst 282 4 so-0/0/1.0 10.0.0.4/32 user 1 10.1.24.0 ucst 290 7 so-0/0/3.0 10.0.0.6/32 user 1 10.1.24.0 ucst 290 7 so-0/0/3.0 10.1.12.0/30 intf 1 ff.3.0.21 ucst 278 6 so-0/0/0.0 10.1.12.0/32 dest 0 10.1.12.0 recv 280 1 so-0/0/0.0 10.1.12.2/32 intf 0 10.1.12.2 locl 277 1 10.1.12.3/32 dest 0 10.1.12.3 bcst 279 1 so-0/0/0.0 10.1.23.0/30 intf 0 ff.3.0.21 ucst 282 4 so-0/0/1.0 10.1.23.0/32 dest 0 10.1.23.0 recv 284 1 so-0/0/1.0 10.1.23.1/32 intf 0 10.1.23.1 locl 281 1 10.1.23.3/32 dest 0 10.1.23.3 bcst 283 1 so-0/0/1.0 10.1.24.0/30 intf 0 ff.3.0.21 ucst 290 7 so-0/0/3.0 10.1.24.0/32 dest 0 10.1.24.0 recv 292 1 so-0/0/3.0 10.1.24.1/32 intf 0 10.1.24.1 locl 289 1 10.1.24.3/32 dest 0 10.1.24.3 bcst 291 1 so-0/0/3.0 10.1.36.0/30 user 0 10.1.23.0 ucst 282 4 so-0/0/1.0 10.1.46.0/30 user 0 10.1.24.0 ucst 290 7 so-0/0/3.0 100.100.1.0/24 user 0 10.1.12.0 ucst 278 6 so-0/0/0.0 100.100.2.0/24 user 0 10.1.12.0 ucst 278 6 so-0/0/0.0 100.100.3.0/24 user 0 10.1.12.0 ucst 278 6 so-0/0/0.0 100.100.4.0/24 user 0 10.1.12.0 ucst 278 6 so-0/0/0.0 [...Output truncated...]
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.
user@host# show policy-options
policy-statement accept-no-install {
term 1 {
from protocol bgp;
then accept;
}
}
user@host# show routing-options
forwarding-table {
export accept-no-install;
}
user@host> show route forwarding-table Routing table: default.inet Internet: Destination Type RtRef Next hop Type Index NhRef Netif default perm 0 rjct 36 2
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.
set policy-options prefix-list install-bgp 66.0.0.1/32 set policy-options policy-statement override-ptx-series-default term 1 from prefix-list install-bgp set policy-options policy-statement override-ptx-series-default term 1 then load-balance per-prefix set policy-options policy-statement override-ptx-series-default term 1 then install-to-fib set routing-options forwarding-table export override-ptx-series-default
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:
Configure uma lista de prefixos para instalar na tabela de encaminhamento.
[edit policy-options prefix-list install-bgp] user@host# set 66.0.0.1/32
Configure a política de roteamento, aplicando a lista de prefixo como condição.
[edit policy-options policy-statement override-ptx-series-default term 1] user@host# set from prefix-list install-bgp user@host# set then install-to-fib user@host# set then load-balance per-prefix
Aplique a política de roteamento na tabela de encaminhamento.
[edit routing-options forwarding-table] user@host# set export override-ptx-series-default
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.
user@host# show policy-options
prefix-list install-bgp {
66.0.0.1/32;
}
policy-statement override-ptx-series-default {
term 1 {
from {
prefix-list install-bgp;
}
then {
load-balance per-prefix;
install-to-fib;
}
}
}
user@host# show routing-options
forwarding-table {
export override-ptx-series-default;
}
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.
user@host> show route forwarding-table destination 66.0.0.1
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
66.0.0.1/32 user 0 indr 2097159 3
ulst 2097156 2
5.1.0.2 ucst 574 1 et-6/0/0.1
5.2.0.2 ucst 575 1 et-6/0/0.2
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:
No modo de configuração, vá para o seguinte nível de hierarquia:
[edit] user@host# edit protocol bgpConfigure o log do sistema:
user@host# set log-updown
Verifique a configuração:
user@host# show
Confirmar a configuração:
user@host# commit
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.
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
- Diagnosticar problemas de estabelecimento de sessão BGP
Exibir informações detalhadas do protocolo BGP
Ação
Para exibir detalhadamente as informações do protocolo BGP, siga essas etapas:
No modo de configuração, vá para o seguinte nível de hierarquia:
[edit] user@host# edit protocol bgp traceoptions
Configure a bandeira para exibir mensagens de protocolo BGP detalhadas:
[edit protocols bgp traceoptions] user@host# set flag update detail
Verifique a configuração:
user@host# show
Por exemplo:
[edit protocols bgp traceoptions] user@host# show flag update detail;
Confirmar a configuração:
user@host# commit
Veja o conteúdo do arquivo que contém as mensagens detalhadas:
user@host# run show log filenamePor exemplo:
[edit protocols bgp traceoptions] user@pro5-a# run show log bgp Sep 17 14:47:16 trace_on: Tracing to "/var/log/bgp" started Sep 17 14:47:17 bgp_read_v4_update: receiving packet(s) from 10.255.245.53 (Internal AS 10458) Sep 17 14:47:17 BGP RECV 10.255.245.53+179 -> 10.255.245.50+1141 Sep 17 14:47:17 BGP RECV message type 2 (Update) length 128 Sep 17 14:47:17 BGP RECV flags 0x40 code Origin(1): IGP Sep 17 14:47:17 BGP RECV flags 0x40 code ASPath(2): 2 Sep 17 14:47:17 BGP RECV flags 0x80 code MultiExitDisc(4): 0 Sep 17 14:47:17 BGP RECV flags 0x40 code LocalPref(5): 100 Sep 17 14:47:17 BGP RECV flags 0xc0 code Extended Communities(16): 2:10458:1 [...Output truncated...]
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.
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:
No modo de configuração, vá para o seguinte nível de hierarquia:
[edit] user@host# edit protocol bgpConfigure mensagens abertas BGP:
[edit protocols bgp] user@host# set traceoptions flag open detail
Verifique a configuração:
user@host# show
Por exemplo:
[edit protocols bgp] user@host# show traceoptions { file bgplog size 10k files 10; flag open detail; }Confirmar a configuração:
user@host# commit
Veja o conteúdo do arquivo que contém as mensagens detalhadas:
user@host#run show log filenamePor exemplo:
[edit protocols bgp] user@hotst# run show log bgplog
Sep 17 17:13:14 trace_on: Tracing to "/var/log/bgplog" started Sep 17 17:13:14 bgp_read_v4_update: done with 201.0.0.2 (Internal AS 10458) received 19 octets 0 updates 0 routes Sep 17 17:13:15 bgp_read_v4_update: receiving packet(s) from 201.0.0.3 (Internal AS 10458) Sep 17 17:13:15 bgp_read_v4_update: done with 201.0.0.3 (Internal AS 10458) received 19 octets 0 updates 0 routes Sep 17 17:13:44 bgp_read_v4_update: receiving packet(s) from 201.0.0.2 (Internal AS 10458) [...Output truncated...]
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
- Exibição de pacotes de protocolo IS-IS enviados ou recebidos
- Analisando detalhadamente as PDUs de estado de enlace IS-IS
Exibição de informações detalhadas do protocolo IS-IS
Ação
Para rastrear detalhadamente as mensagens IS-IS, siga essas etapas:
Configure a bandeira para exibir mensagens de protocolo IS-IS detalhadas.
[edit protocols isis traceoptions] user@host# set flag hello detail
Verifique a configuração.
user@host# show
Por exemplo:
[edit protocols isis traceoptions] user@host# show file isislog size 10k files 10; flag hello detail;
Confirmar a configuração.
user@host# commit
Veja o conteúdo do arquivo que contém as mensagens detalhadas.
user@host# run show log filenamePor exemplo:
user@host# run show log isislog
Nov 29 23:17:50 trace_on: Tracing to "/var/log/isislog" started Nov 29 23:17:50 Sending PTP IIH on so-1/1/1.0 Nov 29 23:17:53 Sending PTP IIH on so-1/1/0.0 Nov 29 23:17:54 Received PTP IIH, source id abc-core-01 on so-1/1/0.0 Nov 29 23:17:54 from interface index 11 Nov 29 23:17:54 max area 0, circuit type l2, packet length 4469 Nov 29 23:17:54 hold time 30, circuit id 6 Nov 29 23:17:54 neighbor state up Nov 29 23:17:54 speaks IP Nov 29 23:17:54 area address 99.0008 (1) Nov 29 23:17:54 IP address 10.10.10.29 Nov 29 23:17:54 4396 bytes of total padding Nov 29 23:17:54 updating neighbor abc-core-01 Nov 29 23:17:55 Received PTP IIH, source id abc-core-02 on so-1/1/1.0 Nov 29 23:17:55 from interface index 12 Nov 29 23:17:55 max area 0, circuit type l2, packet length 4469 Nov 29 23:17:55 hold time 30, circuit id 6 Nov 29 23:17:55 neighbor state up Nov 29 23:17:55 speaks IP Nov 29 23:17:55 area address 99.0000 (1) Nov 29 23:17:55 IP address 10.10.10.33 Nov 29 23:17:55 4396 bytes of total padding Nov 29 23:17:55 updating neighbor abc-core-02
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.
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 |
Consulte também
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:
Configure a bandeira para exibir pacotes enviados, recebidos ou enviados e recebidos.
[edit protocols isis traceoptions] user@host# set flag hello send
ou
[edit protocols isis traceoptions] user@host# set flag hello receive
ou
[edit protocols isis traceoptions] user@host# set flag hello
Verifique a configuração.
user@host# show
Por exemplo:
[edit protocols isis traceoptions] user@host# show file isislog size 10k files 10; flag hello send;
ou
[edit protocols isis traceoptions] user@host# show file isislog size 10k files 10; flag hello receive;
ou
[edit protocols isis traceoptions] user@host# show file isislog size 10k files 10; flag hello send receive;
Confirmar a configuração.
user@host# commit
Veja o conteúdo do arquivo que contém as mensagens detalhadas.
user@host# run show log filenamePor exemplo:
user@host# run show log isislog Sep 27 18:17:01 ISIS periodic xmit to 01:80:c2:00:00:15 (IFL 2) Sep 27 18:17:01 ISIS periodic xmit to 01:80:c2:00:00:14 (IFL 2) Sep 27 18:17:03 ISIS periodic xmit to 01:80:c2:00:00:15 (IFL 2) Sep 27 18:17:04 ISIS periodic xmit to 01:80:c2:00:00:14 (IFL 2) Sep 27 18:17:06 ISIS L2 hello from 0000.0000.0008 (IFL 2) absorbed Sep 27 18:17:06 ISIS periodic xmit to 01:80:c2:00:00:15 (IFL 2) Sep 27 18:17:06 ISIS L1 hello from 0000.0000.0008 (IFL 2) absorbed
Consulte também
Analisando detalhadamente as PDUs de estado de enlace IS-IS
Para analisar detalhadamente as PDUs de estado de enlace IS-IS, siga estas etapas:
Configure mensagens abertas IS-IS.
[edit protocols isis traceoptions] user@host# set flag lsp detail
Verifique a configuração.
user@host# show
Por exemplo:
[edit protocols isis traceoptions] user@host# show file isislog size 5m world-readable; flag error; flag lsp detail;
Confirmar a configuração.
user@host# commit
Veja o conteúdo do arquivo que contém as mensagens detalhadas.
user@host# run show log filenamePor exemplo:
user@host# run show log isislog Nov 28 20:17:24 Received L2 LSP abc-core-01.00-00, interface so-1/1/0.0 Nov 28 20:17:24 from abc-core-01 Nov 28 20:17:24 sequence 0x1c4f9, checksum 0x9fea, lifetime 1199 Nov 28 20:17:24 max area 0, length 426 Nov 28 20:17:24 no partition repair, no database overload Nov 28 20:17:24 IS type 3, metric type 0 Nov 28 20:17:24 area address 99.0908 (1) Nov 28 20:17:24 speaks CLNP Nov 28 20:17:24 speaks IP Nov 28 20:17:24 dyn hostname abc-core-01 Nov 28 20:17:24 IP address 10.10.134.11 Nov 28 20:17:24 IP prefix: 10.10.10.0/30 metric 1 up Nov 28 20:17:24 IP prefix: 10.10.10.4/30 metric 5 up Nov 28 20:17:24 IP prefix: 10.10.10.56/30 metric 5 up Nov 28 20:17:24 IP prefix: 10.10.10.52/30 metric 1 up Nov 28 20:17:24 IP prefix: 10.10.10.64/30 metric 5 up Nov 28 20:17:24 IP prefix: 10.10.10.20/30 metric 5 up Nov 28 20:17:24 IP prefix: 10.10.10.28/30 metric 5 up Nov 28 20:17:24 IP prefix: 10.10.10.44/30 metric 5 up Nov 28 20:17:24 IP prefix 10.10.10.0 255.255.255.252 Nov 28 20:17:24 internal, metrics: default 1 Nov 28 20:17:24 IP prefix 10.10.10.4 255.255.255.252 Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IP prefix 10.10.10.56 255.255.255.252 Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IP prefix 10.10.10.52 255.255.255.252 Nov 28 20:17:24 internal, metrics: default 1 Nov 28 20:17:24 IP prefix 10.10.10.64 255.255.255.252 Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IP prefix 10.10.10.20 255.255.255.252 Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IP prefix 10.10.10.28 255.255.255.252 Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IP prefix 10.10.10.44 255.255.255.252 Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IS neighbors: Nov 28 20:17:24 IS neighbor abc-core-02.00 Nov 28 20:17:24 internal, metrics: default 1 [...Output truncated...] Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IS neighbor abc-brdr-01.00 Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IS neighbor abc-core-02.00, metric: 1 Nov 28 20:17:24 IS neighbor abc-esr-02.00, metric: 5 Nov 28 20:17:24 IS neighbor abc-edge-03.00, metric: 5 Nov 28 20:17:24 IS neighbor abc-edge-01.00, metric: 5 Nov 28 20:17:24 IS neighbor abc-edge-02.00, metric: 5 Nov 28 20:17:24 IS neighbor abc-brdr-01.00, metric: 5 Nov 28 20:17:24 IP prefix: 10.10.134.11/32 metric 0 up Nov 28 20:17:24 IP prefix: 10.11.0.0/16 metric 5 up Nov 28 20:17:24 IP prefix: 10.211.0.0/16 metric 0 up Nov 28 20:17:24 IP prefix 10.10.134.11 255.255.255.255 Nov 28 20:17:24 internal, metrics: default 0 Nov 28 20:17:24 IP prefix 10.11.0.0 255.255.0.0 Nov 28 20:17:24 internal, metrics: default 5 Nov 28 20:17:24 IP prefix 10.211.0.0 255.255.0.0 Nov 28 20:17:24 internal, metrics: default 0 Nov 28 20:17:24 Updating LSP Nov 28 20:17:24 Updating L2 LSP abc-core-01.00-00 in TED Nov 28 20:17:24 Analyzing subtlv's for abc-core-02.00 Nov 28 20:17:24 Analysis complete Nov 28 20:17:24 Analyzing subtlv's for abc-esr-02.00 Nov 28 20:17:24 Analysis complete Nov 28 20:17:24 Analyzing subtlv's for abc-edge-03.00 Nov 28 20:17:24 Analysis complete Nov 28 20:17:24 Analyzing subtlv's for abc-edge-01.00 Nov 28 20:17:24 Analysis complete Nov 28 20:17:24 Analyzing subtlv's for abc-edge-02.00 Nov 28 20:17:24 Analysis complete Nov 28 20:17:24 Analyzing subtlv's for abc-brdr-01.00 Nov 28 20:17:24 Analysis complete Nov 28 20:17:24 Scheduling L2 LSP abc-core-01.00-00 sequence 0x1c4f9 on interface so-1/1/1.0
Consulte também
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
- Analise detalhadamente os pacotes de anúncios de estado de enlace do OSPF
Diagnosticar problemas de estabelecimento de sessão osPF
Ação
Para rastrear detalhadamente as mensagens OSPF, siga essas etapas:
No modo de configuração, vá para o seguinte nível de hierarquia:
[edit] user@host# edit protocols ospf traceoptions
Configure mensagens de olá do OSPF:
[edit protocols ospf traceoptions] user@host# set flag hello detail
Verifique a configuração:
user@host# show
Por exemplo:
[edit protocols ospf traceoptions] user@host# show file ospf size 5m world-readable; flag hello detail;
Confirmar a configuração:
user@host# commit
Veja o conteúdo do arquivo que contém as mensagens detalhadas:
user@host# run show log filenamePor exemplo:
user@host# run show log ospf
Dec 2 16:14:24 Version 2, length 44, ID 10.0.0.6, area 1.0.0.0 Dec 2 16:14:24 checksum 0xf01a, authtype 0 Dec 2 16:14:24 mask 0.0.0.0, hello_ivl 10, opts 0x2, prio 128 Dec 2 16:14:24 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0 Dec 2 16:14:24 OSPF sent Hello (1) -> 224.0.0.5 (so-1/1/2.0) Dec 2 16:14:24 Version 2, length 44, ID 10.0.0.6, area 1.0.0.0 Dec 2 16:14:24 checksum 0xf01a, authtype 0 Dec 2 16:14:24 mask 0.0.0.0, hello_ivl 10, opts 0x2, prio 128 Dec 2 16:14:24 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0 Dec 2 16:14:26 OSPF rcvd Hello 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0) Dec 2 16:14:26 Version 2, length 48, ID 10.10.134.12, area 0.0.0.0 Dec 2 16:14:26 checksum 0x99b8, authtype 0Dec 2 16:14:26 mask 255.255.255.252, hello_ivl 10, opts 0x2, prio 1 ec 2 16:14:26 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0 Dec 2 16:14:29 OSPF rcvd Hello 10.10.10.29 -> 224.0.0.5 (so-1/1/0.0) Dec 2 16:14:29 Version 2, length 48, ID 10.108.134.11, area 0.0.0.0 Dec 2 16:14:29 checksum 0x99b9, authtype 0Dec 2 16:14:29 mask 255.255.255.252, hello_ivl 10, opts 0x2, prio 1 Dec 2 16:14:29 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0
Significado
Tabela 6 lista bandeiras de rastreamento OSPF e apresenta saída de exemplo para algumas das bandeiras.
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:
No modo de configuração, vá para o seguinte nível de hierarquia:
[edit] user@host# edit protocols ospf traceoptions
Configure os pacotes de estado do enlace OSPF:
[edit protocols ospf traceoptions] user@host# set flag lsa-update detail
Verifique a configuração:
user@host# show
Por exemplo:
[edit protocols ospf traceoptions] user@host# show file ospf size 5m world-readable; flag hello detail; flag lsa-update detail;
Confirmar a configuração:
user@host# commit
Veja o conteúdo do arquivo que contém as mensagens detalhadas:
user@host# run show log filenamePor exemplo:
user@host# run show log ospf
Dec 2 16:23:47 OSPF sent LSUpdate (4) -> 224.0.0.5 (so-1/1/0.0) ec 2 16:23:47 Version 2, length 196, ID 10.0.0.6, area 0.0.0.0 Dec 2 16:23:47 checksum 0xcc46, authtype 0 Dec 2 16:23:47 adv count 6 Dec 2 16:23:47 OSPF sent LSUpdate (4) -> 224.0.0.5 (so-1/1/1.0) Dec 2 16:23:47 Version 2, length 196, ID 10.0.0.6, area 0.0.0.0 Dec 2 16:23:47 checksum 0xcc46, authtype 0 Dec 2 16:23:47 adv count 6