Risoluzione dei problemi di connessione delle risorse BGP

Introduzione

Questo documento descrive i problemi che impediscono la corretta definizione del vicinato BGP.

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

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.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Premesse

I router BGP possono scambiare informazioni di routing solo quando tra di essi viene stabilita una connessione peer. La determinazione del peer BGP inizia con la creazione di una connessione TCP tra i dispositivi. Dopo aver stabilito la connessione TCP, i dispositivi BGP tentano di creare una sessione BGP tramite lo scambio di messaggi BGP Open, dove scambiano la versione BGP, il numero AS, il tempo di attesa e l'identificatore BGP.

Sul processo di peer establishment BGP, diverse cose possono impedire la corretta definizione di un vicinato BGP. In questo documento vengono descritte alcune delle possibili cause di questo problema:

• L'istruzione Neighbor non è corretta.

• Non esistono route per l'indirizzo del router adiacente oppure viene utilizzata la route predefinita (0.0.0.0/0) per raggiungere il peer.

• Comando update-source mancante in BGP.

• Errore di digitazione. Indirizzo IP errato nell'istruzione neighbor o numero di sistema autonomo errato. È necessario controllare le configurazioni.

• L'unicast è danneggiato, alcune delle ragioni sono:

  • Mappatura errata del circuito virtuale (VC) in un ambiente ATM (Asynchronous Transfer Mode) o Frame Relay in una rete altamente ridondante.

  • L'elenco degli accessi blocca il pacchetto unicast o TCP.

  • Network Address Translation (NAT) è in esecuzione sul router e sta traducendo il pacchetto unicast.

  • Livello 2 inattivo.

• La mancanza del comando ebgp-multihop è un errore comune che impedisce ai peer di apparire. La questione è trattata nel secondo esempio.

Esempio di rete

Utilizzare questo diagramma di rete come esempio per le prime tre cause:

Esempio di rete

Problema

Istruzione Neighbor Non Corretta

Il comando show ip bgp summary sul router R1-AGS mostra che la sessione è attiva.

R1-AGS(9)#show ip bgp summary

BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.2      4   400       0       0        0    0    0 never    Active

Le configurazioni sono:

interface Loopback0
 ip address 10.2.2.2 255.255.255.255
!
interface Serial1
 ip address 10.10.10.1 255.255.255.0
!
router bgp 400
 neighbor 10.10.10.2 remote-as 400
 neighbor 10.10.10.2 update-source Loopback0
 !
ip route 10.1.1.1 255.255.255.255 10.10.10.2

interface Loopback0
 ip address 10.1.1.1 255.255.255.255
!
interface Serial0
 ip address 10.10.10.2 255.255.255.0
!
router bgp 400
 neighbor 10.10.10.1 remote-as 400
 neighbor 10.10.10.1 update-source Loopback0
 !
ip route 10.2.2.2 255.255.255.255 10.10.10.1

I comandi debug ip bgp e debug ip tcp transaction mostrano un errore di connessione TCP.

Debug sul router R1-AGS:

BGP: 10.10.10.2 open active, local address 10.2.2.2
TCB00135978 created
TCB00135978 setting property 0 16ABEA
TCB00135978 bound to 10.2.2.2.11039
TCP: sending SYN, seq 3797113156, ack 0
TCP0: Connection to 10.10.10.2:179, advertising MSS 1460
TCP0: state was CLOSED -> SYNSENT [11039 -> 10.10.10.2(179)]
TCP0: state was SYNSENT -> CLOSED [11039 -> 10.10.10.2(179)]
TCP0: bad seg from 10.10.10.2 -- closing connection: seq 0 ack 3797113157 rcvnxt 0 rcvwnd 0
TCP0: connection closed - remote sent RST
TCB00135978 destroyed
BGP: 10.10.10.2 open failed: Connection refused by remote host
TCP: sending RST, seq 0, ack 1965664223
TCP: sent RST to 10.1.1.1:11016 from 10.10.10.1:179

Debug sul router R6-2500:

TCP: sending RST, seq 0, ack 3797113157
TCP: sent RST to 10.2.2.2:11039 from 10.10.10.2:179
BGP: 10.10.10.1 open active, local address 10.1.1.1
TCB001E030C created
TCB001E030C setting property TCP_WINDOW_SIZE (0) 194F7A
TCB001E030C setting property TCP_TOS (11) 194F79
TCB001E030C bound to 10.10.1.1.11016
TCP: sending SYN, seq 1965664222, ack 0
TCP0: Connection to 10.10.10.1:179, advertising MSS 1460
TCP0: state was CLOSED -> SYNSENT [11016 -> 10.10.10.1(179)]
TCP0: state was SYNSENT -> CLOSED [11016 -> 10.10.10.1(179)]
TCP0: bad seg from 10.10.10.1 -- closing connection: seq 0 ack 1965664223 rcvnxt 0 rcvwnd 0
TCP0: connection closed - remote sent RST
TCB 0x1E030C destroyed
BGP: 10.10.10.1 open failed: Connection refused by remote host

Soluzione

Per risolvere questo problema, correggere l'indirizzo di loopback nell'istruzione neighbors o rimuovere il comando update-source dalla configurazione.

Nell'esempio l'indirizzo viene corretto.

router bgp 400
 neighbor 10.1.1.1 remote-as 400
 neighbor 10.1.1.1 update-source Loopback0
 !
ip route 10.1.1.1 255.255.255.255 10.10.10.2

router bgp 400
 neighbor 10.2.2.2 remote-as 400
 neighbor 10.2.2.2 update-source Loopback0
 !
ip route 10.2.2.2 255.255.255.255 10.10.10.1

Se si controlla il comando show ip bgp summary, il router R1-AGS è nello stato stabilito.

R1-AGS(9)#show ip bgp summary

BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.1.1.1         4   400       3       3        1    0    0 00:00:26        0

Problema

Non esistono route all'indirizzo del router adiacente oppure viene utilizzata la route predefinita per raggiungere il peer

Il comando show ip bgp summary sul router R1-AGS mostra la sessione attiva.

R1-AGS(9)#show ip bgp summary

BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.1.1.1         4   400       0       0        0    0    0 never    Active

Le configurazioni sono:

interface Loopback0
 ip address 10.2.2.2 255.255.255.255
!
interface Serial1
 ip address 10.10.10.1 255.255.255.0
!
router bgp 300
 neighbor 10.1.1.1 remote-as 400
 neighbor 10.1.1.1 ebgp-multihop 2
 neighbor 10.1.1.1 update-source Loopback0

interface Loopback0
 ip address 10.1.1.1 255.255.255.255
!
interface Serial0
 ip address 10.10.10.2 255.255.255.0
!
router bgp 400
 neighbor 10.2.2.2 remote-as 300
 neighbor 10.2.2.2 ebgp-multihop 2
 neighbor 10.2.2.2 update-source Loopback0

Se si eseguono i comandi di debug, viene mostrato che non è disponibile alcuna route verso il router adiacente.

Debug sul router R1-AGS:

BGP: 10.1.1.1 open active, delay 9568ms
BGP: 10.1.1.1 multihop open delayed 19872ms (no route)
BGP: 10.1.1.1 multihop open delayed 12784ms (no route)

Debug sul router R6-2500:

BGP: 10.2.2.2 open active, delay 6531ms
BGP: 10.2.2.2 multihop open delayed 14112ms (no route)
BGP: 10.2.2.2 multihop open delayed 15408ms (no route)

Soluzione

La soluzione consiste nell'includere un percorso all'hop successivo nell'istruzione BGP neighbors. È possibile utilizzare una route statica o dinamica a seconda della situazione. In un ambiente BGP (iBGP) interno con un maggiore controllo, la route può essere propagata dinamicamente utilizzando un protocollo di routing. In una situazione BGP (eBGP) esterna, si consiglia di configurare una route statica per raggiungere l'hop successivo.

Nota: utilizzare il comando ebgp-multihop adiacente solo quando l'indirizzo IP a cui si sta eseguendo il peering sul peer eBGP non è connesso direttamente.

Nell'esempio viene utilizzata una route statica.

router bgp 300
 neighbor 10.1.1.1 remote-as 400
 neighbor 10.1.1.1 ebgp-multihop 2
 neighbor 10.1.1.1 update-source Loopback0
 !
ip route 10.1.1.1 255.255.255.255 10.10.10.2

router bgp 400
 neighbor 10.2.2.2 remote-as 300
 neighbor 10.2.2.2 ebgp-multihop 2
 neighbor 10.2.2.2 update-source Loopback0
 !
ip route 10.2.2.2 255.255.255.255 10.10.10.1

Il comando show ip bgp summary mostra che il router R1-AGS è nello stato stabilito.

R1-AGS(9)#show ip bgp summary

BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.1.1.1         4   400       3       3        1    0    0 00:00:26        0

Nota: per stabilire una sessione BGP (iBGP/eBGP) non viene mai utilizzata una route predefinita e nei debug viene visualizzato lo stesso output (nessuna route), anche se è possibile eseguire il ping sul router adiacente BGP. La soluzione è di nuovo aggiungere una route al router adiacente BGP.

Problema

Comando Update-source mancante in BGP

Il comando show ip bgp summary sul router R1-AGS mostra che la sessione è attiva.

R1-AGS(9)#show ip bgp summary

BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.1.1.1         4   400       0       0        0    0    0 never    Active

Le configurazioni sono:

interface Loopback0
 ip address 10.2.2.2 255.255.255.255
!
interface Serial1
 ip address 10.10.10.1 255.255.255.0
!
router bgp 400
 neighbor 10.1.1.1 remote-as 400
!
ip route 10.1.1.1 255.255.255.255 10.10.10.2

interface Loopback0
 ip address 10.1.1.1 255.255.255.255
!
interface Serial0
 ip address 10.10.10.2 255.255.255.0
!
router bgp 400
 neighbor 10.2.2.2 remote-as 400
!
ip route 10.2.2.2 255.255.255.255 10.10.10.1

Se si eseguono i comandi di debug, viene visualizzato un errore di connessione TCP.

Debug sul router R1-AGS:

TCP: sending RST, seq 0, ack 2248020754
TCP: sent RST to 10.10.10.2:11018 from 10.2.2.2:179
BGP: 10.1.1.1 open active, local address 10.10.10.1
TCB0016B06C created
TCB0016B06C setting property 0 16ADEA
TCB0016B06C bound to 10.10.10.1.11042
TCP: sending SYN, seq 4099938541, ack 0
TCP0: Connection to 10.1.1.1:179, advertising MSS 536
TCP0: state was CLOSED -> SYNSENT [11042 -> 10.1.1.1(179)]
TCP0: state was SYNSENT -> CLOSED [11042 -> 10.1.1.1(179)]
TCP0: bad seg from 10.1.1.1 -- closing connection: seq 0 ack 4099938542 rcvnxt 0 rcvwnd 0
TCP0: connection closed - remote sent RST
TCB0016B06C destroyed
BGP: 10.1.1.1 open failed: Connection refused by remote host

Debug sul router R6-2500:

BGP: 10.2.2.2 open active, local address 10.10.10.2
TCB00194800 created
TCB00194800 setting property TCP_WINDOW_SIZE (0) E6572
TCB00194800 setting property TCP_TOS (11) E6571
TCB00194800 bound to 10.10.10.2.11018
TCP: sending SYN, seq 2248020753, ack 0
TCP0: Connection to 10.2.2.2:179, advertising MSS 556
TCP0: state was CLOSED -> SYNSENT [11018 -> 10.2.2.2(179)]
TCP0: state was SYNSENT -> CLOSED [11018 -> 10.2.2.2(179)]
TCP0: bad seg from 10.2.2.2 -- closing connection: seq 0 ack 2248020754 rcvnxt 0 rcvwnd 0
TCP0: connection closed - remote sent RST
TCB 0x194800 destroyed
BGP: 10.2.2.2 open failed: Connection refused by remote host
TCP: sending RST, seq 0, ack 4099938542
TCP: sent RST to 10.10.10.1:11042 from 10.1.1.1:179

Soluzione

Per risolvere il problema, configurare il comando update-source su entrambi i router o rimuovere il comando update-source e modificare l'istruzione adiacente su entrambi i router. Questi sono esempi di entrambe le soluzioni.

Il comando update-source è configurato su entrambi i router:

interface Loopback0
 ip address 10.2.2.2 255.255.255.255
!
interface Serial1
 ip address 10.10.10.1 255.255.255.0
!
router bgp 400
 neighbor 10.1.1.1 remote-as 400
 neighbor 10.1.1.1 update-source Loopback0
 !
ip route 10.1.1.1 255.255.255.255 10.10.10.2

interface Loopback0
 ip address 10.1.1.1 255.255.255.255
!
interface Serial0
 ip address 10.10.10.2 255.255.255.0
!
router bgp 400
 neighbor 10.2.2.2 remote-as 400
 neighbor 10.2.2.2 update-source Loopback0
 !
ip route 10.2.2.2 255.255.255.255 10.10.10.1

Il comando show ip bgp summary mostra che il router R1-AGS è nello stato stabilito.

R1-AGS(9)# 
show ip bgp summary

BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.2.2.2         4   400       3       3        1    0    0 00:00:26        0

È necessario utilizzare il comando update-source solo quando un utente esegue il peering all'indirizzo di loopback. Ciò vale per un peer iBGP e un peer eBGP.

Il comando update-source viene rimosso e l'istruzione neighbor viene modificata su entrambi i router.

interface Loopback0
 ip address 10.2.2.2 255.255.255.255
!
interface Serial1
 ip address 10.10.10.1 255.255.255.0
!
router bgp 400
 neighbor 10.10.10.2 remote-as 400

interface Loopback0
 ip address 10.1.1.1 255.255.255.255
!
interface Serial0
 ip address 10.10.10.2 255.255.255.0
!
router bgp 400
 neighbor 10.10.10.1 remote-as 400

Il comando show ip bgp summary mostra che il router R1-AGS è nello stato stabilito.

R1-AGS(9)#show ip bgp summary

BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.2      4   400       3       3        1    0    0 00:00:26        0

Informazioni correlate

• Pagina di supporto BGP
• Supporto tecnico Cisco e download