- play_arrow Descripción general
- play_arrow Configuraciones básicas de BGP
- play_arrow Configuración de atributos de sesión BGP
- play_arrow Configuración de directivas de sesión BGP
- play_arrow Habilitación del equilibrio de carga para BGP
- play_arrow Configuración de un reinicio correcto para BGP
- play_arrow Configuración de multiprotocolo para una sesión BGP
- play_arrow Configuración de BGP CLNS
- play_arrow Uso de reflectores de ruta y confederaciones para redes BGP
- play_arrow Configuración de la seguridad BGP
- play_arrow Configuración de la amortiguación de aletas de ruta BGP y el manejo de errores
- play_arrow Configuración de VPN basada en BGP
- play_arrow Instrucciones de configuración y comandos operativos
Resolución de problemas de sesiones BGP
Lista de comprobación para verificar el protocolo BGP y los pares
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, si las sesiones de Protocolo de puerta de enlace de borde interno (IBGP) y si las sesiones de Protocolo de puerta de enlace de borde exterior (EBGP) están correctamente establecidas, si las rutas externas se anuncian y reciben correctamente, y si el proceso de selección de ruta de BGP funciona correctamente.
Acción
Tareas | Comando o acción |
|---|---|
| Verificar pares BGP | |
| |
| |
| |
| |
| Examinar rutas BGP y selección de rutas | |
| |
| |
| |
| |
| Examinar rutas en la tabla de reenvío |
|
Verificar pares BGP
Propósito
Suponiendo que todos los enrutadores están configurados correctamente para BGP, puede verificar si las sesiones de IBGP y EBGP están correctamente establecidas, si las rutas externas se anuncian y reciben correctamente, y si el proceso de selección de ruta de BGP funciona correctamente.
Figura 1 muestra un ejemplo de topología de red BGP usada en este tema.
La red consta de dos AS conectados directamente y formados por pares externos e internos. Los pares externos están conectados 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 de IBGP. AS 65001 ejecuta OSPF y 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 comuniquen entre sí.
Los dos enrutadores del AS 65001 contienen cada uno un vínculo EBGP al AS 65002 (R2 y R4) sobre el que anuncian prefijos agregados: 100.100.1.0, 100.100.2.0, 100.100.3.0, y 100.100.4.0. Además, R1 y R5 están inyectando valores de discriminador de salida múltiple (MED) de 5 y 10, respectivamente, para algunas rutas.
Los enrutadores internos de ambos AS usan una topología de 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 de IBGP no se distribuyen a otros vecinos internos. Por ejemplo, cuando R3 aprende una ruta de , R3 no distribuye esa ruta a R6 porque la ruta se aprende a través de R2IBGP, por lo que R6 debe tener una conexión BGP directa a R2 para aprender la ruta.
En una topología de malla completa, solo el enrutador de borde que recibe información externa de 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, deberían realizarse 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 comprobar los pares BGP, siga estos pasos:
- Verificar BGP en un enrutador interno
- Verificar BGP en un enrutador de borde
- Verificar las rutas BGP anunciadas
- Verifique que se reciba una ruta BGP en particular en su enrutador
Verificar BGP en un enrutador interno
Propósito
Para comprobar la configuración BGP de un enrutador interno.
Acción
Para comprobar la configuración BGP de un enrutador interno, escriba el siguiente comando de interfaz de línea de comandos (CLI) de Junos OS:
user@host> show configuration
La siguiente salida de ejemplo es para una configuración BGP en R3:
Salida de muestra
nombre-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 básica de BGP en enrutadores R3 y R6. El AS local (65002) y un grupo (internal) están configurados en ambos enrutadores. R3 tiene tres pares internos—10.0.0.2, 10.0.0.4y 10.0.0.6—incluidos en el nivel R6 de jerarquía [protocols bgp groupgroup]. también tiene tres pares internos: 10.0.0.2, 10.0.0.3, y 10.0.0.4. El protocolo IGP subyacente es Sistema intermedio a sistema intermedio (IS-IS) y las interfaces relevantes están configuradas para ejecutar IS-IS.
Tenga en cuenta que en esta configuración, el ID del enrutador se configura manualmente para evitar problemas de ID de enrutador duplicado.
Verificar BGP en un enrutador de borde
Propósito
Para comprobar la configuración BGP de un enrutador de borde.
Acción
Para comprobar la configuración BGP de un enrutador de borde, introduzca el siguiente comando de modo operativo de la CLI de Junos OS:
user@host> show configuration
Salida de muestra
nombre-comando
El siguiente resultado 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 básica de BGP 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, dependiendo del 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 próximo salto del BGP.
Verificar las rutas BGP anunciadas
Propósito
Puede determinar si una ruta concreta que ha configurado se anuncia a un vecino.
Acción
Para verificar la información de enrutamiento tal como se ha preparado para anunciarla en el vecino de 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-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
La salida de ejemplo muestra las rutas BGP anunciadas desde R2 a su vecino, 10.0.0.4 (R4). Del total de 22 rutas en la inet.0 tabla de enrutamiento, 20 son destinos activos. No hay rutas ni hidden en el hold-down estado. Las rutas residen en el estado antes de hold-down 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 su enrutador
Propósito
Muestre la información de enrutamiento tal como se recibe a través de un vecino BGP en particular y que el enrutador local anuncia al vecino.
Acción
Para comprobar que se recibe una ruta BGP concreta en el enrutador, introduzca 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-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 BGP desde R2 y dos desde R4. De las cuatro rutas de R2, sólo dos están activas en la tabla de enrutamiento, como indica el asterisco (*), mientras que las dos rutas recibidas de están activas en la tabla de R4 enrutamiento. Todas las rutas de BGP llegaron a través de AS 65001.
Examinar rutas BGP y selección de rutas
Propósito
Puede examinar el proceso de selección de ruta de BGP para determinar la ruta única y activa cuando BGP recibe varias rutas al mismo prefijo de destino.
La red en Figura 2 muestra que R1 y R5 anuncia las mismas rutas agregadas hacia y R4, que da como R2 resultado R2 y R4 recibe dos rutas al mismo prefijo de destino. El proceso de selección de ruta en R2 y R4 determina cuál de las dos rutas BGP recibidas está activa y se anuncia 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 es accesible. Si no se puede resolver el próximo salto del BGP, 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 de BGP se desarrolla en el orden siguiente:
Se compara la preferencia de ruta en la tabla de enrutamiento. Por ejemplo, si existen una ruta OSPF y BGP para un destino determinado, la ruta OSPF se selecciona como ruta activa porque la ruta OSPF tiene una preferencia predeterminada de 110, mientras que la ruta BGP tiene una preferencia predeterminada de 170.
Las rutas se comparan según 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 alguna 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 del discriminador de salida múltiple.
La ruta se evalúa en cuanto a si se aprende a través de EBGP o IBGP. Las rutas aprendidas del EBGP son preferibles a las rutas aprendidas del IBGP. Para obtener un ejemplo, consulte Examinar la selección de EBGP sobre IBGP
Si la ruta se aprende de IBGP, se prefiere la ruta con el costo IGP más bajo. Para obtener un ejemplo, consulte Examinar la selección de costos de IGP. El siguiente salto físico al par IBGP se instala de acuerdo con las tres reglas siguientes:
Después de que BGP examine las tablas y
inet.3deinet.0enrutamiento, se utiliza el siguiente salto físico de la ruta con la preferencia más baja.
Si los valores de preferencia de las tablas de
inet.0enrutamiento yinet.3son un empate, se utiliza el siguiente salto físico 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 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 (generalmente la dirección de circuito cerrado).
Se examina el valor de la dirección del mismo nivel. Se prefiere el par con la dirección IP del par más baja.
Para determinar la ruta única y activa cuando 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 el motivo de inactividad que se muestra cuando BGP recibe varias rutas al mismo prefijo de destino y se selecciona una ruta como ruta única activa:
- Examinar la selección de preferencias locales
- Examinar la selección de ruta del discriminador de salida múltiple
- Examine la selección de EBGP sobre IBGP
- Examine la selección de costos del 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 para la ruta única y activa.
Acción
Para examinar una ruta y determinar si la preferencia local es el criterio de selección para la ruta única activa, introduzca el siguiente comando del modo operativo de la CLI de Junos OS:
user@host> show route destination-prefix < detail >
Salida de muestra
nombre-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 de 10.0.0.2 (R2) y uno de 10.1.45.2 (R5). R4 seleccionaron la ruta desde R2 como su ruta activa, 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 no se selecciona la ruta desde R5 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 del discriminador de salida múltiple
Propósito
Examinar una ruta para determinar si el MED es el criterio de selección para la ruta única y activa.
Acción
Para examinar una ruta y determinar si el MED es el criterio de selección para la ruta única activa, introduzca el siguiente comando del modo operativo de la CLI de Junos OS:
user@host> show route destination-prefix < detail >
Salida de muestra
nombre-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 uno de 10.1.45.2 (R5). R4 seleccionaron la ruta desde R2 como su ruta activa, como lo 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 desde 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 determinista de MED de forma predeterminada.
Examine la selección de EBGP sobre IBGP
Propósito
Examinar una ruta para determinar si se selecciona EBGP sobre IBGP como criterio de selección para la ruta única activa.
Acción
Para examinar una ruta y determinar si se selecciona EBGP sobre IBGP como criterio de selección para la ruta única activa, escriba el siguiente comando de modo operativo de la CLI de Junos OS:
user@host> show route destination-prefix < detail >
Salida de muestra
nombre-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 de 10.1.45.2 (R5) y uno de 10.0.0.2 (R2). R4 seleccionaron la ruta desde R5 como su ruta activa, 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 acceso de un par EBGP o IBGP examinando los Local As campos y Peer As . Por ejemplo, la ruta desde muestra que el AS local es 65002 y el AS par es 65001, lo que indica que la ruta se recibe de R5 un par EBGP. La ruta desde R2 muestra que tanto el AS local como el 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 esta razón muestra el orden de preferencias aplicadas cuando se recibe la misma ruta de dos enrutadores. La ruta recibida de una fuente estrictamente interna (IGP) se prefiere primero, la ruta recibida de una fuente externa (EBGP) se prefiere a continuación, y cualquier ruta que provenga de una fuente externa y se reciba internamente (IBGP) se prefiere al final. Por lo tanto, las rutas EBGP se seleccionan sobre las rutas IBGP como la ruta activa.
Examine la selección de costos del IGP
Propósito
Examinar una ruta para determinar si se selecciona EBGP sobre IBGP como criterio de selección para la ruta única activa.
Acción
Para examinar una ruta y determinar si se selecciona EBGP sobre IBGP como criterio de selección para la ruta única activa, escriba el siguiente comando de modo operativo de la CLI de Junos OS:
user@host> show route destination-prefix < detail >
Salida de muestra
nombre-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 uno de 10.0.0.2 (R2). R6 seleccionaron la ruta desde R4 como su ruta activa, como lo 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 IGP más baja. En el ejemplo, la ruta con el valor de métrica de IGP más bajo es la ruta de R4, con un valor de métrica de IGP de 10, mientras que la ruta de tiene una métrica de R2 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 comprobación para comprobar la capa BGP
Problema
Description
Esta lista de comprobación proporciona los pasos y comandos para comprobar la configuración BGP de la red de conmutación de etiquetas multiprotocolo (MPLS). La lista de comprobación proporciona vínculos a una descripción general de la configuración del BGP e información más detallada sobre los comandos utilizados para configurar el BGP. (Consulte Tabla 2.)
Solución
Tareas | Comando o acción |
|---|---|
| Comprobación de la capa BGP | |
| |
| |
| |
| |
| |
La siguiente secuencia de comandos resuelve el problema específico descrito en este tema:
| |
|
Comprobación de la capa BGP
Propósito
Después de configurar la ruta de conmutación de etiquetas (LSP) y de determinar que está activa, de configurar el BGP y de determinar que se han establecido sesiones, asegúrese de que el BGP utiliza el LSP para reenviar el tráfico.
Figura 3 ilustra la capa BGP del modelo MPLS en capas.
Cuando se comprueba la capa BGP, se comprueba 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 BGP a menos que se establezca el LSP, porque BGP utiliza el LSP MPLS para reenviar el tráfico. Si la red no funciona en la capa BGP, el LSP no funciona según lo configurado.
Figura 4 ilustra la red MPLS utilizada en este tema.
La red que se muestra en Figura 4 es una configuración completamente mallada donde cada interfaz conectada directamente puede recibir y enviar paquetes a cualquier otra interfaz similar. El LSP de esta red está configurado para ejecutarse desde el enrutador R1de entrada, pasando por el enrutador R3de tránsito, hasta el enrutador R6de salida. Además, un LSP inverso está configurado para ejecutarse desde R6 hasta R1R3 , creando tráfico bidireccional.
La cruz que se muestra en Figura 4 indica dónde no se está utilizando 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 BGP utiliza el LSP
- Comprobar sesiones BGP
- Comprobar la configuración del BGP
- Examinar rutas BGP
- Verificar rutas BGP recibidas
- Tomar las medidas adecuadas para resolver el problema de la red
- Compruebe que el tráfico BGP vuelve a utilizar el LSP
Compruebe que el tráfico BGP utiliza el LSP
Propósito
En este nivel del modelo de solución de problemas, BGP y el LSP pueden estar activos, sin embargo, es posible que el tráfico BGP no esté usando el LSP para reenviar tráfico.
Acción
Para comprobar que el tráfico BGP utiliza el LSP, introduzca 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-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
La salida de ejemplo muestra que el tráfico BGP no utiliza el LSP, por lo que las etiquetas MPLS no aparecen en la salida. En lugar de utilizar el LSP, el tráfico del BGP utiliza el protocolo de puerta de enlace interior (IGP) para llegar a la dirección de salida de LSP del próximo salto del BGP para R6 y R1. El valor predeterminado de Junos OS es usar LSP para el tráfico BGP cuando el próximo salto del BGP sea igual a la dirección de salida de LSP.
Comprobar sesiones BGP
Propósito
Muestra información de resumen sobre BGP y sus vecinos para determinar si las rutas se reciben de pares en el sistema autónomo (AS). Cuando se establece una sesión BGP, los pares intercambian mensajes de actualización.
Acción
Para comprobar que las sesiones BGP están activas, introduzca el siguiente comando de modo operativo de la CLI de Junos OS desde el enrutador de entrada:
user@host> show bgp summary
Ejemplo de salida 1
nombre-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
Ejemplo de salida 2
nombre-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
El resultado de ejemplo 1 muestra que no se ha establecido un par (enrutador 10.0.0.6 de salida), como 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 como lo indica el número de rutas activas, recibidas y amortiguadas. Por ejemplo, 0/0/0 for peer 10.0.0.2 indica que no había rutas BGP activas o recibidas en la tabla de enrutamiento, y que no se amortiguaron rutas BGP; 1/1/0 for peer 10.1.36.2 indica que una ruta BGP estaba activa y recibida en la tabla de enrutamiento, y que no se amortiguaron rutas BGP.
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 información sobre cómo comprobar la configuración del BGP, consulte Comprobar la configuración del BGP.
La salida de ejemplo 2 muestra la salida del enrutador R1 de entrada después de que las configuraciones de BGP se activaron R1 y R6 se corrigieron en Tomar las medidas adecuadas para resolver el problema de red. Se establecen todos los pares BGP y se activa y se recibe una ruta. No se amortiguaron rutas BGP.
Si el resultado del show bgp summary comando muestra que un vecino está activo pero que los paquetes no se reenvían, compruebe las rutas recibidas del enrutador de salida. Para obtener información sobre cómo comprobar si hay rutas recibidas en el enrutador de salida, consulte Verificar rutas BGP recibidas.
Comprobar 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 acerca de al menos un par del grupo (la dirección IP y el número de AS del par). Cuando 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
Ejemplo de salida 1
nombre-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;
}
}
}
Ejemplo de salida 2
nombre-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
La salida de ejemplo muestra las configuraciones de BGP en el enrutador R1 de entrada y en el enrutador R6de 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 relevantes 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/portunit logical-unit-number].
La salida de ejemplo para el enrutador R1 de entrada y el enrutador R6 de salida muestra que a la configuración del protocolo BGP le falta 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 los pares BGP están emparejando. Si la local-address instrucción no está configurada, los paquetes BGP se reenvían desde la dirección de interfaz saliente, que no coincide con la dirección a la que los pares BGP están emparejando, y 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]. BGP utiliza esta dirección, que es idéntica a la dirección LSP, para reenviar el tráfico BGP a través del LSP.
Además, la configuración del BGP en R1 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 próximo salto del BGP (10.1.36.2). La configuración del BGP activado R6 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 del LSP inverso (10.0.0.1) no coincida con la dirección del próximo salto del BGP (10.1.13.1).
En este caso, dado que falta la local-address instrucción en las configuraciones BGP de ambos enrutadores y la dirección de destino LSP no coincide con la dirección del próximo salto BGP, BGP no está utilizando el LSP para reenviar tráfico.
Examinar rutas BGP
Propósito
Puede examinar el proceso de selección de ruta de BGP para determinar la ruta única y activa cuando BGP recibe varias rutas al mismo destino. En este paso, examinamos el LSP R6-to-R1inverso, que hace R6 el enrutador de entrada para ese LSP.
Acción
Para examinar las rutas BGP y la selección de rutas, ingrese el siguiente comando del modo operativo de la CLI de Junos OS:
user@host> show route destination-prefix detail
Ejemplo de salida 1
nombre-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
Ejemplo de salida 2
nombre-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
El resultado de ejemplo 1 muestra que el siguiente salto (10.1.13.1) del BGP 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.
El ejemplo de salida 2, tomado después de corregir las configuraciones en R1 y R6, muestra que el siguiente salto (10.0.0.1) del BGP 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 el 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 concreta en el enrutador de salida, introduzca el siguiente comando de modo operativo de la CLI de Junos OS:
user@host> show route receive protocol bgp neighbor-address
Ejemplo de salida 1
nombre-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)
Ejemplo de salida 2
nombre-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
El resultado 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 BGP de R1 y R6 son incorrectas.
El resultado de ejemplo 2 muestra una ruta BGP instalada en la tabla de inet.0 enrutamiento después de que las configuraciones de BGP estén activadas R1 y R6 se corrigen mediante Tomar las medidas adecuadas para resolver el problema de red.
Tomar las medidas adecuadas para resolver el problema de la red
Problema
Description
La acción adecuada depende del tipo de problema que haya aislado. En este ejemplo, una ruta estática configurada en R2 se elimina del nivel jerárquico [routing-options]. Otras acciones apropiadas podrían incluir las siguientes:
Solución
Compruebe la configuración del router local y edítelo si corresponde.
Solucione los problemas del enrutador intermedio.
Compruebe la configuración del host remoto y edítela si corresponde.
Solucionar problemas de protocolos de enrutamiento.
Identificar posibles causas adicionales.
Para resolver el problema en este ejemplo, escriba los siguientes comandos de la 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 muestra ahora la ruta BGP como la ruta preferida, como lo indica el asterisco (*).
Compruebe que el tráfico BGP vuelve a utilizar el LSP
Propósito
Después de realizar la acción adecuada para corregir el error, es necesario comprobar de nuevo el LSP para confirmar que el tráfico BGP está utilizando el LSP y que el problema en la capa BGP se ha resuelto.
Acción
Para comprobar que el tráfico BGP utiliza el LSP, introduzca 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-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 el número de saltos que este paquete MPLS puede viajar a través de la red (1). Se disminuye 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 ejemplo porque el traceroute comando se emite a un destino BGP donde el siguiente salto BGP para esa ruta es la dirección de salida LSP. De forma predeterminada, Junos OS utiliza LSP para el tráfico BGP cuando el siguiente salto del BGP es igual a la dirección de salida del LSP.
Si el siguiente salto del BGP no es igual a la dirección de salida del 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 ejemplo en Comprobar sesiones BGP.
Mostrar paquetes BGP enviados o recibidos
Acción
Para configurar el seguimiento de paquetes de protocolo BGP enviados o recibidos, siga estos pasos:
En el modo de configuración, vaya al siguiente nivel de jerarquía:
content_copy zoom_out_map[edit] user@host# edit protocol bgp traceoptions
Configure el indicador para mostrar información de paquetes enviados, recibidos o recibidos y enviados:
content_copy zoom_out_map[edit protocols bgp traceoptions] user@host# set flag update sendo
content_copy zoom_out_map[edit protocols bgp traceoptions] user@host# set flag update receive
o
content_copy zoom_out_map[edit protocols bgp traceoptions] user@host# set flag update
Verifique la configuración:
content_copy zoom_out_mapuser@host# show
Por ejemplo:
content_copy zoom_out_map[edit protocols bgp traceoptions] user@host# show file bgplog size 10k files 10; flag update send;
o
content_copy zoom_out_map[edit protocols bgp traceoptions] user@host# show file bgplog size 10k files 10; flag update receive;
o
content_copy zoom_out_map[edit protocols bgp traceoptions] user@host# show file bgplog size 10k files 10; flag update send receive;
Confirme su configuración:
content_copy zoom_out_mapuser@host# commit
Vea el contenido del archivo que contiene los mensajes detallados:
content_copy zoom_out_mapuser@host# run show log filenamePor ejemplo:
content_copy zoom_out_map[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 tenga problemas, como problemas de conectividad, es posible que deba examinar las rutas de 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-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
La salida 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 salto siguiente que en el show route detail comando (la dirección del salto siguiente y el nombre de la 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 del 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 correcta 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 Controladores de tráfico.
Ejemplo: Anulación de la directiva de enrutamiento BGP predeterminada en enrutadores de transporte de paquetes serie PTX
En este ejemplo se muestra cómo invalidar la directiva de enrutamiento predeterminada en enrutadores de transporte de paquetes, como los enrutadores de transporte de paquetes de la serie PTX.
Requisitos
Este ejemplo requiere Junos OS versión 12.1 o posterior.
Descripción general
De forma predeterminada, los enrutadores de la serie PTX no instalan rutas BGP en la tabla de reenvío.
Para los enrutadores de la 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 de Junos OS. Con la siguiente política de enrutamiento en los enrutadores de la serie PTX, las rutas 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 hay rutas BGP instaladas 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 eficazmente la directiva de enrutamiento BGP predeterminada.
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, a continuación, copie y pegue los comandos en la CLI en el nivel de [edit] 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
En el ejemplo siguiente, debe explorar por varios niveles en la jerarquía de configuración. Para obtener información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración en la Guía del usuario de CLI de Junos OS.
Para instalar rutas BGP seleccionadas en la tabla de reenvío:
Configure una lista de prefijos para instalar en la tabla de reenvío.
content_copy zoom_out_map[edit policy-options prefix-list install-bgp] user@host# set 66.0.0.1/32
Configure la directiva de enrutamiento, aplicando la lista de prefijos como condición.
content_copy zoom_out_map[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 directiva de enrutamiento a la tabla de reenvío.
content_copy zoom_out_map[edit routing-options forwarding-table] user@host# set export override-ptx-series-default
Resultados
Desde el modo de configuración, escriba los comandos show policy-options y show routing-options para confirmar la 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;
}
Cuando termine de configurar el dispositivo, ingrese commit en el modo de configuración.
Verificación
Confirme que la configuración funcione correctamente.
Comprobación de que la ruta seleccionada está instalada en la tabla de reenvío
Propósito
Asegúrese de que la directiva configurada anula la directiva predeterminada.
Acción
Desde el modo operativo, ingrese el comando show route forwarding-table.
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 de 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 eventos de transición de estado BGP en el registro del sistema, siga estos pasos:
En el modo de configuración, vaya al siguiente nivel de jerarquía:
content_copy zoom_out_map[edit] user@host# edit protocol bgpConfigure el registro del sistema:
content_copy zoom_out_mapuser@host# set log-updown
Verifique la configuración:
content_copy zoom_out_mapuser@host# show
Confirme su configuración:
content_copy zoom_out_mapuser@host# commit
Significado
Los mensajes de registro de los eventos de transición de estado BGP son suficientes para diagnosticar la mayoría de los problemas de sesión BGP. Tabla 3 enumera y describe los seis estados de una sesión BGP.
Estado de BGP | Description |
|---|---|
Idle | Este es el primer estado de una conexión. BGP espera un evento de inicio iniciado por un administrador. El evento de inicio puede ser el establecimiento de una sesión BGP a través de la configuración del enrutador o el restablecimiento de una sesión existente. Después del evento de inicio, BGP inicializa sus recursos, restablece un temporizador de conexión y reintento, inicia una conexión de transporte TCP y comienza a escuchar las conexiones iniciadas por pares remotos. A continuación, BGP pasa a un Connect estado. Si hay errores, BGP vuelve al Idle estado. |
Connect | BGP espera a que se complete la conexión del protocolo de transporte. Si la conexión de transporte TCP se realiza correctamente, el estado pasa a OpenSent. Si la conexión de transporte no se realiza correctamente, el estado pasa a Active. Si el temporizador de conexión y reintento 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 | BGP intenta adquirir un par iniciando una conexión de protocolo de transporte. Si se realiza correctamente, el estado pasa a OpenSent. Si el temporizador de conexión y reintento caduca, BGP reinicia el temporizador de conexión y vuelve al Connect estado. BGP sigue escuchando una conexión que puede iniciarse desde otro par. El estado puede volver a Idle en caso de otros eventos, como un evento de parada. En general, un estado vecino alterna entre Connect y Active es una indicación de que hay un problema con la conexión de transporte TCP. Tal problema puede ser causado por muchas retransmisiones TCP o la incapacidad de un vecino para llegar a la dirección IP de su par. |
OpenSent | BGP recibe un mensaje abierto de su par. En el estado, BGP OpenSent compara su número de sistema autónomo (AS) con el número de AS de su par y reconoce si el par pertenece al mismo AS (BGP interno) o a un AS (BGP externo) diferente. Se comprueba que el mensaje abierto sea correcto. En caso de errores, como un número de versión incorrecto de un AS inaceptable, 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, 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 keepalive y restablece el temporizador keepalive. En este estado, se negocia el tiempo de espera. Si el tiempo de espera es 0, los temporizadores hold y keepalive no se reinician. Cuando se detecta una desconexión de transporte TCP, el estado vuelve a Active. |
OpenConfirm | BGP espera un mensaje keepalive o de notificación. Si se recibe un keepalive, el estado se convierte en Established, y la negociación del vecino se completa. Si el sistema recibe un mensaje de actualización o keepalive, reinicia el temporizador de espera (suponiendo que el tiempo de espera negociado no sea 0). Si se recibe un mensaje de notificación, el estado recurre Idle. El sistema envía mensajes keepalive periódicos a la velocidad establecida por el temporizador keepalive. En caso de una notificación de desconexión de transporte o en respuesta a un evento de parada, el estado recurre 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 del vecino. En este estado, BGP intercambia ackets de actualización con sus pares y el temporizador de espera se reinicia al recibir un mensaje de actualización o 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. BGP vuelve a Idle cuando expira el temporizador de retención, se recibe una notificación de desconexión del protocolo de transporte, se recibe un evento de detención o en respuesta a cualquier otro evento. |
Para obtener información más detallada sobre los paquetes del protocolo BGP, configure el seguimiento específico del BGP. Consulte Lista de comprobación para rastrear condiciones de error 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 de BGP, puede ver información más detallada configurando opciones específicas de BGP. También puede configurar el seguimiento para un par o grupo de pares BGP específico. Para obtener más información, consulte la Guía de configuración de conceptos básicos del sistema Junos.
- Mostrar información detallada del protocolo BGP
- Diagnosticar problemas de establecimiento de sesión 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:
content_copy zoom_out_map[edit] user@host# edit protocol bgp traceoptions
Configure el indicador para que muestre mensajes de protocolo BGP detallados:
content_copy zoom_out_map[edit protocols bgp traceoptions] user@host# set flag update detail
Verifique la configuración:
content_copy zoom_out_mapuser@host# show
Por ejemplo:
content_copy zoom_out_map[edit protocols bgp traceoptions] user@host# show flag update detail;
Confirme su configuración:
content_copy zoom_out_mapuser@host# commit
Vea el contenido del archivo que contiene los mensajes detallados:
content_copy zoom_out_mapuser@host# run show log filenamePor ejemplo:
content_copy zoom_out_map[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 de BGP y presenta resultados de ejemplo para algunos de los indicadores. También puede configurar el seguimiento para un par o grupo de pares BGP específico. Para obtener más información, consulte la Guía de configuración de conceptos básicos del sistema Junos.
Rastreo de banderas | Description | Ejemplo de salida |
|---|---|---|
aspath | Operaciones de expresión regular de ruta del AS | No disponible. |
damping | Operaciones de amortiguació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 keepalive de 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 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 BGP
Propósito
Para realizar un seguimiento de los problemas de establecimiento de sesiones de BGP.
Acción
Para realizar un seguimiento de los problemas de establecimiento de sesiones BGP, siga estos pasos:
En el modo de configuración, vaya al siguiente nivel de jerarquía:
content_copy zoom_out_map[edit] user@host# edit protocol bgpConfigure los mensajes abiertos del BGP:
content_copy zoom_out_map[edit protocols bgp] user@host# set traceoptions flag open detail
Verifique la configuración:
content_copy zoom_out_mapuser@host# show
Por ejemplo:
content_copy zoom_out_map[edit protocols bgp] user@host# show traceoptions { file bgplog size 10k files 10; flag open detail; }Confirme su configuración:
content_copy zoom_out_mapuser@host# commit
Vea el contenido del archivo que contiene los mensajes detallados:
content_copy zoom_out_mapuser@host#run show log filenamePor ejemplo:
content_copy zoom_out_map[edit protocols bgp] user@hotst# run show log bgplog
content_copy zoom_out_mapSep 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 opciones específicas de IS-IS.
Para configurar las opciones de IS-IS, siga estos pasos:
- Visualización de información detallada del protocolo IS-IS
- Visualización de paquetes de protocolo IS-IS enviados o recibidos
- Análisis detallado de las PDU de estado de vínculo IS-IS
Visualización de información detallada del protocolo IS-IS
Acción
Para realizar un seguimiento detallado de los mensajes IS-IS, siga estos pasos:
Configure el indicador para mostrar mensajes detallados del protocolo IS-IS.
content_copy zoom_out_map[edit protocols isis traceoptions] user@host# set flag hello detail
Compruebe la configuración.
content_copy zoom_out_mapuser@host# show
Por ejemplo:
content_copy zoom_out_map[edit protocols isis traceoptions] user@host# show file isislog size 10k files 10; flag hello detail;
Confirme la configuración.
content_copy zoom_out_mapuser@host# commit
Ver el contenido del archivo que contiene los mensajes detallados.
content_copy zoom_out_mapuser@host# run show log filenamePor ejemplo:
content_copy zoom_out_mapuser@host# run show log isislog
content_copy zoom_out_mapNov 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íficamente para IS-IS y presenta resultados de ejemplo para algunos de los indicadores.
Rastreo de banderas | Description | Ejemplo de salida |
|---|---|---|
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 enlace (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 de PDU con número de secuencia parcial (PSNP) | Nov 28 20:40:39 Received L2 PSN, source abc-core-01, interface so-1/1/0.0Nov 28 20:40:39 Received L2 PSN, source abc-core-02, interface so-1/1/1.0Nov 28 20:41:36 Sending L2 PSN on interface so-1/1/1.0Nov 28 20:41:36 Sending L2 PSN on interface so-1/1/0.0Nov 28 20:42:35 Received L2 PSN, source abc-core-02, interface so-1/1/1.0Nov 28 20:42:35 LSP abc-edge-03.00-00 lifetime 1196Nov 28 20:42:35 sequence 0x68c checksum 0x746dNov 28 20:42:35 Received L2 PSN, source abc-core-01, interface so-1/1/0.0Nov 28 20:42:35 LSP abc-edge-03.00-00 lifetime 1196Nov 28 20:42:35 sequence 0x68c checksum 0x746dNov 28 20:42:49 Sending L2 PSN on interface so-1/1/1.0Nov 28 20:42:49 LSP abc-core-01.00-00 lifetime 1197Nov 28 20:42:49 sequence 0x1c4fb checksum 0x9becNov 28 20:42:49 Sending L2 PSN on interface so-1/1/0.0Nov 28 20:42:49 LSP abc-core-01.00-00 lifetime 1197Nov 28 20:42:49 sequence 0x1c4fb checksum 0x9bec |
spf | Cálculos de la ruta más corta primero (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
Visualización de paquetes de protocolo IS-IS enviados o recibidos
Para configurar el seguimiento sólo para paquetes de protocolo IS-IS enviados o recibidos, siga estos pasos:
Configure el indicador para mostrar los paquetes enviados, recibidos o enviados y recibidos.
content_copy zoom_out_map[edit protocols isis traceoptions] user@host# set flag hello send
o
content_copy zoom_out_map[edit protocols isis traceoptions] user@host# set flag hello receive
o
content_copy zoom_out_map[edit protocols isis traceoptions] user@host# set flag hello
Compruebe la configuración.
content_copy zoom_out_mapuser@host# show
Por ejemplo:
content_copy zoom_out_map[edit protocols isis traceoptions] user@host# show file isislog size 10k files 10; flag hello send;
o
content_copy zoom_out_map[edit protocols isis traceoptions] user@host# show file isislog size 10k files 10; flag hello receive;
o
content_copy zoom_out_map[edit protocols isis traceoptions] user@host# show file isislog size 10k files 10; flag hello send receive;
Confirme la configuración.
content_copy zoom_out_mapuser@host# commit
Ver el contenido del archivo que contiene los mensajes detallados.
content_copy zoom_out_mapuser@host# run show log filenamePor ejemplo:
content_copy zoom_out_mapuser@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
Análisis detallado de las PDU de estado de vínculo IS-IS
Para analizar detalladamente las PDU de estado de vínculo IS-IS, siga estos pasos:
Configure los mensajes abiertos de IS-IS.
content_copy zoom_out_map[edit protocols isis traceoptions] user@host# set flag lsp detail
Compruebe la configuración.
content_copy zoom_out_mapuser@host# show
Por ejemplo:
content_copy zoom_out_map[edit protocols isis traceoptions] user@host# show file isislog size 5m world-readable; flag error; flag lsp detail;
Confirme la configuración.
content_copy zoom_out_mapuser@host# commit
Ver el contenido del archivo que contiene los mensajes detallados.
content_copy zoom_out_mapuser@host# run show log filenamePor ejemplo:
content_copy zoom_out_mapuser@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 opciones específicas de OSPF.
Para configurar las opciones de OSPF, siga estos pasos:
- Diagnosticar problemas de establecimiento de sesiones OSPF
- Analice en detalle los paquetes de publicidad de estado de vínculo de OSPF
Diagnosticar problemas de establecimiento de sesiones OSPF
Acción
Para realizar un seguimiento detallado de los mensajes OSPF, siga estos pasos:
En el modo de configuración, vaya al siguiente nivel de jerarquía:
content_copy zoom_out_map[edit] user@host# edit protocols ospf traceoptions
Configure los mensajes de saludo de OSPF:
content_copy zoom_out_map[edit protocols ospf traceoptions] user@host# set flag hello detail
Verifique la configuración:
content_copy zoom_out_mapuser@host# show
Por ejemplo:
content_copy zoom_out_map[edit protocols ospf traceoptions] user@host# show file ospf size 5m world-readable; flag hello detail;
Confirme su configuración:
content_copy zoom_out_mapuser@host# commit
Vea el contenido del archivo que contiene los mensajes detallados:
content_copy zoom_out_mapuser@host# run show log filenamePor ejemplo:
content_copy zoom_out_mapuser@host# run show log ospf
content_copy zoom_out_mapDec 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 los indicadores de seguimiento de OSPF y presenta resultados de ejemplo para algunos de los indicadores.
Rastreo de banderas | Description | Ejemplo de salida |
|---|---|---|
database-descripttion | Todos los paquetes de descripción de bases 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 de inundación 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 | Hola paquetes | 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 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 en detalle los paquetes de publicidad de estado de vínculo de OSPF
Acción
Para analizar en detalle los paquetes de publicidad de estado de vínculo de OSPF, siga estos pasos:
En el modo de configuración, vaya al siguiente nivel de jerarquía:
content_copy zoom_out_map[edit] user@host# edit protocols ospf traceoptions
Configure los paquetes de estado de vínculo OSPF:
content_copy zoom_out_map[edit protocols ospf traceoptions] user@host# set flag lsa-update detail
Verifique la configuración:
content_copy zoom_out_mapuser@host# show
Por ejemplo:
content_copy zoom_out_map[edit protocols ospf traceoptions] user@host# show file ospf size 5m world-readable; flag hello detail; flag lsa-update detail;
Confirme su configuración:
content_copy zoom_out_mapuser@host# commit
Vea el contenido del archivo que contiene los mensajes detallados:
content_copy zoom_out_mapuser@host# run show log filenamePor ejemplo:
content_copy zoom_out_mapuser@host# run show log ospf
content_copy zoom_out_mapDec 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
