BGP-Multihoming: Redundanz mit zwei Upstreams richtig planen

BGP-Multihoming verbindet ein eigenes Netz mit mindestens zwei unabhängigen Upstreams. Richtig geplant bleibt der Dienst bei einem Leitungs-, Router- oder Carrier-Ausfall erreichbar und kann ein- sowie ausgehenden Verkehr gezielt steuern.

Das Ziel zuerst definieren

Bevor Sessions konfiguriert werden, muss klar sein, gegen welche Ausfälle die Architektur schützen soll. Zwei BGP-Sessions auf demselben Router und derselben physischen Leitung reduzieren nur wenige Risiken. Echte Redundanz benötigt getrennte Router, Ports, Strompfade und nach Möglichkeit unterschiedliche physische Wege.

Technische Voraussetzungen

• Ein eigenes öffentliches ASN und unabhängig nutzbare IP-Präfixe.
• Korrekte IRR- und RPKI-Einträge für alle angekündigten Präfixe.
• Global üblicherweise akzeptierte Präfixlängen, meist bis /24 bei IPv4 und /48 bei IPv6.
• Router mit ausreichender FIB-, RIB- und BGP-Kapazität für die gewünschte Routentabelle.
• Dokumentierte Filter für eigene Präfixe, Bogons, Default-Route und maximale Präfixanzahl.

Active/Active oder Primary/Backup

Bei Active/Active nehmen beide Upstreams produktiv Verkehr auf. Das nutzt Kapazität effizient, verlangt aber sorgfältige Policies. Primary/Backup ist einfacher: Ein Pfad wird bevorzugt, der zweite übernimmt bei Ausfall. Die Wahl hängt von Verkehrsmengen, Kosten, Routing-Kompetenz und den Möglichkeiten beider Carrier ab.

Ausgehenden Verkehr steuern

Local Preference ist das wichtigste Werkzeug innerhalb des eigenen AS. Ein höherer Wert bevorzugt den gewünschten Ausgang. Danach folgen im BGP-Entscheidungsprozess unter anderem AS-Path-Länge und MED. Local Preference sollte zentral und nachvollziehbar gesetzt werden, damit eine einzelne Kunden- oder Peer-Route nicht unbeabsichtigt die gesamte Policy verändert.

Eingehenden Verkehr beeinflussen

Eingehender Traffic wird von fremden Netzen entschieden. Einfluss nehmen Sie vor allem mit spezifischeren Präfixen, AS-Path-Prepending und den Communities Ihrer Upstreams. Communities sind meist präziser als pauschales Prepending, weil sich Ankündigungen nach Region, Peer oder Upstream verändern lassen. Die unterstützten Werte müssen beide Carrier dokumentieren.

DDoS-Schutz muss Teil der Policy sein

Ein zweiter Upstream hilft nicht, wenn ein Angriff beide Anbindungen füllt oder die Mitigation nur auf einem Pfad greift. Klären Sie, welche Präfixe geschützt werden, wie eine Umleitung ausgelöst wird, ob Flowspec oder Blackholing unterstützt werden und wie sich Schutz-Communities mit Ihrer normalen Traffic-Engineering-Policy verhalten.

Failover real testen

1. 1Eine einzelne BGP-Session kontrolliert herunterfahren und Konvergenz messen.
2. 2Den physischen Port trennen, um Layer-1- und LACP-Verhalten zu prüfen.
3. 3Den bevorzugten Router isolieren und interne Routing-Abhängigkeiten beobachten.
4. 4Erreichbarkeit aus mehreren externen Netzen und Regionen kontrollieren.
5. 5Rückweg, Stateful Firewalls und asymmetrisches Routing in die Prüfung einbeziehen.
6. 6Ablauf, Messwerte und Rückbau dokumentieren und regelmäßig wiederholen.

Fazit

Multihoming ist eine Routing-Architektur, keine reine Anzahl von Leitungen. Erst getrennte Fehlerdomänen, klare Policies, passende Mitigation und wiederholbare Tests machen aus zwei Upstreams eine belastbare Hochverfügbarkeitslösung.