FRRouting BGP-Konfiguration auf einem Linux VPS

12 Min. Lesezeit·Matthieu|

Schritt-fuer-Schritt-Anleitung zur FRRouting BGP-Einrichtung fuer die Ankuendigung eigener IPv4- und IPv6-Praefix von einem Linux VPS. Behandelt Installation, vtysh-Konfiguration, Prefix-Listen, Route-Maps, GTSM und nftables-Firewallregeln.

Dieses Tutorial beschreibt die Konfiguration von FRRouting (FRR) zur Ankuendigung eigener IPv4- und IPv6-Praefixe 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-Praefixorigination ueber persistente Dummy-Interfaces, ein- und ausgehende Routenfilterung, GTSM-Sitzungssicherheit und nftables-Firewallregeln zum Schutz von TCP 179.

Falls Sie zwischen FRR und BIRD2 abwaegen: Beide sind solide Optionen. FRR nutzt eine Cisco-aehnliche CLI (vtysh), die vertraut wirkt, wenn Sie mit IOS oder JunOS gearbeitet haben. BIRD2 verwendet eine deklarative Konfigurationsdatei. Diese Anleitung behandelt FRR. Fuer BIRD2 siehe BIRD2 BGP Configuration on a Linux VPS.

Hintergrundwissen zum Mitbringen eigener IP-Adressen auf einen VPS finden Sie unter BGP: Bring Your Own IP to a VPS.

Voraussetzungen

Bevor Sie beginnen, benoetigen Sie:

  • Eine oeffentliche ASN (Autonomous System Number). Falls Sie noch keine haben, siehe Register an ASN at RIPE NCC.
  • Mindestens ein IPv4 /24 oder IPv6 /48 Praefix, das Ihrer ASN zugewiesen ist.
  • ROA-Objekte (Route Origin Authorization), erstellt im RPKI-Dashboard Ihres RIR. Siehe .
  • Einen Upstream-Provider, der eine BGP-Sitzung anbietet (IP-Transit oder Peering). Sie benoetigen: 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 tatsaechlichen 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-Praefix 203.0.113.0/24
YOUR_PREFIX_V6 Ihr IPv6-Praefix 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 Maerz 2026) zu erhalten. Die Distributionspakete in Debian und Ubuntu liegen oft mehrere Hauptversionen zurueck. Das offizielle Repository verfolgt den aktuellen Stable-Branch und unterstuetzt sowohl Bookworm als auch Noble.

GPG-Signaturschluessel hinzufuegen:

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

Repository hinzufuegen. 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 (noetig fuer frr-reload.py):

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

Installierte Version pruefen:

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 ueberlebt, und starten Sie ihn sofort:

sudo systemctl enable --now frr

Pruefen, ob FRR laeuft:

systemctl status frr

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

Wie aktiviere ich den BGP-Daemon in FRR?

FRR liefert alle Protokoll-Daemons deaktiviert aus, mit Ausnahme von zebra. Sie muessen 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.) koennen auf no bleiben, sofern Sie sie nicht benoetigen. Zebra ist immer aktiviert und verwaltet die Kernel-Routingtabelle.

Uebersicht 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 ueber vtysh no

FRR neu starten, um die Aenderung zu uebernehmen:

sudo systemctl restart frr

Pruefen, ob bgpd laeuft:

sudo vtysh -c "show bgp summary"

Sie sollten % BGP instance not found sehen. Das ist erwartet: bgpd laeuft, aber es wurde noch kein router bgp konfiguriert. Das kommt im naechsten Schritt.

vtysh-Grundlagen

vtysh ist die integrierte Shell von FRR. Sie bietet eine Cisco-aehnliche CLI zur Konfiguration aller FRR-Daemons ueber 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 standardmaessig ein integriertes Konfigurationsmodell: Alle Daemon-Konfigurationen befinden sich in einer einzigen Datei.

vtysh mit exit oder end verlassen (end springt aus jedem Untermodus zurueck 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 primaere IPv4-Adresse. Muss im Peering eindeutig sein.
  • no bgp default ipv4-unicast: Verhindert, dass FRR automatisch IPv4-Unicast fuer jeden Nachbarn aktiviert. Sie aktivieren Adressfamilien explizit. Das ist Standardpraxis fuer Dual-Stack-Setups.
  • ttl-security hops 1: Aktiviert GTSM (RFC 5082). Erfordert, dass Pakete mit TTL 254 ankommen (ein Hop entfernt). Verwirft gefaelschte BGP-Pakete von entfernten Quellen. Kann nicht zusammen mit ebgp-multihop verwendet werden.
  • password: Setzt TCP-MD5-Authentifizierung (RFC 2385). Beide Seiten muessen 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 Richtlinienaenderungen ohne Sitzungsreset anwenden koennen. Verbraucht mehr RAM, vermeidet aber Session-Flaps bei Filteraenderungen.

Verlassen Sie den Config-Modus noch nicht. Als Naechstes fuegen wir Adressfamilien und Filter hinzu.

Wie kuendige ich meine eigenen IPv4- und IPv6-Praefixe an?

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

Wie erstelle ich persistente Dummy-Interfaces fuer die Praefixorigination?

Ein Dummy-Interface ist ein Loopback-aehnliches Interface, das eine IP-Adresse haelt, ohne an physische Hardware gebunden zu sein. FRRs zebra uebernimmt Routen aus dem Kernel. Wenn Ihr Praefix einem Dummy-Interface zugewiesen ist, installiert zebra die Route und bgpd kann sie ankuendigen.

Erstellen Sie die Dummy-Interfaces mit systemd-networkd, damit sie ueber 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 Praefixen 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

Fuer die IPv4-Adresse verwenden Sie die erste nutzbare IP in Ihrem Praefix (z.B. 203.0.113.1/24). Fuer IPv6 verwenden Sie eine beliebige Adresse innerhalb Ihres Praefixes (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

Pruefen, ob das Dummy-Interface aktiv ist:

ip addr show dummy-bgp

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

Pruefen, ob die Routen im Kernel vorhanden sind:

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

Address-Family-Konfiguration

Zurueck 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 Praefix zu originieren. Das Praefix muss in der Kernel-Routingtabelle existieren (zebra uebernimmt es vom Dummy-Interface).
  • maximum-prefix 500000 80 beendet die Sitzung, wenn der Peer mehr als 500.000 IPv4-Praefixe 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. Fuer 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 Naechstes definieren.

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

Routenfilterung ist nicht optional. Ohne ausgehende Filter koennte eine Fehlkonfiguration Praefixe leaken, die Ihnen nicht gehoeren. Ohne eingehende Filter akzeptieren Sie Bogon-Routen und leiten potenziell Traffic ins Nichts. Dies folgt RFC 7454 (BGP Operations and Security).

Fuer einen tieferen Einblick in Filterstrategien, siehe .

Ausgehende Prefix-Listen

Kuendigen Sie nur Praefixe an, die Ihnen gehoeren. 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 Praefixe ankuendigen, fuegen Sie weitere permit-Zeilen mit aufsteigenden Sequenznummern hinzu.

Eingehende Bogon-Prefix-Listen

Praefixe ablehnen, die niemals im oeffentlichen 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 Praefixe ab: Niemand sollte ein /25 oder laenger bei IPv4 ankuendigen, oder ein /49 oder laenger bei IPv6.

Route-Maps

Route-Maps verbinden die Prefix-Listen und bieten Ihnen eine Stelle, um spaeter weitere Richtlinien hinzuzufuegen (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 Praefixe. 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

Pruefen, ob die Konfiguration geschrieben wurde:

ls -la /etc/frr/frr.conf

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

Wie sichere ich die BGP-Sitzung ab und schuetze TCP 179?

BGP laeuft auf TCP-Port 179. Jeder Host im Internet kann versuchen, sich damit zu verbinden. Ueber das bereits konfigurierte GTSM und die MD5-Authentifizierung hinaus benoetigen Sie Firewallregeln, die TCP 179 auf Ihre Peer-Adressen beschraenken.

nftables-Firewallregeln

nftables installieren, falls noch nicht vorhanden. Auf minimalen Ubuntu-24.04-Installationen ist es standardmaessig nicht enthalten:

sudo apt install -y nftables

Verzeichnis /etc/nftables.d/ fuer Drop-in-Konfigurationsdateien erstellen und eine Include-Direktive zur Haupt-nftables-Konfiguration hinzufuegen, damit benutzerdefinierte Regeln Neustarts ueberleben:

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

Dedizierte nftables-Konfigurationsdatei fuer 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 stoert andere Firewallregeln nicht.

Um mehrere Peers hinzuzufuegen, ergaenzen Sie deren IPs im elements-Set:

elements = { 198.51.100.1, 203.0.113.1 }

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

sudo systemctl enable --now nftables
sudo systemctl reload nftables

Pruefen, 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.

Sicherheitsuebersicht

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) Kuendigt nur eigene Praefixe 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 Beschraenkt TCP 179 auf bekannte Peer-IPs /etc/nftables.d/bgp.conf

Wie verifiziere ich die BGP-Sitzung und Praefixpropagation?

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

vtysh-Verifizierungsbefehle

Befehl Anzeige
show bgp summary Alle Peers, deren Status, empfangene Praefixe
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 pruefen:

sudo vtysh -c "show bgp summary"

Erwartete Ausgabe (gekuerzt):

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 Praefixe empfangen wurden. Falls Sie Active, Connect oder OpenSent sehen, ist die Sitzung noch nicht aktiv. Lesen Sie den Abschnitt zur Fehlerbehebung weiter unten.

Pruefen, ob Ihr Praefix angekuendigt wird:

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

Ihr Praefix sollte in der Ausgabe erscheinen. Falls nicht, pruefen Sie:

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

Externe Verifizierung

Pruefen Sie von ausserhalb Ihres Netzwerks, ob das Praefix im Internet sichtbar ist.

Von Ihrem lokalen Rechner (nicht dem VPS):

traceroute YOUR_PREFIX_V4_FIRST_IP

Nutzen Sie bgp.tools, um Ihr Praefix nachzuschlagen und zu pruefen:

  • Ob die Origin-AS mit Ihrer ASN uebereinstimmt.
  • Ob der ROA-Status "Valid" zeigt (nicht "Unknown" oder "Invalid").
  • Ob das Praefix von mehreren Standorten aus sichtbar ist.

Sie koennen 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 ausfuehren. Solange der FRR-Service aktiviert ist (systemctl enable frr), liest er diese Datei beim Booten.

Beide Persistenzmechanismen gegenpruefen:

sudo systemctl is-enabled frr

Sollte enabled zurueckgeben.

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

Mit der gespeicherten Datei vergleichen:

head -5 /etc/frr/frr.conf

Beide sollten uebereinstimmen. Falls sie abweichen, fuehren Sie erneut write memory aus.

Das Dummy-Interface bleibt durch systemd-networkd bestehen (frueher konfiguriert). Pruefen:

sudo systemctl is-enabled systemd-networkd

Vollstaendige kommentierte frr.conf

Hier ist eine vollstaendige 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 haengt im Status Active oder Connect

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

  1. Firewall: Koennen Sie den Peer auf TCP 179 erreichen?
    sudo nft list ruleset | grep 179
    
  2. Peer-IP: Ist die Nachbar-IP korrekt? Tippfehler sind die haeufigste Ursache.
    sudo vtysh -c "show bgp neighbors PEER_IPV4" | grep "BGP state"
    
  3. MD5-Mismatch: Bei Verwendung von TCP MD5 muessen beide Seiten exakt denselben Passwort-String haben. Es gibt keine hilfreiche Fehlermeldung dafuer. Die Sitzung baut sich stillschweigend nicht auf.
  4. GTSM: Wenn ttl-security hops 1 gesetzt ist, aber der Peer mehrere Hops entfernt ist (durch NAT oder Tunnel), schlaegt die TTL-Pruefung fehl. Entfernen Sie ttl-security und verwenden Sie stattdessen ebgp-multihop fuer Multi-Hop-Sitzungen.

Praefix extern nicht sichtbar

Ihre Sitzung ist aufgebaut, aber das Praefix erscheint nicht auf Looking Glasses.

  1. Angekuendigte Routen pruefen:

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

    Falls Ihr Praefix nicht aufgelistet ist, blockiert der ausgehende Filter es. Pruefen Sie, ob die Prefix-List exakt zu Ihrem Praefix passt.

  2. Kernel-Route pruefen:

    ip route show YOUR_PREFIX_V4
    

    Falls fehlend, ist das Dummy-Interface nicht aktiv oder falsch konfiguriert.

  3. ROA-Validitaet pruefen: Wenn Ihre ROA fehlt oder inkorrekt ist, verwerfen RPKI-validierende Netzwerke Ihre Ankuendigung. Pruefen Sie bei RIPE RPKI Validator.

Logs lesen

FRR loggt standardmaessig nach syslog. Um BGP-spezifische Ereignisse zu verfolgen:

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

Fuer ausfuehrlichere Ausgabe aktivieren Sie Debug temporaer in vtysh:

debug bgp updates
debug bgp keepalives

Danach wieder deaktivieren (die Ausgabe ist sehr ausfuehrlich):

no debug bgp updates
no debug bgp keepalives

Naechste Schritte

  • RPKI-Validierung hinzufuegen: Konfigurieren Sie FRRs eingebaute RPKI-Unterstuetzung, um eingehende Routen gegen ROA-Daten zu validieren. Siehe .
  • Erweiterte Filterung: Erstellen Sie granularere Route-Maps mit Community-Matching, AS-Path-Filtern und Local-Preference-Tuning. Siehe .
  • Monitoring: Richten Sie BGP-Sitzungsueberwachung ein mit Tools wie Prometheus + bgp_exporter oder Zabbix SNMP Traps, um Benachrichtigungen zu erhalten, wenn eine Sitzung ausfaellt.

Copyright 2026 Virtua.Cloud. Alle Rechte vorbehalten. Dieser Inhalt ist ein Originalwerk des Virtua.Cloud-Teams. Vervielfaeltigung, Wiederveroeffentlichung oder Weiterverbreitung ohne schriftliche Genehmigung ist untersagt.

Bereit, es selbst auszuprobieren?

Stellen Sie Ihren eigenen Server in Sekunden bereit. Linux, Windows oder FreeBSD.

VPS-Angebote ansehen