BGP einfach erklärt – Routing, AS-Nummern und Communities

Das Border Gateway Protocol (BGP) ist das Protokoll, mit dem das Internet seine Routen austauscht. Auch in Unternehmensnetzen gewinnt BGP an Bedeutung, zum Beispiel bei Multi-Homing, Cloud-Anbindungen oder SD-WAN. Wenn du die Grundbegriffe kennst, wirkt BGP schnell logisch und beherrschbar.

In diesem Leitfaden bekommst du einen klaren Überblick: Was macht BGP, wie funktionieren AS-Nummern (ASN), wie wählt BGP Pfade, wofür sind Communities gut und wie sieht eine Basis-Konfiguration aus. Alles in einfacher Sprache, damit du sofort mitreden und die ersten Setups einschätzen kannst.

Was BGP ist – und wofür du es nutzt

BGP tauscht IP-Präfixe zwischen Autonomen Systemen (AS) aus. Ein AS ist eine Sammlung von Netzen unter gemeinsamer Routing-Policy. BGP ist pfadvektorbasiert: Zu jedem Präfix trägt es Attributwerte mit, aus denen der beste Pfad gewählt wird. So steuerst du, welche Upstream-Verbindung bevorzugt wird, wie Failover funktioniert und wie eingehender Traffic verteilt wird.

Die Bausteine: Präfixe, ASN, Peers

• Präfixe: Netzangaben wie 203.0.113.0/24 oder 2001:db8::/32.
• ASN: AS-Nummern identifizieren Netze. Private ASN sind z. B. 64512-65534 (16-bit) und 4200000000-4294967294 (32-bit).
• Peers: BGP-Nachbarn, mit denen du Routen austauschst. Es gibt eBGP zwischen ASen und iBGP innerhalb eines AS.

iBGP vs eBGP – wo der Unterschied zählt

eBGP verbindet verschiedene AS. Standardmäßig ändert es den TTL auf 1 und setzt AS-Pfade. iBGP verbindet Router im selben AS. Wichtige Regel: iBGP verteilt keine Routen, die es von iBGP gelernt hat, an andere iBGP-Nachbarn weiter. Darum nutzt man Route Reflectors oder Full Mesh, damit alle iBGP-Router alle Präfixe sehen.

Route Reflector in einem Satz

Ein Route Reflector (RR) nimmt iBGP-Routen von Clients an und verteilt sie an andere Clients weiter. So sparst du ein Full Mesh und hältst die Kontroll-Ebene schlank.

Wie BGP Pfade auswählt – die vereinfachte Reihenfolge

BGP wählt den besten Pfad anhand von Attributen. Vereinfacht und praxisnah:

1. Weight – nur auf Cisco lokal, höher ist besser.
2. Local Preference (LOCAL_PREF) – AS-weit, steuert ausgehenden Traffic. Höher ist besser.
3. AS-Path-Länge – weniger Hops ist besser.
4. Origin – IGP vor EGP vor Incomplete.
5. MED – beeinflusst eingehenden Traffic zwischen denselben Nachbarn, kleiner ist besser.
6. eBGP bevorzugt vor iBGP.
7. IGP-Metrik zum Next-Hop – kürzer ist besser.
8. Router-ID als Tie-Breaker.

Merke: Für ausgehenden Traffic nutzt du Local Preference. Für eingehenden Traffic wirken AS-Path Prepending, MED und BGP Communities bei deinen Upstreams.

BGP Communities – Metadaten, die Routing steuern

Communities sind Tags an Routen. Sie erlauben Policies, ohne jede einzelne Route anfassen zu müssen.

Typische Einsatzfälle

• Traffic Engineering: Mit einer vom Provider dokumentierten Community erhöhst du Local Preference im Upstream oder setzt No-Export.
• Blackholing: Spezielle Blackhole-Communities signalisieren, dass ein Präfix auf Null geleitet wird, um DDoS zu entschärfen.
• No-Export / No-Advertise: Well-known Communities wie no-export verhindern, dass Routen über eBGP weitergegeben werden.

Beispielnotation: 65000:100 ist eine Standard-Community, Extended Communities tragen z. B. Bandbreiten- oder Pfadinfos.

Einfache BGP-Konfiguration – beispielhaft gedacht

Beispiel mit einem Upstream und iBGP über Route Reflector. Syntax angelehnt an gängige Router-CLIs.

# eBGP zum Provider
router bgp 65000
  neighbor 198.51.100.1 remote-as 64500
  neighbor 198.51.100.1 description Uplink-1
  address-family ipv4 unicast
    network 203.0.113.0 mask 255.255.255.0
    neighbor 198.51.100.1 route-map OUTBOUND out
    neighbor 198.51.100.1 maximum-prefix 500 90 restart 5

# iBGP mit Route Reflector
  neighbor 10.0.0.10 remote-as 65000
  neighbor 10.0.0.10 update-source Loopback0
  neighbor 10.0.0.10 route-reflector-client

# Policy: ausgehend hohe LocalPref für Uplink-1
route-map OUTBOUND permit 10
  set local-preference 200
  set community 65000:100 additive

Wichtig: Setze maximum-prefix, damit Fehlkonfigurationen deinen Uplink nicht überfluten. Nutze Prefix-Listen und Route-Maps, um nur gewünschte Netze zu bewerben und eingehende Routen zu filtern.

Stabilität und Sicherheit – das darfst du nie weglassen

• Prefix-Filter: Erlaube nur die eigenen Präfixe als Outbound-Ankündigung.
• Ingress-Filter: Akzeptiere keine zu spezifischen Netze von außen, und nie private oder martian Präfixe.
• RPKI Origin Validation: Prüfe, ob ein Präfix laut ROA von diesem ASN stammen darf. Ungültige Routen ablehnen oder herabstufen.
• GTSM TTL-Security: Setze TTL hoch und prüfe, um Off-Path Angriffe zu erschweren.
• MD5 für BGP-Sessions: Sichere die Nachbarschaft mit einem Passwort.
• Logging und Max-Prefix: Alarmiere bei Policy-Verstößen und Routenfluten.

Troubleshooting – schnell zur Ursache

• show bgp summary oder show ip bgp summary: Ist die Session up und wie viele Präfixe kommen an
• show bgp neighbors: Timers, Capabilities, Received Prefixes
• show bgp <prefix>: Wer gewinnt laut Attributen und warum
• Prüfe Next-Hop-Reachability mit Ping/Traceroute – ohne Erreichbarkeit fällt der Best Path raus

Mini-Fahrplan für dein erstes BGP

1. Ziele definieren: Ausfallsicherheit, Lastverteilung, eingehender Traffic steuern.
2. Adressraum klären: Eigene Präfixe und ASN oder Provider-aggregiert.
3. Policies aufschreiben: Welche Präfixe raus, welche rein, Local Pref, Communities.
4. Filter und Schutz bauen: Prefix-Listen, RPKI, Max-Prefix, MD5.
5. Testen: Erst im Lab, dann stufenweise in der Produktion.

Fazit

BGP wirkt komplex, besteht aber aus wenigen Bausteinen: ASNs, Präfixe, Peers und Attribute für die Pfadwahl. Mit Local Preference, AS-Path und Communities steuerst du den Traffic verlässlich. Wenn du von Anfang an Filter, RPKI, Max-Prefix und Session-Schutz einplanst, bekommst du ein stabiles und vorhersehbares Routing, das zu deinen Zielen passt.