Solução de problemas de sessões BGP
Lista de verificação para verificar o protocolo BGP e os pares
Finalidade
A Tabela 1 fornece links e comandos para verificar se o Border Gateway Protocol (BGP) está configurado corretamente em um roteador da Juniper Networks em sua rede, se as sessões internas do Border Gateway Protocol (IBGP) e externas do Border Gateway Protocol (EBGP) estão devidamente estabelecidas, se as rotas externas estão anunciadas e recebidas corretamente e se o processo de seleção de caminho do BGP está funcionando corretamente.
Ação
Tarefas |
Comando ou ação |
|---|---|
| Verificar peers BGP | |
|
|
|
|
|
|
|
|
| Examine as rotas BGP e a seleção de rotas | |
|
|
|
|
|
|
|
|
| Examinar rotas na tabela de encaminhamento |
|
Verificar peers BGP
Finalidade
Supondo que todos os roteadores estejam configurados corretamente para o BGP, você pode verificar se as sessões de IBGP e EBGP estão devidamente estabelecidas, se as rotas externas são anunciadas e recebidas corretamente e se o processo de seleção de caminho do BGP está funcionando corretamente.
A Figura 1 ilustra um exemplo de topologia de rede BGP usada neste tópico.
de rede BGP
A rede consiste em dois ASs diretamente conectados 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 peers internos são conectados por meio de suas interfaces de loopback (lo0) através do IBGP. O AS 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 conectados diretamente, o IGP subjacente permite que os vizinhos se conectem.
Os dois roteadores no AS 65001 contêm um link EBGP para o AS 65002 (R2 e R4) sobre o qual eles anunciam prefixos agregados: 100.100.1.0, 100.100.2.0, 100.100.3.0, e 100.100.4.0. Além disso, R1 e R5 estão injetando vários valores de discriminador de saída (MED) de 5 e 10, respectivamente, para algumas rotas.
Os roteadores internos em ambos os 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 rotas, 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 , R3 não distribui essa rota para R6 porque a rota é aprendida através do R2IBGP, então 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 de 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 da 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 EBGP estabelecida comR1. -
R4deve ter uma sessão EBGP estabelecida comR5.
Para verificar os pares BGP, siga estas etapas:
- Verificar o BGP em um roteador interno
- Verificar o BGP em um roteador de borda
- Verificar rotas BGP anunciadas
- Verifique se uma rota BGP específica foi recebida em seu roteador
Verificar o BGP em um roteador interno
Finalidade
Para verificar a configuração BGP de um roteador interno.
Ação
Para verificar a configuração de BGP de um roteador interno, insira o seguinte comando da interface de linha de comando (CLI) do Junos OS:
user@host> show configuration
A saída de exemplo a seguir é para uma configuração de BGP em R3:
Saída de amostra
nome do 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 exemplo mostra uma configuração básica de BGP 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.2 , 10.0.0.4e 10.0.0.6— incluídos no nível R6 deprotocols bgp group group [] hierarquia. Também tem três pares internos: 10.0.0.2, 10.0.0.3, e 10.0.0.4. O protocolo IGP subjacente é o Sistema Intermediário para Sistema Intermediário (IS-IS), e as interfaces relevantes são configuradas para executar o IS-IS.
Observe que, nessa configuração, o ID do roteador é configurado manualmente para evitar problemas de ID do roteador duplicado.
Verificar o BGP em um roteador de borda
Finalidade
Para verificar a configuração BGP de um roteador de borda.
Ação
Para verificar a configuração BGP de um roteador de borda, entre no seguinte comando de modo operacional Junos OS CLI:
user@host> show configuration
Saída de amostra
nome do comando
O exemplo de saída a seguir é para uma configuração de BGP em dois roteadores de borda, R2 e R4 do 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 exemplo mostra uma configuração básica de BGP em roteadores de R2 borda e R4. Ambos os roteadores têm o AS (65002) incluído no nível derouting-options [] hierarquia. Cada roteador tem dois grupos incluídos no nível deprotocols bgp group group[ ] hierarquia. Os pares externos são incluídos no grupo externo, toR1 ou toR5, dependendo do roteador. Os pares internos são incluídos no internal grupo. O protocolo IGP subjacente é IS-IS em ambos os roteadores, e as interfaces relevantes são configuradas para executar 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 é incluída para evitar problemas de acessibilidade de próximo salto do BGP.
Verificar rotas BGP anunciadas
Finalidade
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 foram preparadas para anúncio ao vizinho BGP especificado, entre no seguinte comando de modo operacional Junos OS CLI:
user@host> show route advertising-protocol bgp neighbor-address
Saída de amostra
nome do 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 exemplo mostra as rotas BGP anunciadas R2 para 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 estado antes de serem declaradas ativas e as hold-down hidden rotas rejeitadas por uma política de roteamento podem ser colocadas no 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 foi recebida em seu roteador
Finalidade
Exiba as informações de roteamento conforme elas são recebidas por um vizinho BGP específico e anunciadas pelo roteador local para o vizinho.
Ação
Para verificar se uma rota BGP específica é recebida em seu roteador, entre no seguinte comando de modo operacional Junos OS CLI:
user@host> show route receive-protocol bgp neighbor-address
Saída de amostra
nome do 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 exemplo 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 de R4 estão ativas na tabela de roteamento. Todas as rotas BGP passaram pelo AS 65001.
Examine as rotas BGP e a seleção de rotas
Finalidade
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.
de rede BGP
A rede na Figura 2 mostra que R1 e R5 anuncia as mesmas rotas agregadas para R2 e R4, que resulta em R2 e R4 recebendo duas rotas para o mesmo prefixo de destino. O processo de seleção de rota determina R2 qual R4 das duas rotas BGP recebidas está ativa e anunciada para os outros roteadores internos (R3 e R6).
Antes de o roteador instalar uma rota BGP, ele deve certificar-se de que o atributo BGP next-hop esteja acessível. Se o próximo salto do 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 caminho se houver várias rotas para o mesmo prefixo de destino. O processo de seleção de caminho BGP prossegue na seguinte ordem:
-
A preferência de rota na tabela de roteamento é comparada. Por exemplo, se um OSPF e uma rota BGP existirem para um destino específico, 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 quanto à preferência local. A rota com a maior preferência local é a preferida. Por exemplo, consulte Examinar a seleção de preferência local.
-
O atributo do caminho AS é avaliado. O caminho AS mais curto é o preferido.
-
O código de origem é avaliado. O código de origem mais baixo é preferido (
I (IGP) < E (EGP) < ? (Incomplete)). -
O valor MED é avaliado. Por padrão, se qualquer uma das rotas for anunciada do mesmo AS vizinho, o valor de MED mais baixo será preferido. A ausência de um valor de MED é interpretada como um MED de 0. Para obter um exemplo, consulte Examinar a seleção de rota do discriminador de saída múltipla.
-
A rota é avaliada para saber se é aprendida por meio de EBGP ou IBGP. As rotas aprendidas do EBGP são preferidas às rotas aprendidas do IBGP. Para obter um exemplo, consulte Examinar a seleção de EBGP sobre IBGP
-
Se a rota for aprendida do IBGP, a rota com o menor custo de IGP é a preferida. Para obter um exemplo, consulte Examinar a seleção de custo do IGP. O próximo salto físico para o peer do IBGP é instalado de acordo com as três regras a seguir:
-
-
Depois que o BGP examina as tabelas e de
inet.0inet.3roteamento, o próximo salto físico da rota com a preferência mais baixa é usado.
-
-
-
Se os valores de preferência nas
inet.0tabelas e nasinet.3tabelas de roteamento estiverem empatados, o próximo salto físico da rota nainet.3tabela de roteamento será 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 cluster de comprimento mais curto é preferida. As rotas sem uma lista de clusters são consideradas como tendo um comprimento de lista de cluster de 0.
-
O ID do roteador é avaliado. A rota do peer com o ID de roteador mais baixo é preferida (geralmente o endereço de loopback).
-
O valor do endereço do par é examinado. O peer com o endereço IP de peer mais baixo é o preferido.
Para determinar o caminho único e ativo quando o BGP recebe várias rotas para o mesmo prefixo de destino, entre no seguinte comando de modo operacional Junos OS CLI:
user@host> show route
destination-prefix
< detail >
As etapas a seguir ilustram o motivo de inatividade exibido quando o BGP recebe várias rotas para o mesmo prefixo de destino e uma rota é selecionada como o único caminho ativo:
- Examine a seleção de preferência local
- Examine a seleção de rota discriminatória de saída múltipla
- Examine a seleção de EBGP sobre IBGP
- Examine a seleção de custo do IGP
Examine a seleção de preferência local
Finalidade
Para 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 e 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 do 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 exemplo mostra que R4 recebeu duas instâncias da 100.100.1.0 rota: uma de 10.0.0.2 (R2) e outra de 10.1.45.2 (R5). R4 selecionou o caminho de 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 maior preferência local é o preferido. No exemplo, o caminho com o maior valor de preferência local é o caminho de R2, 200.
O motivo pelo qual a rota de R5 não está selecionada está no Inactive reason campo, neste caso, Local Preference.
Observe que os dois caminhos são da mesma rede vizinha: AS 65001.
Examine a seleção de rota discriminatória de saída múltipla
Finalidade
Para examinar uma rota para determinar se o MED é o critério de seleção para o caminho único e ativo.
Ação
Para examinar uma rota e 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 do 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 exemplo mostra que R4 recebeu duas instâncias da 100.100.2.0 rota: uma de 10.0.0.2 (R2) e outra de 10.1.45.2 (R5). R4 selecionou o caminho de R2 como sua rota ativa, conforme indicado pelo asterisco (*). A seleção é baseada no valor 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: AS 65001.
O motivo pelo qual o caminho inativo não está selecionado é exibido no Inactive reason: campo, neste caso, Not Best in its group. O texto é usado porque o Junos OS usa o processo de seleção MED determinística, por padrão.
Examine a seleção de EBGP sobre IBGP
Finalidade
Examinar uma rota para determinar se o EBGP está selecionado em vez do IBGP como o critério de seleção para o caminho único e ativo.
Ação
Para examinar uma rota para determinar se o EBGP está selecionado sobre o IBGP como o critério de seleção para o caminho único e ativo, insira o seguinte comando do modo operacional Junos OS CLI:
user@host> show route destination-prefix < detail >
Saída de amostra
nome do 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 exemplo mostra que R4 recebeu duas instâncias da 100.100.3.0 rota: uma de 10.1.45.2 (R5) e outra de 10.0.0.2 (R2). R4 selecionou o caminho de R5 como seu caminho ativo, conforme indicado pelo asterisco (*). A seleção é baseada em uma preferência por rotas aprendidas de um peer EBGP em vez de rotas aprendidas de um IBGP. R5 é um par EBGP.
Você pode determinar se um caminho é recebido de um peer EBGP ou IBGP examinando os Local As campos e Peer As . Por exemplo, a rota de R5 mostra que o AS local é 65002 e o peer AS é 65001, indicando que a rota é recebida de um peer EBGP. A rota de R2 mostra que o AS local e peer é 65002, indicando que ele é recebido de um peer do IBGP.
O motivo pelo qual o caminho inativo não está selecionado é exibido no Inactive reason campo, neste caso, Interior > Exterior > Exterior via Interior. A redação desse motivo mostra a ordem das preferências aplicadas quando a mesma rota é recebida de dois roteadores. A rota recebida de uma fonte estritamente interna (IGP) é 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) é preferida por último. Portanto, as rotas EBGP são selecionadas em vez de rotas do IBGP como o caminho ativo.
Examine a seleção de custo do IGP
Finalidade
Examinar uma rota para determinar se o EBGP está selecionado em vez do IBGP como o critério de seleção para o caminho único e ativo.
Ação
Para examinar uma rota para determinar se o EBGP está selecionado sobre o IBGP como o critério de seleção para o caminho único e ativo, insira o seguinte comando do modo operacional Junos OS CLI:
user@host> show route destination-prefix < detail >
Saída de amostra
nome do 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 exemplo mostra que R6 recebeu duas instâncias da 100.100.4.0 rota: uma de 10.0.0.4 (R4) e outra de 10.0.0.2 (R2). R6 selecionou o caminho de R4 como sua rota ativa, conforme indicado pelo asterisco (*). A seleção é baseada na métrica IGP, exibida no Metric2 campo. A rota com a métrica de IGP mais baixa é a preferida. No exemplo, o caminho com o menor valor de métrica de IGP é o caminho de , com um valor de métrica de R4IGP de 10, enquanto o caminho de tem uma métrica de R2 IGP de 20. Observe que os dois caminhos são da mesma rede vizinha: AS 65001.
O motivo pelo qual o caminho inativo não foi selecionado é exibido no 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 os comandos para verificar a configuração de BGP da rede Multiprotocol Label Switching (MPLS). A lista de verificação fornece 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 a 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
Finalidade
Depois de configurar o caminho comutado por rótulos (LSP) e determinar que ele está ativo, configurar o BGP e determinar que as sessões estão estabelecidas, certifique-se de que o BGP esteja usando o LSP para encaminhar o tráfego.
A Figura 3 ilustra a camada BGP do modelo MPLS em camadas.
BGP
Ao verificar a camada BGP, você verifica se a rota está presente e ativa e, mais importante, garante que o próximo salto seja o LSP. Não faz sentido verificar a camada BGP a menos que o LSP esteja estabelecido, porque o BGP usa o LSP MPLS para encaminhar o tráfego. Se a rede não estiver funcionando na camada BGP, o LSP não funcionará como configurado.
A Figura 4 ilustra a rede MPLS usada neste tópico.
BGP
A rede mostrada na Figura 4 é uma configuração de malha completa, na qual cada interface conectada diretamente pode receber e enviar pacotes para todas as outras interfaces semelhantes. O LSP nessa rede está configurado para ser executado do roteador de entrada R1, passando pelo roteador de trânsito R3, até o roteador de saída R6. Além disso, um LSP reverso é configurado para ir de R6 a R3 a R1, criando tráfego bidirecional.
A cruz mostrada na Figura 4 indica onde o BGP não está sendo usado para encaminhar o tráfego pelo LSP. As possíveis razões para o LSP não funcionar corretamente são que o endereço IP de destino do LSP não é igual ao próximo salto do BGP ou que o BGP não está configurado corretamente.
Para verificar a camada BGP, siga estas etapas:
- Verifique se o tráfego BGP está usando o LSP
- Verificar sessões de BGP
- Verificar a configuração do BGP
- Examinar rotas BGP
- Verificar rotas BGP recebidas
- Tomar as medidas apropriadas para resolver o problema de rede
- Verifique se o tráfego BGP está usando o LSP novamente
Verifique se o tráfego BGP está usando o LSP
Finalidade
Nesse nível do modelo de solução de problemas, o BGP e o LSP podem estar ativos, no entanto, o tráfego BGP pode não estar usando o LSP para encaminhar o tráfego.
Ação
Para verificar se o tráfego BGP está usando o LSP, entre no seguinte comando de modo operacional da interface de linha de comando (CLI) do Junos OS no roteador de entrada:
user@host> traceroute hostname
Saída de amostra
nome do 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 exemplo mostra que o tráfego BGP não está usando o LSP, consequentemente os rótulos 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 alcançar o endereço de saída LSP de próximo salto do BGP para R6 e R1. O padrão do Junos OS é usar LSPs para tráfego BGP quando o próximo salto do BGP é igual ao endereço de saída do LSP.
Verificar sessões de BGP
Finalidade
Exiba informações resumidas 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 de BGP estão ativas, entre no seguinte comando de modo operacional Junos OS CLI no roteador de entrada:
user@host> show bgp summary
Saída de amostra 1
nome do 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 do 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 exemplo 1 mostra que um peer (roteador de saída 10.0.0.6 ) não está estabelecido, conforme indicado pelo campo Down Peers: 1 . A última coluna (Estado|#Active/Recebido/Amortecido) mostra que o peer 10.0.0.6 está ativo, indicando que ele não está estabelecido. Todos os outros peers são estabelecidos conforme indicado pelo número de rotas ativas, recebidas e amortecidas. Por exemplo, 0/0/0 para o 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 o peer 10.1.36.2 indica que uma rota BGP estava ativa e recebida na tabela de roteamento, e nenhuma rota BGP foi amortecida.
Se a saída do show bgp summary comando de um roteador de entrada mostrar que um vizinho está inativo, verifique a configuração do BGP. Para obter informações sobre como verificar a configuração do BGP, consulte Verificar a configuração do BGP.
A saída de exemplo 2 mostra a saída do roteador de entrada R1 depois que as configurações de BGP em R1 e R6 foram corrigidas em Tomando as medidas apropriadas para resolver o problema de rede. Todos os pares BGP são estabelecidos e uma rota está ativa e recebida. Nenhuma rota BGP foi amortecida.
Se a saída do show bgp summary comando mostrar que um vizinho está ativo, mas os pacotes não estão sendo encaminhados, verifique as rotas recebidas do roteador de saída. Para obter informações sobre como verificar se há rotas recebidas no roteador de saída, consulte Verificar rotas BGP recebidas.
Verificar a configuração do BGP
Finalidade
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 (o endereço IP e o número AS do peer). 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 próximo salto do BGP para que as rotas BGP sejam instaladas com o LSP como o próximo salto para essas rotas.
Ação
Para verificar a configuração do BGP, entre no seguinte comando Junos OS CLI operational mode:
user@host> show configuration
Saída de amostra 1
nome do 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 do 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 exemplo mostra as configurações de BGP no roteador de entrada R1 e no roteador de saída R6. Ambas as configurações mostram o AS local (65432), um grupo (internal) e seis pares configurados. O protocolo de gateway interior subjacente é o IS-IS e as interfaces relevantes são configuradas para executar o IS-IS.
Nessa configuração, o RID é configurado manualmente para evitar problemas de RID duplicados, e todas as interfaces configuradas com BGP incluem a family inet declaração no nível deunitedit interfaces type-fpc/pic/port logical-unit-number [ ] hierarquia.
A saída de exemplo para o roteador de entrada R1 e o roteador de saída R6 mostra que a configuração do protocolo BGP não tem 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 da interface de loopback (lo0) do roteador local, que é o endereço para o qual os pares BGP estão emparelhando. Se a local-address declaração não estiver configurada, os pacotes BGP serão encaminhados do endereço da interface de saída, que não corresponde ao endereço para o qual os pares BGP estão emparelhando, 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 noedit protocols mpls label-switched-path lsp-path-namenível 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 do BGP inclui R1 dois endereços IP para R6, um endereço de interface (10.1.36.2) e um endereço de interface de loopback (lo0) (10.0.0.6), resultando no endereço de destino LSP (10.0.0.6) não correspondente ao endereço de próximo salto do BGP (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) não correspondendo ao endereço next-hop do BGP (10.1.13.1).
Nesse caso, como a local-address declaração está ausente nas configurações de BGP de ambos os roteadores e o endereço de destino do LSP não corresponde ao endereço de próximo salto do BGP, o BGP não está usando o LSP para encaminhar o tráfego.
Examinar rotas BGP
Finalidade
Você pode examinar o processo de seleção de caminho do BGP para determinar o caminho único e ativo quando o BGP recebe várias rotas para o mesmo destino. Nesta etapa, examinamos o LSP reverso R6 para R1, tornando 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 do 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 do 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 exemplo 1 mostra que o próximo salto do BGP (10.1.13.1) não é igual ao to endereço de destino do LSP (10.0.0.1) na declaração no nível de [edit protocols mpls label-switched-pathlabel-switched-path-name] hierarquia quando a configuração do BGP de R6 e R1 está incorreta.
A saída de exemplo 2, obtida após as configurações em R1 e R6 serem corrigidas, mostra que o próximo salto do BGP (10.0.0.1) e o endereço de destino do LSP (10.0.0.1) são os mesmos, indicando que o BGP pode usar o LSP para encaminhar o tráfego BGP.
Verificar rotas BGP recebidas
Finalidade
Exiba as informações de roteamento recebidas no roteador R6, o roteador de entrada para o LSP reverso R6 para R1.
Ação
Para verificar se uma rota BGP específica é recebida no roteador de saída, entre no seguinte comando de modo operacional Junos OS CLI:
user@host> show route receive protocol bgp neighbor-address
Saída de amostra 1
nome do 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 do 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 exemplo 1 mostra que o roteador de entrada R6 (LSP reverso R6 para R1) não recebe nenhuma rota BGP na tabela de roteamento inet.0 quando as configurações de BGP de R1 e R6 estão incorretas.
A saída de exemplo 2 mostra uma rota BGP instalada na tabela de roteamento inet.0 após as configurações de BGP em R1 e R6 serem corrigidas usando a ação apropriada para resolver o problema de rede.
Tomar as medidas apropriadas para resolver o problema de rede
Problema
Descrição
A ação apropriada depende do tipo de problema que você isolou. Neste exemplo, uma rota estática configurada em R2 é excluída do nível de hierarquia [routing-options]. Outras ações apropriadas podem incluir o seguinte:
Solução
Verifique a configuração do roteador local e edite-a, se apropriado.
Solucione problemas do roteador intermediário.
Verifique a configuração do host remoto e edite-a, se apropriado.
Solucione problemas de protocolos de roteamento.
Identifique outras possíveis causas.
Para resolver o problema neste exemplo, insira os seguintes comandos Junos OS CLI:
[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 exemplo mostra a rota estática excluída darouting-options [] hierarquia e a nova configuração confirmada. A saída do show route comando agora mostra a rota BGP como a rota preferencial, conforme indicado pelo asterisco (*).
Verifique se o tráfego BGP está usando o LSP novamente
Finalidade
Depois de tomar a ação apropriada para corrigir o erro, o LSP precisa ser verificado novamente para confirmar se o tráfego BGP está usando o LSP e se o problema na camada BGP foi resolvido.
Ação
Para verificar se o tráfego BGP está usando o LSP, entre no seguinte comando de modo operacional Junos OS CLI do roteador de entrada:
user@host> traceroute hostname
Saída de amostra
nome do 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 exemplo 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 vida útil (TTL=1) e o valor de bit de pilha (S=1).
O campo Rótulo MPLS é 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 vida útil (TTL) contém um limite para o número de saltos que esse pacote MPLS pode trafegar pela rede (1). Ele é diminuído a cada salto e, se o valor de TTL cair abaixo de um, o pacote será descartado.
A parte inferior do valor do bit da pilha (S=1) indica que é o último rótulo na pilha e que esse 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 de 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 de pilha de rótulos MPLS.
Os rótulos MPLS aparecem na saída de exemplo porque o traceroute comando é emitido para um destino BGP onde o próximo salto do BGP para essa rota é o endereço de saída do LSP. O Junos OS, por padrão, usa LSPs para tráfego BGP quando o próximo salto do BGP é igual ao endereço de saída do LSP.
Se o próximo salto do BGP não for igual ao endereço de saída do LSP, o tráfego BGP não usará o LSP e, consequentemente, os rótulos MPLS não aparecerão na saída do traceroute comando, conforme indicado na saída de exemplo em Verificar sessões BGP.
Exibir pacotes BGP enviados ou recebidos
Ação
Para configurar o rastreamento para pacotes de protocolo BGP enviados ou recebidos, siga estas etapas:
No modo de configuração, vá para o seguinte nível de hierarquia:
[edit] user@host# edit protocol bgp traceoptions
Configure o sinalizador para exibir informações de pacotes enviados, recebidos ou enviados e recebidos:
[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;
Confirme 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...]
Examinar rotas na tabela de encaminhamento
Finalidade
Quando você se depara com problemas, como problemas de conectividade, pode ser necessário examinar as rotas na tabela de encaminhamento para verificar se o processo do protocolo de roteamento retransmitiu 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 do 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 exemplo 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 next-hop que no comando (o endereço next-hop e o nome da show route detail interface). As informações adicionais incluem o tipo de destino, o tipo de próximo salto, o número de referências a esse 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 dos pacotes enviados por uma interface. Esse banco de dados não está acessível ao usuário.
Para obter informações detalhadas sobre os significados dos vários campos de sinalizadores e tipos, consulte o Guia do usuário de políticas de roteamento, filtros de firewall e policiadores de tráfego.
Exemplo: Substituição da política de roteamento BGP padrão 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.
Requerimentos
Este exemplo requer o Junos OS versão 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 then accept ação não tem o resultado usual que tem em outros dispositivos de roteamento do Junos OS. Com a seguinte política de roteamento 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 then install-to-fib ação para substituir efetivamente a política de roteamento BGP padrão.
Configuração
Configuração rápida da CLI
Para configurar rapidamente este exemplo, copie os comandos a seguir, cole-os em um arquivo de texto, remova as quebras de linha, altere os detalhes necessários para corresponder à configuração de rede e, em seguida, copie e cole os comandos na 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 requer que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Uso do Editor de CLI no Modo de Configuração no Guia do Usuário da CLI do Junos OS.
Para instalar rotas BGP selecionadas na tabela de encaminhamento:
Configure uma lista de prefixos a serem instalados 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 prefixos como uma 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 à tabela de encaminhamento.
[edit routing-options forwarding-table] user@host# set export override-ptx-series-default
Resultados
No modo de configuração, confirme sua configuração digitando os show policy-options comandos e show routing-options . 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
Finalidade
Certifique-se de que a política configurada substitua a política padrão.
Ação
Do modo operacional, insira o 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.
Registrar eventos de transição de estado do BGP
Finalidade
As transições de estado do Border Gateway Protocol (BGP) indicam um problema de rede e precisam ser registradas e investigadas.
Ação
Para registrar eventos de transição de estado do BGP no 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
Confirme a configuração:
user@host# commit
Significado
As mensagens de log de eventos de transição de estado do BGP são suficientes para diagnosticar a maioria dos problemas de sessão do BGP. A Tabela 3 lista e descreve os seis estados de uma sessão BGP.
Estado do BGP |
Descrição |
|---|---|
Ocioso |
Esse é o primeiro estado de uma conexão. O BGP aguarda um evento de início iniciado por um administrador. O evento de início pode ser o estabelecimento de uma sessão BGP por meio da configuração do roteador ou a redefinição de uma sessão existente. Após o evento de início, o BGP inicializa seus recursos, redefine um temporizador de nova tentativa de conexão, inicia uma conexão de transporte TCP e começa a escutar conexões iniciadas por pares remotos. Em seguida, o BGP faz a transição para um estado Connect . Se houver erros, o BGP retornará ao estado Inativo . |
Conecte-se |
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 fará a transição para OpenSent. Se a conexão de transporte não for bem-sucedida, o estado será transferido para Ativo. Se o temporizador de nova tentativa de conexão tiver expirado, o estado permanecerá no estado Conectar , o temporizador será redefinido e uma conexão de transporte será iniciada. Com qualquer outro evento, o estado volta ao ocioso. |
Ativo |
O BGP tenta adquirir um peer iniciando uma conexão de protocolo de transporte. Se for bem-sucedido, o estado fará a transição para OpenSent. Se o temporizador de nova tentativa de conexão expirar, o BGP reiniciará o temporizador de conexão e voltará ao estado Conectar . O BGP continua a escutar uma conexão que pode ser iniciada de outro peer. O estado pode voltar para Ocioso no caso de outros eventos, como um evento de parada. Em geral, uma inversão de estado vizinho entre Connect 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 TCP ou pela incapacidade de um vizinho de acessar o endereço IP de seu peer. |
Enviado Aberto |
O BGP recebe uma mensagem aberta de seu peer. No estado OpenSend , o BGP compara seu número de sistema autônomo (AS) com o número AS de seu peer e reconhece se o peer pertence ao mesmo AS (BGP interno) ou a um AS diferente (BGP externo). A mensagem aberta é verificada quanto à correção. Em caso de erros, como um número de versão incorreto de um AS inaceitável, o BGP envia uma mensagem de notificação de erro e volta para Ocioso. Para quaisquer outros erros, como expiração do temporizador de espera ou um evento de parada, o BGP envia uma mensagem de notificação com o código de erro correspondente e volta para o estado Idle . Se não houver erros, o BGP enviará mensagens keepalive e redefinirá o temporizador keepalive. Nesse estado, o tempo de espera é negociado. Se o tempo de espera for 0, os temporizadores de espera e keepalive não serão reiniciados. Quando uma desconexão de transporte TCP é detectada, o estado volta para Ativo. |
AbrirConfirmar |
O BGP aguarda uma mensagem keepalive ou de notificação. Se um keepalive for recebido, o estado se tornará Estabelecido e a negociação de vizinhos será concluída. Se o sistema receber uma mensagem de atualização ou keepalive, ele reiniciará o temporizador de espera (supondo que o tempo de espera negociado não seja 0). Se uma mensagem de notificação for recebida, o estado voltará para Ocioso. O sistema envia mensagens keepalive periódicas na taxa definida pelo temporizador keepalive. No caso de uma notificação de desconexão de transporte ou em resposta a um evento de parada, o estado volta para Ocioso. 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 Ocioso. |
Estabelecido |
Esse é o estado final na negociação de vizinhos. Nesse estado, o BGP troca ackets de atualização com seus pares e o temporizador de espera é reiniciado no recebimento de uma mensagem de atualização ou keepalive quando não está definido como zero. Se o sistema receber uma mensagem de notificação, o estado voltará para Ocioso. As mensagens de atualização são verificadas quanto a erros, como atributos ausentes, atributos duplicados e assim por diante. Se forem encontrados erros, uma notificação será enviada ao par e o estado voltará para Ocioso. O BGP volta para ocioso quando o temporizador de espera expira, 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 sobre o pacote do protocolo BGP, configure o rastreamento específico do BGP. Consulte Lista de verificação para acompanhar condições de erro para obter mais informações.
Configurar opções específicas do BGP
Finalidade
Quando ocorrem eventos ou problemas inesperados, ou se você deseja diagnosticar problemas de estabelecimento do BGP, pode visualizar informações mais detalhadas configurando opções específicas para o BGP. Você também pode configurar o rastreamento para um peer BGP ou grupo de peer específico. Para obter mais informações, consulte o Guia de configuração do Junos System Basics.
- 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 as informações do protocolo BGP em detalhes, siga estas etapas:
No modo de configuração, vá para o seguinte nível de hierarquia:
[edit] user@host# edit protocol bgp traceoptions
Configure o sinalizador para exibir mensagens detalhadas do protocolo BGP:
[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;
Confirme 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
A Tabela 4 lista os sinalizadores de rastreamento específicos do BGP e apresenta exemplos de saída para alguns dos sinalizadores. Você também pode configurar o rastreamento para um peer BGP ou grupo de peer específico. Para obter mais informações, consulte o Guia de configuração do Junos System Basics.
Sinalizadores de rastreamento |
Descrição |
Exemplo de saída |
|---|---|---|
Aspath |
Operações de expressão regular de caminho AS |
Não disponível. |
Amortecimento |
Operações de amortecimento |
28 de novembro 17:01:12 bgp_damp_change: Alterar evento 28 de novembro 17:01:12 bgp_dampen: Amortecimento 10.10.1.0 28 de novembro 17:01:12 bgp_damp_change: Alterar evento 28 de novembro 17:01:12 bgp_dampen: Amortecimento 10.10.2.0 28 de novembro 17:01:12 bgp_damp_change: Alterar evento 28 de novembro 17:01:12 bgp_dampen: Amortecimento 10.10.3.0 |
Mantenha-se vivo |
Mensagens de keepalive do BGP |
28 de novembro 17:09:27 bgp_send: enviando 19 bytes para 10.09 217.5.101 (AS externo 65471) 28 de novembro 17:09:27 28 de novembro 17:09:27 BGP ENVIAR 10.217.5.1+179 -> 10.217.5.101+52162 28 de novembro 17:09:27 BGP ENVIAR tipo de mensagem 4 (KeepAlive) comprimento 19 28 de novembro 17:09:28 28 de novembro 17:09:28 BGP RECV 10.217.5.101+52162 -> 10.217.5.1+179 28 de novembro 17:09:28 BGP Tipo de mensagem RECV 4 (KeepAlive) comprimento 19 |
aberto |
Pacotes abertos BGP |
28 de novembro 18:37:42 bgp_send: enviando 37 bytes para 10.217.5.101 (AS externo 65471) 28 de novembro 18:37:42 28 de novembro 18:37:42 BGP ENVIAR 10.217.5.1+179 -> 10.217.5.101+38135 28 de novembro 18:37:42 BGP ENVIAR tipo de mensagem 1 (Aberto) comprimento 37 |
pacotes |
Todos os pacotes de protocolo BGP |
27 de setembro 17:00 45:31 BGP RECV 10.0.100.108+179 -> 10.0.100.105+1033 27 de setembro 17:45:31 BGP Tipo de mensagem RECV 4 (KeepAlive) comprimento 19 Sep 27 17:45:31 bgp_send: enviando 19 bytes para 10.0.100.108 (AS 100 interno) Sep 27 17:45:31 BGP SEND 10.0.100.105+1033 -> 10.0.100.108+179 Sep 27 17:45:31 BGP SEND tipo de mensagem 4 (KeepAlive) comprimento 19 Sep 27 17:45:31 bgp_read_v4_update: recebendo pacote(s) de 10.0.100.108 (AS 100 interno) |
atualização |
Atualizar pacotes |
28 de novembro 19:05:24 BGP ENVIAR 10.05 217.5.1+179 -> 10.217.5.101+55813 28 de novembro 19:05:24 BGP ENVIAR tipo de mensagem 2 (Atualização) comprimento 53 28 de novembro 19:05:24 bgp_send: enviando 65 bytes para 10.217.5.101 (AS externo 65471) 28 de novembro 19:05:24 28 de novembro 19:05:24 BGP ENVIAR 10.217.5.1+179 -> 10.217.5.101+55813 28 de novembro 19:05:24 BGP ENVIAR tipo de mensagem 2 (Atualização) comprimento 65 28 de novembro 19:05:24 bgp_send: envio de 55 bytes para 10.217.5.101 (AS 65471 externo) |
Diagnosticar problemas de estabelecimento de sessão BGP
Finalidade
Para rastrear problemas de estabelecimento de sessão BGP.
Ação
Para rastrear problemas de estabelecimento de sessão BGP, siga estas etapas:
No modo de configuração, vá para o seguinte nível de hierarquia:
[edit] user@host# edit protocol bgpConfigure mensagens abertas do 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; }Confirme 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...]
Configurar opções específicas do IS-IS
Finalidade
Quando ocorrem eventos ou problemas inesperados, ou se você deseja diagnosticar problemas de estabelecimento de adjacência do IS-IS, pode exibir informações mais detalhadas configurando opções específicas do IS-IS.
Para configurar as opções do IS-IS, siga estas etapas:
- Exibindo informações detalhadas do protocolo IS-IS
- Exibindo pacotes de protocolo IS-IS enviados ou recebidos
- Analisando detalhadamente as PDUs de estado de enlace IS-IS
Exibindo informações detalhadas do protocolo IS-IS
Ação
Para rastrear mensagens IS-IS em detalhes, siga estas etapas:
Configure o sinalizador para exibir mensagens detalhadas do protocolo IS-IS.
[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;
Comprometa a configuração.
user@host# commit
Exiba 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
A Tabela 5 lista os sinalizadores de rastreamento que podem ser configurados especificamente para o IS-IS e apresenta a saída de exemplo para alguns dos sinalizadores.
Sinalizadores de rastreamento |
Descrição |
Exemplo de saída |
|---|---|---|
csn |
PDU de número de sequência completo (CSNP) |
28 de novembro 20:02:48 Enviando CSN L2 na interface so-1/1/0.0Nov 28 20:02:48 Enviando CSN L2 na interface so-1/1/1.0 Com a opção de detalhe . 28 de novembro 20:06:08 Enviando L2 CSN na interface so-1/1/1.0Nov 28 20:06:08 LSP abc-core-01.00-00 vida útil 1146Nov 28 20:08 06:08 sequência 0x1c4f8 checksum 0xa1e9Nov 28 20:06:08 LSP abc-core-02.00-00 lifetime 411Nov 28 20:06:08 sequência 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 sequência 0x45cc checksum 0x6883 |
Olá |
Pacote Hello |
28 de novembro 20:13:50 Enviando PTP IIH em soo-1/1/1.0Nov 28 20:13:50 Recebido PTP IIH, id de fonte abc-core-01 em soo-1/1/0.0Nov 28 20:13:53 Recebido PTP IIH, id de fonte abc-core-02 em so-1/1/1.0Nov 28 20:13:57 Enviando PTP IIH em so-1/1/0.0Nov 28 20:13:58 Recebido PTP IIH, id de fonte abc-core-01 em soo-1/1/0.0Nov 28 20:13:59 Enviando PTP IIH em so-1/1/1.0 |
LSP |
PDUs de estado de enlace (LSPs) |
28 de novembro 20:15:46 Recebido L2 LSP abc-edge-01.00-00, interface so-1/1/0.0Nov 28 20:15:46 de abc-core-01Nov 28 20:15:46 sequência 0x1617, soma de verificação 0xd92a, tempo de vida 1197Nov 28 20:15:46 Atualizando L2 LSP abc-edge-01.00-00 em TEDNov 28 20:15:47 Recebido L2 LSP abc-edge-01.00-00, interface so-1/1/1.0Nov 28 20:15:47 de abc-core-02Nov 28 20:15:47 sequência 0x1617, soma de verificação 0xd92a, tempo de vida 1197 |
Geração de LSP |
Pacotes de geração de PDU de estado de enlace |
28 de novembro 20:21:24 Regenerando L1 LSP abc-edge-03.00-00, sequência antiga 0x682 28 de novembro 20:24 21:27 Reconstruindo L1, fragmento abc-edge-03.00-00Nov 28 20:21:27 Reconstruído L1 fragmento abc-edge-03.00-00, tamanho 59Nov 28 20:31:52 Regenerando L2 LSP abc-edge-03.00-00, sequência antiga 0x689Nov 28 20:31:54 Reconstruindo L2, fragmento abc-edge-03.00-00Nov 28 20:31:54 Reconstruído fragmento L2 abc-edge-03.00-00, tamanho 256Nov 28 20:34:05 Regenerando L1 LSP abc-edge-03.00-00, sequência antiga 0x683Nov 28 20:34:08 Reconstruindo L1, fragmento abc-edge-03.00-00Nov 28 20:34:08 Fragmento L1 reconstruído abc-edge-03.00-00, tamanho 59 |
pacotes |
Todos os pacotes de protocolo IS-IS |
Não disponível. |
PSN |
Pacotes PSNP (PDU de número de sequência parcial) |
28 de novembro 20:40:39 Recebido L2 PSN, fonte abc-core-01, interface so-1/1/0.0Nov 28 20:40:39 Recebido L2 PSN, fonte abc-core-02, interface so-1/1/1.0Nov 28 20:41:36 Enviando L2 PSN na interface so-1/1/1.0Nov 28 20:41:36 Enviando L2 PSN na interface so-1/1/0.0Nov 28 20:42:35 Recebido L2 PSN, fonte 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 sequência 0x68c checksum 0x746dNov 28 20:42:35 Recebido L2 PSN, fonte abc-core-01, interface so-1/1/0.028 de novembro 20:42:35 LSP abc-edge-03.00-00 lifetime 1196Nov 28 20:42:35 sequência 0x68c checksum 0x746dNov 28 20:42:49 Enviando L2 PSN na interface so-1/1/1.0Nov 28 20:42:49 LSP abc-core-01.00-00 lifetime 1197Nov 28 20:42:49 sequência 0x1c4fb checksum 0x9becNov 28 20:42:49 Enviando L2 PSN na interface so-1/1/0.0Nov 28 20:42:49 LSP abc-core-01.00-00 lifetime 1197Nov 28 20:42:49 sequência 0x1c4fb checksum 0x9bec |
FPS |
Cálculos de caminho mais rápido primeiro (shortest-path-first, SPF) |
28 de novembro 20:44:01 Agendamento de SPF para L1: ReconfigNov 28 20:44:01 Agendamento de SPF de multicast para L1: ReconfigNov 28 20:44:01 Agendamento de SPF para L2: ReconfigNov 28 20:44:01 Agendamento de SPF de multicast para L2: ReconfigNov 28 20:44:02 Executando L1 SPFNov 28 20:44:02 Inicialização de SPF L1 concluída: tempo cumulativo de 0,000099sNov 28 20:44:02 Processamento primário de SPF L1 concluído: tempo cumulativo de 0,000303sNov 28 20:44:02 Pós-processamento do resultado do SPF L1 concluído: Tempo cumulativo de 0,000497sNov 28 20:44:02 Pós-processamento L1 SPF RIB concluído: tempo cumulativo de 0,000626sNov 28 20:44:02 Pós-processamento completo da tabela de roteamento SPF L1: tempo cumulativo de 0,000736s |
Veja também
Exibindo pacotes de protocolo IS-IS enviados ou recebidos
Para configurar o rastreamento apenas para pacotes de protocolo IS-IS enviados ou recebidos, siga estas etapas:
Configure o sinalizador 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;
Comprometa a configuração.
user@host# commit
Exiba 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
Veja também
Analisando detalhadamente as PDUs de estado de enlace IS-IS
Para analisar detalhadamente as PDUs de estado de enlace do IS-IS, siga estas etapas:
Configure mensagens abertas do 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;
Comprometa a configuração.
user@host# commit
Exiba 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
Veja também
Configurar opções específicas do OSPF
Finalidade
Quando ocorrerem eventos inesperados ou problemas, ou se você quiser diagnosticar problemas de estabelecimento de vizinhos OSPF, poderá exibir informações mais detalhadas configurando opções específicas para OSPF.
Para configurar as opções de OSPF, siga estas etapas:
- Diagnosticar problemas de estabelecimento de sessão OSPF
- Analisar detalhadamente os pacotes de anúncio de estado de enlace OSPF
Diagnosticar problemas de estabelecimento de sessão OSPF
Ação
Para rastrear mensagens OSPF em detalhes, siga estas etapas:
No modo de configuração, vá para o seguinte nível de hierarquia:
[edit] user@host# edit protocols ospf traceoptions
Configure mensagens de saudação 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;
Confirme 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
A Tabela 6 lista os sinalizadores de rastreamento OSPF e apresenta exemplos de saída para alguns dos sinalizadores.
Sinalizadores de rastreamento |
Descrição |
Exemplo de saída |
|---|---|---|
descrição de banco de dados |
Todos os pacotes de descrição do banco de dados |
2 de dezembro 15:: 44:51 RPD_OSPF_NBRDOWN: OSPF estado do vizinho 10.10.10.29 (so-1/1/0.0) alterado de Full para Down 2 de dezembro 15:44:51 RPD_OSPF_NBRDOWN: OSPF estado do vizinho 10.10.10.33 (so-1/1/1.0) alterado de Full para Down 2 de dezembro 15:44:55 RPD_OSPF_NBRUP: OSPF estado do vizinho 10.10.10.33 (so-1/1/1.0) alterado de Init para ExStart 2 de dezembro 15:44:55 OSPF enviou DbD (2) -> 224.0.0.5 (so-1/1/1.0) 2 de dezembro 15:44:55 Versão 2, comprimento 32, ID 10.0.0.6, área 0.0.0.0 2 de dezembro 15:44:55 soma de verificação 0xf76b, authtype 0 2 de dezembro 15:44:55 opções 0x42, i 1, m 1, ms 1, seq 0xa009eee, mtu 4470 2 de dezembro 15:44:55 OSPF rcvd DbD 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0) 2 de dezembro 15:44:55 Versão 2, comprimento 32, ID 10.10.134.12, área 0.0.0.0 2 de dezembro 15:44:55 0x312c de soma de verificação, authtype 0 2 de dezembro 15:44:55 opções 0x42, i 1, m 1, ms 1, seq 0x2154, mtu 4470 |
erro |
Pacotes com erro de OSPF |
2 de dezembro 15:49:34 Pacote OSPF ignorado: nenhuma interface correspondente de 172.16.120.29 2 de dezembro 15:49:44 Pacote OSPF ignorado: nenhuma interface correspondente de 172.16.120.29 2 de dezembro 15:49:54 Pacote OSPF ignorado: nenhuma interface correspondente de 172.16.120.29 2 de dezembro 15:50:04 Pacote OSPF ignorado: nenhuma interface correspondente de 172.16.120.29 2 de dezembro 15:50:14 Pacote OSPF ignorado: nenhuma interface correspondente de 172.16.120.29 |
evento |
Transições de estado do OSPF |
2 De dezembro 15:52:35 Interface OSPF ge-2/2/0.0 estado alterado de DR para DR 2 de dezembro 15:52:35 Interface OSPF ge-3/1/0.0 estado alterado de DR para DR 2 de dezembro 15:52:35 Interface OSPF ge-3/2/0.0 estado alterado de DR para DR 2 de dezembro 15:52:35 Interface OSPF ge-4/2/0.0 estado alterado de DR para DR 2 de dezembro 15:53:21 Vizinho OSPF 10.10.10.29 (so-1/1/0.0) estado alterado de Completo para Ativo 2 de dezembro 15:53:21 RPD_OSPF_NBRDOWN: O estado do vizinho OSPF 10.10.10.29 (so-1/1/0.0) foi alterado de Completo para Inativo 2 de dezembro 15:53:21 Vizinho OSPF 10.10.10.33 (so-1/1/1.0) estado alterado de Full para Down 2 de dezembro 15:53:21 RPD_OSPF_NBRDOWN: o estado do vizinho OSPF 10.10.10.33 (so-1/1/1.0) foi alterado de Full para Down 2 de dezembro 15:53:25 O estado do vizinho OSPF 10.10.10.33 (so-1/1/1.0) foi alterado de Down para Init 2 de dezembro 15:53:25 O estado do vizinho OSPF 10.10.10.33 (so-1/1/1.0) foi alterado de Init para ExStart 2 de dezembro 15:53:25 RPD_OSPF_ NBRUP: o estado do vizinho OSPF 10.10.10.33 (so-1/1/1.0) foi alterado de Init para ExStart 2 de dezembro 15:53:25 O estado do vizinho OSPF 10.10.10.33 (so-1/1/1.0) foi alterado de ExStart para Exchange 2 de dezembro 15:53:25 O estado do vizinho OSPF 10.10.10.33 (so-1/1/1.0) foi alterado de Exchange para Full 2 de dezembro 15:53:25 RPD_OSPF_NBRUP: o estado do vizinho OSPF 10.10.10.33 (so-1/1/1.0) foi alterado de Exchange para Full |
inundações |
Pacotes de inundação de estado de enlace |
2 de dezembro 15:: 55:21 Resumo do OSPF LSA 10.218.0.0 10.0.0.6 inundação em SO-1/1/0.0 2 de dezembro 15:55:21 Resumo do OSPF LSA 10.218.0.0 10.0.0.6 inundação em SO-1/1/1.0 2 de dezembro 15:55:21 Resumo do OSPF LSA 10.218.0.0 10.0.0.6 em nenhuma lista de rexmit SO-1/1/2.0, sem inundação 2 de dezembro 15:55:21 Resumo do OSPF LSA 10.218.0.0 10.0.0.6 em listas de rexmit SO-1/1/3.0, sem inundação 2 de dezembro 15:55:21 Resumo do OSPF LSA 10.245.0.1 10.0.0.6 em nenhuma lista de rexmit so-1/1/2.0, sem inundação 2 de dezembro 15:55:21 Resumo do OSPF LSA 10.245.0.1 10.0.0.6 em nenhuma lista de rexmit so-1/1/3.0, sem inundação |
Olá |
Olá, pacotes |
2 De Dezembro 15:57:25 OSPF enviado Olá (1) -> 224.0.0.5 (ge-3/1/0.0) 2 de dezembro 15:57:25 Versão 2, comprimento 44, ID 10.0.0.6, área 2.0.0.0 2 de dezembro 15:57:25 soma de verificação 0xe43f, authtype 0 2 de dezembro 15:57:25 máscara 255.255.0.0, hello_ivl 10, opta 0x2, prio 128 2 de dezembro 15:57:25 dead_ivl 40, DR 10.218.0.1, BDR 0.0.0.0 2 de dezembro 15:57:25 OSPF rcvd Olá 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0) 2 de dezembro 15:57:25 Versão 2, comprimento 48, ID 10.10.134.12, área 0.0.0.0 2 de dezembro 15:57:25 soma de verificação 0x99b8, authtype 0 2 de dezembro 15:57:25 máscara 255.255.255.252, hello_ivl 10, opta 0x2, prio 1 2 de dezembro 15:57:25 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0 2 de dezembro 15:57:27 OSPF enviado Olá (1) -> 224.0.0.5 (ge-3/2/0.0) 2 de dezembro 15:57:27 Versão 2, comprimento 44, ID 10.0.0.6, área 2.0.0.0 2 de dezembro 15:57:27 soma de verificação 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 Olá 10.10. 10.29 -> 224.0.0.5 (so-1/1/0.0) 2 de dezembro 15:57:28 Versão 2, comprimento 48, ID 10.10. 134.11, área 0.0.0.0 2 de dezembro 15:57:28 soma de verificação 0x99b9, authtype 0 2 de dezembro 15:57:28 máscara 255.255.255.252, hello_ivl 10, opta 0x2, prio 1 2 de dezembro 15:57:28 dead_ivl 40, DR 0.0.0.0, BDR 0.0.0.0 |
lsa-ack |
Pacotes de confirmação de estado de enlace |
2 de dezembro 16:00:11 OSPF rcvd LSAck 10.10.10.29 -> 224.0.0.5 (so-1/1/0.0) 2 de dezembro 16:00:11 Versão 2, comprimento 44, ID 10.10.134.11, área 0.0.0.0 2 de dezembro 16:00:11 soma de verificação 0xcdbf, authtype 0 2 de dezembro 16:00:11 OSPF rcvd LSAck 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0) 2 de dezembro 16:00:11 Versão 2, comprimento 144, ID 10.10. 134.12, área 0.0.0.0 2 de dezembro 16:00:11 soma de verificação 0x73bc, authtype 0 2 de dezembro 16:00:16 OSPF rcvd LSAck 10.10.10.33 -> 224.0.0.5 (so-1/1/1.0) 2 de dezembro 16:00:16 Versão 2, comprimento 44, ID 10.10. 134.12, área 0.0.0.0 2 de dezembro 16:00:16 soma de verificação 0x8180, authtype 0 |
solicitação de lsa |
Pacotes de solicitação de estado de enlace |
2 de dezembro 16:01:38 OSPF rcvd LSReq 10.10.10.29 -> 224.0.0.5 (so-1/1/0.0) 2 de dezembro 16:01:38 Versão 2, comprimento 108, ID 10.10. 134.11, área 0.0.0.0 2 de dezembro 16:01:38 soma de verificação 0xe86, authtype 0 |
atualização de LSA |
Pacotes de atualização do estado do enlace |
2 De Dec 16:09:12 OSPF construído roteador LSA, área 0.0.0.0 Dec 2 16:09:12 OSPF construído roteador LSA, área 1.. 0.0.0 2 de dezembro 16:09:12 OSPF construído roteador LSA, área 2.0.0.0 2 de dezembro 16:09:13 OSPF enviado LSUpdate (4) -> 224.0.0.5 (so-1/1/0.0) 2 de dezembro 16:09:13 Versão 2, comprimento 268, ID 10.0.0.6, área 0.0.0.0 2 de dezembro 16:09:13 soma de verificação 0x8047, authtype 0 2 de dezembro 16:09:13 contagem de anúncios 7 2 de dezembro 16:09:13 OSPF enviado LSUpdate (4) -> 224.0.0.5 (so-1/1/1.0) 2 de dezembro 16:09:13 Versão 2, comprimento 268, ID 10.0.0.6, área 0.0.0.0 2 de dezembro 16:09:13 soma de verificação 0x8047, authtype 0 2 de dezembro 16:09:13 contagem de anúncios 7 |
pacotes |
Todos os pacotes OSPF |
Não disponível. |
despejo de pacotes |
Despejar o conteúdo dos tipos de pacotes selecionados |
Não disponível. |
FPS |
Cálculos de SPF |
2 de dezembro 16:08:03 Atualização completa do SPF do OSPF agendada 2 de dezembro 16:03 08:04 OSPF SPF início, área 1.0.0.0 2 de dezembro 16:08:04 OSPF adicionar roteador LSA 10.0.0.6 distância 0 à lista SPF 2 de dezembro 16:08:04 SPF tempo decorrido 0.000525s 2 de dezembro 16:08:04 Tempo decorrido do SPF 0.000263s 2 de dezembro 16:08:04 Início do SPF OSPF, área 2.0.0.00 2 de dezembro 16:08:04 OSPF adicionar roteador LSA 10.0.0.6 distância 0 à lista SPF 2 de dezembro 16:08:04 Tempo decorrido do SPF 0.000253s 2 de dezembro 16:08:04 Esboço tempo decorrido 0.000249s 2 de dezembro 16:08:04 Início do SPF do OSPF, área 0.0.0.0 2 de dezembro 16:08:04 OSPF adiciona roteador LSA 10.0.0.6 distância 0 à lista de SPF 2 de dezembro 16:08:04 OSPF adiciona roteador LSA 10.10. 134.11 distância 1 para lista SPF 2 de dezembro 16:08:04 IP nexthop so-1/1/0.0 0.0.0.0 2 de dezembro 16:08:04 OSPF adiciona o roteador LSA 10.10. 134.12 distância 1 para a lista SPF 2 de dezembro 16:08:04 IP nexthop so-1/1/1.0 0.0.0.0 |
Analisar detalhadamente os pacotes de anúncio de estado de enlace OSPF
Ação
Para analisar detalhadamente os pacotes de anúncio de estado de enlace OSPF, siga estes passos:
No modo de configuração, vá para o seguinte nível de hierarquia:
[edit] user@host# edit protocols ospf traceoptions
Configure pacotes de estado de 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;
Confirme 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