Qual è la differenza tra gli stati di connessione e attivi di BGP?

I peer BGP iniziano in Inattivo stato. Nello stato di inattività, i peer sono stati configurati per formare unadiacenza luno con laltro, ma non hanno ancora avviato o ricevuto alcuna comunicazione.

BGP utilizza TCP come trasporto. Quindi, affinché ci sia un Adiacenza BGP, il primo passo è stabilire una connessione TCP. Sebbene entrambi i peer siano in stato IDLE, tenteranno periodicamente di avviare una connessione TCP a intervalli indipendenti (in base a quando la configurazione del peering BGP è stata effettivamente completata).

Quando un peer avvia lhandshake TCP a tre vie con un SYN, quel peer passa a attivo stato. Questo stato indica che il router locale sta attivamente tentando di avviare una connessione TCP.

Quando laltro peer riceve il TCP SYN dal suo peer, passerà allo stato Connect . Questo stato indica che il router locale ha ricevuto uniniziazione TCP dallaltro router e ha risposto con un SYN ACK.

Da lì, entrambi i peer continuano attraverso gli stati rimanenti: Open Sent, Open Confirmed, Stabilito.

Per riassumere:

• Attivo stato – locale il router ha appena inviato un TCP SYN
• Connect state – router locale ha appena ricevuto un TCP SYN dal suo peer

Le transizioni di stato di “avvio” dellaltoparlante BGP per formare ladiacenza saranno: Idle, Active, Open Sent, Open Received, Established

Le transizioni di stato “rispondente” BGP speaker “per formare ladiacenza saranno: Idle, Connect, Open Sent, Open Received, Established

Notare che solo il peer che ha avviato lhandshake TCP passa attraverso lo stato Active. E solo il peer che NON ha avviato lhandshake TCP passa attraverso lo stato Connect.

Aggiunta di alcuni debug che dimostrano il comportamento. Questo è il codice del router Cisco versione 15.4 (1) T.

Questo è da una sessione di peering BGP tra R1 (9.9.12.1) e R2 (9.9.12.2).

R2 è liniziatore per questa sessione TCP:

router1# show ip bgp neighbors | i ^BGP|host BGP neighbor is 9.9.12.2, remote AS 2323, external link Local host: 9.9.12.1, Local port: 179 Foreign host: 9.9.12.2, Foreign port: 43876 

Confermato sullaltro router:

router2# show ip bgp neighbors | i ^BGP|host BGP neighbor is 9.9.12.1, remote AS 1111, external link Local host: 9.9.12.2, Local port: 43876 Foreign host: 9.9.12.1, Foreign port: 179 

Questo è il debug (filtrato) su R2, liniziatore:

$ cat BGP-Peering_Initiator.txt | grep -e "TCP src" -e "went from" *Oct 28 17:06:36.971: BGP: 9.9.12.1 active went from Idle to Active *Oct 28 17:06:36.972: TCP src=43876, dst=179, seq=1526684246, ack=0, win=16384 SYN *Oct 28 17:06:36.975: TCP src=179, dst=43876, seq=2072809595, ack=1526684247, win=16384 ACK SYN *Oct 28 17:06:36.975: TCP src=43876, dst=179, seq=1526684247, ack=2072809596, win=16384 ACK *Oct 28 17:06:36.977: BGP: 9.9.12.1 active went from Active to OpenSent *Oct 28 17:06:36.982: TCP src=43876, dst=179, seq=1526684247, ack=2072809596, win=16384 ACK PSH *Oct 28 17:06:36.985: TCP src=179, dst=43876, seq=2072809596, ack=1526684304, win=16327 ACK *Oct 28 17:06:36.985: TCP src=179, dst=43876, seq=2072809596, ack=1526684304, win=16327 ACK PSH *Oct 28 17:06:36.985: BGP: 9.9.12.1 active went from OpenSent to OpenConfirm *Oct 28 17:06:36.985: TCP src=43876, dst=179, seq=1526684304, ack=2072809653, win=16327 ACK PSH *Oct 28 17:06:36.987: TCP src=179, dst=43876, seq=2072809653, ack=1526684304, win=16327 ACK PSH *Oct 28 17:06:36.987: BGP: 9.9.12.1 active went from OpenConfirm to Established 

E questo è il debug (filtrato) su R1, il risponditore:

$ cat BGP-Peering_Responder.txt | grep -e "TCP src" -e "went from" *Oct 28 17:06:36.973: TCP src=43876, dst=179, seq=1526684246, ack=0, win=16384 SYN *Oct 28 17:06:36.974: TCP src=179, dst=43876, seq=2072809595, ack=1526684247, win=16384 ACK SYN *Oct 28 17:06:36.976: TCP src=43876, dst=179, seq=1526684247, ack=2072809596, win=16384 ACK *Oct 28 17:06:36.976: BGP: 9.9.12.2 passive went from Idle to Connect *Oct 28 17:06:36.983: TCP src=43876, dst=179, seq=1526684247, ack=2072809596, win=16384 ACK PSH *Oct 28 17:06:36.984: TCP src=179, dst=43876, seq=2072809596, ack=1526684304, win=16327 ACK *Oct 28 17:06:36.984: BGP: 9.9.12.2 passive went from Connect to OpenSent *Oct 28 17:06:36.984: BGP: 9.9.12.2 passive went from OpenSent to OpenConfirm *Oct 28 17:06:36.985: TCP src=179, dst=43876, seq=2072809596, ack=1526684304, win=16327 ACK PSH *Oct 28 17:06:36.986: TCP src=179, dst=43876, seq=2072809653, ack=1526684304, win=16327 ACK PSH *Oct 28 17:06:36.986: TCP src=43876, dst=179, seq=1526684304, ack=2072809653, win=16327 ACK PSH *Oct 28 17:06:36.986: BGP: 9.9.12.2 passive went from OpenConfirm to Established 

Commenti

• In realtà hai gli stati Attivo e Connetti allindietro. Ad esempio, lRFC dice questo sullo stato attivo: " Stato attivo: in questo stato, BGP FSM sta tentando di acquisire un peer ascoltando e accettare una connessione TCP. " Inoltre, " Stato di connessione: in questo stato, BGP FSM sta aspettando che la connessione TCP sia completata. " Dopo aver inviato il TCP SYN.
• Ciao @RonMaupin. Non ' penso di sì. Mi sono incuriosito dopo averlo scritto e truccato, e questo conferma che gli stati Active / Connect funzionano come li ho descritti. ' cercherò di mettere insieme " pulito " output di debug e di aggiungerlo al risposta.
• @RonMaupin Ho appena aggiunto i debug, vedi sopra. Inoltre, ' sono molto più interessato a ciò che Cisco fa rispetto a ciò che Cisco dice . Sentiti libero di dirmi se vedi / sospetti che ' sto interpretando i debug in modo errato.
• Guardandolo, lunica cosa che vedo è che il risponditore è andato da Idle a Connect dopo il completamento della connessione TCP. Nella mia risposta ho detto che era dopo aver inviato il SYN / ACK. Sembra che effettivamente transiti dopo aver ricevuto lACK finale.
• Interpreterei la riga " 28 ottobre 17: 06: 36.971: BGP: 9.9.12.1 attivo andato da Idle ad Active " mentre R1 sta passando da Idle ad Active. Poiché R2 sta avviando la sessione TCP, ciò confermerebbe la visualizzazione di @RonMaupins.

TCP crea una connessione tra due peer e BGP utilizza TCP. Un peer TCP proverà a connettersi allaltro peer TCP e questo è lo stato connect.Un peer può ascoltare una connessione (specialmente dopo un tentativo di connessione fallito da parte sua), e questo è lo stato active.

BGP ha diversi stati e ognuno è chiaramente documentato in RFC 4271, A Border Gateway Protocol 4 (BGP-4) . Le descrizioni degli stati e del passaggio da uno allaltro (e / o viceversa) sono davvero troppo ampie per essere discusse qui. Di seguito unimmagine che descrive la BGP Finite State Machine (FSM):

La RFC ha una descrizione completa dei vari stati della FSM e di ciò che accade in ogni fase .

A partire dallo stato Idle, quando si verifica un evento ManualStart o AutomaticStart sul sistema, cambia il suo stato in Connect, ma le versioni passive di quegli eventi (ManualStart_with_PassiveTcpEstablishment o AutomaticStart_with_PassiveTcpEstablishment) si verificano, quindi cambia il suo stato in Active. Fondamentalmente, quando gli viene detto di connettersi a un peer, cambia in Connect, ma quando gli viene detto di ascoltare un peer, cambia in Active.

Nello stato Connect, se la connessione TCP fallisce, cambia il suo stato in Attivo per ascoltare una connessione dal peer.

Quando si trova nello stato Attivo e si verifica levento ConnectRetryTimer_Expires, prova la connessione TCP e passa allo stato Connetti.

Cè davvero molto di più, ma è troppo grande per un sito come questo.