DEV Community

Uhltak Therestismysecret
Uhltak Therestismysecret

Posted on

FRRouting im Homelab: BGP für Fortgeschrittene – Praxis‑Guide & Tipps

#bgp #frrouting #homelab #netzwerk

FRRouting im Homelab: BGP für Fortgeschrittene – Praxis‑Guide & Tipps

Hook – Stell dir vor, du könntest exakt dieselbe Routing‑Logik, die Internet‑Provider nutzen, in deinem Wohnzimmer‑Rack testen. Kein Cloud‑Abonnement, keine teuren Lizenzen – nur ein alter Laptop, ein paar Ethernet‑Kabel und FRRouting (FRR). Genau das ermöglicht ein BGP‑Homelab. In den letzten Jahren hat das Interesse daran explosionsartig zugenommen, weil es nicht nur ein tiefes Verständnis von IP‑Routing vermittelt, sondern auch das Fundament für Network‑Automation, SD‑WAN und Hybrid‑Cloud legt. In diesem Artikel zeige ich dir, wie du BGP mit FRR im eigenen Homelab einrichtest, welche Stolperfallen typisch sind und warum du das jetzt unbedingt ausprobieren solltest.

Warum BGP im Homelab? – Mehr als nur Router‑Übung

BGP (Border Gateway Protocol) ist das Rückgrat des Internets. Alle großen Provider, Cloud‑Anbieter und Unternehmen setzen es ein, um Tausende von Routen zu verwalten. Für einen Hobby‑Netzwerker mag das übertrieben klingen – bis du merkst, dass BGP dir präzise Kontrolle über Pfad‑Auswahl, Policy‑Based Routing und Multi‑Homing bietet. Du kannst z. B. ein zweites ISP‑Kabel an deinem Heimrouter anschließen und exakt bestimmen, welcher Traffic über welchen ISP geht – ideal für Redundanz und Kostenoptimierung.

Persönliche Einschätzung: In meinem eigenen Lab war das Umstellen von statischen Default‑Routes auf dynamisches BGP‑Routing das entscheidende Upgrade. Plötzlich konnten meine virtuellen Maschinen (VMs) nahtlos zwischen zwei Internet‑Anbindungen wechseln, ohne dass ich manuell eingreifen musste.

FRR installieren – Der einfache Weg zum BGP‑Daemon

FRR ist die offene Variante des berühmten Quagga‑Stacks und wird von vielen Service‑Providern eingesetzt. Die Installation ist auf den gängigen Distributionen ein Kinderspiel.

# Auf Debian/Ubuntu 22.04
sudo apt update && sudo apt install frr frr-pythontools

# Auf CentOS 9 Stream (EPEL nötig)
sudo dnf install epel-release
sudo dnf install frr frr-pythontools
Enter fullscreen mode Exit fullscreen mode

Nach der Installation musst du die Daemon‑Konfiguration anpassen, sonst startet FRR ohne BGP‑Modul.

# /etc/frr/daemons – BGP aktivieren
sudo sed -i 's/^bgpd=no/bgpd=yes/' /etc/frr/daemons
sudo systemctl restart frr
Enter fullscreen mode Exit fullscreen mode

Persönliche Einschätzung: Die meisten Probleme in frühen Testphasen entstehen, weil der bgpd‑Daemon aus Versehen deaktiviert bleibt. Prüfe immer den Status mit systemctl status frr und vtysh -c "show version".

BGP‑Peer‑Konfiguration – Beispiel 1: Zwei Router verbinden

Nehmen wir an, du hast zwei physische Geräte im Homelab: router1 (192.168.1.1) und router2 (192.168.2.1). Beide laufen FRR und sollen eine eBGP‑Session über das interne Netzwerk aufbauen.

# Auf router1 – vtysh (interaktiver Modus)
vtysh
router> enable
router# configure terminal
router(config)# router bgp 65001
router(config-router)# neighbor 192.168.2.1 remote-as 65002
router(config-router)# neighbor 192.168.2.1 description "router2‑eBGP"
router(config-router)# exit
router(config)# exit
router# write memory
Enter fullscreen mode Exit fullscreen mode 
# Auf router2 – analog, AS‑Nummer 65002
vtysh
router> enable
router# configure terminal
router(config)# router bgp 65002
router(config-router)# neighbor 192.168.1.1 remote-as 65001
router(config-router)# neighbor 192.168.1.1 description "router1‑eBGP"
router(config-router)# exit
router(config)# exit
router# write memory
Enter fullscreen mode Exit fullscreen mode

Nachdem du die Konfiguration gespeichert hast, prüfst du die Session‑Status:

router# show ip bgp summary
Enter fullscreen mode Exit fullscreen mode

Du solltest eine ESTABLISHED‑Zeile sehen.

Persönliche Einschätzung: In meinem ersten Versuch hat das falsche Subnetz (z. B. 10.0.0.0/24 statt 192.168.x.x) die Session blockiert. Achte darauf, dass beide Interfaces im gleichen Layer‑2‑Segment liegen und keine ACLs die TCP‑Port 179 blockieren.

Route‑Policy und Präfixlisten – Beispiel 2: Selective Export

Ein Hauptvorteil von BGP ist die Fähigkeit, Präfixlisten und Route‑Maps zu nutzen, um exakt zu definieren, welche Netzwerke du nach außen (oder innen) exportierst. Angenommen, du willst nur das interne 10.0.0.0/24‑Netz von router1 zu router2 propagieren.

# Auf router1 – Präfixliste erstellen
vtysh -c "configure terminal" \
 -c "ip prefix-list INTERNAL permit 10.0.0.0/24" \
 -c "route-map EXPORT-INTERNAL permit 10" \
 -c "match ip address prefix-list INTERNAL" \
 -c "exit" \
 -c "router bgp 65001" \
 -c "neighbor 192.168.2.1 route-map EXPORT-INTERNAL out" \
 -c "exit" \
 -c "write memory"
Enter fullscreen mode Exit fullscreen mode

Damit wird nur das 10.0.0.0/24‑Netz an den Peer gesendet. Auf router2 kannst du das prüfen:

router# show ip bgp
Enter fullscreen mode Exit fullscreen mode

Persönliche Einschätzung: Ohne diese Filter hast du schnell das Routing‑Table‑Explosion‑Problem, besonders wenn du mehrere Netzwerke simulierst. Die konsequente Nutzung von Präfixlisten bewahrt das System vor ungewolltem Overhead.

Monitoring und Fehlersuche – Beispiel 3: Real‑Time Debugging

Selbst im kleinen Lab werden Fehler sichtbar – z. B. ein fehlender BGP‑Update. FRR liefert mächtige Debug‑Tools.

# Aktivieren des BGP‑Debug‑Levels
vtysh -c "debug bgp events" -c "debug bgp updates"
Enter fullscreen mode Exit fullscreen mode

Du kannst die Live‑Logs mit tcpdump auf Port 179 beobachten:

sudo tcpdump -i eth0 -nn -vvv tcp port 179
Enter fullscreen mode Exit fullscreen mode

Ein weiteres hilfreiches Kommando ist show ip bgp neighbors <IP> advertised-routes, das exakt anzeigt, welche Routen du an einen Peer gesendet hast.

Persönliche Einschätzung: Das unmittelbare Anzeigen von BGP‑Updates spart Stunden an Rätselraten. In meinem letzten Projekt habe ich einen fehlenden network‑Befehl entdeckt, weil der Log‑Eintrag „update not sent – no matching route“ gezeigt hat.

Häufige Fehler beim BGP‑Setup im Homelab

  1. Falscher AS‑Nummer‑Typ – Viele Heimrouter simulieren private AS‑Nummern (64512‑65534). Wenn du mit einem echten ISP testest, musst du eine öffentlich zugewiesene Nummer nutzen oder 4‑Byte‑ASNs korrekt konfigurieren.
  2. MTU‑Mismatches – BGP nutzt TCP. Ein 1500‑Byte‑MTU‑Mismatch zwischen Interfaces führt zu „segment reassembly timeout“ und bricht die Session.
  3. Fehlende network‑Anweisungen – Nur weil du ein Interface hast, heißt das nicht, dass das Netzwerk automatisch in BGP sichtbar wird. Du musst network 10.0.0.0/24 oder eine passende Route‑Map deklarieren.
  4. Firewall‑Regeln – Port 179 muss in beiden Richtungen offen sein. In manchen Home‑Routern blockiert das Standard‑LAN‑Firewall‑Modul BGP‑Pakete.
  5. Loop‑Prevention ignorieren – Ohne bgp router-id oder bgp deterministic-med können sich ungewollte Loops einschleichen, sobald du mehr als zwei Peer‑Verbindungen hast.

Fazit und nächste Schritte – Dein BGP‑Lab ist bereit für den nächsten Level

Du hast nun einen funktionierenden BGP‑Daemon, Peer‑Sessions, Policy‑Kontrolle und ein Monitoring‑Setup. Der wahre Wert eines Homelabs liegt jedoch nicht nur im Funken‑Erfolg, sondern im kontinuierlichen Ausbau:

  1. Multi‑Homing – Schließe ein zweites ISP‑Kabel an und definiere Präferenz‑Routen (local-preference).
  2. BGP‑Multipath – Aktiviere bgp bestpath as-path ignore und teste Load‑Balancing über mehrere Pfade.
  3. Route‑Reflector – Simuliere ein größeres Netzwerk, indem du einen Router als RR einsetzt.
  4. Automation – Exportiere die FRR‑Konfiguration nach Ansible oder Terraform, um reproduzierbare Deployments zu ermöglichen.
  5. Observability – Integriere Prometheus‑Exporter (frr_exporter) und Grafana‑Dashboards, um BGP‑Metriken live zu visualisieren.

Persönlicher Aufruf: Warte nicht, bis du ein komplettes Rechenzentrum verwaltest. Starte heute mit einem einzelnen Laptop, zwei Ethernet‑Kabeln und FRR – das ist alles, was du brauchst, um das Herz des Internets in deinem Wohnzimmer zu fühlen.

Top comments (0)