Care este diferența dintre conectarea și stările active ale BGP?

Colegii BGP încep în Inactiv stare. În starea de repaus, colegii au fost configurați pentru a forma o adiacență unul cu celălalt, dar nu au inițiat sau primit încă nicio comunicare.

BGP folosește TCP ca transport. Deci, pentru a exista o Adiacența BGP, primul pas este de a stabili o conexiune TCP. În timp ce ambii colegi sunt în starea IDLE, fiecare va încerca periodic să inițieze o conexiune TCP la intervale independente (în funcție de momentul în care configurația de peering BGP a fost finalizată efectiv).

Când un peer inițiază strângerea de mână în trei direcții TCP cu un SYN, acel tranziție peer în Activ . Această stare indică faptul că routerul local activ încearcă să inițieze o conexiune TCP.

Când celălalt peer primește TCP SYN din colegul său, va trece în starea Connect . Această stare indică faptul că routerul local a primit o inițiere TCP de la celălalt router și este / a răspuns cu un SYN ACK.

De acolo, ambii colegi continuă prin restul stărilor: Open Sent, Open Confirmed, Stabilit.

Pentru a rezuma:

• Activ stat – local routerul tocmai a trimis un TCP SYN
• Conectare stat – router local tocmai a primit un TCP SYN de la colegul său

Tranzițiile stării „inițiatorului„ difuzorului BGP ”pentru a forma adiacența vor fi: Idle, Active, Open Sent, Open Received, Established

Tranzițiile de stare ale „difuzorului BGP” care răspund pentru a forma adiacența vor fi: Idle, Connect, Open Sent, Open Received, Established

Observați, doar peer-ul care a inițiat strângerea de mână TCP trece prin starea Active. Și numai peer-ul care NU a inițiat strângerea de mână TCP trece prin starea Connect.

Adăugarea unor depanări care dovedesc comportamentul. Acesta este codul routerului Cisco Versiunea 15.4 (1) T.

Acesta provine dintr-o sesiune de peering BGP între R1 (9.9.12.1) și R2 (9.9.12.2).

R2 este inițiatorul pentru această sesiune 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 

Confirmat pe celălalt 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 

Acesta este depanarea (filtrată) pe R2, inițiatorul:

$ 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 

Și aceasta este depanarea (filtrată) de pe R1, răspunsul:

$ 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 

Comentarii

• De fapt, aveți stările Active și Connect înapoi. De exemplu, RFC spune acest lucru despre starea activă: " Starea activă: În această stare, BGP FSM încearcă să dobândească un peer ascultând și acceptarea unei conexiuni TCP. " De asemenea, " Stare conectare: În această stare, BGP FSM așteaptă finalizarea conexiunii TCP. " După ce a trimis TCP SYN.
• Bună @RonMaupin. Nu ' cred că o fac. Am devenit curios după ce l-am scris și l-am testat și confirmă stările Active / Connect funcționează așa cum le-am descris. ' voi încerca să pun laolaltă " " ieșire de depanare și să o adaug la răspuns.
• @RonMaupin Tocmai a adăugat depanările, vezi mai sus. De asemenea, eu ' sunt mult mai preocupat de ceea ce face Cisco decât de ceea ce spune Cisco . Simțiți-vă liber să-mi spuneți dacă vedeți / bănuiți că ' interpretez erorile în mod incorect.
• Privind, singurul lucru pe care îl văd este că răspunsul a mers de la Repaus la Conectare după conexiunea TCP finalizată. În răspunsul meu am spus că a fost după ce am trimis SYN / ACK. Se pare că de fapt trece după ce a primit ACK final.
• Aș interpreta linia " 28 oct. 17: 06: 36.971: BGP: 9.9.12.1 activ de la Idle la Active " întrucât R1 merge de la Idle la Active. Deoarece R2 inițiază sesiunea TCP, acest lucru ar confirma vizualizarea @RonMaupins.