Site icon bintorosoft.com

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

Red Snapper

Computer technology 3D illustration. Computation of big data center. Cloud computing. Online devices upload and download information. Modern 3D illustration. 3D rendering

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).

Status-Denkmodell

ROV  →  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.

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“.

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“.

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.

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.

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.

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

Sie erhalten

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.

Exit mobile version