JNCIP-ENT: Next-Hop Probleme in der Praxis
28.06.2026 4 Min. Lesezeit
BGP operiert nicht isoliert, sondern ist in hohem Maße von den darunterliegenden Routingmechanismen abhängig. Besonders deutlich wird das beim Next-Hop-Attribut, das eine zentrale Rolle in der praktischen Weiterleitung spielt, aber häufig falsch interpretiert wird. Viele Probleme, bei denen BGP scheinbar korrekt funktioniert, lassen sich letztlich darauf zurückführen, dass der Next-Hop zwar logisch vorhanden, aber faktisch nicht nutzbar ist.
Das Next-Hop-Attribut beschreibt den nächsten Router auf dem Weg zum Zielpräfix. Es ist kein optionales Detail, sondern die eigentliche Grundlage der Forwarding-Entscheidung. Während BGP selbst nur entscheidet, welcher Pfad bevorzugt wird, verlässt es sich darauf, dass der Next-Hop über das zugrunde liegende Routing erreichbar ist. Diese Trennung führt dazu, dass eine Route innerhalb von BGP vollkommen valide erscheinen kann, aber dennoch nicht verwendet wird, weil die Erreichbarkeit des Next-Hops nicht gewährleistet ist.
Der entscheidende Punkt liegt darin, dass BGP keine eigene Topologie berechnet. Es übernimmt die Information aus anderen Protokollen, typischerweise einem IGP wie OSPF oder IS‑IS. Eine BGP-Route ist daher immer nur so gut wie die Fähigkeit des Routers, den angegebenen Next-Hop über diese Protokolle zu erreichen. Wenn diese Voraussetzung nicht erfüllt ist, bleibt die Route zwar in der Kontroll-Ebene sichtbar, aber sie scheitert in der praktischen Nutzung.
Besonders deutlich wird dieses Verhalten beim Übergang zwischen eBGP und iBGP. Wird eine Route über eBGP empfangen, setzt der Router standardmäßig sich selbst als Next-Hop. Damit ist sichergestellt, dass der empfangende Router einen direkt erreichbaren Einstiegspunkt hat. Sobald diese Route jedoch innerhalb des eigenen autonomen Systems weitergegeben wird, verändert sich das Verhalten. Im iBGP bleibt der Next-Hop unverändert. Der ursprüngliche Einstiegspunkt in das externe Netzwerk wird also beibehalten.
Dieses Verhalten ist logisch, da sich aus Sicht des Protokolls der Eintrittspunkt nicht geändert hat. Für nachgelagerte Router bedeutet es jedoch, dass sie einen Next-Hop verwenden sollen, zu dem sie möglicherweise gar keinen Pfad kennen. In kleinen oder vollständig vermaschten Netzwerken fällt dies oft nicht auf, da alle notwendigen Informationen vorhanden sind. In realistischen Umgebungen, in denen nicht jeder Router Kenntnis über alle externen Netze hat, führt dies jedoch zu Problemen.
Ein typisches Szenario entsteht, wenn ein Router eine externe Route empfängt und sie über mehrere iBGP-Stationen weitergegeben wird. Der ursprüngliche Next-Hop bleibt dabei erhalten, auch wenn er physikalisch nur am ersten Router erreichbar ist. Wenn das interne Routing keinen Weg zu diesem Next-Hop kennt, ist die Route für alle nachfolgenden Router nicht nutzbar. Sie existiert zwar weiterhin im BGP-Kontext, scheitert aber an der fehlenden Auflösung.
Die Auflösung selbst erfolgt rekursiv. Der Router prüft, ob er eine Route zum angegebenen Next-Hop besitzt, und verwendet diese Information, um die eigentliche Weiterleitung zu bestimmen. Dieser Prozess kann mehrere Ebenen umfassen, insbesondere wenn der Next-Hop nicht direkt erreichbar ist, sondern über weitere interne Pfade aufgelöst wird. Jede Stufe dieser Rekursion stellt eine potenzielle Fehlerquelle dar. Sobald eine dieser Abhängigkeiten nicht erfüllt ist, bricht die gesamte Auflösung zusammen.
Die Folge dieser Situation ist häufig schwer erkennbar. Die Route wird weiterhin als gültig betrachtet und erscheint in den BGP-Tabellen. Erst bei genauerer Betrachtung zeigt sich, dass sie nicht aktiv ist oder nicht in die Forwarding-Ebene übernommen wurde. Dieses Verhalten vermittelt den Eindruck, dass das Problem im BGP selbst liegt, obwohl die eigentliche Ursache in der fehlenden Integration mit dem IGP zu finden ist.
Um dieses Problem zu adressieren, wird häufig das Next-Hop-Verhalten gezielt verändert. Anstatt den ursprünglichen Einstiegspunkt beizubehalten, setzt ein Router sich selbst als neuen Next-Hop. Dadurch wird sichergestellt, dass alle nachgelagerten Router einen erreichbaren Pfad haben, da sie den Router ohnehin über interne Mechanismen kennen. Diese Anpassung verändert nicht den eigentlichen BGP-Pfad, sondern lediglich die Art und Weise, wie er im eigenen Netzwerk erreicht wird.
Diese Lösung ist weit verbreitet, hat aber auch Auswirkungen auf die Transparenz des Netzwerks. Der ursprüngliche Einstiegspunkt ist nicht mehr direkt sichtbar, da der Verkehr zunächst zum lokalen Router geleitet wird, der die Route weitergegeben hat. In vielen Designs ist dies gewünscht, da es die Kontrolle über den Datenfluss erhöht. In anderen Fällen kann es jedoch erforderlich sein, den ursprünglichen Next-Hop beizubehalten, um eine präzisere Steuerung zu ermöglichen.
Ein weiterer Aspekt ist die Interaktion mit Load Balancing und Multipath-Verfahren. Wenn mehrere gleichwertige BGP-Pfade existieren, können unterschiedliche Next-Hops entstehen. Die Fähigkeit, diese Pfade parallel zu nutzen, hängt nicht nur von den BGP-Attributen ab, sondern auch davon, ob alle beteiligten Next-Hops korrekt aufgelöst werden können. Fehlt diese Voraussetzung für einen der Pfade, wird er verworfen, selbst wenn er aus BGP-Sicht gleichwertig wäre.
In größeren Netzwerken ergibt sich daraus ein deutliches Bild: BGP entscheidet über Präferenzen, aber das tatsächliche Funktionieren hängt maßgeblich vom darunterliegenden Routing ab. Die Konsistenz zwischen dieser Kontroll-Ebene und der Weiterleitungsebene ist entscheidend. Sobald sie nicht mehr gegeben ist, entstehen Zustände, die sich nur durch ein Verständnis beider Ebenen erklären lassen.
Die praktische Konsequenz ist klar: BGP muss immer im Kontext des gesamten Netzwerks betrachtet werden. Der Next-Hop ist dabei der zentrale Verbindungspunkt zwischen den Protokollen. Er bestimmt, ob eine Route nicht nur logisch existiert, sondern auch tatsächlich nutzbar ist. Wer diesen Mechanismus verstanden hat, erkennt schnell, dass viele vermeintliche BGP-Probleme in Wirklichkeit Probleme der Erreichbarkeit sind, die sich nur indirekt im Verhalten des Protokolls zeigen.