iBGP Skalierung: Route Reflector Design, Cluster-IDs & Redundanz

iBGP skaliert in größeren Netzen nicht mit Full-Mesh: Ab einer gewissen Routeranzahl explodieren Session-Zahlen, Betrieb wird fehleranfällig und Changes dauern zu lange. Route Reflectors (RR) lösen dieses Problem, indem sie iBGP-Routen gezielt reflektieren und so Full-Mesh vermeiden. Damit RR-Design im Enterprise stabil ist, brauchst du drei Dinge: eine saubere Topologie (RR-Tiers), korrekt gesetzte Cluster-IDs (Loop-Prevention im RR-System) und Redundanz (damit ein RR-Ausfall keinen Routing-Kollaps erzeugt). Dieser Artikel erklärt die Praxis-Patterns, die in echten iBGP-Backbones funktionieren.

Warum Full-Mesh nicht skaliert

In iBGP muss ohne RR (oder Confederations) jeder Router mit jedem sprechen, damit Routen verteilt werden. Die Anzahl der Sessions wächst quadratisch und wird schnell unpraktisch.

Session-Wachstum

$\text{Sessions}=\frac{\text{n}\times \text{n}–1}{2}$

• n = 10 → 45 Sessions
• n = 50 → 1225 Sessions
• n = 200 → 19900 Sessions

Route Reflector Grundidee: RR und Clients

Ein Route Reflector nimmt iBGP-Routen von Clients (und Non-Clients) an und reflektiert sie gemäß Regeln weiter. Clients müssen nicht mehr untereinander meshen, sondern nur noch zum RR – dadurch sinkt die Session-Zahl drastisch.

• RR: reflektiert iBGP-Routen
• Client: iBGP-Neighbor, der vom RR bedient wird
• Non-Client: iBGP-Neighbor, der normal behandelt wird

RR Design Patterns: 1-Tier vs. 2-Tier

In Enterprise-Backbones sind zwei Patterns üblich. Kleine Netze funktionieren mit einem RR-Paar (1-Tier). Größere Netze nutzen 2-Tier: Core-RRs und regionale/PoP-RRs, um Update-Last und Failure Domains zu begrenzen.

• 1-Tier: ein RR-Paar, alle Clients hängen daran
• 2-Tier: Regional-RRs reflektieren zu Core-RRs (Skalierung)
• Best Practice: Failure Domains bewusst klein halten

Wann 2-Tier sinnvoll wird

• Viele Clients (hundert+), hohe Update-Rate
• Geografisch verteilte PoPs/Standorte
• Unterschiedliche Policy-Domänen (z. B. Core vs. Edge)

Cluster-ID: Warum sie existiert und wann sie kritisch wird

Cluster-IDs verhindern Route Reflection Loops: Ein RR fügt reflektierten Routen einen CLUSTER_LIST-Eintrag hinzu. Wenn eine Route wieder in denselben Cluster zurückkommt, wird sie verworfen. Das ist essenziell, sobald du mehrere RRs oder RR-Tiers hast.

• Cluster-ID identifiziert einen RR-Cluster (logische Einheit)
• CLUSTER_LIST wächst entlang der RR-Kette
• Loop-Prevention: Route mit eigener Cluster-ID wird gedroppt

Merker

$\text{CLUSTER\_LIST enthält Cluster-ID} \to \text{Route wird nicht erneut reflektiert}$

Cluster-ID Best Practices

Ein RR-Paar, das Redundanz liefert, sollte die gleiche Cluster-ID haben. Unterschiedliche Cluster-IDs im selben RR-Paar führen zu unerwarteten Pfaden und erhöhen Loop-Risiko in komplexen Designs.

• RR-Paar: gleiche Cluster-ID (ein Cluster)
• Unterschiedliche RR-Tiers/Regionen: unterschiedliche Cluster-IDs
• Cluster-ID dokumentieren wie IP-Plan (kein Wildwuchs)

Redundanz: RR-Ausfall ohne Routing-Outage

Ein einzelner RR ist ein Single Point of Failure. Deshalb ist „RR Pair“ die Standardanforderung. Clients peeren zu beiden RRs, damit ein Ausfall nur eine Session verliert, aber Routing weiterläuft.

• Jeder Client peert zu RR1 und RR2
• RR1 und RR2 teilen sich die gleiche Cluster-ID
• RRs sollten physisch/standortseitig getrennt sein (wenn möglich)

Client peert zu zwei RRs (Beispiel)

router bgp 65000
 neighbor 10.255.0.1 remote-as 65000
 neighbor 10.255.0.2 remote-as 65000
 neighbor 10.255.0.1 update-source loopback0
 neighbor 10.255.0.2 update-source loopback0

RR-Konfiguration: Client-Definition und Cluster-ID

Auf dem RR definierst du, welche Neighbors Clients sind. Zusätzlich setzt du die Cluster-ID. Die genaue CLI kann je Plattform/AFI variieren, das Muster bleibt gleich.

RR (Beispielkonzept)

router bgp 65000
 bgp cluster-id 10.255.0.100
neighbor 10.255.10.1 remote-as 65000

neighbor 10.255.10.1 route-reflector-client

neighbor 10.255.10.1 update-source loopback0
neighbor 10.255.10.2 remote-as 65000

neighbor 10.255.10.2 route-reflector-client

neighbor 10.255.10.2 update-source loopback0

Loop Prevention zusätzlich: Originator-ID verstehen

Neben CLUSTER_LIST nutzt RR auch Originator-ID, um klassische Reflection-Loops zu verhindern: Wenn eine Route wieder beim Originator landet, wird sie verworfen. Das ist ein weiterer Grund, warum RR-Design auch ohne Full-Mesh stabil sein kann.

• Originator-ID entspricht dem ursprünglichen iBGP-Origin
• Schützt vor Loops, wenn Route zurück zum Ursprung kommt
• Zusammen mit CLUSTER_LIST robust gegen RR-Schleifen

Policy-Design im RR-Umfeld: Wo du Policies platzierst

Ein häufiger Fehler ist, auf dem RR zu viel Policy zu machen. Best Practice ist: RRs möglichst „transparent“ halten und Policies an den Edge-Routern anwenden (Ingress/Egress), außer du baust bewusst Policy-RRs.

• RRs: möglichst nur reflektieren, nicht „verformen“
• Edges: LocalPref, Communities, Filtering
• Wenn Policy-RR: sauber dokumentieren und testen (hohes Risiko)

Fast Convergence im RR-Design: Add-Path und Multipath

RRs können Konvergenz verlangsamen, wenn Clients nur einen Pfad sehen. Add-Path kann helfen, mehrere Pfade zu verteilen, damit bei Ausfall des Best Path schneller ein Alternativpfad verfügbar ist. Das muss jedoch bewusst dimensioniert werden (Memory/Update-Last).

• Add-Path: mehr Alternativen im iBGP, weniger Path-Exploration
• Multipath: Lastverteilung, wenn Pfade ausreichend gleichwertig
• Trade-off: mehr State und mehr Updates

Verifikation: RR-Design prüfen wie ein Pro

Nach dem Design willst du belegen: Sessions stabil, Clients korrekt, Cluster-ID korrekt, und Routen werden wie erwartet reflektiert.

RR/Client Status

show ip bgp summary
show ip bgp neighbors | include Route-reflector|Cluster
show ip bgp <prefix>

Reflection-Indizien (CLUSTER_LIST/Originator)

show ip bgp <prefix> | include Originator|Cluster

Typische Pitfalls und wie du sie vermeidest

RR-Probleme sind selten „BGP kaputt“, sondern fast immer Design-/Konfigfehler. Diese Punkte solltest du gezielt gegenprüfen.

• Clients peeren nur zu einem RR → SPOF
• RR-Paar hat unterschiedliche Cluster-IDs → unerwartete Pfade
• RR zu viel Policy → schwer debuggbare Route-Manipulation
• Next-Hop Reachability fehlt (IGP) → Routes existieren, aber sind unusable

Quick-Template: RR Pair + Clients (Minimal-Baseline)

Dieses Template ist ein Startpunkt: RR-Paar mit gleicher Cluster-ID, Clients peeren zu beiden RRs via Loopbacks. Passe IPs/ASNs an.

! RR1/RR2 (gleiche Cluster-ID)
router bgp 65000
 bgp cluster-id 10.255.0.100
! RR1: Clients definieren

neighbor 10.255.10.1 remote-as 65000

neighbor 10.255.10.1 route-reflector-client

neighbor 10.255.10.1 update-source loopback0
! Client: zu beiden RRs

router bgp 65000

neighbor 10.255.0.1 remote-as 65000

neighbor 10.255.0.2 remote-as 65000

neighbor 10.255.0.1 update-source loopback0

neighbor 10.255.0.2 update-source loopback0

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.