Zum Hauptinhalt springen

8. BGP Finite State Machine (FSM) (BGP Endliche Zustandsmaschine)

  1. BGP Finite State Machine (FSM) (BGP Endliche Zustandsmaschine)

    Die in diesem Dokument beschriebenen Datenstrukturen und FSM sind konzeptionell und müssen nicht genau wie beschrieben implementiert werden, solange die Implementierungen die beschriebene Funktionalität unterstützen und das gleiche von außen sichtbare Verhalten zeigen.

    Dieser Abschnitt spezifiziert den BGP-Betrieb im Hinblick auf eine endliche Zustandsmaschine (Finite State Machine: FSM). Der Abschnitt gliedert sich in zwei Teile:

    1. Beschreibung der Ereignisse für die Zustandsmaschine (Abschnitt 8.1)
    2. Beschreibung der FSM (Abschnitt 8.2)

    Die für jede Verbindung erforderlichen (mandatory) Sitzungsattribute sind:

    1. State (Zustand)
    2. ConnectRetryCounter (Verbindungswiederholungszähler)
    3. ConnectRetryTimer (Verbindungswiederholungs-Timer)
    4. ConnectRetryTime (Verbindungswiederholungszeit)
    5. HoldTimer (Halte-Timer)
    6. HoldTime (Haltezeit)
    7. KeepaliveTimer (Keepalive-Timer)
    8. KeepaliveTime (Keepalive-Zeit)

    Das Zustands-Sitzungsattribut gibt den aktuellen Zustand der BGP-FSM an. Der ConnectRetryCounter gibt an, wie oft ein BGP-Peer versucht hat, eine Peer-Sitzung einzurichten.

    Die obligatorischen Attribute bezüglich Timer werden in Abschnitt 10 beschrieben. Jeder Timer hat einen "timer" und eine "time" (den Anfangswert).

    Die optionalen Sitzungsattribute sind unten aufgelistet. Diese optionalen Attribute können entweder pro Verbindung oder pro lokalem System unterstützt werden:

    1. AcceptConnectionsUnconfiguredPeers (Verbindungen unkonfigurierter Peers akzeptieren)
    2. AllowAutomaticStart (Automatischen Start erlauben)
    3. AllowAutomaticStop (Automatischen Stopp erlauben)
    4. CollisionDetectEstablishedState (Kollisionserkennung im Established-Zustand)
    5. DampPeerOscillations (Peer-Oszillationsdämpfung)
    6. DelayOpen (Verzögertes Öffnen)
    7. DelayOpenTime (Verzögerungsöffnungszeit)
    8. DelayOpenTimer (Verzögerungsöffnungs-Timer)
    9. IdleHoldTime (Idle-Haltezeit)
    10. IdleHoldTimer (Idle-Halte-Timer)
    11. PassiveTcpEstablishment (Passive TCP-Einrichtung)
    12. SendNOTIFICATIONwithoutOPEN (NOTIFICATION ohne OPEN senden)
    13. TrackTcpState (TCP-Zustand verfolgen)

    Die optionalen Sitzungsattribute unterstützen verschiedene Funktionen der BGP-Funktionalität, die Auswirkungen auf die BGP-FSM-Zustandsübergänge haben. Zwei Gruppen der Attribute, die sich auf Timer beziehen, sind:

    Gruppe 1: DelayOpen, DelayOpenTime, DelayOpenTimer Gruppe 2: DampPeerOscillations, IdleHoldTime, IdleHoldTimer

    Der erste Parameter (DelayOpen, DampPeerOscillations) ist ein optionales Attribut, das anzeigt, dass die Timer-Funktion aktiv ist. Der "Time"-Wert gibt den Anfangswert für den "Timer" (DelayOpenTime, IdleHoldTime) an. Der "Timer" gibt den tatsächlichen Timer an.

    Bitte beziehen Sie sich auf Abschnitt 8.1.1 für eine Erklärung der Interaktion zwischen diesen optionalen Attributen und den der Zustandsmaschine signalisierten Ereignissen. Abschnitt 8.2.1.3 bietet auch einen kurzen Überblick über die verschiedenen Arten optionaler Attribute (Flags oder Timer).

8.1. Events for the BGP FSM (Ereignisse für die BGP-FSM)

8.1.1. Optional Events Linked to Optional Session Attributes (Optionale Ereignisse verknüpft mit optionalen Sitzungsattributen)

Die Eingaben zur BGP-FSM sind Ereignisse. Ereignisse können entweder obligatorisch oder optional sein. Einige optionale Ereignisse sind mit optionalen Sitzungsattributen verknüpft. Optionale Sitzungsattribute aktivieren mehrere Gruppen von FSM-Funktionalität.

Die Verknüpfung zwischen FSM-Funktionalität, Ereignissen und den optionalen Sitzungsattributen wird unten beschrieben.

Gruppe 1: Automatische administrative Ereignisse (Start/Stop)

Optionale Sitzungsattribute: AllowAutomaticStart, AllowAutomaticStop, DampPeerOscillations, IdleHoldTime, IdleHoldTimer

Option 1: AllowAutomaticStart

Beschreibung: Eine BGP-Peer-Verbindung kann durch administrative Kontrolle gestartet und gestoppt werden. Diese administrative Kontrolle kann entweder manuell sein, basierend auf Operator-Intervention, oder unter der Kontrolle von Logik, die spezifisch für eine BGP-Implementierung ist. Der Begriff "automatisch" bezieht sich auf einen Start, der an die BGP-Peer-Verbindungs-FSM ausgegeben wird, wenn eine solche Logik bestimmt, dass die BGP-Peer-Verbindung neu gestartet werden sollte.

Das AllowAutomaticStart-Attribut spezifiziert, dass diese BGP-Verbindung automatisches Starten der BGP-Verbindung unterstützt.

Wenn die BGP-Implementierung AllowAutomaticStart unterstützt, kann der Peer wiederholt neu gestartet werden. Drei weitere Optionen steuern die Rate, mit der der automatische Neustart erfolgt: DampPeerOscillations, IdleHoldTime und IdleHoldTimer.

Die DampPeerOscillations-Option spezifiziert, dass die Implementierung zusätzliche Logik einsetzt, um die Oszillationen von BGP-Peers angesichts von Sequenzen von automatischem Start und automatischem Stopp zu dämpfen. IdleHoldTime spezifiziert die Zeitdauer, für die der BGP-Peer im Idle-Zustand gehalten wird, bevor der nächste automatische Neustart zugelassen wird. Der IdleHoldTimer ist der Timer, der den Peer im Idle-Zustand hält.

Ein Beispiel für DampPeerOscillations-Logik ist eine Erhöhung des IdleHoldTime-Werts, wenn ein BGP-Peer die Konnektivität (verbunden/getrennt) innerhalb eines Zeitraums wiederholt oszilliert. Um diese Logik zu aktivieren, könnte sich ein Peer 10 Mal innerhalb von 5 Minuten verbinden und trennen. Der IdleHoldTime-Wert würde von 0 auf 120 Sekunden zurückgesetzt.

Werte: TRUE oder FALSE

Option 2: AllowAutomaticStop

Beschreibung: Dieses optionale Attribut der BGP-Peer-Sitzung zeigt an, dass die BGP-Verbindung "automatisches" Stoppen der BGP-Verbindung erlaubt. Ein "automatischer" Stopp wird als Stopp unter der Kontrolle von implementierungsspezifischer Logik definiert. Die implementierungsspezifische Logik liegt außerhalb des Geltungsbereichs dieser Spezifikation.

Werte: TRUE oder FALSE

Option 3: DampPeerOscillations

Beschreibung: Das optionale Sitzungsattribut DampPeerOscillations zeigt an, dass die BGP-Verbindung Logik verwendet, die BGP-Peer-Oszillationen im Idle-Zustand dämpft.

Wert: TRUE oder FALSE

Option 4: IdleHoldTime

Beschreibung: Die IdleHoldTime ist der Wert, der im IdleHoldTimer gesetzt wird.

Werte: Zeit in Sekunden

Option 5: IdleHoldTimer

Beschreibung: Der IdleHoldTimer hilft bei der Kontrolle von BGP-Peer-Oszillationen. Der IdleHoldTimer wird verwendet, um den BGP-Peer für eine bestimmte Dauer in Idle zu halten. Das IdleHoldTimer_Expires-Ereignis wird in Abschnitt 8.1.3 beschrieben.

Werte: Zeit in Sekunden

Gruppe 2: Nicht konfigurierte Peers

Optionale Sitzungsattribute: AcceptConnectionsUnconfiguredPeers

Option 1: AcceptConnectionsUnconfiguredPeers

Beschreibung: Die BGP-FSM erlaubt optional die Annahme von BGP-Peer-Verbindungen von Nachbarn, die nicht vorkonfiguriert sind. Das optionale Sitzungsattribut "AcceptConnectionsUnconfiguredPeers" ermöglicht es der FSM, die Zustandsübergänge zu unterstützen, die es der Implementierung ermöglichen, diese nicht konfigurierten Peers zu akzeptieren oder abzulehnen.

AcceptConnectionsUnconfiguredPeers hat Sicherheitsauswirkungen. Bitte beziehen Sie sich auf das BGP-Schwachstellen-Dokument [RFC4272] für Details.

Wert: True oder False

Gruppe 3: TCP-Verarbeitung

Optionale Sitzungsattribute: PassiveTcpEstablishment, TrackTcpState

Option 1: PassiveTcpEstablishment

Beschreibung: Diese Option zeigt an, dass die BGP-FSM passiv darauf warten wird, dass der entfernte BGP-Peer die BGP-TCP-Verbindung einrichtet.

Wert: TRUE oder FALSE

Option 2: TrackTcpState

Beschreibung: Die BGP-FSM verfolgt normalerweise das Endergebnis eines TCP-Verbindungsversuchs anstelle einzelner TCP-Nachrichten. Optional kann die BGP-FSM zusätzliche Interaktion mit der TCP-Verbindungsaushandlung unterstützen. Die Interaktion mit den TCP-Ereignissen kann die Menge der Protokollierung erhöhen, die die BGP-Peer-Verbindung erfordert, und die Anzahl der BGP-FSM-Änderungen.

Wert: TRUE oder FALSE

Gruppe 4: BGP-Nachrichtenverarbeitung

Optionale Sitzungsattribute: DelayOpen, DelayOpenTime, DelayOpenTimer, SendNOTIFICATIONwithoutOPEN, CollisionDetectEstablishedState

Option 1: DelayOpen

Beschreibung: Das optionale Sitzungsattribut DelayOpen ermöglicht es Implementierungen, konfiguriert zu werden, um das Senden einer OPEN-Nachricht für einen bestimmten Zeitraum (DelayOpenTime) zu verzögern. Die Verzögerung gibt dem entfernten BGP-Peer Zeit, die erste OPEN-Nachricht zu senden.

Wert: TRUE oder FALSE

Option 2: DelayOpenTime

Beschreibung: Die DelayOpenTime ist der Anfangswert, der im DelayOpenTimer gesetzt wird.

Wert: Zeit in Sekunden

Option 3: DelayOpenTimer

Beschreibung: Das optionale Sitzungsattribut DelayOpenTimer wird verwendet, um das Senden einer OPEN-Nachricht auf einer Verbindung zu verzögern. Das DelayOpenTimer_Expires-Ereignis (Ereignis 12) wird in Abschnitt 8.1.3 beschrieben.

Wert: Zeit in Sekunden

Option 4: SendNOTIFICATIONwithoutOPEN

Beschreibung: SendNOTIFICATIONwithoutOPEN ermöglicht es einem Peer, eine NOTIFICATION zu senden, ohne zuerst eine OPEN-Nachricht zu senden. Ohne dieses optionale Sitzungsattribut nimmt die BGP-Verbindung an, dass eine OPEN-Nachricht von einem Peer gesendet werden muss, bevor der Peer eine NOTIFICATION-Nachricht sendet.

Wert: True oder False

Option 5: CollisionDetectEstablishedState

Beschreibung: Normalerweise wird eine Kollisionserkennung (siehe Abschnitt 6.8) im Established-Zustand ignoriert. Dieses optionale Sitzungsattribut zeigt an, dass diese BGP-Verbindung Kollisionen im Established-Zustand verarbeitet.

Wert: True oder False

Hinweis: Die optionalen Sitzungsattribute klären die BGP-FSM-Beschreibung für bestehende Funktionen von BGP-Implementierungen. Die optionalen Sitzungsattribute können für eine Implementierung vordefiniert sein und nicht über Verwaltungsschnittstellen für bestehende korrekte Implementierungen lesbar sein. Wenn neuere BGP-MIBs (Version 2 und darüber hinaus) unterstützt werden, werden diese Felder über eine Verwaltungsschnittstelle zugänglich sein.

8.1.2. Administrative Events (Administrative Ereignisse)

Ein administratives Ereignis ist ein Ereignis, bei dem die Operator-Schnittstelle und die BGP-Policy-Engine der BGP-endlichen Zustandsmaschine signalisieren, die BGP-Zustandsmaschine zu starten oder zu stoppen. Die grundlegenden Start- und Stopp-Anzeigen werden durch optionale Verbindungsattribute erweitert, die der BGP-FSM einen bestimmten Typ von Start- oder Stopp-Mechanismus signalisieren. Ein Beispiel für diese Kombination ist Ereignis 5, AutomaticStart_with_PassiveTcpEstablishment. Mit diesem Ereignis signalisiert die BGP-Implementierung der BGP-FSM, dass die Implementierung einen automatischen Start mit der Option zur Verwendung einer passiven TCP-Einrichtung verwendet. Die passive TCP-Einrichtung signalisiert, dass diese BGP-FSM darauf warten wird, dass die entfernte Seite die TCP-Einrichtung startet.

Beachten Sie, dass nur Ereignis 1 (ManualStart) und Ereignis 2 (ManualStop) obligatorische administrative Ereignisse sind. Alle anderen administrativen Ereignisse sind optional (Ereignisse 3-8). Jedes Ereignis unten hat einen Namen, eine Definition, einen Status (obligatorisch oder optional) und die optionalen Sitzungsattribute, die SOLLTEN (SHOULD) in jeder Phase gesetzt werden. Beim Generieren von Ereignis 1 bis Ereignis 8 für die BGP-FSM werden die im Abschnitt "Status optionaler Attribute" spezifizierten Bedingungen überprüft. Wenn eine dieser Bedingungen nicht erfüllt ist, sollte das lokale System einen FSM-Fehler protokollieren.

Die Einstellungen optionaler Sitzungsattribute können in einigen Implementierungen implizit sein und daher nicht explizit durch eine externe Operator-Aktion gesetzt werden. Abschnitt 8.2.1.5 beschreibt diese impliziten Einstellungen der optionalen Sitzungsattribute. Die unten beschriebenen administrativen Zustände können auch in einigen Implementierungen implizit sein und nicht direkt durch einen externen Operator konfigurierbar sein.

Ereignis 1: ManualStart (Manueller Start)

Definition: Der Systemadministrator des lokalen Systems startet die Peer-Verbindung manuell.

Status: Obligatorisch

Status optionaler Attribute: Das PassiveTcpEstablishment-Attribut SOLLTE (SHOULD) auf FALSE gesetzt werden.

Ereignis 2: ManualStop (Manueller Stopp)

Definition: Der Systemadministrator des lokalen Systems stoppt die Peer-Verbindung manuell.

Status: Obligatorisch

Status optionaler Attribute: Keine Interaktion mit optionalen Attributen.

Ereignis 3: AutomaticStart (Automatischer Start)

Definition: Das lokale System startet die BGP-Verbindung automatisch.

Status: Optional, abhängig vom lokalen System

Status optionaler Attribute: 1) Das AllowAutomaticStart-Attribut SOLLTE (SHOULD) auf TRUE gesetzt werden, wenn dieses Ereignis auftritt. 2) Wenn das optionale Sitzungsattribut PassiveTcpEstablishment unterstützt wird, SOLLTE (SHOULD) es auf FALSE gesetzt werden. 3) Wenn DampPeerOscillations unterstützt wird, SOLLTE (SHOULD) es auf FALSE gesetzt werden, wenn dieses Ereignis auftritt.

Ereignis 4: ManualStart_with_PassiveTcpEstablishment (Manueller Start mit passiver TCP-Einrichtung)

Definition: Der Systemadministrator des lokalen Systems startet die Peer-Verbindung manuell, hat aber PassiveTcpEstablishment aktiviert. Das optionale Attribut PassiveTcpEstablishment zeigt an, dass der Peer lauschen wird, bevor die Verbindung eingerichtet wird.

Status: Optional, abhängig vom lokalen System

Status optionaler Attribute: 1) Das PassiveTcpEstablishment-Attribut SOLLTE (SHOULD) auf TRUE gesetzt werden, wenn dieses Ereignis auftritt. 2) Das DampPeerOscillations-Attribut SOLLTE (SHOULD) auf FALSE gesetzt werden, wenn dieses Ereignis auftritt.

Ereignis 5: AutomaticStart_with_PassiveTcpEstablishment (Automatischer Start mit passiver TCP-Einrichtung)

Definition: Das lokale System startet die BGP-Verbindung automatisch mit aktiviertem PassiveTcpEstablishment. Das optionale Attribut PassiveTcpEstablishment zeigt an, dass der Peer lauschen wird, bevor eine Verbindung eingerichtet wird.

Status: Optional, abhängig vom lokalen System

Status optionaler Attribute: 1) Das AllowAutomaticStart-Attribut SOLLTE (SHOULD) auf TRUE gesetzt werden. 2) Das PassiveTcpEstablishment-Attribut SOLLTE (SHOULD) auf TRUE gesetzt werden. 3) Wenn das DampPeerOscillations-Attribut unterstützt wird, SOLLTE (SHOULD) DampPeerOscillations auf FALSE gesetzt werden.

Ereignis 6: AutomaticStart_with_DampPeerOscillations (Automatischer Start mit Peer-Oszillationsdämpfung)

Definition: Das lokale System startet die BGP-Peer-Verbindung automatisch mit aktivierter Peer-Oszillationsdämpfung. Die genaue Methode zur Dämpfung persistenter Peer-Oszillationen wird durch die Implementierung bestimmt und liegt außerhalb des Geltungsbereichs dieses Dokuments.

Status: Optional, abhängig vom lokalen System.

Status optionaler Attribute: 1) Das AllowAutomaticStart-Attribut SOLLTE (SHOULD) auf TRUE gesetzt werden. 2) Das DampPeerOscillations-Attribut SOLLTE (SHOULD) auf TRUE gesetzt werden. 3) Das PassiveTcpEstablishment-Attribut SOLLTE (SHOULD) auf FALSE gesetzt werden.

Ereignis 7: AutomaticStart_with_DampPeerOscillations_and_ PassiveTcpEstablishment (Automatischer Start mit Peer-Oszillationsdämpfung und passiver TCP-Einrichtung)

Definition: Das lokale System startet die BGP-Peer-Verbindung automatisch mit aktivierter Peer-Oszillationsdämpfung und aktiviertem PassiveTcpEstablishment. Die genaue Methode zur Dämpfung persistenter Peer-Oszillationen wird durch die Implementierung bestimmt und liegt außerhalb des Geltungsbereichs dieses Dokuments.

Status: Optional, abhängig vom lokalen System

Status optionaler Attribute: 1) Das AllowAutomaticStart-Attribut SOLLTE (SHOULD) auf TRUE gesetzt werden. 2) Das DampPeerOscillations-Attribut SOLLTE (SHOULD) auf TRUE gesetzt werden. 3) Das PassiveTcpEstablishment-Attribut SOLLTE (SHOULD) auf TRUE gesetzt werden.

Ereignis 8: AutomaticStop (Automatischer Stopp)

Definition: Das lokale System stoppt die BGP-Verbindung automatisch.

Ein Beispiel für ein automatisches Stopp-Ereignis ist das Überschreiten der Anzahl von Präfixen für einen gegebenen Peer und das lokale System trennt den Peer automatisch.

Status: Optional, abhängig vom lokalen System

Status optionaler Attribute: 1) Das AllowAutomaticStop-Attribut SOLLTE (SHOULD) TRUE sein.

8.1.3. Timer Events (Timer-Ereignisse)

Ereignis 9: ConnectRetryTimer_Expires (Ablauf des Verbindungswiederholungs-Timers)

Definition: Ein Ereignis, das generiert wird, wenn der ConnectRetryTimer abläuft.

Status: Obligatorisch

Ereignis 10: HoldTimer_Expires (Ablauf des Halte-Timers)

Definition: Ein Ereignis, das generiert wird, wenn der HoldTimer abläuft.

Status: Obligatorisch

Ereignis 11: KeepaliveTimer_Expires (Ablauf des Keepalive-Timers)

Definition: Ein Ereignis, das generiert wird, wenn der KeepaliveTimer abläuft.

Status: Obligatorisch

Ereignis 12: DelayOpenTimer_Expires (Ablauf des Verzögerungsöffnungs-Timers)

Definition: Ein Ereignis, das generiert wird, wenn der DelayOpenTimer abläuft.

Status: Optional

Status optionaler Attribute: Wenn dieses Ereignis auftritt,

  1. SOLLTE (SHOULD) das DelayOpen-Attribut auf TRUE gesetzt werden,
  2. SOLLTE (SHOULD) das DelayOpenTime-Attribut unterstützt werden,
  3. SOLLTE (SHOULD) der DelayOpenTimer unterstützt werden.

Ereignis 13: IdleHoldTimer_Expires (Ablauf des Idle-Halte-Timers)

Definition: Ein Ereignis, das generiert wird, wenn der IdleHoldTimer abläuft und anzeigt, dass die BGP-Verbindung das Warten auf die Back-off-Periode abgeschlossen hat, um BGP-Peer-Oszillationen zu verhindern.

Der IdleHoldTimer wird nur verwendet, wenn die Funktion zur Dämpfung persistenter Peer-Oszillationen aktiviert ist, indem das optionale Attribut DampPeerOscillations auf TRUE gesetzt wird.

Implementierungen, die die Funktion zur Dämpfung persistenter Peer-Oszillationen nicht implementieren, haben möglicherweise keinen IdleHoldTimer.

Status: Optional

Status optionaler Attribute: Wenn dieses Ereignis auftritt:

  1. SOLLTE (SHOULD) das DampPeerOscillations-Attribut auf TRUE gesetzt werden.
  2. SOLLTE (SHOULD) der IdleHoldTimer gerade abgelaufen sein.

8.1.4. TCP Connection-Based Events (TCP-verbindungsbasierte Ereignisse)

Ereignis 14: TcpConnection_Valid (TCP-Verbindung gültig)

Definition: Ereignis, das den Empfang einer TCP-Verbindungsanfrage mit einer gültigen Quell-IP-Adresse, TCP-Port, Ziel-IP-Adresse und TCP-Port durch das lokale System anzeigt. Die Definition einer ungültigen Quell- und ungültigen Ziel-IP-Adresse wird durch die Implementierung bestimmt.

Der Zielport von BGP SOLLTE (SHOULD) Port 179 sein, wie von IANA definiert.

Eine TCP-Verbindungsanfrage wird durch das lokale System bezeichnet, das ein TCP-SYN empfängt.

Status: Optional

Status optionaler Attribute: 1) Das TrackTcpState-Attribut SOLLTE (SHOULD) auf TRUE gesetzt werden, wenn dieses Ereignis auftritt.

Ereignis 15: Tcp_CR_Invalid (TCP-Verbindungsanfrage ungültig)

Definition: Ereignis, das den Empfang einer TCP-Verbindungsanfrage mit entweder einer ungültigen Quelladresse oder Portnummer oder einer ungültigen Zieladresse oder Portnummer durch das lokale System anzeigt.

Die BGP-Zielportnummer SOLLTE (SHOULD) 179 sein, wie von IANA definiert.

Eine TCP-Verbindungsanfrage tritt auf, wenn das lokale System ein TCP-SYN empfängt.

Status: Optional

Status optionaler Attribute: 1) Das TrackTcpState-Attribut sollte auf TRUE gesetzt werden, wenn dieses Ereignis auftritt.

Ereignis 16: Tcp_CR_Acked (TCP-Verbindungsanfrage bestätigt)

Definition: Ereignis, das die Anfrage des lokalen Systems anzeigt, eine TCP-Verbindung zum entfernten Peer einzurichten.

Die TCP-Verbindung des lokalen Systems hat ein TCP-SYN gesendet, eine TCP-SYN/ACK-Nachricht empfangen und ein TCP-ACK gesendet.

Status: Obligatorisch

Ereignis 17: TcpConnectionConfirmed (TCP-Verbindung bestätigt)

Definition: Ereignis, das anzeigt, dass das lokale System eine Bestätigung erhalten hat, dass die TCP-Verbindung durch die entfernte Site eingerichtet wurde.

Die TCP-Engine des entfernten Peers hat ein TCP-SYN gesendet. Die TCP-Engine des lokalen Peers hat eine SYN-, ACK-Nachricht gesendet und hat nun ein finales ACK empfangen.

Status: Obligatorisch

Ereignis 18: TcpConnectionFails (TCP-Verbindung schlägt fehl)

Definition: Ereignis, das anzeigt, dass das lokale System eine Benachrichtigung über einen TCP-Verbindungsfehler erhalten hat.

Die TCP-Maschine des entfernten BGP-Peers hätte ein FIN senden können. Der lokale Peer würde mit einem FIN-ACK antworten. Eine andere Möglichkeit ist, dass der lokale Peer einen Timeout in der TCP-Verbindung angezeigt und die Verbindung heruntergefahren hat.

Status: Obligatorisch

8.1.5. BGP Message-Based Events (BGP-nachrichtenbasierte Ereignisse)

Ereignis 19: BGPOpen

Definition: Ein Ereignis wird generiert, wenn eine gültige OPEN-Nachricht empfangen wurde.

Status: Obligatorisch

Status optionaler Attribute: 1) Das optionale Attribut DelayOpen SOLLTE (SHOULD) auf FALSE gesetzt werden. 2) Der DelayOpenTimer SOLLTE (SHOULD) NICHT laufen.

Ereignis 20: BGPOpen with DelayOpenTimer running (BGPOpen mit laufendem DelayOpenTimer)

Definition: Ein Ereignis wird generiert, wenn eine gültige OPEN-Nachricht für einen Peer empfangen wurde, der eine erfolgreich eingerichtete Transportverbindung hat und derzeit das Senden einer BGP-Open-Nachricht verzögert.

Status: Optional

Status optionaler Attribute: 1) Das DelayOpen-Attribut SOLLTE (SHOULD) auf TRUE gesetzt werden. 2) Der DelayOpenTimer SOLLTE (SHOULD) laufen.

Ereignis 21: BGPHeaderErr (BGP-Header-Fehler)

Definition: Ein Ereignis wird generiert, wenn ein empfangener BGP-Nachrichten-Header nicht gültig ist.

Status: Obligatorisch

Ereignis 22: BGPOpenMsgErr (BGP-Open-Nachrichten-Fehler)

Definition: Ein Ereignis wird generiert, wenn eine OPEN-Nachricht mit Fehlern empfangen wurde.

Status: Obligatorisch

Ereignis 23: OpenCollisionDump (Open-Kollisions-Dump)

Definition: Ein administrativ generiertes Ereignis, wenn eine Verbindungskollision während der Verarbeitung einer eingehenden OPEN-Nachricht erkannt wurde und diese Verbindung ausgewählt wurde, um getrennt zu werden. Siehe Abschnitt 6.8 für weitere Informationen zur Kollisionserkennung.

Ereignis 23 ist eine administrative Aktion, die durch Implementierungslogik generiert wird, die bestimmt, ob diese Verbindung gemäß den Regeln in Abschnitt 6.8 fallen gelassen werden muss. Dieses Ereignis kann auftreten, wenn die FSM als zwei verknüpfte Zustandsmaschinen implementiert ist.

Status: Optional

Status optionaler Attribute: Wenn die Zustandsmaschine dieses Ereignis im Established-Zustand verarbeiten soll,

  1. SOLLTE (SHOULD) das optionale Attribut CollisionDetectEstablishedState auf TRUE gesetzt werden.

Bitte beachten Sie: Das OpenCollisionDump-Ereignis kann in Idle, Connect, Active, OpenSent und OpenConfirm auftreten, ohne dass optionale Attribute gesetzt sind.

Ereignis 24: NotifMsgVerErr (Benachrichtigungsnachricht-Versionsfehler)

Definition: Ein Ereignis wird generiert, wenn eine NOTIFICATION-Nachricht mit "Versionsfehler" empfangen wird.

Status: Obligatorisch

Ereignis 25: NotifMsg (Benachrichtigungsnachricht)

Definition: Ein Ereignis wird generiert, wenn eine NOTIFICATION-Nachricht empfangen wird und der Fehlercode nicht "Versionsfehler" ist.

Status: Obligatorisch

Ereignis 26: KeepAliveMsg (Keepalive-Nachricht)

Definition: Ein Ereignis wird generiert, wenn eine KEEPALIVE-Nachricht empfangen wird.

Status: Obligatorisch

Ereignis 27: UpdateMsg (Update-Nachricht)

Definition: Ein Ereignis wird generiert, wenn eine gültige UPDATE-Nachricht empfangen wird.

Status: Obligatorisch

Ereignis 28: UpdateMsgErr (Update-Nachrichten-Fehler)

Definition: Ein Ereignis wird generiert, wenn eine ungültige UPDATE-Nachricht empfangen wird.

Status: Obligatorisch

8.2. Description of FSM (Beschreibung der FSM)

8.2.1. FSM Definition (FSM-Definition)

BGP MUSS (MUST) eine separate FSM für jeden konfigurierten Peer aufrechterhalten. Jeder BGP-Peer, der in einer potenziellen Verbindung gepaart ist, wird versuchen, sich mit dem anderen zu verbinden, es sei denn, er ist so konfiguriert, dass er im Idle-Zustand verbleibt, oder so konfiguriert, dass er passiv bleibt. Für den Zweck dieser Diskussion wird die aktive oder verbindende Seite der TCP-Verbindung (die Seite einer TCP-Verbindung, die das erste TCP-SYN-Paket sendet) als ausgehend bezeichnet. Die passive oder lauschende Seite (der Absender des ersten SYN/ACK) wird als eingehende Verbindung bezeichnet. (Siehe Abschnitt 8.2.1.1 für Informationen zu den unten verwendeten Begriffen aktiv und passiv.)

Eine BGP-Implementierung MUSS (MUST) sich mit dem TCP-Port 179 verbinden und darauf lauschen, um eingehende Verbindungen zu empfangen, zusätzlich zum Versuch, sich mit Peers zu verbinden. Für jede eingehende Verbindung MUSS (MUST) eine Zustandsmaschine instanziiert werden. Es gibt eine Periode, in der die Identität des Peers am anderen Ende einer eingehenden Verbindung bekannt ist, aber der BGP-Identifikator nicht bekannt ist. Während dieser Zeit können sowohl eine eingehende als auch eine ausgehende Verbindung für dasselbe konfigurierte Peering existieren. Dies wird als Verbindungskollision bezeichnet (siehe Abschnitt 6.8).

Eine BGP-Implementierung wird höchstens eine FSM für jedes konfigurierte Peering haben, plus eine FSM für jede eingehende TCP-Verbindung, für die der Peer noch nicht identifiziert wurde. Jede FSM entspricht genau einer TCP-Verbindung.

Es kann mehr als eine Verbindung zwischen einem Paar von Peers geben, wenn die Verbindungen so konfiguriert sind, dass sie ein anderes Paar von IP-Adressen verwenden. Dies wird als mehrere "konfigurierte Peerings" zum gleichen Peer bezeichnet.

8.2.1.1. Terms "active" and "passive" (Begriffe "aktiv" und "passiv")

Die Begriffe aktiv und passiv sind seit fast einem Jahrzehnt im Vokabular der Internet-Betreiber und haben sich als nützlich erwiesen. Die Wörter aktiv und passiv haben leicht unterschiedliche Bedeutungen, wenn sie auf eine TCP-Verbindung oder einen Peer angewendet werden. Es gibt nur eine aktive Seite und eine passive Seite zu jeder TCP-Verbindung, gemäß der obigen Definition und der untenstehenden Zustandsmaschine. Wenn ein BGP-Speaker als aktiv konfiguriert ist, kann er auf der aktiven oder passiven Seite der Verbindung enden, die schließlich eingerichtet wird. Sobald die TCP-Verbindung abgeschlossen ist, spielt es keine Rolle, welches Ende aktiv und welches passiv war. Der einzige Unterschied besteht darin, auf welcher Seite der TCP-Verbindung die Portnummer 179 liegt.

8.2.1.2. FSM and Collision Detection (FSM und Kollisionserkennung)

Es gibt eine FSM pro BGP-Verbindung. Wenn die Verbindungskollision auftritt, bevor bestimmt wird, mit welchem Peer eine Verbindung verbunden ist, können zwei Verbindungen für einen Peer existieren. Nach der Auflösung der Verbindungskollision (siehe Abschnitt 6.8) SOLLTE (SHOULD) die FSM für die geschlossene Verbindung entsorgt werden.

8.2.1.3. FSM and Optional Session Attributes (FSM und optionale Sitzungsattribute)

Optionale Sitzungsattribute spezifizieren entweder Attribute, die als Flags fungieren (TRUE oder FALSE), oder optionale Timer. Für optionale Attribute, die als Flags fungieren, müssen, wenn das optionale Sitzungsattribut auf dem System auf TRUE gesetzt werden kann, die entsprechenden BGP-FSM-Aktionen unterstützt werden. Wenn beispielsweise die folgenden Optionen in einer BGP-Implementierung gesetzt werden können: AutoStart und PassiveTcpEstablishment, dann müssen die Ereignisse 3, 4 und 5 unterstützt werden. Wenn ein optionales Sitzungsattribut nicht auf TRUE gesetzt werden kann, müssen die Ereignisse, die diesen Optionssatz unterstützen, nicht unterstützt werden.

Jeder der optionalen Timer (DelayOpenTimer und IdleHoldTimer) hat eine Gruppe von Attributen, die sind:

  • Flag, das Unterstützung anzeigt,
  • Im Timer gesetzte Zeit
  • Timer.

Die zwei optionalen Timer zeigen dieses Format:

DelayOpenTimer: DelayOpen, DelayOpenTime, DelayOpenTimer IdleHoldTimer: DampPeerOscillations, IdleHoldTime, IdleHoldTimer

Wenn das Flag, das die Unterstützung für einen optionalen Timer anzeigt (DelayOpen oder DampPeerOscillations), nicht auf TRUE gesetzt werden kann, müssen die Timer und Ereignisse, die diese Option unterstützen, nicht unterstützt werden.

8.2.1.4. FSM Event Numbers (FSM-Ereignisnummern)

Die in dieser Zustandsmaschinenbeschreibung verwendeten Ereignisnummern (1-28) helfen bei der Spezifikation des Verhaltens der BGP-Zustandsmaschine. Implementierungen KÖNNEN (MAY) diese Nummern verwenden, um Netzwerkverwaltungsinformationen bereitzustellen. Die genaue Form einer FSM oder der FSM-Ereignisse ist spezifisch für jede Implementierung.

8.2.1.5. FSM Actions that are Implementation Dependent (FSM-Aktionen, die implementierungsabhängig sind)

An bestimmten Punkten spezifiziert die BGP-FSM, dass BGP-Initialisierung stattfinden wird oder dass BGP-Ressourcen gelöscht werden. Die Initialisierung der BGP-FSM und der zugehörigen Ressourcen hängt vom Policy-Teil der BGP-Implementierung ab. Die Details dieser Aktionen liegen außerhalb des Geltungsbereichs des FSM-Dokuments.

8.2.2. Finite State Machine (Endliche Zustandsmaschine)

Idle-Zustand:

Anfänglich befindet sich die BGP-Peer-FSM im Idle-Zustand. Im Folgenden wird die BGP-Peer-FSM auf BGP-FSM verkürzt.

In diesem Zustand lehnt die BGP-FSM alle eingehenden BGP-Verbindungen für diesen Peer ab. Es werden keine Ressourcen dem Peer zugewiesen. Als Reaktion auf ein ManualStart-Ereignis (Ereignis 1) oder ein AutomaticStart-Ereignis (Ereignis 3) führt das lokale System Folgendes aus:

  • initialisiert alle BGP-Ressourcen für die Peer-Verbindung,

  • setzt ConnectRetryCounter auf Null,

  • startet den ConnectRetryTimer mit dem Anfangswert,

  • initiiert eine TCP-Verbindung zum anderen BGP-Peer,

  • lauscht auf eine Verbindung, die vom entfernten BGP-Peer initiiert werden kann, und

  • ändert seinen Zustand zu Connect.

Das ManualStop-Ereignis (Ereignis 2) und das AutomaticStop-Ereignis (Ereignis 8) werden im Idle-Zustand ignoriert.

Als Reaktion auf ein ManualStart_with_PassiveTcpEstablishment-Ereignis (Ereignis 4) oder ein AutomaticStart_with_PassiveTcpEstablishment-Ereignis (Ereignis 5) führt das lokale System Folgendes aus:

  • initialisiert alle BGP-Ressourcen,

  • setzt den ConnectRetryCounter auf Null,

  • startet den ConnectRetryTimer mit dem Anfangswert,

  • lauscht auf eine Verbindung, die vom entfernten Peer initiiert werden kann, und

  • ändert seinen Zustand zu Active.

Der genaue Wert des ConnectRetryTimers ist eine lokale Angelegenheit, aber er SOLLTE (SHOULD) ausreichend groß sein, um die TCP-Initialisierung zu ermöglichen.

Wenn das DampPeerOscillations-Attribut auf TRUE gesetzt ist, können die folgenden drei zusätzlichen Ereignisse im Idle-Zustand auftreten:

  • AutomaticStart_with_DampPeerOscillations (Ereignis 6),

  • AutomaticStart_with_DampPeerOscillations_and_ PassiveTcpEstablishment (Ereignis 7),

  • IdleHoldTimer_Expires (Ereignis 13).

Beim Empfang dieser 3 Ereignisse wird das lokale System diese Ereignisse verwenden, um Peer-Oszillationen zu verhindern. Die Methode zur Verhinderung persistenter Peer-Oszillationen liegt außerhalb des Geltungsbereichs dieses Dokuments.

Jedes andere Ereignis (Ereignisse 9-12, 15-28), das im Idle-Zustand empfangen wird, verursacht keine Änderung im Zustand des lokalen Systems.

Connect-Zustand:

In diesem Zustand wartet die BGP-FSM darauf, dass die TCP-Verbindung abgeschlossen wird.

Die Start-Ereignisse (Ereignisse 1, 3-7) werden im Connect-Zustand ignoriert.

Als Reaktion auf ein ManualStop-Ereignis (Ereignis 2) führt das lokale System Folgendes aus:

  • lässt die TCP-Verbindung fallen,

  • gibt alle BGP-Ressourcen frei,

  • setzt ConnectRetryCounter auf Null,

  • stoppt den ConnectRetryTimer und setzt ConnectRetryTimer auf Null, und

  • ändert seinen Zustand zu Idle.

Als Reaktion auf das ConnectRetryTimer_Expires-Ereignis (Ereignis 9) führt das lokale System Folgendes aus:

  • lässt die TCP-Verbindung fallen,

  • startet den ConnectRetryTimer neu,

  • stoppt den DelayOpenTimer und setzt den Timer auf Null zurück,

  • initiiert eine TCP-Verbindung zum anderen BGP-Peer,

  • lauscht weiter auf eine Verbindung, die vom entfernten BGP-Peer initiiert werden kann, und

  • bleibt im Connect-Zustand.

Wenn das DelayOpenTimer_Expires-Ereignis (Ereignis 12) im Connect-Zustand auftritt, führt das lokale System Folgendes aus:

  • sendet eine OPEN-Nachricht an seinen Peer,

  • setzt den HoldTimer auf einen großen Wert, und

  • ändert seinen Zustand zu OpenSent.

Wenn die BGP-FSM ein TcpConnection_Valid-Ereignis (Ereignis 14) empfängt, wird die TCP-Verbindung verarbeitet, und die Verbindung bleibt im Connect-Zustand.

Wenn die BGP-FSM ein Tcp_CR_Invalid-Ereignis (Ereignis 15) empfängt, lehnt das lokale System die TCP-Verbindung ab, und die Verbindung bleibt im Connect-Zustand.

Wenn die TCP-Verbindung erfolgreich ist (Ereignis 16 oder Ereignis 17), überprüft das lokale System das DelayOpen-Attribut vor der Verarbeitung. Wenn das DelayOpen-Attribut auf TRUE gesetzt ist, führt das lokale System Folgendes aus:

  • stoppt den ConnectRetryTimer (falls laufend) und setzt den ConnectRetryTimer auf Null,

  • setzt den DelayOpenTimer auf den Anfangswert, und

  • bleibt im Connect-Zustand.

Wenn das DelayOpen-Attribut auf FALSE gesetzt ist, führt das lokale System Folgendes aus:

  • stoppt den ConnectRetryTimer (falls laufend) und setzt den ConnectRetryTimer auf Null,

  • schließt die BGP-Initialisierung ab

  • sendet eine OPEN-Nachricht an seinen Peer,

  • setzt den HoldTimer auf einen großen Wert, und

  • ändert seinen Zustand zu OpenSent.

Ein HoldTimer-Wert von 4 Minuten wird vorgeschlagen.

Wenn die TCP-Verbindung fehlschlägt (Ereignis 18), überprüft das lokale System den DelayOpenTimer. Wenn der DelayOpenTimer läuft, führt das lokale System Folgendes aus:

  • startet den ConnectRetryTimer mit dem Anfangswert neu,

  • stoppt den DelayOpenTimer und setzt seinen Wert auf Null zurück,

  • lauscht weiter auf eine Verbindung, die vom entfernten BGP-Peer initiiert werden kann, und

  • ändert seinen Zustand zu Active.

Wenn der DelayOpenTimer nicht läuft, führt das lokale System Folgendes aus:

  • stoppt den ConnectRetryTimer auf Null,

  • lässt die TCP-Verbindung fallen,

  • gibt alle BGP-Ressourcen frei, und

  • ändert seinen Zustand zu Idle.

Wenn eine OPEN-Nachricht empfangen wird, während der DelayOpenTimer läuft (Ereignis 20), führt das lokale System Folgendes aus:

  • stoppt den ConnectRetryTimer (falls laufend) und setzt den ConnectRetryTimer auf Null,

  • schließt die BGP-Initialisierung ab,

  • stoppt und löscht den DelayOpenTimer (setzt den Wert auf Null),

  • sendet eine OPEN-Nachricht,

  • sendet eine KEEPALIVE-Nachricht,

  • wenn der Anfangswert des HoldTimers nicht null ist,

    • startet den KeepaliveTimer mit dem Anfangswert und

    • setzt den HoldTimer auf den ausgehandelten Wert zurück,

    ansonsten, wenn der Anfangswert des HoldTimers null ist,

    • setzt den KeepaliveTimer zurück und

    • setzt den HoldTimer-Wert auf Null zurück,

  • und ändert seinen Zustand zu OpenConfirm.

Wenn der Wert des Autonomous-System-Feldes mit der lokalen Autonomous-System-Nummer übereinstimmt, setzen Sie den Verbindungsstatus auf eine interne Verbindung; andernfalls wird es "extern" sein.

Wenn die BGP-Nachrichten-Header-Überprüfung (Ereignis 21) oder die OPEN-Nachrichten-Überprüfung einen Fehler erkennt (Ereignis 22) (siehe Abschnitt 6.2), führt das lokale System Folgendes aus:

  • (optional) Wenn das SendNOTIFICATIONwithoutOPEN-Attribut auf TRUE gesetzt ist, sendet das lokale System zuerst eine NOTIFICATION-Nachricht mit dem entsprechenden Fehlercode, und dann

  • stoppt den ConnectRetryTimer (falls laufend) und setzt den ConnectRetryTimer auf Null,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen,

  • erhöht den ConnectRetryCounter um 1,

  • (optional) führt Peer-Oszillationsdämpfung durch, wenn das DampPeerOscillations-Attribut auf TRUE gesetzt ist, und

  • ändert seinen Zustand zu Idle.

Wenn eine NOTIFICATION-Nachricht mit einem Versionsfehler empfangen wird (Ereignis 24), überprüft das lokale System den DelayOpenTimer. Wenn der DelayOpenTimer läuft, führt das lokale System Folgendes aus:

  • stoppt den ConnectRetryTimer (falls laufend) und setzt den ConnectRetryTimer auf Null,

  • stoppt und setzt den DelayOpenTimer zurück (setzt auf Null),

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen, und

  • ändert seinen Zustand zu Idle.

Wenn der DelayOpenTimer nicht läuft, führt das lokale System Folgendes aus:

  • stoppt den ConnectRetryTimer und setzt den ConnectRetryTimer auf Null,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen,

  • erhöht den ConnectRetryCounter um 1,

  • führt Peer-Oszillationsdämpfung durch, wenn das DampPeerOscillations-Attribut auf True gesetzt ist, und

  • ändert seinen Zustand zu Idle.

Als Reaktion auf alle anderen Ereignisse (Ereignisse 8, 10-11, 13, 19, 23, 25-28) führt das lokale System Folgendes aus:

  • wenn der ConnectRetryTimer läuft, stoppt und setzt den ConnectRetryTimer zurück (setzt auf Null),

  • wenn der DelayOpenTimer läuft, stoppt und setzt den DelayOpenTimer zurück (setzt auf Null),

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen,

  • erhöht den ConnectRetryCounter um 1,

  • führt Peer-Oszillationsdämpfung durch, wenn das DampPeerOscillations-Attribut auf True gesetzt ist, und

  • ändert seinen Zustand zu Idle.

Active-Zustand:

In diesem Zustand versucht die BGP-FSM, einen Peer zu erwerben, indem sie auf eine TCP-Verbindung lauscht und diese akzeptiert.

Die Start-Ereignisse (Ereignisse 1, 3-7) werden im Active-Zustand ignoriert.

Als Reaktion auf ein ManualStop-Ereignis (Ereignis 2) führt das lokale System Folgendes aus:

  • Wenn der DelayOpenTimer läuft und das SendNOTIFICATIONwithoutOPEN-Sitzungsattribut gesetzt ist, sendet das lokale System eine NOTIFICATION mit Cease,

  • gibt alle BGP-Ressourcen frei, einschließlich des Stoppens des DelayOpenTimers

  • lässt die TCP-Verbindung fallen,

  • setzt ConnectRetryCounter auf Null,

  • stoppt den ConnectRetryTimer und setzt den ConnectRetryTimer auf Null, und

  • ändert seinen Zustand zu Idle.

Als Reaktion auf ein ConnectRetryTimer_Expires-Ereignis (Ereignis 9) führt das lokale System Folgendes aus:

  • startet den ConnectRetryTimer (mit Anfangswert) neu,

  • initiiert eine TCP-Verbindung zum anderen BGP-Peer,

  • lauscht weiter auf eine TCP-Verbindung, die von einem entfernten BGP-Peer initiiert werden kann, und

  • ändert seinen Zustand zu Connect.

Wenn das lokale System ein DelayOpenTimer_Expires-Ereignis (Ereignis 12) empfängt, führt das lokale System Folgendes aus:

  • setzt den ConnectRetryTimer auf Null,

  • stoppt und löscht den DelayOpenTimer (setzt auf Null),

  • schließt die BGP-Initialisierung ab,

  • sendet die OPEN-Nachricht an seinen entfernten Peer,

  • setzt seinen Hold-Timer auf einen großen Wert, und

  • ändert seinen Zustand zu OpenSent.

Ein HoldTimer-Wert von 4 Minuten wird auch für diesen Zustandsübergang vorgeschlagen.

Wenn das lokale System ein TcpConnection_Valid-Ereignis (Ereignis 14) empfängt, verarbeitet das lokale System die TCP-Verbindungs-Flags und bleibt im Active-Zustand.

Wenn das lokale System ein Tcp_CR_Invalid-Ereignis (Ereignis 15) empfängt, lehnt das lokale System die TCP-Verbindung ab und bleibt im Active-Zustand.

Als Reaktion auf den Erfolg einer TCP-Verbindung (Ereignis 16 oder Ereignis 17) überprüft das lokale System das optionale DelayOpen-Attribut vor der Verarbeitung.

Wenn das DelayOpen-Attribut auf TRUE gesetzt ist, führt das lokale System Folgendes aus:

  • stoppt den ConnectRetryTimer und setzt den ConnectRetryTimer auf Null,

  • setzt den DelayOpenTimer auf den Anfangswert (DelayOpenTime), und

  • bleibt im Active-Zustand.

Wenn das DelayOpen-Attribut auf FALSE gesetzt ist, führt das lokale System Folgendes aus:

  • setzt den ConnectRetryTimer auf Null,

  • schließt die BGP-Initialisierung ab,

  • sendet die OPEN-Nachricht an seinen Peer,

  • setzt seinen HoldTimer auf einen großen Wert, und

  • ändert seinen Zustand zu OpenSent.

Ein HoldTimer-Wert von 4 Minuten wird als "großer Wert" für den HoldTimer vorgeschlagen.

Wenn das lokale System ein TcpConnectionFails-Ereignis (Ereignis 18) empfängt, führt das lokale System Folgendes aus:

  • startet den ConnectRetryTimer (mit dem Anfangswert) neu,

  • stoppt und löscht den DelayOpenTimer (setzt den Wert auf Null),

  • gibt alle BGP-Ressourcen frei,

  • erhöht den ConnectRetryCounter um 1,

  • führt optional Peer-Oszillationsdämpfung durch, wenn das DampPeerOscillations-Attribut auf TRUE gesetzt ist, und

  • ändert seinen Zustand zu Idle.

Wenn eine OPEN-Nachricht empfangen wird und der DelayOpenTimer läuft (Ereignis 20), führt das lokale System Folgendes aus:

  • stoppt den ConnectRetryTimer (falls laufend) und setzt den ConnectRetryTimer auf Null,

  • stoppt und löscht den DelayOpenTimer (setzt auf Null),

  • schließt die BGP-Initialisierung ab,

  • sendet eine OPEN-Nachricht,

  • sendet eine KEEPALIVE-Nachricht,

  • wenn der HoldTimer-Wert nicht null ist,

    • startet den KeepaliveTimer auf den Anfangswert,

    • setzt den HoldTimer auf den ausgehandelten Wert zurück,

    ansonsten, wenn der HoldTimer null ist

    • setzt den KeepaliveTimer zurück (setzt auf Null),

    • setzt den HoldTimer auf Null zurück, und

  • ändert seinen Zustand zu OpenConfirm.

Wenn der Wert des Autonomous-System-Feldes mit der lokalen Autonomous-System-Nummer übereinstimmt, setzen Sie den Verbindungsstatus auf eine interne Verbindung; andernfalls wird es extern sein.

Wenn die BGP-Nachrichten-Header-Überprüfung (Ereignis 21) oder die OPEN-Nachrichten-Überprüfung einen Fehler erkennt (Ereignis 22) (siehe Abschnitt 6.2), führt das lokale System Folgendes aus:

  • (optional) sendet eine NOTIFICATION-Nachricht mit dem entsprechenden Fehlercode, wenn das SendNOTIFICATIONwithoutOPEN-Attribut auf TRUE gesetzt ist,

  • setzt den ConnectRetryTimer auf Null,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen,

  • erhöht den ConnectRetryCounter um 1,

  • (optional) führt Peer-Oszillationsdämpfung durch, wenn das DampPeerOscillations-Attribut auf TRUE gesetzt ist, und

  • ändert seinen Zustand zu Idle.

Wenn eine NOTIFICATION-Nachricht mit einem Versionsfehler empfangen wird (Ereignis 24), überprüft das lokale System den DelayOpenTimer. Wenn der DelayOpenTimer läuft, führt das lokale System Folgendes aus:

  • stoppt den ConnectRetryTimer (falls laufend) und setzt den ConnectRetryTimer auf Null,

  • stoppt und setzt den DelayOpenTimer zurück (setzt auf Null),

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen, und

  • ändert seinen Zustand zu Idle.

Wenn der DelayOpenTimer nicht läuft, führt das lokale System Folgendes aus:

  • setzt den ConnectRetryTimer auf Null,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen,

  • erhöht den ConnectRetryCounter um 1,

  • (optional) führt Peer-Oszillationsdämpfung durch, wenn das DampPeerOscillations-Attribut auf TRUE gesetzt ist, und

  • ändert seinen Zustand zu Idle.

Als Reaktion auf alle anderen Ereignisse (Ereignisse 8, 10-11, 13, 19, 23, 25-28) führt das lokale System Folgendes aus:

  • setzt den ConnectRetryTimer auf Null,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen,

  • erhöht den ConnectRetryCounter um eins,

  • (optional) führt Peer-Oszillationsdämpfung durch, wenn das DampPeerOscillations-Attribut auf TRUE gesetzt ist, und

  • ändert seinen Zustand zu Idle.

OpenSent:

In diesem Zustand wartet die BGP-FSM auf eine OPEN-Nachricht von ihrem Peer.

Die Start-Ereignisse (Ereignisse 1, 3-7) werden im OpenSent-Zustand ignoriert.

Wenn ein ManualStop-Ereignis (Ereignis 2) im OpenSent-Zustand ausgegeben wird, führt das lokale System Folgendes aus:

  • sendet die NOTIFICATION mit Cease,

  • setzt den ConnectRetryTimer auf Null,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen,

  • setzt den ConnectRetryCounter auf Null, und

  • ändert seinen Zustand zu Idle.

Wenn ein AutomaticStop-Ereignis (Ereignis 8) im OpenSent-Zustand ausgegeben wird, führt das lokale System Folgendes aus:

  • sendet die NOTIFICATION mit Cease,

  • setzt den ConnectRetryTimer auf Null,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen,

  • erhöht den ConnectRetryCounter um 1,

  • (optional) führt Peer-Oszillationsdämpfung durch, wenn das DampPeerOscillations-Attribut auf TRUE gesetzt ist, und

  • ändert seinen Zustand zu Idle.

Wenn der HoldTimer_Expires (Ereignis 10) auftritt, führt das lokale System Folgendes aus:

  • sendet eine NOTIFICATION-Nachricht mit dem Fehlercode Hold Timer Expired,

  • setzt den ConnectRetryTimer auf Null,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen,

  • erhöht den ConnectRetryCounter,

  • (optional) führt Peer-Oszillationsdämpfung durch, wenn das DampPeerOscillations-Attribut auf TRUE gesetzt ist, und

  • ändert seinen Zustand zu Idle.

Wenn ein TcpConnection_Valid- (Ereignis 14), Tcp_CR_Acked- (Ereignis 16) oder TcpConnectionConfirmed-Ereignis (Ereignis 17) empfangen wird, kann eine zweite TCP-Verbindung im Gange sein. Diese zweite TCP-Verbindung wird gemäß der Verbindungskollisionsverarbeitung (Abschnitt 6.8) verfolgt, bis eine OPEN-Nachricht empfangen wird.

Eine TCP-Verbindungsanfrage für einen ungültigen Port (Tcp_CR_Invalid (Ereignis 15)) wird ignoriert.

Wenn ein TcpConnectionFails-Ereignis (Ereignis 18) empfangen wird, führt das lokale System Folgendes aus:

  • schließt die BGP-Verbindung,

  • startet den ConnectRetryTimer neu,

  • lauscht weiter auf eine Verbindung, die vom entfernten BGP-Peer initiiert werden kann, und

  • ändert seinen Zustand zu Active.

Wenn eine OPEN-Nachricht empfangen wird, werden alle Felder auf Korrektheit überprüft. Wenn es keine Fehler in der OPEN-Nachricht gibt (Ereignis 19), führt das lokale System Folgendes aus:

  • setzt den DelayOpenTimer auf Null zurück,

  • setzt den BGP-ConnectRetryTimer auf Null,

  • sendet eine KEEPALIVE-Nachricht, und

  • setzt einen KeepaliveTimer (über den untenstehenden Text)

  • setzt den HoldTimer gemäß dem ausgehandelten Wert (siehe Abschnitt 4.2),

  • ändert seinen Zustand zu OpenConfirm.

Wenn der ausgehandelte Hold-Time-Wert null ist, werden der HoldTimer und der KeepaliveTimer nicht gestartet. Wenn der Wert des Autonomous-System-Feldes mit der lokalen Autonomous-System-Nummer übereinstimmt, ist die Verbindung eine "interne" Verbindung; andernfalls ist es eine "externe" Verbindung. (Dies wird sich auf die UPDATE-Verarbeitung auswirken, wie unten beschrieben.)

Wenn die BGP-Nachrichten-Header-Überprüfung (Ereignis 21) oder die OPEN-Nachrichten-Überprüfung einen Fehler erkennt (Ereignis 22) (siehe Abschnitt 6.2), führt das lokale System Folgendes aus:

  • sendet eine NOTIFICATION-Nachricht mit dem entsprechenden Fehlercode,

  • setzt den ConnectRetryTimer auf Null,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen,

  • erhöht den ConnectRetryCounter um 1,

  • (optional) führt Peer-Oszillationsdämpfung durch, wenn das DampPeerOscillations-Attribut TRUE ist, und

  • ändert seinen Zustand zu Idle.

Kollisionserkennungsmechanismen (Abschnitt 6.8) müssen angewendet werden, wenn eine gültige BGP-OPEN-Nachricht empfangen wird (Ereignis 19 oder Ereignis 20). Bitte beziehen Sie sich auf Abschnitt 6.8 für die Details des Vergleichs.

Ein CollisionDetectDump-Ereignis tritt auf, wenn die BGP-Implementierung durch Mittel außerhalb des Geltungsbereichs dieses Dokuments bestimmt, dass eine Verbindungskollision aufgetreten ist.

Wenn eine Verbindung im OpenSent-Zustand als die Verbindung bestimmt wird, die geschlossen werden muss, wird ein OpenCollisionDump (Ereignis 23) an die Zustandsmaschine signalisiert. Wenn ein solches Ereignis im OpenSent-Zustand empfangen wird, führt das lokale System Folgendes aus:

  • sendet eine NOTIFICATION mit Cease,

  • setzt den ConnectRetryTimer auf Null,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen,

  • erhöht den ConnectRetryCounter um 1,

  • (optional) führt Peer-Oszillationsdämpfung durch, wenn das DampPeerOscillations-Attribut auf TRUE gesetzt ist, und

  • ändert seinen Zustand zu Idle.

Wenn eine NOTIFICATION-Nachricht mit einem Versionsfehler empfangen wird (Ereignis 24), führt das lokale System Folgendes aus:

  • setzt den ConnectRetryTimer auf Null,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen, und

  • ändert seinen Zustand zu Idle.

Als Reaktion auf alle anderen Ereignisse (Ereignisse 9, 11-13, 20, 25-28) führt das lokale System Folgendes aus:

  • sendet die NOTIFICATION mit dem Fehlercode Finite State Machine Error,

  • setzt den ConnectRetryTimer auf Null,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen,

  • erhöht den ConnectRetryCounter um 1,

  • (optional) führt Peer-Oszillationsdämpfung durch, wenn das DampPeerOscillations-Attribut auf TRUE gesetzt ist, und

  • ändert seinen Zustand zu Idle.

OpenConfirm-Zustand:

In diesem Zustand wartet BGP auf eine KEEPALIVE- oder NOTIFICATION-Nachricht.

Jedes Start-Ereignis (Ereignisse 1, 3-7) wird im OpenConfirm-Zustand ignoriert.

Als Reaktion auf ein vom Operator initiiertes ManualStop-Ereignis (Ereignis 2) führt das lokale System Folgendes aus:

  • sendet die NOTIFICATION-Nachricht mit Cease,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen,

  • setzt den ConnectRetryCounter auf Null,

  • setzt den ConnectRetryTimer auf Null, und

  • ändert seinen Zustand zu Idle.

Als Reaktion auf das vom System initiierte AutomaticStop-Ereignis (Ereignis 8) führt das lokale System Folgendes aus:

  • sendet die NOTIFICATION-Nachricht mit Cease,

  • setzt den ConnectRetryTimer auf Null,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen,

  • erhöht den ConnectRetryCounter um 1,

  • (optional) führt Peer-Oszillationsdämpfung durch, wenn das DampPeerOscillations-Attribut auf TRUE gesetzt ist, und

  • ändert seinen Zustand zu Idle.

Wenn das HoldTimer_Expires-Ereignis (Ereignis 10) eintritt, bevor eine KEEPALIVE-Nachricht empfangen wird, führt das lokale System Folgendes aus:

  • sendet die NOTIFICATION-Nachricht mit dem Fehlercode Hold Timer Expired,

  • setzt den ConnectRetryTimer auf Null,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen,

  • erhöht den ConnectRetryCounter um 1,

  • (optional) führt Peer-Oszillationsdämpfung durch, wenn das DampPeerOscillations-Attribut auf TRUE gesetzt ist, und

  • ändert seinen Zustand zu Idle.

Wenn das lokale System ein KeepaliveTimer_Expires-Ereignis (Ereignis 11) empfängt, führt das lokale System Folgendes aus:

  • sendet eine KEEPALIVE-Nachricht,

  • startet den KeepaliveTimer neu, und

  • bleibt im OpenConfirmed-Zustand.

Im Fall eines TcpConnection_Valid-Ereignisses (Ereignis 14) oder des Erfolgs einer TCP-Verbindung (Ereignis 16 oder Ereignis 17) während OpenConfirm muss das lokale System die zweite Verbindung verfolgen.

Wenn eine TCP-Verbindung mit einem ungültigen Port versucht wird (Ereignis 15), ignoriert das lokale System den zweiten Verbindungsversuch.

Wenn das lokale System ein TcpConnectionFails-Ereignis (Ereignis 18) vom zugrunde liegenden TCP oder eine NOTIFICATION-Nachricht (Ereignis 25) empfängt, führt das lokale System Folgendes aus:

  • setzt den ConnectRetryTimer auf Null,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen,

  • erhöht den ConnectRetryCounter um 1,

  • (optional) führt Peer-Oszillationsdämpfung durch, wenn das DampPeerOscillations-Attribut auf TRUE gesetzt ist, und

  • ändert seinen Zustand zu Idle.

Wenn das lokale System eine NOTIFICATION-Nachricht mit einem Versionsfehler empfängt (NotifMsgVerErr (Ereignis 24)), führt das lokale System Folgendes aus:

  • setzt den ConnectRetryTimer auf Null,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen, und

  • ändert seinen Zustand zu Idle.

Wenn das lokale System eine gültige OPEN-Nachricht empfängt (BGPOpen (Ereignis 19)), wird die Kollisionserkennungsfunktion gemäß Abschnitt 6.8 verarbeitet. Wenn diese Verbindung aufgrund einer Verbindungskollision fallen gelassen werden soll, führt das lokale System Folgendes aus:

  • sendet eine NOTIFICATION mit Cease,

  • setzt den ConnectRetryTimer auf Null,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen (sendet TCP FIN),

  • erhöht den ConnectRetryCounter um 1,

  • (optional) führt Peer-Oszillationsdämpfung durch, wenn das DampPeerOscillations-Attribut auf TRUE gesetzt ist, und

  • ändert seinen Zustand zu Idle.

Wenn eine OPEN-Nachricht empfangen wird, werden alle Felder auf Korrektheit überprüft. Wenn die BGP-Nachrichten-Header-Überprüfung (BGPHeaderErr (Ereignis 21)) oder die OPEN-Nachrichten-Überprüfung einen Fehler erkennt (siehe Abschnitt 6.2) (BGPOpenMsgErr (Ereignis 22)), führt das lokale System Folgendes aus:

  • sendet eine NOTIFICATION-Nachricht mit dem entsprechenden Fehlercode,

  • setzt den ConnectRetryTimer auf Null,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen,

  • erhöht den ConnectRetryCounter um 1,

  • (optional) führt Peer-Oszillationsdämpfung durch, wenn das DampPeerOscillations-Attribut auf TRUE gesetzt ist, und

  • ändert seinen Zustand zu Idle.

Wenn während der Verarbeitung einer anderen OPEN-Nachricht die BGP-Implementierung durch Mittel außerhalb des Geltungsbereichs dieses Dokuments bestimmt, dass eine Verbindungskollision aufgetreten ist und diese Verbindung geschlossen werden soll, gibt das lokale System ein OpenCollisionDump-Ereignis (Ereignis 23) aus. Wenn das lokale System ein OpenCollisionDump-Ereignis (Ereignis 23) empfängt, führt das lokale System Folgendes aus:

  • sendet eine NOTIFICATION mit Cease,

  • setzt den ConnectRetryTimer auf Null,

  • gibt alle BGP-Ressourcen frei

  • lässt die TCP-Verbindung fallen,

  • erhöht den ConnectRetryCounter um 1,

  • (optional) führt Peer-Oszillationsdämpfung durch, wenn das DampPeerOscillations-Attribut auf TRUE gesetzt ist, und

  • ändert seinen Zustand zu Idle.

Wenn das lokale System eine KEEPALIVE-Nachricht empfängt (KeepAliveMsg (Ereignis 26)), führt das lokale System Folgendes aus:

  • startet den HoldTimer neu und

  • ändert seinen Zustand zu Established.

Als Reaktion auf alle anderen Ereignisse (Ereignisse 9, 12-13, 20, 27-28) führt das lokale System Folgendes aus:

  • sendet eine NOTIFICATION mit einem Code von Finite State Machine Error,

  • setzt den ConnectRetryTimer auf Null,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen,

  • erhöht den ConnectRetryCounter um 1,

  • (optional) führt Peer-Oszillationsdämpfung durch, wenn das DampPeerOscillations-Attribut auf TRUE gesetzt ist, und

  • ändert seinen Zustand zu Idle.

Established-Zustand:

Im Established-Zustand kann die BGP-FSM UPDATE-, NOTIFICATION- und KEEPALIVE-Nachrichten mit ihrem Peer austauschen.

Jedes Start-Ereignis (Ereignisse 1, 3-7) wird im Established-Zustand ignoriert.

Als Reaktion auf ein ManualStop-Ereignis (initiiert von einem Operator) (Ereignis 2) führt das lokale System Folgendes aus:

  • sendet die NOTIFICATION-Nachricht mit Cease,

  • setzt den ConnectRetryTimer auf Null,

  • löscht alle mit dieser Verbindung verbundenen Routen,

  • gibt BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen,

  • setzt den ConnectRetryCounter auf Null, und

  • ändert seinen Zustand zu Idle.

Als Reaktion auf ein AutomaticStop-Ereignis (Ereignis 8) führt das lokale System Folgendes aus:

  • sendet eine NOTIFICATION mit Cease,

  • setzt den ConnectRetryTimer auf Null

  • löscht alle mit dieser Verbindung verbundenen Routen,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen,

  • erhöht den ConnectRetryCounter um 1,

  • (optional) führt Peer-Oszillationsdämpfung durch, wenn das DampPeerOscillations-Attribut auf TRUE gesetzt ist, und

  • ändert seinen Zustand zu Idle.

Ein Grund für ein AutomaticStop-Ereignis ist: Ein BGP empfängt UPDATE-Nachrichten mit einer Anzahl von Präfixen für einen gegebenen Peer, so dass die insgesamt empfangenen Präfixe die maximal konfigurierte Anzahl von Präfixen überschreiten. Das lokale System trennt den Peer automatisch.

Wenn das HoldTimer_Expires-Ereignis eintritt (Ereignis 10), führt das lokale System Folgendes aus:

  • sendet eine NOTIFICATION-Nachricht mit dem Fehlercode Hold Timer Expired,

  • setzt den ConnectRetryTimer auf Null,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen,

  • erhöht den ConnectRetryCounter um 1,

  • (optional) führt Peer-Oszillationsdämpfung durch, wenn das DampPeerOscillations-Attribut auf TRUE gesetzt ist, und

  • ändert seinen Zustand zu Idle.

Wenn das KeepaliveTimer_Expires-Ereignis eintritt (Ereignis 11), führt das lokale System Folgendes aus:

  • sendet eine KEEPALIVE-Nachricht, und

  • startet seinen KeepaliveTimer neu, es sei denn, der ausgehandelte HoldTime-Wert ist null.

Jedes Mal, wenn das lokale System eine KEEPALIVE- oder UPDATE-Nachricht sendet, startet es seinen KeepaliveTimer neu, es sei denn, der ausgehandelte HoldTime-Wert ist null.

Ein TcpConnection_Valid (Ereignis 14), empfangen für einen gültigen Port, wird die zweite Verbindung verfolgen lassen.

Eine ungültige TCP-Verbindung (Tcp_CR_Invalid-Ereignis (Ereignis 15)) wird ignoriert.

Als Reaktion auf eine Anzeige, dass die TCP-Verbindung erfolgreich eingerichtet wurde (Ereignis 16 oder Ereignis 17), MUSS (SHALL) die zweite Verbindung verfolgt werden, bis sie eine OPEN-Nachricht sendet.

Wenn eine gültige OPEN-Nachricht (BGPOpen (Ereignis 19)) empfangen wird und wenn das optionale Attribut CollisionDetectEstablishedState TRUE ist, wird die OPEN-Nachricht überprüft, um zu sehen, ob sie mit einer anderen Verbindung kollidiert (Abschnitt 6.8). Wenn die BGP-Implementierung bestimmt, dass diese Verbindung beendet werden muss, verarbeitet sie ein OpenCollisionDump-Ereignis (Ereignis 23). Wenn diese Verbindung beendet werden muss, führt das lokale System Folgendes aus:

  • sendet eine NOTIFICATION mit Cease,

  • setzt den ConnectRetryTimer auf Null,

  • löscht alle mit dieser Verbindung verbundenen Routen,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen,

  • erhöht den ConnectRetryCounter um 1,

  • (optional) führt Peer-Oszillationsdämpfung durch, wenn das DampPeerOscillations auf TRUE gesetzt ist, und

  • ändert seinen Zustand zu Idle.

Wenn das lokale System eine NOTIFICATION-Nachricht (Ereignis 24 oder Ereignis 25) oder ein TcpConnectionFails (Ereignis 18) vom zugrunde liegenden TCP empfängt, führt das lokale System Folgendes aus:

  • setzt den ConnectRetryTimer auf Null,

  • löscht alle mit dieser Verbindung verbundenen Routen,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen,

  • erhöht den ConnectRetryCounter um 1,

  • ändert seinen Zustand zu Idle.

Wenn das lokale System eine KEEPALIVE-Nachricht empfängt (Ereignis 26), führt das lokale System Folgendes aus:

  • startet seinen HoldTimer neu, wenn der ausgehandelte HoldTime-Wert nicht null ist, und

  • bleibt im Established-Zustand.

Wenn das lokale System eine UPDATE-Nachricht empfängt (Ereignis 27), führt das lokale System Folgendes aus:

  • verarbeitet die Nachricht,

  • startet seinen HoldTimer neu, wenn der ausgehandelte HoldTime-Wert nicht null ist, und

  • bleibt im Established-Zustand.

Wenn das lokale System eine UPDATE-Nachricht empfängt und die UPDATE-Nachrichten-Fehlerbehandlungsprozedur (siehe Abschnitt 6.3) einen Fehler erkennt (Ereignis 28), führt das lokale System Folgendes aus:

  • sendet eine NOTIFICATION-Nachricht mit einem Update-Fehler,

  • setzt den ConnectRetryTimer auf Null,

  • löscht alle mit dieser Verbindung verbundenen Routen,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen,

  • erhöht den ConnectRetryCounter um 1,

  • (optional) führt Peer-Oszillationsdämpfung durch, wenn das DampPeerOscillations-Attribut auf TRUE gesetzt ist, und

  • ändert seinen Zustand zu Idle.

Als Reaktion auf alle anderen Ereignisse (Ereignisse 9, 12-13, 20-22) führt das lokale System Folgendes aus:

  • sendet eine NOTIFICATION-Nachricht mit dem Fehlercode Finite State Machine Error,

  • löscht alle mit dieser Verbindung verbundenen Routen,

  • setzt den ConnectRetryTimer auf Null,

  • gibt alle BGP-Ressourcen frei,

  • lässt die TCP-Verbindung fallen,

  • erhöht den ConnectRetryCounter um 1,

  • (optional) führt Peer-Oszillationsdämpfung durch, wenn das DampPeerOscillations-Attribut auf TRUE gesetzt ist, und

  • ändert seinen Zustand zu Idle.