RPKI ROA für BGP: ROAs erstellen, Routen in BIRD2 und FRR validieren

12 Min. Lesezeit·Matthieu·rpkiroabgpbird2frrroutinatorripe-nccipv6|

IPv4- und IPv6-ROAs im RIPE-NCC-Portal erstellen, Routinator als RTR-Cache installieren, RPKI-Routenvalidierung in BIRD2 und FRRouting konfigurieren und den Präfixstatus mit bgp.tools und RIPE Stat prüfen.

Ohne RPKI kann jede ASN jedes Präfix ankündigen. Ein Route Origin Authorization (ROA) bindet Ihr Präfix kryptographisch an Ihre ASN, und Route Origin Validation (ROV) ermöglicht es Ihrem Router, ungültige Ankündigungen abzulehnen. Dieses Tutorial deckt die gesamte Kette ab: ROAs im RIPE-NCC-Portal erstellen, Routinator als lokalen RPKI-Cache betreiben, Validierung in BIRD2 und FRRouting konfigurieren und alles überprüfen.

Voraussetzungen: eine registrierte ASN, zugewiesene IP-Präfixe (PA oder PI), eine funktionierende BGP-Session auf einem Linux-VPS (BGP mit eigener IP auf einem VPS) und entweder BIRD2 (BIRD2-BGP-Konfiguration) oder FRR (FRR-BGP-Konfiguration) bereits in Betrieb.

Was ist RPKI und warum braucht Ihr BGP-Präfix ein ROA?

Resource Public Key Infrastructure (RPKI) ist ein kryptographisches Framework, definiert in RFC 6480, das Internet-Nummernressourcen (IP-Präfixe, ASNs) über X.509-Zertifikate der Regional Internet Registries an ihre rechtmäßigen Inhaber bindet. Ein Route Origin Authorization (ROA) ist ein signiertes Objekt, das besagt: „ASN X ist autorisiert, Präfix Y mit einer maximalen Präfixlänge von Z anzukündigen." Validatoren rufen diese ROAs ab und leiten das Ergebnis über das RPKI-to-Router-Protokoll (RTR) (RFC 8210) an Ihren Router weiter.

Wenn ein Router ein BGP-Update empfängt, prüft er die Origin-ASN und das Präfix gegen seine lokale ROA-Tabelle. Jedes Präfix erhält einen von drei Validierungszuständen:

Zustand Bedeutung Empfohlene Aktion
Valid Ein ROA existiert und stimmt mit der Origin-ASN und Präfixlänge überein Akzeptieren
Invalid Ein ROA existiert, aber Origin-ASN oder Präfixlänge stimmen nicht überein Ablehnen
Not Found Kein ROA deckt dieses Präfix ab Akzeptieren (optional mit niedrigerem Local-Pref)

Ohne ROA erscheinen Ihre Präfixe als „Not Found". Das ist besser als „Invalid", aber Netzwerke mit ROV bevorzugen „Valid"-Routen Ihrer Peers gegenüber Ihren „Not Found"-Ankündigungen, wenn beide verfügbar sind. ROAs zu erstellen ist der erste Schritt. Die Validierung eingehender Routen schützt Ihr Netzwerk davor, gekaperte Präfixe zu akzeptieren.

Wie erstellen Sie IPv4- und IPv6-ROAs im RIPE-NCC-Portal?

Melden Sie sich im RIPE-NCC-Portal an, navigieren Sie zu Resources, dann RPKI Dashboard. Falls Sie RPKI noch nicht initialisiert haben, wählen Sie „Hosted" Certificate Authority. RIPE NCC verwaltet die CA und Signierung für Sie. Sobald die Hosted CA aktiv ist, wechseln Sie zum Tab BGP Announcements. RIPE füllt ROA-Vorschläge basierend auf Ihren aktuellen BGP-Ankündigungen vor.

  1. Klicken Sie auf Create ROA (oder + New ROA im ROA-Tab).
  2. Setzen Sie Origin ASN auf Ihre AS-Nummer (z.B. AS213279).
  3. Setzen Sie Prefix auf Ihre IPv4-Allokation (z.B. 192.0.2.0/24).
  4. Setzen Sie Maximum Length gleich der Präfixlänge (/24). Erhöhen Sie diesen Wert nicht. Siehe den maxLength-Abschnitt weiter unten.
  5. Klicken Sie auf Publish.
  6. Wiederholen Sie den Vorgang für Ihr IPv6-Präfix (z.B. 2001:db8::/48 mit maximaler Länge /48).

Überprüfen Sie im RPKI Dashboard, dass der ROA-Status „Published" anzeigt. Die Propagation zu Validatoren dauert in der Regel 10 bis 20 Minuten, abhängig von deren Aktualisierungsintervall.

Dual-Stack-Hinweis: Erstellen Sie ein ROA pro Präfix. Wenn Sie 192.0.2.0/24 und 2001:db8::/48 ankündigen, benötigen Sie zwei ROAs. Wenn Sie zusätzliche More-Specifics ankündigen (ein /25 aus dem /24), braucht jedes seinen eigenen ROA mit eigener ASN-Bindung.

Wie installieren Sie Routinator als RPKI-RTR-Cache unter Linux?

Routinator ist ein RPKI Relying Party (Validator), entwickelt von NLnet Labs. Er ruft ROAs von allen fünf RIR-Trust-Anchors ab, validiert sie und liefert Validated ROA Payloads (VRPs) über das RTR-Protokoll an Ihren Router. Aktuelle stabile Version: 0.15.1.

Installation aus dem NLnet-Labs-Repository

Auf Debian 12 oder Ubuntu 24.04:

sudo apt update
sudo apt install -y ca-certificates curl gnupg lsb-release

Fügen Sie den NLnet-Labs-Signaturschlüssel und das Repository hinzu:

curl -fsSL https://packages.nlnetlabs.nl/aptkey.asc | sudo gpg --dearmor -o /usr/share/keyrings/nlnetlabs-archive-keyring.gpg

Für Debian:

echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/nlnetlabs-archive-keyring.gpg] https://packages.nlnetlabs.nl/linux/debian $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/nlnetlabs.list > /dev/null

Für Ubuntu:

echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/nlnetlabs-archive-keyring.gpg] https://packages.nlnetlabs.nl/linux/ubuntu $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/nlnetlabs.list > /dev/null

Installieren Sie Routinator:

sudo apt update
sudo apt install -y routinator

Das Paket installiert einen systemd-Dienst, der automatisch startet. Routinator läuft unter dem Benutzer routinator.

Dienst überprüfen

sudo systemctl status routinator

Sie sollten active (running) sehen. Die erste Synchronisierung dauert 2 bis 5 Minuten, während Routinator alle Trust-Anchor-Zertifikate abruft und den globalen ROA-Bestand validiert.

Prüfen Sie, ob die initiale Synchronisierung abgeschlossen ist, indem Sie die HTTP-API abfragen (die Paketversion loggt nach syslog mit wenig Detail; die HTTP-API ist die zuverlässige Quelle):

curl -s http://127.0.0.1:8323/api/v1/status | python3 -c "import sys,json; d=json.load(sys.stdin); print(f'IPv4 VRPs: {d[\"payload\"][\"routeOriginsIPv4\"][\"final\"]}, IPv6 VRPs: {d[\"payload\"][\"routeOriginsIPv6\"][\"final\"]}')"

Falls die Synchronisierung noch läuft, sind die Zähler null. Warten Sie 2 bis 5 Minuten und versuchen Sie es erneut. Sobald Sie Werte ungleich null sehen (Hunderttausende für IPv4, Zehntausende für IPv6), ist die initiale Synchronisierung abgeschlossen.

Konfiguration

Die Paketkonfiguration befindet sich unter /etc/routinator/routinator.conf. Die Standardwerte sind sicher: RTR lauscht auf 127.0.0.1:3323 und HTTP auf 127.0.0.1:8323. Beide sind nur an localhost gebunden.

Wichtige Einstellungen:

Option Standard Zweck
rtr-listen ["127.0.0.1:3323"] RTR-Server für Router
http-listen ["127.0.0.1:8323"] HTTP-Oberfläche und API
refresh 600 Sekunden zwischen RPKI-Synchronisierungen
retry 600 Sekunden vor erneutem Versuch nach fehlgeschlagener Synchronisierung
expire 7200 Sekunden, bevor gecachte VRPs als veraltet gelten

Wenn BIRD2 oder FRR auf derselben Maschine läuft (typisch für ein VPS-BGP-Setup), behalten Sie das Standard-Binding auf 127.0.0.1 bei. Keine Firewall-Änderungen nötig.

Wenn Sie Routinator auf einem separaten Server betreiben, binden Sie ihn an eine private IP und beschränken Sie den Zugriff:

sudo ufw allow from 10.0.0.0/24 to any port 3323 proto tcp comment "RTR from routers"

Prüfen Sie die HTTP-Oberfläche:

curl -s http://127.0.0.1:8323/api/v1/status | head -20

Dies liefert JSON mit der aktuellen VRP-Anzahl, der letzten Synchronisierungszeit und dem Validatorstatus.

Wie konfigurieren Sie RPKI-Validierung in BIRD2?

BIRD2 hat native RPKI-Unterstützung über das rpki-Protokoll (verfügbar seit BIRD 2.0; Ubuntu 24.04 liefert BIRD 2.14). Es verbindet sich über RTR mit Routinator, befüllt ROA-Tabellen und stellt die Funktion roa_check() für Importfilter bereit. Keine externen Bibliotheken nötig.

Fügen Sie Folgendes zu Ihrer BIRD2-Konfiguration hinzu (typischerweise /etc/bird/bird.conf):

ROA-Tabellen definieren

roa4 table roa_v4;
roa6 table roa_v6;

RPKI-Protokoll konfigurieren

protocol rpki rpki_routinator {
    roa4 { table roa_v4; };
    roa6 { table roa_v6; };
    remote 127.0.0.1 port 3323;
    retry keep 90;
    refresh keep 600;
    expire keep 7200;
}

Das Schlüsselwort keep weist BIRD an, die vom Server bereitgestellten Timer-Werte zu bevorzugen und auf die angegebenen Standardwerte zurückzufallen. retry 90 bedeutet, dass BIRD sich 90 Sekunden nach Verlust der RTR-Session neu verbindet.

ROA-Validierung zum Importfilter hinzufügen

filter bgp_import_v4 {
    if (roa_check(roa_v4, net, bgp_path.last_nonaggregated) = ROA_INVALID) then {
        print "RPKI INVALID: ", net, " from AS", bgp_path.last;
        reject;
    }
    if (roa_check(roa_v4, net, bgp_path.last_nonaggregated) = ROA_VALID) then {
        bgp_local_pref = 200;
    }
    accept;
}

filter bgp_import_v6 {
    if (roa_check(roa_v6, net, bgp_path.last_nonaggregated) = ROA_INVALID) then {
        print "RPKI INVALID: ", net, " from AS", bgp_path.last;
        reject;
    }
    if (roa_check(roa_v6, net, bgp_path.last_nonaggregated) = ROA_VALID) then {
        bgp_local_pref = 200;
    }
    accept;
}

bgp_path.last_nonaggregated ist sicherer als bgp_path.last, da es AS_SET-Einträge aus Aggregation überspringt. Ungültige Routen werden abgelehnt. Gültige Routen erhalten ein höheres Local-Pref. Not-Found-Routen passieren mit dem Standard-Local-Pref.

Filter auf Ihren BGP-Peer anwenden

protocol bgp upstream_v4 {
    local as 213279;
    neighbor 198.51.100.1 as 64500;
    ipv4 {
        import filter bgp_import_v4;
        import table;
        export where source ~ [RTS_STATIC, RTS_BGP];
    };
}

Die import table-Direktive ist wichtig. Sie ermöglicht BIRD, gefilterte Routen neu zu bewerten, wenn sich die ROA-Tabelle ändert, ohne einen vollständigen Session-Reset zu benötigen.

Neu laden und überprüfen

sudo birdc configure

Prüfen Sie die RPKI-Session:

sudo birdc show protocols all rpki_routinator

Suchen Sie nach Established in der Ausgabe. Dann prüfen Sie den Inhalt der ROA-Tabelle:

sudo birdc show route table roa_v4 count

Sie sollten Hunderttausende Einträge sehen (die globale ROA-Tabelle umfasst Anfang 2026 über 800.000 VRPs).

Überprüfen Sie die Validierung eines bestimmten Präfixes:

sudo birdc show route 192.0.2.0/24 all

Die Ausgabe enthält ein ROA-Feld mit valid, invalid oder unknown (Not Found).

Wie konfigurieren Sie RPKI-Validierung in FRRouting?

FRRouting unterstützt RPKI über das rpki-Modul, das intern librtr verwendet (Ubuntu 24.04 liefert FRR 8.4.4; FRR 9.x+ und 10.x werden ebenfalls unterstützt). Das Modul verbindet sich mit dem RTR-Server von Routinator und integriert sich in BGP-Route-Maps.

RPKI-Modul installieren

Auf Debian/Ubuntu mit bereits installiertem FRR:

sudo apt install -y frr-rpki-rtrlib

Modul aktivieren

Bearbeiten Sie /etc/frr/daemons und fügen Sie -M rpki zu den bgpd-Optionen hinzu:

bgpd_options="  -A 127.0.0.1 -M rpki"

Starten Sie FRR neu:

sudo systemctl restart frr

Überprüfen Sie, ob bgpd das Modul geladen hat:

sudo vtysh -c "show rpki cache-server"

Wenn der Befehl ohne Fehler ausgeführt wird (die Ausgabe kann vor der Cache-Konfiguration leer sein), ist das Modul geladen. Wenn Sie % Unknown command erhalten, fehlt das -M rpki-Flag oder frr-rpki-rtrlib ist nicht installiert.

RTR-Cache konfigurieren

Starten Sie vtysh und konfigurieren Sie:

sudo vtysh

configure terminal
rpki
 rpki cache 127.0.0.1 3323 preference 1
 rpki polling_period 300
 rpki expire_interval 7200
 rpki retry_interval 600
 exit

Hinweis: FRR 9.x+ verwendet die Syntax rpki cache tcp 127.0.0.1 3323 preference 1 (mit explizitem tcp-Schlüsselwort). FRR 8.x verwendet rpki cache 127.0.0.1 3323 preference 1 ohne dieses Schlüsselwort. Prüfen Sie Ihre Version mit vtysh -c "show version".

Route-Maps für RPKI-Zustände erstellen

route-map rpki-filter permit 10
 match rpki valid
 set local-preference 200
exit

route-map rpki-filter deny 20
 match rpki invalid
exit

route-map rpki-filter permit 30
 match rpki notfound
exit

Dies akzeptiert gültige Routen mit erhöhtem Local-Pref, lehnt ungültige Routen ab und akzeptiert Not-Found-Routen mit Standard-Local-Pref.

Route-Map auf Ihren BGP-Nachbarn anwenden

router bgp 213279
 neighbor 198.51.100.1 remote-as 64500
 address-family ipv4 unicast
  neighbor 198.51.100.1 route-map rpki-filter in
  neighbor 198.51.100.1 soft-reconfiguration inbound
 exit-address-family
 address-family ipv6 unicast
  neighbor 2001:db8::1 route-map rpki-filter in
  neighbor 2001:db8::1 soft-reconfiguration inbound
 exit-address-family
exit

soft-reconfiguration inbound ist erforderlich. Ohne diese Option kann FRR bestehende Routen nicht neu bewerten, wenn sich der RPKI-Cache aktualisiert. FRR speichert die unveränderten Routen vom Peer und wendet die Route-Map erneut an, wenn sich die VRPs ändern.

Konfiguration speichern:

write memory
end

Überprüfen

Prüfen Sie die RTR-Verbindung:

sudo vtysh -c "show rpki cache-connection"

Suchen Sie nach (connected) in der Ausgabe. Dann prüfen Sie die Präfixtabelle:

sudo vtysh -c "show rpki prefix-table" | head -20

Filtern Sie BGP-Routen nach Validierungszustand:

sudo vtysh -c "show bgp ipv4 unicast rpki valid" | head -20
sudo vtysh -c "show bgp ipv4 unicast rpki invalid"

Die Invalid-Ausgabe sollte die Routen zeigen, die Sie aktiv ablehnen.

BIRD2 vs. FRR: RPKI-Konfiguration im Überblick

Funktion BIRD2 FRR
Modulinstallation Integriert (kein zusätzliches Paket) Paket frr-rpki-rtrlib + Flag -M rpki
RTR-Konfiguration protocol rpki-Block mit remote rpki cache-Befehl in vtysh
ROA-Tabellen Explizite roa4/roa6-Tabellen Intern, nicht direkt zugänglich
Filtermechanismus roa_check() im Importfilter match rpki in Route-Map
Automatische Neubewertung import table-Direktive soft-reconfiguration inbound
ROA-Anzahl anzeigen birdc show route table roa_v4 count vtysh show rpki prefix-table
Validierung anzeigen birdc show route ... all (ROA-Feld) vtysh show bgp rpki valid/invalid/notfound

Wie überprüfen Sie den RPKI-Status Ihres Präfixes?

Nach dem Erstellen der ROAs und der Konfiguration der Validierung prüfen Sie von mehreren Standpunkten aus.

Lokale Überprüfung

Auf dem Router selbst prüfen Sie, ob Ihr eigenes Präfix als gültig angezeigt wird:

BIRD2:

sudo birdc show route 192.0.2.0/24 all | grep -i roa

FRR:

sudo vtysh -c "show rpki prefix-table 192.0.2.0/24"

Beide sollten Ihre ASN als autorisierte Origin anzeigen.

Routinator-HTTP-API

curl -s "http://127.0.0.1:8323/api/v1/validity/AS213279/192.0.2.0/24"

Liefert JSON mit dem Validierungszustand, den passenden VRPs und dem Quell-Trust-Anchor.

bgp.tools

Öffnen Sie https://bgp.tools/prefix/192.0.2.0/24 im Browser. Die RPKI-Spalte zeigt ein grünes Schild für Valid, rot für Invalid oder grau für Not Found. Rechnen Sie mit 15 bis 30 Minuten nach ROA-Erstellung, bis externe Tools die Änderung übernehmen.

RIPE Stat

Fragen Sie die RPKI-Validierungs-API ab:

curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS213279&prefix=192.0.2.0/24" | python3 -m json.tool

Suchen Sie nach "status": "valid" in der Antwort. RIPE Stat zeigt auch, welche ROAs das Präfix abdecken und ob die maxLength übereinstimmt.

Für IPv6 wiederholen

Führen Sie dieselben Prüfungen mit Ihrem IPv6-Präfix durch. Jeder obige Befehl akzeptiert IPv6-Präfixe. Ersetzen Sie 192.0.2.0/24 durch 2001:db8::/48 und überprüfen Sie, dass beide Adressfamilien abgedeckt sind.

Warum sollten Sie maxLength nicht länger als Ihre Präfixlänge setzen?

Setzen Sie maxLength gleich Ihrer Präfixlänge. Das ist die Empfehlung aus RFC 9319 (die RFC 7115 aktualisiert und erweitert).

Wenn Sie maxLength auf /24 bei einem /20-ROA setzen, autorisieren Sie Ihre ASN, das /20 und jedes More-Specific bis /24 anzukündigen. Das bedeutet, dass 16 /24 abgedeckt sind. Ein Angreifer, der eines dieser /24 mit Ihrer ASN als Origin kapert, besteht die RPKI-Validierung als „Valid". Das gekaperte More-Specific gewinnt durch Longest-Match-Routing, und der ROA kann Ihnen nicht helfen, weil Sie diese Länge autorisiert haben.

Das nennt man Forged-Origin Sub-Prefix Hijack. Messungen aus 2017, zitiert in RFC 9319, ergaben, dass 84 % der ROAs mit maxLength für diese Attacke anfällig waren.

Konkretes Beispiel:

ROA Was er autorisiert
192.0.2.0/20, maxLength /20 Nur 192.0.2.0/20 von Ihrer ASN. Sicher.
192.0.2.0/20, maxLength /24 /20, /21, /22, /23, /24 von Ihrer ASN. Jedes /24 kann durch Spoofing Ihrer Origin-ASN gekapert werden.

Wann ist maxLength > Präfixlänge akzeptabel? Nur wenn Sie in der Produktion tatsächlich deaggregieren (z.B. ein /20 und spezifische /24 für Traffic Engineering ankündigen) und jedes deaggregierte Präfix validiert werden muss. Erstellen Sie in diesem Fall individuelle ROAs für jedes angekündigte Präfix statt eines ROA mit breitem maxLength. Ein ROA pro Ankündigung ist das sicherste Muster.

Ausnahme DDoS-Mitigation: Wenn Sie einen Dienst wie ein Scrubbing Center nutzen, das Ihre More-Specifics von Ihrer ASN erneut ankündigt, benötigen Sie möglicherweise maxLength, um diese Präfixe abzudecken. Dokumentieren Sie diese Ausnahme und überprüfen Sie sie regelmäßig.

Was passiert, wenn der RPKI-Cache ausfällt?

Wenn Routinator stoppt oder unerreichbar wird, hängt das Verhalten Ihres Routers vom Expire-Timer ab.

BIRD2 behält die letzte bekannte ROA-Tabelle für die Dauer von expire im Speicher (Standard 7200 Sekunden / 2 Stunden). Während dieses Zeitfensters läuft die Validierung normal mit veralteten Daten weiter. Nach Ablauf entfernt BIRD alle ROA-Einträge und jede Route fällt auf „Not Found" zurück. Keine Routen werden wegen Ungültigkeit abgelehnt, aber keine Routen erhalten den Valid-Local-Pref-Bonus.

FRR verhält sich ähnlich. Das rpki expire_interval steuert, wie lange gecachte VRPs nach Abbruch der RTR-Verbindung nutzbar bleiben.

Risiko reduzieren

Betreiben Sie eine zweite Routinator-Instanz oder verwenden Sie einen anderen Validator (StayRTR, Fort) auf einer separaten Maschine. Konfigurieren Sie beide als RTR-Quellen.

BIRD2 unterstützt mehrere protocol rpki-Blöcke:

protocol rpki rpki_backup {
    roa4 { table roa_v4; };
    roa6 { table roa_v6; };
    remote 10.0.0.2 port 3323;
    retry keep 90;
    refresh keep 600;
    expire keep 7200;
}

FRR unterstützt mehrere Cache-Server mit unterschiedlichen Präferenzen:

rpki
 rpki cache 127.0.0.1 3323 preference 1
 rpki cache 10.0.0.2 3323 preference 2
exit

Niedrigere Präferenzwerte werden zuerst versucht. FRR fällt auf den sekundären Server zurück, wenn der primäre ausfällt.

Überwachen Sie den Routinator-Zustand. Prüfen Sie systemctl status routinator und den Status-Endpunkt der HTTP-API mit Ihrem Monitoring-System. Alarmieren Sie bei VRP-Zahl-Einbrüchen (ein plötzlicher Abfall auf null bedeutet Synchronisierungsfehler) und bei RTR-Verbindungsverlusten, sichtbar in journalctl -u routinator.

Fehlerbehebung

ROA zeigt „Not Found" nach Erstellung. Die Propagation dauert 10 bis 20 Minuten. Routinator synchronisiert standardmäßig alle 10 Minuten (refresh = 600). Erzwingen Sie einen Synchronisierungs-Neustart: sudo systemctl restart routinator, dann warten Sie, bis die initiale Synchronisierung abgeschlossen ist.

birdc zeigt 0 Einträge in der ROA-Tabelle. Prüfen Sie birdc show protocols all rpki_routinator. Wenn der Status nicht „Established" ist, überprüfen Sie, ob Routinator läuft und auf Port 3323 lauscht: ss -tlnp | grep 3323.

FRR „Unknown command" bei rpki. Das -M rpki-Flag fehlt in /etc/frr/daemons oder frr-rpki-rtrlib ist nicht installiert. Installieren Sie das Paket, fügen Sie das Flag hinzu, starten Sie FRR neu.

Routen werden nach ROA-Änderung nicht neu bewertet. In BIRD2 fügen Sie import table; zum BGP-Kanal hinzu. In FRR aktivieren Sie soft-reconfiguration inbound beim Nachbarn.

Alle Routen zeigen Invalid. Ihr ROA hat möglicherweise die falsche ASN oder das falsche Präfix. Überprüfen Sie es im RIPE-Portal. Stellen Sie auch sicher, dass die ASN Ihres Routers mit der im ROA eingetragenen übereinstimmt.

Nächste Schritte: Kombinieren Sie RPKI-Validierung mit Prefix-Listen und AS-Path-Filtern für Defense in Depth . Überwachen Sie RPKI-Invalid-Alarme für Ihre Präfixe mit BGPalerter .

Copyright 2026 Virtua.Cloud. Alle Rechte vorbehalten. Dieser Inhalt ist ein Originalwerk des Virtua.Cloud-Teams. Vervielfältigung, Wiederveröffentlichung 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