BGP ist kein schneller Ersatz für OSPF und auch kein Allzweck-Routing für jedes Homelab. Das Protokoll spielt
seine Stärken dort aus, wo Policy wichtiger ist als reine Metrik: mehrere Uplinks, getrennte
autonome Systeme, EVPN-Fabrics oder kontrollierte Routenweitergabe zwischen Standorten und Providern.
Für ein einzelnes Heimnetz mit einem Router ist BGP meist überdimensioniert. Sinnvoll wird es, wenn man
absichtlich mit mehreren Routing-Domänen arbeitet, etwa in einem Lab für Provider- oder Rechenzentrumsdesign,
bei redundanten Edge-Routern oder in VXLAN/EVPN-Szenarien mit FRRouting.
Weniger sinnvoll: simples Inter-VLAN-Routing, kleine Single-Site-Netze ohne Policy-Bedarf.
Wichtig: Stabilität entsteht bei BGP vor allem durch gute Filter und klare Betriebsregeln.
2. Kernkonzepte von BGP
BGP ist ein Path-Vector-Protokoll. Es entscheidet nicht primär anhand einer Linkkosten-Metrik,
sondern anhand von Attributen und Richtlinien. Die wichtigsten Grundlagen sollte man sauber auseinanderhalten:
AS (Autonomous System): logische Verwaltungsdomäne mit eigener AS-Nummer.
eBGP: Session zwischen unterschiedlichen AS, typischerweise Edge zu Provider oder Partner.
iBGP: Session innerhalb desselben AS, um gelernte Routen intern zu verteilen.
NLRI: das eigentliche Präfix, das angekündigt wird, zum Beispiel 10.10.10.0/24.
AS_PATH: Liste der AS entlang des Pfads; wichtig für Schleifenvermeidung und Policy.
LOCAL_PREF: internes Attribut, mit dem man bevorzugte Ausgänge innerhalb des eigenen AS steuert.
MED: Hinweis an Nachbar-AS, welchen Eintrittspfad man bevorzugt.
COMMUNITIES: Tags für wiederverwendbare Policy-Entscheidungen.
Häufigster Denkfehler: BGP lernt nicht automatisch "den besten technischen Pfad". Es setzt exakt das um, was
Attribute und Policies vorgeben. Deshalb müssen Prefix-Filter, Communities und Defaults vor dem ersten
produktiven Einsatz stehen.
3. Kleines FRR-Lab als Ausgangspunkt
Für den Einstieg reicht ein minimales Zwei-AS-Lab. Router A repräsentiert das eigene Netz
(AS 65001), Router B einen Upstream oder Partner (AS 65002). Beide Systeme laufen
unter Debian oder Ubuntu mit FRRouting.
AS 65001 AS 65002
10.10.10.0/24 10.20.20.0/24
host-a --- rtr-a ===== rtr-b --- host-b
192.0.2.1 192.0.2.2
Ziele für das erste Lab:
eigene Netze per network-Statement ankündigen,
nur definierte Präfixe vom Nachbarn akzeptieren,
Auswirkung von LOCAL_PREF und AS_PATH nachvollziehen,
Show-Befehle und Logs lesen, bevor weitere Komplexität dazukommt.
4. Grundkonfiguration mit FRR
Unter Debian installiert man FRR aus dem Paketmanager. Anschließend werden die benötigten Daemons aktiviert,
typischerweise mindestens zebra und bgpd.
Für produktive Umgebungen sollte man no bgp ebgp-requires-policy gerade nicht
dauerhaft verwenden. Im Lab hilft es beim Einstieg, im Betrieb ist die restriktive Default-Haltung sinnvoll,
damit keine ungefilterten Routen akzeptiert oder exportiert werden.
5. Policies, Filter und Sicherheit
Der wichtigste Betriebsgrundsatz lautet: keine BGP-Session ohne Inbound- und Outbound-Filter.
Schon kleine Labore profitieren davon, weil man damit Fehlerbilder früh lernt, die später im Produktivnetz
kritisch werden.
5.1 Prefix-Filter und Route-Maps
ip prefix-list PL-IN seq 10 permit 10.20.20.0/24
ip prefix-list PL-OUT seq 10 permit 10.10.10.0/24
route-map RM-IN permit 10
match ip address prefix-list PL-IN
set local-preference 200
route-map RM-OUT permit 10
match ip address prefix-list PL-OUT
router bgp 65001
address-family ipv4 unicast
neighbor 192.0.2.2 prefix-list PL-IN in
neighbor 192.0.2.2 route-map RM-IN in
neighbor 192.0.2.2 prefix-list PL-OUT out
exit-address-family
5.2 Sicherheitsmaßnahmen
MD5-Passwort: schützt die TCP-Session vor einfachen Störungen und Fehlpeering.
TTL-Security: sinnvoll bei direkt benachbarten eBGP-Peers.
Maximum-Prefix: begrenzt Schaden bei Route-Leaks oder Fehlkonfigurationen.
BFD: für schnellere Fehlererkennung, wenn die Plattform und der Einsatzzweck es rechtfertigen.
Dokumentierte Communities: spart später sehr viel Zeit in Betrieb und Automatisierung.
In echten Internet- oder Provider-Szenarien gehören zusätzlich RPKI-Validierung, saubere IRR/RPKI-Prozesse
und explizite Export-Regeln auf die Pflichtliste. Im Homelab reicht oft schon die Disziplin, nur eigene
Testpräfixe zu verwenden und niemals ungeprüft Default-Routen oder fremde Netze weiterzuverteilen.
6. Betrieb, Monitoring und Skalierung
Sobald mehr als zwei oder drei Router beteiligt sind, wird iBGP-Design relevant. Ein Vollmesh ist funktional,
skaliert aber schlecht. Dann kommen Route Reflectors oder klare Rollenmodelle ins Spiel.
Kleines Lab: direkter iBGP-Vollmesh meist ausreichend.
Mehrere Edge-Router: LOCAL_PREF konsistent halten und Failover-Logik explizit dokumentieren.
EVPN-Fabrics: BGP wird häufig zur Control Plane, nicht nur für klassische Prefixe.
Monitoring: Session-Status, Prefix-Anzahl, Flaps und Policy-Abweichungen beobachten.
Sinnvolle Betriebskennzahlen sind:
Anzahl empfangener und exportierter Präfixe pro Peer,
Session-Uptime und Flap-Häufigkeit,
Änderungen an Communities und Route-Maps,
Abweichungen zwischen Soll-Prefixen und tatsächlich angekündigten Netzen.
7. Troubleshooting
BGP-Störungen lassen sich meist auf vier Gruppen zurückführen: Session kommt nicht hoch, Route wird nicht
akzeptiert, Route wird nicht exportiert oder der "falsche" Pfad wird gewählt. Eine feste Prüfreihenfolge hilft:
TCP-Erreichbarkeit zu Port 179 und Nachbar-IP prüfen.
show bgp summary
show bgp ipv4 unicast
show bgp ipv4 unicast neighbors 192.0.2.2 advertised-routes
show bgp ipv4 unicast neighbors 192.0.2.2 received-routes
show ip route 10.20.20.0/24
show run
Typische Fehlerbilder:
Idle / Active: IP-Konnektivität, ACLs, Passwort oder AS-Nummer falsch.
Route fehlt trotz Session: Prefix-Filter oder network-Statement passt nicht.
NEXT_HOP unerreichbar: häufig bei iBGP ohne next-hop-self.
Unerwarteter Best Path: LOCAL_PREF, Weight, AS_PATH oder MED wirken anders als gedacht.
8. Zusammenfassung
BGP lohnt sich, wenn Routing-Entscheidungen absichtlich über Regeln statt über reine Linkkosten gesteuert
werden sollen. Für FRR ist der Einstieg technisch einfach, aber betriebliche Disziplin bleibt der entscheidende
Faktor: restriktive Filter, dokumentierte Policies, saubere Show-Befehle und kleine, reproduzierbare Labs.
Wer BGP wirklich verstehen will, sollte nicht mit riesigen Konfigurationen starten, sondern mit einem kleinen
eBGP-Lab, Prefix-Filtern und klaren Tests. Erst danach lohnen sich Communities, Route Reflectors oder EVPN.