DEV Community

Uhltak Therestismysecret
Uhltak Therestismysecret

Posted on

BGP im Homelab: FRRouting einrichten und fortgeschrittene Szenarien meistern

#bgp #frrouting #homelab #netzwerk

BGP im Homelab: FRRouting einrichten und fortgeschrittene Szenarien meistern

Hook – Warum BGP im eigenen Keller ein Game‑Changer ist

Stell dir vor, du baust ein kleines Netzwerk‑Lab wie ein Architekt sein Modellhaus. Du willst nicht nur ein Netzkabel verlegen, sondern auch lernen, wie das Internet‑Rückgrat funktioniert. Genau hier kommt BGP ins Spiel. Viele denken, BGP sei nur für ISPs und Cloud‑Provider – ein Mythos, den ich seit über zehn Jahren immer wieder zerbreche. Wenn du FRRouting (FRR) im Homelab einsetzt, bekommst du die gleichen Werkzeuge wie ein Operator bei Deutsche Telekom, nur ohne teure Verträge. In diesem Beitrag zeige ich dir Schritt für Schritt, wie du BGP auf Debian‑basierten VMs aufsetzt, komplexe Topologien modellierst und typische Stolperfallen umgehst.

1. Grundlagen von BGP und warum FRRouting im Homelab

BGP (Border Gateway Protocol) ist das „Routing‑Protokoll des Internets“. Es tauscht Reachability‑Information zwischen autonomen Systemen (AS) aus und ermöglicht Policy‑basiertes Routing. In einer privaten Umgebung nutzt du BGP, um mehrere Router‑Instanzen zu verbinden, unterschiedliche Pfade zu simulieren und Lerninhalte ohne Produktionsdruck zu testen.

Beispiel 1 – Warum ein eigenständiger Router‑Daemon sinnvoll ist

# Auf einer normalen Linux‑Box laufen nur Quell‑Routing‑Tools (ip route)
# FRR bringt einen vollwertigen BGP‑Daemon, der OSPF, IS‑IS und mehr kennt.
# Das bedeutet: du kannst in einer VM mehrere BGP‑Nachbarn simulieren.
Enter fullscreen mode Exit fullscreen mode

Persönliche Einschätzung: Ich habe in den ersten fünf Jahren meiner Karriere ausschließlich Cisco‑CLI benutzt. Der Moment, als ich FRR auf einem Ubuntu‑Container laufen ließ, war wie der Sprung vom Skateboard zum Motorroller – plötzlich konnte ich komplexe Policies schreiben, ohne teure Lizenzen.

2. FRR installieren und Grundkonfiguration

FRR ist in den meisten Debian‑ und Ubuntu‑Repos enthalten. Für ein sauberes Homelab‑Setup installieren wir nur die BGP‑Komponente.

Beispiel 2 – Installation und Aktivierung

sudo apt update && sudo apt install frr frr-pythontools -y

# FRR verwendet die Datei /etc/frr/daemons, um Daemons zu aktivieren.
sudo sed -i 's/^bgpd=no/bgpd=yes/' /etc/frr/daemons
sudo systemctl restart frr
Enter fullscreen mode Exit fullscreen mode

Jetzt können wir über vtysh die CLI betreten:

sudo vtysh
BGP# show version
Enter fullscreen mode Exit fullscreen mode

Die Ausgabe bestätigt, dass der BGP‑Daemon aktiv ist.

Persönliche Einschätzung: Die Installation dauert nicht länger als ein Kaffee‑Kochvorgang. Der entscheidende Moment ist das Aktivieren des bgpd im Daemons‑File – ein einziger sed-Befehl, der die gesamte Grundlagenschicht freischaltet.

3. Aufbau einer einfachen Zwei‑Router‑Topologie

Eine Minimalumgebung besteht aus zwei VMs (Router A und Router B) mit jeweils einer vNIC im selben virtuellen Netzwerk. Wir verwenden netplan für die IP‑Zuweisung, FRR für das BGP‑Peering.

Router A – IP‑Konfiguration

# /etc/netplan/01‑eth0.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      addresses: [10.0.0.1/24]
      gateway4: 10.0.0.254
Enter fullscreen mode Exit fullscreen mode 
sudo netplan apply
Enter fullscreen mode Exit fullscreen mode

Router A – BGP‑Konfiguration

# /etc/frr/frr.conf (A)
router bgp 65001
  neighbor 10.0.0.2 remote-as 65002
  network 192.168.10.0/24
!
log syslog informational
Enter fullscreen mode Exit fullscreen mode

Router B – BGP‑Konfiguration (ausgelassen) – analog, AS 65002, Netzwerk 192.168.20.0/24

Nach dem Neustart:

vtysh -c "show ip bgp summary"
Enter fullscreen mode Exit fullscreen mode

Du solltest einen Established‑Status sehen und die Anzahl der ausgetauschten Prefixes (zwei in diesem Beispiel).

Persönliche Einschätzung: Sobald das Peer‑Verhältnis steht, fließt das Routing‑Buchstabiergerät wie ein Tanzpartner – das ist das süße Gefühl, das ich jedes Mal erlebe, wenn ich ein neues Lab‑Setup aufbaue.

4. Fortgeschrittene Szenarien: Route‑Reflectors, Communities und Policy‑Routing

Ein echtes Homelab‑BGP‑Projekt beinhaltet mehr als nur zwei Router. Wir erweitern das Beispiel zu einer drei‑Router‑Topologie: R1 (Route‑Reflector), R2 und R3. Ziel ist es, dass R2 und R3 keine direkte Peering‑Beziehung benötigen – ein typisches Muster in großen Netzwerken.

Beispiel 3 – Route‑Reflector‑Konfiguration auf R1

# /etc/frr/frr.conf (R1 – RR)
router bgp 65000
  bgp router-id 10.0.0.1
  neighbor 10.0.0.2 remote-as 65001
  neighbor 10.0.0.3 remote-as 65002
  neighbor 10.0.0.2 route-reflector-client
  neighbor 10.0.0.3 route-reflector-client
!
Enter fullscreen mode Exit fullscreen mode

Beispiel 4 – Communities auf R2

router bgp 65001
  neighbor 10.0.0.1 remote-as 65000
  neighbor 10.0.0.1 send-community both
  network 192.168.10.0/24 route-map SET_COMM
!
route-map SET_COMM permit 10
  set community 65000:100
Enter fullscreen mode Exit fullscreen mode

Damit propagiert R2 die Community 65000:100 automatisch über den RR zu R3.

Beispiel 5 – Policy‑Based Routing (PBR) auf R3

router bgp 65002
  neighbor 10.0.0.1 remote-as 65000
  network 192.168.20.0/24
!
route-map PBR_IN permit 10
  match community 65000:100
  set local-preference 200
!
bgp default local-preference 100
bgp listen range 10.0.0.0/24
ebgp-multipath
Enter fullscreen mode Exit fullscreen mode

Durch die erhöhte local-preference bevorzugt R3 den Pfad über R2, wenn beide Alternativen vorhanden sind.

Persönliche Einschätzung: Das Aufsetzen von Route‑Reflectors und Communities fühlt sich an wie das Anlegen von „Gruppenkarten“ in einem Kartenspiel – du definierst, wer welche Informationen sehen darf, und spielst damit gezielt strategisch.

5. Monitoring und Debugging: Tools und Befehle

Ein Lab ist nur so gut wie seine Sichtbarkeit. FRR bietet mehrere native Befehle, aber ergänzende Tools wie tcpdump, Wireshark und birdc (falls du Bird installierst) geben tiefe Einblicke.

Beispiel 6 – Echtzeit‑BGP‑Statistik

vtysh -c "show ip bgp summary" -c "show bgp neighbor 10.0.0.2" -c "show ip bgp"
Enter fullscreen mode Exit fullscreen mode

Beispiel 7 – Paket‑Capture für BGP (Port 179)

sudo tcpdump -i eth0 port 179 -vv -w bgp.pcap
Enter fullscreen mode Exit fullscreen mode

Durch das Öffnen der .pcap‑Datei in Wireshark kannst du die BGP‑Open‑Nachrichten, Update‑Nachrichten und Fehlermeldungen visuell inspizieren.

Beispiel 8 – Log‑Analyse

sudo journalctl -u frr -f | grep BGP
Enter fullscreen mode Exit fullscreen mode

Dieser Befehl liefert Echtzeit‑Logs, die bei Fehlkonfigurationen sofort Alarm schlagen.

Persönliche Einschätzung: Das Debuggen von BGP ist für mich vergleichbar mit dem Entwirren eines Kopfhörerkabels – es gibt immer ein erstes tcpdump‑Snippet, das das Problem sofort sichtbar macht.

6. Häufige Fehler im Homelab‑BGP

Fehler Ursache Korrektur
1. Forgetting to enable bgpd /etc/frr/daemons hat bgpd=no sed -i 's/^bgpd=no/bgpd=yes/' /etc/frr/daemons && systemctl restart frr
2. Mismatched Router‑ID Identische Router‑IDs führen zu BGP‑Flaps Setze eindeutige router-id (z. B. 10.0.0.1)
3. Missing send-community Communities werden nicht propagiert neighbor <IP> send-community both im BGP‑Kontext
4. Wrong remote-as Peer hat anderes AS definiert Prüfe show ip bgp neighbor und korrigiere das remote-as
5. Firewall‑Block Port 179 gesperrt sudo ufw allow 179/tcp oder iptables‑Rule einrichten

Vermeide diese Stolperfallen, sonst landest du schnell im „BGP‑Black‑Hole“. Die meisten Probleme lassen sich mit einem schnellen show ip bgp und einem Blick in das System‑Log beheben.

7. Fazit und konkreter nächster Schritt

BGP im Homelab kann zunächst einschüchternd wirken, ist aber mit FRR praktisch kostenlos und unglaublich flexibel. Du hast jetzt:

  1. FRR installiert und den BGP‑Daemon aktiviert.
  2. Ein einfaches Zwei‑Router‑Peering aufgebaut und getestet.
  3. Route‑Reflector, Communities und Policy‑Routing in einer dreier Topologie umgesetzt.
  4. Monitoring‑ und Debug‑Tools kennengelernt, um Probleme schnell zu finden.
  5. Typische Fehlerquellen identifiziert und korrigiert.

Nächster Schritt: Erstelle ein Lab‑Playbook mit Ansible, das deine FRR‑Konfiguration automatisiert. Beispiel‑Snippet für Ansible‑Task:

- name: Deploy FRR BGP config
  copy:
    dest: /etc/frr/frr.conf
    content: |
      router bgp {{ bgp_as }}
        neighbor {{ neighbor_ip }} remote-as {{ neighbor_as }}
        network {{ advertised_prefix }}
      log syslog informational
  notify: restart frr
Enter fullscreen mode Exit fullscreen mode

Damit kannst du deine BGP‑Topologie per Code versionieren – ein echter Schritt von „Lab‑Playground“ zu GitOps‑Network‑Automation.

Abschließende Empfehlung: Starte ein Mini‑ISP‑Projekt: Simuliere Kundennetzwerke, setze verschiedene MED‑ und Local‑Preference‑Werte und beobachte, wie deine Traffic‑Engineering‑Policies das Routing beeinflussen. Das ist das ultimative Lernfeld – und du bist dabei nicht mehr nur ein Beobachter, sondern der Architekt des eigenen Internets.

Top comments (0)