RPKI für BGP auf Cisco: Route Origin Validation in der Praxis

RPKI (Resource Public Key Infrastructure) ist heute einer der wichtigsten Sicherheitsbausteine für BGP: Mit Route Origin Validation (ROV) prüfst du kryptografisch, ob der AS, der ein Prefix announced, dafür autorisiert ist. Damit reduzierst du das Risiko von Route Leaks und Hijacks deutlich – ohne komplizierte Filterlisten. In der Praxis ist RPKI kein „Allheilmittel“, sondern ein zusätzlicher Prüfmechanismus, den du sauber in deine BGP-Policy integrierst: valide Routen bevorzugen, invalid Routen konsequent ablehnen (oder zumindest stark benachteiligen) und unknown Routen kontrolliert behandeln. Dieses Tutorial zeigt RPKI/ROV auf Cisco Routern in einem betriebssicheren Workflow.

Was RPKI/ROV genau prüft

ROV prüft nur den Origin-AS (den letzten AS im AS-Path, der das Prefix ursprünglich announced). Es prüft nicht die gesamte AS-Path-Kette. Das Ergebnis ist ein Status pro Prefix: valid, invalid oder not-found (unknown).

• valid: ROA existiert und Origin-AS passt
• invalid: ROA existiert, aber Origin-AS oder MaxLength passt nicht
• not-found: kein ROA vorhanden (weder gut noch böse)

Status-Denkmodell

$\text{ROV} \to \text{valid | invalid | not-found}$

Warum RPKI in der Praxis wirkt

Die meisten schweren Routing-Vorfälle entstehen durch falsche Origins (Hijack) oder unabsichtliche Leaks (z. B. ein AS announced fremde Prefixes). ROV erkennt viele dieser Fälle automatisch. Der operative Gewinn ist groß, weil du nicht jede Route manuell pflegen musst.

• Reduziert Risiko von Origin-Hijacks
• Hilft gegen Fehlankündigungen durch Drittparteien
• Ergänzt Prefix-Lists und Max-Prefix (nicht ersetzen)

Designentscheidung: „Drop invalid“ oder „Deprioritize invalid“?

Die wichtigste Policy-Frage ist, wie du mit invalid Routen umgehst. Best Practice im Internet-Edge ist meist: invalid konsequent verwerfen. In Übergangsphasen kannst du invalid zunächst nur benachteiligen, um unerwartete Impacts zu vermeiden – aber mit klarem Ziel „drop invalid“.

• Strict Mode: invalid = reject (sicherste Variante)
• Soft Mode: invalid = LocalPref stark senken (temporär)
• Unknown: normal behandeln oder leicht benachteiligen (je nach Policy)

Architektur: Router spricht nicht direkt mit RPKI, sondern mit einem RTR Cache

Auf Cisco Routern wird RPKI typischerweise über das RTR-Protokoll (RFC-konform) zu einem RPKI Cache/Validator angebunden. Der Validator sammelt ROAs von Trust Anchors, validiert sie und liefert dem Router ein kompaktes „ROA-Set“.

• Router: konsumiert Validierungsdaten (RTR)
• Validator/Cache: sammelt und validiert ROAs
• Best Practice: mindestens zwei Validatoren (Redundanz)

Konfiguration Schritt 1: RPKI Cache Server anbinden (Beispielpattern)

Die Syntax ist je IOS XE Version leicht unterschiedlich, das Muster bleibt: du definierst RTR-Server, optional VRF/Source-Interface, und prüfst den Sync-Status.

RTR Cache definieren

router bgp 65000
 bgp rpki server 10.255.0.10 port 323
 bgp rpki server 10.255.0.11 port 323

Verifikation der Cache-Verbindung

show bgp rpki servers
show bgp rpki summary

Konfiguration Schritt 2: RPKI Status in die BGP-Policy integrieren

ROV ist erst wirksam, wenn du den Status in einer Policy nutzt. Auf Cisco erfolgt das typischerweise über Route-Maps mit Matches auf den RPKI-Status und dann entsprechenden Aktionen (deny oder LocalPref/Community setzen).

Strict Mode: invalid ablehnen

route-map RM_RPKI_IN deny 5
 match rpki invalid
route-map RM_RPKI_IN permit 10

match rpki valid
route-map RM_RPKI_IN permit 20

match rpki notfound

Policy am Neighbor anwenden

router bgp 65000
 neighbor 203.0.113.1 remote-as 64500
 neighbor 203.0.113.1 route-map RM_RPKI_IN in

Soft Mode: invalid benachteiligen statt droppen (Übergangsphase)

Wenn du schrittweise einführen willst, senkst du für invalid Routen LocalPref drastisch, statt sie sofort zu droppen. Dadurch bleibt Konnektivität oft erhalten, aber invalid wird nur gewählt, wenn es keine Alternative gibt.

Soft Mode Route-Map

route-map RM_RPKI_IN permit 5
 match rpki invalid
 set local-preference 50
route-map RM_RPKI_IN permit 10

match rpki valid

set local-preference 200
route-map RM_RPKI_IN permit 20

match rpki notfound

set local-preference 150

Operational Guardrails: Was du zusätzlich immer brauchst

RPKI ist ein Layer, aber kein vollständiger BGP-Schutz. Du brauchst weiterhin klassische Guardrails, damit Fehler nicht eskalieren: Prefix-Limits, Bogon-Filter, Outbound Whitelists und saubere Communities.

• Outbound Whitelist: nur eigene Prefixes announcen
• Max-Prefix: schützt vor Route Explosion
• Bogons/RFC1918 inbound filtern (je nach Peering)
• Monitoring: RPKI Server down, invalid-count Trends

Maximum-Prefix Beispiel

router bgp 65000
 neighbor 203.0.113.1 maximum-prefix 100000 90 restart 5

Verifikation: Wirkt ROV wirklich?

Du verifizierst in drei Ebenen: (1) Router hat ROA-Daten, (2) Routen erhalten einen RPKI-Status, (3) deine Policy setzt sich durch (invalid wird gedroppt oder depriorisiert).

ROA Sync prüfen

show bgp rpki summary
show bgp rpki servers

Status pro Prefix prüfen

show ip bgp <prefix>
show ip bgp | include valid|invalid|notfound

Policy-Treffer prüfen

show route-map RM_RPKI_IN

Typische Pitfalls in der Praxis

Die häufigsten Probleme sind nicht „RPKI kaputt“, sondern Betriebs- und Policyfehler: Cache nicht erreichbar, falsche VRF/Source, oder zu aggressives Droppen, bevor du Monitoring und Redundanz hast.

• RPKI Cache down → alle Prefixes plötzlich „not-found“ (je nach Verhalten)
• Falsche Source/VRF → RTR Session kommt nicht hoch
• Strict drop ohne Pilot → unerwartete Reachability-Probleme bei Partnern
• ROA MaxLength falsch bei eigenen Prefixes → du machst dich selbst invalid

Einführungsprozess: sicher von „aus“ zu „drop invalid“

RPKI ist am sichersten, wenn du es stufenweise einführst: erst Visibility, dann Soft Mode, dann Strict Mode. So findest du false positives und organisatorische Lücken (ROA-Pflege) bevor es impactet.

• Phase 1: nur Status sammeln und monitoren (kein Policy-Impact)
• Phase 2: invalid depriorisieren (LocalPref runter)
• Phase 3: invalid droppen (Strict)
• Phase 4: regelmäßige ROA-Compliance für eigene Prefixes (MaxLength/Origin)

Quick-Runbook: RPKI/ROV in 5 Minuten prüfen

Diese Kommandos liefern dir schnell: Cache up, ROAs geladen, Status sichtbar, Policy greift.

show bgp rpki servers
show bgp rpki summary
show ip bgp <prefix>
show route-map RM_RPKI_IN
show ip bgp summary

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.