Welche Bedeutung haben zwei unterschiedliche Zustände in FSM, wenn beide versuchen, eine TCP-Verbindung herzustellen?
Antwort
BGP-Peers beginnen in Leerlauf Zustand. Im Ruhezustand wurden die Peers so konfiguriert, dass sie eine Nachbarschaft zueinander bilden, haben jedoch noch keine Kommunikation initiiert oder empfangen.
BGP verwendet TCP als Transportmittel BGP-Adjazenz: Der erste Schritt besteht darin, eine TCP-Verbindung herzustellen. Während sich beide Peers im IDLE-Status befinden, versuchen sie jeweils regelmäßig, in unabhängigen Intervallen eine TCP-Verbindung herzustellen (basierend darauf, wann die BGP-Peering-Konfiguration tatsächlich abgeschlossen wurde).
Wenn ein Peer den TCP-Drei-Wege-Handshake mit einem SYN initiiert , wechselt dieser Peer in Active -Status. Dieser Status gibt an, dass der lokale Router aktiv versucht, eine TCP-Verbindung herzustellen.
Wenn der andere Peer
Von dort aus fahren beide Peers mit den verbleibenden Status fort: Offen Gesendet, Offen Bestätigt, Etabliert.
Zusammenfassend:
- Aktiv state – local Der Router hat gerade einen TCP-SYN gesendet
- Verbinden Sie den -Status – lokalen Router hat gerade eine TCP-SYN von seinem Peer erhalten
Die Zustandsübergänge des „initiierenden“ BGP-Sprechers zur Bildung der Nachbarschaft lauten: Idle, Active, Open Sent, Open Received, Established
Die Zustandsübergänge des „antwortenden“ BGP-Sprechers zur Bildung der Nachbarschaft lauten: Idle, Connect, Open Sent, Open Received, Established
Beachten Sie, dass nur der Peer, der den TCP-Handshake initiiert hat, den Status Active durchläuft. Und nur der Peer, der den TCP-Handshake NICHT initiiert hat, durchläuft den Status Connect.
Hinzufügen einiger Debugs, die dies beweisen das Verhalten. Dies ist der Cisco-Router-Code Version 15.4 (1) T.
Dies stammt aus einer BGP-Peering-Sitzung zwischen R1 (9.9.12.1) und R2 (9.9.12.2).
R2 ist Der Initiator für diese TCP-Sitzung:
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 Auf dem anderen Router bestätigt:
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 Dies ist das (gefilterte) Debugging auf R2, dem 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 Und dies ist das (gefilterte) Debugging auf R1, dem 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 Kommentare
- Sie haben tatsächlich den Status „Aktiv“ und „Verbinden“ rückwärts. Der RFC sagt dies beispielsweise über den aktiven Status aus: " Aktiver Status: In diesem Status versucht BGP FSM, einen Peer zu erwerben, indem auf gewartet wird b> und Akzeptieren einer TCP-Verbindung. " Außerdem " Verbindungsstatus: In diesem Status BGP FSM wartet auf den Abschluss der TCP-Verbindung. " Nach dem Senden der TCP-SYN.
- Hi @RonMaupin. Ich glaube nicht, dass ' ich es tue. Ich wurde neugierig, nachdem ich es ausgeschrieben und ausgemustert hatte, und es bestätigt, dass die Active / Connect-Zustände so funktionieren, wie ich sie beschrieben habe. Ich ' werde versuchen, " ordentliche " Debug-Ausgabe zusammenzustellen und sie der hinzuzufügen Antwort.
- @RonMaupin Fügte gerade die Debugs hinzu, siehe oben. Außerdem bin ich ' viel mehr damit beschäftigt, was Cisco tut als was Cisco sagt . Sie können mir gerne sagen, wenn Sie sehen / vermuten, dass ich ' die Debugs falsch interpretiere.
- Wenn ich es mir anschaue, sehe ich nur, dass der Responder gegangen ist von Leerlauf zu Verbindung nach Abschluss der TCP-Verbindung. In meiner Antwort sagte ich, es sei nach dem Senden der SYN / ACK. Es scheint, dass es tatsächlich Übergänge nach Erhalt der endgültigen ACK gibt.
- Ich würde die Zeile interpretieren " 28. Oktober 17: 06: 36.971: BGP: 9.9.12.1 aktiv ging von Leerlauf zu Aktiv ", während R1 von Leerlauf zu Aktiv wechselt. Da R2 die TCP-Sitzung initiiert, würde dies die Ansicht @RonMaupins bestätigen.
Antwort
TCP erstellt eine Verbindung zwischen zwei Peers und BGP verwendet TCP. Ein TCP-Peer versucht, eine Verbindung zum anderen TCP-Peer herzustellen. Dies ist der Status connect.Ein Peer kann auf eine Verbindung warten (insbesondere nach einem fehlgeschlagenen Verbindungsversuch), und dies ist der Status active.
BGP hat mehrere Status und Jedes ist in RFC 4271, A Border Gateway Protocol 4 (BGP-4) klar dokumentiert. Die Beschreibungen der Zustände und des Wechsels von einem zum anderen (und / oder zurück) sind wirklich zu umfangreich, um hier diskutiert zu werden. Unten sehen Sie ein Bild, das die BGP Finite State Machine (FSM) beschreibt:
Wenn ein ManualStart- oder AutomaticStart-Ereignis auf dem System auftritt und sich im Ruhezustand befindet, ändert es seinen Status in Connect. Die passiven Versionen dieser Ereignisse (ManualStart_with_PassiveTcpEstablishment oder AutomaticStart_with_PassiveTcpEstablishment) werden jedoch in Active geändert. Wenn es angewiesen wird, eine Verbindung zu einem Peer herzustellen, wechselt es grundsätzlich zu Connect. Wenn es jedoch aufgefordert wird, auf einen Peer zu warten, wechselt es zu Active.
Wenn im TC-Status die TCP-Verbindung fehlschlägt, Es ändert seinen Status in Aktiv, um auf eine Verbindung vom Peer zu warten.
Wenn im Status Aktiv das Ereignis ConnectRetryTimer_Expires auftritt, versucht es die TCP-Verbindung und wechselt in den Status Verbinden.
Es steckt wirklich viel mehr dahinter, aber es ist viel zu groß für eine Site wie diese.