Gibt es Gründe, BFD nicht zu verwenden?

Bei der Implementierung der bidirektionalen Weiterleitungserkennung (BFD) scheint es sehr flexibel in Bezug auf die Timer-Abstimmung zu sein, geringes Gewicht hinsichtlich des Overheads und Flexibilität in Bezug auf die Gesamtanwendung scheint sehr beeindruckend zu sein.

Wenn es beispielsweise zum Erkennen von Verbindungsfehlern über Ethernet, MPLS über mehrere Hops, am Netzwerkrand, zur IGP-Konvergenz, für Tunnel usw. usw. verwendet werden kann - warum sollte es in bestimmten Szenarien möglicherweise nicht verwendet werden und gibt es andere aufkommende Alternativen? sich bewusst sein über?

Mir ist nur ein Problem mit BFD direkt bekannt, nämlich die CPU-Nachfrage. Ich untersuche derzeit ein Problem mit einem Cisco 7301. Wenn zu unseren Stoßzeiten im Vergleich zum Rest des Tages mehr Datenverkehr übertragen wird, tritt bei BFD manchmal eine Zeitüberschreitung auf und es werden Fahrten zum nächsten Link weitergeleitet.

Es scheint, dass die CPU-Auslastung des Routers bei hohem Verkehrsaufkommen zunimmt (was nicht ungewöhnlich ist), aber bei etwa 40-50% der CPU-BFD-Pakete nicht genügend Ressourcen erhalten.

Ich habe jedoch die folgenden Informationen gefunden, die auf zusätzliche Probleme mit BFD hinweisen (Aus dieser NANOG-Präsentation geht mehr hervor, es ist eine gute, lesen Sie sie durch!)

Was sind die Vorbehalte?

• Zwei Hauptpunkte:
  1. BFD kann abhängig von Ihrer Größe einen hohen Ressourcenbedarf haben.
  2. BFD ist für Layer 2-Bündelungsprotokolle nicht sichtbar. (Ethernet-LAGs oder POS-Bundles)

BFD-Ressourcenanforderungen

• Die Anzahl der BFD-Sitzungen auf jeder Linecard oder jedem Router kann sich darauf auswirken, wie gut BFD für Sie skaliert. -Jede einzigartige Plattform hat ihre eigenen Grenzen.
• Es wurden gebündelte Schnittstellen gefunden, die eine Empfangszeit von mindestens 250 ms oder 2 Sekunden unterstützen.
• In einigen Fällen müssen BFD-Instanzen auf einem Router abhängig von der Implementierung möglicherweise auf dem Routenprozessor ausgeführt werden (nicht auf Nachbarschaft basierende BFD-Sitzungen).
• Testen Sie zuerst Ihre Plattform, bevor Sie BFD bereitstellen. Versuchen Sie, die RP- oder LC-CPU mit Ihren konfigurierten Einstellungen zu belasten. Dies kann erfolgen durch:
• CPU-lastige Befehle ausführen
• Flooding-Pakete zu TTL laufen am Ziel ab

BFD-Ressourcenanforderungen (Fortsetzung)

• Welche Werte können sicher ausprobiert werden?
• 300 ms mit einem Multiplikator von 3 (900 ms Erkennung) scheinen ein sicherer Wert zu sein, der auf den meisten Geräten recht gut funktioniert.
• Dies ist eine signifikante Verbesserung gegenüber einigen Alternativen.

BFD- und L2-Linkbündelung

• Der BFD sind die zugrunde liegenden Mitglieder des L2-Verbindungsbündels nicht bekannt.
• Ein 4x10GigE L2-Bundle (802.3ad) würde als einzelne L3-Nachbarschaft erscheinen. BFD-Pakete würden auf einer einzelnen Mitgliedsverbindung übertragen, anstatt auf allen vier Verbindungen.
• Ein Ausfall der Verbindung mit BFD würde dazu führen, dass die gesamte L3-Nachbarschaft ausfällt.
• In einigen Szenarien kann die fehlerhafte Mitgliederverbindung jedoch dazu führen, dass nur ein einzelnes BFD-Paket verworfen wird. Nachfolgende Pakete können über Arbeitsmitgliedsverbindungen weitergeleitet werden.

Ich habe zwei Gründe gesehen, warum BFD nicht implementiert wurde:

1. Unwissenheit darüber (ich war einige Zeit schuldig).

2. Kosten, wenn Sie ein Cisco-Shop sind. Abhängig von der Größe Ihrer Organisation ist dies möglicherweise vernachlässigbar, aber mit der Implementierung von BFD sind jetzt Lizenzkosten verbunden.

Ab dem ISR G2 / ASR-Zeitraum ist BFD nicht mehr im Lizenzpaket "IP Base" enthalten. Sie müssen mindestens auf die Lizenzstufe "Daten" aktualisieren, um BFD freizuschalten. Lesen Sie dieses Whitepaper von Cisco.

Diese Lizenzierungsanforderung ist möglicherweise kein Problem, da Sie möglicherweise bereits eine höhere Lizenzierungsstufe für andere Funktionen erwerben, dies ist jedoch zu beachten.

Ein paar Dinge, um Javanos Antwort abzurunden:

• Denken Sie daran, dass 40 g und 100 g Ethernet als Bündel betrachtet werden können, wenn auch nicht das gleiche wie LACP, sondern 4x10, 4x25 und 10x10
• Bei einigen Hardwarekomponenten (z. B. bei einigen High-End-Junipern) wird BFD auf der Leitungskarte verarbeitet. Dies kann ein Vorteil (kein Verlust bei hoher RE-Last) oder ein Defizit (kein sofortiger Verlust, wenn die RE ausfällt) sein.
• Das Ausführen von BFD über eine Verbindung / einen Pfad, die / der bereits ein SPOF (z. B. ein einzelnes Faserbündel) ist, kann schlimmer sein, als nur die Verzögerung des Trägers zu erhöhen

BFD ist eine Funktion, die erfunden wurde, um L2-Konnektivitätsprobleme zu erkennen, wenn sich zwischen zwei Peers ein zwischengeschaltetes Gerät befindet. BFD ist also eine Fehlererkennungsfunktion.

Normalerweise benötigen wir BFD, wenn 2 Router über L2-Switch 9 oder eine andere L2-Cloud miteinander verbunden sind. In diesem Fall wird der Verbindungsstatus bei Ausfall eines einzelnen Routers nicht auf einen anderen Router übertragen, da der Switch die Verbindung aufrecht erhalten würde. Wenn es sich nur um eine P2P-Verbindung (einzelnes Kabel) zwischen den Routern handelte, fiel die Schnittstelle bei einem Ausfall des Peers sofort aus, und das IGP wurde in Intervallen von weniger als einer Sekunde wiederhergestellt.

Die Gründe, BFDs nicht zu verwenden, sind: - BFD wird auf der Box [es] nicht unterstützt; - BFD wird nicht benötigt, da Sie kein Zwischengerät haben (verwenden Sie stattdessen udld und carrier-delay).