BGP RPKI Troubleshooting: Invalid Routes und Policy Impacts

BGP RPKI Troubleshooting wird in immer mehr Netzen zum Tagesgeschäft: Sobald Route Origin Validation (ROV) aktiv ist, werden Routen nicht mehr nur nach klassischen Attributen wie Local Preference, AS-Pfad oder MED bewertet, sondern zusätzlich nach ihrem kryptografisch gestützten Origin-Status. Das verbessert die Routing-Hygiene, reduziert Route Leaks und hilft gegen Prefix Hijacks – kann aber im Incident schmerzhaft sein, wenn plötzlich „Invalid Routes“ auftauchen und Traffic unerwartet umgelenkt oder gedroppt wird. Typische Symptome reichen von „ein einzelner Kunde ist nicht erreichbar“ über „bestimmte Prefixe verschwinden“ bis zu „Failover funktioniert nicht mehr, obwohl BGP Sessions up sind“. Genau hier ist methodisches Troubleshooting entscheidend: Sie müssen sauber trennen, ob eine Route wirklich invalid ist (weil ein ROA fehlt oder falsch ist), ob die Validierungspipeline (RTR-Session zum Validator, Cache, Timings) fehlerhaft ist, oder ob Ihre Policies den RPKI-Status anders behandeln als gedacht. Dieser Artikel zeigt eine praxistaugliche Vorgehensweise für BGP RPKI Troubleshooting: Wie Invalid Routes entstehen, wie Sie den Policy-Impact nachvollziehen, wie Sie Fehlerquellen zwischen Validator, Router und Routing-Policy eingrenzen und wie Sie Mitigationen umsetzen, ohne die Sicherheitswirkung von RPKI „aus Versehen“ zu zerstören.

RPKI, ROAs und ROV: Die Begriffe, die im Incident sitzen müssen

Für Troubleshooting hilft ein klares Vokabular. RPKI (Resource Public Key Infrastructure) ist die Infrastruktur, mit der Ressourceninhaber (Prefix-Holder) kryptografisch bestätigen können, welche ASNs bestimmte IP-Prefixe originieren dürfen. Das zentrale Objekt dafür ist das ROA (Route Origin Authorization). Ein Router validiert dann BGP-Routen über ROV (Route Origin Validation) und ordnet ihnen einen Status zu: valid, invalid oder not-found.

• ROA: Autorisiert ein oder mehrere Prefixe und ein Origin-AS (ASID) plus eine maximale Präfixlänge (maxLength).
• ROV: Der Validierungsprozess auf dem Router, der den Status für eine BGP-Route bestimmt.
• Status valid: Origin-AS passt zum ROA und Prefix-Länge ist innerhalb von maxLength.
• Status invalid: ROA existiert, aber Origin-AS passt nicht oder Prefix ist „zu spezifisch“ (länger als maxLength).
• Status not-found: Kein ROA für diesen Prefix vorhanden (nicht automatisch „schlecht“, aber weniger abgesichert).

Hintergrund und Terminologie sind in RFC 6811 (BGP Prefix Origin Validation) gut beschrieben. Die grundlegende RPKI-Architektur und Signed Objects sind unter anderem in RFC 6480 dokumentiert.

Wie eine Route „Invalid“ wird: Die zwei häufigsten Ursachen

In der Praxis entstehen Invalid Routes meist durch zwei Muster – und beide sind sehr gut debugbar, wenn Sie systematisch vorgehen.

Invalid wegen falschem Origin-AS

• Ursache: Ein Prefix wird aus einem anderen ASN announced als im ROA autorisiert.
• Typische Auslöser: Migration auf neues ASN, M&A/Providerwechsel, falsche Upstream-Konfiguration, Route Leak, Hijack.
• Fehlerbild: Route existiert, aber ROV markiert sie invalid; Policy droppt oder depriorisiert sie.

Invalid wegen maxLength und „zu spezifischen“ Prefixen

• Ursache: ROA erlaubt z. B. 203.0.113.0/24 mit maxLength /24, aber jemand announced 203.0.113.0/25.
• Typische Auslöser: Traffic Engineering mit deaggregates, DDoS-Mitigation via /25-/48, Anycast-Designs, Fehlkonfiguration im ROA.
• Fehlerbild: Aggregat ist valid, spezifischere Route ist invalid – genau das erzeugt „komische“ Pfadwechsel.

Policy Impacts: Warum RPKI-„Invalid“ so viel kaputt machen kann

RPKI ist nicht nur ein Label, sondern ein Input in Ihre Routing-Decision. Der Impact hängt davon ab, wie Ihre Policies mit valid/invalid/not-found umgehen. Häufige Policy-Modelle:

• Drop Invalid: Sehr sicher, aber riskant, wenn ROAs falsch/alt sind oder wenn Kunden legitime deaggregates brauchen.
• Deprioritize Invalid: Invalid bleibt als Fallback im RIB, aber bekommt schlechtere Local Pref. Dadurch können Blackouts vermieden werden, aber Sicherheit ist geringer.
• Prefer Valid: Valid gewinnt bei Gleichstand; not-found bleibt normal; invalid wird reduziert oder gedroppt.
• Treat not-found konservativ: Manche Netze depriorisieren not-found, um ROA-Adoption zu fördern; operativ kann das Failover beeinflussen.

Der wichtigste Troubleshooting-Gedanke: Der Nutzerimpact entsteht oft nicht durch den Status allein, sondern durch die Kombination aus Status und Policy. Ein invalid Prefix kann völlig harmlos sein, wenn Sie ihn nur „depriorisieren“. Er kann aber einen kompletten Standort offline nehmen, wenn Sie ihn dropen und es keinen alternativen Pfad gibt.

Die RPKI-Validierungskette: Wo Fehler realistisch entstehen

Damit ROV funktioniert, muss die Pipeline stimmen. Typischerweise gibt es einen oder mehrere RPKI-Validatoren (Caches), die ROAs aus dem RPKI beziehen und über das RPKI-to-Router Protokoll (RTR) an Router liefern. Router markieren dann BGP-Routen mit einem Validierungsstatus. Fehler entstehen entlang dieser Kette:

• ROA-Daten sind falsch oder fehlen: Der häufigste Grund für invalid/not-found – organisatorisch, nicht technisch.
• Validator hat einen stale oder fehlerhaften View: Probleme beim Fetching, Repository-Fehler, Timing/Refresh.
• RTR-Session ist down oder instabil: Router fällt auf alten Cache oder „unknown“ Status zurück.
• Router setzt Status anders um als erwartet: Plattform-/Softwareunterschiede, falsche Policy-Integration.

Für RTR als Mechanismus ist RFC 6810 (RPKI to Router Protocol) eine gute Referenz; modernisierte Varianten existieren ebenfalls, aber für Troubleshooting reicht das Grundprinzip: Router bezieht validierte Prefix-Origin-Daten vom Cache.

High-Signal Symptome im Betrieb: So erkennen Sie RPKI-Probleme schnell

RPKI-Probleme haben typische Muster, die sich von „normalen“ BGP-Fehlern unterscheiden. Statt Session-Down sehen Sie häufig Session-Up, aber Route-Decision ändert sich unerwartet.

• BGP Session stabil, Route fehlt: Policy droppt invalid; im Adj-RIB-In ist die Route sichtbar, im Loc-RIB nicht.
• Traffic shift nach Policy-Change oder ROA-Update: RPKI-Status kippt und Local Pref/Best Path ändert sich.
• Nur spezifische Prefixlängen betroffen: /24 valid, /25 invalid; bei IPv6 z. B. /48 valid, /56 invalid.
• Asymmetrische Erreichbarkeit: Ein Standort erreicht Ziel, anderer nicht – unterschiedliche Upstreams oder unterschiedliche RPKI-Policy/Validator-Views.
• „Not-found“ plötzlich massenhaft: Validator down, RTR down, oder Router nutzt fallback behavior.

Methodik: RPKI Troubleshooting ohne Ratespiel

Ein belastbarer Workflow beantwortet nacheinander fünf Fragen. Wenn Sie diese Reihenfolge einhalten, finden Sie die Ursache meist sehr schnell.

Frage 1: Welche Route ist betroffen (Prefix, Origin-AS, Prefixlänge)?

• Prefix und Länge: Ist es das Aggregat oder ein deaggregate?
• Origin-AS: Welches ASN announced es tatsächlich?
• Alternative Pfade: Gibt es mehrere Origin-ASNs (z. B. Multi-Origin, Anycast) oder nur einen?

Frage 2: Welchen RPKI-Status sieht der Router wirklich?

Viele NMS/Collectors zeigen „RPKI invalid“, aber im Incident zählt die Sicht des betroffenen Routers. Prüfen Sie im Router, wie die Route im Adj-RIB-In und Loc-RIB markiert ist. Ist sie valid/invalid/not-found oder „unknown“?

Frage 3: Ist der Status korrekt oder ein Pipeline-Problem?

• RTR-Session Health: Ist der Router mit dem Validator verbunden? Ist der Cache frisch?
• Stale-Indicators: Gibt es Hinweise auf veraltete ROA-Daten oder Refresh-Probleme?
• Vergleich: Sehen andere Router denselben Status? Wenn nicht, ist es oft ein Validator- oder Policy-Divergenzproblem.

Frage 4: Welche Policy-Action wird durch den Status ausgelöst?

• Drop oder Deprioritize? Ist invalid hart gedroppt oder nur weniger bevorzugt?
• Wo greift die Policy? Inbound am Peer, im Core, beim RR, oder outbound in Richtung Kunden?
• Interaktion mit anderen Policies: Prefix-Listen, max-prefix, communities, RTBH/DDoS-Policies können sich überlagern.

Frage 5: Was ist die eigentliche Root Cause und der nachhaltige Fix?

Wenn eine Route truly invalid ist, liegt der Fix fast immer in ROA/Origin-Design oder im Routing-Design (z. B. deaggregation). Wenn die Route fälschlich invalid ist, ist der Fix häufig ein ROA-Update oder eine Korrektur des Origin-AS. Wenn die Route „not-found“ ist, ist der Fix oft organisatorisch: ROA erstellen.

Debugging „Invalid“: Schritt-für-Schritt zur Ursache

Invalid ist der spannendste Status, weil er sowohl echte Angriffe als auch echte Betriebsfehler abdeckt. Für Troubleshooting ist daher wichtig, invalid nicht automatisch als Hijack zu labeln, aber auch nicht automatisch als „Fehlalarm“ abzutun.

• Check 1: Gibt es ein ROA für das Prefix? Wenn ja, welcher Origin-AS ist autorisiert?
• Check 2: Ist die announced Prefixlänge innerhalb maxLength?
• Check 3: Passt das Origin-AS des BGP-Updates zum ROA?
• Check 4: Gibt es legitime Gründe für Multi-Origin (MOAS) und sind entsprechende ROAs vorhanden?
• Check 5: Hat sich etwas geändert (Migration, Providerwechsel, DDoS-Mitigation, Traffic Engineering)?

Wenn Sie schnelle externe Plausibilisierung brauchen, helfen RPKI-Check-Tools von Regional Internet Registries, z. B. RIPE NCC RPKI (inklusive Validator/Infos) oder ähnliche Angebote anderer RIRs. In produktiven Incidents ist allerdings die eigene Validator-Sicht (inkl. Logs/State) oft noch wichtiger.

Debugging „Not-found“: Sicherheits-Impact vs. Betriebsrealität

Not-found bedeutet: kein ROA vorhanden. Viele Betreiber behandeln not-found weiterhin normal, weil ROA-Abdeckung global nicht vollständig ist. Wenn Sie not-found jedoch depriorisieren oder filtern, entsteht ein Policy-Impact, der sich wie „Random Reachability“ anfühlen kann.

• Wenn not-found erlaubt ist: Betrieb stabil, aber weniger Schutz gegen Spoofing/Hijacks für diese Prefixe.
• Wenn not-found depriorisiert ist: Valid gewinnt; kann bei Failover oder Multi-Provider-Setups Pfade verändern.
• Wenn not-found gedroppt ist: Sehr restriktiv; nur sinnvoll, wenn Sie ROA-Abdeckung in Ihrer Domäne/bei Ihren Kunden kontrollieren.

Im Troubleshooting sollten Sie not-found nicht als „Fehler“ behandeln, sondern als Input für Policy-Entscheidungen. Wenn ein Kunde plötzlich unreachable ist, weil sein Prefix not-found ist und Ihre Policy das nicht akzeptiert, ist die Mitigation meist ein ROA beim Kunden oder eine temporäre Ausnahme.

Route Reflectors und RPKI: Wo der Status verloren gehen kann

In großen Netzen laufen BGP-Entscheidungen über Route Reflectors (RR). Je nach Design kann RPKI-Validierung am Edge, am RR oder auf beiden stattfinden. Das erzeugt typische Fehlerbilder:

• Validierung nur am Edge: RR sieht den Status nicht und propagiert Routen ohne RPKI-Tag; Downstream-Router interpretieren anders.
• Validierung nur am RR: Edge markiert nicht; RR entscheidet und filtert; Troubleshooting muss auf RR-Sicht starten.
• Doppelte Validierung: Kann ok sein, aber führt zu Divergenzen, wenn Validatoren nicht konsistent sind.

Best Practice für Troubleshooting: Dokumentieren Sie, wo in Ihrem Netz ROV stattfindet und wo Policies greifen. Ohne diese Karte kann ein Incident unnötig lange dauern.

Policy-Design, das im Incident nicht eskaliert

RPKI ist Sicherheit – aber Betrieb ist Verfügbarkeit. Ein gutes Policy-Design verhindert, dass ein einzelner ROA-Fehler sofort einen kompletten Blackout verursacht, und bietet gleichzeitig Schutzwirkung.

• Staged rollout: Erst markieren (tagging), dann depriorisieren, erst danach dropen – mit klaren Monitoring-Grenzwerten.
• Graceful fallback: Invalid wird depriorisiert statt gedroppt, zumindest in Übergangsphasen oder für kritische Services.
• Ausnahmen mit Ablauf: Temporäre Allow-Listen für bekannte legitime Sonderfälle (z. B. DDoS-Mitigation), mit Ablaufdatum und Ticketpflicht.
• MaxLength bewusst setzen: Nicht zu eng (bricht legitime deaggregates), nicht zu weit (reduziert Schutzwirkung). Das ist ein Governance-Thema.

Mitigation im Incident: Stabilisieren ohne RPKI „abzuschalten“

Wenn invalid Routen impacten, ist die spontane Reaktion oft: RPKI aus. Das ist operativ verständlich, aber sicherheitlich riskant und kann in Multi-Provider-Umgebungen neue Probleme erzeugen. Besser ist eine abgestufte Mitigation:

• Temporär: invalid nur depriorisieren: Statt drop, Local Pref reduzieren und fallback erlauben.
• Scope begrenzen: Nur den betroffenen Peer/VRF/Edge anpassen, nicht global.
• Root Cause parallel fixen: ROA korrigieren (Origin-AS oder maxLength), oder Announcement korrigieren.
• Monitoring aktivieren: Invalid-Rate pro Peer/ASN, sudden spikes, Policy-hit counters; so sehen Sie sofort, ob es ein Leak/Hijack ist.

Verifikation und Beweisführung: Was Sie dokumentieren sollten

RPKI-Incidents sind häufig teamübergreifend (NetOps, SecOps, Peering, Kunde/Provider). Je besser Ihre Beweisführung, desto schneller wird das Problem gelöst. Minimal sollten Sie festhalten:

• Betroffene Prefixe: Prefix, Länge, Origin-AS, Peer.
• Status: valid/invalid/not-found + Zeitpunkt, wann Status kippte.
• Policy-Impact: drop/deprioritize/allow und wo die Policy greift.
• Validator-Status: RTR up/down, cache age, ggf. Vergleich mit zweitem Validator.
• Fix: ROA-Änderung oder Routing-Änderung inkl. erwarteter Propagationszeit (TTL/Cache/Refresh).

Runbook-Baustein: BGP RPKI Troubleshooting in 15 Minuten

• Minute 0–3: Betroffenen Prefix identifizieren (Prefix/Länge/Origin-AS) und prüfen, ob Route im Adj-RIB-In vorhanden ist.
• Minute 3–6: RPKI-Status auf dem betroffenen Router prüfen (valid/invalid/not-found/unknown) und RTR-Session/Validator-Health checken.
• Minute 6–9: ROA-Logik prüfen: Origin-AS vs. ROA, Prefixlänge vs. maxLength. Wenn invalid: ist es Origin-Mismatch oder maxLength?
• Minute 9–12: Policy-Impact lokalisieren: Wo wird invalid gefiltert oder depriorisiert? Gibt es Overlap mit anderen Policies (prefix-lists, communities, max-prefix)?
• Minute 12–15: Mitigation wählen: temporär depriorisieren/allow mit Scope, parallel ROA/Announcement fixen. Danach verifizieren: Route erscheint wieder, Best Path stabil, Traffic normalisiert.

Weiterführende Quellen

• RFC 6811 für BGP Prefix Origin Validation (Status valid/invalid/not-found und Grundprinzipien)
• RFC 6810 für das RPKI-to-Router Protokoll (RTR) und die Validator-Router-Interaktion
• RFC 6480 für RPKI-Architektur und Signed Objects (Grundlagen für ROAs)
• RFC 4271 für BGP-4 Grundlagen (wenn Sie Policy-Impact mit klassischer BGP-Decision kombinieren müssen)
• RIPE NCC RPKI als praxisnahe Referenz für RPKI/ROV-Ökosystem, Validator-Umfeld und Checks

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.