Jaký je rozdíl mezi připojením a aktivním stavem BGP?

BGP Peers začíná v Idle stavu. V nečinném stavu byli vrstevníci nakonfigurováni tak, aby vytvářeli vzájemné sousedství, ale dosud nezačali ani nepřijímali žádnou komunikaci.

BGP používá jako svůj přenos protokol TCP. BGP adjacency, prvním krokem je navázání připojení TCP. I když jsou oba partneři ve stavu IDLE, každý se bude pravidelně pokoušet zahájit připojení TCP v nezávislých intervalech (na základě toho, kdy byla konfigurace peeringu BGP skutečně dokončena).

Když jeden peer inicializuje třícestné handshake TCP pomocí SYN, tento peer přechází do Aktivní stav. Tento stav označuje, že se místní router aktivně pokouší navázat TCP spojení.

Když druhý peer přijme TCP SYN z jeho peer, přejde do stavu Connect . Tento stav označuje, že místní směrovač přijal iniciaci TCP od druhého směrovače a odpovídá / odpověděl pomocí SYN ACK.

Odtamtud pokračují oba partneři zbývajícími stavy: Otevřít odeslané, Otevřít potvrzeno, Stanoveno.

Souhrn:

• Aktivní stav – místní router právě poslal stav TCP SYN
• Connect – místní router právě obdržel TCP SYN od svého vrstevníka

Přechody stavu „inicializujícího“ reproduktoru BGP k vytvoření sousedství budou: Idle, Active, Open Sent, Open Received, Established

Přechody stavu „odpovídajícího“ reproduktoru BGP do podoby sousedství budou: Idle, Connect, Open Sent, Open Received, Established

Všimněte si, že pouze partner, který inicioval handshake TCP, projde stavem Active. Stavem Connect prochází pouze peer, který NE inicializoval handshake TCP.

Přidání některých ladicích programů, které dokazují chování. Toto je kód směrovače Cisco verze 15.4 (1) T.

Toto je z peeringové relace BGP mezi R1 (9.9.12.1) a R2 (9.9.12.2).

R2 je iniciátor této relace 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 

Potvrzeno na druhém routeru:

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 

Toto je (filtrovaný) ladění na R2, iniciátor:

$ 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 

A toto je (filtrovaný) ladění na R1, respondér:

$ 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 

Komentáře

• Ve skutečnosti máte stavy Active a Connect zpět. Například The RFC říká toto o aktivním stavu: " Aktivní stav: V tomto stavu se BGP FSM pokouší získat peer nasloucháním pro a přijetí připojení TCP. " Také " Stav připojení: V tomto stavu, BGP FSM čeká na dokončení připojení TCP. " Po odeslání protokolu TCP SYN.
• Ahoj @RonMaupin. Nemyslím si ' že ano. Poté, co jsem to napsal, jsem zvědavý a označil to a potvrzuje to, že stavy Active / Connect fungují, jak jsem je popsal. ' Pokusím se sestavit " čistý " ladit výstup a přidat jej do odpověď.
• @RonMaupin Právě přidal ladění, viz výše. Také mě ' mnohem více zajímá to, co Cisco dělá , než to, co Cisco říká . Klidně mi řekněte, jestli vidíte / máte podezření, že ' interpretuji ladění nesprávně.
• Když se na to podívám, vidím jen to, že respondent šel z nečinnosti na připojení po dokončení připojení TCP. Ve své odpovědi jsem řekl, že to bylo po odeslání SYN / ACK. Zdá se, že to skutečně přechází po obdržení konečné ACK.
• Interpretoval bych řádek " Oct 28 17: 06: 36.971: BGP: 9.9.12.1 active goes z nečinnosti na aktivní ", protože R1 přechází z nečinnosti na aktivní. Protože R2 inicializuje relaci TCP, potvrdilo by to zobrazení @RonMaupins.

TCP vytvoří spojení mezi dvěma partnery a BGP používá TCP. Jeden TCP peer se pokusí připojit k druhému TCP peer, a to je stav connect.Jeden peer může naslouchat připojení (zejména po neúspěšném pokusu o připojení z jeho strany), a toto je stav active.

BGP má několik stavů a každý je jasně zdokumentován v RFC 4271, A Border Gateway Protocol 4 (BGP-4) . Popisy stavů a přesun z jednoho do druhého (a / nebo zpět) jsou opravdu příliš velké na to, abychom je zde diskutovali. Níže je obrázek, který popisuje BGP Finite State Machine (FSM):

RFC má úplný popis různých stavů FSM a toho, co se děje v jednotlivých fázích .

Počínaje stavem nečinnosti, když se v systému stane událost ManualStart nebo AutomaticStart, změní se její stav na Connect, ale dojde k pasivní verzi těchto událostí (ManualStart_with_PassiveTcpEstablishment nebo AutomaticStart_with_PassiveTcpEstablishment), pak změní svůj stav na Active. V zásadě, když je řečeno, že se má připojit k peer, změní se na Connect, ale když se řekne, aby naslouchal peer, změní se na Active.

Ve stavu Connect, pokud připojení TCP selže, změní svůj stav na Aktivní, aby naslouchal připojení od partnera.

Když je v aktivním stavu a dojde k události ConnectRetryTimer_Expires, zkusí připojení TCP a přejde do stavu Připojit.

Ve skutečnosti je toho mnohem víc, ale pro takové stránky je to příliš velké.