Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Solución de problemas de sesiones BGP

Lista de verificación para comprobar el protocolo de BGP y los interlocutores

Purpose

Tabla 1proporciona vínculos y comandos para comprobar si el Protocolo de puerta de enlace de borde (BGP) está configurado correctamente en un enrutador Juniper Networks de su red, las sesiones del Protocolo de puerta de enlace de borde interno (IBGP) y del Protocolo de puerta de enlace de borde exterior (EBGP) son correctamente establecida, las rutas externas se anuncian y se reciben correctamente, y el proceso de selección de ruta de acceso de BGP funciona correctamente.

Intervención

 

Tabla 1: Lista de verificación para comprobar el protocolo de BGP y los interlocutores

Funciones

Comando o acción

Verificar BGP homólogos
  1. Comprobar BGP en un enrutador interno

show configuration

  1. Comprobar BGP en un enrutador de borde

show configuration

  1. Comprobar rutas BGP anunciadas

show route advertising-protocol bgp neighbor-address

  1. Compruebe que se ha recibido una ruta BGP específica en su enrutador

show route receive-protocol bgp neighbor-address

Examinar BGP rutas y la selección de ruta  
  1. Examinar la selección de preferencias local

show route destination-prefix < detail >

  1. Examinar la selección de varias rutas de discriminador de salida

show route destination-prefix < detail >

  1. Examinar la EBGP sobre la selección de IBGP

show route destination-prefix < detail >

  1. Examen de la selección de costos de IGP

show route destination-prefix < detail >

Examinar rutas de la tabla de reenvío

show route forwarding-table

Verificar BGP homólogos

Purpose

Suponiendo que todos los enrutadores estén configurados correctamente para BGP, puede comprobar si las sesiones IBGP y EBGP están establecidas correctamente, si las rutas externas se anuncian y se reciben correctamente, y si el proceso de selección de ruta de acceso BGP funciona correctamente.

Figura 1muestra un ejemplo BGP topología de red utilizada en este tema.

Figura 1: Topología de red BGPTopología de red BGP

La red consta de dos equipos conectados directamente, los cuales son externos e internos. Los homólogos externos se conectan directamente a través de una interfaz compartida y ejecutan EBGP. Los homólogos internos se conectan a través delo0sus interfaces de bucle de retroceso () a través de IBGP. Cuando 65001 está ejecutando OSPF y como 65002 se está ejecutando, es como su IGP subyacente. Los enrutadores IBGP no tienen que estar conectados directamente, el IGP subyacente permite que los vecinos se lleguen de uno a otro.

Los dos enrutadores en como 65001 contienen un EBGP que se enlaza a comoR2 65002 R4(y) sobre el que anuncian prefijos adicionales: 100.100.1.0, 100.100.2.0, 100.100.3.0y 100.100.4.0. Asimismo, R1 y R5 está insertando valores discriminadores de varios salidas (MED) de 5 y 10, respectivamente, para algunas rutas.

Los enrutadores internos de ambas asociadas utilizan una topología de IBGP de malla completa. Se requiere una malla completa, ya que las redes no utilizan confederaciones ni reflectores de rutas, por lo que cualquier ruta obtenida a través de IBGP no se distribuye a otros vecinos internos. Por ejemplo, cuando R3 se aprende una ruta de R2, R3 no distribuye esa ruta a R6 porque la ruta se aprendió a través de IBGP, R6 por lo que debe tener una conexión R2 directa BGP con el fin de conocer la ruta.

En una topología de malla completa, solo el enrutador de borde que recibe la información BGP externa distribuye esa información a otros enrutadores de su propio como. El enrutador receptor no redistribuye esa información a otros enrutadores IBGP por sí mismo como.

Desde el punto de vista de 65002, las siguientes sesiones deben ser:

  • Los cuatro enrutadores en como 65002 deben tener IBGP sesiones establecidas entre sí.

  • R2debe haber establecida una sesión EBGP con R1.

  • R4debe haber establecida una sesión EBGP con R5.

Para comprobar BGP iguales, siga estos pasos:

Comprobar BGP en un enrutador interno

Purpose

Para comprobar el BGP configuración de un enrutador interno.

Intervención

Para comprobar el BGP configuración de un enrutador interno, escriba el siguiente comando Junos OS de la interfaz de línea de comandos (CLI):

La siguiente muestra de resultados es para una configuración BGP en R3:

Resultados de ejemplo
nombre de comando

Efectos

El resultado del ejemplo muestra una configuración básica BGP en enrutadores R3 y. R6 El AS local (65002) y un grupo ( ) se configuran en ambos enrutadores. tiene tres pares internos, y — incluidos en el nivel de jerarquía [ ]. también tiene tres pares internalR310.0.0.210.0.0.410.0.0.6protocols bgp group groupR6 internos: 10.0.0.2, 10.0.0.3, y 10.0.0.4. El protocolo de IGP subyacente es el sistema intermedio sistema-a-intermedio (IS-IS) y las interfaces relevantes están configuradas para ejecutarse es-IS.

Tenga en cuenta que, en esta configuración, el ID del enrutador se configura manualmente para evitar cualquier problema de identificación de enrutador duplicado.

Comprobar BGP en un enrutador de borde

Purpose

Para comprobar el BGP la configuración de un enrutador de borde.

Intervención

Para comprobar el BGP la configuración de un enrutador de borde, escriba el siguiente comando de Junos OS modo operativo de CLI:

Resultados de ejemplo
nombre de comando

El siguiente resultado de ejemplo es para una configuración BGP en dos enrutadores de borde, R2 y R4 desde 65002:

Efectos

El resultado de ejemplo muestra una configuración BGP básica en enrutadores de borde R2 y R4. Ambos enrutadores tienen el preparado (65002) incluidorouting-optionsen el nivel de jerarquía []. Cada enrutador incluye dos grupos en elprotocols bgp group groupnivel de jerarquía []. Los pares externos se incluyen en el grupo externo, ya sea toR1 o toR5 , según el enrutador. Los interlocutores internos se incluyen en internal el grupo. El protocolo subyacente de IGP es-está en ambos enrutadores y la configuración de ejecución de las interfaces relevantes es IS-IS.

Tenga en cuenta que, en la configuración de ambos enrutadores, el ID del enrutador se configura manualmente para evitar next-hop-self problemas de ID de enrutador duplicados, y la instrucción se incluye para evitar cualquier problema de accesibilidad de próximo salto BGP.

Comprobar rutas BGP anunciadas

Purpose

Puede determinar si una ruta concreta configurada se está anunciando a un vecino.

Intervención

Para comprobar la información de enrutamiento tal y como se ha preparado para la publicidad de la BGP vecino especificada, escriba el siguiente comando de Junos OS modo operativo de CLI:

Resultados de ejemplo
nombre de comando

Efectos

El resultado del ejemplo muestra las rutas de R2 BGP anunciadas a su vecino 10.0.0.4 ,R4(). De un total de 22 rutas en inet.0 la tabla de enrutamiento, 20 son destinos activos. Ninguna ruta está hidden o está en hold-down el estado. Las rutas residen en hold-down el estado anterior a la declaración activa, y las rutas rechazadas por una directiva de enrutamiento pueden hidden colocarse en el estado. La información mostrada refleja las rutas que exporta la tabla de enrutamiento al Protocolo de enrutamiento BGP.

Compruebe que se ha recibido una ruta BGP específica en su enrutador

Purpose

Mostrar la información de enrutamiento a medida que se recibe a través de una BGP vecino en particular y anunciada por el enrutador local al vecino.

Intervención

Para comprobar que se recibe una ruta de BGP específica en su enrutador, escriba el siguiente comando de Junos OS modo operativo de CLI:

Resultados de ejemplo
nombre de comando

Efectos

El resultado del ejemplo muestra cuatro rutas de R2 BGP desde y R4dos de. De las cuatro rutas desde R2, solo dos están activos en la tabla de enrutamiento, como indica el asterisco (*), mientras que las dos rutas R4 recibidas de están activas en la tabla de enrutamiento. Todas las rutas de BGP se prosiguieron como 65001.

Examinar BGP rutas y la selección de ruta

Purpose

Puede examinar el proceso de selección de BGP ruta de acceso para determinar el único path activo cuando BGP recibe varias rutas al mismo prefijo de destino.

Figura 2: Topología de red BGPTopología de red BGP

La red en Figura 2 muestra que R1 y R5 se anuncian las mismas rutas de R2 agregado R4, a y que R2 da R4 como resultado dos rutas al mismo prefijo de destino. El proceso de selección de R2 ruta R4 en y 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 next-hop el atributo BGP es alcanzable. Si no se puede resolver el BGP siguiente salto, la ruta no se instalará. Cuando se instala una ruta BGP en la tabla de enrutamiento, ésta debe pasar por un proceso de selección de ruta si existen varias rutas para el mismo prefijo de destino. El proceso de selección de ruta de acceso de BGP continúa en el siguiente orden:

  1. Se comparan las preferencias de ruta en la tabla de enrutamiento. Por ejemplo, si existe una OSPF y una ruta BGP para un destino determinado, se selecciona la ruta OSPF como ruta activa, ya que la ruta OSPF tiene una preferencia predefinida de 110, mientras que la ruta BGP tiene una preferencia predefinida de 170.

  2. Se comparan las rutas para las preferencias locales. Se prefiere la ruta con la mayor preferencia local. Por ejemplo, consulte examinar la selección de preferencias locales.

  3. Se evalúa el atributo AS path. Es preferible que sea más corta que la ruta de acceso.

  4. Se evalúa el código de origen. Se prefiere el código de origen más I (IGP) < E (EGP) < ? (Incomplete)bajo ().

  5. Se evalúa el valor MED. De forma predeterminada, si alguna de las rutas se anuncia desde el mismo vecino que, es preferible el menor valor MED. La ausencia de un valor MED se interpreta como un MED de 0. Para obtener un ejemplo, consulte examinar la selección de ruta de discriminador de múltiples salidas.

  6. La ruta se evalúa para que se aprendirá a través de EBGP o IBGP. EBGP se prefieren las rutas aprendidas a IBGP rutas aprendidas. Para obtener un ejemplo, consulte examinar el EBGP a través de la selección de IBGP

  7. Si la ruta se ha aprendido desde IBGP, se prefiere la ruta con el menor IGP coste. Para obtener un ejemplo, consulte examinar el IGP selección de costos. El siguiente salto físico al IBGP del mismo nivel se instala de acuerdo con las tres reglas siguientes:

      1. Después de que el BGP inet.0 examina inet.3 las tablas de enrutamiento y, se utiliza el siguiente salto físico de la ruta con la menor preferencia.

      1. Si los valores de preferencia en inet.0 la y inet.3 las tablas de enrutamiento son empates, se utiliza el siguiente salto físico de inet.3 la ruta en la tabla de enrutamiento.

      1. Cuando existe una perdedo de preferencia en la misma tabla de enrutamiento, se instala el siguiente salto físico de la ruta con más trazados.

  8. Se evalúa el atributo de lista de clústeres de reflejo de ruta. Se prefiere la lista de clústeres con una 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.

  9. Se evalúa el identificador del enrutador. Es preferible usar la ruta desde el interlocutor con el identificador de enrutador más bajo (normalmente, la dirección de bucle de retroceso).

  10. Se examina el valor de dirección del mismo nivel. Es preferible el interlocutor con la dirección IP más baja.

Para determinar el único path activo cuando el BGP recibe varias rutas al mismo prefijo de destino, escriba el siguiente comando de Junos OS modo operativo de CLI:

Los pasos siguientes ilustran el motivo inactivo que se muestra cuando BGP recibe varias rutas al mismo prefijo de destino y se selecciona una ruta como el único path activo:

Examinar la selección de preferencias local

Purpose

Para examinar una ruta a fin de determinar si preferencia local son los criterios de selección para el único path activo.

Intervención

Para examinar una ruta a fin de determinar si la preferencia local son los criterios de selección para el único path activo, escriba el siguiente comando de Junos OS modo operativo de CLI:

Resultados de ejemplo
nombre de comando

Efectos

El resultado del ejemplo muestra R4 que recibió dos instancias de 100.100.1.0 la ruta: uno from 10.0.0.2 (R2) y uno from 10.1.45.2 (R5). R4 seleccionó la ruta R2 desde como su ruta de acceso activa, tal y como se indica en el asterisco (*). La selección se basa en el valor de preferencia local contenido en Localpref el campo. Se prefiere la ruta con la preferencia local más alta. En el ejemplo, la ruta de acceso con el valor de preferencia local superior es R2el de 200.

La razón por la que no R5 se selecciona la ruta desde no Inactive reason se encuentra en el campo, Local Preferenceen este caso,.

Tenga en cuenta que las dos rutas proceden de la misma red vecina: COMO 65001.

Examinar la selección de varias rutas de discriminador de salida

Purpose

Para examinar una ruta para determinar si el MED son los criterios de selección para el único path activo.

Intervención

Para examinar una ruta a fin de determinar si el MED son los criterios de selección para el único path activo, escriba el siguiente comando de Junos OS modo operativo de CLI:

Resultados de ejemplo
nombre de comando

Efectos

El resultado del ejemplo muestra R4 que recibió dos instancias de 100.100.2.0 la ruta: uno de 10.0.0.2 (R2) y uno de 10.1.45.2 (R5). R4 seleccionó la ruta R2 de acceso de como su ruta activa, tal como se indica en el asterisco (*). La selección se basa en el valor MED contenido en el Metric: campo. Es preferible la ruta de acceso con el menor valor MED. En el ejemplo, la ruta de acceso con el menor valor MED (5) es la R2ruta de acceso desde la que. Tenga en cuenta que las dos rutas proceden de la misma red vecina: COMO 65001.

La razón por la que no se selecciona el path inactivo se muestra Inactive reason: en el campo, en este Not Best in its groupcaso. El texto se utiliza porque la Junos OS usa el proceso de selección MED determinista, de forma predeterminada.

Examinar la EBGP sobre la selección de IBGP

Purpose

Para examinar una ruta a fin de determinar si EBGP está seleccionado encima de IBGP como criterio de selección para el único path activo.

Intervención

Para examinar una ruta con el fin de determinar si EBGP está seleccionado más de IBGP como criterios de selección para el único path activo, escriba el siguiente comando de Junos OS modo operativo de CLI:

Resultados de ejemplo
nombre de comando

Efectos

El resultado del ejemplo muestra R4 que recibió dos instancias de 100.100.3.0 la ruta: uno from 10.1.45.2 (R5) y uno from 10.0.0.2 (R2). R4 seleccionó la ruta R5 desde como su ruta de acceso activa, tal y como se indica en el asterisco (*). La selección se basa en una preferencia para las rutas aprendidas de un EBGP del mismo nivel sobre las rutas aprendidas desde un IBGP. R5 es un EBGP del mismo nivel.

Puede determinar si se recibe una ruta de acceso desde un EBGP o IBGP de igual nivel Local As examinando Peer As los campos y. Por ejemplo, la ruta from R5 muestra el local AS IS 65002 y el interlocutor igual a 65001, lo que indica que la ruta se recibe de un EBGP del mismo nivel. La ruta from R2 muestra que tanto el local como el interlocutor es igual a 65002, lo que indica que se recibe de una IBGP del mismo nivel.

La razón por la que no se selecciona el path inactivo se muestra Inactive reason en el campo, en este Interior > Exterior > Exterior via Interiorcaso. El texto de esta razón muestra el orden de las preferencias que se aplican cuando se recibe la misma ruta desde dos enrutadores. La ruta recibida de una fuente estrictamente interna (IGP) es preferible en primer lugar, la ruta recibida de una fuente externa (EBGP) es preferible a la siguiente, y cualquier ruta que proceda de una fuente externa y que se reciba internamente (IBGP) será la preferida en último lugar. Por lo tanto, se seleccionan rutas EBGP a través de rutas del IBGP como la ruta activa.

Examen de la selección de costos de IGP

Purpose

Para examinar una ruta a fin de determinar si EBGP está seleccionado encima de IBGP como criterio de selección para el único path activo.

Intervención

Para examinar una ruta con el fin de determinar si EBGP está seleccionado más de IBGP como criterios de selección para el único path activo, escriba el siguiente comando de Junos OS modo operativo de CLI:

Resultados de ejemplo
nombre de comando

Efectos

El resultado del ejemplo muestra R6 que recibió dos instancias de 100.100.4.0 la ruta: uno from 10.0.0.4 (R4) y uno from 10.0.0.2 (R2). R6 seleccionó la ruta R4 de acceso de como su ruta activa, tal como se indica en el asterisco (*). La selección se basa en la métrica IGP, que se muestra Metric2 en el campo. Se prefiere la ruta con la métrica IGP más baja. En el ejemplo, la ruta de acceso con el menor valor de métrica IGP es R4la ruta de acceso de, con un valor de métrica de IGP R2 de 10, mientras que la ruta de acceso de tiene una métrica IGP de 20. Tenga en cuenta que las dos rutas proceden de la misma red vecina: COMO 65001.

El motivo por el que no se seleccionó el trazado inactivo se Inactive reason muestra en el campo, en IGP metriceste caso.

Lista de verificación para comprobar la capa de BGP

Relacionado

Descripción

Esta lista de comprobación proporciona los pasos y comandos para comprobar la configuración de BGP de la red conmutación de etiquetas multiprotocolo (MPLS). La lista de comprobación proporciona vínculos para obtener una descripción general de la configuración del BGP e información más detallada acerca de los comandos utilizados para configurar BGP. (Consulte Tabla 2.)

Solución

Tabla 2: Lista de verificación para comprobar la capa de BGP

Funciones

Comando o acción

Comprobación de la capa de BGP  
  1. Comprobar que el tráfico de BGP está utilizando el LSP

traceroute hostname

  1. Comprobar BGP las sesiones

show bgp summary

  1. Comprobar la configuración del BGP

show configuration

  1. Examinar BGP rutas

show route destination-prefix detail

  1. Comprobar la BGP de las rutas recibidas

show route receive protocol bgp neighbor-address

  1. Adopción de las medidas apropiadas para resolver el problema de red

La siguiente secuencia de comandos resuelve el problema específico que se describe en este tema:

[edit] edit protocols bgp

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

  1. Comprobar que el tráfico de BGP está utilizando de nuevo el LSP

traceroute hostname

Comprobación de la capa de BGP

Purpose

Después de haber configurado la ruta conmutada por etiqueta (LSP), haber determinado que está activa y configurado BGP y haber determinado que se han establecido las sesiones, asegúrese de que BGP esté utilizando el LSP para reenviar el tráfico.

Figura 3ilustra la capa de BGP del modelo de MPLS en capas.

Figura 3: Comprobación de la capa de BGPComprobación de la capa de BGP

Cuando comprueba la capa BGP, 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 hay ningún punto para comprobar la capa de BGP a menos que se haya establecido el LSP, ya que BGP utiliza el LSP de MPLS para reenviar el tráfico. Si la red no funciona en la capa BGP, el LSP no funciona según la configuración.

Figura 4ilustra el MPLS red que se utiliza en este tema.

Figura 4: MPLS red interrumpida en la capa BGPMPLS red interrumpida en la capa BGP

La red de Figura 4 la que se muestra es una configuración completamente commallada 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 de entrada R1 , a través del enrutador de tránsito, hasta el enrutador de R3 salida R6 . Además, se configura un LSP inverso para que se ejecute desde R6R3 a hasta R1 y se crea tráfico bidireccional.

La cruz que se Figura 4 muestra en indica dónde no se está utilizando BGP para reenviar el tráfico a través del LSP. Las posibles razones para que el LSP no funcione correctamente son que la dirección IP de destino de LSP no es igual a la BGP siguiente salto o que la BGP no está configurada correctamente.

Para comprobar la capa BGP, siga estos pasos:

Comprobar que el tráfico de BGP está utilizando el LSP

Purpose

En este nivel del modelo de solución de problemas, BGP y el LSP pueden estar en funcionamiento, no obstante BGP es posible que el tráfico no utilice el LSP para reenviar el tráfico.

Intervención

Para comprobar que el tráfico de BGP está utilizando el LSP, escriba el siguiente comando del modo operativo de interfaz de línea de comandos (CLI) Junos OS del enrutador de entrada:

Resultados de ejemplo
nombre de comando

Efectos

El resultado del ejemplo muestra que BGP tráfico no utiliza el LSP, por lo que MPLS etiquetas no aparecen en el resultado. En lugar de usar el LSP, el tráfico de BGP usa el protocolo de puerta de enlace interior (IGP) para llegar a la BGP dirección de salida del LSP de salto siguiente para R6 y R1 . El Junos OS predeterminada es utilizar LSP para el tráfico de BGP cuando el BGP siguiente salto es igual a la dirección de salida de LSP.

Comprobar BGP las sesiones

Purpose

Muestra información de resumen acerca de BGP y sus vecinos para determinar si los interlocutores reciben las rutas en el sistema autónomo (AS). Cuando se establece una sesión de BGP, los interlocutores intercambian mensajes de actualización.

Intervención

Para comprobar que BGP las sesiones están activas, escriba el siguiente comando de Junos OS modo operativo de CLI desde el enrutador de entrada:

Salida de ejemplo 1
nombre de comando
Ejemplo de salida 2
nombre de comando

Efectos

El resultado de ejemplo 1 muestra que un par (enrutador de salida 10.0.0.6 ) no está establecido, tal y como se indica en 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 elementos del mismo nivel se establecen de la forma indicada por el número de rutas activas, recibidas y amortiguadas. Por ejemplo, 0/0/0 para 10.0.0.2 el par indica que no había rutas de BGP activas o recibidas en la tabla de enrutamiento, y que no había ninguna ruta BGP amortiguación; 1/1/0 para 10.1.36.2 el par indica que una ruta BGP estaba activa y se recibió en la tabla de enrutamiento, y que no se amortiguaron rutas BGP.

Si la salida 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.

El resultado de ejemplo 2 muestra la salida del enrutador de entrada R1 después de que las configuraciones de BGP R1 y R6 se corrigieron en la adopción de la acción adecuada para resolver el problema de red. . Se establecen todos BGP iguales y una ruta está activa y se recibe. No hay ninguna ruta de BGP amortiguada.

Si la salida del show bgp summary comando muestra que un vecino está activo, pero no se reenvían los paquetes, compruebe si existen rutas recibidas del enrutador de salida. Para obtener información sobre cómo comprobar el enrutador de salida para rutas recibidas, consulte Verify received BGP Routes.

Comprobar la configuración del BGP

Purpose

Para que BGP se ejecute en el enrutador, debe definir el número de AS local, configurar al menos un grupo e incluir información de al menos un par en el grupo (dirección IP del par y número AS). Cuando BGP forma parte de una red MPLS, debe asegurarse de que el LSP esté configurado con una dirección IP de destino igual a la BGP siguiente salto para que BGP rutas se instalen con el LSP como el siguiente salto para esas rutas.

Intervención

Para comprobar la BGP la configuración, escriba el siguiente comando de Junos OS modo operativo de CLI:

Salida de ejemplo 1
nombre de comando
Ejemplo de salida 2
nombre de comando

Efectos

El resultado del ejemplo muestra las configuraciones de BGP en enrutador R1 de entrada y R6en el enrutador de salida. Ambas configuraciones muestran la local como (65432), una agrupacióninternal() y seis pares configurados. El protocolo de puerta de enlace interior subyacente es is y las interfaces relevantes están configuradas para ejecutarse.

Nota:

En esta configuración, el RID se configura manualmente para evitar cualquier problema de RID duplicado, y todas las interfaces configuradas con BGP family inet incluyenedit interfaces type-fpc/pic/port unit logical-unit-numberla instrucción en el nivel de jerarquía [].

Salida de ejemplo de enrutador R1 de entrada y enrutador R6 de salida muestra que la configuración del local-address protocolo de BGP no está en la instrucción del grupo interno. Cuando se local-address configura la instrucción, BGP paquetes se reenvían desde la dirección de interfaz delo0bucle de retroceso () de enrutador local, que es la dirección a la que están interfuncionando BGP iguales del mismo nivel. Si la local-address instrucción no está configurada, BGP paquetes se reenvían desde la dirección de la interfaz de salida, que no coincide con la dirección en la que están interconectando BGP interlocutores y no se BGP.

En el enrutador de entrada, la dirección IP10.0.0.1() de local-address la instrucción debe ser igual que la dirección configurada para el LSP en el enrutadorR6de salida to () en laedit protocols mpls label-switched-path lsp-path-nameinstrucción en el nivel de jerarquía []. BGP utiliza esta dirección, que es idéntica a la dirección del LSP, para reenviar BGP tráfico a través del LSP.

Además, la BGP configuración de en R1 incluye dos direcciones IP para R6, una dirección de interfaz10.1.36.2() y una direcciónlo010.0.0.6de interfaz de bucle de retroceso (), lo que da como10.0.0.6resultado que la dirección de destino del LSP () no coincida con la BGP Dirección de salto siguiente (10.1.36.2). La configuración R6 de BGP incluye también dos direcciones IP para R1, una dirección de interfaz10.1.13.1() y una direcciónlo0de interfaz de bucle de retroceso (), lo que da10.0.0.1como resultado que la dirección de destino de LSP inverso () no coincida con la BGP dirección de próximo salto ( 10.1.13.1).

En este caso, debido a local-address que falta la instrucción de la BGP configuraciones de ambos enrutadores y la dirección de destino del LSP no coincide con la BGP dirección de salto siguiente, BGP no está utilizando el LSP para reenviar el tráfico.

Examinar BGP rutas

Purpose

Puede examinar el proceso de selección de BGP ruta de acceso para determinar el único path activo cuando BGP recibe varias rutas al mismo destino. En este paso, examinaremos el LSP inverso, que conformará R6-to-R1R6 el enrutador de entrada para ese LSP.

Intervención

Para examinar BGP rutas y la selección de rutas, escriba el siguiente comando de Junos OS modo operativo de CLI:

Salida de ejemplo 1
nombre de comando
Ejemplo de salida 2
nombre de comando

Efectos

El resultado de ejemplo 1 muestra que el BGP siguiente salto ( 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 edit protocols mpls label-switched-path label-switched-path-name nivel de jerarquía [] cuando la configuración BGP de R6 y R1 no es correcta.

El resultado de ejemplo 2, tomado tras la corrección de las configuraciones de R1 y R6, muestra que el BGP siguiente ( 10.0.0.1 ) y la dirección de destino del LSP ( 10.0.0.1 ) son las mismas, lo que indica que BGP puede utilizar el LSP para reenviar BGP tráfico.

Comprobar la BGP de las rutas recibidas

Purpose

Muestre la información de enrutamiento que se recibió en el enrutador R6 , el enrutador de entrada para el LSP inverso R6-to-R1 .

Intervención

Para comprobar que se recibe una ruta de BGP específica en el enrutador de salida, escriba el siguiente comando de Junos OS modo operativo de CLI:

Salida de ejemplo 1
nombre de comando
Ejemplo de salida 2
nombre de comando

Efectos

La salida de ejemplo 1 muestra que el enrutador R6 de entrada (LSP inverso R6-to-R1 ) no recibe ninguna ruta de 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 inet.0 tabla de enrutamiento después de las BGP configuraciones R1 y R6 se corrigen mediante la adopción de la acción adecuada para resolver el problema de red.

Adopción de las medidas apropiadas para resolver el problema de red

Relacionado

Descripción

La acción adecuada depende del tipo de problema que se haya aislado. En este ejemplo, se elimina una ruta estática R2 configurada en enrouting-optionsel nivel de jerarquía []. Entre otras acciones apropiadas se pueden incluir las siguientes:

Solución

  • Compruebe la configuración del enrutador local y edítelo si es necesario.

  • Solucione el problema del enrutador intermedio.

  • Compruebe la configuración del host remoto y edítelo si es necesario.

  • Solucionar problemas de protocolos de enrutamiento.

  • Identificar posibles causas adicionales.

Para resolver el problema de este ejemplo, escriba los siguientes comandos de Junos OS CLI:

Resultados de ejemplo

Efectos

El resultado del ejemplo muestra la ruta estática eliminada derouting-optionsla jerarquía [] y la nueva configuración confirmada. La salida del show route comando ahora muestra el BGP ruta como la ruta preferida, tal y como lo indica el*asterisco ().

Comprobar que el tráfico de BGP está utilizando de nuevo el LSP

Purpose

Después de tomar las medidas adecuadas para corregir el error, debe comprobarse de nuevo el LSP para confirmar que BGP tráfico está utilizando el LSP y que se ha resuelto el problema en la capa BGP.

Intervención

Para comprobar que el tráfico de BGP está utilizando el LSP, escriba el siguiente comando de Junos OS modo operativo de CLI desde el enrutador de entrada:

Resultados de ejemplo
nombre de comando

Efectos

El resultado del ejemplo muestra que las etiquetas de MPLS se utilizan para reenviar paquetes a través del LSP. En la salida se incluye un valor de etiqueta ( MPLS Label=100016 ), el valor del período de vida ( TTL=1 ) y el valor de bit de la pila ( S=1 ).

El MPLS Label campo se utiliza para identificar el paquete para un LSP determinado. Se trata de un campo de 20 bits, con un valor máximo de (2 ^ ^ 20-1), aproximadamente 1 millón.

El valor de período de vida (TTL) contiene un límite para el número de saltos que este paquete MPLS puede atravesar en la red (1). Se reduce en cada salto y, si el valor TTL cae por debajo de uno, se descarta el paquete.

La parte inferior del valor del bit de la 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 del 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 acerca de la pila de etiquetas de MPLS, consulte RFC 3032, MPLS la codificación de etiquetas de etiqueta.

MPLS aparecen etiquetas en el resultado de la muestra traceroute , ya que el comando se emite a un BGP destino donde el BGP siguiente salto de esa ruta es la dirección de salida de LSP. El Junos OS utiliza de forma predeterminada el LSP para el tráfico de BGP cuando el BGP siguiente salto es la dirección de salida de LSP.

Si el BGP siguiente salto no es igual a la dirección de salida de LSP, el tráfico BGP no utiliza el LSP y, consecuentemente, MPLS etiquetas no aparecen en la salida del traceroute comando, tal y como se indica en el resultado de ejemplo, en check BGP Sessions.

Mostrar paquetes de BGP enviados o recibidos

Intervención

Para configurar el seguimiento de paquetes de protocolo de BGP enviados o recibidos, siga estos pasos:

  1. En el modo de configuración, vaya al siguiente nivel de jerarquía:

  2. Configure el indicador para que muestre la información enviada, recibida o enviada y recibida del paquete:

    o

    o

  3. Compruebe la configuración:

    Por ejemplo:

    o

    o

  4. Confirme la configuración:

  5. Vea el contenido del archivo que contiene los mensajes detallados:

    Por ejemplo:

Descripción de rutas ocultas

Las rutas ocultas son rutas que el dispositivo no puede utilizar por motivos como un salto siguiente no válido o una directiva de enrutamiento que rechaza las rutas.

Nota:

Si una ruta es completamente no válida, la ruta no se coloca en la tabla de enrutamiento como una ruta candidata y ni siquiera aparece como oculta.

A continuación, se muestran algunos comandos útiles para ver y solucionar problemas de rutas ocultas:

Las rutas pueden ocultarse por las siguientes razones:

  • Una directiva de importación rechaza la ruta.

  • No se puede resolver el siguiente salto con la regla de resolución de saltos indirecto actual. Dado que los protocolos de enrutamiento, como los BGP internos (IBGP) pueden enviar información de enrutamiento acerca de rutas conectadas indirectamente, Junos OS se basa en las rutas de protocolos de enrutamiento intra-AS (OSPF, IS-IS, RIP y Static) para resolver el mejor próximo salto conectado directamente. El motor de enrutamiento realiza la resolución de la ruta para determinar cuál es el mejor salto directamente conectado e instala la ruta a la motor de reenvío de paquetes.

  • Una política de amortiguación suprime la ruta.

  • La ruta AS contiene atributos de la Confederación ilegales o no válidos.

  • La dirección del próximo salto es la dirección del dispositivo de enrutamiento local.

  • La ruta AS contiene atributos transitivos ilegales o no válidos.

  • La ruta AS está vacía. Esto solo se aplica a EBGP. Para IBGP, una ruta vacía AS es normal.

  • La ruta AS contiene un cero.

  • La dirección del próximo salto es una dirección de multidifusión.

  • La dirección del próximo salto es una dirección local de vínculo IPv6.

  • El prefijo de ruta o el próximo salto de ruta es una dirección Martian.

  • Se produce un error en la sesión LDP (Protocolo de distribución de etiquetas). Las rutas recibidas no se instalan en la tabla de enrutamiento hasta que el enrutador del mismo nivel restablece la sesión LDP.

Examinar rutas de la tabla de reenvío

Purpose

Cuando tenga problemas, como problemas de conectividad, es posible que tenga que examinar las rutas de la tabla de reenvío para comprobar que el proceso del Protocolo de enrutamiento ha retransmitido la información correcta a la tabla de reenvío.

Intervención

Para mostrar el conjunto de rutas instaladas en la tabla de reenvío, escriba el siguiente comando de Junos OS modo operativo de CLI:

Resultados de ejemplo

nombre de comando

Efectos

El resultado del ejemplo muestra los prefijos de capa de red y sus próximos saltos instalados en la tabla de reenvío. La salida incluye la misma información del próximo salto, como en show route detail el comando (la dirección de salto siguiente y el nombre de interfaz). Entre la información adicional se 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 próximo salto. (La base de datos interna contiene información adicional utilizada por el motor de reenvío de paquetes para garantizar una encapsulación correcta de los paquetes enviados por 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 indicadores y tipos, consulte la Guía del usuario de directivas de enrutamiento, filtros de firewalls y políticas de tráfico.

Ejemplo Reemplazar la Directiva de enrutamiento BGP predeterminada en enrutadores de transporte de paquetes serie PTX

En este ejemplo se muestra cómo reemplazar la Directiva de enrutamiento predeterminada en enrutadores de transporte de paquetes, como el serie PTX enrutadores de transporte de paquetes.

Aplicables

Este ejemplo requiere Junos OS versión 12,1 o posterior.

Descripción general

De forma predeterminada, los enrutadores serie PTX no instalan rutas BGP en la tabla de reenvío.

En el caso de los enrutadores serie PTX from protocols bgp , la configuración then accept de la condición con la acción no tiene el resultado habitual de que tenga en otros dispositivos de enrutamiento Junos os. Con la siguiente directiva de enrutamiento en serie PTX enrutadores, BGP rutas no se instalan en la tabla de reenvío.

No hay ninguna ruta BGP instalada en la tabla de reenvío. Éste es el comportamiento esperado.

En este ejemplo, se muestra cómo then install-to-fib utilizar la acción para reemplazar eficazmente la Directiva de enrutamiento BGP predeterminada.

Automática

Configuración rápida de CLI

Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, quite los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, a continuación, copie y [edit] pegue los comandos en la CLI en el nivel de jerarquía.

Instalación de rutas de BGP seleccionadas en la tabla de reenvío

Procedimiento paso a paso

El ejemplo siguiente requiere que se exploren varios niveles en la jerarquía de configuración. Para obtener más información sobre 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 CLI de Junos os.

Para instalar las rutas de BGP seleccionadas en la tabla de reenvío:

  1. Configure una lista de prefijos para instalar en la tabla de reenvío.

  2. Configure la Directiva de enrutamiento, aplicando la lista de prefijos como condición.

  3. Aplique la Directiva de enrutamiento a la tabla de reenvío.

Resultados

Desde el modo de configuración, escriba los show policy-options comandos y show routing-options para confirmar la configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones de este ejemplo para corregir la configuración.

Si ha terminado de configurar el dispositivo, entre commit en el modo de configuración.

Comproba

Confirme que la configuración funciona correctamente.

Comprobando que la ruta seleccionada está instalada en la tabla de reenvío

Purpose

Asegúrese de que la Directiva configurada invalida la directiva predeterminada.

Intervención

En modo operativo, escriba el show route forwarding-table comando.

Efectos

Esta salida muestra que la ruta a 66.0.0.1/32 está instalada en la tabla de reenvío.

Eventos de transición de estado de BGP del registro

Purpose

Las transiciones de estado del Protocolo de puerta de enlace de borde (BGP) indican un problema de red y deben registrarse y investigarse.

Intervención

Para BGP registrar los sucesos de transición de estado en el registro del sistema, siga estos pasos:

  1. En el modo de configuración, vaya al siguiente nivel de jerarquía:

  2. Configure el registro del sistema:

  3. Compruebe la configuración:

  4. Confirme la configuración:

Efectos

Los mensajes de registro de los eventos de transición del estado de BGP son suficientes para diagnosticar la mayoría de los problemas de las sesiones BGP. Tabla 3 enumera y describe los seis Estados de una sesión de BGP.

Tabla 3: Seis Estados de una sesión de BGP

BGP estado

Descripción

Idle

Éste es el primer estado de una conexión. BGP espera un evento de inicio Iniciado por un administrador. El evento de inicio podría ser el establecimiento de una BGP sesión 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 connect-retry, inicia una conexión de transporte TCP e inicia la escucha de las conexiones iniciadas por los interlocutores remotos. A continuación, BGP pasa a un Connect Estado.

Si hay errores, BGP retrocede al Idle Estado.

Connect

BGP espera a que finalice la conexión del Protocolo de transporte. Si la conexión de transporte TCP se realiza correctamente, el estado cambia a OpenSent .

Si la conexión de transporte no se realiza correctamente, el estado cambia a Active .

Si el temporizador connect-retry ha expirado, 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 elemento del mismo nivel iniciando una conexión de protocolo de transporte.

Si se realiza correctamente, el estado cambia a OpenSent .

Si se agota el temporizador connect-retry, el BGP reinicia el temporizador de conexión y retrocede al Connect Estado. BGP sigue escuchando una conexión que se puede iniciar desde otro igual. El estado puede volver a Idle en caso de otros eventos, como un evento de detención.

En general, un disquete con volteo de estado vecino entre Connect y Active es una indicación de que hay un problema con la conexión de transporte TCP. Un problema de este tipo podría ser ocasionado por muchas retransmisiones de TCP o por la incapacidad de un vecino en alcanzar la dirección IP de su interlocutor.

OpenSent

BGP recibe un mensaje abierto de su interlocutor. En el OpenSent Estado, 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 se comprueba si es correcto. En caso de que se produzcan errores, como un número de versión incorrecto de una AS inaceptable, BGP envía un mensaje de notificación de error y vuelve al Idle .

En el caso de otros errores, como la caducidad del temporizador de suspensión o un evento de detención, BGP envía un mensaje de notificación con el código de error correspondiente y retrocede al Idle Estado.

Si no hay errores, BGP envía mensajes de actividad y restablece el temporizador de KeepAlive. En este estado, se negocia el tiempo de conservación. Si el tiempo de espera es 0, los temporizadores de suspensión y keepalive no se reiniciarán.

Cuando se detecta una desconexión de transporte TCP, el estado retrocede a Active .

OpenConfirm

BGP espera un mensaje de notificación o keepalive.

Si se recibe una 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 de KeepAlive, reinicia el temporizador de suspensión (suponiendo que la hora de retención negociada no sea 0).

Si se recibe un mensaje de notificación, el estado retrocede a Idle .

El sistema envía mensajes de KeepAlive periódicos a la velocidad establecida por el temporizador de KeepAlive. En caso de una notificación de desconexión de transporte o en respuesta a un evento de detención, el estado retrocede 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 la Idle .

Established

Este es el estado final de la negociación de vecinos. En este estado, BGP Exchange actualiza ackets con sus homólogos y el temporizador de suspensión se reinicia tras la recepción de un mensaje de actualización o de KeepAlive cuando no se establece en cero.

Si el sistema recibe un mensaje de notificación, el estado retrocede a Idle .

Los mensajes de actualización se comprueban en busca de errores, como atributos que faltan, atributos duplicados, etc. Si se detectan errores, se envía una notificación al par y el estado retrocede a Idle .

BGP vuelve a Idle cuando el temporizador de retención se agota, se recibe una notificación de desconexión del Protocolo de transporte, se recibe un evento de detención o como respuesta a cualquier otro evento.

Para obtener información más detallada acerca de los paquetes del protocolo BGP, configure el seguimiento específico de BGP. Vea lista de comprobación para realizar el seguimiento de las condiciones de error para obtener más información.

Configurar opciones específicas de BGP

Purpose

Si se producen problemas o sucesos inesperados, o si desea diagnosticar problemas de establecimiento BGP, puede ver información más detallada configurando opciones específicas de BGP. También puede configurar el seguimiento para un grupo par BGP o igual específico. Para obtener más información, consulte la Guía de configuración de fundamentos del sistema de Junos.

Mostrar información detallada de protocolos de BGP

Intervención

Para mostrar información de protocolos de BGP detalladamente, siga estos pasos:

  1. En el modo de configuración, vaya al siguiente nivel de jerarquía:

  2. Configure el indicador para que muestre mensajes de protocolo BGP detallado:

  3. Compruebe la configuración:

    Por ejemplo:

  4. Confirme la configuración:

  5. Vea el contenido del archivo que contiene los mensajes detallados:

    Por ejemplo:

Efectos

Tabla 4enumera indicadores de traza específicos de BGP y presenta el resultado de ejemplo para algunos de los indicadores. También puede configurar el seguimiento para un grupo par BGP o igual específico. Para obtener más información, consulte la Guía de configuración de fundamentos del sistema de Junos.

Tabla 4: BGP indicadores de seguimiento de protocolo

Indicadores de traza

Descripción

Resultados de ejemplo

aspath

Operaciones de expresiones regulares de ruta de acceso

No está 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 de BGP keepalive

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

BGP paquetes abiertos

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 del 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 BGP problemas de establecimiento de sesión

Purpose

Para trazar BGP problemas de establecimiento de sesión.

Intervención

Para trazar BGP problemas de establecimiento de sesión, siga estos pasos:

  1. En el modo de configuración, vaya al siguiente nivel de jerarquía:

  2. Configure BGP mensajes abiertos:

  3. Compruebe la configuración:

    Por ejemplo:

  4. Confirme la configuración:

  5. Vea el contenido del archivo que contiene los mensajes detallados:

    Por ejemplo:

Configurar opciones específicas de IS-IS

Purpose

Si se producen problemas o sucesos inesperados, o si desea diagnosticar problemas de establecimiento de adyacencias, puede ver información más detallada mediante la configuración de opciones específicas de IS-IS.

Para configurar las opciones IS-IS, siga estos pasos:

Mostrando información detallada de protocolo de is

Intervención

Para hacer un seguimiento de los mensajes IS es detallados, siga estos pasos:

  1. Configure el indicador para mostrar mensajes de protocolo IS detallados.

  2. Compruebe la configuración.

    Por ejemplo:

  3. Confirme la configuración.

  4. Vea el contenido del archivo que contiene los mensajes detallados.

    Por ejemplo:

Efectos

Tabla 5enumera indicadores de traza que se pueden configurar de forma específica para IS IS y presenta el resultado de ejemplo para algunos de los indicadores.

Tabla 5: Indicadores de seguimiento de protocolo IS

Indicadores de traza

Descripción

Resultados de ejemplo

csn

PDU de número de secuencia completo (CSNP)

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

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

Paquete de saludo

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 (LSPs) de estado de conexión

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 IS-IS de protocolo

No está disponible.

psn

Paquetes PDU (PSNP) de números de secuencia parciales

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

Los cálculos de la ruta de acceso 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

Mostrando paquetes de protocolo IS de enviados o recibidos

Para configurar el seguimiento de paquetes de protocolo IS IS IS-IS, sólo para enviar o recibir, siga estos pasos:

  1. Configure el indicador para que muestre paquetes enviados, recibidos o enviados y recibidos.

    o

    o

  2. Compruebe la configuración.

    Por ejemplo:

    o

    o

  3. Confirme la configuración.

  4. Vea el contenido del archivo que contiene los mensajes detallados.

    Por ejemplo:

Analizar las PDU de estado de los vínculos es en detalle

Para analizar las PDU de estado de vínculos de IS en detalle, siga estos pasos:

  1. La configuración de IS-IS Open messages.

  2. Compruebe la configuración.

    Por ejemplo:

  3. Confirme la configuración.

  4. Vea el contenido del archivo que contiene los mensajes detallados.

    Por ejemplo:

Configurar opciones específicas de OSPF

Purpose

Cuando se producen problemas o sucesos inesperados, o si desea diagnosticar OSPF problemas del establecimiento del vecino, puede ver información más detallada mediante la configuración de opciones específicas para OSPF.

Para configurar las opciones del OSPF, siga estos pasos:

Diagnosticar OSPF problemas de establecimiento de sesión

Intervención

Para trazar mensajes de OSPF en detalle, siga estos pasos:

  1. En el modo de configuración, vaya al siguiente nivel de jerarquía:

  2. Configure OSPF mensajes de saludo:

  3. Compruebe la configuración:

    Por ejemplo:

  4. Confirme la configuración:

  5. Vea el contenido del archivo que contiene los mensajes detallados:

    Por ejemplo:

Efectos

Tabla 6enumera OSPF indicadores de traza y presenta el resultado de ejemplo para algunos de los indicadores.

Tabla 6: OSPF indicadores de seguimiento de protocolo

Indicadores de traza

Descripción

Resultados de ejemplo

database-descripttion

Todos los paquetes de descripción de 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 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 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 saturación del estado de vínculos

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 saludo

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.29 -> 224.0.0.5 (so-1/1/0.0) Dec 2 15:57:28 Version 2, length 48, ID 10.10.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 del estado de vínculos

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 del estado de vínculos

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 de OSPF

No está disponible.

packet-dump

Volcar el contenido de los tipos de paquetes seleccionados

No está disponible.

spf

Cálculos 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. 134.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 10.10.134.12 distance 1 to SPF list Dec 2 16:08:04 IP nexthop so-1/1/1.0 0.0.0.0

Análisis detallado de OSPF paquetes de anuncio de estado de enlace

Intervención

Para analizar de forma detallada OSPF paquetes de anuncios de estado de enlace, siga estos pasos:

  1. En el modo de configuración, vaya al siguiente nivel de jerarquía:

  2. Configure OSPF paquetes de estado de los vínculos:

  3. Compruebe la configuración:

    Por ejemplo:

  4. Confirme la configuración:

  5. Vea el contenido del archivo que contiene los mensajes detallados:

    Por ejemplo: