Hvad er forskellen mellem forbindelse og aktive tilstande for BGP?

BGP Peers starter i Tomgang tilstand. I inaktiv tilstand er jævnaldrende konfigureret til at danne en tilknytning til hinanden, men har endnu ikke startet eller modtaget nogen kommunikation.

BGP bruger TCP som transport. Så for at der skal være en BGP-tilknytning, det første trin er at etablere en TCP-forbindelse. Mens begge jævnaldrende er i tomgangstilstand, vil de med jævne mellemrum forsøge at starte en TCP-forbindelse med uafhængige intervaller (baseret på hvornår BGP-peering-konfigurationen faktisk blev afsluttet). >

Når en peer initierer TCPs trevejshåndtryk med et SYN, at peer overgår til Aktiv tilstand. Denne tilstand angiver, at den lokale router aktivt prøver at starte en TCP-forbindelse.

Når den anden peer modtager TCP SYN fra dens peer, den overgår til Forbind tilstand. Denne tilstand indikerer, at den lokale router har modtaget en TCP-initiering fra den anden router, og er / har reageret med en SYN ACK.

Derfra fortsætter begge jævnaldrende gennem de resterende tilstande: Åbn sendt, Åbn bekræftet, Etableret.

For at opsummere:

• Aktiv tilstand – lokal routeren har netop sendt en TCP SYN
• Tilslut tilstand – lokal router har netop modtaget en TCP SYN fra sin peer

Den “initierende” BGP-højttaler “tilstandsovergange for at danne nærhed vil være: Idle, Active, Open Sent, Open Received, Established

Den “svarende” BGP-højttalers tilstandsovergange for at danne adjacency vil være: Idle, Connect, Open Sent, Open Received, Established

Bemærk, kun den peer, der initierede TCP-håndtrykket, passerer gennem tilstanden Active. Og kun den peer, som IKKE initierede TCP-håndtrykket, passerer gennem Connect -tilstanden.

Tilføjelse af nogle fejlsøgninger, der viser adfærd. Dette er Cisco-routerkode version 15.4 (1) T.

Dette er fra en BGP-peering-session mellem R1 (9.9.12.1) og R2 (9.9.12.2).

R2 er initiativtager til denne TCP-session:

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 

Bekræftet på den anden 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 

Dette er (filtreret) debug på R2, initiativtager:

$ 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 (filtreret) debug på R1, responder:

$ 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 baglæns. For eksempel siger RFC dette om den aktive tilstand: " Aktiv tilstand: I denne tilstand forsøger BGP FSM at skaffe en peer ved at lytte efter og accepterer en TCP-forbindelse. " Også " Connect State: I denne tilstand, BGP FSM venter på, at TCP-forbindelsen skal gennemføres. " Efter at have sendt TCP SYN.
• Hej @ RonMaupin. Jeg tror ikke ' jeg gør det. Jeg blev nysgerrig efter at have skrevet det ud og labbede det ud, og det bekræfter, at Active / Connect-tilstandene fungerer, som jeg beskrev dem. Jeg ' Jeg prøver at sammensætte " pænt " debug output og tilføj det til svar.
• @RonMaupin Bare tilføjet debugs, se ovenfor. Også ' er jeg meget mere bekymret over hvad Cisco gør end hvad Cisco siger . Fortæl mig gerne, hvis du ser / har mistanke om, at jeg ' m fortolker fejlretningerne forkert.
• Når jeg ser på det, er det eneste, jeg ser, at svareren gik fra inaktiv til forbindelse efter TCP-forbindelsen er gennemført. I mit svar sagde jeg, at det var efter afsendelse af SYN / ACK. Det ser ud til, at det faktisk overgår efter modtagelse af den endelige ACK.
• Jeg vil fortolke linjen " 28. oktober 17: 06: 36.971: BGP: 9.9.12.1 aktiv gik fra inaktiv til aktiv ", da R1 går fra inaktiv til aktiv. Da R2 initierer TCP-sessionen, vil dette bekræfte visningen af @RonMaupins.

TCP opretter en forbindelse mellem to jævnaldrende, og BGP bruger TCP. En TCP-peer forsøger at oprette forbindelse til den anden TCP-peer, og dette er tilstanden connect.En peer kan lytte efter en forbindelse (især efter et mislykket forbindelsesforsøg fra dens side), og dette er active -tilstanden.

BGP har flere tilstande, og hver er tydeligt dokumenteret i RFC 4271, A Border Gateway Protocol 4 (BGP-4) . Beskrivelserne af staterne og bevægelse fra en til en anden (og / eller tilbage) er virkelig for store til at diskutere her. Nedenfor er et billede, der beskriver BGP Finite State Machine (FSM):

RFC har en fuld beskrivelse af FSMs forskellige tilstande og hvad der sker i hvert trin .

Startende med inaktiv tilstand, når en ManualStart- eller AutomaticStart-hændelse sker på systemet, ændrer den sin tilstand til Connect, men de passive versioner af disse hændelser (ManualStart_with_PassiveTcpEtablishment eller AutomaticStart_with_PassiveTcpEtablishment) sker, så ændrer den sin tilstand til Aktiv. Grundlæggende, når det bliver bedt om at oprette forbindelse til en peer, ændres det til Connect, men når det bliver bedt om at lytte efter en peer, ændres det til Active.

Når TCP-forbindelsen mislykkes, hvis TCP-forbindelsen mislykkes, den ændrer sin tilstand til Aktiv for at lytte efter en forbindelse fra peer.

Når den er i Active-tilstand, og begivenheden ConnectRetryTimer_Expires sker, prøver den TCP-forbindelsen og går ind i Connect-tilstanden.

Der er virkelig meget mere end det, men det er alt for stort til et websted som dette.