BGP Route Advertisement, Next-Hop und Route Reflectors

26.08.2026 5 Min. Lesezeit

Einleitung

Im letzten Artikel haben wir gelernt, wie BGP aus mehreren möglichen Wegen den bevorzugten Pfad auswählt.

Dabei standen Attribute wie:

Local Preference
AS Path
MED
Origin

im Mittelpunkt.

Doch bevor BGP überhaupt eine Entscheidung treffen kann, müssen die Routen zunächst verteilt werden.

Genau hier beginnt einer der interessantesten Unterschiede zwischen eBGP und iBGP.

Viele Administratoren verstehen die grundlegende BGP-Pfadselektion recht schnell. Schwierigkeiten entstehen meist erst dann, wenn mehrere BGP-Router innerhalb eines Unternehmens zusammenarbeiten sollen.

Warum sieht ein Router bestimmte Routen nicht?

Warum entstehen plötzlich unerwartete Routing-Lücken?

Und warum benötigt BGP zusätzliche Mechanismen wie Route Reflectors?

Diese Fragen gehören zu den klassischen JNCIS-ENT-Themen.

Ein einfaches BGP-Szenario

Betrachten wir zunächst ein Unternehmen mit zwei Edge-Routern:

          Internet
              |
         Provider
              |
      ----------------
      |              |
     R1            R2
      \            /
       \          /
        Unternehmensnetz

Beide Router lernen externe Routen vom Provider.

Beispielsweise:

203.0.113.0/24

Diese Route muss nun innerhalb des Unternehmens bekannt gemacht werden.

Dafür verwendet BGP:

iBGP

Der Unterschied zwischen eBGP und iBGP

Wir erinnern uns:

eBGP

Kommunikation zwischen unterschiedlichen Autonomous Systems.

AS65000
   |
 eBGP
   |
AS65100

iBGP

Kommunikation innerhalb desselben Autonomous Systems.

AS65000

R1 ---- R2

Warum existiert iBGP überhaupt?

Ein Edge-Router kennt möglicherweise tausende externe Routen.

Diese Informationen müssen intern verteilt werden.

Andernfalls würden andere Router im Unternehmen die Ziele nicht erreichen.

Das berühmte iBGP-Problem

Nun kommen wir zu einer der wichtigsten BGP-Regeln.

Betrachten wir folgendes Netzwerk:

Alle Router befinden sich im selben AS.

R1 lernt eine Route vom Internet.

Anschließend verteilt R1 diese Route an R2.

Die entscheidende Frage lautet:

Gibt R2 die Route automatisch an R3 weiter?

Viele Einsteiger antworten:

Natürlich.

Doch genau das passiert nicht.

Die wichtigste iBGP-Regel

Eine Route, die über iBGP gelernt wurde, wird nicht an andere iBGP-Nachbarn weitergegeben.

Beispiel

R1 → iBGP → R2

R2 lernt die Route.

Danach:

R2 → iBGP → R3

Die Route wird nicht weitergegeben.

Warum existiert diese Regel?

Der Hintergrund ist die Schleifenvermeidung.

BGP besitzt innerhalb eines AS keinen AS Path, der für die Erkennung interner Schleifen genutzt werden könnte.

Deshalb verhindert BGP die Weitergabe standardmäßig.

Die Konsequenz

Wenn jede iBGP-Verbindung manuell aufgebaut werden müsste, entstünde ein Problem.

Nehmen wir fünf Router:

R1
R2
R3
R4
R5

Damit alle Router alle Informationen erhalten, benötigt man:

Full Mesh

Das Full-Mesh-Konzept

Jeder Router muss mit jedem anderen Router eine iBGP-Session aufbauen.

Bei fünf Routern:

R1 ↔ R2
R1 ↔ R3
R1 ↔ R4
R1 ↔ R5

R2 ↔ R3
R2 ↔ R4
R2 ↔ R5

R3 ↔ R4
R3 ↔ R5

R4 ↔ R5

Skalierungsproblem

Bei:

10 Routern

entstehen:

45 Sessions

Bei:

100 Routern

bereits:

4950 Sessions

Spätestens jetzt wird klar:

Das skaliert nicht.

Die Lösung: Route Reflectors

Um das Full-Mesh-Problem zu lösen, wurde das Route-Reflector-Konzept entwickelt.

Grundidee

Ein spezieller Router übernimmt die Weitergabe von iBGP-Routen.

Beispiel:

RR steht für:

Route Reflector

Was macht ein Route Reflector?

Der Route Reflector durchbricht die normale iBGP-Regel.

Normalerweise gilt:

iBGP gelernt
↓
nicht weitergeben

Beim Route Reflector gilt:

iBGP gelernt
↓
reflektieren
↓
andere Clients

Vorteil

Die Anzahl der Sessions sinkt drastisch.

Statt Full Mesh:

R1 ↔ RR
R2 ↔ RR
R3 ↔ RR

Prüfungsrelevanz

Wenn gefragt wird:

Warum werden Route Reflectors eingesetzt?

Antwort:

Reduzierung der iBGP-Full-Mesh-Anforderungen

Route Reflector Clients

Die Router, die mit dem Route Reflector verbunden sind, heißen:

Clients

Beispiel

RR

├─ Client R1
├─ Client R2
└─ Client R3

Der RR verteilt die BGP-Routen zwischen den Clients.

Next-Hop-Verhalten in BGP

Ein weiteres äußerst beliebtes JNCIS-ENT-Thema.

Betrachten wir:

Internet
   |
  R1
   |
 iBGP
   |
  R2

R1 lernt:

203.0.113.0/24

Die Überraschung

Wenn R1 die Route an R2 weitergibt, bleibt der ursprüngliche Next Hop oft erhalten.

Beispiel:

Route:
203.0.113.0/24

Next Hop:
198.51.100.1

Problem

R2 kennt möglicherweise keinen Weg zu:

198.51.100.1

Die Route erscheint zwar in der BGP-Tabelle, kann aber nicht genutzt werden.

Next-Hop Reachability

Dies führt zu einer der wichtigsten BGP-Regeln:

Der Next Hop muss erreichbar sein.

Andernfalls wird die Route nicht installiert.

Typische Symptome

Route vorhanden:

show route receive-protocol bgp

Aber nicht aktiv:

show route

Häufige Ursache:

Next Hop unreachable

Next-Hop Self

Um dieses Problem zu lösen, wird häufig verwendet:

next-hop self

Was passiert dabei?

Der sendende Router ersetzt den ursprünglichen Next Hop durch seine eigene Adresse.

Beispiel:

Vorher:

Next Hop:
198.51.100.1

Nachher:

Next Hop:
10.0.0.1

Dadurch können interne Router die Route problemlos nutzen.

Route Advertisement in eBGP

Nun betrachten wir die externe Weitergabe.

Standardverhalten

eBGP-Routen dürfen weitergegeben werden.

Beispiel:

AS65000
   |
 eBGP
   |
AS65100

Empfangene Routen werden an andere eBGP-Nachbarn weiterverteilt.

Warum funktioniert das?

Der AS Path wächst bei jedem Übergang.

Dadurch erkennt BGP mögliche Schleifen.

Route Advertisement und Schleifenvermeidung

Beispiel:

65000 65100 65200

Wenn ein Router seine eigene AS-Nummer entdeckt:

wird die Route verworfen.

Prüfungsrelevanz

AS Path ist das wichtigste Werkzeug zur Schleifenvermeidung zwischen Autonomous Systems.

Wichtige Junos-Kommandos

BGP-Status:

show bgp summary

Nachbarn:

show bgp neighbor

Empfangene Routen:

show route receive-protocol bgp

Beworbene Routen:

show route advertising-protocol bgp

Detailinformationen:

show route protocol bgp extensive

Typische JNCIS-ENT Prüfungsfallen

Falle 1

Annehmen, dass iBGP-Routen automatisch weitergegeben werden.

Tun sie nicht.

Falle 2

Route Reflector und Router-ID verwechseln.

Falle 3

Next Hop ignorieren.

Viele BGP-Probleme entstehen durch unerreichbare Next Hops.

Falle 4

Glauben, dass Route Reflectors Routing-Schleifen erzeugen.

Sie verwenden zusätzliche Attribute wie Cluster-ID und Originator-ID zur Schleifenvermeidung.

Für die JNCIS-ENT reicht meist das Grundverständnis.

Falle 5

Full Mesh als optionale Empfehlung betrachten.

Ohne Route Reflectors oder Confederations ist Full Mesh die Standardanforderung für iBGP.

Praxisbezug

Fast jedes größere Enterprise-Netzwerk mit BGP verwendet Route Reflectors.

Ein vollständiges iBGP-Full-Mesh wäre in modernen Umgebungen kaum wartbar.

Auch das Next-Hop-Verhalten gehört zu den häufigsten Ursachen für BGP-Troubleshooting-Fälle.

In vielen realen Störungen existiert die Route tatsächlich bereits in BGP – sie kann lediglich nicht genutzt werden, weil der Next Hop unerreichbar ist.

Genau deshalb wird dieses Thema in der JNCIS-ENT regelmäßig abgefragt.

Fazit

Die Verteilung von BGP-Routen innerhalb eines Autonomous Systems unterscheidet sich grundlegend von klassischen IGPs.

Die wichtigste Regel lautet:

iBGP-gelernte Routen werden nicht automatisch an andere iBGP-Nachbarn weitergegeben.

Dadurch entsteht die Full-Mesh-Anforderung, die in größeren Netzwerken durch Route Reflectors gelöst wird.

Für die JNCIS-ENT solltest du insbesondere verstehen:

den Unterschied zwischen eBGP- und iBGP-Advertisements,
die Full-Mesh-Anforderung,
die Rolle von Route Reflectors,
das Konzept der Route Reflector Clients,
sowie die Bedeutung der Next-Hop-Reachability.

Diese Themen bilden die Grundlage für viele BGP-Design- und Troubleshooting-Fragen.