Mi a különbség a BGP kapcsolódási és aktív állapota között?

Mi a jelentősége annak, ha két különböző állapot van az FSM-ben, amikor mindkettő megpróbálja létrehozni a TCP-kapcsolatot?

Válasz

A BGP társai tétlen állapotban állapot. Készenléti állapotban a társak úgy vannak konfigurálva, hogy szomszédságot alkossanak egymással, de még nem kezdeményeztek és nem kaptak semmilyen kommunikációt.

A BGP a TCP-t használja szállításakor. Tehát A BGP szomszédságának első lépése a TCP-kapcsolat létrehozása. Míg mindkét társ IDLE állapotban van, rendszeresen független időközönként megpróbálnak TCP-kapcsolatot kezdeményezni (attól függően, hogy a BGP társviszony-konfiguráció valóban elkészült-e).

Amikor egy társ kezdeményezi a TCP háromirányú kézfogását egy SYN-lel, ez a társ áttér aktív állapot. Ez az állapot azt jelzi, hogy a helyi útválasztó aktív ban próbál TCP-kapcsolatot kezdeményezni.

Amikor a másik társ fogad a TCP SYN a társától, áttér Csatlakozás állapotra. Ez az állapot azt jelzi, hogy a helyi útválasztó TCP-kezdeményezést kapott a másik útválasztótól, és SYN ACK-val válaszolt / válaszolt.

Onnan mindkét társ folytatja a fennmaradó állapotokat: Nyitott elküldve, Megnyitva nyitva, Létrehozva.

Összefoglalva:

  • Aktív állapot – helyi az útválasztó éppen küldött nek egy TCP SYN-t
  • Csatlakozás állapot – helyi útválasztó éppen kapott egy TCP SYN-t a társától

A “kezdeményező” BGP beszélő állapotátmenetei a szomszédság kialakításához a következők lesznek: Idle, Active, Open Sent, Open Received, Established

A “válaszoló” BGP hangszóró állapotátmenetei a szomszédság kialakításához a következők lesznek: Idle, Connect, Open Sent, Open Received, Established

Figyelem, csak a TCP kézfogást kezdeményező társa halad át Active állapoton. Csak a Connect állapoton megy át az a társ, amely NEM kezdeményezte a TCP kézfogást.


Néhány olyan hibakeresés hozzáadása, amely bizonyítja a viselkedés. Ez a Cisco útválasztókód 15.4 (1) T verziója.

Ez egy RG (9.9.12.1) és R2 (9.9.12.2) közötti BGP társviszony-munkamenetből származik.

R2 ennek a TCP-munkamenetnek a kezdeményezője:

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 

Megerősítve a másik útválasztón:

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 

Ez a (szűrt) hibakeresés az R2-n, a kezdeményező:

$ 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 

És ez az R1 (szűrt) hibakeresője, a válaszadó:

$ 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 

Megjegyzések

  • Valójában az Aktív és a Csatlakozás állapotok hátra vannak. Például az RFC ezt mondja az aktív állapotról: " Aktív állapot: Ebben az állapotban a BGP FSM megpróbálja megszerezni a társát azáltal, hogy hallgatja a és elfogadja a TCP kapcsolatot. " Továbbá, " Csatlakozási állapot: Ebben az állapotban A BGP FSM a TCP-kapcsolat befejezésére vár. " A TCP SYN elküldése után.
  • Szia @RonMaupin. Nem gondolom, hogy ' gondolom. Kíváncsivá váltam, miután kiírtam, és kibogoztam, és ez megerősíti az Active / Connect állapotok működését, ahogy leírtam őket. ' megpróbálom összeállítani a " ügyes " hibakereső kimenetet, és hozzáadni a válasz.
  • @RonMaupin Csak hozzáadta a hibakeresőket, lásd fent. Ezenkívül ' sokkal jobban foglalkoztat, hogy mit csinál a Cisco , mint amit a Cisco mond . Nyugodtan mondd meg, ha úgy látod / gyanítom, hogy ' hibásan értelmezem a hibákat.
  • Ha ránézek, az egyetlen dolog, amit látok, az a válaszadó az alapjárattól a Csatlakozásig miután a TCP-kapcsolat elkészült. Válaszomban azt mondtam, hogy a SYN / ACK elküldése után történt. Úgy tűnik, valójában átmenet az utolsó ACK kézhezvétele után.
  • Értelmezném az " sort 28. okt. 17: 06: 36.971: BGP: 9.9.12.1 aktív az alapjáratról az aktívra ", amikor az R1 alapjáratról aktívra vált. Mivel az R2 kezdeményezi a TCP munkamenetet, ez megerősíti a @RonMaupins nézetet.

Válasz

A TCP kapcsolatot hoz létre két társ között, és a BGP TCP-t használ. Az egyik TCP-társ megpróbál csatlakozni a másik TCP-társhoz, és ez a connect állapot.Egy társ meghallgathatja a kapcsolatot (főleg sikertelen kapcsolódási kísérlet után), és ez a active állapot.

A BGP-nek több állapota van, és mindegyik világosan dokumentálva van az RFC 4271, A Border Gateway Protocol 4 (BGP-4) fájlban. Az állapotok leírása és az egyikről a másikra (és / vagy vissza) való elmozdulás valóban túl nagy ahhoz, hogy itt tárgyaljuk. Az alábbiakban egy kép ismerteti a BGP véges állapotú gépet (FSM):

írja ide a kép leírását

Az RFC teljes körű leírást tartalmaz az FSM különböző állapotairól és arról, hogy mi történik az egyes szakaszokban .

A tétlen állapotból kiindulva, amikor a ManualStart vagy az AutomaticStart esemény bekövetkezik a rendszeren, az állapota Connect-re változik, de az események passzív verziói (ManualStart_with_PassiveTcpEstablishment vagy AutomaticStart_with_PassiveTcpEstablishment) megtörténnek, majd az állapotát Active-ra változtatja. Alapvetően, ha azt mondják, hogy csatlakozzon egy társhoz, akkor az átvált Connect-re, de ha azt mondják, hogy hallgasson meg egy társra, akkor az Active-ra változik.

Csatlakozás állapotban, ha a TCP-kapcsolat nem sikerül, állapotát Aktívra változtatja, hogy kapcsolatokat hallgasson a társától.

Amikor aktív állapotban van, és bekövetkezik a ConnectRetryTimer_Expires esemény, akkor megpróbálja a TCP kapcsolatot, és belép a Csatlakozás állapotba.

Ennél sokkal több van benne, de túl nagy egy ilyen webhelyhez.

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük