Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Esempio di rete

Convenzioni

Istruzione Neighbor Non Corretta

Soluzione

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

Soluzione

Comando update-source mancante in BGP

Soluzione

Informazioni correlate

Introduzione

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 del router adiacente 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 del router adiacente o numero di sistema autonomo errato. È necessario controllare le configurazioni.

- L'unicast viene interrotto per uno dei motivi seguenti:

- 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.

- Il livello 2 è inattivo.

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

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.

Esempio di rete

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

Convenzioni

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

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

Ecco le configurazioni:

R1-AGS

R6-2500

interface Loopback0

ip address 2.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 1.1.1.1 255.255.255.255 10.10.10.2

interface Loopback0

ip address 1.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 2.2.2.2 255.255.255.255 10.10.10.1

I comandi debug ip bgp e debug ip tcp transaction indicano che la connessione TCP non è riuscita.

Debug sul router R1-AGS:

BGP: 10.10.10.2 open active, local address 2.2.2.2

TCB00135978 created

TCB00135978 setting property 0 16ABEA

TCB00135978 bound to 2.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 1.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 2.2.2.2:11039 from 10.10.10.2:179

BGP: 10.10.10.1 open active, local address 1.1.1.1

TCB001E030C created

TCB001E030C setting property TCP_WINDOW_SIZE (0) 194F7A

TCB001E030C setting property TCP_TOS (11) 194F79

TCB001E030C bound to 1.1.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.

R1-AGS

R6-2500

router bgp 400

neighbor 1.1.1.1 remote-as 400

neighbor 1.1.1.1 update-source Loopback0

!

ip route 1.1.1.1 255.255.255.255 10.10.10.2

router bgp 400

neighbor 2.2.2.2 remote-as 400

neighbor 2.2.2.2 update-source Loopback0

!

ip route 2.2.2.2 255.255.255.255 10.10.10.1

Se si controlla il comando show ip bgp summary , il router R1-AGS è in 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

1.1.1.1         4   400       3       3        1    0    0 00:00:26        0

Nota: se non viene stabilita una sessione BGP dopo il ricaricamento di un router, configurare le istruzioni di riconfigurazione soft dei router adiacenti in BGP per il soft reset.

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

1.1.1.1         4   400       0       0        0    0    0 never    Active

Ecco le configurazioni:

R1-AGS

R6-2500

interface Loopback0

ip address 2.2.2.2 255.255.255.255

!

interface Serial1

ip address 10.10.10.1 255.255.255.0

!

router bgp 300

neighbor 1.1.1.1 remote-as 400

neighbor 1.1.1.1 ebgp-multihop 2

neighbor 1.1.1.1 update-source Loopback0

interface Loopback0

ip address 1.1.1.1 255.255.255.255

!

interface Serial0

ip address 10.10.10.2 255.255.255.0

!

router bgp 400

neighbor 2.2.2.2 remote-as 300

neighbor 2.2.2.2 ebgp-multihop 2

neighbor 2.2.2.2 update-source Loopback0

Se si eseguono i comandi di debug, non viene visualizzata alcuna route verso il router adiacente.

Debug sul router R1-AGS:

BGP: 1.1.1.1 open active, delay 9568ms

BGP: 1.1.1.1 multihop open delayed 19872ms (no route)

BGP: 1.1.1.1 multihop open delayed 12784ms (no route)

Debug sul router R6-2500:

BGP: 2.2.2.2 open active, delay 6531ms

BGP: 2.2.2.2 multihop open delayed 14112ms (no route)

BGP: 2.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.

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

Nell'esempio riportato sotto, è stata utilizzata una route statica.

R1-AGS

R6-2500

router bgp 300

neighbor 1.1.1.1 remote-as 400

neighbor 1.1.1.1 ebgp-multihop 2

neighbor 1.1.1.1 update-source Loopback0

!

ip route 1.1.1.1 255.255.255.255 10.10.10.2

router bgp 400

neighbor 2.2.2.2 remote-as 300

neighbor 2.2.2.2 ebgp-multihop 2

neighbor 2.2.2.2 update-source Loopback0

!

ip route 2.2.2.2 255.255.255.255 10.10.10.1

Il comando show ip bgp summary visualizza 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

1.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.

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

1.1.1.1         4   400       0       0        0    0    0 never    Active

Ecco le configurazioni:

R1-AGS

R6-2500

interface Loopback0

ip address 2.2.2.2 255.255.255.255

!

interface Serial1

ip address 10.10.10.1 255.255.255.0

!

router bgp 400

neighbor 1.1.1.1 remote-as 400

!

ip route 1.1.1.1 255.255.255.255 10.10.10.2

interface Loopback0

ip address 1.1.1.1 255.255.255.255

!

interface Serial0

ip address 10.10.10.2 255.255.255.0

!

router bgp 400

neighbor 2.2.2.2 remote-as 400

!

ip route 2.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 2.2.2.2:179

BGP: 1.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 1.1.1.1:179, advertising MSS 536

TCP0: state was CLOSED -> SYNSENT [11042 -> 1.1.1.1(179)]

TCP0: state was SYNSENT -> CLOSED [11042 -> 1.1.1.1(179)]

TCP0: bad seg from 1.1.1.1 -- closing connection: seq 0 ack 4099938542 rcvnxt 0 rcvwnd 0

TCP0: connection closed - remote sent RST

TCB0016B06C destroyed

BGP: 1.1.1.1 open failed: Connection refused by remote host

Debug sul router R6-2500:

BGP: 2.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 2.2.2.2:179, advertising MSS 556

TCP0: state was CLOSED -> SYNSENT [11018 -> 2.2.2.2(179)]

TCP0: state was SYNSENT -> CLOSED [11018 -> 2.2.2.2(179)]

TCP0: bad seg from 2.2.2.2 -- closing connection: seq 0 ack 2248020754 rcvnxt 0 rcvwnd 0

TCP0: connection closed - remote sent RST

TCB 0x194800 destroyed

BGP: 2.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 1.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.

In questo caso, il comando update-source è configurato su entrambi i router.

R1-AGS

R6-2500

interface Loopback0

ip address 2.2.2.2 255.255.255.255

!

interface Serial1

ip address 10.10.10.1 255.255.255.0

!

router bgp 400

neighbor 1.1.1.1 remote-as 400

neighbor 1.1.1.1 update-source Loopback0

!

ip route 1.1.1.1 255.255.255.255 10.10.10.2

interface Loopback0

ip address 1.1.1.1 255.255.255.255

!

interface Serial0

ip address 10.10.10.2 255.255.255.0

!

router bgp 400

neighbor 2.2.2.2 remote-as 400

neighbor 2.2.2.2 update-source Loopback0

!

ip route 2.2.2.2 255.255.255.255 10.10.10.1

Il comando show ip bgp summary visualizza 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

2.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.

In questo caso, il comando update-source viene rimosso e l'istruzione neighbor viene modificata su entrambi i router.

R1-AGS

R6-2500

interface Loopback0

ip address 2.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 1.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 visualizza 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

- Documentazione e supporto tecnico – Cisco Systems