Quelle est la différence entre les états de connexion et actif de BGP?

Les pairs BGP commencent dans Inactif état. Dans létat Idle, les pairs ont été configurés pour former une contiguïté les uns avec les autres, mais nont pas encore initié ou reçu de communication.

BGP utilise TCP comme transport. Donc, pour quil y ait un Adjacence BGP, la première étape consiste à établir une connexion TCP. Alors que les deux homologues sont dans létat IDLE, ils tenteront chacun périodiquement dinitier une connexion TCP à des intervalles indépendants (en fonction du moment où la configuration dappairage BGP a été effectivement terminée).

Lorsquun pair lance la prise de contact TCP à trois avec un SYN, ce pair passe en Active état. Cet état indique que le routeur local essaie activement d’établir une connexion TCP.

Lorsque l’autre homologue reçoit TCP SYN de son homologue, il passera à létat Connect . Cet état indique que le routeur local a reçu une initiation TCP de lautre routeur et quil a répondu par un SYN ACK.

À partir de là, les deux pairs continuent à travers les états restants: Ouvert envoyé, ouvert confirmé, Établi.

Pour résumer:

• Actif état – local le routeur vient d envoyer un TCP SYN
• Connect état – routeur local vient de recevoir un TCP SYN de son homologue

Les transitions d’état du «locuteur BGP initiateur» pour former la contiguïté seront: Idle, Active, Open Sent, Open Received, Established

Les transitions détat du « répondant » BGP speaker « pour former la contiguïté seront: Idle, Connect, Open Sent, Open Received, Established

Remarquez, seul lhomologue qui a initié la prise de contact TCP passe par létat Active. Et seul le pair qui NA PAS initié la prise de contact TCP passe par létat Connect.

Ajout de quelques débogages qui prouvent le comportement. Il sagit du code de routeur Cisco Version 15.4 (1) T.

Il sagit dune session dappairage BGP entre R1 (9.9.12.1) et R2 (9.9.12.2).

R2 est linitiateur de cette session TCP:

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 

Confirmé sur lautre routeur:

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 

Voici le débogage (filtré) sur R2, linitiateur:

$ 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 

Et voici le débogage (filtré) sur R1, le répondeur:

$ 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 

Commentaires

• Vous avez en fait les états Active et Connect à lenvers. Par exemple, la RFC dit ceci à propos de létat actif: " État actif: dans cet état, BGP FSM tente dacquérir un pair en écoutant et acceptant une connexion TCP. " Aussi, " État de connexion: dans cet état, BGP FSM attend que la connexion TCP soit terminée. " Ayant envoyé le TCP SYN.
• Bonjour @RonMaupin. Je ne ' que je pense. Je suis devenu curieux après lavoir écrit et lavoir étudié, et cela confirme que les états Active / Connect fonctionnent comme je les ai décrits. Je ' vais essayer de rassembler la sortie de débogage " soignée " et l’ajouter réponse.
• @RonMaupin Je viens dajouter les débogages, voir ci-dessus. De plus, je ' suis beaucoup plus préoccupé par ce que Cisco fait que par ce que Cisco dit . Nhésitez pas à me dire si vous voyez / soupçonnez que je ' m interpréter les débogages de manière incorrecte.
• En y regardant, la seule chose que je vois est que le répondeur est allé de Idle à Connect après la connexion TCP terminée. Dans ma réponse, jai dit que cétait après lenvoi du SYN / ACK. Il semble quil transite réellement après avoir reçu le dernier ACK.
• Jinterpréterais la ligne " 28 octobre 17: 06: 36.971: BGP: 9.9.12.1 active est allé de Inactif à Actif " car R1 passe de Inactif à Actif. Puisque R2 lance la session TCP, cela confirmerait la vue @RonMaupins.

TCP crée une connexion entre deux pairs, et BGP utilise TCP. Un pair TCP essaiera de se connecter à lautre pair TCP, et cest létat connect.Un pair peut écouter une connexion (surtout après une tentative de connexion infructueuse de sa part), et cest létat active.

BGP a plusieurs états, et chacun est clairement documenté dans RFC 4271, A Border Gateway Protocol 4 (BGP-4) . Les descriptions des états et le passage de lun à lautre (et / ou retour) sont vraiment trop volumineux pour être discutés ici. Voici une image qui décrit la machine à états finis BGP (FSM):

La RFC a une description complète des différents états du FSM et de ce qui se passe à chaque étape .

À partir de létat Idle, lorsquun événement ManualStart ou AutomaticStart se produit sur le système, il change son état en Connect, mais les versions passives de ces événements (ManualStart_with_PassiveTcpEstablishment ou AutomaticStart_with_PassiveTcpEstablishment) se produit, puis il change son état en Active. Fondamentalement, quand on lui dit de se connecter à un pair, il passe à Connect, mais quand on lui dit découter un pair, il devient Actif.

Dans létat Connect, si la connexion TCP échoue, il change son état en Actif pour écouter une connexion de lhomologue.

Lorsquil est dans létat Actif, et que lévénement ConnectRetryTimer_Expires se produit, il essaie la connexion TCP et passe à létat Connect.

Il y a vraiment beaucoup plus que cela, mais cest beaucoup trop grand pour un site comme celui-ci.