Dieses Tutorial beschreibt die Konfiguration von FRRouting (FRR) zur Ankündigung eigener IPv4- und IPv6-Präfixe per BGP von einem Linux VPS. Alle Befehle sind auf Debian 12 und Ubuntu 24.04 mit FRR 10.5 getestet.

Am Ende haben Sie eine laufende eBGP-Sitzung mit Ihrem Upstream-Provider, Dual-Stack-Präfixorigination über persistente Dummy-Interfaces, ein- und ausgehende Routenfilterung, GTSM-Sitzungssicherheit und nftables-Firewallregeln zum Schutz von TCP 179.

Falls Sie zwischen FRR und BIRD2 abwägen: Beide sind solide Optionen. FRR nutzt eine Cisco-ähnliche CLI (vtysh), die vertraut wirkt, wenn Sie mit IOS oder JunOS gearbeitet haben. BIRD2 verwendet eine deklarative Konfigurationsdatei. Diese Anleitung behandelt FRR. Für BIRD2 siehe BIRD2 BGP-Konfiguration auf einem Linux VPS.

Hintergrundwissen zum Mitbringen eigener IP-Adressen auf einen VPS finden Sie unter BGP und Bring Your Own IP auf einem VPS: Der vollständige Leitfaden.

Voraussetzungen

Bevor Sie beginnen, benötigen Sie:

Eine öffentliche ASN (Autonomous System Number). Falls Sie noch keine haben, siehe ASN bei der RIPE NCC registrieren: Ablauf, Kosten und Voraussetzungen.
Mindestens ein IPv4 /24 oder IPv6 /48 Präfix, das Ihrer ASN zugewiesen ist.
ROA-Objekte (Route Origin Authorization), erstellt im RPKI-Dashboard Ihres RIR. Siehe RPKI ROA für BGP: ROAs erstellen, Routen in BIRD2 und FRR validieren.
Einen Upstream-Provider, der eine BGP-Sitzung anbietet (IP-Transit oder Peering). Sie benötigen: die ASN des Providers, die Peer-IPv4- und IPv6-Adressen sowie ein vereinbartes MD5-Passwort (falls zutreffend).
Einen Linux VPS mit Debian 12 (Bookworm) oder Ubuntu 24.04 (Noble). Root- oder sudo-Zugang.

In dieser Anleitung ersetzen Sie die folgenden Platzhalter durch Ihre tatsächlichen Werte:

Platzhalter	Bedeutung	Beispiel
`YOUR_ASN`	Ihre AS-Nummer	`212345`
`PEER_ASN`	ASN des Upstream-Providers	`6939`
`PEER_IPV4`	BGP-Peer-IPv4 des Providers	`198.51.100.1`
`PEER_IPV6`	BGP-Peer-IPv6 des Providers	`2001:db8:1::1`
`YOUR_IPV4`	Ihre Seite des BGP-Peerings (IPv4)	`198.51.100.2`
`YOUR_IPV6`	Ihre Seite des BGP-Peerings (IPv6)	`2001:db8:1::2`
`YOUR_PREFIX_V4`	Ihr IPv4-Präfix	`203.0.113.0/24`
`YOUR_PREFIX_V6`	Ihr IPv6-Präfix	`2001:db8:abc::/48`
`MD5_PASSWORD`	Vereinbartes TCP-MD5-Passwort	(von Ihrem Provider)

Wie installiere ich FRRouting auf Debian 12 und Ubuntu 24.04?

Installieren Sie FRR aus dem offiziellen apt-Repository, um die aktuelle stabile Version (10.5.x, Stand März 2026) zu erhalten. Die Distributionspakete in Debian und Ubuntu liegen oft mehrere Hauptversionen zurück. Das offizielle Repository verfolgt den aktuellen Stable-Branch und unterstützt sowohl Bookworm als auch Noble.

GPG-Signaturschlüssel hinzufügen:

curl -s https://deb.frrouting.org/frr/keys.gpg | sudo tee /usr/share/keyrings/frrouting.gpg > /dev/null

Repository hinzufügen. Verwenden Sie frr-stable, um dem aktuellen Stable-Branch zu folgen:

FRRVER="frr-stable"
echo deb '[signed-by=/usr/share/keyrings/frrouting.gpg]' https://deb.frrouting.org/frr \
     $(lsb_release -s -c) $FRRVER | sudo tee /etc/apt/sources.list.d/frr.list

FRR und die Python-Tools installieren (nötig für frr-reload.py):

sudo apt update && sudo apt install -y frr frr-pythontools

Installierte Version prüfen:

sudo vtysh -c "show version" | head -1

Erwartete Ausgabe:

FRRouting 10.5.3 (<hostname>) on Linux(6.8.0-xxx-generic).

FRR wird als systemd-Service installiert. Aktivieren Sie ihn, damit er Neustarts überlebt, und starten Sie ihn sofort:

sudo systemctl enable --now frr

Prüfen, ob FRR läuft:

systemctl status frr

In der Ausgabe sollte active (running) stehen. FRR betreibt mehrere Daemons (zebra, bgpd etc.), die von einem einzelnen übergeordneten Prozess verwaltet werden.

Wie aktiviere ich den BGP-Daemon in FRR?

FRR liefert alle Protokoll-Daemons deaktiviert aus, mit Ausnahme von zebra. Sie müssen bgpd in der Daemons-Datei explizit aktivieren, bevor FRR einen BGP-Prozess startet. Die Daemons-Datei liegt unter /etc/frr/daemons.

Daemons-Datei bearbeiten:

sudo nano /etc/frr/daemons

Die Zeile bgpd finden und auf yes setzen:

bgpd=yes

Alle anderen Daemons (ospfd, isisd usw.) können auf no bleiben, sofern Sie sie nicht benötigen. Zebra ist immer aktiviert und verwaltet die Kernel-Routingtabelle.

Übersicht der Daemons:

Daemon	Aufgabe	Standard
`zebra`	Kernel-Routenverwaltung, Interface-Tracking	immer an
`bgpd`	BGP-Protokoll	`no`
`ospfd`	OSPFv2	`no`
`ospf6d`	OSPFv3 (IPv6)	`no`
`ripd`	RIP	`no`
`isisd`	IS-IS	`no`
`staticd`	Statische Routen über vtysh	`no`

FRR neu starten, um die Änderung zu übernehmen:

sudo systemctl restart frr

Prüfen, ob bgpd läuft:

sudo vtysh -c "show bgp summary"

Sie sollten % BGP instance not found sehen. Das ist erwartet: bgpd läuft, aber es wurde noch kein router bgp konfiguriert. Das kommt im nächsten Schritt.

vtysh-Grundlagen

vtysh ist die integrierte Shell von FRR. Sie bietet eine Cisco-ähnliche CLI zur Konfiguration aller FRR-Daemons über ein einziges Interface. Einige Grundlagen, bevor wir mit der Konfiguration beginnen.

vtysh aufrufen:

sudo vtysh

Sie befinden sich jetzt in der FRR-CLI. Der Prompt zeigt den Hostnamen. Die Modi, die Sie verwenden werden:

Modus	Aufrufen mit	Prompt	Zweck
Exec	(Standard)	`#`	Show-Befehle, Verifizierung
Config	`configure terminal`	`(config)#`	Globale Konfiguration
Router BGP	`router bgp ASN`	`(config-router)#`	BGP-Konfiguration
Address-family	`address-family ipv4 unicast`	`(config-router-af)#`	Per-AFI/SAFI-Konfiguration

Laufende Konfiguration auf Platte speichern:

write memory

Dies schreibt nach /etc/frr/frr.conf. FRR verwendet standardmäßig ein integriertes Konfigurationsmodell: Alle Daemon-Konfigurationen befinden sich in einer einzigen Datei.

vtysh mit exit oder end verlassen (end springt aus jedem Untermodus zurück in den Exec-Modus).

Wie konfiguriere ich eine BGP-Sitzung mit meinem Upstream-Provider?

Rufen Sie vtysh auf und wechseln Sie in den configure-terminal-Modus, um die BGP-Kernkonfiguration einzurichten. Damit wird der Router-Prozess erstellt, die Router-ID gesetzt, automatisches IPv4-Unicast deaktiviert (sodass Sie pro Nachbar genau kontrollieren, welche Adressfamilien aktiv sind) und der Upstream-Peer definiert.

sudo vtysh

configure terminal

router bgp YOUR_ASN
 bgp router-id YOUR_IPV4
 no bgp default ipv4-unicast

 neighbor PEER_IPV4 remote-as PEER_ASN
 neighbor PEER_IPV4 description Upstream-v4
 neighbor PEER_IPV4 password MD5_PASSWORD
 neighbor PEER_IPV4 ttl-security hops 1
 neighbor PEER_IPV4 soft-reconfiguration inbound

 neighbor PEER_IPV6 remote-as PEER_ASN
 neighbor PEER_IPV6 description Upstream-v6
 neighbor PEER_IPV6 password MD5_PASSWORD
 neighbor PEER_IPV6 ttl-security hops 1
 neighbor PEER_IPV6 soft-reconfiguration inbound

Was jede Direktive bewirkt:

bgp router-id: Ein 32-Bit-Identifikator, typischerweise Ihre primäre IPv4-Adresse. Muss im Peering eindeutig sein.
no bgp default ipv4-unicast: Verhindert, dass FRR automatisch IPv4-Unicast für jeden Nachbarn aktiviert. Sie aktivieren Adressfamilien explizit. Das ist Standardpraxis für Dual-Stack-Setups.
ttl-security hops 1: Aktiviert GTSM (RFC 5082). Erfordert, dass Pakete mit TTL 254 ankommen (ein Hop entfernt). Verwirft gefälschte BGP-Pakete von entfernten Quellen. Kann nicht zusammen mit ebgp-multihop verwendet werden.
password: Setzt TCP-MD5-Authentifizierung (RFC 2385). Beide Seiten müssen denselben String verwenden. Nicht alle Provider nutzen dies. Weglassen, wenn Ihr Provider es nicht verlangt.
soft-reconfiguration inbound: Speichert empfangene Routen im Speicher, sodass Sie Richtlinienänderungen ohne Sitzungsreset anwenden können. Verbraucht mehr RAM, vermeidet aber Session-Flaps bei Filteränderungen.

Verlassen Sie den Config-Modus noch nicht. Als Nächstes fügen wir Adressfamilien und Filter hinzu.

Wie kündige ich meine eigenen IPv4- und IPv6-Präfixe an?

Präfixorigination in FRR erfordert zwei Dinge: ein network-Statement in der BGP-Konfiguration und das Präfix in der Kernel-Routingtabelle. Der einfachste Weg, das Präfix in den Kernel zu injizieren, ist über ein Dummy-Interface. Wir richten zuerst die Dummy-Interfaces ein und konfigurieren dann die BGP-Adressfamilien.

Wie erstelle ich persistente Dummy-Interfaces für die Präfixorigination?

Ein Dummy-Interface ist ein Loopback-ähnliches Interface, das eine IP-Adresse hält, ohne an physische Hardware gebunden zu sein. FRRs zebra übernimmt Routen aus dem Kernel. Wenn Ihr Präfix einem Dummy-Interface zugewiesen ist, installiert zebra die Route und bgpd kann sie ankündigen.

Erstellen Sie die Dummy-Interfaces mit systemd-networkd, damit sie über Neustarts hinweg bestehen bleiben.

Netdev-Datei erstellen:

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

Network-Datei mit Ihren Präfixen erstellen:

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

[Address]
Address=YOUR_PREFIX_V4

[Address]
Address=YOUR_PREFIX_V6
EOF

Für die IPv4-Adresse verwenden Sie die erste nutzbare IP in Ihrem Präfix (z.B. 203.0.113.1/24). Für IPv6 verwenden Sie eine beliebige Adresse innerhalb Ihres Präfixes (z.B. 2001:db8:abc::1/48).

systemd-networkd aktivieren (falls noch nicht aktiv) und neu starten:

sudo systemctl enable --now systemd-networkd
sudo systemctl restart systemd-networkd

Prüfen, ob das Dummy-Interface aktiv ist:

ip addr show dummy-bgp

Sie sollten sowohl Ihre IPv4- als auch IPv6-Adressen am Interface zugewiesen sehen.

Prüfen, ob die Routen im Kernel vorhanden sind:

ip route show dev dummy-bgp
ip -6 route show dev dummy-bgp

Address-Family-Konfiguration

Zurück im vtysh-Config-Modus (oder erneut aufrufen mit sudo vtysh, dann configure terminal, dann router bgp YOUR_ASN):

 address-family ipv4 unicast
  network YOUR_PREFIX_V4
  neighbor PEER_IPV4 activate
  neighbor PEER_IPV4 route-map EXPORT-V4 out
  neighbor PEER_IPV4 route-map IMPORT-V4 in
  neighbor PEER_IPV4 prefix-list BOGONS-V4 in
  neighbor PEER_IPV4 maximum-prefix 500000 80
 exit-address-family

 address-family ipv6 unicast
  network YOUR_PREFIX_V6
  neighbor PEER_IPV6 activate
  neighbor PEER_IPV6 route-map EXPORT-V6 out
  neighbor PEER_IPV6 route-map IMPORT-V6 in
  neighbor PEER_IPV6 prefix-list BOGONS-V6 in
  neighbor PEER_IPV6 maximum-prefix 200000 80
 exit-address-family

Details:

activate aktiviert den Nachbarn innerhalb dieser Adressfamilie. Erforderlich, weil wir bgp default ipv4-unicast deaktiviert haben.
network weist bgpd an, dieses Präfix zu originieren. Das Präfix muss in der Kernel-Routingtabelle existieren (zebra übernimmt es vom Dummy-Interface).
maximum-prefix 500000 80 beendet die Sitzung, wenn der Peer mehr als 500.000 IPv4-Präfixe sendet. Die 80 erzeugt eine Warnung bei 80% (400.000). Passen Sie den Wert an, je nachdem, ob Sie eine Full Table oder nur eine Default-Route empfangen. Für eine Sitzung mit nur Default-Route setzen Sie den Wert auf 10.
Die Route-Map- und Prefix-List-Verweise zeigen auf Filter, die wir als Nächstes definieren.

Wie filtere ich BGP-Routen mit Prefix-Listen und Route-Maps?

Routenfilterung ist nicht optional. Ohne ausgehende Filter könnte eine Fehlkonfiguration Präfixe leaken, die Ihnen nicht gehören. Ohne eingehende Filter akzeptieren Sie Bogon-Routen und leiten potenziell Traffic ins Nichts. Dies folgt RFC 7454 (BGP Operations and Security).

Für einen tieferen Einblick in Filterstrategien, siehe BGP Route Filtering: Prefix-Listen, AS-Path-Filter, Bogon-Ablehnung und GTSM.

Ausgehende Prefix-Listen

Kündigen Sie nur Präfixe an, die Ihnen gehören. Nichts anderes.

ip prefix-list OUR-PREFIXES-V4 seq 10 permit YOUR_PREFIX_V4
ip prefix-list OUR-PREFIXES-V4 seq 999 deny any

ipv6 prefix-list OUR-PREFIXES-V6 seq 10 permit YOUR_PREFIX_V6
ipv6 prefix-list OUR-PREFIXES-V6 seq 999 deny any

Wenn Sie mehrere Präfixe ankündigen, fügen Sie weitere permit-Zeilen mit aufsteigenden Sequenznummern hinzu.

Eingehende Bogon-Prefix-Listen

Präfixe ablehnen, die niemals im öffentlichen Internet auftauchen sollten. Diese Liste folgt dem NLNOG BGP Filter Guide:

ip prefix-list BOGONS-V4 seq 10 deny 0.0.0.0/8 le 32
ip prefix-list BOGONS-V4 seq 20 deny 10.0.0.0/8 le 32
ip prefix-list BOGONS-V4 seq 30 deny 100.64.0.0/10 le 32
ip prefix-list BOGONS-V4 seq 40 deny 127.0.0.0/8 le 32
ip prefix-list BOGONS-V4 seq 50 deny 169.254.0.0/16 le 32
ip prefix-list BOGONS-V4 seq 60 deny 172.16.0.0/12 le 32
ip prefix-list BOGONS-V4 seq 70 deny 192.0.2.0/24 le 32
ip prefix-list BOGONS-V4 seq 80 deny 192.88.99.0/24 le 32
ip prefix-list BOGONS-V4 seq 90 deny 192.168.0.0/16 le 32
ip prefix-list BOGONS-V4 seq 100 deny 198.18.0.0/15 le 32
ip prefix-list BOGONS-V4 seq 110 deny 198.51.100.0/24 le 32
ip prefix-list BOGONS-V4 seq 120 deny 203.0.113.0/24 le 32
ip prefix-list BOGONS-V4 seq 130 deny 224.0.0.0/4 le 32
ip prefix-list BOGONS-V4 seq 140 deny 240.0.0.0/4 le 32
ip prefix-list BOGONS-V4 seq 999 permit 0.0.0.0/0 le 24

ipv6 prefix-list BOGONS-V6 seq 10 deny ::/8 le 128
ipv6 prefix-list BOGONS-V6 seq 20 deny 100::/64 le 128
ipv6 prefix-list BOGONS-V6 seq 30 deny 2001:2::/48 le 128
ipv6 prefix-list BOGONS-V6 seq 40 deny 2001:10::/28 le 128
ipv6 prefix-list BOGONS-V6 seq 50 deny 2001:db8::/32 le 128
ipv6 prefix-list BOGONS-V6 seq 60 deny 3fff::/20 le 128
ipv6 prefix-list BOGONS-V6 seq 70 deny 2002::/16 le 128
ipv6 prefix-list BOGONS-V6 seq 80 deny 3ffe::/16 le 128
ipv6 prefix-list BOGONS-V6 seq 90 deny 5f00::/16 le 128
ipv6 prefix-list BOGONS-V6 seq 100 deny fc00::/7 le 128
ipv6 prefix-list BOGONS-V6 seq 110 deny fe80::/10 le 128
ipv6 prefix-list BOGONS-V6 seq 120 deny fec0::/10 le 128
ipv6 prefix-list BOGONS-V6 seq 130 deny ff00::/8 le 128
ipv6 prefix-list BOGONS-V6 seq 999 permit ::/0 le 48

Die letzte permit-Zeile in jeder Liste akzeptiert alles, was nicht explizit abgelehnt wurde. Das le 24 (IPv4) und le 48 (IPv6) lehnen zu spezifische Präfixe ab: Niemand sollte ein /25 oder länger bei IPv4 ankündigen, oder ein /49 oder länger bei IPv6.

Route-Maps

Route-Maps verbinden die Prefix-Listen und bieten Ihnen eine Stelle, um später weitere Richtlinien hinzuzufügen (Local-Pref, Communities, AS-Path-Prepending).

route-map EXPORT-V4 permit 10
 match ip address prefix-list OUR-PREFIXES-V4

route-map EXPORT-V6 permit 10
 match ipv6 address prefix-list OUR-PREFIXES-V6

route-map IMPORT-V4 permit 10
 match ip address prefix-list BOGONS-V4

route-map IMPORT-V6 permit 10
 match ipv6 address prefix-list BOGONS-V6

Die Export-Route-Maps erlauben nur Ihre eigenen Präfixe. Alles andere wird implizit abgelehnt (FRR lehnt alles ab, was nicht explizit durch eine Route-Map gematcht wird). Die Import-Route-Maps leiten den Verkehr durch die Bogon-Prefix-Liste, die die Bogon-Bereiche ablehnt und alles andere erlaubt.

Konfiguration speichern:

write memory

Prüfen, ob die Konfiguration geschrieben wurde:

ls -la /etc/frr/frr.conf

Die Datei sollte einen aktuellen Änderungszeitstempel zeigen, mit dem Besitzer frr:frr und den Berechtigungen 640.

Wie sichere ich die BGP-Sitzung ab und schütze TCP 179?

BGP läuft auf TCP-Port 179. Jeder Host im Internet kann versuchen, sich damit zu verbinden. Über das bereits konfigurierte GTSM und die MD5-Authentifizierung hinaus benötigen Sie Firewallregeln, die TCP 179 auf Ihre Peer-Adressen beschränken.

nftables-Firewallregeln

nftables installieren, falls noch nicht vorhanden. Auf minimalen Ubuntu-24.04-Installationen ist es standardmäßig nicht enthalten:

sudo apt install -y nftables

Verzeichnis /etc/nftables.d/ für Drop-in-Konfigurationsdateien erstellen und eine Include-Direktive zur Haupt-nftables-Konfiguration hinzufügen, damit benutzerdefinierte Regeln Neustarts überleben:

sudo mkdir -p /etc/nftables.d
echo 'include "/etc/nftables.d/*.conf"' | sudo tee -a /etc/nftables.conf

Dedizierte nftables-Konfigurationsdatei für BGP erstellen:

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

    set bgp_peers_v6 {
        type ipv6_addr
        elements = { PEER_IPV6 }
    }

    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

        # Allow BGP return traffic (our side initiates)
        tcp sport 179 ip saddr @bgp_peers_v4 accept
        tcp sport 179 ip6 saddr @bgp_peers_v6 accept

        # Drop all other BGP attempts
        tcp dport 179 drop
        tcp sport 179 drop
    }
}
EOF

Falls Sie bereits eine nftables-Konfiguration haben, integrieren Sie diese Regeln in Ihre bestehende Input-Chain, anstatt eine separate Tabelle zu erstellen. Der obige Ansatz ist in sich geschlossen und stört andere Firewallregeln nicht.

Um mehrere Peers hinzuzufügen, ergänzen Sie deren IPs im elements-Set:

elements = { 198.51.100.1, 203.0.113.1 }

nftables aktivieren, damit Regeln über Neustarts hinweg bestehen, dann neu laden:

sudo systemctl enable --now nftables
sudo systemctl reload nftables

Prüfen, ob die Regeln geladen sind:

sudo nft list table inet bgp-filter

Sie sollten Ihre Peer-IPs in den Sets und die Chain-Regeln in der Auflistung sehen.

Sicherheitsübersicht

Schutzmechanismus	Wirkung	Konfigurationsort
GTSM (`ttl-security hops 1`)	Verwirft BGP-Pakete, die nicht von einem direkt verbundenen Peer stammen	vtysh, pro Nachbar
TCP MD5 (`password`)	Authentifiziert TCP-Segmente, verhindert RST-Injection	vtysh, pro Nachbar
Prefix-List (ausgehend)	Kündigt nur eigene Präfixe an	vtysh, Route-Map
Prefix-List (eingehend)	Lehnt Bogon-/reservierte Bereiche ab	vtysh, pro Nachbar
`maximum-prefix`	Beendet die Sitzung, wenn der Peer zu viele Routen sendet	vtysh, pro Address-Family
nftables	Beschränkt TCP 179 auf bekannte Peer-IPs	`/etc/nftables.d/bgp.conf`

Wie verifiziere ich die BGP-Sitzung und Präfixpropagation?

Nach dem Speichern der Konfiguration mit write memory sollte die BGP-Sitzung beginnen, sich aufzubauen. Die Verifizierung erfolgt in drei Stufen: lokale vtysh-Prüfungen, Kernel-Routingtabelle und externe Looking Glasses.

vtysh-Verifizierungsbefehle

Befehl	Anzeige
`show bgp summary`	Alle Peers, deren Status, empfangene Präfixe
`show bgp ipv4 unicast`	IPv4-BGP-Tabelle
`show bgp ipv6 unicast`	IPv6-BGP-Tabelle
`show bgp ipv4 unicast neighbors PEER_IPV4 advertised-routes`	Was Sie an den Peer senden
`show bgp ipv4 unicast neighbors PEER_IPV4 received-routes`	Was der Peer Ihnen sendet (erfordert `soft-reconfiguration inbound`)
`show ip bgp neighbors PEER_IPV4`	Detaillierter Nachbarstatus, Uptime, Capabilities

Sitzungsstatus prüfen:

sudo vtysh -c "show bgp summary"

Erwartete Ausgabe (gekürzt):

IPv4 Unicast Summary:
BGP router identifier YOUR_IPV4, local AS number YOUR_ASN, vrf default
Neighbor        V    AS   MsgRcvd  MsgSent  TblVer   InQ  OutQ  Up/Down  State/PfxRcd
PEER_IPV4       4  PEER_ASN   1205     843       0      0     0 01:23:45        12

Beachten Sie die Spalte State/PfxRcd. Eine Zahl bedeutet, dass die Sitzung aufgebaut ist und so viele Präfixe empfangen wurden. Falls Sie Active, Connect oder OpenSent sehen, ist die Sitzung noch nicht aktiv. Lesen Sie den Abschnitt zur Fehlerbehebung weiter unten.

Prüfen, ob Ihr Präfix angekündigt wird:

sudo vtysh -c "show bgp ipv4 unicast neighbors PEER_IPV4 advertised-routes"

Ihr Präfix sollte in der Ausgabe erscheinen. Falls nicht, prüfen Sie:

Ob das Dummy-Interface aktiv ist (ip addr show dummy-bgp).
Ob die Route im Kernel existiert (ip route show YOUR_PREFIX_V4).
Ob das network-Statement exakt zum Präfix und der Maske passt.

Externe Verifizierung

Prüfen Sie von außerhalb Ihres Netzwerks, ob das Präfix im Internet sichtbar ist.

Von Ihrem lokalen Rechner (nicht dem VPS):

traceroute YOUR_PREFIX_V4_FIRST_IP

Nutzen Sie bgp.tools, um Ihr Präfix nachzuschlagen und zu prüfen:

Ob die Origin-AS mit Ihrer ASN übereinstimmt.
Ob der ROA-Status "Valid" zeigt (nicht "Unknown" oder "Invalid").
Ob das Präfix von mehreren Standorten aus sichtbar ist.

Sie können auch das RIPE RIS Looking Glass abfragen:

curl -s "https://stat.ripe.net/data/looking-glass/data.json?resource=YOUR_PREFIX_V4" | python3 -m json.tool | head -50

Konfiguration persistieren

FRR speichert seine Konfiguration in /etc/frr/frr.conf, wenn Sie write memory in vtysh ausführen. Solange der FRR-Service aktiviert ist (systemctl enable frr), liest er diese Datei beim Booten.

Beide Persistenzmechanismen gegenprüfen:

sudo systemctl is-enabled frr

Sollte enabled zurückgeben.

sudo vtysh -c "show running-config" | head -5

Mit der gespeicherten Datei vergleichen:

head -5 /etc/frr/frr.conf

Beide sollten übereinstimmen. Falls sie abweichen, führen Sie erneut write memory aus.

Das Dummy-Interface bleibt durch systemd-networkd bestehen (früher konfiguriert). Prüfen:

sudo systemctl is-enabled systemd-networkd

Vollständige kommentierte frr.conf

Hier ist eine vollständige Beispielkonfiguration als Referenz. Ersetzen Sie alle Platzhalter durch Ihre Werte.

frr version 10.5.3
frr defaults traditional
hostname bgp-vps
log syslog informational
!
! --- Prefix-lists: outbound (only our prefixes) ---
ip prefix-list OUR-PREFIXES-V4 seq 10 permit 203.0.113.0/24
ip prefix-list OUR-PREFIXES-V4 seq 999 deny any
!
ipv6 prefix-list OUR-PREFIXES-V6 seq 10 permit 2001:db8:abc::/48
ipv6 prefix-list OUR-PREFIXES-V6 seq 999 deny any
!
! --- Prefix-lists: inbound bogon filters ---
ip prefix-list BOGONS-V4 seq 10 deny 0.0.0.0/8 le 32
ip prefix-list BOGONS-V4 seq 20 deny 10.0.0.0/8 le 32
ip prefix-list BOGONS-V4 seq 30 deny 100.64.0.0/10 le 32
ip prefix-list BOGONS-V4 seq 40 deny 127.0.0.0/8 le 32
ip prefix-list BOGONS-V4 seq 50 deny 169.254.0.0/16 le 32
ip prefix-list BOGONS-V4 seq 60 deny 172.16.0.0/12 le 32
ip prefix-list BOGONS-V4 seq 70 deny 192.0.2.0/24 le 32
ip prefix-list BOGONS-V4 seq 80 deny 192.88.99.0/24 le 32
ip prefix-list BOGONS-V4 seq 90 deny 192.168.0.0/16 le 32
ip prefix-list BOGONS-V4 seq 100 deny 198.18.0.0/15 le 32
ip prefix-list BOGONS-V4 seq 110 deny 198.51.100.0/24 le 32
ip prefix-list BOGONS-V4 seq 120 deny 203.0.113.0/24 le 32
ip prefix-list BOGONS-V4 seq 130 deny 224.0.0.0/4 le 32
ip prefix-list BOGONS-V4 seq 140 deny 240.0.0.0/4 le 32
ip prefix-list BOGONS-V4 seq 999 permit 0.0.0.0/0 le 24
!
ipv6 prefix-list BOGONS-V6 seq 10 deny ::/8 le 128
ipv6 prefix-list BOGONS-V6 seq 20 deny 100::/64 le 128
ipv6 prefix-list BOGONS-V6 seq 30 deny 2001:2::/48 le 128
ipv6 prefix-list BOGONS-V6 seq 40 deny 2001:10::/28 le 128
ipv6 prefix-list BOGONS-V6 seq 50 deny 2001:db8::/32 le 128
ipv6 prefix-list BOGONS-V6 seq 60 deny 3fff::/20 le 128
ipv6 prefix-list BOGONS-V6 seq 70 deny 2002::/16 le 128
ipv6 prefix-list BOGONS-V6 seq 80 deny 3ffe::/16 le 128
ipv6 prefix-list BOGONS-V6 seq 90 deny 5f00::/16 le 128
ipv6 prefix-list BOGONS-V6 seq 100 deny fc00::/7 le 128
ipv6 prefix-list BOGONS-V6 seq 110 deny fe80::/10 le 128
ipv6 prefix-list BOGONS-V6 seq 120 deny fec0::/10 le 128
ipv6 prefix-list BOGONS-V6 seq 130 deny ff00::/8 le 128
ipv6 prefix-list BOGONS-V6 seq 999 permit ::/0 le 48
!
! --- Route-maps ---
route-map EXPORT-V4 permit 10
 match ip address prefix-list OUR-PREFIXES-V4
!
route-map EXPORT-V6 permit 10
 match ipv6 address prefix-list OUR-PREFIXES-V6
!
route-map IMPORT-V4 permit 10
 match ip address prefix-list BOGONS-V4
!
route-map IMPORT-V6 permit 10
 match ipv6 address prefix-list BOGONS-V6
!
! --- BGP configuration ---
router bgp 212345
 bgp router-id 198.51.100.2
 no bgp default ipv4-unicast
 !
 ! IPv4 peer
 neighbor 198.51.100.1 remote-as 6939
 neighbor 198.51.100.1 description Upstream-v4
 neighbor 198.51.100.1 password SECRET
 neighbor 198.51.100.1 ttl-security hops 1
 neighbor 198.51.100.1 soft-reconfiguration inbound
 !
 ! IPv6 peer
 neighbor 2001:db8:1::1 remote-as 6939
 neighbor 2001:db8:1::1 description Upstream-v6
 neighbor 2001:db8:1::1 password SECRET
 neighbor 2001:db8:1::1 ttl-security hops 1
 neighbor 2001:db8:1::1 soft-reconfiguration inbound
 !
 address-family ipv4 unicast
  network 203.0.113.0/24
  neighbor 198.51.100.1 activate
  neighbor 198.51.100.1 route-map EXPORT-V4 out
  neighbor 198.51.100.1 route-map IMPORT-V4 in
  neighbor 198.51.100.1 prefix-list BOGONS-V4 in
  neighbor 198.51.100.1 maximum-prefix 500000 80
 exit-address-family
 !
 address-family ipv6 unicast
  network 2001:db8:abc::/48
  neighbor 2001:db8:1::1 activate
  neighbor 2001:db8:1::1 route-map EXPORT-V6 out
  neighbor 2001:db8:1::1 route-map IMPORT-V6 in
  neighbor 2001:db8:1::1 prefix-list BOGONS-V6 in
  neighbor 2001:db8:1::1 maximum-prefix 200000 80
 exit-address-family
!

Fehlerbehebung

BGP-Sitzung hängt im Status Active oder Connect

Die Sitzung versucht sich aufzubauen, aber TCP 179 kann keine Verbindung herstellen. Prüfen Sie in dieser Reihenfolge:

Firewall: Können Sie den Peer auf TCP 179 erreichen?
```
sudo nft list ruleset | grep 179
```
Peer-IP: Ist die Nachbar-IP korrekt? Tippfehler sind die häufigste Ursache.
```
sudo vtysh -c "show bgp neighbors PEER_IPV4" | grep "BGP state"
```
MD5-Mismatch: Bei Verwendung von TCP MD5 müssen beide Seiten exakt denselben Passwort-String haben. Es gibt keine hilfreiche Fehlermeldung dafür. Die Sitzung baut sich stillschweigend nicht auf.
GTSM: Wenn ttl-security hops 1 gesetzt ist, aber der Peer mehrere Hops entfernt ist (durch NAT oder Tunnel), schlägt die TTL-Prüfung fehl. Entfernen Sie ttl-security und verwenden Sie stattdessen ebgp-multihop für Multi-Hop-Sitzungen.

Präfix extern nicht sichtbar

Ihre Sitzung ist aufgebaut, aber das Präfix erscheint nicht auf Looking Glasses.

Angekündigte Routen prüfen:
```
sudo vtysh -c "show bgp ipv4 unicast neighbors PEER_IPV4 advertised-routes"
```
Falls Ihr Präfix nicht aufgelistet ist, blockiert der ausgehende Filter es. Prüfen Sie, ob die Prefix-List exakt zu Ihrem Präfix passt.
Kernel-Route prüfen:
```
ip route show YOUR_PREFIX_V4
```
Falls fehlend, ist das Dummy-Interface nicht aktiv oder falsch konfiguriert.
ROA-Validität prüfen: Wenn Ihre ROA fehlt oder inkorrekt ist, verwerfen RPKI-validierende Netzwerke Ihre Ankündigung. Prüfen Sie bei RIPE RPKI Validator.

Logs lesen

FRR loggt standardmäßig nach syslog. Um BGP-spezifische Ereignisse zu verfolgen:

journalctl -u frr -f --grep="bgpd"

Für ausführlichere Ausgabe aktivieren Sie Debug temporär in vtysh:

debug bgp updates
debug bgp keepalives

Danach wieder deaktivieren (die Ausgabe ist sehr ausführlich):

no debug bgp updates
no debug bgp keepalives

Nächste Schritte

RPKI-Validierung hinzufügen: Konfigurieren Sie FRRs eingebaute RPKI-Unterstützung, um eingehende Routen gegen ROA-Daten zu validieren. Siehe RPKI ROA für BGP: ROAs erstellen, Routen in BIRD2 und FRR validieren.
Erweiterte Filterung: Erstellen Sie granularere Route-Maps mit Community-Matching, AS-Path-Filtern und Local-Preference-Tuning. Siehe BGP Route Filtering: Prefix-Listen, AS-Path-Filter, Bogon-Ablehnung und GTSM.
Monitoring: Richten Sie BGP-Sitzungsüberwachung ein mit Tools wie Prometheus + bgp_exporter oder Zabbix SNMP Traps, um Benachrichtigungen zu erhalten, wenn eine Sitzung ausfällt.