Sesión eBGP del Troubleshooting pegada en el estado activo

Opciones de descarga

PDF (214.3 KB)
Visualice con Adobe Reader en una variedad de dispositivos
ePub (175.3 KB)
Visualice en diferentes aplicaciones en iPhone, iPad, Android, Sony Reader o Windows Phone
Mobi (Kindle) (146.8 KB)
Visualice en dispositivo Kindle o aplicación Kindle en múltiples dispositivos

Actualizado:24 de septiembre de 2018

ID del documento:213710

Acerca de la traducción

Acerca de esta traducción

Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).

Contenido

Introducción

prerrequisitos

Requisitos

Componentes Utilizados

Problema

Escenario 1 - EBGP Multihop con el cambio de la topología

Escenario 2 - eBGP con el cambio de la dirección de origen de la actualización

Solución

Mejora en la versión XR

Información Relacionada

Introducción

Este documento describe cómo resolver problemas el eBGP (Border Gateway Protocol externo) cuando la sesión se pega en el estado activo debido a las entradas incorrectas LPTS (servicios de transporte del paquete local).

Contribuido por Guillermo Xu, ingeniero de Cisco TAC.

Prerrequisitos

Requisitos

Cisco recomienda que tenga conocimiento sobre estos temas:

BGP
TCP
LPTS para IOS XR

Componentes Utilizados

La información en este documento se basa en (la agregación mantiene al router) las Plataformas ASR9000.

La información de este documento se originó a partir de dispositivos dentro de un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si su red está viva, asegúrese de que usted entienda el impacto potencial de los comandos any.

Problema

Cuando usted configura el eBGP, la sesión se puede pegar en el active indefinidamente si:

No hay comando update-source configurado
Hay un cambio de la topología que hace el tráfico tomar una diversa trayectoria

Estos síntomas presentes en que ocurre este problema:

Los IP address son accesibles
Ambos peeres BGP siguen pegados en el active
La captura de paquetes muestra que el Routers envía muchas restauraciones TCP
el error de la traza tcp de la demostración indica este error para las sesiones de BGP.

Feb 18 09:32:15.393 tcp/error 0/RSP0/CPU0 t9  Lpts set the drop flag for 179 -> 5368, drop packet (pak 0xb1cf80f3) and send a RST

En resumen, la causa raíz del problema es que las entradas LPTS no son puestas al día por el cambio de la encaminamiento y de la expedición. Significa que permanecen en un estado añejo después de los cambios de la topología.

Hay algunas mejoras hechas para el BGP. Estos dos escenarios cubren más detalle sobre este problema.

Note: el iBGP (Internal Border Gateway Protocol) no golpea normalmente este problema puesto que la actualización-fuente se utiliza siempre.

Escenario 1 - EBGP Multihop con el cambio de la topología

Usted puede construir a las sesiones eBGP multihop entre ASR9K-1 y ASR9K-3. Los IP Address de Peer son 172.123.1.1 y 172.123.2.2 en las interfaces físicas. No hay comando update-source configurado. Con la topología actual, la sesión permanece en el estado activo. Se espera esto porque ambo Routers utilizará la interfaz en la subred 172.123.3.0/24 como la interfaz de egreso.

Usted puede apagar el link directo entre ASR9K-1 y ASR9K-3. Entonces, las direcciones de peer son accesibles vía ASR9K-2 que sea el link multihop, así el ping es acertado. Las dirección IP de origen hacen juego en los ambos extremos, pero la sesión de BGP todavía está en un estado activo.

Cuando configuran a los vecinos BGP, las entradas LPTS se crean según la tabla CEF (Cisco Express Forwarding). Para ASR9K-1, la dirección IP 172.123.2.2 es accesible vía la subred 172.123.3.0/24. Por lo tanto, las entradas pertinentes en LPTS están disponibles. Permite que el vecino BGP conecte el puerto 179 con el IP Address local 172.123.3.1. Puesto que intenta iniciar a una sesión TCP del puerto local 26036, usted puede ver otra entrada para ella.

ASR9K-1:
========
ASR9K-1#show lpts ifib entry brief | inc "BGP"
...
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.1,179 172.123.2.2
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.1,26036 172.123.2.2,179

Esta salida es lo mismo en el ASR9K-3.

ASR9K-3:
========
ASR9K-3#show lpts ifib entry brief | inc "BGP"
...
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.2,11126 172.123.1.1,179
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.2,179 172.123.1.1

Cuando va el link entre ASR9K-1 y ASR9K-3 abajo, los pares son accesibles vía la trayectoria ASR9K-2 con una nueva dirección IP de origen local. Pero el cambio de la topología no acciona la actualización LPTS. La entrada original con el puerto 179 permanece con el IP Address local original. Esto previene al router para permitir las peticiones del ingreso TCP al nuevo IP Address local. Por lo tanto, la sesión de BGP en los ambos extremos sigue pegada en un estado activo.

Escenario 2 - eBGP con el cambio de la dirección de origen de la actualización

Usted puede desplegar a una sesión eBGP entre ASR9K-1 y ASR9K-3. Los IP Addresses son 172.123.3.1 y 172.123.3.2. Según el nuevo plan, usted cambió los IP Addresses a 172.123.3.111 y a 172.123.3.222. Si usted configura el eBGP primero y en seguida pone al día los IP Addresses en las interfaces, pegan a la sesión eBGP en un estado activo.

La causa es lo mismo que el escenario 1. Una vez que usted configura a la sesión eBGP, las entradas LPTS se generan según la interfaz de egreso local en ese momento.

ASR9K-1:
========
ASR9K-1#show lpts ifib entry brief | inc "BGP"
...
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.1,179 172.123.3.222
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.1,24067 172.123.3.222,179

ASR9K-3:
========
ASR9K-3#show lpts ifib entry brief | inc "BGP"
...
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.2,45091 172.123.3.111,179
BGP4 default TCP any 0/RSP1/CPU0 172.123.3.2,179 172.123.3.111

Aunque los IP Address locales fueran cambiados más adelante, las entradas LPTS no son actualizadas. Se bloquea la petición TCP y la sesión sigue pegada en un estado activo para siempre.

Solución

Para solucionar este problema, usted necesita accionar una actualización a LPTS. Usted puede utilizar estas opciones para resolver el problema:

Shut/No cerró a los vecinos BGP
Reconfiguración de los vecinos BGP
BGP de proceso del reinicio
Configure la actualización-fuente en los ambos extremos que pueden prevenir este problema.

Mejora en la versión XR

Hay algunas mejoras en las versiones recientes IOS XR.

CSCuz51103 - Sesión de BGP pegada en el active

Esta mejora introducida de la versión 6.1.1 XR. En esta versión, cuando el BGP intenta restablecer la sesión, LPTS pone al día sus entradas con el nuevo IP Address local. La hora de actualización depende de la configuración del tiempo en espera en los ambos extremos. Usted puede todavía esperar a veces para ver la sesión para arriba.

Incluso con esta mejora, una sesión de BGP todavía puede ser pegada en un estado activo si usted ha configurado al modo pasivo. La razón es obvia. Si el BGP no intenta restablecer la sesión, el IP Address local no se marca. Por lo tanto las entradas LPTS no son actualizadas.

Hay otra mejora para esta situación de la versión 6.2.1 XR.

CSCvb15128- la sesión de BGP se pegó en el active mientras que el router hace el modo pasivo BGP configurar