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