Border Gateway Protocol (BGP) ist das Rückgrat großer Unternehmensnetze und der Verbindung zu Providern. In diesem Beitrag zeige ich praxisnah, wie Sie BGP für Enterprise stabil betreiben: vom Aufbau sicherer Nachbarschaften über saubere Route‑Filter bis zu AS‑Path‑Policies. Ziel ist nicht nur eine funktionierende Konfiguration, sondern ein wiederholbarer Betrieb mit Prüfpfaden, Fehlersuche und Rückfallstrategie.
BGP‑Grundlagen und notwendige Voraussetzungen
BGP ist ein Pfadvektor‑Routingprotokoll. Kurz: Router tauschen Routen als Pfade aus, wobei jeder Pfad mit einer AS‑Sequence (AS‑Pfad) markiert wird. In Unternehmen brauchen Sie oft zwei BGP‑Szenarien: eBGP (externes Peering mit anderen Autonomous Systems, AS) und iBGP (internes Peering innerhalb Ihres AS). Bevor Sie starten, prüfen Sie:
- AS‑Nummern und Adresspläne: Haben Sie eine öffentliche AS‑Nummer oder nutzen Sie eine private AS‑Nummer (nur innerhalb MPLS/VPN)?
- IP‑Pläne/Loopbacks für Peering: Verwenden Sie /31 oder /30 point‑to‑point Netze oder Loopbacks plus multihop bei iBGP?
- Firewall‑ und ACL‑Regeln: TCP Port 179 muss zwischen Peers durchgelassen werden; bei stateful Firewalls sind Ausnahmen nötig.
- Operationaler Zugang: Zugang zu Console/SSH, Monitoring (SNMP/Telemetry) und Logging sind bereitgestellt.
Ohne diese Voraussetzungen sind Troubleshooting und Rollback deutlich schwieriger.
BGP für Enterprise: Nachbarschaften sicher aufbauen
„Nachbarschaft“ (Neighbor/Peer) bezeichnet eine BGP‑Verbindung zwischen zwei Router‑Instanzen. Wichtige Aspekte:
eBGP vs. iBGP: Unterschiede, Praxisregeln
eBGP peers queren AS‑Grenzen; TTL für eBGP ist standardmäßig 1. iBGP peers sind innerhalb des gleichen AS und haben spezielle Regeln: iBGP verteilt nur solche Routen, die es selbst über eBGP gelernt hat oder von einem Route‑Reflector weitergeleitet werden. Typische Praxis:
- Nutzen Sie eBGP für Provider‑Peering und iBGP innerhalb Ihres AS (bei größeren Installationen Route‑Reflector einsetzen).
- Für iBGP mit Loopbacks aktivieren Sie multihop oder nutzen Sie direkte Links in einem L2‑Backbone.
Authentifizierung, TTL‑Security und BFD
Sicherheit und Stabilität sind zentral. TCP‑MD5 oder TCP‑AUTH (bei neueren Plattformen) schützt vor Spoofing der BGP‑Session. TTL‑Security (ebgp‑multihop oder ip ttl‑security) reduziert Risiko durch IP‑Spoofing zwischen benachbarten Geräten, und BFD (Bidirectional Forwarding Detection) bietet schnelle Erkennung von Linkausfällen.
Beispiel: TCP‑MD5 auf Cisco IOS (plattformabhängig beachten):
router bgp 65000
neighbor 203.0.113.2 remote-as 65001
neighbor 203.0.113.2 password 0 geheimesPasswort
!Warum es funktioniert: Der TCP‑MD5‑Hash bindet die Session an ein gemeinsames Geheimnis, sodass Pakete ohne korrekten Hash verworfen werden. Wann es scheitert: Bei unterschiedlichen Hashes, MTU‑Inkonsistenzen oder wenn Zwischenfirewalls TCP‑MD5 Pakete beeinflussen.
Praktische Checkliste für neue Peers
- Ping auf Peer‑IP (oder auf Loopback wenn iBGP multihop): IPv4/IPv6 überprüfen.
- TCP Connectivity prüfen: telnet peer 179 oder nc -vz peer 179.
- Konfiguration synchronisieren: AS‑Nummer, remote‑as, password, update‑source (bei multihop Loopback).
- Enable BFD, falls verfügbar, und testen Sie das Abbau‑/Wiederaufbauverhalten.
- Setzen Sie max‑prefix, damit Fehlkonfigurationen Ihr Control Plane nicht überschwemmen.
Route‑Filter: Schutz vor fehlerhaften oder ungewollten Routen
Route‑Filter regeln, welche Routen Sie annehmen, weitergeben oder verändern. Wichtige Konstrukte: Prefix‑Lists/Route‑Filters (beschreiben Präfixe), AS‑Path‑Access‑Lists (filtern nach AS‑Sequenzen), Communities (Metadaten), und Route‑Maps/Policy‑Statements (kombinieren Match und Set‑Operationen).
Warum Filter wichtig sind
Ungefiltertes BGP kann zu Routing‑Leaks führen, z. B. mit globalen Präfixen, die fälschlich ins Internet verteilt werden. Filter begrenzen den Schaden, schützen vor falschen Next‑Hops und verhindern, dass fremde Routen Ihr internes Netz dominieren.
Konkrete Filtermuster
Empfohlener Aufbau am Provider‑Peering:
- Inbound: Accept only your prefixes (prefix‑list mit Ihren IPs) und AS‑Path‑Filter, die Provider‑ASes oder Customer‑ASes akzeptieren.
- Outbound: Nur die Präfixe, die Sie tatsächlich ankündigen wollen — keine Aggregate ohne Absprache.
- max‑prefix: Schützt vor Ankündigungen von zu vielen Routen; bei Überschreiten: Session drosseln oder resetten.
Beispiel: Prefix‑List und Route‑Map in Cisco‑Style:
ip prefix-list MY_PREFIXES seq 5 permit 198.51.100.0/24
ip prefix-list MY_PREFIXES seq 10 permit 203.0.113.0/24
!
route-map OUT-TO-ISP permit 10
match ip address prefix-list MY_PREFIXES
set community 65000:100 additive
!
router bgp 65000
neighbor 198.51.100.1 remote-as 65010
neighbor 198.51.100.1 route-map OUT-TO-ISP out
neighbor 198.51.100.1 maximum-prefix 50
!Erklärung: Die Prefix‑List begrenzt, was Sie ankündigen. Die Route‑Map setzt Communities, die Provider für Transit‑Policies nutzen können. max‑prefix schützt vor versehentlicher Flut.
RPKI und ROA als zusätzliche Validierung
Resource Public Key Infrastructure (RPKI) prüft, ob eine AS berechtigt ist, ein Präfix anzukündigen. RPKI‑Integration in Ihre Routing‑Policy reduziert Risiko von Hijacks. Betriebsaspekt: Halten Sie Ihre ROAs aktuell, denn ein falsch gesetzter ROA kann legitime Routen ungewollt als invalid kennzeichnen und damit verwerfen.
AS‑Path‑Policies praktisch anwenden
AS‑Path‑Policies beeinflussen, wie Routen ausgewählt oder weiterverbreitet werden. Zwei Hauptanwendungsfälle: Präferenzsteuerung (z. B. Prepend für Traffic Engineering) und Schutz (z. B. AS‑Path‑Filter gegen bestimmte AS‑Sequences).
AS‑Path‑Filter und Access‑Lists
AS‑Path‑Filter verwenden reguläre Ausdrücke auf der AS‑Sequenz. Beispiel: Verwerfen von Routen, die ein bestimmtes AS in der Sequence enthalten:
ip as-path access-list 10 deny _65530_
ip as-path access-list 10 permit .*
!
route-map IN-FILTER permit 10
match as-path 10
!Erklärung: _65530_ (Unterstriche als Wortgrenzen) erkennt AS 65530 in der Route. Diese Technik verhindert, dass Routen durch bekannte problematische ASes laufen.
AS‑Prepending für Traffic Engineering
Durch mehrfaches Einfügen der eigenen AS in den AS‑Pfad (Prepend) machen Sie eine Route für entfernte ASes weniger attraktiv. Das ist nützlich, wenn Sie über mehrere Provider unterschiedliche Präferenzen für ausgehenden Traffic erzwingen wollen.
route-map PREPEND-TO-ISP permit 10
set as-path prepend 65000 65000 65000
!
neighbor 198.51.100.1 route-map PREPEND-TO-ISP out
Vorsicht: Übermäßiges Prepending kann unerwartete Pfade erzeugen und Troubleshooting erschweren. Testen Sie schrittweise und dokumentieren Sie Änderungen.
Firewall‑Aspekte und BGP: Praxis, Troubleshooting, Best Practices
BGP ist auf der Control Plane aktiv; Firewalls aber operieren oft in der Data‑Plane. Stellen Sie sicher, dass Firewalls weder BGP‑TCP (Port 179) noch BFD‑Pakete ungewollt filtern. Bei stateful Firewalls müssen eingehende BGP‑Verbindungen als ‚established‘ erkannt werden. Außerdem: Conntrack‑State‑Limits und Timeouts können unerwartet Sessions abbrechen.
Konkrete Firewall‑Regeln (nftables Beispiel)
Wenn Sie Linux‑Border‑Router mit nftables betreiben, hier ein Mindestsatz — inklusive Loopback‑Multihop‑Zulassung:
table inet filter {
chain input {
type filter hook input priority 0;
ct state established,related accept
# Erlaube BGP-Neuaufbau (Port 179)
tcp dport 179 ct state new accept
# Falls iBGP über Loopbacks multihop läuft: quell- und ziel-ip explizit erlauben
ip saddr 10.0.0.0/24 ip daddr 10.0.0.1 tcp dport 179 accept
# BFD (UDP 3784/3785) für schnelle Link-Detektion
udp dport {3784,3785} ct state new accept
icmp type echo-request accept
drop
}
}
Erklärung: Die Regel ct state established,related schützt gegen unnötige Blockierungen bestehender Verbindungen. Spezielle Regeln für Loopback‑IPs sind nötig, wenn Multihop genutzt wird — sonst werden neu aufgebaute Sessions geblockt.
Conntrack und Timeouts
Stateful Firewalls verwenden Conntrack‑Timeouts. BGP‑Keepalives sind selten sehr häufig, aber wenn ein Firewall‑Timeout kürzer ist als Ihr Keepalive/hold‑Timer, wird die Session unnötig abgebaut. Prüfen und setzen Sie Conntrack‑Timeous passend:
# Conntrack-Timeouts prüfen (Linux)
cat /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established
Passen Sie ggf. an, oder erstellen Sie explizite stateless Regeln nur für BGP‑Peers, um Conntrack zu umgehen.
Prüf‑ und Troubleshooting‑Schritte
Ein strukturiertes Troubleshooting vermeidet kostspielige Fehler. Folgen Sie dieser erweiterten Prüfsequenz, die datengetriebene Diagnosen ermöglicht:
- Physische und L2‑Verbindung prüfen: Link‑Status, SFPs, Duplex/Mismatch, Fehlerzähler.
- IP‑Konnektivität: Ping und traceroute zu Peer‑IP und Loopbacks; prüfen Sie asymmetrische Pfade.
- TCP‑Handshakes: telnet/nc zu Port 179 prüfen und bei Bedarf tcpdump‑Capture zur Analyse anfertigen.
- Router‑Logs und BGP‑Show‑Befehle auswerten (BGP‑Summary, Neighbor‑Detail, RIB‑Status).
- ACLs/Firewalls prüfen: Logs auf verwehrte Verbindungen oder NAT/Rewrites durchsuchen.
- Wenn Session instabil: MD5/Passwort, MTU, BFD‑Timers, CPU‑Load, Interrupt‑Queues prüfen.
Packet‑Capture ist in vielen Fällen entscheidend. Beispiel für tcpdump auf einem Linux‑Bordergerät:
# BGP-Traffic aufzeichnen (inkl. Keepalives und Open-Pakete)
tcpdump -i eth0 -s 0 tcp port 179 -w /tmp/bgp-179.pcap
# Live-Ausgabe für schnelle Prüfung
tcpdump -i eth0 -n -vvv tcp port 179
Interpretation: In einem Capture sehen Sie Open‑/Keepalive‑/Update‑Pakete. Open‑Fehler deuten häufig auf Auth/Version/Capability‑Mismatch, Update‑Anomalien auf Filter‑Probleme.
Wichtige Router‑Befehle
# Cisco IOS
show ip bgp summary
show ip bgp neighbors 203.0.113.2
show ip bgp regexp _65530_
show logging | include BGP
# Junos
show bgp summary
show bgp neighbor 203.0.113.2 detail
show route protocol bgp
show log messages | match bgp
Diese Befehle geben State, empfangene/gesendete Prefix‑Counts, Timer und Fehlerursachen aus. Bei Flaps prüfen Sie Interface/CPU/MTU‑Fehler; bei fehlenden Routen prüfen Sie Filter, next‑hop Erreichbarkeit und RPKI‑Status.
Automatisierung, Backup und kontrollierte Änderungen
Änderungen an BGP müssen reproduzierbar und rückgängig machbar sein. Versionieren Sie Konfigurationen, automatisieren Sie Backups und führen Sie Änderungen per Orchestrierung durch. Beispiel: Ansible‑Playbook‑Snippet, das eine running config sichert (vereinfachtes Beispiel):
- name: Backup Router Config
hosts: routers
gather_facts: no
tasks:
- name: Fetch running-config
ios_command:
commands: show running-config
register: running_cfg
- name: Save to file
copy:
content: "{{ running_cfg.stdout[0] }}"
dest: "/var/backups/router-{{ inventory_hostname }}-{{ ansible_date_time.date }}.cfg"
Warum das hilft: Versionierte Backups beschleunigen Rollbacks und Audits. In Kombination mit CI/CD‑Pipelines können Sie Konfigurationsprüfungen (linting) vor dem Rollout einfügen.
Change‑Management, Canary‑Rollouts und Rückfallstrategien
Für risikoreiche Änderungen nutzen Sie Canary‑Rollouts: Erst ein einzelner Peer oder ein nicht‑kritischer POP, beobachten, dann stufenweise erweitern. Definieren Sie klare Abbruchkriterien (z. B. erhöhter Prefix‑Anzahl, Flaps, Latenz). Beispiel‑Rollback‑Skript (bash) zum schnellen Deaktivieren einer Route‑Map:
#!/bin/bash
# rollback-bgp.sh - entfernt kürzlich angewendete route-map an einem Neighbor
ROUTER=198.51.100.1
SSH_USER=admin
ssh ${SSH_USER}@${ROUTER} /bin/bash <<'EOS'
configure terminal
router bgp 65000
no neighbor 198.51.100.1 route-map OUT-TO-ISP out
end
write memory
EOS
Hinweis: Testen Sie Scripts in einer Lab‑Umgebung bevor Sie sie produktiv einsetzen. Sorgen Sie dafür, dass der Zugang in Notfällen auch über Out‑of‑Band möglich ist.
Zusatztools und Monitoring‑Integration
Nutzen Sie externe BGP‑Observability‑Tools (z. B. Looking Glass, RIB/Route‑Servers) und intern RPKI‑Validatoren. Monitoring‑Checks, die sinnvoll sind:
- BGP‑Session‑Status mit Kontext (CPU, Interface, letzte Änderung).
- Prefix‑Anzahl und Abweichungen gegenüber Baseline.
- RPKI‑Validation State Alerts (invalid/unknown).
- BFD‑Down Events mit Link‑Mapping.
Strukturierte Logs (JSON) erleichtern automatische Analyse in SRE‑Pipelines und SIEM‑Systemen.
Typische Stolperfallen und wie Sie sie vermeiden
- Fehlende next‑hop Erreichbarkeit: iBGP‑Routen haben oft next‑hop gesetzt; wenn dieser nicht erreichbar ist, wird die Route nicht installiert.
- Unbedachte route‑maps: Set‑Operationen wie set local‑preference oder set community können unbeabsichtigt Traffic umlenken.
- Max‑prefix zu strikt: Ein zu geringes Limit dropt legitime Ankündigungen bei Providerwechseln.
- RPKI‑Policy zu aggressiv: Bei Strict‑Mode können legitime Provider‑Ankündigungen verloren gehen, wenn ROAs fehlen.
- Stateful Firewalls ohne explizite Regeln für BGP: Verweigerte Sessions sind häufige Ursachen.
Rollback‑und Notfallstrategie
Vor jeder Änderung erstellen Sie ein getestetes Backout‑Skript und kommunizieren Wartungsfenster. Konkrete Maßnahmen:
- Sichern Sie aktuelle Router‑Config (copy running-config / save to git/backup).
- Schrittweise Änderung: Test auf einem Peer/Standby‑Router, Beobachtungszeit (z. B. 30 Minuten).
- Automatisches Rücksetzen: Bei kritischen Änderungen setzen Sie Timers und max‑prefix so, dass ein Fehler die Session schützt statt das Netz zu gefährden.
- Rollback‑Kommando bereit halten, z. B. standard‑route‑map wiederherstellen oder Neighbor‑Shutdown.
Beispiel: Schnelles Deaktivieren eines Peers (Cisco):
configure terminal
router bgp 65000
no neighbor 198.51.100.1
end
write memory
Oder weniger disruptiv: neighbor shutdown:
configure terminal
router bgp 65000
neighbor 198.51.100.1 shutdown
end
Diese Optionen lassen sich per Automatisierung (Ansible, GitOps) in Debug‑Fenstern prüfen und kontrolliert ausrollen.
Betriebsregeln, Monitoring und Regelmäßige Prüfungen
Ein stabiler BGP‑Betrieb braucht Monitoring, Alarmierung und Dokumentation:
- Routenanzahl pro Peer überwachen (plötzliche Anstiege sind Warnsignale).
- BGP session‑Flaps detektieren und Alerts mit Kontext (CPU, Interface, ACL changes) ausliefern.
- ROA/RPKI‑Status prüfen und Alerts bei Unstimmigkeiten bereitstellen.
- Regelmäßige Review‑Meetings mit Providern: Filter, Community‑Policies, geplante Änderungen dokumentieren.
Logging‑Tipp: Aktivieren Sie selective BGP‑events (neighbor up/down, prefix changes) mit strukturierter Logausgabe für SRE‑Pipelines und SIEM‑Korrelation.
Fazit: Planen, prüfen, automatisieren
BGP für Enterprise ist beherrschbar, wenn Sie Nachbarschaften methodisch aufbauen, Route‑Filter konsistent gestalten und AS‑Path‑Policies mit Augenmaß einsetzen. Schützen Sie Control Plane mit Firewall‑Regeln und CoPP, nutzen Sie RPKI zur Absicherung, aber behalten Sie Prüfpfade und Rückfallscenarios. Automatisierung und Monitoring machen Änderungen vorhersagbar und beherrschbar — vergessen Sie dabei nicht die einfache Basis: saubere IP‑Pläne, dokumentierte Policies und abgestimmte Provider‑Absprachen.
Nutzen Sie die Checklisten in diesem Beitrag als Startpunkt und erstellen Sie daraus konkrete Runbooks für Ihre Infrastruktur: Testumgebung, Canary‑Rollout und ein dokumentierter Backout‑Plan sind unverzichtbar.
Für dieses Thema sind auch Bgp Peering und Route-Filter wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.