verstehen, wie BFD Netzwerkfehler erkennt

Das BFD-Protokoll (Bidirectional Forwarding Detection) ist ein einfacher Hallo-Mechanismus, der Fehler in einem Netzwerk erkennt. Ein Paar von Routing-Geräten tauscht BFD-Pakete aus. Die Geräte senden hello-Pakete in einem festgelegten, regelmäßigen Intervall. Das Gerät erkennt einen Nachbarfehler, wenn das Routinggerät nach einem bestimmten Intervall keine Antwort mehr empfängt.

Verwenden Sie Funktionen entdecken, um die Plattform- und Releaseunterstützung für bestimmte Funktionen zu bestätigen.

Lesen Sie den Abschnitt Plattformspezifisches BFD-Verhalten , um Hinweise zu Ihrer Plattform zu erhalten.

• Nützt
• Arten von BFD-Sitzungen
• Single-Hop- und Multihop-BFD

Ab Junos OS Version 24.3R1 haben wir auf vSRX 3.0 den verteilten Modus für die BFD-Fehlererkennung (Bidirectional Forwarding Detection) eingeführt. Mit dieser Unterstützung haben wir auch die dedizierte Funktion zum Auslagern von CPUs auf vSRX 3.0 hinzugefügt. Die dedizierte Offload-CPU-Funktion plant einen Datenflussthread neu und verwendet die DPDK-Datenflussfilter auf der Netzwerkkarte, um Pakete mit hoher Priorität (BGP, RIPv2, OSPF, PIM, Multicast, IGMP, Single-Hop-BFD und Multihop-BFD) auf den dedizierten Datenfluss-Thread zu verschieben. Dadurch werden Funktionspakete von einem eigenen dedizierten Datenfluss-Thread oder einer eigenen Warteschlange verarbeitet, selbst in Fällen, in denen die Weiterleitungsebene überbelegt ist und Pakete verworfen werden.

Da ein ganzer Datenfluss-Thread aus dem Weiterleitungsdatenverkehr entfernt wird, kann eine Verringerung des Paketdurchsatzes beobachtet werden, und diese Auswirkungen auf die Leistung sind in kleineren vSRX 3.0-Bereitstellungen ausgeprägter.

Führen Sie den set security forwarding-options dedicated-offload-cpu folgenden Befehl aus, um die Funktion "Dedizierte CPU-Entlastung" auf vSRX 3.0 zu aktivieren.

Wenn Sie diese Funktion konfigurieren, wird die folgende Warnmeldung in der Syslog-Ausgabe angezeigt: Warnung, Sie haben dedicated-offload-cpu aktiviert, dies wirkt sich auf die Leistung aus.

Ohne eine dedizierte Offload-CPU können im Falle einer Überbelegung, bei denen entweder Speicher- oder CPU-Schwellenwerte auf der Packet Forwarding Engine erreicht werden und Pakete verworfen werden, auch die Fast-BFD-Pakete verworfen werden, was zu BFD-Flapping führt.

Verwenden Sie den folgenden show security forward-options dedicated-offload-cpu Befehl, um den aktuellen CPU-Status der dedizierten Offload-Engine der Packet Forwarding Engine anzuzeigen. Mit diesem Befehl wird angezeigt, ob die Funktion "Dedizierte Offload-CPU" für die Packet Forwarding Engine aktiviert oder deaktiviert ist.

• Nützt
• Einschränkungen bei dedizierter Offload-CPU für vSRX 3.0
• Verteilte Konfiguration und Support

Wir unterstützen zwei Arten von Inline-BFD: Inline-BFD und hardwaregestütztes Inline-BFD. Inline-BFD-Sitzungen werden auf der FPC-Software ausgeführt. Hardwaregestützte Inline-BFD-Sitzungen werden auf der ASIC-Firmware ausgeführt. Der Support hängt von Ihrem Gerät und Ihrer Softwareversion ab.

• Nützt
• Inline-BFD
• Hardware-gestützter Inline-BFD
• Konfiguration

Mit der BFD-Sitzungsdämpfung können Sie übermäßige BFD-Klappenbenachrichtigungen verhindern, indem Sie Änderungen des BFD-Sitzungszustands für einen konfigurierten Zeitraum dämpfen, wenn definierte Schwellenwerte überschritten werden.

• Nützt
• Überblick
• Konfiguration

Das BFD-Protokoll (Bidirectional Forwarding Detection) ist ein einfacher Hallo-Mechanismus, der Fehler in einem Netzwerk erkennt. BFD arbeitet mit einer Vielzahl von Netzwerkumgebungen und -topologien. Ein Paar von Routing-Geräten tauscht BFD-Pakete aus. Hello-Pakete werden in einem festgelegten, regelmäßigen Intervall gesendet. Ein Nachbarfehler wird erkannt, wenn das Routinggerät nach einem bestimmten Intervall keine Antwort mehr empfängt. Die Timer für die BFD-Fehlererkennung haben kürzere Zeitlimits als die statischen Mechanismen zur Erkennung von Routenfehlern, sodass sie eine schnellere Erkennung ermöglichen.

Die Timer für die BFD-Fehlererkennung können so eingestellt werden, dass sie schneller oder langsamer sind. Je niedriger der Timerwert für die BFD-Fehlererkennung, desto schneller erfolgt die Fehlererkennung und umgekehrt. Beispielsweise können die Timer an einen höheren Wert angepasst werden, wenn die Nachbarschaft fehlschlägt (d. h., der Timer erkennt Fehler langsamer). Oder ein Nachbar kann einen höheren Wert für einen Timer aushandeln als den konfigurierten Wert. Die Timer passen sich an einen höheren Wert an, wenn eine BFD-Sitzungsklappe mehr als dreimal in einer Zeitspanne von 15 Sekunden auftritt. Ein Back-Off-Algorithmus erhöht das Empfangsintervall (Rx) um zwei, wenn die lokale BFD-Instanz der Grund für die Sitzungsstörung ist. Das Übertragungsintervall (Tx) wird um zwei erhöht, wenn die entfernte BFD-Instanz der Grund für die Sitzungsstörung ist. Mit dem Befehl können Sie BFD-Intervall-Timer clear bfd adaptation auf ihre konfigurierten Werte zurücksetzen. Der clear bfd adaptation Befehl ist hitless, was bedeutet, dass sich der Befehl nicht auf den Datenverkehrsfluss auf dem Routing-Gerät auswirkt.

Standardmäßig wird BFD auf statischen Single-Hop-Routen unterstützt.

Um die Fehlererkennung zu aktivieren, schließen Sie die bfd-liveness-detection Anweisung in die Konfiguration der statischen Route ein.

In Junos OS Version 9.1 und höher wird das BFD-Protokoll für statische IPv6-Routen unterstützt. Globale Unicast- und link-lokale IPv6-Adressen werden für statische Routen unterstützt. Das BFD-Protokoll wird für Multicast- oder Anycast-IPv6-Adressen nicht unterstützt. Für IPv6 unterstützt das BFD-Protokoll nur statische Routen und nur in Junos OS Version 9.3 und höher. IPv6 für BFD wird auch für das eBGP-Protokoll unterstützt.

Um das BFD-Protokoll für statische IPv6-Routen zu konfigurieren, schließen Sie die bfd-liveness-detection Anweisung auf der [edit routing-options rib inet6.0 static route destination-prefix] Hierarchieebene ein.

In Junos OS Version 8.5 und höher können Sie ein Halteintervall konfigurieren, um anzugeben, wie lange die BFD-Sitzung aktiv bleiben muss, bevor eine Benachrichtigung über eine Zustandsänderung gesendet wird.

Um das Hold-Down-Intervall festzulegen, fügen Sie die holddown-interval Anweisung in die BFD-Konfiguration ein. Sie können eine Zahl im Bereich von 0 bis 255.000 Millisekunden konfigurieren. Der Standardwert ist 0. Wenn die BFD-Sitzung ausfällt und dann während des Halteintervalls wieder hochgefahren wird, wird der Timer neu gestartet.

Um die minimalen Sende- und Empfangsintervalle für die Fehlererkennung anzugeben, fügen Sie die minimum-interval Anweisung in die BFD-Konfiguration ein.

Dieser Wert stellt sowohl das minimale Intervall dar, nach dem das lokale Routing-Gerät Hello-Pakete überträgt, als auch das minimale Intervall, nach dem das Routing-Gerät eine Antwort von dem Nachbarn erwartet, mit dem es eine BFD-Sitzung eingerichtet hat. Sie können eine Zahl im Bereich von 1 bis 255.000 Millisekunden konfigurieren. Anstatt diese Anweisung zu verwenden, können Sie optional die minimalen Sende- und Empfangsintervalle separat konfigurieren, indem Sie die Anweisungen transmit-interval minimum-interval und minimum-receive-interval verwenden.

Um das minimale Empfangsintervall für die Fehlererkennung anzugeben, fügen Sie die minimum-receive-interval Anweisung in die BFD-Konfiguration ein. Dieser Wert stellt das minimale Intervall dar, nach dem das Routing-Gerät eine Antwort von einem Nachbarn erwartet, mit dem es eine BFD-Sitzung aufgebaut hat. Sie können eine Zahl im Bereich von 1 bis 255.000 Millisekunden konfigurieren. Anstatt diese Anweisung zu verwenden, können Sie optional das minimale Empfangsintervall mithilfe der minimum-interval Anweisung auf Hierarchieebene [edit routing-options static route destination-prefix bfd-liveness-detection] konfigurieren.

Um die Anzahl der hello-Pakete anzugeben, die nicht vom Nachbarn empfangen wurden, was dazu führt, dass die ursprüngliche Schnittstelle als inaktiv deklariert wird, fügen Sie die multiplier Anweisung in die BFD-Konfiguration ein. Der Standardwert ist 3. Sie können eine Zahl im Bereich von 1 bis 255 konfigurieren.

Um einen Schwellenwert für die Erkennung der Anpassung der Erkennungszeit anzugeben, fügen Sie die threshold Anweisung in die BFD-Konfiguration ein.

Wenn sich die Erkennungszeit der BFD-Sitzung an einen Wert anpasst, der gleich oder höher als der Schwellenwert ist, werden ein einzelner Trap und eine Systemprotokollmeldung gesendet. Die Erkennungszeit basiert auf dem Multiplikator des Minimum-Intervalls bzw. des Minimum-Empfangsintervall-Wertes . Der Schwellenwert muss ein höherer Wert als der Multiplikator für einen dieser konfigurierten Werte sein. Wenn das minimale Empfangsintervall beispielsweise 300 ms und der Multiplikator 3 beträgt, beträgt die Gesamterkennungszeit 900 ms. Daher muss der Schwellenwert für die Erkennungszeit einen Wert größer als 900 haben.

Um das minimale Sendeintervall für die Fehlererkennung anzugeben, fügen Sie die transmit-interval minimum-interval Anweisung in die BFD-Konfiguration ein.

Dieser Wert stellt das minimale Intervall dar, nach dem das lokale Routing-Gerät Hello-Pakete an den Nachbarn überträgt, mit dem es eine BFD-Sitzung aufgebaut hat. Sie können einen Wert im Bereich von 1 bis 255.000 Millisekunden konfigurieren. Anstatt diese Anweisung zu verwenden, können Sie optional das minimale Übertragungsintervall mit der minimum-interval Anweisung auf Hierarchieebene [edit routing-options static route destination-prefix bfd-liveness-detection] konfigurieren.

Um den Schwellwert für die Anpassung des Sendeintervalls festzulegen, nehmen Sie die transmit-interval threshold Anweisung in die BFD-Konfiguration auf.

Der Schwellwert muss größer als das Sendeintervall sein. Wenn sich die Übertragungszeit der BFD-Sitzung an einen Wert anpasst, der größer als der Schwellenwert ist, werden ein einzelner Trap und eine Systemprotokollmeldung gesendet. Die Erkennungszeit basiert auf dem Multiplikator des Wertes für das Minimum-Intervall bzw. der minimum-receive-interval Anweisung auf Hierarchieebene [edit routing-options static route destination-prefix bfd-liveness-detection] . Der Schwellenwert muss ein höherer Wert als der Multiplikator für einen dieser konfigurierten Werte sein.

Um die BFD-Version anzugeben, fügen Sie die version Anweisung in die BFD-Konfiguration ein. Standardmäßig wird die Version automatisch erkannt.

Um eine IP-Adresse für den nächsten Hop der BFD-Sitzung einzuschließen, fügen Sie die neighbor Anweisung in die BFD-Konfiguration ein.

In Junos OS Version 9.0 und höher können Sie BFD-Sitzungen so konfigurieren, dass sie nicht an sich ändernde Netzwerkbedingungen angepasst werden. Um die BFD-Anpassung zu deaktivieren, fügen Sie die no-adaptation Anweisung in die BFD-Konfiguration ein.

Das BFD-Protokoll (Bidirectional Forwarding Detection) ist ein einfacher Hallo-Mechanismus, der Fehler in einem Netzwerk erkennt. Hello-Pakete werden in einem festgelegten, regelmäßigen Intervall gesendet. Ein Nachbarfehler wird erkannt, wenn das Routinggerät nach einem bestimmten Intervall keine Antwort mehr empfängt. BFD arbeitet mit einer Vielzahl von Netzwerkumgebungen und -topologien. Die Zeitgeber für die Fehlererkennung für BFD haben kürzere Zeitlimits als die standardmäßigen Fehlererkennungsmechanismen für BGP und bieten daher eine schnellere Erkennung.

Verwenden Sie Funktionen entdecken, um die Plattform- und Releaseunterstützung für bestimmte Funktionen zu bestätigen.

Im Abschnitt Plattformspezifische BFD für BGP-Verhalten finden Sie Hinweise zu Ihrer Plattform.

Die Timer für die BFD-Fehlererkennung können so eingestellt werden, dass sie schneller oder langsamer sind. Je niedriger der Timerwert für die BFD-Fehlererkennung, desto schneller erfolgt die Fehlererkennung und umgekehrt. Beispielsweise können die Timer an einen höheren Wert angepasst werden, wenn die Nachbarschaft fehlschlägt (d. h., der Timer erkennt Fehler langsamer). Oder ein Nachbar kann einen höheren Wert für einen Timer aushandeln als den konfigurierten Wert. Die Timer passen sich an einen höheren Wert an, wenn ein BFD-Sitzungs-Flap mehr als dreimal in einem Zeitraum von 15 Sekunden (15000 Millisekunden) auftritt. Ein Back-Off-Algorithmus erhöht das Empfangsintervall (Rx) um zwei, wenn die lokale BFD-Instanz der Grund für die Sitzungsstörung ist. Das Übertragungsintervall (Tx) wird um zwei erhöht, wenn die entfernte BFD-Instanz der Grund für die Sitzungsstörung ist. Mit dem Befehl können Sie BFD-Intervall-Timer clear bfd adaptation auf ihre konfigurierten Werte zurücksetzen. Der clear bfd adaptation Befehl ist hitless, was bedeutet, dass sich der Befehl nicht auf den Datenverkehrsfluss auf dem Routing-Gerät auswirkt.

Das BFD-Protokoll (Bidirectional Forwarding Detection) ist ein einfacher Hallo-Mechanismus, der Fehler in einem Netzwerk erkennt. BFD arbeitet mit einer Vielzahl von Netzwerkumgebungen und -topologien. Ein Paar von Routing-Geräten tauscht BFD-Pakete aus. Hello-Pakete werden in einem festgelegten, regelmäßigen Intervall gesendet. Ein Nachbarfehler wird erkannt, wenn das Routinggerät nach einem bestimmten Intervall keine Antwort mehr empfängt. Die Timer für die BFD-Fehlererkennung haben kürzere Zeitlimits als die OSPF-Fehlererkennungsmechanismen, sodass sie eine schnellere Erkennung ermöglichen.

Die Timer für die BFD-Fehlererkennung sind adaptiv und können so eingestellt werden, dass sie schneller oder langsamer sind. Je niedriger der Timerwert für die BFD-Fehlererkennung, desto schneller erfolgt die Fehlererkennung und umgekehrt. Beispielsweise können die Timer an einen höheren Wert angepasst werden, wenn die Nachbarschaft fehlschlägt (d. h., der Timer erkennt Fehler langsamer). Oder ein Nachbar kann einen höheren Wert für einen Timer aushandeln als den konfigurierten Wert. Die Timer passen sich an einen höheren Wert an, wenn eine BFD-Sitzungsklappe mehr als dreimal in einer Zeitspanne von 15 Sekunden auftritt. Ein Back-Off-Algorithmus erhöht das Empfangsintervall (Rx) um zwei, wenn die lokale BFD-Instanz der Grund für die Sitzungsstörung ist. Das Übertragungsintervall (Tx) wird um zwei erhöht, wenn die entfernte BFD-Instanz der Grund für die Sitzungsstörung ist. Mit dem Befehl können Sie BFD-Intervall-Timer clear bfd adaptation auf ihre konfigurierten Werte zurücksetzen. Der clear bfd adaptation Befehl ist hitless, was bedeutet, dass sich der Befehl nicht auf den Datenverkehrsfluss auf dem Routing-Gerät auswirkt.

Sie können die folgenden BFD-Protokolleinstellungen konfigurieren:

• detection-time threshold—Schwellenwert für die Anpassung der Erkennungszeit. Wenn sich die Erkennungszeit der BFD-Sitzung an einen Wert anpasst, der gleich oder größer als der konfigurierte Schwellenwert ist, werden ein einzelner Trap und eine einzelne Systemprotokollnachricht gesendet.

• full-neighbors-only– Möglichkeit, BFD-Sitzungen nur für OSPF-Nachbarn einzurichten, die sich in direkter Nachbarschaft befinden. Das Standardverhalten besteht darin, BFD-Sitzungen für alle OSPF-Nachbarn einzurichten. Diese Einstellung ist in Junos OS Version 9.5 und höher verfügbar.

• minimum-intervalMinimales Sende- und Empfangsintervall für die Fehlererkennung. Diese Einstellung konfiguriert sowohl das minimale Intervall, nach dem das lokale Routing-Gerät Hello-Pakete überträgt, als auch das minimale Intervall, nach dem das Routing-Gerät eine Antwort von dem Nachbarn erwartet, mit dem es eine BFD-Sitzung eingerichtet hat. Beide Intervalle werden in Millisekunden angegeben. Sie können die minimalen Sende- und Empfangsintervalle auch separat mit den transmit-interval minimum-interval minimum-receive-interval Anweisungen und angeben.

  Anmerkung:

  BFD ist ein intensives Protokoll, das Systemressourcen verbraucht. Die Angabe eines Mindestintervalls für BFD von weniger als 100 ms für Routing-Engine-basierte Sitzungen und 10 ms für verteilte BFD-Sitzungen kann zu unerwünschtem BFD-Flapping führen.

  Abhängig von Ihrer Netzwerkumgebung kann Folgendes zutreffen:

  • Geben Sie für groß angelegte Netzwerkbereitstellungen mit einer großen Anzahl von BFD-Sitzungen ein Mindestintervall von mindestens 500 ms an. Ein Intervall von 1000 ms wird empfohlen, um Instabilitätsprobleme zu vermeiden.

  • Damit BFD-Sitzungen während eines Routing-Engine-Switchover-Ereignisses aktiv bleiben, wenn Nonstop Active Routing (NSR) konfiguriert ist, geben Sie ein Mindestintervall von 2500 ms für Routing-Engine-basierte Sitzungen an. Ohne NSR können Routing-Engine-basierte Sitzungen ein Mindestintervall von 100 ms haben.

  • Für verteilte BFD-Sitzungen mit konfiguriertem NSR bleiben die Empfehlungen für das Mindestintervall unverändert und hängen nur von Ihrer Netzwerkbereitstellung ab.

  • BFD wird nicht vor Junos 21.2 verteilt (da BFD für OSPFv3 in der Routing-Engine basiert).

• minimum-receive-interval– Minimales Empfangsintervall für die Fehlererkennung. Mit dieser Einstellung wird das minimale Empfangsintervall in Millisekunden konfiguriert, nach dem das Routinggerät ein Hello-Paket von einem Nachbarn erwartet, mit dem es eine BFD-Sitzung eingerichtet hat. Sie können auch das minimale Empfangsintervall mithilfe der minimum-interval Anweisung angeben.

• multiplier– Multiplikator für Hallo-Pakete. Mit dieser Einstellung wird die Anzahl der hello-Pakete konfiguriert, die nicht von einem Nachbarn empfangen werden, was dazu führt, dass die ursprüngliche Schnittstelle als inaktiv deklariert wird. Standardmäßig führen drei verpasste hello-Pakete dazu, dass die ursprüngliche Schnittstelle als inaktiv deklariert wird.

• no-adaptation—Deaktiviert die BFD-Anpassung. Diese Einstellung verhindert, dass sich BFD-Sitzungen an sich ändernde Netzwerkbedingungen anpassen. Diese Einstellung ist in Junos OS Version 9.0 und höher verfügbar.

  Anmerkung:

  Es wird empfohlen, die BFD-Anpassung nicht zu deaktivieren, es sei denn, es ist vorzuziehen, die BFD-Anpassung in Ihrem Netzwerk nicht zu verwenden.

• transmit-interval minimum-interval– Minimales Übertragungsintervall für die Fehlererkennung. Mit dieser Einstellung wird das minimale Übertragungsintervall in Millisekunden konfiguriert, in dem das lokale Routing-Gerät hello-Pakete an den Nachbarn sendet, mit dem es eine BFD-Sitzung eingerichtet hat. Mit der minimum-interval Anweisung können Sie auch das minimale Übertragungsintervall angeben.

• transmit-interval threshold—Schwellenwert für die Anpassung des Sendeintervalls der BFD-Sitzung. Wenn sich das Übertragungsintervall an einen Wert anpasst, der größer als der Schwellenwert ist, werden ein einzelner Trap und eine einzelne Systemprotokollmeldung gesendet. Der Schwellwert muss größer als das minimale Sendeintervall sein. Wenn Sie versuchen, eine Konfiguration mit einem Schwellenwert zu bestätigen, der kleiner als das minimale Übertragungsintervall ist, zeigt das Routing-Gerät einen Fehler an und akzeptiert die Konfiguration nicht.

• version—BFD-Version. Mit dieser Einstellung wird die BFD-Version konfiguriert, die für die Erkennung verwendet wird. Sie können die BFD-Version 1 explizit konfigurieren, oder das Routing-Gerät kann die BFD-Version automatisch erkennen. Standardmäßig erkennt das Routing-Gerät automatisch die BFD-Version, die entweder 0 oder 1 ist.

Sie können BFD-Vorgänge auch zu Zwecken der Fehlerbehebung verfolgen.

Die Timer für die BFD-Fehlererkennung sind adaptiv und können so eingestellt werden, dass sie schneller oder langsamer sind. Beispielsweise können sich die Timer an einen höheren Wert anpassen, wenn die Nachbarschaft fehlschlägt, oder ein Nachbar kann einen höheren Wert für einen Timer als den konfigurierten Wert aushandeln. Die Timer passen sich an einen höheren Wert an, wenn eine BFD-Sitzungsklappe mehr als dreimal in einer Zeitspanne von 15 Sekunden auftritt. Ein Back-Off-Algorithmus erhöht das Empfangsintervall (RX) um zwei, wenn die lokale BFD-Instanz der Grund für die Sitzungsstörung ist. Das Sendeintervall (TX) wird um zwei erhöht, wenn die entfernte BFD-Instanz der Grund für die Sitzungsstörung ist.

Mit dem Befehl können Sie BFD-Intervall-Timer clear bfd adaptation auf ihre konfigurierten Werte zurücksetzen. Der clear bfd adaptation Befehl ist hitless, was bedeutet, dass sich der Befehl nicht auf den Datenverkehrsfluss auf dem Routing-Gerät auswirkt.

Um Ausfälle im Netzwerk zu erkennen, werden die Anweisungen in Tabelle 2 in der Konfiguration verwendet.

Eine Liste der Hierarchieebenen, auf denen Sie diese Anweisungen einschließen können, finden Sie in den Abschnitten zur Anweisungszusammenfassung für diese Anweisungen.

BFD ermöglicht ein schnelles Failover zwischen einem primären und einem sekundären gerouteten Pfad. Das Protokoll testet den Betriebsstatus der Schnittstelle mehrmals pro Sekunde. BFD stellt Konfigurationstimer und Schwellenwerte für die Fehlererkennung bereit. Wenn z. B. das Mindestintervall auf 50 Millisekunden festgelegt ist und der Schwellenwert den Standardwert von drei verpassten Nachrichten verwendet, wird innerhalb von 200 Millisekunden nach dem Fehler ein Fehler auf einer Schnittstelle erkannt.

Zwischengeschaltete Geräte (z. B. ein Ethernet-LAN-Switch) verbergen Fehler der Verbindungsschicht vor Routing-Protokoll-Peers, z. B. wenn zwei Router über einen LAN-Switch verbunden sind, wobei der lokale Schnittstellenstatus auch dann bestehen bleibt, wenn ein physischer Fehler an der Remote-Verbindung auftritt. Die Erkennungszeiten für Link-Layer-Fehler variieren je nach physischem Medium und Layer-2-Verkapselung. BFD bietet schnelle Fehlererkennungszeiten für alle Medientypen, Kapselungen, Topologien und Routing-Protokolle.

Um BFD für RIP zu aktivieren, müssen beide Seiten der Verbindung eine Aktualisierungsnachricht vom Peer erhalten. Standardmäßig exportiert RIP keine Routen. Daher müssen Sie das Versenden von Aktualisierungsnachrichten aktivieren, indem Sie eine Exportrichtlinie für Routen konfigurieren, bevor eine BFD-Sitzung ausgelöst wird.

Wenn Sie Micro-BFD-Sitzungen für jeden Mitgliedslink in einem LAG-Bundle konfigurieren, bestimmt jede einzelne Sitzung die Layer-2- und Layer-3-Konnektivität jedes Mitgliedslinks in einer LAG.

Nachdem die einzelne Sitzung auf einer bestimmten Verbindung eingerichtet wurde, werden die Mitgliederlinks an die LAG angehängt und dann durch eine der folgenden Optionen ausgeglichen:

• Statische Konfiguration: Der Gerätesteuerungsprozess fungiert als Client für die Mikro-BFD-Sitzung.

• Link Aggregation Control Protocol (LACP): LACP fungiert als Client für die Mikro-BFD-Sitzung.

Wenn die Micro-BFD-Sitzung aktiv ist, wird eine LAG-Verbindung hergestellt, und die Daten werden über diese LAG-Verbindung übertragen. Wenn die Micro-BFD-Sitzung auf einem Mitgliedslink ausgefallen ist, wird dieser bestimmte Mitgliedslink aus dem Load Balancer entfernt, und die LAG-Manager leiten den Datenverkehr nicht mehr an diesen Link weiter. Diese Mikro-BFD-Sitzungen sind unabhängig voneinander, obwohl sie einen einzigen Client haben, der die LAG-Schnittstelle verwaltet.

Micro-BFD-Sitzungen werden in den folgenden Modi ausgeführt:

• Verteilungsmodus: In diesem Modus sendet und empfängt die Packet Forwarding Engine (PFE) die Pakete auf Layer 3. Standardmäßig werden Micro-BFD-Sitzungen auf Layer 3 verteilt.

• Nicht-Verteilungsmodus: In diesem Modus sendet und empfängt die Routing-Engine die Pakete auf Layer 2. Sie können die BFD-Sitzung so konfigurieren, dass sie in diesem Modus ausgeführt wird, indem Sie die no-delegate-processing Anweisung unter Periodic Packet Management (PPM) einfügen.

Ein Paar von Routing-Geräten in einer LAG tauscht BFD-Pakete in einem festgelegten, regelmäßigen Intervall aus. Das Routinggerät erkennt einen Nachbarfehler, wenn es nach einem bestimmten Intervall keine Antwort mehr erhält. Dies ermöglicht die schnelle Überprüfung der Member-Link-Konnektivität mit oder ohne LACP. Ein UDP-Port unterscheidet BFD über LAG-Pakete von BFD über Single-Hop-IP-Pakete. Die Internet Assigned Numbers Authority (IANA) hat 6784 als UDP-Zielport für Micro-BFD zugewiesen.

Ab Junos OS 16.1R1 können Sie den Status der statischen Route im Status "BFD Admin Down" festlegen, indem Sie einen der folgenden Befehle konfigurieren:

• set routing-options static static-route bfd-admin-down active– Der Status "BFD Admin Down" zieht die statische Route nach unten.

• set routing-options static static-route bfd-admin-down passive– Der Status "BFD Admin Down" zieht die statische Route nicht herunter.

Nahtlose BFD (S-BFD) reduziert die Zeit, die für die Erkennung und Reaktion auf Pfadfehler benötigt wird, indem die BFD-Initiierungszeit verkürzt wird. Jedem Knoten im Netzwerk wird ein eindeutiger S-BFD-Diskriminator zugewiesen. Knoten fungieren entweder als Initiatoren, die aktiv die Erreichbarkeit von Pfaden prüfen, oder als Responder, die auf Erreichbarkeitsanfragen hören und reagieren. Wenn ein S-BFD-Initiator ein Anforderungspaket sendet, antwortet der Responder, indem er die Diskriminatoren vertauscht und den Status sofort auf UPfestlegt. Dieser zustandslose Betrieb ermöglicht den schnellen Aufbau mehrerer Sitzungen und ist damit ideal für Umgebungen, die schnelle Konnektivitätsprüfungen erfordern.

Um sbfd zu aktivieren, konfigurieren Sie die bfd-liveness-detection sbfd remote-discriminator value Anweisung auf den Initator-Knoten und auf den bfd sbfd local-discriminator value On-Reponder-Knoten.

• Vorteile von S-BFD
• S-BFD getriggerte schnelle Umleitung

Ab Junos OS Version 22.4R1 können Sie BFD so konfigurieren, dass Echopakete von einem benachbarten Gerät hin und her gesendet werden, um sicherzustellen, dass ein Weiterleitungspfad verfügbar ist. Verwenden Sie die bfd-liveness-detection echo minimum-interval milliseconds Konfigurationsanweisung, um den BFD-Echomodus zu aktivieren und das Mindestintervall für Echopakete festzulegen. Der BFD-Echomodus funktioniert nur, wenn das benachbarte Gerät BFD unterstützt.

Wenn das benachbarte Gerät BFD nicht unterstützt, können Sie den BFD-Echo-Lite-Modus verwenden. Um den BFD-Echo-Lite-Modus zu aktivieren, verwenden Sie die bfd-liveness-detection echo-lite minimum-interval milliseconds Konfigurationsanweisung. Der BFD-Echo-Lite-Modus erfüllt die gleiche Funktion wie der BFD-Echomodus, ohne dass eine BFD-Konfiguration auf dem Nachbargerät erforderlich ist.

Standardmäßig unterstützen die Modi echo und echo-lite nur Single-Hop-Sitzungen im zentralisierten BFD-Modus. Ab Junos OS Version 24.2R1 unterstützen PRPD-BFD-APIs den Echo-Lite-Modus für Multihop-Sitzungen im verteilten und Inline-BFD-Modus. Weitere Informationen zu PRPD-APIs finden Sie unter Übersicht über JET-APIs.

Verwenden Sie Funktionen entdecken, um die Plattform- und Releaseunterstützung für bestimmte Funktionen zu bestätigen.

Verwenden Sie die folgenden Tabellen, um plattformspezifische Verhaltensweisen für Ihre Plattform zu überprüfen:

• Plattformspezifisches verteiltes BFD-Verhalten
• Plattformspezifisches Inline-BFD-Verhalten
• Plattformspezifischer BFD für statisches Routenverhalten
• Plattformspezifische BFD für BGP-Verhalten
• Plattformspezifische BFD für OSPF-Verhalten
• Plattformspezifische BFD für IS-IS-Verhalten
• Plattformspezifischer BFD für RIP-Verhalten
• Plattformspezifisches Micro-BFD-Verhalten