BIRD2 BGP-Konfiguration auf einem Linux VPS

13 Min. Lesezeit·Matthieu·bgpbird2routingipv6firewall|

Installieren Sie BIRD2 auf Debian 12 oder Ubuntu 24.04 und richten Sie eine BGP-Session ein, um Ihre eigenen IP-Prefixe zu annoncieren. Dual-Stack, Export-Filter, persistente Dummy-Interfaces, nftables-Regeln und birdc-Verifizierung.

BIRD ist der Routing-Daemon, der von CZ.NIC gepflegt wird. Version 2 vereinte IPv4 und IPv6 in einem einzigen Daemon, ersetzte die getrennte BIRD/BIRD6-Architektur aus 1.x und brachte eine leistungsstarke Filtersprache mit. Diese Anleitung behandelt die Installation von BIRD2 auf einem Linux VPS, die Konfiguration einer BGP-Session mit Ihrem Upstream-Provider, das Annoncieren Ihrer IP-Prefixe und die Verifizierung des gesamten Setups.

Alle Beispiele sind Dual-Stack (IPv4 + IPv6). Ersetzen Sie die Platzhalter-ASNs, IPs und Prefixe durchgehend mit Ihren eigenen Werten.

Was brauchen Sie vor der BIRD2-BGP-Konfiguration?

Bevor Sie bird.conf bearbeiten, brauchen Sie eine ASN, zugewiesenen IP-Adressraum und einen Provider, der BGP-Sessions auf Ihrem VPS anbietet. Ohne alle drei hat BIRD2 nichts zu annoncieren und niemanden zum Peering.

Sammeln Sie diese Informationen von Ihrem Provider oder aus Ihrer RIR-Allokation:

Element Beispielwert Woher
Ihre ASN AS65400 RIPE NCC, ARIN oder Ihr LIR
Ihr IPv4-Prefix 203.0.113.0/24 RIR-Allokation oder PA-Assignment vom Provider
Ihr IPv6-Prefix 2001:db8:1000::/48 RIR-Allokation oder PA-Assignment vom Provider
Upstream-ASN AS64496 BGP-Session-Details des Providers
Upstream-Peer IPv4 198.51.100.1 BGP-Session-Details des Providers
Upstream-Peer IPv6 2001:db8::1 BGP-Session-Details des Providers
Ihre Peering-IPv4 198.51.100.2 BGP-Session-Details des Providers
Ihre Peering-IPv6 2001:db8::2 BGP-Session-Details des Providers
MD5-Passwort (Shared Secret) Mit dem Provider vereinbart

Sie brauchen außerdem ROA-Records (Route Origin Authorization), die für Ihre Prefixe publiziert sind, bevor Ihre Routen die RPKI-Validierung bei Downstream-Netzwerken bestehen. Siehe RPKI ROA für BGP: ROAs erstellen, Routen in BIRD2 und FRR validieren für dieses Setup.

Stellen Sie sicher, dass Ihr Provider Ihre Prefixe in seine IRR-Filter aufgenommen hat. Ohne das werden Ihre Announcements gefiltert, selbst wenn die BGP-Session aufgebaut wird.

Ein VPS mit mindestens 1 GB RAM reicht für BIRD2 mit einer Full Table (über 1 Million IPv4-Routen). Wenn Sie nur eine Default-Route von Ihrem Upstream akzeptieren, bleibt der Speicherverbrauch unter 100 MB.

Wie installieren Sie BIRD2 auf Debian 12 und Ubuntu 24.04?

BIRD2 ist in den Standard-Repositories beider Distributionen verfügbar. Debian 12 liefert Version 2.0.12, Ubuntu 24.04 liefert 2.14. Beide funktionieren für einfaches BGP, aber das offizielle CZ.NIC-Repository stellt BIRD 2.18 (veröffentlicht Januar 2026) bereit, mit BGP Dynamic Unnumbered Support, Performance-Verbesserungen und aktuellen Bugfixes. Verwenden Sie das CZ.NIC-Repo für Produktionsumgebungen.

Hinweis: CZ.NIC veröffentlicht BIRD2-Pakete unter dem Projektnamen bird2. Verwechseln Sie es nicht mit dem Projekt bird (das nur Debian abdeckt) oder bird3 (BIRD 3.x).

Installation aus dem CZ.NIC-Repository (empfohlen)

Fügen Sie das offizielle Repository hinzu und installieren Sie:

sudo apt-get update
sudo apt-get -y install apt-transport-https ca-certificates wget

Importieren Sie den CZ.NIC-GPG-Schlüssel:

sudo wget -O /usr/share/keyrings/cznic-labs-pkg.gpg https://pkg.labs.nic.cz/gpg

Fügen Sie das Repository hinzu. Auf Debian 12:

echo "deb [signed-by=/usr/share/keyrings/cznic-labs-pkg.gpg] https://pkg.labs.nic.cz/bird2 bookworm main" | sudo tee /etc/apt/sources.list.d/cznic-labs-bird.list

Auf Ubuntu 24.04:

echo "deb [signed-by=/usr/share/keyrings/cznic-labs-pkg.gpg] https://pkg.labs.nic.cz/bird2 noble main" | sudo tee /etc/apt/sources.list.d/cznic-labs-bird.list

Installieren Sie BIRD2:

sudo apt-get update
sudo apt-get -y install bird2

Installation aus den Standard-Repositories

Wenn Sie das Distributionspaket bevorzugen:

sudo apt-get update
sudo apt-get -y install bird2

Installation verifizieren

bird --version

Erwartete Ausgabe (CZ.NIC-Repo):

BIRD version 2.18

Prüfen Sie, ob der Dienst läuft:

sudo systemctl status bird

BIRD startet nach der Installation automatisch. Die Standardkonfiguration unter /etc/bird/bird.conf ist ein Gerüst. Sie werden sie im nächsten Abschnitt vollständig ersetzen.

Wie ist bird.conf für BGP aufgebaut?

Eine BGP-taugliche bird.conf besteht aus fünf Blöcken: globale Einstellungen und vier Protokollabschnitte (device, direct, kernel, bgp). Jedes Protokoll läuft unabhängig und kommuniziert über Routing-Tabellen.

Hier ist die vollständige bird.conf für ein Dual-Stack-BGP-Setup. Lesen Sie sie zuerst durch; die folgenden Abschnitte erklären jeden Block.

sudo cp /etc/bird/bird.conf /etc/bird/bird.conf.bak

sudo tee /etc/bird/bird.conf > /dev/null << 'BIRDCONF'
# /etc/bird/bird.conf - BIRD2 BGP configuration
# Replace all placeholder values with your own

log syslog all;

router id 198.51.100.2;

# Watch interface state changes
protocol device {
    scan time 10;
}

# Import connected routes (needed for next-hop resolution)
protocol direct {
    ipv4;
    ipv6;
    interface "dummy0";
    interface "eth0";
}

# Sync BIRD routes to kernel routing table
protocol kernel {
    ipv4 {
        export all;
        import all;
    };
    learn;
    scan time 15;
    merge paths on;
}

protocol kernel {
    ipv6 {
        export all;
        import all;
    };
    learn;
    scan time 15;
    merge paths on;
}

# Define your prefixes
define OWN_V4_PREFIX = 203.0.113.0/24;
define OWN_V6_PREFIX = 2001:db8:1000::/48;

# Export filter: only announce your own prefixes
filter export_bgp_v4 {
    if net = OWN_V4_PREFIX then accept;
    reject;
}

filter export_bgp_v6 {
    if net = OWN_V6_PREFIX then accept;
    reject;
}

# Static routes for prefix origination (point to dummy0)
protocol static static_v4 {
    ipv4;
    route 203.0.113.0/24 via "dummy0";
}

protocol static static_v6 {
    ipv6;
    route 2001:db8:1000::/48 via "dummy0";
}

# BGP session with upstream provider
protocol bgp upstream1 {
    description "Upstream Provider";
    local 198.51.100.2 as 65400;
    neighbor 198.51.100.1 as 64496;
    source address 198.51.100.2;
    hold time 90;
    keepalive time 30;
    password "your-md5-secret";

    ipv4 {
        import all;
        export filter export_bgp_v4;
        next hop self;
    };

    ipv6 {
        import all;
        export filter export_bgp_v6;
        next hop self;
    };
}
BIRDCONF

Setzen Sie die Berechtigungen der Konfigurationsdatei. Nur root und der Benutzer bird brauchen Zugriff:

sudo chown root:bird /etc/bird/bird.conf
sudo chmod 640 /etc/bird/bird.conf

Berechtigungen überprüfen:

ls -la /etc/bird/bird.conf

Erwartete Ausgabe:

-rw-r----- 1 root bird 1247 Mar 19 12:00 /etc/bird/bird.conf

Globale Einstellungen

log syslog all;
router id 198.51.100.2;

router id muss eine global eindeutige IPv4-Adresse sein. Verwenden Sie eine Ihrer zugewiesenen IPs. BIRD kann sie automatisch von Interfaces erkennen, aber eine explizite Angabe ist besser.

log syslog all sendet alle Log-Nachrichten an das Systemjournal. Lesen Sie sie mit journalctl -u bird -f. Wenn Sie bei der Fehlersuche für ein bestimmtes Protokoll ausführlichere Ausgaben brauchen, fügen Sie temporär debug protocols all; hinzu. Entfernen Sie es, sobald die Session funktioniert. Debug-Level-Logging erzeugt hohes Volumen und kann Ihren Journal-Speicher füllen.

Protocol device

protocol device {
    scan time 10;
}

Überwacht Interface-Zustandsänderungen alle 10 Sekunden. Erforderlich. Ohne diesen Block weiß BIRD nicht, wann Interfaces hoch- oder herunterfahren.

Protocol direct

protocol direct {
    ipv4;
    ipv6;
    interface "dummy0";
    interface "eth0";
}

Importiert Connected Routes von den aufgelisteten Interfaces. BIRD braucht diese für die Next-Hop-Auflösung. Listen Sie nur die Interfaces auf, die an Ihrem BGP-Setup beteiligt sind.

Protocol kernel

Zwei Kernel-Protokollblöcke werden benötigt: einer für IPv4, einer für IPv6. Jeder synchronisiert seine Adressfamilie zwischen BIRDs Routing-Tabelle und der Linux-Kernel-Tabelle.

merge paths on aktiviert ECMP, wenn Sie mehrere Upstreams haben. learn importiert bestehende Kernel-Routen in BIRD.

Was macht der Protocol-BGP-Block?

Der protocol bgp-Block definiert eine Peering-Session mit einem Neighbor. Er legt fest, wer Sie sind (local ... as), mit wem Sie peeren (neighbor ... as), die Authentifizierung (password) und welche Routen ausgetauscht werden (Channel-Blöcke).

Wichtige Direktiven:

Direktive Zweck
local <ip> as <ASN> Ihre Peering-IP und ASN
neighbor <ip> as <ASN> Peering-IP und ASN des Upstreams
source address <ip> Quell-IP für die TCP-Verbindung
hold time 90 Sekunden bis zur Peer-Toterklärung (3x Keepalive)
keepalive time 30 Intervall zwischen Keepalive-Nachrichten
password "..." MD5-Authentifizierung (RFC 2385)

MD5-Authentifizierung schützt die BGP-Session gegen gefälschte TCP-Resets und Injection-Angriffe. Beide Seiten müssen dasselbe Passwort konfigurieren. Fragen Sie Ihren Provider nach dem Shared Secret.

Wie konfigurieren Sie Dual-Stack-IPv4- und IPv6-Channels?

BIRD2 behandelt IPv4 und IPv6 als separate Channels innerhalb desselben Protokollblocks. Jeder Channel hat seine eigene Import/Export-Policy:

ipv4 {
    import all;
    export filter export_bgp_v4;
    next hop self;
};

ipv6 {
    import all;
    export filter export_bgp_v6;
    next hop self;
};

import all akzeptiert alle Routen vom Upstream. In Produktionsumgebungen sollten Sie auch Imports filtern. Siehe BGP Route Filtering: Prefix-Listen, AS-Path-Filter, Bogon-Ablehnung und GTSM für Import-Filter-Beispiele.

next hop self schreibt das Next-Hop-Attribut auf Ihre Peering-IP um. Erforderlich, wenn der Upstream erwartet, dass Traffic über Ihre Adresse läuft -- das ist das Standardsetup auf einem VPS.

Wenn Ihr Provider separate BGP-Sessions für IPv4 und IPv6 betreibt (unterschiedliche Neighbor-IPs pro Adressfamilie), teilen Sie sie stattdessen in zwei protocol bgp-Blöcke auf.

Wie schreiben Sie Export-Filter, die nur Ihre Prefixe annoncieren?

Export-Filter steuern, welche Routen BIRD an den Upstream sendet. Ein falsch konfigurierter Export-Filter kann Routen leaken, die Ihnen nicht gehören. Das führt dazu, dass Ihre Session beendet wird, und möglicherweise erhalten Sie einen Anruf vom NOC Ihres Upstreams.

Der Filter in der obigen Konfiguration verwendet einen einfachen Prefix-Match:

define OWN_V4_PREFIX = 203.0.113.0/24;

filter export_bgp_v4 {
    if net = OWN_V4_PREFIX then accept;
    reject;
}

Dieser akzeptiert nur das exakte /24. Alles andere wird abgelehnt. Das reject am Ende ist das Default Deny.

Für mehrere Prefixe verwenden Sie ein Set:

define OWN_V4_PREFIXES = [ 203.0.113.0/24, 198.51.100.0/24 ];

filter export_bgp_v4 {
    if net ~ OWN_V4_PREFIXES then accept;
    reject;
}

Der Operator ~ gleicht gegen ein Prefix-Set ab. Er unterstützt auch Range-Notation:

define OWN_V4_PREFIXES = [ 203.0.113.0/24{24,24} ];

{24,24} beschränkt den Match auf exakt /24. Verwenden Sie {24,28}, um auch Deaggregation bis /28 zuzulassen, falls Sie für Traffic Engineering More-Specifics annoncieren müssen.

Für IPv6 gilt dasselbe Muster:

define OWN_V6_PREFIXES = [ 2001:db8:1000::/48{48,48} ];

filter export_bgp_v6 {
    if net ~ OWN_V6_PREFIXES then accept;
    reject;
}

Halten Sie Export-Filter immer so eng wie möglich. Annoncieren Sie nur, was Ihnen gehört, mit den exakten Prefixlängen, die Sie beabsichtigen. Ein fehlendes reject am Ende Ihres Filters führt dazu, dass BIRD die Standardaktion des Channels verwendet, die accept sein kann. Beenden Sie Filter immer mit einem expliziten reject.

Sie können Ihren Filter testen, ohne ihn anzuwenden:

sudo birdc eval '203.0.113.0/24 ~ [ 203.0.113.0/24 ]'

Dies gibt TRUE oder FALSE zurück und hilft bei der Fehlersuche in der Filterlogik vor einem Config-Reload.

Wie erstellen Sie ein persistentes Dummy-Interface für Prefix Origination?

BGP annonciert Prefixe, die in der Routing-Tabelle existieren. Sie brauchen ein Interface mit Ihrem Prefix, damit BIRD die Route originieren kann. Ein Dummy-Interface erfüllt diesen Zweck: Es ist immer up, hat keinen physischen Link und überlebt Neustarts, wenn es über systemd-networkd konfiguriert wird.

Flüchtige ip link add-Befehle gehen beim Neustart verloren. Verwenden Sie stattdessen systemd-networkd.

.netdev-Datei erstellen

sudo tee /etc/systemd/network/10-dummy0.netdev > /dev/null << 'EOF'
[NetDev]
Name=dummy0
Kind=dummy
EOF

.network-Datei erstellen

sudo tee /etc/systemd/network/10-dummy0.network > /dev/null << 'EOF'
[Match]
Name=dummy0

[Network]
Address=203.0.113.1/32
Address=2001:db8:1000::1/128
EOF

Weisen Sie dem Dummy-Interface eine einzelne /32 (oder /128 für IPv6) aus Ihrem zugewiesenen Prefix zu. Diese Adresse muss nicht von aussen erreichbar sein. Sie existiert nur, damit BIRD eine Connected Route für das Prefix hat.

Anwenden und verifizieren

sudo systemctl restart systemd-networkd

Warten Sie einige Sekunden und prüfen Sie dann:

ip addr show dummy0

Erwartete Ausgabe:

3: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ether aa:bb:cc:dd:ee:ff brd ff:ff:ff:ff:ff:ff
    inet 203.0.113.1/32 scope global dummy0
       valid_lft forever preferred_lft forever
    inet6 2001:db8:1000::1/128 scope global
       valid_lft forever preferred_lft forever

Der Zustand state UNKNOWN bei einem Dummy-Interface ist normal. Er bedeutet, dass die Link-Schicht keinen physischen Carrier zu überwachen hat, aber das Interface ist UP und leitet weiter. Die MAC-Adresse wird von systemd-networkd zufällig generiert und wird auf Ihrem System anders sein.

Wenn Sie ifupdown statt systemd-networkd verwenden (prüfen Sie mit networkctl status), müssen Sie systemd-networkd möglicherweise zuerst aktivieren:

sudo systemctl enable --now systemd-networkd

Verifizieren Sie, dass die Dateien für den nächsten Neustart vorhanden sind:

ls -la /etc/systemd/network/10-dummy0.*

-rw-r--r-- 1 root root  42 Mar 19 12:00 /etc/systemd/network/10-dummy0.netdev
-rw-r--r-- 1 root root  89 Mar 19 12:00 /etc/systemd/network/10-dummy0.network

Wie sichern Sie BGP mit nftables-Firewall-Regeln ab?

BGP läuft auf TCP-Port 179. Ohne Firewall-Regeln kann jeder Host im Internet versuchen, eine BGP-Session mit Ihrem Router aufzubauen. Automatisierte Scanner finden einen offenen Port 179 innerhalb von Stunden, nachdem ein VPS online geht. Beschränken Sie Port 179 auf Ihre Peer-IPs.

nftables ist unter Ubuntu 24.04 möglicherweise nicht standardmäßig installiert. Installieren Sie es zuerst:

sudo apt-get -y install nftables

nftables-Regelsatz erstellen

sudo tee /etc/nftables.d/bgp.conf > /dev/null << 'EOF'
table inet bgp_filter {
    set bgp_peers_v4 {
        type ipv4_addr
        elements = { 198.51.100.1 }
    }

    set bgp_peers_v6 {
        type ipv6_addr
        elements = { 2001:db8::1 }
    }

    chain input {
        type filter hook input priority 0; policy accept;

        # Allow BGP from known peers only
        tcp dport 179 ip saddr @bgp_peers_v4 accept
        tcp dport 179 ip6 saddr @bgp_peers_v6 accept

        # Drop BGP from everyone else
        tcp dport 179 drop
    }
}
EOF

Fügen Sie weitere Peer-IPs zu den Sets hinzu, wenn Sie Upstreams ergänzen. Benannte Sets ermöglichen es Ihnen, Peer-Listen zu aktualisieren, ohne Regeln umzuschreiben.

Integration mit Ihrer bestehenden nftables-Konfiguration

Wenn Sie bereits /etc/nftables.conf haben, binden Sie die BGP-Regeln ein:

echo 'include "/etc/nftables.d/bgp.conf"' | sudo tee -a /etc/nftables.conf

Wenn Sie nftables noch nicht eingerichtet haben, erstellen Sie das Verzeichnis und laden Sie die Konfiguration:

sudo mkdir -p /etc/nftables.d
sudo systemctl enable --now nftables

enable --now startet nftables sofort und stellt sicher, dass es bei jedem Boot geladen wird.

Wenden Sie die Regeln an:

sudo nft -f /etc/nftables.d/bgp.conf

Regeln verifizieren

sudo nft list table inet bgp_filter

Erwartete Ausgabe:

table inet bgp_filter {
	set bgp_peers_v4 {
		type ipv4_addr
		elements = { 198.51.100.1 }
	}

	set bgp_peers_v6 {
		type ipv6_addr
		elements = { 2001:db8::1 }
	}

	chain input {
		type filter hook input priority filter; policy accept;
		tcp dport 179 ip saddr @bgp_peers_v4 accept
		tcp dport 179 ip6 saddr @bgp_peers_v6 accept
		tcp dport 179 drop
	}
}

nft list normalisiert priority 0 zu priority filter und entfernt Kommentare. Das ist erwartetes Verhalten.

Testen Sie, ob die Regel funktioniert, indem Sie den Verbindungsstatus prüfen. Vom VPS aus:

sudo nft list ruleset | grep -c "179"

Dies sollte eine Zahl zurückgeben, die der Anzahl Ihrer Port-179-Regeln entspricht.

Stellen Sie außerdem sicher, dass BGP-Traffic zwischen Ihnen und Ihrem Peer nicht blockiert wird. Die obigen Regeln betreffen nur eingehende Verbindungen. BIRD initiiert ausgehende Verbindungen zum Peer, die vom established/related Conntrack-Eintrag behandelt werden. Wenn Sie eine restriktive Outbound-Policy haben, fügen Sie hinzu:

sudo nft add rule inet bgp_filter input ct state established,related accept

Das sollte bereits in Ihrem Basis-Firewall-Regelsatz enthalten sein. Wenn nicht, fügen Sie es vor den BGP-Regeln hinzu.

Wie wenden Sie die BIRD2-Konfiguration an?

Bevor Sie eine neue Konfiguration laden, validieren Sie sie:

sudo birdc configure check

Erwartete Ausgabe:

BIRD 2.18 ready.
Reading configuration from /etc/bird/bird.conf
Configuration OK

Wenn Syntaxfehler vorhanden sind, meldet BIRD die Zeilennummer und das Problem. Beheben Sie den Fehler und prüfen Sie erneut.

Wenden Sie die Konfiguration an:

sudo birdc configure

BIRD 2.18 ready.
Reading configuration from /etc/bird/bird.conf
Reconfigured

Möglicherweise sehen Sie Reconfiguration in progress statt Reconfigured, wenn BIRD noch Protokolländerungen verarbeitet (z.B. den Aufbau einer neuen BGP-Session). Beides ist normal.

BIRD wendet die neue Konfiguration ohne Neustart an. Bestehende Sessions führen nach Möglichkeit eine Soft Reconfiguration durch. Wenn Sie die Neighbor-IP oder die lokale AS geändert haben, startet BIRD das betroffene Protokoll automatisch neu.

Für Konfigurationsänderungen, die laufende Sessions nicht unterbrechen sollen (Filteränderungen, statische Routenergänzungen), verwenden Sie:

sudo birdc reload upstream1

Dies wendet Import/Export-Filter erneut auf bestehende Routen an, ohne die TCP-Session abzubauen.

Wie verifizieren Sie Ihre BGP-Session und Route-Announcements?

Nach dem Anwenden der Konfiguration verwenden Sie birdc, um zu prüfen, ob die Session aufgebaut ist und Routen annonciert werden. Diese Befehle sind Ihre wichtigsten Debugging-Werkzeuge.

Befehl Was er zeigt Wann verwenden
show protocols Protokollstatus-Übersicht (Established, Active, etc.) Erste Prüfung nach Konfigurationsänderung
show protocols all upstream1 Vollständige Session-Details, Zähler, Timer Debugging einer bestimmten Session
show route Alle Routen in BIRDs Tabelle Empfangene und statische Routen verifizieren
show route export upstream1 Routen, die an den Upstream gesendet werden Bestätigen, dass Ihre Prefixe annonciert werden
show route for 203.0.113.0/24 Beste Route für ein bestimmtes Prefix Pfadauswahl nachverfolgen
show route protocol static_v4 Routen aus einem bestimmten Protokoll Statische Routen verifizieren

Session-Status prüfen

sudo birdc show protocols

Erwartete Ausgabe im funktionierenden Zustand:

BIRD 2.18 ready.
Name       Proto      Table      State  Since         Info
device1    Device     ---        up     12:00:00.000
direct1    Direct     ---        up     12:00:00.000
kernel1    Kernel     master4    up     12:00:00.000
kernel2    Kernel     master6    up     12:00:00.000
static_v4  Static     master4    up     12:00:00.000
static_v6  Static     master6    up     12:00:00.000
upstream1  BGP        ---        up     12:00:05.000  Established

Der Status Established bedeutet, dass die BGP-Session aktiv ist und Routen ausgetauscht werden können. Alles andere deutet auf ein Problem hin.

Exportierte Routen prüfen

sudo birdc show route export upstream1

BIRD 2.18 ready.
Table master4:
203.0.113.0/24       unicast [static_v4 12:00:00.000] * (200)
	dev dummy0
Table master6:
2001:db8:1000::/48   unicast [static_v6 12:00:00.000] * (200)
	dev dummy0

Ihre IPv4- und IPv6-Prefixe sollten hier beide erscheinen. Wenn ein Prefix fehlt, lehnt der Export-Filter es ab.

Vollständige Session-Details prüfen

sudo birdc show protocols all upstream1

Achten Sie auf die Zeile Routes::

  Routes:         2 imported, 0 filtered, 2 exported, 0 preferred

Der Wert exported sollte der Anzahl der Prefixe entsprechen, die Sie annoncieren möchten.

Von aussen verifizieren

Verwenden Sie ein öffentliches Looking Glass, um zu bestätigen, dass Ihr Prefix im Internet sichtbar ist. NLNOG Looking Glass oder PeeringDB können helfen. Suchen Sie nach Ihrem Prefix und verifizieren Sie:

  • Die Origin-AS stimmt mit Ihrer überein
  • Der AS-Path führt über Ihren Upstream
  • Kein RPKI-Invalid-Status erscheint

Prüfen Sie auch die Kernel-Routing-Tabelle:

ip route show | grep 203.0.113
ip -6 route show | grep 2001:db8:1000

Sie sollten Routen sehen, die auf das dummy0-Interface zeigen.

Wie beheben Sie häufige BIRD2-BGP-Probleme?

Die meisten BGP-Probleme fallen in wenige Kategorien. Prüfen Sie diese der Reihe nach.

BGP-Session-Statusreferenz

Status Bedeutung Was prüfen
Idle BIRD versucht keine Verbindung Konfigurationsfehler, Protokoll deaktiviert
Connect TCP-Verbindung wird aufgebaut Firewall blockiert Port 179, falsche Neighbor-IP
Active TCP-Verbindung fehlgeschlagen, neuer Versuch Peer nicht erreichbar, Firewall, falsche Source-Adresse
OpenSent TCP verbunden, wartet auf OPEN-Antwort MD5-Mismatch, falsche ASN auf Gegenseite
OpenConfirm OPEN empfangen, wartet auf KEEPALIVE Selten sichtbar, geht normalerweise schnell weiter
Established Session aktiv, Routenaustausch läuft Funktioniert

Session hängt in Connect oder Active

Das bedeutet, TCP kann Port 179 auf dem Peer nicht erreichen. Prüfen Sie:

# Can you reach the peer at all?
ping -c 3 198.51.100.1

# Is port 179 open on the peer?
nc -zv 198.51.100.1 179

# Are your nftables rules blocking outbound?
sudo nft list ruleset | grep 179

# Check BIRD logs
journalctl -u bird --since "5 minutes ago" --no-pager

Häufige Ursachen: falsche source address im BGP-Block, der Peer hat seine Seite noch nicht konfiguriert, oder Ihre Firewall blockiert ausgehende Verbindungen.

Session hängt in OpenSent

Die TCP-Verbindung funktioniert, aber die BGP-OPEN-Nachricht wird abgelehnt. Das ist fast immer ein MD5-Passwort-Mismatch. Prüfen Sie:

  1. Ihr password in bird.conf stimmt exakt mit dem überein, was der Provider Ihnen gegeben hat (Gross-/Kleinschreibung beachten, auf Leerzeichen am Ende achten)
  2. Beide Seiten stimmen bei der ASN überein

Prüfen Sie die Logs für Details:

journalctl -u bird | grep -i "error\|md5\|password"

Prefix erscheint nicht in show route export

Ihr Prefix existiert in BIRDs Tabelle, aber der Export-Filter akzeptiert es nicht. Debuggen Sie den Filter:

sudo birdc show route 203.0.113.0/24 all

Prüfen Sie die Route Source. Wenn dort [device1] oder [direct1] statt [static_v4] steht, ist die statische Route nicht korrekt konfiguriert. Der Export-Filter matched auf die Route, daher muss sie vom richtigen Protokoll stammen.

sudo birdc show route noexport upstream1

Dies zeigt Routen, die der Filter explizit abgelehnt hat. Wenn Ihr Prefix hier erscheint, hat die Filterlogik einen Fehler.

Prefix annonciert, aber nicht auf Looking Glass sichtbar

Ihr Export funktioniert, aber die Route propagiert nicht. Mögliche Ursachen:

  • Kein ROA-Record: Ihr Upstream oder dessen Peers filtern RPKI-invalide Routen. Publizieren Sie zuerst ROA-Records RPKI ROA für BGP: ROAs erstellen, Routen in BIRD2 und FRR validieren
  • IRR-Filtering: Ihr Upstream filtert anhand von IRR-Objekten (RIPE DB, RADB). Erstellen oder aktualisieren Sie Ihre route/route6-Objekte
  • Max-Prefix-Limit: Ihr Upstream hat möglicherweise ein Prefix-Limit konfiguriert. Kontaktieren Sie ihn, wenn Sie daran stoßen
  • Propagation Delay: BGP-Konvergenz dauert Minuten. Warten Sie 5-10 Minuten und prüfen Sie erneut

Logs lesen

BIRD loggt in das Systemjournal. Für Echtzeit-Fehlersuche:

journalctl -u bird -f

Für Ereignisse der letzten Stunde:

journalctl -u bird --since "1 hour ago" --no-pager

Suchen Sie nach Zeilen mit Error, BGP, session oder Received. Sie sagen Ihnen genau, was BIRD tut und was schiefgelaufen ist.

BIRD2 vs. BIRD 1.x: Migrationshinweise

Wenn Sie von BIRD 1.x migrieren, sind die wesentlichen Unterschiede:

  • Einzelner Daemon: BIRD2 ersetzt sowohl bird als auch bird6 durch einen einzigen Prozess
  • Channel-Syntax: IPv4 und IPv6 werden als Channels innerhalb von Protokollblöcken konfiguriert, nicht als separate Protokolle
  • Filter-Syntax: Weitgehend kompatibel, aber einige Funktionen haben neue Namen. Prüfen Sie die BIRD2-Dokumentation für die vollständige Filterreferenz
  • Konfigurationsdatei: Standardpfad geändert von /etc/bird/bird.conf und /etc/bird/bird6.conf zu einer einzigen /etc/bird/bird.conf
  • birdc-Socket: Ein einzelner Socket unter /run/bird/bird.ctl statt separater IPv4/IPv6-Sockets

Nächste Schritte

Mit Ihrer aufgebauten BGP-Session und annoncierten Prefixen gibt es einige Dinge, die Sie als Nächstes konfigurieren sollten:

Für den alternativen Routing-Daemon siehe FRRouting BGP-Konfiguration auf einem Linux VPS. Für die vollständige BYOIP-Reise beginnen Sie bei BGP und Bring Your Own IP auf einem VPS: Der vollständige Leitfaden.

Bereit, es selbst auszuprobieren?

Betreiben Sie BGP-Sessions auf Ihrem eigenen IP-Bereich mit Virtua.Cloud VPS. →