Mitä eroa BGP: n yhteys- ja aktiivisten tilojen välillä on?

Mikä merkitys on, että Mikronesiassa on kaksi eri tilaa, kun molemmat yrittävät muodostaa TCP-yhteyttä?

vastaus

BGP-ikäisensä alkavat Idle tila. Valmiustilassa vertaisversiot on määritetty muodostamaan vierekkäisyys keskenään, mutta eivät ole vielä aloittaneet tai vastaanottaneet mitään viestintää.

BGP käyttää TCP: tä siirtona. Joten siellä on BGP-vierekkäisyys, ensimmäinen vaihe on luoda TCP-yhteys. Vaikka molemmat vertaisryhmät ovat IDLE-tilassa, he yrittävät kumpikin säännöllisesti aloittaa TCP-yhteyden itsenäisin välein (sen mukaan, milloin BGP-vertaisarviointi oli todella valmis).

Kun yksi vertaisryhmä aloittaa TCP: n kolmitiekäden kättelyn SYN: n kanssa, tämä vertaistiedosto siirtyy aktiiviseen -tila. Tämä tila osoittaa, että paikallinen reititin yrittää aktiivisesti aloittaa TCP-yhteyttä.

Kun toinen vertaisverkko vastaanottaa TCP SYN sen vertaisversiosta, se siirtyy Connect -tilaan. Tämä tila osoittaa, että paikallinen reititin on saanut TCP-aloituksen toiselta reitittimeltä ja on / on vastannut SYN ACK: lla.

Sieltä molemmat vertaisryhmät jatkavat jäljellä olevien tilojen kautta: Avoin lähetetty, Avoin vahvistettu, Perustettu.

Yhteenveto:

  • Aktiivinen tila – paikallinen reititin on juuri lähettänyt TCP SYN: n
  • Yhdistä -tila – paikallinen reititin on juuri saanut TCP SYN: n vertaisiltaan

”Aloittavan” BGP-puhujan ”tilasiirtymät vierekkäisyyden muodostamiseksi ovat: Idle, Active, Open Sent, Open Received, Established

”Vastaavan” BGP-kaiuttimen tilasiirtymät vierekkäisyyden muodostamiseksi ovat: Idle, Connect, Open Sent, Open Received, Established

Huomaa, että vain TCP-kättelyn aloittanut vertaisryhmä kulkee Active -tilan läpi. Ja vain vertaisryhmä, joka EI käynnistänyt TCP-kättelyä, kulkee Connect -tilan läpi.


Lisää joitakin virheitä, jotka todistavat käytös. Tämä on Ciscon reitittimen koodiversio 15.4 (1) T.

Tämä on RG: n (9.9.12.1) ja R2: n (9.9.12.2) välisestä BGP-peering-istunnosta.

R2 on tämän TCP-istunnon aloittaja:

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 

Vahvistettu toisella reitittimellä:

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 

Tämä on R2: n (suodatettu) virheenkorjaus, aloittaja:

$ 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 

Ja tämä on R1: n (suodatettu) virheenkorjaus, vastaaja:

$ 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 

Kommentit

  • Sinulla on tosiasiassa Active- ja Connect-tilat taaksepäin. Esimerkiksi RFC sanoo tämän aktiivisesta tilasta: " Aktiivinen tila: Tässä tilassa BGP FSM yrittää hankkia vertaisarviointia kuuntelemalla ja hyväksyy TCP-yhteyden. " Lisäksi " Yhdistä tila: Tässä tilassa BGP FSM odottaa TCP-yhteyden muodostumista. " Lähetetty TCP SYN.
  • Hei @RonMaupin. En usko ' luulevan. Sain uteliaisuuden kirjoitettuani sen ja labbed sen pois, ja se vahvistaa, että Active / Connect-tilat toimivat kuten kuvasin niitä. Y ' yritän koota " siistin " virheenkorjauslähdön ja lisätä sen vastaus.
  • @RonMaupin lisäsi juuri virheenkorjaukset, katso yllä. Lisäksi olen ' paljon kiinnostunut siitä, mitä Cisco tekee kuin mitä Cisco sanoo . Voit vapaasti kertoa minulle, jos näet / epäilet, että ' tulkitsen virheenkorjauksia väärin.
  • Katson sitä, että ainoa asia, jonka näen, on vastaaja valmiustilasta yhteyden muodostamiseen sen jälkeen kun TCP-yhteys on valmis. Vastauksessani sanoin, että se oli lähetetty SYN / ACK. Vaikuttaa siltä, että se todella siirtyy saatuaan lopullisen ACK: n.
  • Tulkitsisin linjan " 28. lokakuuta 17: 06: 36.971: BGP: 9.9.12.1 aktiivinen meni tyhjäkäynnistä aktiiviseen ", kun R1 siirtyy tyhjäkäynnistä aktiiviseksi. Koska R2 aloittaa TCP-istunnon, tämä vahvistaa @RonMaupins -näkymän.

Vastaa

TCP luo yhteyden kahden ikäisensä välillä, ja BGP käyttää TCP: tä. Yksi TCP-vertaisyritys yrittää muodostaa yhteyden toiseen TCP-vertaisryhmään, ja tämä on tila connect.Yksi vertaisryhmä voi kuunnella yhteyttä (varsinkin epäonnistuneen yhteysyrityksen jälkeen), ja tämä on tila active.

BGP: llä on useita tiloja, ja kukin niistä on selkeästi dokumentoitu RFC 4271, A Border Gateway Protocol 4 (BGP-4) . Tilojen kuvaukset ja siirtyminen tilasta toiseen (ja / tai taaksepäin) on todellakin liian suuri keskustelemaan täällä. Alla on kuva, joka kuvaa BGP Finite State Machine -laitetta (FSM):

kirjoita kuvan kuvaus tähän

RFC: llä on täydellinen kuvaus Mikronesian eri tiloista ja siitä, mitä kussakin vaiheessa tapahtuu .

Valmiustilasta alkaen, kun järjestelmässä tapahtuu ManualStart- tai AutomaticStart-tapahtuma, se muuttaa tilansa Connect-tilaan, mutta tapahtumien passiiviset versiot (ManualStart_with_PassiveTcpEstablishment tai AutomaticStart_with_PassiveTcpEstablishment) tapahtuvat, ja sen jälkeen tilaksi tulee Active. Periaatteessa, kun käsketään muodostaa yhteys vertaisverkkoon, se muuttuu Yhdistä-muotoon, mutta kun käsketään kuuntelemaan ikäisensä, se muuttuu Aktiiviseksi.

Kun yhteys on tilassa, jos TCP-yhteys epäonnistuu, se vaihtaa tilaksi Aktiivinen kuunnellakseen yhteyttä vertaisilta.

Kun se on aktiivisessa tilassa ja tapahtuu ConnectRetryTimer_Expires-tapahtuma, se yrittää TCP-yhteyttä ja menee Yhdistä-tilaan.

Siinä on todellakin paljon enemmän, mutta se on aivan liian suuri tällaiselle sivustolle.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *