Site icon bintorosoft.com

Route-based VPN (VTI) mit BGP: Skalierbarer als Crypto Map?

Red Snapper

internet business concept.desktop connected to the business graph

Route-based VPNs über Virtual Tunnel Interfaces (VTIs) gelten im Enterprise-Betrieb als „skalierbarer“ als klassische Crypto Maps, weil Routing (statt ACL-Selector) bestimmt, welcher Traffic durch den Tunnel geht. Kombinierst du VTIs mit BGP, bekommst du ein sehr robustes Betriebsmodell: dynamische Prefix-Verteilung, saubere Failover-Entscheidungen und weniger Copy/Paste-ACLs pro Peer. Der entscheidende Punkt ist jedoch: VTI+BGP ist nicht automatisch besser – es ist ein anderes Design. Du tauschst Selector-Komplexität gegen Routing-Governance. Dieser Artikel erklärt, warum VTI mit BGP oft skalierbarer ist, welche Fallstricke es gibt und wie ein praxistaugliches Konfigurationsmuster auf Cisco aussieht.

Crypto Map vs. VTI: Woher kommt die Skalierung?

Crypto Maps sind policy-based: Jede neue Subnetz-Kombination braucht meist eine ACL-Anpassung. VTIs sind route-based: Neue Netze sind „nur“ neue Routes. Mit BGP wird daraus ein automatisierter Mechanismus, der große Peer-Zahlen deutlich besser handhabbar macht.

Merker

Operativer Aufwand ≈ Änderungen an ACLs → Änderungen an Routen

Warum BGP über VTI im Betrieb oft stabiler ist

BGP liefert zwei Dinge, die du bei Crypto Maps mühsam nachbauen musst: dynamische Reachability (Prefixes kommen/gehen) und Policy-Steuerung (LocalPref, AS-Path, Communities). Damit wird Failover kontrollierter und skalierbarer.

Wann Crypto Maps trotzdem sinnvoll sind

Crypto Maps sind nicht „falsch“. Sie sind oft die bessere Wahl, wenn du sehr wenige, statische Selectors hast und Routing im Tunnel bewusst vermeiden willst. Für kleine Umgebungen ist das oft einfacher.

VTI + BGP Design Patterns: Das bewährte Grundmuster

Das Standardmuster ist ein point-to-point Tunnel mit einem /30 oder /31 (IPv4) oder einem /127 (IPv6) als Tunnel-IP. BGP läuft über diese Tunnel-IP. Der IPsec-Schutz wird per tunnel protection gebunden. Routing-Policy steuert, welche Prefixes über den Tunnel gehen.

Konfiguration: VTI + IPsec (Pattern)

Dieses Beispiel zeigt ein typisches Cisco IOS XE Setup: IPsec Profile, Tunnel Interface und Schutz des Tunnels. Die IKEv2 Details (Proposal/Keyring/Profile) sind in vielen Deployments bereits standardisiert und werden hier als „gegeben“ betrachtet.

IPsec Transform/Profil

crypto ipsec transform-set TS-ESP-AESGCM esp-gcm 256
 mode tunnel

crypto ipsec profile IPSEC-PROF-VTI

set transform-set TS-ESP-AESGCM

set pfs group14

Tunnel Interface (VTI)

interface Tunnel100
 description VTI to BRANCH1
 ip address 169.254.100.1 255.255.255.252
 tunnel source GigabitEthernet0/0
 tunnel destination 203.0.113.10
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile IPSEC-PROF-VTI

Konfiguration: BGP über VTI (Pattern)

BGP läuft über die Tunnel-IP. Du kontrollierst Prefix-Exchange über Prefix-Lists/Route-Maps und setzt sinnvolle Schutzmechanismen (Max-Prefix, Timer, ggf. BFD).

BGP Neighbor über Tunnel

router bgp 65000
 neighbor 169.254.100.2 remote-as 65100
 neighbor 169.254.100.2 description BRANCH1 over VTI
 neighbor 169.254.100.2 timers 10 30
 neighbor 169.254.100.2 maximum-prefix 500 90 restart 5

Prefix-Filter (Best Practice)

ip prefix-list PL_FROM_BRANCH1 seq 10 permit 10.20.0.0/16 le 24
ip prefix-list PL_TO_BRANCH1   seq 10 permit 10.10.0.0/16 le 24

route-map RM_FROM_BRANCH1 permit 10

match ip address prefix-list PL_FROM_BRANCH1


route-map RM_TO_BRANCH1 permit 10

match ip address prefix-list PL_TO_BRANCH1


router bgp 65000

neighbor 169.254.100.2 route-map RM_FROM_BRANCH1 in

neighbor 169.254.100.2 route-map RM_TO_BRANCH1 out

Skalierung: 1 Tunnel pro Site vs. „Hub-and-Spoke“

VTI+BGP skaliert besonders gut in Hub-and-Spoke-Designs: Jede Branch hat einen Tunnel zum Hub, BGP tauscht die Prefixes, und der Hub kontrolliert Policy zentral. Für große Netze brauchst du Redundanz (zwei Hubs oder zwei Tunnels pro Site) und saubere BGP-Policy (LocalPref/Communities).

Failover-Mechanik: Warum BGP „sauberer“ ist als Selector-Failover

Wenn ein Tunnel down ist, fällt die BGP Session und Prefixes werden withdrawn. Dadurch stoppt Traffic deterministisch. Bei Crypto Maps mit statischen Routen kann Traffic weiter „in den Tunnel“ geroutet werden, wenn du keine sauberen Tracking-Mechanismen hast.

BFD optional (Pattern)

interface Tunnel100
 bfd interval 300 min_rx 300 multiplier 3

router bgp 65000

neighbor 169.254.100.2 fall-over bfd

Wichtige Pitfalls: Routing-Governance ersetzt Selector-Klarheit

VTI+BGP ist skalierbar, aber nur, wenn du Routing sauber kontrollierst. Ohne Filter und klare Policy kann ein Site versehentlich Default Routes announcen, oder du baust dir unbeabsichtigte Transitpfade.

MTU/MSS im VTI: Der unterschätzte Stabilitätsfaktor

Viele „VPN instabil“-Tickets sind MTU/PMTUD-Probleme. Besonders bei TCP hilft MSS Clamping auf dem Tunnel-Interface, um Fragmentierung zu vermeiden.

MSS Clamping (Pattern)

interface Tunnel100
 ip tcp adjust-mss 1360

Troubleshooting: Was du bei VTI+BGP zuerst prüfst

Der Vorteil von VTI+BGP ist das klare Troubleshooting: (1) Tunnel up, (2) IKE/IPsec SAs up, (3) BGP Session up, (4) Routen in der Tabelle, (5) CEF Next-Hop über Tunnel. Damit findest du Fehler meist schneller als bei ACL-basierten Selectors.

Health Checks

show interface Tunnel100
show crypto ikev2 sa
show crypto ipsec sa
show ip bgp summary
show ip bgp neighbors 169.254.100.2 received-routes
show ip route 10.20.10.0 255.255.255.0
show ip cef 10.20.10.10 detail

Best Practices: Warum VTI+BGP in großen Umgebungen gewinnt

In der Praxis ist VTI+BGP skalierbarer, weil es Änderungen in Routing-Policy statt in Crypto-Selector-ACLs verschiebt. Wenn du Standardisierung, Templates und strikte Filter nutzt, wird das Betriebsmodell sehr stabil.

Quick-Runbook: VTI+BGP Incident unter Zeitdruck

Diese Sequenz zeigt schnell, ob das Problem Tunnel, Crypto oder Routing ist.

show interface Tunnel100
show crypto ikev2 sa
show crypto ipsec sa
show ip bgp summary
show ip route <remote-prefix>
show ip cef <remote-host> detail
show interfaces | include drops|error

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