Dieses Tutorial zeigt, wie Sie dasselbe IP-Präfix von zwei separaten VPS-Standorten per BGP ankündigen. Sie konfigurieren die Primär-/Backup-Präferenz mit LOCAL_PREF und MED, aktivieren BFD für Fehlererkennung unter einer Sekunde und implementieren Graceful Shutdown für geplante Wartung. Alle Beispiele zeigen BIRD2 und FRR nebeneinander.

Voraussetzungen:

Eine funktionierende BGP-Session auf mindestens einem VPS (BIRD2 BGP-Konfiguration auf einem Linux VPS oder FRRouting BGP-Konfiguration auf einem Linux VPS)
Ihre eigene ASN und mindestens ein /24- (IPv4) oder /48-Präfix (IPv6)
Grundlegendes Verständnis von BGP-Communities (BGP Communities erklärt: Standard, Large und Extended)

Was ist BGP-Multihoming und warum auf einem VPS?

BGP-Multihoming bedeutet, dasselbe IP-Präfix von zwei oder mehr Standorten per eBGP anzukündigen. Jeder Standort unterhält eine unabhängige BGP-Session mit seinem Upstream-Provider. Fällt ein Standort aus, kündigt der andere das Präfix weiter an und übernimmt den gesamten Traffic automatisch. Die Konvergenzzeit hängt von den Hold-Timern ab (üblicherweise 180-240 Sekunden mit Standardeinstellungen) oder von BFD (unter einer Sekunde bei korrekter Konfiguration).

Auf einem VPS bietet Multihoming Redundanz, ohne von einem einzelnen Rechenzentrum abhängig zu sein. Sie betreiben zwei VPS-Instanzen an verschiedenen Standorten, die beide Ihr Präfix ankündigen. Eine dient als Primär-, die andere als Backup-Instanz. Traffic-Engineering-Attribute (LOCAL_PREF, MED, AS-Path-Prepending) steuern, welcher Pfad den Traffic unter normalen Bedingungen verarbeitet.

Wie wird BGP-Failover über zwei Standorte aufgebaut?

Das Setup verwendet zwei Virtua-VPS an verschiedenen europäischen Standorten, die jeweils eine eBGP-Session zum lokalen Upstream-Router unterhalten. Beide kündigen dasselbe /24 und /48 an.

                    Internet
                   /        \
            Upstream A     Upstream B
            (Frankfurt)    (Amsterdam)
                |              |
           eBGP session   eBGP session
                |              |
          +-----------+  +-----------+
          |  VPS-PRI  |  |  VPS-BKP  |
          | AS 64500  |  | AS 64500  |
          | BIRD2/FRR |  | BIRD2/FRR |
          +-----------+  +-----------+
           announces       announces
          198.51.100.0/24  198.51.100.0/24
          2001:db8::/48    2001:db8::/48

Beide Knoten gehören zu Ihrem AS (AS 64500 in diesen Beispielen). Ersetzen Sie ASN, Präfixe und Peer-IPs durch Ihre tatsächlichen Werte.

Firewall-Regeln für beide Knoten:

BGP verwendet TCP-Port 179. BFD verwendet UDP-Ports 3784 und 3785. Öffnen Sie diese Ports zwischen Ihrem VPS und dem Upstream-Peer, bevor Sie fortfahren.

# nftables example - adjust PEER_IP to your upstream
nft add rule inet filter input ip saddr PEER_IP tcp dport 179 accept
nft add rule inet filter input ip saddr PEER_IP udp dport { 3784, 3785 } accept

Wie steuern Sie die BGP-Pfadpräferenz?

Drei Attribute ermöglichen die Beeinflussung des Traffic-Pfads. Jedes wirkt auf einer anderen Ebene.

Attribut	Richtung	Geltungsbereich	An Peers gesendet?	Einsatz
LOCAL_PREF	Ausgehend (Ihr Ausgang)	Innerhalb Ihres AS	Nein (nur iBGP)	Steuern, welcher Knoten ausgehenden Traffic sendet
MED	Eingehend (vom Upstream)	Zwischen Ihnen und einem Upstream-AS	Ja (an direkten Nachbarn)	Einem Upstream mitteilen, welchen Einstiegspunkt er bevorzugen soll
AS-Path-Prepending	Eingehend (global)	Alle AS im Pfad	Ja (wird propagiert)	Einen Pfad für das gesamte Internet länger erscheinen lassen

LOCAL_PREF und MED sind präzise. AS-Path-Prepending ist ein grobes Werkzeug, funktioniert aber, wenn Ihre Standorte an verschiedene Upstreams angebunden sind.

Wie konfigurieren Sie LOCAL_PREF für Primär- und Backup-Pfade?

LOCAL_PREF bestimmt, welchen Ausgangspfad Ihr AS für ausgehenden Traffic bevorzugt. Der höhere Wert gewinnt. Standard ist 100. Setzen Sie 200 auf dem Primärknoten und belassen Sie 100 auf dem Backup. Dies betrifft nur den Traffic, der Ihr Netzwerk verlässt.

BIRD2-Konfiguration für LOCAL_PREF

Auf dem Primärknoten (VPS-PRI) erstellen oder ändern Sie den Import-Filter:

# /etc/bird/bird.conf - Primary node

filter upstream_import_primary {
    bgp_local_pref = 200;
    accept;
}

protocol bgp upstream_v4 {
    local 192.0.2.2 as 64500;
    neighbor 192.0.2.1 as 64496;
    ipv4 {
        import filter upstream_import_primary;
        export where net = 198.51.100.0/24;
    };
}

protocol bgp upstream_v6 {
    local 2001:db8:1::2 as 64500;
    neighbor 2001:db8:1::1 as 64496;
    ipv6 {
        import filter upstream_import_primary;
        export where net = 2001:db8::/48;
    };
}

Auf dem Backup-Knoten (VPS-BKP) belassen Sie den Standard-LOCAL_PREF:

# /etc/bird/bird.conf - Backup node

filter upstream_import_backup {
    bgp_local_pref = 100;
    accept;
}

protocol bgp upstream_v4 {
    local 203.0.113.2 as 64500;
    neighbor 203.0.113.1 as 64497;
    ipv4 {
        import filter upstream_import_backup;
        export where net = 198.51.100.0/24;
    };
}

Laden Sie BIRD2 neu und prüfen Sie die Routen:

birdc configure
birdc show route for 0.0.0.0/0 all

0.0.0.0/0          unicast [upstream_v4 12:00:00] * (100/?) [AS64496i]
        via 192.0.2.1 on eth0
        Type: BGP univ
        BGP.origin: IGP
        BGP.as_path: 64496
        BGP.local_pref: 200

Der Wert BGP.local_pref: 200 auf dem Primärknoten bedeutet, dass dieser für ausgehenden Traffic bevorzugt wird.

FRR-Konfiguration für LOCAL_PREF

Auf dem Primärknoten:

vtysh -c "configure terminal
route-map UPSTREAM-IN permit 10
 set local-preference 200
exit
router bgp 64500
 neighbor 192.0.2.1 remote-as 64496
 address-family ipv4 unicast
  neighbor 192.0.2.1 route-map UPSTREAM-IN in
  network 198.51.100.0/24
 exit-address-family
 neighbor 2001:db8:1::1 remote-as 64496
 address-family ipv6 unicast
  neighbor 2001:db8:1::1 route-map UPSTREAM-IN in
  network 2001:db8::/48
 exit-address-family
exit
exit"

Auf dem Backup-Knoten setzen Sie set local-preference 100 (oder lassen die Route-Map weg, da 100 der Standardwert ist).

Prüfen Sie die Routing-Tabelle:

vtysh -c "show ip bgp"

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0/0        192.0.2.1                     200      0 64496 i

Wie nutzen Sie MED zur Steuerung des eingehenden Traffics?

MED (Multi-Exit Discriminator) teilt Ihrem Upstream mit, welchen Einstiegspunkt er bevorzugen soll. Der niedrigere Wert gewinnt. Setzen Sie MED 0 auf dem Primär- und MED 100 auf dem Backup-Knoten. MED wird nur zwischen Pfaden desselben benachbarten AS verglichen und funktioniert daher am besten, wenn beide Standorte beim selben Upstream-Provider peeren.

BIRD2-Konfiguration für MED

Auf dem Primärknoten setzen Sie MED im Export-Filter:

filter upstream_export_primary {
    if net = 198.51.100.0/24 || net = 2001:db8::/48 then {
        bgp_med = 0;
        accept;
    }
    reject;
}

protocol bgp upstream_v4 {
    local 192.0.2.2 as 64500;
    neighbor 192.0.2.1 as 64496;
    ipv4 {
        import filter upstream_import_primary;
        export filter upstream_export_primary;
    };
}

Auf dem Backup-Knoten:

filter upstream_export_backup {
    if net = 198.51.100.0/24 || net = 2001:db8::/48 then {
        bgp_med = 100;
        accept;
    }
    reject;
}

FRR-Konfiguration für MED

Auf dem Primärknoten:

vtysh -c "configure terminal
route-map UPSTREAM-OUT permit 10
 set metric 0
exit
router bgp 64500
 address-family ipv4 unicast
  neighbor 192.0.2.1 route-map UPSTREAM-OUT out
 exit-address-family
exit
exit"

Auf dem Backup-Knoten verwenden Sie set metric 100.

Prüfen Sie die exportierten Routen:

vtysh -c "show ip bgp neighbors 192.0.2.1 advertised-routes"

   Network          Next Hop            Metric LocPrf Weight Path
*> 198.51.100.0/24  0.0.0.0                  0         32768 i

Die Spalte Metric zeigt 0 auf dem Primärknoten. Der Backup-Knoten zeigt 100.

Wann sollten Sie AS-Path-Prepending statt MED verwenden?

Verwenden Sie AS-Path-Prepending, wenn Ihre beiden Standorte an verschiedene Upstream-Provider angebunden sind. MED wird nur zwischen Pfaden desselben AS verglichen und hat daher keine Wirkung, wenn Ihre Upstreams verschiedene ASes sind. Prepending lässt den Backup-Pfad länger erscheinen und lenkt globale Routing-Entscheidungen zum Primärknoten.

Fügen Sie Ihre eigene ASN 1-3 Mal auf dem Backup-Knoten hinzu. Mehr als 3 Prepends ändern selten Routing-Entscheidungen und erzeugen nur Rauschen.

BIRD2 (Export-Filter des Backup-Knotens):

filter upstream_export_backup_prepend {
    if net = 198.51.100.0/24 || net = 2001:db8::/48 then {
        bgp_path.prepend(64500);
        bgp_path.prepend(64500);
        accept;
    }
    reject;
}

FRR (Backup-Knoten):

vtysh -c "configure terminal
route-map UPSTREAM-OUT permit 10
 set as-path prepend 64500 64500
exit
exit"

Nach der Anwendung prüfen Sie den AS-Pfad über ein Looking Glass oder einen entfernten Host:

# From an external machine
traceroute -A 198.51.100.1

Der Backup-Pfad zeigt jetzt 64500 64500 64500 (Ihre ASN erscheint dreimal: einmal echt, zweimal vorgefügt), während der Primärpfad 64500 einmal zeigt.

Wie aktivieren Sie BFD für schnelle Fehlererkennung?

Ohne BFD verlässt sich BGP auf Hold-Timer zur Erkennung eines Peer-Ausfalls. Der Standard-Hold-Timer beträgt 240 Sekunden bei BIRD2 und 180 Sekunden bei FRR. Mit BFD sinkt die Erkennungszeit auf unter eine Sekunde bei Verbindungen mit niedriger Latenz.

Parameter	Standard	Empfohlen für VPS
Sendeintervall	300 ms	300 ms
Empfangsintervall	300 ms	300 ms
Erkennungsmultiplikator	3	3
Effektive Erkennungszeit	900 ms	900 ms

Für VPS-Umgebungen auf demselben Provider-Backbone bieten 300-ms-Intervalle mit Multiplikator 3 eine zuverlässige Erkennung unter einer Sekunde ohne Fehlalarme. Setzen Sie die Intervalle auf VPS-Instanzen nicht unter 100 ms. Virtualisierungs-Jitter kann Flapping verursachen.

BIRD2-Konfiguration für BFD

Fügen Sie ein BFD-Protokoll hinzu und aktivieren Sie es für die BGP-Session:

protocol bfd {
    interface "*" {
        min rx interval 300 ms;
        min tx interval 300 ms;
        multiplier 3;
    };
}

protocol bgp upstream_v4 {
    local 192.0.2.2 as 64500;
    neighbor 192.0.2.1 as 64496;
    bfd graceful;
    ipv4 {
        import filter upstream_import_primary;
        export filter upstream_export_primary;
    };
}

Die Option bfd graceful bewirkt, dass BIRD2 bei einem BFD-erkannten Ausfall einen Graceful Restart auslöst (mit Beibehaltung veralteter Routen) statt eines harten Session-Resets. Unterstützt der Peer kein BFD, wird die Session trotzdem normal aufgebaut.

Nach dem Neuladen prüfen Sie den BFD-Status:

birdc show bfd sessions

BFD sessions:
IP address       Interface  State   Since       Interval  Timeout
192.0.2.1        eth0       Up      12:00:00    300 ms    900 ms

FRR-Konfiguration für BFD

vtysh -c "configure terminal
bfd
 profile vps-detect
  receive-interval 300
  transmit-interval 300
  detect-multiplier 3
 exit
exit
router bgp 64500
 neighbor 192.0.2.1 bfd profile vps-detect
 neighbor 2001:db8:1::1 bfd profile vps-detect
exit
exit"

Prüfen Sie den BFD-Peer-Status:

vtysh -c "show bfd peers"

BFD Peers:
        peer 192.0.2.1 vrf default
                ID: 1
                Remote ID: 2
                Status: up
                Uptime: 5 minute(s)
                Diagnostics: ok
                Remote diagnostics: ok
                Peer Type: configured
                Local timers:
                        Receive interval: 300ms
                        Transmission interval: 300ms
                        Echo receive interval: disabled
                        Echo transmission interval: disabled
                Peer timers:
                        Receive interval: 300ms
                        Transmission interval: 300ms
                        Echo receive interval: disabled

BFD erfordert offene UDP-Ports 3784 und 3785 zwischen den Peers. Wenn Sie den Firewall-Schritt zuvor übersprungen haben, bleiben BFD-Sessions im Status Down.

Wie führen Sie einen Graceful Shutdown für Wartung durch?

RFC 8326 definiert die Well-known Community GRACEFUL_SHUTDOWN (65535:0). Vor geplanter Wartung markieren Sie alle Routen mit dieser Community. Peers, die sie berücksichtigen, setzen die Local-Preference für diese Routen auf 0, sodass der Traffic auf alternative Pfade umgeleitet wird, bevor Sie die Session beenden. Das vermeidet das Traffic-Blackhole, das bei normaler BGP-Konvergenz auftritt.

Die Graceful-Shutdown-Prozedur:

Markieren Sie Routen mit der GRACEFUL_SHUTDOWN-Community auf dem Knoten, den Sie herunterfahren
Warten Sie auf Konvergenz (30-60 Sekunden, bis das Internet den Traffic umleitet)
Prüfen Sie, ob der Traffic umgeleitet wurde, über ein Looking Glass oder Traffic-Zähler
Beenden Sie die BGP-Session
Führen Sie die Wartung durch
Starten Sie die Session neu und entfernen Sie die Community
Bestätigen Sie die Re-Konvergenz

Graceful Shutdown mit BIRD2

Um den Graceful Shutdown auf dem Primärknoten vor der Wartung einzuleiten, ändern Sie den Export-Filter:

# Temporary export filter for graceful shutdown
filter upstream_export_shutdown {
    if net = 198.51.100.0/24 || net = 2001:db8::/48 then {
        bgp_community.add((65535, 0));
        bgp_med = 65535;
        accept;
    }
    reject;
}

Wenden Sie ihn an, indem Sie den Export-Filter im BGP-Protokoll ändern und neu laden:

# Edit bird.conf: change export filter to upstream_export_shutdown
# Then reload
birdc configure

Um Graceful Shutdown von Peers zu berücksichtigen (wenden Sie dies auf beiden Knoten an), fügen Sie eine Prüfung im Import-Filter hinzu. Die Reihenfolge ist wichtig: Die Graceful-Shutdown-Prüfung muss accept innerhalb des if-Blocks aufrufen, sonst überschreibt eine spätere bgp_local_pref-Zuweisung den Wert.

filter upstream_import_backup {
    if (65535, 0) ~ bgp_community then {
        bgp_local_pref = 0;
        accept;
    }
    bgp_local_pref = 100;
    accept;
}

Graceful Shutdown mit FRR

FRR bietet einen einzelnen Befehl, der das Tagging automatisch übernimmt:

vtysh -c "configure terminal
router bgp 64500
 bgp graceful-shutdown
exit
exit"

Dies fügt die GRACEFUL_SHUTDOWN-Community (65535:0) zu allen Routen hinzu und setzt die Local-Preference auf 0. Ein Route-Refresh wird an alle Peers gesendet.

Um zu bestätigen, dass die Community gesendet wird:

vtysh -c "show ip bgp neighbors 192.0.2.1 advertised-routes"

   Network          Next Hop            Metric LocPrf Weight Path
*> 198.51.100.0/24  0.0.0.0                  0      0  32768 i
                                         Community: graceful-shutdown

Nach der Wartung entfernen Sie die Community:

vtysh -c "configure terminal
router bgp 64500
 no bgp graceful-shutdown
exit
exit"

Damit FRR den Graceful Shutdown von Peers berücksichtigt, konfigurieren Sie eine eingehende Route-Map:

vtysh -c "configure terminal
bgp community-list standard GRACEFUL_SHUTDOWN permit graceful-shutdown
route-map UPSTREAM-IN permit 5
 match community GRACEFUL_SHUTDOWN
 set local-preference 0
exit
route-map UPSTREAM-IN permit 10
 set local-preference 200
exit
exit"

Sequence 5 erkennt Routen mit der Community und senkt die Local-Preference auf 0. Sequence 10 verarbeitet alle anderen Routen normal.

Wie testen Sie das BGP-Failover?

Testen Sie das Failover, indem Sie die primäre BGP-Session beenden und vom Backup-Knoten sowie einem externen Standort aus beobachten.

Schritt 1: Prüfen Sie den aktuellen Routing-Status auf beiden Knoten.

BIRD2:

birdc show route for 198.51.100.0/24 all

FRR:

vtysh -c "show ip bgp 198.51.100.0/24"

Schritt 2: Beenden Sie die primäre BGP-Session.

BIRD2 (auf VPS-PRI):

birdc disable upstream_v4
birdc disable upstream_v6

FRR (auf VPS-PRI):

vtysh -c "configure terminal
router bgp 64500
 neighbor 192.0.2.1 shutdown
 neighbor 2001:db8:1::1 shutdown
exit
exit"

Schritt 3: Beobachten Sie den Backup-Knoten.

Auf VPS-BKP sollte die Route jetzt als einziger Pfad erscheinen:

# BIRD2
birdc show route for 198.51.100.0/24

# FRR
vtysh -c "show ip bgp summary"

Schritt 4: Testen Sie von extern.

Führen Sie von Ihrer lokalen Maschine oder einem Looking Glass einen Traceroute zu Ihrem Präfix durch:

traceroute -A 198.51.100.1

Der Traffic sollte jetzt über den Backup-Standort eingehen. Mit aktiviertem BFD erfolgt die Umschaltung in unter einer Sekunde. Ohne BFD ist mit der vollen Hold-Timer-Dauer vor der Konvergenz zu rechnen.

Erkennungsmethode	Typische Failover-Zeit
Nur BGP-Hold-Timer (BIRD2-Standard 240 s)	160-240 s
Nur BGP-Hold-Timer (FRR-Standard 180 s)	120-180 s
Reduzierter Hold-Timer (z. B. 30 s)	20-30 s
BFD (300-ms-Intervalle, Multiplikator 3)	< 1 s

Nutzen Sie NLNOG Looking Glass oder bgp.tools, um die globale Routing-Konvergenz zu bestätigen.

Wie stellen Sie den Betrieb nach einem Failover wieder her?

Starten Sie die primäre Session neu und bestätigen Sie, dass der Traffic zum bevorzugten Pfad zurückkehrt.

BIRD2:

birdc enable upstream_v4
birdc enable upstream_v6

FRR:

vtysh -c "configure terminal
router bgp 64500
 no neighbor 192.0.2.1 shutdown
 no neighbor 2001:db8:1::1 shutdown
exit
exit"

Nach einigen Sekunden prüfen Sie, ob der Primärpfad wieder bevorzugt wird:

# BIRD2
birdc show route for 0.0.0.0/0 all | grep local_pref

        BGP.local_pref: 200

# FRR
vtysh -c "show ip bgp"

   Network          Next Hop            Metric LocPrf Weight Path
*> 0.0.0.0/0        192.0.2.1                     200      0 64496 i

Führen Sie erneut einen Traceroute von einem externen Host durch, um zu bestätigen, dass der Traffic wieder über den Primärstandort eingeht.

Vergleich der BIRD2- und FRR-Konfigurationen

Funktion	BIRD2	FRR
LOCAL_PREF	`bgp_local_pref = 200;` im Import-Filter	`set local-preference 200` in der Route-Map
MED	`bgp_med = 0;` im Export-Filter	`set metric 0` in der Route-Map
AS-Path-Prepend	`bgp_path.prepend(64500);` im Export-Filter	`set as-path prepend 64500` in der Route-Map
BFD	`protocol bfd {}` + `bfd graceful;` in BGP	`bfd`-Sektion + `neighbor X bfd profile Y`
Graceful Shutdown (einleiten)	`(65535, 0)` zu `bgp_community` im Export-Filter hinzufügen	`bgp graceful-shutdown` unter `router bgp`
Graceful Shutdown (berücksichtigen)	`(65535, 0) ~ bgp_community` im Import-Filter prüfen, `bgp_local_pref = 0` setzen	`match community GRACEFUL_SHUTDOWN` in der Route-Map, `set local-preference 0`
Session deaktivieren	`birdc disable <protocol>`	`neighbor X shutdown`
Konfiguration neu laden	`birdc configure`	`write memory` dann `clear ip bgp *` oder Neustart

Überwachung von Failover-Ereignissen

Richten Sie Monitoring ein, um bei tatsächlichen Failovers benachrichtigt zu werden. BGP-Ankündigungen mit BGPalerter unter Linux überwachen behandelt BGPalerter für Route-Monitoring. Überwachen Sie mindestens:

Statusänderungen der BGP-Sessions: journalctl -u bird oder journalctl -u frr
BFD-Session-Flaps: birdc show bfd sessions / vtysh -c "show bfd peers"
Änderungen der Routenanzahl: Alarm auslösen, wenn die Anzahl der exportierten Präfixe auf null fällt

Fehlerbehebung

BGP-Session bleibt im Status Active/Connect:

Prüfen Sie die Firewall-Regeln für TCP 179
Stellen Sie sicher, dass Peer-IP und ASN mit den Erwartungen Ihres Upstreams übereinstimmen
Prüfen Sie journalctl -u bird -f oder journalctl -u frr -f auf Fehlermeldungen

BFD-Session bleibt im Status Down:

Die UDP-Ports 3784 und 3785 müssen in beide Richtungen offen sein
Bestätigen Sie, dass der Peer BFD unterstützt und konfiguriert hat
Prüfen Sie MTU-Probleme auf dem Pfad

MED beeinflusst den eingehenden Traffic nicht:

MED wird nur zwischen Pfaden desselben AS verglichen. Sind Ihre Upstreams verschiedene ASes, verwenden Sie stattdessen AS-Path-Prepending
Manche Upstreams ignorieren MED per Richtlinie. Fragen Sie Ihren Provider

Graceful-Shutdown-Community wird nicht berücksichtigt:

Der Peer muss RFC 8326 explizit unterstützen. Nicht alle Upstreams tun dies
Erkundigen Sie sich bei Ihrem Provider, ob er die GRACEFUL_SHUTDOWN-Community berücksichtigt
Manche Implementierungen erfordern eine explizite Konfiguration zur Berücksichtigung der Community

Traffic wechselt nicht den Pfad:

Stellen Sie sicher, dass beide Knoten dasselbe Präfix ankündigen, mit birdc show route export upstream_v4 oder vtysh -c "show ip bgp neighbors X advertised-routes"
Prüfen Sie von einem externen Looking Glass aus, nicht von den Knoten selbst
DNS-TTL kann Clients auf die alte IP verweisen, wenn Sie standortspezifische IPs für Dienste oberhalb des Anycast-Präfixes verwenden

BGP-Failover und Multihoming von zwei VPS-Standorten