Resolución de Problemas de Sesión eBGP Bloqueada en Estado Activo

Introducción

Este documento describe cómo resolver problemas de eBGP (External Border Gateway Protocol) cuando la sesión se bloquea en estado activo debido a entradas incorrectas de LPTS (Local Packet Transport Services).

Colaboración de William Xu, ingeniero del TAC de Cisco.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• BGP
• TCP
• LPTS para IOS XR

Componentes Utilizados

La información de este documento se basa en las plataformas ASR9000 (Aggregation Services Router).

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á activa, asegúrese de comprender el impacto potencial de cualquier comando.

Problema

Al configurar eBGP, la sesión puede permanecer indefinidamente en estado activo si:

• No hay ningún comando update-source configurado
• Hay un cambio de topología que hace que el tráfico tome un trayecto diferente

Estos síntomas se presentan cuando ocurre este problema:

• Las direcciones IP son accesibles
• Ambos peers BGP permanecen atascados en activo
• La captura de paquetes muestra que los routers envían muchos reinicios de TCP
• show tcp trace error indica este error para las sesiones 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 se actualizan por el cambio de ruteo y reenvío. Esto significa que permanecen en un estado obsoleto después de que cambia la topología.

Se han realizado algunas mejoras para BGP. Estos dos escenarios cubren más detalles sobre este problema.

Nota: iBGP (Internal Border Gateway Protocol) normalmente no llega a este problema ya que update-source siempre se utiliza.

Situación 1: EBGP multisalto con cambio de topología

Puede crear sesiones eBGP multisalto entre ASR9K-1 y ASR9K-3. Las direcciones IP de peer son 172.123.1.1 y 172.123.2.2 en las interfaces físicas. No hay ningún comando update-source configurado. Con la topología actual, la sesión permanece en el estado activo. Esto se espera porque ambos routers utilizarán la interfaz en la subred 172.123.3.0/24 como la interfaz de egreso.

Puede cerrar el vínculo directo entre ASR9K-1 y ASR9K-3. Luego, las direcciones de peer son alcanzables a través de ASR9K-2 que es el link multisalto, por lo tanto el ping es exitoso. Las direcciones IP de origen coinciden en ambos extremos, pero la sesión BGP aún se encuentra en estado activo.

Cuando se configuran los vecinos BGP, las entradas LPTS se crean de acuerdo con la tabla CEF (Cisco Express Forwarding). Para ASR9K-1, la dirección IP 172.123.2.2 se puede alcanzar a través de la subred 172.123.3.0/24. Por lo tanto, se dispone de las entradas pertinentes en los LPTS. Permite que el vecino BGP conecte el puerto 179 con la dirección IP local 172.123.3.1. Dado que intenta iniciar una sesión TCP desde el puerto local 26036, puede ver otra entrada para él.

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

Este resultado es el 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 el link entre ASR9K-1 y ASR9K-3 deja de funcionar, los peers son accesibles a través de la trayectoria de ASR9K-2 con una nueva dirección IP de origen local. Pero el cambio de topología no activa la actualización de LPTS. La entrada original con el puerto 179 permanece con la dirección IP local original. Esto evita que el router permita el ingreso de solicitudes TCP a la nueva dirección IP local. Por lo tanto, la sesión BGP en ambos extremos permanece atascada en un estado activo.

Situación 2: eBGP con cambio de dirección de origen de actualización

Puede implementar una sesión eBGP entre ASR9K-1 y ASR9K-3. Las direcciones IP son 172.123.3.1 y 172.123.3.2. Según el nuevo plan, cambió las direcciones IP a 172.123.3.111 y 172.123.3.222. Si configura eBGP primero y luego actualiza las direcciones IP en las interfaces, la sesión EBGP se bloquea en un estado activo.

La causa es la misma que en el escenario 1. Una vez configurada la sesión eBGP, las entradas LPTS se generan según la interfaz de salida local en ese punto.

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 las direcciones IP locales se cambiaron más tarde, las entradas LPTS no se actualizan. La solicitud TCP se bloquea y la sesión permanece bloqueada en estado activo para siempre.

Solución

Para resolver este problema, debe activar una actualización de LPTS. Puede utilizar estas opciones para resolver el problema:

• Shut/No shut los vecinos BGP
• Reconfiguración de los vecinos BGP
• Reiniciar proceso bgp
• Configure update-source en ambos extremos para evitar este problema.

Mejora en la versión XR

Hay algunas mejoras en las últimas versiones de IOS XR.

CSCuz51103 - Sesión BGP bloqueada en activo

Esta mejora se introdujo desde la versión 6.1.1 de XR. En esta versión, cuando BGP intenta restablecer la sesión, LPTS actualiza sus entradas con la nueva dirección IP local . El tiempo de actualización depende de la configuración del tiempo de espera en ambos extremos. A veces puede esperar a ver la sesión activa.

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

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

CSCvb15128: sesión BGP bloqueada en activo mientras el router tiene configurado el modo BGP pasivo

Información Relacionada

• ASR9000/XR: CoPP de servicios de transporte de paquetes locales (LPTS) (políticas del plano de control)
• Guía de configuración: implementación de LPTS
• Guía de configuración: Implementación de BGP

---