Solución de problemas de sesiones de BGP
Lista de verificación para verificar el protocolo y los pares del BGP
Propósito
Tabla 1 proporciona vínculos y comandos para verificar si el Protocolo de puerta de enlace de borde (BGP) está configurado correctamente en un enrutador de Juniper Networks en su red, las sesiones del Protocolo de puerta de enlace de borde interno (IBGP) y el Protocolo de puerta de enlace de borde exterior (EBGP) están correctamente establecidas, las rutas externas se anuncian y se reciben correctamente, y el proceso de selección de rutas del BGP funciona correctamente.
Acción
Tareas |
Comando o acción |
|---|---|
| Verificar los pares del BGP | |
|
|
|
|
|
|
|
|
| Examinar rutas BGP y selección de rutas | |
|
|
|
|
|
|
|
|
| Examinar rutas en la tabla de reenvío |
|
Verificar los pares del BGP
Propósito
Suponiendo que todos los enrutadores están correctamente configurados para el BGP, puede verificar si las sesiones de IBGP y EBGP están bien establecidas, las rutas externas se anuncian y se reciben correctamente, y el proceso de selección de rutas del BGP funciona correctamente.
Figura 1 muestra un ejemplo de topología de red del BGP utilizada en este tema.
La red consta de dos AS conectados directamente que constan de pares externos e internos. Los pares externos se conectan directamente a través de una interfaz compartida y ejecutan EBGP. Los pares internos se conectan a través de sus interfaces de circuito cerrado (lo0) a través del IBGP. El AS 65001 ejecuta OSPF y el AS 65002 ejecuta IS-IS como su IGP subyacente. Los enrutadores IBGP no tienen que estar conectados directamente, el IGP subyacente permite que los vecinos se puedan comunicar entre sí.
Los dos enrutadores del AS 65001 contienen un vínculo EBGP al AS 65002 (R2 y R4) sobre el cual anuncian prefijos agregados: 100.100.1.0 100.100.3.0 100.100.4.0y 100.100.2.0. Además, R1 y R5 están inyectando valores discriminatorios de salida múltiple (MED) de 5 y 10, respectivamente, para algunas rutas.
Los enrutadores internos de ambos AS usan una topología IBGP de malla completa. Se requiere una malla completa porque las redes no utilizan confederaciones ni reflectores de ruta, por lo que las rutas aprendidas a través del IBGP no se distribuyen a otros vecinos internos. Por ejemplo, cuando R3 aprende una ruta de R2, R3 no distribuye esa ruta en porque la ruta se aprende a R6 través del IBGP, por lo que R6 se debe tener una conexión BGP directa para R2 aprender la ruta.
En una topología de malla completa, solo el enrutador de borde que recibe información externa del BGP distribuye esa información a otros enrutadores dentro de su AS. El enrutador receptor no redistribuye esa información a otros enrutadores IBGP en su propio AS.
Desde el punto de vista del AS 65002, se deben realizar las siguientes sesiones:
Los cuatro enrutadores del AS 65002 deben tener sesiones de IBGP establecidas entre sí.
R2debe tener una sesión de EBGP establecida conR1.R4debe tener una sesión de EBGP establecida conR5.
Para verificar los pares del BGP, siga estos pasos:
- Verificar BGP en un enrutador interno
- Verificar BGP en un enrutador de borde
- Verificar rutas de BGP anunciadas
- Verifique que se reciba una ruta BGP en particular en el enrutador
Verificar BGP en un enrutador interno
Propósito
Para comprobar la configuración del BGP de un enrutador interno.
Acción
Para comprobar la configuración del BGP de un enrutador interno, escriba el siguiente comando de interfaz de línea de comandos (CLI) de Junos OS:
user@host> show configuration
El siguiente resultado de ejemplo es para una configuración de BGP en R3:
Salida de muestra
nombre 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
La salida de ejemplo muestra una configuración BGP básica en enrutadores R3 y R6. El AS local (65002) y un grupo (internal) se configuran en ambos enrutadores. R3 tiene tres pares internos—10.0.0.2, 10.0.0.4y 10.0.0.6—se incluyen en el nivel R6 de jerarquía [protocols bgp group group]. También tiene tres pares internos: 10.0.0.2y 10.0.0.3.10.0.0.4 El protocolo IGP subyacente es de sistema intermedio a sistema intermedio (IS-IS), y las interfaces pertinentes están configuradas para ejecutar IS-IS.
Tenga en cuenta que en esta configuración, el ID del enrutador se configura manualmente para evitar cualquier problema de ID de enrutador duplicado.
Verificar BGP en un enrutador de borde
Propósito
Para comprobar la configuración del BGP de un enrutador de borde.
Acción
Para comprobar la configuración del BGP de un enrutador de borde, escriba el siguiente comando de modo operativo de LA CLI de Junos OS:
user@host> show configuration
Salida de muestra
nombre de comando
La siguiente salida de ejemplo es para una configuración de BGP en dos enrutadores de borde, R2 y R4 del 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
El resultado de ejemplo muestra una configuración BGP básica en enrutadores de R2 borde y R4. Ambos enrutadores tienen el AS (65002) incluido en el nivel de jerarquía [routing-options]. Cada enrutador tiene dos grupos incluidos en el nivel de jerarquía [protocols bgp group group]. Los pares externos se incluyen en el grupo externo, ya sea toR1 o toR5, según el enrutador. Los pares internos se incluyen en el internal grupo. El protocolo IGP subyacente es IS-IS en ambos enrutadores, y las interfaces relevantes están configuradas para ejecutar IS-IS.
Tenga en cuenta que en la configuración de ambos enrutadores, el ID del enrutador se configura manualmente para evitar problemas de ID de enrutador duplicados, y la next-hop-self instrucción se incluye para evitar cualquier problema de accesibilidad del salto siguiente del BGP.
Verificar rutas de BGP anunciadas
Propósito
Puede determinar si una ruta determinada que ha configurado se anuncia a un vecino.
Acción
Para verificar la información de enrutamiento tal como se preparó para el anuncio del vecino del BGP especificado, ingrese el siguiente comando del modo operativo de la CLI de Junos OS:
user@host> show route advertising-protocol bgp neighbor-address
Salida de muestra
nombre 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
El resultado de ejemplo muestra las rutas del BGP anunciadas desde R2 su vecino, 10.0.0.4 (R4). Del total de 22 rutas de la inet.0 tabla de enrutamiento, 20 son destinos activos. Ninguna ruta está hidden o está en el hold-down estado. Las rutas residen en el hold-down estado antes de ser declaradas activas, y las rutas rechazadas por una política de enrutamiento se pueden colocar en el hidden estado. La información mostrada refleja las rutas que la tabla de enrutamiento exportó al protocolo de enrutamiento BGP.
Verifique que se reciba una ruta BGP en particular en el enrutador
Propósito
Muestra la información de enrutamiento a medida que se recibe a través de un vecino de BGP en particular y se anuncia por el enrutador local al vecino.
Acción
Para comprobar que se recibe una ruta BGP determinada en el enrutador, escriba el siguiente comando del modo operativo de la CLI de Junos OS:
user@host> show route receive-protocol bgp neighbor-address
Salida de muestra
nombre 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
La salida de ejemplo muestra cuatro rutas de BGP desde R2 y dos desde R4. De las cuatro rutas de R2, solo dos están activas en la tabla de enrutamiento, como indica el asterisco (*), mientras que ambas rutas recibidas de están activas en la tabla de R4 enrutamiento. Todas las rutas del BGP llegaron a través del AS 65001.
Examinar rutas BGP y selección de rutas
Propósito
Puede examinar el proceso de selección de ruta del BGP para determinar la ruta única y activa cuando el BGP recibe varias rutas al mismo prefijo de destino.
La red en Figura 2 muestra eso R1 y R5 anuncia las mismas rutas agregadas a R2 y R4, que da como resultado R2 y R4 recibir dos rutas al mismo prefijo de destino. El proceso de selección de rutas en R2 y R4 determina cuál de las dos rutas de BGP recibidas está activa y anunciada a los otros enrutadores internos (R3 y R6).
Antes de que el enrutador instale una ruta BGP, debe asegurarse de que el atributo BGP next-hop sea accesible. Si el siguiente salto del BGP no se puede resolver, la ruta no está instalada. Cuando se instala una ruta BGP en la tabla de enrutamiento, debe pasar por un proceso de selección de ruta si existen varias rutas al mismo prefijo de destino. El proceso de selección de ruta del BGP se realiza en el siguiente orden:
Se compara la preferencia de ruta en la tabla de enrutamiento. Por ejemplo, si existen una ruta OSPF y un BGP para un destino determinado, la ruta OSPF se selecciona como ruta activa, ya que la ruta OSPF tiene una preferencia predeterminada de 110, mientras que la ruta BGP tiene una preferencia predeterminada de 170.
Las rutas se comparan para las preferencias locales. Se prefiere la ruta con la preferencia local más alta. Por ejemplo, consulte Examinar la selección de preferencias locales.
Se evalúa el atributo de ruta del AS. Se prefiere la ruta de AS más corta.
Se evalúa el código de origen. Se prefiere el código de origen más bajo (
I (IGP) < E (EGP) < ? (Incomplete)).Se evalúa el valor MED. De forma predeterminada, si cualquiera de las rutas se anuncia desde el mismo AS vecino, se prefiere el valor MED más bajo. La ausencia de un valor MED se interpreta como un MED de 0. Para obtener un ejemplo, consulte Examinar la selección de ruta discriminatoria de salida múltiple.
La ruta se evalúa en cuanto a si se aprende a través de EBGP o IBGP. Se prefieren las rutas aprendidas de EBGP a las rutas aprendidas del IBGP. Para obtener un ejemplo, consulte Examinar el EBGP sobre la selección de IBGP
Si la ruta se aprende del IBGP, se prefiere la ruta con el costo de IGP más bajo. Para obtener un ejemplo, consulte Examinar la selección de costos de IGP. El siguiente salto físico al par de IBGP se instala de acuerdo con las siguientes tres reglas:
Después de que el BGP examina las
inet.0tablas de enrutamiento yinet.3, se utiliza el siguiente salto físico de la ruta con la preferencia más baja.
Si los valores de preferencia en las
inet.0inet.3tablas de enrutamiento y y son un vínculo, se utiliza el salto físico siguiente de la ruta en lainet.3tabla de enrutamiento.
Cuando existe un vínculo de preferencias en la misma tabla de enrutamiento, se instala el siguiente salto físico de la ruta con más rutas.
Se evalúa el atributo de la lista de clústeres de reflexión de ruta. Se prefiere la lista de clústeres de longitud más corta. Se considera que las rutas sin una lista de clústeres tienen una longitud de lista de clústeres de 0.
Se evalúa el ID del enrutador. Se prefiere la ruta desde el par con el ID de enrutador más bajo (por lo general, la dirección de circuito cerrado).
Se examina el valor de la dirección del par. Se prefiere el par con la dirección IP del par más bajo.
Para determinar la ruta única y activa cuando el BGP recibe varias rutas al mismo prefijo de destino, ingrese el siguiente comando del modo operativo de la CLI de Junos OS:
user@host> show route destination-prefix < detail >
Los pasos siguientes ilustran la razón inactiva que se muestra cuando el BGP recibe varias rutas al mismo prefijo de destino y se selecciona una ruta como ruta única y activa:
- Examinar la selección de preferencias locales
- Examinar la selección de ruta discriminatoria de salida múltiple
- Examinar el EBGP sobre la selección de IBGP
- Examinar la selección de costos de IGP
Examinar la selección de preferencias locales
Propósito
Examinar una ruta para determinar si la preferencia local es el criterio de selección de la ruta única y activa.
Acción
Para examinar una ruta para determinar si la preferencia local es el criterio de selección para la ruta única y activa, ingrese el siguiente comando del modo operativo de CLI de Junos OS:
user@host> show route destination-prefix < detail >
Salida de muestra
nombre 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
El resultado de ejemplo muestra que R4 recibió dos instancias de la 100.100.1.0 ruta: uno desde 10.0.0.2 (R2) y otro desde 10.1.45.2 (R5). R4 se seleccionó la ruta desde R2 como su ruta activa, tal como lo indica el asterisco (*). La selección se basa en el valor de preferencia local contenido en el Localpref campo. Se prefiere la ruta con la preferencia local más alta . En el ejemplo, la ruta con el valor de preferencia local más alto es la ruta de R2, 200.
La razón por la que la ruta R5 de no está seleccionada está en el Inactive reason campo, en este caso, Local Preference.
Tenga en cuenta que las dos rutas son de la misma red vecina: AS 65001.
Examinar la selección de ruta discriminatoria de salida múltiple
Propósito
Examinar una ruta para determinar si med es el criterio de selección de la ruta única activa.
Acción
Para examinar una ruta para determinar si med es el criterio de selección de la ruta única activa, escriba el siguiente comando del modo operativo de la CLI de Junos OS:
user@host> show route destination-prefix < detail >
Salida de muestra
nombre 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
El resultado de ejemplo muestra que R4 recibió dos instancias de la 100.100.2.0 ruta: uno de 10.0.0.2 (R2), y otro de 10.1.45.2 (R5). R4 se seleccionó la ruta desde R2 como su ruta activa, tal y como indica el asterisco (*). La selección se basa en el valor MED contenido en el Metric: campo. Se prefiere la ruta con el valor MED más bajo. En el ejemplo, la ruta con el valor MED más bajo (5) es la ruta de R2. Tenga en cuenta que las dos rutas son de la misma red vecina: AS 65001.
La razón por la que la ruta inactiva no está seleccionada se muestra en el Inactive reason: campo, en este caso, Not Best in its group. La redacción se utiliza porque Junos OS utiliza el proceso de selección de MED determinista, de forma predeterminada.
Examinar el EBGP sobre la selección de IBGP
Propósito
Para examinar una ruta para determinar si ebGP está seleccionado a través de IBGP como los criterios de selección para la ruta única y activa.
Acción
Para examinar una ruta para determinar si EBGP se selecciona a través de IBGP como el criterio de selección para la ruta única y activa, escriba el siguiente comando del modo operativo de la CLI de Junos OS:
user@host> show route destination-prefix < detail >
Salida de muestra
nombre 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
El resultado de ejemplo muestra que R4 recibió dos instancias de la 100.100.3.0 ruta: uno desde 10.1.45.2 (R5) y otro desde 10.0.0.2 (R2). R4 se seleccionó la ruta desde R5 como su ruta activa, tal como lo indica el asterisco (*). La selección se basa en una preferencia por las rutas aprendidas de un par EBGP sobre las rutas aprendidas de un IBGP. R5 es un par EBGP.
Puede determinar si se recibe una ruta de un par de EBGP o IBGP mediante el examen de los Local As campos y Peer As . Por ejemplo, la ruta desde R5 muestra que el AS local es 65002 y el par as es 65001, lo que indica que la ruta se recibe de un par del EBGP. La ruta de R2 muestra que el AS local y del par es 65002, lo que indica que se recibe de un par de IBGP.
La razón por la que la ruta inactiva no está seleccionada se muestra en el Inactive reason campo, en este caso, Interior > Exterior > Exterior via Interior. La redacción de este motivo muestra el orden de las preferencias aplicadas cuando se recibe la misma ruta de dos enrutadores. La ruta recibida desde un origen estrictamente interno (IGP) se prefiere primero, la ruta recibida de un origen externo (EBGP) es la siguiente y cualquier ruta que provenga de un origen externo y se reciba internamente (IBGP) se prefiere en último lugar. Por lo tanto, las rutas EBGP se seleccionan a través de rutas IBGP como la ruta activa.
Examinar la selección de costos de IGP
Propósito
Para examinar una ruta para determinar si ebGP está seleccionado a través de IBGP como los criterios de selección para la ruta única y activa.
Acción
Para examinar una ruta para determinar si EBGP se selecciona a través de IBGP como el criterio de selección para la ruta única y activa, escriba el siguiente comando del modo operativo de la CLI de Junos OS:
user@host> show route destination-prefix < detail >
Salida de muestra
nombre 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
El resultado de ejemplo muestra que R6 recibió dos instancias de la 100.100.4.0 ruta: uno de 10.0.0.4 (R4) y otro de 10.0.0.2 (R2). R6 se seleccionó la ruta desde R4 como su ruta activa, tal y como indica el asterisco (*). La selección se basa en la métrica IGP que se muestra en el Metric2 campo. Se prefiere la ruta con la métrica de IGP más baja. En el ejemplo, la ruta con el valor de métrica IGP más bajo es la ruta de R4, con un valor de métrica IGP de 10, mientras que la ruta de R2 tiene una métrica IGP de 20. Tenga en cuenta que las dos rutas son de la misma red vecina: AS 65001.
La razón por la que no se seleccionó la ruta inactiva se muestra en el Inactive reason campo, en este caso, IGP metric.
Lista de verificación para comprobar la capa del BGP
Problema
Descripción
Esta lista de verificación proporciona los pasos y comandos para comprobar la configuración del BGP de la red de conmutación de etiquetas multiprotocolo (MPLS). La lista de verificación proporciona vínculos a una descripción general de la configuración del BGP e información más detallada acerca de los comandos utilizados para configurar el BGP. (Ver Tabla 2.)
Solución
Tareas |
Comando o acción |
|---|---|
| Comprobar la capa del BGP | |
|
|
|
|
|
|
|
|
|
|
La siguiente secuencia de comandos aborda el problema específico descrito en este tema:
|
|
|
Comprobar la capa del BGP
Propósito
Después de configurar la ruta conmutada por etiquetas (LSP) y de determinar que está activa, y configurar el BGP y determinar que las sesiones están establecidas, asegúrese de que el BGP esté usando el LSP para reenviar tráfico.
Figura 3 ilustra la capa BGP del modelo MPLS por capas.
Cuando comprueba la capa BGP, verifica que la ruta está presente y activa, y lo que es más importante, se asegura de que el siguiente salto sea el LSP. No tiene sentido comprobar la capa del BGP a menos que se establezca el LSP, ya que el BGP usa el LSP MPLS para reenviar tráfico. Si la red no funciona en la capa BGP, el LSP no funciona como está configurado.
Figura 4 ilustra la red MPLS utilizada en este tema.
La red que se muestra en es una configuración completamente mallada en Figura 4 la que cada interfaz conectada directamente puede recibir y enviar paquetes a cualquier otra interfaz similar. El LSP de esta red está configurado para que se ejecute desde el enrutador de entrada, a través del enrutador R1de tránsito, al enrutador R3R6de salida. Además, un LSP inverso está configurado para ejecutarse desde R6 el a través R3 hasta R1, creando tráfico bidireccional.
La cruz que se muestra en Figura 4 indica dónde no se utiliza BGP para reenviar tráfico a través del LSP. Las posibles razones por las que el LSP no funciona correctamente son que la dirección IP de destino del LSP no es igual al siguiente salto del BGP o que el BGP no está configurado correctamente.
Para comprobar la capa BGP, siga estos pasos:
- Compruebe que el tráfico del BGP usa el LSP
- Comprobar sesiones de BGP
- Verificar la configuración del BGP
- Examinar rutas de BGP
- Verificar rutas BGP recibidas
- Tomar las medidas adecuadas para resolver el problema de la red
- Compruebe que el tráfico del BGP está usando el LSP de nuevo
Compruebe que el tráfico del BGP usa el LSP
Propósito
En este nivel del modelo de solución de problemas, el BGP y el LSP pueden estar funcionando, sin embargo, es posible que el tráfico del BGP no esté usando el LSP para reenviar tráfico.
Acción
Para comprobar que el tráfico del BGP utiliza el LSP, escriba el siguiente comando de modo operativo de interfaz de línea de comandos (CLI) de Junos OS desde el enrutador de entrada:
user@host> traceroute hostname
Salida de muestra
nombre 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
El resultado de ejemplo muestra que el tráfico del BGP no utiliza el LSP, por lo que las etiquetas MPLS no aparecen en la salida. En lugar de usar el LSP, el tráfico del BGP está usando el protocolo de puerta de enlace interior (IGP) para llegar a la dirección de salida de LSP del siguiente salto del BGP para R6 y R1. El valor predeterminado de Junos OS es usar LSP para el tráfico del BGP cuando el siguiente salto del BGP sea igual a la dirección de salida del LSP.
Comprobar sesiones de BGP
Propósito
Muestra información de resumen del BGP y sus vecinos para determinar si las rutas se reciben de los pares del sistema autónomo (AS). Cuando se establece una sesión de BGP, los pares intercambian mensajes de actualización.
Acción
Para comprobar que las sesiones de BGP estén activas, ingrese el siguiente comando de modo operativo de LA CLI de Junos OS desde el enrutador de entrada:
user@host> show bgp summary
Salida de muestra 1
nombre 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
Salida de muestra 2
nombre 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
La salida de ejemplo 1 muestra que un par (enrutador 10.0.0.6 de salida) no está establecido, como lo indica el Down Peers: 1 campo. La última columna (State|#Active/Received/Damped) muestra que el par 10.0.0.6 está activo, lo que indica que no está establecido. Todos los demás pares se establecen según lo indicado por el número de rutas activas, recibidas y atenuadas. Por ejemplo, 0/0/0 para par 10.0.0.2 indica que no había rutas BGP activas o recibidas en la tabla de enrutamiento y que ninguna ruta de BGP estaba atenuada; 1/1/0 para par 10.1.36.2 indica que una ruta de BGP estaba activa y recibida en la tabla de enrutamiento, y que ninguna ruta del BGP se comedió.
Si el resultado del show bgp summary comando de un enrutador de entrada muestra que un vecino está inactivo, compruebe la configuración del BGP. Para obtener más información sobre cómo comprobar la configuración del BGP, consulte Verificar la configuración del BGP.
La salida de muestra 2 muestra la salida del enrutador R1 de entrada después de que las configuraciones del BGP activadas R1 y R6 se corrigieron en Tomar medidas adecuadas para resolver el problema de la red. Se establecen todos los pares del BGP y una ruta está activa y recibida. No se mojaron rutas de BGP.
Si el resultado del show bgp summary comando muestra que un vecino está activo pero no se reenvían los paquetes, compruebe las rutas recibidas desde el enrutador de salida. Para obtener más información sobre cómo comprobar el enrutador de salida para las rutas recibidas, consulte Verificar rutas BGP recibidas.
Verificar la configuración del BGP
Propósito
Para que el BGP se ejecute en el enrutador, debe definir el número de AS local, configurar al menos un grupo e incluir información sobre al menos un par en el grupo (la dirección IP y el número de AS del par). Cuando el BGP forma parte de una red MPLS, debe asegurarse de que el LSP esté configurado con una dirección IP de destino igual al siguiente salto del BGP para que las rutas del BGP se instalen con el LSP como el siguiente salto para esas rutas.
Acción
Para comprobar la configuración del BGP, escriba el siguiente comando del modo operativo de la CLI de Junos OS:
user@host> show configuration
Salida de muestra 1
nombre 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;
}
}
}
Salida de muestra 2
nombre 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
El resultado de ejemplo muestra las configuraciones del BGP en el enrutador de entrada y el enrutador R1R6de salida. Ambas configuraciones muestran el AS local (65432), un grupo (internal) y seis pares configurados. El protocolo de puerta de enlace interior subyacente es IS-IS, y las interfaces pertinentes están configuradas para ejecutar IS-IS.
En esta configuración, el RID se configura manualmente para evitar cualquier problema de RID duplicado, y todas las interfaces configuradas con BGP incluyen la family inet instrucción en el nivel de jerarquía [edit interfaces type-fpc/pic/port unit logical-unit-number].
La salida de ejemplo para el enrutador R1 de entrada y el enrutador R6 de salida muestra que la configuración del protocolo BGP no se encuentra en la local-address instrucción para el grupo interno. Cuando se configura la local-address instrucción, los paquetes BGP se reenvían desde la dirección de interfaz de circuito cerrado (lo0) del enrutador local, que es la dirección a la que se emparejan los pares del BGP. Si la local-address instrucción no está configurada, los paquetes del BGP se reenvían desde la dirección de la interfaz de salida, que no coincide con la dirección a la que se emparejan los pares del BGP, y el BGP no aparece.
En el enrutador de entrada, la dirección IP (10.0.0.1) de la local-address instrucción debe ser la misma que la dirección configurada para el LSP en el enrutador de salida (R6) en la to instrucción en el nivel de jerarquía [edit protocols mpls label-switched-path lsp-path-name]. El BGP usa esta dirección, que es idéntica a la dirección LSP, para reenviar el tráfico del BGP a través del LSP.
Además, la configuración R1 del BGP incluye dos direcciones IP para R6, una dirección de interfaz (10.1.36.2) y una dirección de interfaz de circuito cerrado (lo0) (10.0.0.6), lo que da como resultado que la dirección de destino del LSP (10.0.0.6) no coincida con la dirección del salto siguiente del BGP (10.1.36.2). La configuración R6 del BGP también incluye dos direcciones IP para R1, una dirección de interfaz (10.1.13.1) y una dirección de interfaz de circuito cerrado (lo0), lo que da como resultado que la dirección de destino LSP inversa (10.0.0.1) no coincida con la dirección del siguiente salto del BGP (10.1.13.1).
En este caso, dado que la local-address instrucción no está en las configuraciones del BGP de ambos enrutadores y la dirección de destino del LSP no coincide con la dirección del salto siguiente del BGP, el BGP no utiliza el LSP para reenviar tráfico.
Examinar rutas de BGP
Propósito
Puede examinar el proceso de selección de ruta del BGP para determinar la ruta única y activa cuando el BGP recibe varias rutas al mismo destino. En este paso, examinamos el LSP R6-to-R1inverso, que hace R6 que el enrutador de entrada para ese LSP.
Acción
Para examinar las rutas del BGP y la selección de rutas, escriba el siguiente comando de modo operativo de CLI de Junos OS:
user@host> show route destination-prefix detail
Salida de muestra 1
nombre 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
Salida de muestra 2
nombre 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
La salida de ejemplo 1 muestra que el salto siguiente del BGP (10.1.13.1) no es igual a la dirección de destino del LSP (10.0.0.1) en la to instrucción en el nivel de jerarquía [edit protocols mpls label-switched-path label-switched-path-name] cuando la configuración del BGP de R6 y R1 es incorrecta.
La salida de muestra 2, tomada después de que se corrijan las configuraciones de R1 y R6, muestra que el siguiente salto del BGP (10.0.0.1) y la dirección de destino del LSP (10.0.0.1) son los mismos, lo que indica que el BGP puede usar el LSP para reenviar tráfico del BGP.
Verificar rutas BGP recibidas
Propósito
Muestra la información de enrutamiento recibida en el enrutador R6, el enrutador de entrada para el LSP R6-to-R1inverso.
Acción
Para comprobar que se recibe una ruta BGP en particular en el enrutador de salida, escriba el siguiente comando de modo operativo de la CLI de Junos OS:
user@host> show route receive protocol bgp neighbor-address
Salida de muestra 1
nombre 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)
Salida de muestra 2
nombre 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
La salida de ejemplo 1 muestra que el enrutador R6 de entrada (LSP R6-to-R1inverso) no recibe ninguna ruta BGP en la inet.0 tabla de enrutamiento cuando las configuraciones del BGP de R1 y R6 son incorrectas.
La salida de ejemplo 2 muestra una ruta BGP instalada en la inet.0 tabla de enrutamiento después de que las configuraciones del BGP estén R1 activadas y R6 se corrijan mediante tomar medidas adecuadas para resolver el problema de red.
Tomar las medidas adecuadas para resolver el problema de la red
Problema
Descripción
La acción adecuada depende del tipo de problema que haya aislado. En este ejemplo, una ruta estática configurada R2 en se elimina del nivel de jerarquía [routing-options]. Otras acciones adecuadas pueden incluir las siguientes:
Solución
Compruebe la configuración del enrutador local y edítala si corresponde.
Solucionar problemas del enrutador intermedio.
Compruebe la configuración del host remoto y edítala si corresponde.
Solucionar problemas de protocolos de enrutamiento.
Identifique otras causas posibles.
Para resolver el problema en este ejemplo, escriba los siguientes comandos de CLI de Junos OS:
[edit]
user@R2# delete routing-options static route destination-prefix
user@R2# commit and-quit
user@R2# show route destination-prefix
Salida de muestra
[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
El resultado de ejemplo muestra la ruta estática eliminada de la jerarquía [routing-options] y la nueva configuración confirmada. El resultado del show route comando ahora muestra la ruta del BGP como la ruta preferida, como indica el asterisco (*).
Compruebe que el tráfico del BGP está usando el LSP de nuevo
Propósito
Después de tomar las medidas adecuadas para corregir el error, debe comprobarse de nuevo el LSP para confirmar que el tráfico del BGP utiliza el LSP y que el problema en la capa BGP se ha resuelto.
Acción
Para comprobar que el tráfico del BGP usa el LSP, escriba el siguiente comando de modo operativo de la CLI de Junos OS desde el enrutador de entrada:
user@host> traceroute hostname
Salida de muestra
nombre 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
El resultado de ejemplo muestra que las etiquetas MPLS se utilizan para reenviar paquetes a través del LSP. En el resultado se incluye un valor de etiqueta (MPLS Label=100016), el valor de tiempo de vida (TTL=1) y el valor de bit de pila (S=1).
El MPLS Label campo se utiliza para identificar el paquete de un LSP determinado. Es un campo de 20 bits, con un valor máximo de (2^^20-1), aproximadamente 1.000.000.
El valor de tiempo de vida (TTL) contiene un límite en la cantidad de saltos que este paquete MPLS puede viajar a través de la red (1). Se decrementa en cada salto, y si el valor TTL cae por debajo de uno, el paquete se descarta.
La parte inferior del valor de bit de pila (S=1) indica que es la última etiqueta de la pila y que este paquete MPLS tiene una etiqueta asociada. La implementación de MPLS en Junos OS admite una profundidad de apilamiento de 3 en los enrutadores de la serie M y hasta 5 en las plataformas de enrutamiento de la serie T. Para obtener más información sobre el apilamiento de etiquetas MPLS, consulte RFC 3032, Codificación de pila de etiquetas MPLS.
Las etiquetas MPLS aparecen en la salida de muestra porque el traceroute comando se emite a un destino BGP donde el siguiente salto del BGP para esa ruta es la dirección de salida del LSP. Junos OS de forma predeterminada usa LSP para el tráfico del BGP cuando el siguiente salto del BGP es igual a la dirección de salida del LSP.
Si el salto siguiente del BGP no es igual a la dirección de salida de la LSP, el tráfico del BGP no utiliza el LSP y, en consecuencia, las etiquetas MPLS no aparecen en la salida del traceroute comando, como se indica en la salida de muestra en Check BGP Session.
Mostrar paquetes BGP enviados o recibidos
Acción
Para configurar el seguimiento de los paquetes de protocolo BGP enviados o recibidos, siga estos pasos:
En el modo de configuración, vaya al siguiente nivel de jerarquía:
[edit] user@host# edit protocol bgp traceoptions
Configure la marca para mostrar la información de paquetes enviados, recibidos o ambos enviados y recibidos:
[edit protocols bgp traceoptions] user@host# set flag update sendo de
[edit protocols bgp traceoptions] user@host# set flag update receive
o de
[edit protocols bgp traceoptions] user@host# set flag update
Compruebe la configuración:
user@host# show
Por ejemplo:
[edit protocols bgp traceoptions] user@host# show file bgplog size 10k files 10; flag update send;
o de
[edit protocols bgp traceoptions] user@host# show file bgplog size 10k files 10; flag update receive;
o de
[edit protocols bgp traceoptions] user@host# show file bgplog size 10k files 10; flag update send receive;
Confirme la configuración:
user@host# commit
Vea el contenido del archivo que contiene los mensajes detallados:
user@host# run show log filenamePor ejemplo:
[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 rutas en la tabla de reenvío
Propósito
Cuando se encuentra con problemas, como problemas de conectividad, es posible que deba examinar las rutas en la tabla de reenvío para comprobar que el proceso de protocolo de enrutamiento ha transmitido la información correcta a la tabla de reenvío.
Acción
Para mostrar el conjunto de rutas instaladas en la tabla de reenvío, escriba el siguiente comando del modo operativo de la CLI de Junos OS:
user@host> show route forwarding-table
Salida de muestra
nombre 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
El resultado de ejemplo muestra los prefijos de capa de red y sus próximos saltos instalados en la tabla de reenvío. El resultado incluye la misma información del siguiente salto que en el show route detail comando (la dirección del salto siguiente y el nombre de interfaz). La información adicional incluye el tipo de destino, el tipo de salto siguiente, el número de referencias a este salto siguiente y un índice en una base de datos interna de salto siguiente. (La base de datos interna contiene información adicional utilizada por el motor de reenvío de paquetes para garantizar la encapsulación adecuada de los paquetes enviados a una interfaz. El usuario no puede acceder a esta base de datos.
Para obtener información detallada acerca de los significados de los distintos campos de indicadores y tipos, consulte la Guía del usuario de políticas de enrutamiento, filtros de firewall y policías de tráfico.
Ejemplo: Anular la política de enrutamiento predeterminada del BGP en enrutadores de transporte de paquetes serie PTX
En este ejemplo, se muestra cómo reemplazar la política de enrutamiento predeterminada en enrutadores de transporte de paquetes, como los enrutadores de transporte de paquetes serie PTX.
Requisitos
En este ejemplo, se requiere la versión 12.1 o posterior de Junos OS.
Descripción general
De forma predeterminada, los enrutadores de la serie PTX no instalan rutas BGP en la tabla de reenvío.
En el caso de los enrutadores serie PTX, la configuración de la from protocols bgp condición con la then accept acción no tiene el resultado habitual que tiene en otros dispositivos de enrutamiento Junos OS. Con la siguiente política de enrutamiento en enrutadores serie PTX, las rutas del BGP no se instalan en la tabla de reenvío.
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
No se instalan rutas BGP en la tabla de reenvío. Este es el comportamiento esperado.
En este ejemplo, se muestra cómo usar la then install-to-fib acción para invalidar efectivamente la política de enrutamiento predeterminada del BGP.
Configuración
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, luego, copie y pegue los comandos en la CLI en el [edit] nivel de jerarquía.
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
Instalación de rutas BGP seleccionadas en la tabla de reenvío
Procedimiento paso a paso
El siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en el modo de configuración en la Guía del usuario de la CLI de Junos OS.
Para instalar rutas de BGP seleccionadas en la tabla de reenvío:
Configure una lista de prefijos para instalar en la tabla de reenvío.
[edit policy-options prefix-list install-bgp] user@host# set 66.0.0.1/32
Configure la política de enrutamiento y aplique la lista de prefijos como una condición.
[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 la política de enrutamiento a la tabla de reenvío.
[edit routing-options forwarding-table] user@host# set export override-ptx-series-default
Resultados
Desde el modo de configuración, ingrese los comandos y show routing-options para confirmar la show policy-options configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.
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;
}
Si ha terminado de configurar el dispositivo, ingrese commit desde el modo de configuración.
Verificación
Confirme que la configuración funciona correctamente.
Comprobar que la ruta seleccionada está instalada en la tabla de reenvío
Propósito
Asegúrese de que la política configurada reemplaza a la política predeterminada.
Acción
Desde el modo operativo, ingrese el 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
Este resultado muestra que la ruta a 66.0.0.1/32 está instalada en la tabla de reenvío.
Registrar eventos de transición de estado del BGP
Propósito
Las transiciones de estado del Protocolo de puerta de enlace de borde (BGP) indican un problema de red y deben registrarse e investigarse.
Acción
Para registrar los eventos de transición de estado del BGP al registro del sistema, siga estos pasos:
En el modo de configuración, vaya al siguiente nivel de jerarquía:
[edit] user@host# edit protocol bgpConfigure el registro del sistema:
user@host# set log-updown
Compruebe la configuración:
user@host# show
Confirme la configuración:
user@host# commit
Significado
Los mensajes de registro de los eventos de transición de estado del BGP son suficientes para diagnosticar la mayoría de los problemas de la sesión del BGP. Tabla 3 enumera y describe los seis estados de una sesión de BGP.
Estado del BGP |
Descripción |
|---|---|
Idle |
Este es el primer estado de una conexión. El BGP espera un evento de inicio iniciado por un administrador. El evento de inicio puede ser el establecimiento de una sesión de BGP mediante la configuración del enrutador o el restablecimiento de una sesión existente. Después del evento start, BGP inicializa sus recursos, restablece un temporizador de conexión de reintentos, inicia una conexión de transporte TCP y comienza a escuchar las conexiones iniciadas por pares remotos. Luego, el BGP pasa a un Connect estado. Si hay errores, el BGP vuelve al Idle estado. |
Connect |
El BGP espera a que se complete la conexión del protocolo de transporte. Si la conexión de transporte TCP es correcta, el estado pasa a OpenSent. Si la conexión de transporte no es correcta, el estado pasa a Active. Si el temporizador de conexión de reintentos ha caducado, el estado permanece en el Connect estado, el temporizador se restablece y se inicia una conexión de transporte. Con cualquier otro evento, el estado vuelve a Idle. |
Active |
El BGP intenta adquirir un par iniciando una conexión de protocolo de transporte. Si se realiza correctamente, el estado pasa a OpenSent. Si caduca el temporizador de reintentos de conexión, el BGP reinicia el temporizador de conexión y vuelve al Connect estado. El BGP sigue escuchando una conexión que puede iniciarse desde otro par. El estado puede volver al Idle caso de otros eventos, como un evento de parada. En general, un estado vecino flip-flopping entre Connect y Active es una indicación de que hay un problema con la conexión de transporte TCP. Tal problema puede deberse a muchas retransmisiones TCP o a la incapacidad de un vecino para llegar a la dirección IP de su par. |
OpenSent |
El BGP recibe un mensaje abierto de su par. En el estado, el OpenSent BGP compara su número de sistema autónomo (AS) con el número as de su par y reconoce si el par pertenece al mismo AS (BGP interno) o a un AS diferente (BGP externo). El mensaje abierto está comprobado para que sea correcto. En caso de errores, como un número de versión malo de un AS inaceptable, el BGP envía un mensaje de notificación de error y vuelve a Idle. Para cualquier otro error, como la expiración del temporizador de espera o un evento de detención, el BGP envía un mensaje de notificación con el código de error correspondiente y vuelve al Idle estado. Si no hay errores, BGP envía mensajes de keepalive y restablece el temporizador de keepalive. En este estado, se negocia el tiempo de espera. Si el tiempo de espera es 0, los temporizadores de espera y mantener no se reinician. Cuando se detecta una desconexión de transporte TCP, el estado vuelve a .Active |
OpenConfirm |
El BGP espera un mensaje de mantención o notificación. Si se recibe una conservación, el estado se convierte en Established, y la negociación de vecino se completa. Si el sistema recibe un mensaje de actualización o de mantención, reinicia el temporizador de espera (suponiendo que el tiempo de espera negociado no es 0). Si se recibe un mensaje de notificación, el estado vuelve a Idle. El sistema envía mensajes periódicos de mantenimiento a la velocidad establecida por el temporizador de mantenimiento. En caso de una notificación de desconexión de transporte o en respuesta a un evento de detención, el estado vuelve a. Idle En respuesta a otros eventos, el sistema envía un mensaje de notificación con un código de error de máquina de estado finito (FSM) y vuelve a Idle. |
Established |
Este es el estado final en la negociación de vecinos. En este estado, los intercambios del BGP actualizan los ackets con sus pares y el temporizador de espera se reinicia al recibir una actualización o mensaje de keepalive cuando no está establecido en cero. Si el sistema recibe un mensaje de notificación, el estado vuelve a .Idle Los mensajes de actualización se comprueban en busca de errores, como atributos faltantes, atributos duplicados, etc. Si se encuentran errores, se envía una notificación al par y el estado vuelve a .Idle El BGP vuelve a Idle cuando caduca el temporizador de espera, se recibe una notificación de desconexión del protocolo de transporte, se recibe un evento de parada o en respuesta a cualquier otro evento. |
Para obtener información más detallada de paquetes de protocolo BGP, configure el rastreo específico del BGP. Consulte la lista de verificación para encontrar condiciones de error de seguimiento para obtener más información.
Configurar opciones específicas del BGP
Propósito
Cuando se producen eventos o problemas inesperados, o si desea diagnosticar problemas de establecimiento del BGP, puede ver información más detallada configurando las opciones específicas del BGP. También puede configurar el seguimiento para un par o grupo de pares de BGP específicos. Para obtener más información, consulte la Guía de configuración básica de Junos System.
- Mostrar información detallada del protocolo BGP
- Diagnosticar problemas de establecimiento de sesión de BGP
Mostrar información detallada del protocolo BGP
Acción
Para mostrar la información del protocolo BGP en detalle, siga estos pasos:
En el modo de configuración, vaya al siguiente nivel de jerarquía:
[edit] user@host# edit protocol bgp traceoptions
Configure la marca para que muestre mensajes de protocolo BGP detallados:
[edit protocols bgp traceoptions] user@host# set flag update detail
Compruebe la configuración:
user@host# show
Por ejemplo:
[edit protocols bgp traceoptions] user@host# show flag update detail;
Confirme la configuración:
user@host# commit
Vea el contenido del archivo que contiene los mensajes detallados:
user@host# run show log filenamePor ejemplo:
[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
Tabla 4 enumera los indicadores de seguimiento específicos del BGP y presenta un resultado de ejemplo para algunos de los indicadores. También puede configurar el seguimiento para un par o grupo de pares de BGP específicos. Para obtener más información, consulte la Guía de configuración básica de Junos System.
Indicadores de rastreo |
Descripción |
Salida de ejemplo |
|---|---|---|
aspath |
Operaciones de expresión regular de ruta del AS |
No disponible. |
damping |
Operaciones de atenuación |
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 |
Mensajes de mantener 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 |
Paquetes abiertos del 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 los paquetes 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 |
Actualizar paquetes |
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 establecimiento de sesión de BGP
Propósito
Para rastrear problemas de establecimiento de sesión del BGP.
Acción
Para rastrear los problemas de establecimiento de sesión del BGP, siga estos pasos:
En el modo de configuración, vaya al siguiente nivel de jerarquía:
[edit] user@host# edit protocol bgpConfigurar mensajes abiertos del BGP:
[edit protocols bgp] user@host# set traceoptions flag open detail
Compruebe la configuración:
user@host# show
Por ejemplo:
[edit protocols bgp] user@host# show traceoptions { file bgplog size 10k files 10; flag open detail; }Confirme la configuración:
user@host# commit
Vea el contenido del archivo que contiene los mensajes detallados:
user@host#run show log filenamePor ejemplo:
[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 opciones específicas de IS-IS
Propósito
Cuando se producen eventos o problemas inesperados, o si desea diagnosticar problemas de establecimiento de adyacencia IS-IS, puede ver información más detallada configurando las opciones específicas de IS-IS.
Para configurar las opciones de IS-IS, siga estos pasos:
- Mostrar información detallada del protocolo IS-IS
- Mostrar paquetes de protocolo IS-IS enviados o recibidos
- Analizar las PDU de vínculo-estado DE IS-IS en detalle
Mostrar información detallada del protocolo IS-IS
Acción
Para rastrear los mensajes de IS-IS en detalle, siga estos pasos:
Configure la marca para que muestre mensajes de protocolo IS-IS detallados.
[edit protocols isis traceoptions] user@host# set flag hello detail
Compruebe la configuración.
user@host# show
Por ejemplo:
[edit protocols isis traceoptions] user@host# show file isislog size 10k files 10; flag hello detail;
Confirme la configuración.
user@host# commit
Vea el contenido del archivo que contiene los mensajes detallados.
user@host# run show log filenamePor ejemplo:
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
Tabla 5 enumera los indicadores de seguimiento que se pueden configurar específicos de IS-IS y muestra el resultado de ejemplo para algunos de los indicadores.
Indicadores de rastreo |
Descripción |
Salida de ejemplo |
|---|---|---|
csn |
Número de secuencia completo PDU (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 Con la detail opción. 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 |
Hola paquete |
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 |
PDU de estado de vínculo (LSP) |
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 |
Paquetes de generación de PDU de estado de vínculo |
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 los paquetes de protocolo IS-IS |
No disponible. |
psn |
Paquetes PDU (PSNP) de número de secuencia parcial |
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 ruta más corta (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 también
Mostrar paquetes de protocolo IS-IS enviados o recibidos
Para configurar el seguimiento para solo los paquetes de protocolo IS-IS enviados o recibidos, siga estos pasos:
Configure la marca para mostrar los paquetes enviados, recibidos o ambos enviados y recibidos.
[edit protocols isis traceoptions] user@host# set flag hello send
o de
[edit protocols isis traceoptions] user@host# set flag hello receive
o de
[edit protocols isis traceoptions] user@host# set flag hello
Compruebe la configuración.
user@host# show
Por ejemplo:
[edit protocols isis traceoptions] user@host# show file isislog size 10k files 10; flag hello send;
o de
[edit protocols isis traceoptions] user@host# show file isislog size 10k files 10; flag hello receive;
o de
[edit protocols isis traceoptions] user@host# show file isislog size 10k files 10; flag hello send receive;
Confirme la configuración.
user@host# commit
Vea el contenido del archivo que contiene los mensajes detallados.
user@host# run show log filenamePor ejemplo:
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 también
Analizar las PDU de vínculo-estado DE IS-IS en detalle
Para analizar las PDU de estado de vínculo IS-IS en detalle, siga estos pasos:
Configure los mensajes abiertos IS-IS.
[edit protocols isis traceoptions] user@host# set flag lsp detail
Compruebe la configuración.
user@host# show
Por ejemplo:
[edit protocols isis traceoptions] user@host# show file isislog size 5m world-readable; flag error; flag lsp detail;
Confirme la configuración.
user@host# commit
Vea el contenido del archivo que contiene los mensajes detallados.
user@host# run show log filenamePor ejemplo:
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 también
Configurar opciones específicas de OSPF
Propósito
Cuando ocurren eventos o problemas inesperados, o si desea diagnosticar problemas de establecimiento de vecinos de OSPF, puede ver información más detallada configurando las opciones específicas de OSPF.
Para configurar las opciones de OSPF, siga estos pasos:
- Diagnóstico de problemas de establecimiento de sesión de OSPF
- Analice los paquetes de anuncios de estado de vínculo de OSPF en detalle
Diagnóstico de problemas de establecimiento de sesión de OSPF
Acción
Para rastrear los mensajes de OSPF en detalle, siga estos pasos:
En el modo de configuración, vaya al siguiente nivel de jerarquía:
[edit] user@host# edit protocols ospf traceoptions
Configure los mensajes de saludo de OSPF:
[edit protocols ospf traceoptions] user@host# set flag hello detail
Compruebe la configuración:
user@host# show
Por ejemplo:
[edit protocols ospf traceoptions] user@host# show file ospf size 5m world-readable; flag hello detail;
Confirme la configuración:
user@host# commit
Vea el contenido del archivo que contiene los mensajes detallados:
user@host# run show log filenamePor ejemplo:
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
Tabla 6 enumera las marcas de seguimiento de OSPF y presenta un resultado de ejemplo para algunos de los indicadores.
Indicadores de rastreo |
Descripción |
Salida de ejemplo |
|---|---|---|
database-descripttion |
Todos los paquetes de descripción de la base de datos |
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 |
Paquetes con errores 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 |
Transiciones de estado de 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 |
Paquetes inundados de estado de vínculo |
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 |
Paquetes de hola |
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 |
Paquetes de confirmación de estado de vínculo |
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 a 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 |
Paquetes de solicitud de estado de vínculo |
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 |
Paquetes de actualización de estado de vínculo |
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 los paquetes OSPF |
No disponible. |
packet-dump |
Volcar el contenido de los tipos de paquetes seleccionados |
No disponible. |
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 |
Analice los paquetes de anuncios de estado de vínculo de OSPF en detalle
Acción
Para analizar los paquetes de anuncios de estado de vínculo OSPF en detalle, siga estos pasos:
En el modo de configuración, vaya al siguiente nivel de jerarquía:
[edit] user@host# edit protocols ospf traceoptions
Configure paquetes de estado de vínculo OSPF:
[edit protocols ospf traceoptions] user@host# set flag lsa-update detail
Compruebe la configuración:
user@host# show
Por ejemplo:
[edit protocols ospf traceoptions] user@host# show file ospf size 5m world-readable; flag hello detail; flag lsa-update detail;
Confirme la configuración:
user@host# commit
Vea el contenido del archivo que contiene los mensajes detallados:
user@host# run show log filenamePor ejemplo:
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