BGP Route Reflector: Skalierung im iBGP richtig umsetzen

Ein BGP Route Reflector (RR) löst ein zentrales Skalierungsproblem von iBGP: Ohne RR müssten alle iBGP-Router ein Full Mesh bilden, was bei vielen Routern schnell unübersichtlich und betrieblich teuer wird. Mit einem RR werden iBGP-Routen gezielt „reflected“, sodass Clients nicht mehr untereinander peeren müssen. Dieses Tutorial erklärt das Konzept praxisnah und zeigt ein sauberes Cisco-IOS-Beispiel inklusive Best Practices.

Warum iBGP ohne Route Reflector nicht skaliert

iBGP hat die Regel: iBGP-gelernte Routen werden standardmäßig nicht an andere iBGP-Nachbarn weitergegeben. Damit alle Router alle Routen kennen, braucht man deshalb ein Full Mesh – und das wächst quadratisch.

Session-Anzahl im Full Mesh

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

• 10 Router → 45 iBGP-Sessions
• 50 Router → 1225 iBGP-Sessions
• 100 Router → 4950 iBGP-Sessions

Was ein Route Reflector genau macht

Ein RR ist ein iBGP-Router, der Routen zwischen iBGP-Nachbarn „reflektiert“. Seine Clients peeren mit dem RR, nicht untereinander. Der RR übernimmt damit die Verteilung der Routen innerhalb der RR-Topologie.

• RR empfängt Routen von Clients und reflektiert sie an andere Clients
• Clients brauchen kein iBGP-Full-Mesh mehr
• Ein RR bleibt ein normaler iBGP-Router, nur mit RR-Rolle

Kernbegriffe: RR, Client, Cluster und Cluster-ID

Für ein stabiles Design sind drei Begriffe wichtig. Der Cluster-ID verhindert Reflections-Loops zwischen mehreren RRs. Der Originator-ID verhindert, dass eine Route zum Ursprung zurückreflektiert wird.

• RR: Route Reflector (reflektiert iBGP-Routen)
• Client: iBGP-Nachbar, der als RR-Client markiert ist
• Cluster-ID: Identität einer RR-Gruppe zur Loop-Vermeidung

Merker: RR reduziert Mesh, braucht aber klare Struktur

$\text{RR} \to \text{Skalierung} => \text{Cluster/Redundanz planen}$

Praxis-Topologie: Zwei RR (redundant) und zwei Clients

Ein sauberes Enterprise-Muster ist ein RR-Paar (RR1/RR2) und mehrere Clients (Edge/Leaf/PE). Clients peeren zu beiden RRs, damit ein RR-Ausfall nicht den iBGP-Backbone zerlegt.

• AS: 65001
• RR1 Loopback: 10.255.255.1
• RR2 Loopback: 10.255.255.2
• Client1 Loopback: 10.255.255.11
• Client2 Loopback: 10.255.255.12

Voraussetzung: Loopbacks per IGP erreichbar

iBGP über Loopbacks ist Best Practice. Dafür müssen die Loopbacks im IGP (OSPF/EIGRP/Static) erreichbar sein, sonst bleibt BGP in Active.

Router# show ip route 10.255.255.1
Router# ping 10.255.255.1

Konfiguration auf dem Route Reflector (RR1/RR2)

Auf dem RR definierst du iBGP-Neighbors zu den Clients und markierst sie als route-reflector-client. Zusätzlich setzt du eine Cluster-ID, insbesondere wenn du mehr als einen RR im Cluster betreibst.

RR1: iBGP zu Clients, RR-Client markieren, Cluster-ID setzen

RR1# configure terminal
RR1(config)# router bgp 65001
RR1(config-router)# bgp cluster-id 10.255.255.1
RR1(config-router)# neighbor 10.255.255.11 remote-as 65001

RR1(config-router)# neighbor 10.255.255.11 update-source loopback0

RR1(config-router)# neighbor 10.255.255.11 route-reflector-client
RR1(config-router)# neighbor 10.255.255.12 remote-as 65001

RR1(config-router)# neighbor 10.255.255.12 update-source loopback0

RR1(config-router)# neighbor 10.255.255.12 route-reflector-client

RR1(config-router)# end

RR2: identisches Muster, Cluster-ID konsistent im Cluster

Wenn RR1 und RR2 im gleichen Cluster arbeiten, sollte die Cluster-ID identisch sein. In der Praxis wird dafür oft eine feste Cluster-ID verwendet.

RR2# configure terminal
RR2(config)# router bgp 65001
RR2(config-router)# bgp cluster-id 10.255.255.1
RR2(config-router)# neighbor 10.255.255.11 remote-as 65001

RR2(config-router)# neighbor 10.255.255.11 update-source loopback0

RR2(config-router)# neighbor 10.255.255.11 route-reflector-client
RR2(config-router)# neighbor 10.255.255.12 remote-as 65001

RR2(config-router)# neighbor 10.255.255.12 update-source loopback0

RR2(config-router)# neighbor 10.255.255.12 route-reflector-client

RR2(config-router)# end

Konfiguration auf den Clients (Client1/Client2)

Clients peeren zu beiden RRs. Sie sind normale iBGP-Router und werden nicht gegenseitig vernetzt. In der Praxis setzt du zusätzlich oft next-hop-self abhängig davon, ob der RR auch als Transit-Next-Hop dienen soll.

Client1: iBGP zu RR1 und RR2

Client1# configure terminal
Client1(config)# router bgp 65001
Client1(config-router)# neighbor 10.255.255.1 remote-as 65001
Client1(config-router)# neighbor 10.255.255.1 update-source loopback0
Client1(config-router)# neighbor 10.255.255.2 remote-as 65001
Client1(config-router)# neighbor 10.255.255.2 update-source loopback0
Client1(config-router)# end

Client2: iBGP zu RR1 und RR2

Client2# configure terminal
Client2(config)# router bgp 65001
Client2(config-router)# neighbor 10.255.255.1 remote-as 65001
Client2(config-router)# neighbor 10.255.255.1 update-source loopback0
Client2(config-router)# neighbor 10.255.255.2 remote-as 65001
Client2(config-router)# neighbor 10.255.255.2 update-source loopback0
Client2(config-router)# end

Next-Hop-Verhalten im RR-Design: häufige Falle

Route Reflectors ändern das Next-Hop-Attribut bei iBGP standardmäßig nicht. Das ist korrekt, kann aber dazu führen, dass Clients Routen sehen, deren Next-Hop im IGP nicht erreichbar ist. Das ist einer der häufigsten Gründe für „Route in BGP, aber nicht im RIB“.

• Clients müssen den Next-Hop via IGP/Static erreichen können
• Alternativ: Edge-Design mit next-hop-self an geeigneter Stelle
• Prüfen: Next-Hop in show ip bgp und Route zum Next-Hop

Next-Hop prüfen

Router# show ip bgp 203.0.113.0
Router# show ip route <next-hop-ip>

Verifikation: Funktioniert Reflection und Redundanz?

Du prüfst zuerst, ob alle Sessions „Established“ sind, dann ob Routen zwischen Clients verteilt werden, und schließlich ob Best Paths installiert werden. Bei zwei RRs sollte ein RR-Ausfall nicht zum vollständigen Verlust der iBGP-Verteilung führen.

Sessions prüfen

RR1# show ip bgp summary
RR2# show ip bgp summary
Client1# show ip bgp summary
Client2# show ip bgp summary

Routes und Reflection prüfen

RR1# show ip bgp
Client1# show ip bgp
Client1# show ip route bgp

RR-spezifische Ansicht

RR1# show ip bgp neighbors 10.255.255.11
RR1# show ip bgp neighbors 10.255.255.12

Best Practices: Route Reflector betriebssicher designen

Ein RR ist ein zentrales Element. Mit diesen Standards bleibt das Design stabil, skalierbar und gut zu betreiben.

• Immer RR-Redundanz: mindestens zwei RRs pro Cluster
• Clients peeren zu beiden RRs (keine Single Points of Failure)
• Loopbacks als Neighbor-Endpunkte, IGP-Erreichbarkeit sicherstellen
• Cluster-ID konsistent pro Cluster setzen
• Next-Hop-Design bewusst planen (IGP zum Next-Hop oder gezieltes next-hop-self)
• Filter/Policies zentral und nachvollziehbar halten

Typische Fehler und schnelle Fixes

Wenn RR-Designs „komisch“ wirken, ist es meist kein BGP-Problem, sondern Erreichbarkeit/Next-Hop oder falsche RR-Client-Zuordnung.

• Sessions bleiben Active: Loopback-Routing fehlt, update-source falsch
• Clients sehen Routen, aber installieren sie nicht: Next-Hop unreachable
• Routen „stoppen“: Client nicht als RR-Client markiert oder peert nur zu einem RR
• Loops/Instabilität: Cluster-ID/Design inkonsistent

Quick-Checks

show ip bgp summary
show ip bgp
show ip bgp neighbors
show ip route 10.255.255.0
show ip route bgp

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.