Vad är skillnaden mellan anslutning och aktiva tillstånd för BGP?

BGP Peers startar i Tomgång tillstånd. I viloläge har kamraterna konfigurerats för att bilda en angränsning med varandra, men har ännu inte initierat eller fått någon kommunikation.

BGP använder TCP som transport. Så för att det ska finnas en BGP-angränsning, det första steget är att upprätta en TCP-anslutning. Medan båda kamraterna är i viloläge försöker de varje period att initiera en TCP-anslutning med oberoende intervall (baserat på när BGP-peeringkonfigurationen faktiskt slutfördes). >

När en peer initierar TCP-trevägshandskakningen med ett SYN, att peer övergår till Aktiv tillstånd. Detta tillstånd indikerar att den lokala routern aktivt försöker initiera en TCP-anslutning.

När den andra kollegan tar emot TCP SYN från dess peer, det kommer att övergå till Anslut tillstånd. Detta tillstånd indikerar att den lokala routern har fått en TCP-initiering från den andra routern och har / har svarat med en SYN ACK.

Därifrån fortsätter båda kamraterna genom de återstående tillstånden: Öppna skickade, Öppna bekräftade, Upprättat.

Sammanfattningsvis:

• Aktiv tillstånd – lokal routern har precis skickat ett TCP SYN
• Anslut tillstånd – lokal router har precis fått en TCP SYN från sin peer

Den ”initierande” BGP-högtalarens tillståndsövergångar för att bilda angränsningen kommer att vara: Idle, Active, Open Sent, Open Received, Established

Den ”svarande” BGP-högtalarens tillståndsövergångar för att bilda angränsningen kommer att vara: Idle, Connect, Open Sent, Open Received, Established

Observera att endast den kamrat som initierade TCP-handskakningen passerar genom tillståndet Active. Och bara den kamrat som INTE initierade TCP-handskakningen passerar genom tillståndet Connect.

Lägga till några felsök som visar uppförandet. Detta är Cisco-routerkod version 15.4 (1) T.

Detta kommer från en BGP-peering-session mellan R1 (9.9.12.1) och R2 (9.9.12.2).

R2 är initiativtagaren till denna 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äftad på den andra routern:

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 

Detta är den (filtrerade) felsökningen på R2, initiatören:

$ 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 

Och detta är den (filtrerade) felsökningen på R1, svararen:

$ 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 faktiskt statusen Active och Connect bakåt. Till exempel säger RFC detta om det aktiva tillståndet: " Aktivt tillstånd: I detta tillstånd försöker BGP FSM att skaffa en peer genom att lyssna efter och accepterar en TCP-anslutning. " Dessutom " Anslut tillstånd: I detta tillstånd, BGP FSM väntar på att TCP-anslutningen ska slutföras. " Har skickat TCP SYN.
• Hej @RonMaupin. Jag tror inte ' att jag gör det. Jag blev nyfiken efter att ha skrivit ut den och labbat ut den, och det bekräftar att Active / Connect-tillstånd fungerar som jag beskrev dem. Jag ' Jag försöker sätta ihop " snyggt " felsökningsoutput och lägga till det i svara.
• @RonMaupin Har precis lagt till felsökningarna, se ovan. Jag ' är också mycket mer bekymrad över vad Cisco gör än vad Cisco säger . Berätta gärna för mig om du ser / misstänker att jag ' tolkar felsökningarna felaktigt.
• Om jag ser det är det enda jag ser att svararen gick från tomgång till anslutning efter att TCP-anslutningen slutförts. I mitt svar sa jag att det var efter att ha skickat SYN / ACK. Det verkar som om det faktiskt övergår efter att ha fått den sista ACK.
• Jag skulle tolka raden " 28 oktober 17: 06: 36.971: BGP: 9.9.12.1 aktiv gick från tomgång till aktiv " eftersom R1 går från tomgång till aktiv. Eftersom R2 initierar TCP-sessionen, skulle detta bekräfta vyn @RonMaupins.

TCP skapar en anslutning mellan två kamrater, och BGP använder TCP. En TCP-peer försöker ansluta till den andra TCP-peer, och detta är connect -tillståndet.En kollega kan lyssna efter en anslutning (särskilt efter ett misslyckat anslutningsförsök från dess sida), och detta är active -tillståndet.

BGP har flera tillstånd, och var och en är tydligt dokumenterad i RFC 4271, A Border Gateway Protocol 4 (BGP-4) . Beskrivningarna av staterna och att flytta från en till en annan (och / eller tillbaka) är verkligen för stor för att diskutera här. Nedan är en bild som beskriver BGP Finite State Machine (FSM):

RFC har en fullständig beskrivning av FSM: s olika tillstånd och vad som händer i varje steg .

Från och med viloläget, när en ManualStart- eller AutomaticStart-händelse inträffar i systemet, ändras det till Connect, men de passiva versionerna av dessa händelser (ManualStart_with_PassiveTcpEstablishment eller AutomaticStart_with_PassiveTcpEstablishment) inträffar och ändrar sedan tillståndet till Aktiv. I grund och botten, när den uppmanas att ansluta till en peer, ändras den till Connect, men när den uppmanas att lyssna på en peer ändras den till Active.

Om TCP-anslutningen misslyckas, om TCP-anslutningen misslyckas, det ändrar sitt tillstånd till Aktiv för att lyssna efter en anslutning från peer.

När det är i aktivt tillstånd och händelsen ConnectRetryTimer_Expires inträffar, försöker den TCP-anslutningen och går in i Connect-tillståndet.

Det finns verkligen mycket mer än så, men det är alldeles för stort för en webbplats som denna.