Risoluzione dei problemi relativi alla sessione eBGP bloccata nello stato attivo

Introduzione

In questo documento viene descritto come risolvere i problemi di eBGP (External Border Gateway Protocol) quando la sessione è bloccata in stato attivo a causa di voci LPTS (Local Packet Transport Services) errate.

Contributo di William Xu, Cisco TAC Engineer.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• BGP
• TCP
• LPTS per IOS XR

Componenti usati

Le informazioni fornite in questo documento si basano sulle piattaforme ASR9000 (Aggregation Services Router).

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Problema

Quando si configura eBGP, la sessione può rimanere indefinitamente attiva se:

• Nessun comando update-source configurato
• Modifica della topologia che determina un percorso diverso per il traffico

Questi sintomi si manifestano quando si verifica il problema:

• gli indirizzi IP sono raggiungibili
• Entrambi i peer BGP rimangono bloccati in stato attivo
• L'acquisizione dei pacchetti mostra che i router inviano molti reset TCP
• show tcp trace error indica questo errore per le sessioni 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

In sintesi, la causa principale del problema è che le voci LPTS non vengono aggiornate in base alla modifica apportata al routing e all'inoltro. Significa che rimangono in uno stato obsoleto dopo le modifiche della topologia.

Sono stati apportati alcuni miglioramenti a BGP. In questi due scenari vengono fornite informazioni più dettagliate su questo problema.

Nota: iBGP (Internal Border Gateway Protocol) normalmente non risolve questo problema, in quanto viene sempre utilizzato update-source.

Scenario 1 - Multihop EBGP con modifica della topologia

È possibile creare sessioni eBGP multihop tra ASR9K-1 e ASR9K-3. Gli indirizzi IP dei peer sono 172.123.1.1 e 172.123.2.2 nelle interfacce fisiche. Non è configurato alcun comando update-source. Con la topologia corrente, la sessione rimane nello stato attivo. Questa condizione si verifica perché entrambi i router utilizzeranno l'interfaccia nella subnet 172.123.3.0/24 come interfaccia di uscita.

È possibile arrestare il collegamento diretto tra ASR9K-1 e ASR9K-3. Quindi, gli indirizzi dei peer sono raggiungibili tramite ASR9K-2, che è il collegamento multihop, quindi il ping ha esito positivo. Gli indirizzi IP di origine corrispondono a entrambe le estremità, ma la sessione BGP è ancora in uno stato attivo.

Quando si configurano i router BGP adiacenti, le voci LPTS vengono create in base alla tabella CEF (Cisco Express Forwarding). Per ASR9K-1, l'indirizzo IP 172.123.2.2 è raggiungibile tramite la subnet 172.123.3.0/24. Sono pertanto disponibili le voci pertinenti dell’LPTS. Consente al router adiacente BGP di collegare la porta 179 all'indirizzo IP locale 172.123.3.1. Poiché tenta di avviare una sessione TCP dalla porta locale 26036, è possibile visualizzare un'altra voce.

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

Questo output è lo stesso in 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

Quando il collegamento tra ASR9K-1 e ASR9K-3 diventa inattivo, i peer sono raggiungibili tramite il percorso ASR9K-2 con un nuovo indirizzo IP di origine locale. Tuttavia, la modifica della topologia non attiva l'aggiornamento LPTS. La voce originale con porta 179 rimane con l'indirizzo IP locale originale. In questo modo il router non potrà consentire le richieste TCP in entrata al nuovo indirizzo IP locale. Pertanto, la sessione BGP a entrambe le estremità rimane bloccata in uno stato attivo.

Scenario 2 - eBGP con modifica indirizzo di origine aggiornamento

È possibile distribuire una sessione eBGP tra ASR9K-1 e ASR9K-3. Gli indirizzi IP sono 172.123.3.1 e 172.123.3.2. In base al nuovo piano, gli indirizzi IP sono stati modificati in 172.123.3.111 e 172.123.3.222. Se prima si configura eBGP e poi si aggiornano gli indirizzi IP sulle interfacce, la sessione EBGP è bloccata in uno stato attivo.

La causa è la stessa dello scenario 1. Una volta configurata la sessione eBGP, le voci LPTS vengono generate in base all'interfaccia di uscita locale in quel 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

Anche se gli indirizzi IP locali sono stati modificati in seguito, le voci LPTS non vengono aggiornate. La richiesta TCP è bloccata e la sessione rimane bloccata in uno stato attivo per sempre.

Soluzione

Per risolvere questo problema, è necessario attivare un aggiornamento di LPTS. Per risolvere il problema, è possibile utilizzare le seguenti opzioni:

• Chiudi/No arresta i vicini BGP
• Riconfigurazione dei vicini BGP
• Riavvia processo bgp
• Configurare update-source su entrambe le estremità per evitare il problema.

Miglioramento nella release XR

Nelle versioni più recenti di IOS XR sono stati apportati alcuni miglioramenti.

CSCuz51103 - Sessione BGP bloccata in attiva

Questo miglioramento è stato introdotto da XR release 6.1.1. In questa release, quando BGP tenta di ristabilire la sessione, LPTS aggiorna le sue voci con il nuovo indirizzo IP locale . Il tempo di aggiornamento dipende dalla configurazione del tempo di attesa su entrambe le estremità. A volte è ancora possibile attendere per vedere la sessione attiva.

Anche con questo miglioramento, una sessione BGP può comunque essere bloccata in uno stato attivo se è stata configurata la modalità passiva. La ragione è ovvia. Se BGP non tenta di ristabilire la sessione, l'indirizzo IP locale non viene controllato. Pertanto, le voci LPTS non vengono aggiornate.

La release 6.2.1 di XR prevede un altro miglioramento per questa situazione.

CSCvb15128 - Sessione BGP bloccata in attiva mentre per il router è configurata la modalità BGP passiva

Informazioni correlate

• ASR 9000/XR: Local Packet Transport Services (LPTS) CoPP (Control Plane Policing)
• Guida alla configurazione : Implementazione di LPTS
• Guida alla configurazione: implementazione di BGP

---