Hva er forskjellen mellom tilkobling og aktive tilstander til BGP?

BGP Jevnaldrende starter i Tomgang tilstand. I inaktiv tilstand har jevnaldrende blitt konfigurert til å danne en tilknytning til hverandre, men har ennå ikke startet eller mottatt noen kommunikasjon.

BGP bruker TCP som transport. Så for at det skal være en BGP-tilknytning, det første trinnet er å etablere en TCP-forbindelse. Mens begge jevnaldrende er i tomgangstilstand, vil de med jevne mellomrom prøve å starte en TCP-forbindelse med uavhengige intervaller (basert på når BGP-peering-konfigurasjonen faktisk ble fullført). >

Når en jevnaldrende initierer TCP-treveishåndtrykket med et SYN, overgår den jevnaldrende til Aktiv tilstand. Denne tilstanden indikerer at den lokale ruteren aktivt prøver å starte en TCP-tilkobling.

Når den andre kollegaen mottar TCP SYN fra den er peer, den vil gå over til Koble til tilstand. Denne tilstanden indikerer at den lokale ruteren har mottatt en TCP-initiering fra den andre ruteren, og er / har svart med en SYN ACK.

Derfra fortsetter begge jevnaldrende gjennom de gjenværende tilstandene: Åpent sendt, Åpne bekreftet, Etablert.

For å oppsummere:

• Aktiv tilstand – lokal ruteren har nettopp sendt en TCP SYN
• Koble til tilstand – lokal ruter har nettopp mottatt en TCP SYN fra sin likemann

Den «initierende» BGP-høyttalerens tilstandsoverganger for å danne nærhet vil være: Idle, Active, Open Sent, Open Received, Established

Den «svarende» BGP-høyttalerens tilstandsoverganger for å danne adjacency vil være: Idle, Connect, Open Sent, Open Received, Established

Legg merke til at bare den jevnaldrende som initierte TCP-håndtrykket passerer gjennom tilstanden Active. Og bare den likemannen som IKKE initierte TCP-håndtrykket, passerer gjennom Connect -tilstanden.

Legger til noen feilsøkinger som viser oppførselen. Dette er Cisco ruterkode versjon 15.4 (1) T.

Dette er fra en BGP-peering-økt mellom R1 (9.9.12.1) og R2 (9.9.12.2).

R2 er initiativtakeren til denne TCP-økten:

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 

Bekreftet på den andre ruteren:

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 

Dette er (filtrert) feilsøkingen på R2, initiativtakeren:

$ 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 

Og dette er (filtrert) feilsøkingen på R1, responderen:

$ 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 

Kommentarer

• Du har faktisk tilstandene Active og Connect bakover. For eksempel sier RFC dette om den aktive tilstanden: " Aktiv tilstand: I denne tilstanden prøver BGP FSM å skaffe seg en peer ved å lytte etter , og godta en TCP-forbindelse. " Også " Connect State: I denne tilstanden, BGP FSM venter på at TCP-tilkoblingen skal fullføres. " Etter å ha sendt TCP SYN.
• Hei @RonMaupin. Jeg tror ikke ' jeg gjør det. Jeg ble nysgjerrig etter å ha skrevet den ut og labbet den ut, og den bekrefter at Active / Connect-tilstandene fungerer slik jeg beskrev dem. Jeg ' Jeg prøver å sette sammen " pent " feilsøkingsutdata og legge det til i svar.
• @RonMaupin Bare lagt til feilsøkingen, se ovenfor. Også, jeg ' er mye mer opptatt av hva Cisco gjør enn hva Cisco sier . Fortell meg gjerne om du ser / mistenker at jeg ' m tolker feilsøkingen feil.
• Ser vi på det, er det eneste jeg ser at svareren gikk fra inaktiv til Connect etter at TCP-forbindelsen er fullført. I svaret mitt sa jeg at det var etter sending av SYN / ACK. Det ser ut til at det faktisk overgår etter å ha mottatt den endelige ACK.
• Jeg vil tolke linjen " 28. oktober 17: 06: 36.971: BGP: 9.9.12.1 aktiv gikk fra tomgang til aktiv " ettersom R1 går fra tomgang til aktiv. Siden R2 starter TCP-økten, vil dette bekrefte visningen av @RonMaupins.

TCP oppretter en forbindelse mellom to jevnaldrende, og BGP bruker TCP. En TCP-peer vil prøve å koble til den andre TCP-peer, og dette er connect -tilstanden.En jevnaldrende kan lytte etter en forbindelse (spesielt etter et mislykket tilkoblingsforsøk fra sin side), og dette er active -tilstanden.

BGP har flere tilstander, og hver er tydelig dokumentert i RFC 4271, A Border Gateway Protocol 4 (BGP-4) . Beskrivelsene av statene og å bevege seg fra en til en annen (og / eller tilbake) er egentlig for store til å diskutere her. Nedenfor er et bilde som beskriver BGP Finite State Machine (FSM):

RFC har full beskrivelse av de forskjellige tilstandene i FSM og hva som skjer i hvert trinn .

Fra og med inaktiv tilstand, når en ManualStart- eller AutomaticStart-hendelse skjer på systemet, endrer den statusen til Connect, men de passive versjonene av disse hendelsene (ManualStart_with_PassiveTcpEstablishment eller AutomaticStart_with_PassiveTcpEstablishment) skjer, og endrer deretter tilstanden til Aktiv. Når det blir bedt om å koble til en likemann, endres det til Koble, men når det blir bedt om å lytte etter en jevnaldrende, endres det til Aktiv.

Når TCP-tilkoblingen mislykkes, er den endrer tilstanden til Aktiv for å lytte etter en forbindelse fra jevnaldrende.

Når den er i Aktiv-tilstand, og ConnectRetryTimer_Expires-hendelsen skjer, prøver den TCP-tilkoblingen og går inn i Connect-tilstanden.

Det er virkelig mye mer enn det, men det er altfor stort for et nettsted som dette.