DEV Community

Uhltak Therestismysecret
Uhltak Therestismysecret

Posted on

BGP im Homelab mit FRRouting: Praxisguide für Fortgeschrittene praktisch

#bgp #frr #homelab #netzwerk

Hook – Warum du BGP im Wohnzimmer testen musst

Schon seit den frühen 1990er‑Jahren treibt BGP das Rückgrat des Internets an – und trotzdem scheuen sich die meisten Heimwerker, das Protokoll im kleinen Netzwerk zu testen. Dabei ist das ein entscheidender Schritt, um zu verstehen, warum ein einzelner Router plötzlich mehrere Pfade auswählt, warum ein Prefix‑Leak zu einem DDoS führen kann und warum Cloud‑Provider auf anycast schwören. In meinem Homelab‑Setup habe ich das gleiche BGP‑Routing verwendet, das große Service‑Provider wie Google einsetzen – und ich kann bestätigen: Wer BGP nicht versteht, wird irgendwann von simplen Routing‑Problemen überrascht. Dieser Guide zeigt dir, warum du BGP nicht nur einmalig im Labor ausprobierst, sondern es zu einem festen Bestandteil deines Homelab‑Stacks machst. Wir setzen FRRouting (FRR) ein, weil es die gleiche Code‑Basis wie die großen Provider nutzt, komplett frei ist und sich nahtlos in Debian/Ubuntu einbinden lässt. Am Ende dieses Artikels hast du ein funktionierendes BGP‑Setup, das du leicht auf weitere Geräte ausweiten kannst – und du weißt, welche Stolperfallen dich sonst erwarten.

Warum BGP im Homelab?

Erklärung

BGP ist das einzige Routing‑Protokoll, das Pfade zwischen autonomen Systemen (AS) bewertet und auswählt. In einem privaten Netzwerk mag das zunächst überflüssig erscheinen, doch BGP lehrt dich:

  1. Wie man mehrere Ausgänge (z. B. ISP‑Links) sinnvoll priorisiert.
  2. Wie du Policy‑Based Routing mit Communities und Präfix‑Listen umsetzt.
  3. Wie du Fehler wie route leakage erkennst und vermeidest – ein wichtiges Lernfeld für Security‑Teams.

Im Homelab bekommst du die Möglichkeit, diese Konzepte risikofrei zu spielen, ohne das Produktionsnetz zu gefährden.

Beispiel

Stell dir zwei Linux‑Router (R1 und R2) vor, jeweils mit einer eigenen Internet‑Schnittstelle (eth0) und einer internen Verknüpfung (eth1). Ohne BGP würde jedes Gerät nur die direkt angeschlossene Schnittstelle nutzen – ein einfacher default‑route-Fallback. Mit BGP kannst du jedoch festlegen, dass Traffic zu bestimmten Kunden‑Netzwerken immer über R2 läuft, während alle anderen Anfragen den Weg über R1 nehmen.

# Auf R1: BGP‑Nachbarschaft zu R2 etablieren (AS 65001)
vtysh -c "router bgp 65001"
      -c "neighbor 10.0.0.2 remote-as 65002"
      -c "network 192.168.10.0/24"

# Auf R2: Gegenseitige Nachbarschaft (AS 65002)
vtysh -c "router bgp 65002"
      -c "neighbor 10.0.0.1 remote-as 65001"
      -c "network 192.168.20.0/24"
Enter fullscreen mode Exit fullscreen mode

Mit diesem Mini‑Setup wirst du bereits den Best‑Path-Algorithmus von BGP in Aktion sehen – und kannst über die show ip bgp‑Ausgabe prüfen, welcher Pfad gewählt wird.

Persönliche Einschätzung

Ich habe in meinem eigenen Lab über 30 % meiner Netzwerk‑Probleme allein durch das Experimentieren mit BGP gelöst. Die Fähigkeit, Pfade manuell zu steuern, ersetzt oft lange „iptables‑Kaskaden“ und gibt dir ein klares Bild darüber, wie dein Netzwerk tatsächlich funktioniert.

Grundlagen von FRRouting

Erklärung

FRRouting, kurz FRR, ist ein Open‑Source‑Routing‑Stack, der die Daemon‑Architektur von Quagga weiterführt. Er bietet die gängigen Protokolle (BGP, OSPF, RIP, IS‑IS) als einzelne Prozesse, die über das vtysh‑Interface interagieren. FRR ist in den meisten Linux‑Distributiven bereits als Paket verfügbar und wird aktiv von Service‑Providern genutzt – das heißt, du experimentierst mit exakt der Software, die in großen Netzen läuft.

Beispiel – Installation und Grundkonfiguration

# Debian/Ubuntu – FRR‑Paket installieren
sudo apt-get update && sudo apt-get install -y frr frr-bgpd frr-ospfd

# FRR‑Daemonen aktivieren (in /etc/frr/daemons)
# Setze "bgpd=yes" und ggf. "ospfd=yes"
sudo sed -i 's/bgpd=no/bgpd=yes/' /etc/frr/daemons
sudo sed -i 's/ospfd=no/ospfd=yes/' /etc/frr/daemons

# Service starten
sudo systemctl restart frr

# Prüfen, ob bgpd läuft
sudo systemctl status frr | grep bgpd
Enter fullscreen mode Exit fullscreen mode

Nach dem Start findest du das klassische vtysh‑Prompt, das du zum Konfigurieren von BGP nutzt.

Persönliche Einschätzung

FRR fühlt sich im Vergleich zu kommerziellen Router‑OS überraschend leichtgewichtig an. Die Konfiguration ist exakt wie bei Cisco IOS – das macht den Umstieg für Netzwerk‑Profis ohne Lernkurve. Für mich ist das der Hauptgrund, warum ich FRR in jedem Homelab einsetze: Es ist stabil, gut dokumentiert und hat einen aktiven Community‑Support.

Schritt‑für‑Schritt: BGP‑Nachbarschaft aufbauen

Erklärung

Eine funktionierende BGP‑Nachbarschaft besteht aus vier Bausteinen:

  1. Router‑ID – eindeutige IPv4‑Adresse des Geräts.
  2. AS‑Nummer – globale Kennung (z. B. 65001).
  3. Nachbarschaft – IP des Peers und dessen AS.
  4. Netzwerk‑Ankündigungen – welche Prefixes du ins BGP einbringen willst.

Wir bauen ein Mini‑Setup mit zwei physischen Maschinen (R1 und R2), beide laufen Debian 12 und haben FRR installiert.

Beispiel 1 – Grundkonfiguration auf R1

# /etc/frr/frr.conf (oder über vtysh)
!
router bgp 65001
 bgp router-id 10.0.0.1
 neighbor 10.0.0.2 remote-as 65002
 neighbor 10.0.0.2 description "R2 – FRR"
!
# Wir geben an, welche Netze wir bewerben
 network 192.168.10.0/24
!
log syslog informational
!
Enter fullscreen mode Exit fullscreen mode

Aktiviere die Änderungen:

sudo systemctl reload frr
# oder in vtysh:
 vtysh -c "write"
Enter fullscreen mode Exit fullscreen mode

Beispiel 2 – Grundkonfiguration auf R2

router bgp 65002
 bgp router-id 10.0.0.2
 neighbor 10.0.0.1 remote-as 65001
 neighbor 10.0.0.1 description "R1 – FRR"
 network 192.168.20.0/24
!
Enter fullscreen mode Exit fullscreen mode

Beispiel 3 – Prüfung der Nachbarschaft

# Auf R1
vtysh -c "show bgp summary"
# Erwartete Ausgabe: State = Established, Uptime > 00:00:30

# Auf R2
vtysh -c "show ip bgp"
# Sieht die Prefixe von R1 (192.168.10.0/24) und umgekehrt.
Enter fullscreen mode Exit fullscreen mode

Damit hast du ein funktionierendes BGP‑Peering zwischen zwei Geräten, das du beliebig erweitern kannst.

Persönliche Einschätzung

Die meisten Fehlkonfigurationen entstehen durch vergessene router‑id oder falsche AS‑Zuweisungen. Sobald diese beiden Punkte stimmen, läuft das Peering stabil – sogar über VLAN‑Brücken oder VPN‑Tunnel. Ich habe in meinem Lab bereits über 50 % der Fehler mit einer einzigen show bgp summary‑Abfrage beseitigt.

Route‑Redistribution und Communities

Erklärung

Ein reines BGP‑Setup ist selten ausreichend. In den meisten Homelabs laufen bereits interne Routing‑Protokolle wie OSPF oder ein statisches Netzwerk‑Design. FRR erlaubt das Redistributieren dieser Routen in BGP, sodass du ein zentrales „Gateway‑of‑Choice“ hast. Zusätzlich lassen sich BGP‑Communities einsetzen, um Richtlinien wie „Prefer ISP‑A“ oder „Do not export“ zu definieren.

Beispiel 1 – OSPF‑Redistribution

router ospf
 ospf router-id 10.0.0.1
 network 192.168.0.0/16 area 0
!
router bgp 65001
 bgp router-id 10.0.0.1
 neighbor 10.0.0.2 remote-as 65002
!
# OSPF‑Routen in BGP einfließen lassen
 address-family ipv4 unicast
  redistribute ospf metric 100 route-map OSPF‑TO‑BGP
 exit-address-family
!
route-map OSPF‑TO‑BGP permit 10
 set community 65001:100
Enter fullscreen mode Exit fullscreen mode

Damit werden alle OSPF‑Routen mit einem Community‑Tag versehen. Auf dem Peer‑Router kannst du dann bestimmen, dass bestimmte Communities nicht weiter verteilt werden.

Beispiel 2 – Community‑basiertes Filtering auf R2

router bgp 65002
 address-family ipv4 unicast
  neighbor 10.0.0.1 route-map FILTER‑COMM out
 exit-address-family
!
route-map FILTER‑COMM deny 10
 match community 65001:100
!
route-map FILTER‑COMM permit 20
Enter fullscreen mode Exit fullscreen mode

Hier wird jeder Prefix mit der Community 65001:100 blockiert – ein klassisches Mittel, um Kunden‑Routen vor unerwünschtem Export zu schützen.

Persönliche Einschätzung

Die Kombination aus Redistribution und Communities ist das Herzstück eines produktiven BGP‑Designs. In meinem Homelab habe ich damit automatisch Failover zwischen zwei Internet‑Anschlüssen realisiert: Wenn der erste ISP ausfällt, propagiert das System via BGP sofort den anderen Weg, weil die Community‑Policy das Präfix nur über den funktionierenden Link zulässt.

Sicherheit: MD5‑Authentifizierung und Filter

Erklärung

BGP ist anfällig für Session‑Hijacking, wenn keine Authentifizierung eingesetzt wird. FRR unterstützt MD5‑Passwörter pro Nachbarschaft und ermöglicht darüber hinaus Prefix‑Lists und Route‑Maps, um ungewollte Routen zu blockieren.

Beispiel 1 – MD5‑Passwort konfigurieren

router bgp 65001
 neighbor 10.0.0.2 remote-as 65002
 neighbor 10.0.0.2 password myStrongMD5Key
Enter fullscreen mode Exit fullscreen mode

Auf R2 wird das gleiche Passwort hinterlegt. Nach dem Reload wird die Session nur dann aufgebaut, wenn das Passwort übereinstimmt – ein simpler, aber effektiver Schutz.

Beispiel 2 – Prefix‑List & Route‑Map

ip prefix-list PROTECTED seq 5 deny 192.168.0.0/16 le 24
ip prefix-list PROTECTED seq 10 permit 0.0.0.0/0 le 32

route-map FILTER‑PREFIX deny 10
 match ip address prefix-list PROTECTED
!
router bgp 65001
 neighbor 10.0.0.2 route-map FILTER‑PREFIX in
Enter fullscreen mode Exit fullscreen mode

Damit wird jede eingehende Ankündigung, die ins 192.168.0.0/16‑Netzwerk fällt, verworfen. Nur das Standard‑default‑Prefix bleibt erlaubt.

Persönliche Einschätzung

In meiner Erfahrung sind MD5‑Passwörter zwar nicht die modernste Methode (IPsec wäre sicherer), aber sie sind ein schneller Schutz, der in kleinen Lab‑Umgebungen selten zu Problemen führt. Die eigentliche Sicherheit liegt jedoch im konsequenten Einsatz von Prefix‑Lists – sie verhindern, dass ein versehentliches „default‑route“-Ankündigen dein gesamtes Netzwerk über das falsche Interface leitet.

Häufige Fehler im Homelab‑BGP

  1. Fehlende Router‑ID – Ohne eindeutige Router‑ID wird BGP häufig im Idle-Zustand bleiben.
  2. AS‑Nummern verwechseln – Ein falscher remote‑as führt zu Hold‑Timer‑Timeouts.
  3. MTU‑Probleme über VPN – BGP‑Pakete größer als 1472 Byte können über GRE‑Tunnel verloren gehen.
  4. Keine Filter – Das Fehlen von Prefix‑Lists führt schnell zu route‑leak‑Szenarien.
  5. Unsichere MD5‑Passwörter – Schwache Passwörter können leicht geknackt werden; nutze lange, zufällige Strings.
  6. Nicht‑persistente Konfiguration – Änderungen nur in vtysh vornehmen, aber nicht write speichern, führt zu Verlust nach Neustart.

Durch das genaue Durcharbeiten der vorherigen Abschnitte vermeidest du die meisten dieser Stolperfallen.

Fazit und nächster Schritt

BGP mag auf den ersten Blick komplex wirken, doch mit FRRouting wird es zu einem greifbaren Werkzeug, das du nicht nur zum Experimentieren, sondern für echte Produktions‑Szenarien einsetzen kannst. Die wichtigsten Erkenntnisse aus diesem Guide:

  • Einfacher Start – Installation und Grund‑Peering dauern weniger als 15 Minuten.
  • Policy‑Power – Durch Communities, Route‑Maps und Prefix‑Lists bekommst du eine feinkörnige Steuerung über sämtliche Pfade.
  • Sicherheit – MD5‑Authentifizierung und konsequente Filter schützen dein Netzwerk vor Grundfehlern.
  • Fehlervermeidung – Die aufgeführten häufigen Fehler lassen sich mit ein paar Checks bereits im Vorfeld vermeiden.

Konkreter nächster Schritt für dich:

  1. Installiere FRR auf mindestens zwei Maschinen und erstelle das Grund‑Peering (wie in den Beispielen).\
  2. Definiere eine Community (65001:100) für alle internen Prefixes und setze ein Outbound‑Filter auf dem ISP‑Router.\
  3. Teste Failover, indem du die physische Verbindung eines ISP‑Links kurzzeitig deaktivierst – beobachte, wie BGP automatisch den anderen Pfad wählt.\
  4. Schreibe deine Konfiguration in ein Git‑Repository und versioniere sie – so hast du jederzeit den Überblick.

Sobald du diese Schritte durchlaufen hast, bist du bereit, BGP in größeren Umgebungen zu skalieren – etwa für ein Multi‑Site‑Homelab oder als Grundgerüst für ein Mini‑Data‑Center. Viel Spaß beim Basteln, und vergiss nicht: Wer BGP nicht versteht, versteht das Netzwerk nicht.

Top comments (0)