Wat is het verschil tussen connect en actieve status van BGP?

BGP-peers starten in Inactief staat. In de rusttoestand zijn de peers geconfigureerd om een nabijheid met elkaar te vormen, maar hebben ze nog geen communicatie geïnitieerd of ontvangen.

BGP gebruikt TCP als transport. Dus om een BGP-nabijheid, de eerste stap is het tot stand brengen van een TCP-verbinding. Hoewel beide peers zich in de IDLE-status bevinden, zullen ze elk periodiek proberen een TCP-verbinding tot stand te brengen met onafhankelijke tussenpozen (gebaseerd op wanneer de BGP-peeringconfiguratie daadwerkelijk is voltooid).

Wanneer een peer initieert de TCP drieweg-handshake met een SYN, die peer gaat over in Actief state. Deze status geeft aan dat de lokale router actief probeert een TCP-verbinding tot stand te brengen.

Wanneer de andere peer de TCP SYN van zijn peer, het zal overgaan naar Connect toestand. Deze status geeft aan dat de lokale router een TCP-initiatie heeft ontvangen van de andere router, en is / heeft gereageerd met een SYN ACK.

Van daaruit gaan beide peers door met de resterende statussen: Open Verzonden, Open Bevestigd, Gevestigd.

Samenvattend:

• Actief staat – lokaal router heeft zojuist verzonden een TCP SYN
• Connect state – lokale router heeft zojuist ontvangen een TCP SYN van zijn peer

De overgangen van de “initiërende” BGP-spreker naar de toestand van de aangrenzende zijn: Idle, Active, Open Sent, Open Received, Established

De statusovergangen van de “reagerende” BGP-spreker “om de nabijheid te vormen zijn: Idle, Connect, Open Sent, Open Received, Established

Let op, alleen de peer die de TCP-handshake heeft geïnitieerd, doorloopt de status Active. En alleen de peer die NIET de TCP-handshake heeft geïnitieerd, gaat door de Connect -status.

Het toevoegen van enkele foutopsporingen die bewijzen het gedrag. Dit is Cisco-routercode versie 15.4 (1) T.

Dit is van een BGP-peering-sessie tussen R1 (9.9.12.1) en R2 (9.9.12.2).

R2 is de initiator voor deze TCP-sessie:

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 

Bevestigd op de andere 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 

Dit is de (gefilterde) debug op R2, de initiator:

$ 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 

En dit is de (gefilterde) debug op R1, de 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 

Reacties

• Je hebt feitelijk de status Actief en Connect achterstevoren. De RFC zegt bijvoorbeeld dit over de actieve status: " Actieve status: in deze status probeert BGP FSM een peer te krijgen door te luisteren naar , en accepteren, een TCP-verbinding. " Ook " Verbindingsstatus: in deze toestand BGP FSM wacht op voltooiing van de TCP-verbinding. " Na het verzenden van de TCP SYN.
• Hallo @RonMaupin. Ik denk niet dat ik het ' niet doe. Ik werd nieuwsgierig nadat ik het had uitgeschreven en uitgeprobeerd, en het bevestigt dat de Active / Connect-statussen werken zoals ik ze heb beschreven. Ik ' zal proberen " netjes " foutopsporingsuitvoer samen te stellen en toe te voegen aan de antwoord.
• @RonMaupin Zojuist de debugs toegevoegd, zie hierboven. Bovendien ben ik ' veel meer bezorgd over wat Cisco doet dan wat Cisco zegt . Voel je vrij om me te vertellen of je ziet / vermoedt dat ik ' de foutopsporingen verkeerd interpreteer.
• Als ik ernaar kijk, is het enige dat ik zie dat de responder is gegaan van Idle naar Connect nadat de TCP-verbinding is voltooid. In mijn antwoord zei ik dat het was na het verzenden van de SYN / ACK. Het lijkt erop dat het daadwerkelijk overgaat na ontvangst van de laatste ACK.
• Ik zou de regel " 28 oktober 17: 06: 36.971: BGP: 9.9.12.1 actief gaan interpreteren van inactief naar actief " terwijl R1 van inactief naar actief gaat. Aangezien R2 de TCP-sessie start, zou dit de weergave @RonMaupins bevestigen.

TCP maakt een verbinding tussen twee peers, en BGP gebruikt TCP. De ene TCP-peer zal proberen verbinding te maken met de andere TCP-peer, en dit is de status connect.Eén peer kan luisteren naar een verbinding (vooral na een mislukte verbindingspoging van zijn kant), en dit is de status active.

BGP heeft verschillende statussen, en elk is duidelijk gedocumenteerd in RFC 4271, A Border Gateway Protocol 4 (BGP-4) . De beschrijvingen van de toestanden en het verplaatsen van de ene naar de andere (en / of terug) is echt te uitgebreid om hier te bespreken. Hieronder staat een afbeelding die de BGP Finite State Machine (FSM) beschrijft:

De RFC heeft een volledige beschrijving van de verschillende staten van de FSM en wat er in elke fase gebeurt .

Beginnend met de Idle-status, wanneer een ManualStart- of AutomaticStart-gebeurtenis plaatsvindt op het systeem, verandert de status in Connect, maar de passieve versies van die gebeurtenissen (ManualStart_with_PassiveTcpEstablishment of AutomaticStart_with_PassiveTcpEstablishment) gebeurt, waarna de status verandert in Actief. In principe verandert het in Connect als het wordt verteld om verbinding te maken met een peer, maar als het wordt verteld om te luisteren naar een peer, verandert het in Active.

In de Connect-status, als de TCP-verbinding mislukt, het verandert zijn status in Actief om te luisteren naar een verbinding van de peer.

Wanneer het in de actieve status is en de ConnectRetryTimer_Expires-gebeurtenis plaatsvindt, probeert het de TCP-verbinding en gaat het naar de Connect-status.

Er komt echt veel meer bij kijken, maar het is veel te groot voor een site als deze.