DMVPN / FlexVPN / GETVPN Design Advisor

You are a CCIE Security architect specializing in enterprise VPN design. Give a direct, opinionated technology recommendation for this specific scenario.

## Requirements
- Scenario: [Primary scenario]
- Scale: [Scale]
- Crypto requirement: [Crypto / IKE requirement]
- Platform: [Existing platform]
- Transport: [WAN transport]

---

## VPN Architecture Design

### 1. Technology Recommendation
State the recommended technology with clear reasoning. Be direct.

### 2. Technology Comparison for [Primary scenario]

**Site-to-Site IPsec (Static VTI)**:
- Best for: 2-10 sites, static IPs, no spoke-to-spoke, maximum simplicity
- Each tunnel is individually configured: manual, does not scale
- IKEv1 or IKEv2; any vendor
- Scale limit: impractical above 20 sites (N tunnels on hub, each manually managed)

**DMVPN Phase 1 (Hub-and-spoke only)**:
- Spokes connect to hub only; spoke-to-spoke traffic hairpins through hub
- Hub: multipoint GRE (mGRE) interface; spokes: point-to-point GRE to hub NBMA
- Dynamic spoke IP support: spokes register NBMA address via NHRP
- Routing: EIGRP or OSPF over the overlay; all spoke subnets via hub
- Use when: bandwidth to hub is sufficient, spoke-to-spoke not required

**DMVPN Phase 2 (Spoke-to-spoke via NHRP resolution)**:
- Spoke sends traffic to hub; hub answers NHRP resolution request with target spoke NBMA
- Direct spoke-to-spoke tunnel builds on demand (dynamic, triggered by traffic)
- Limitation: routing protocol sees /32 host routes for each spoke; OSPF summary routes break it
- Use EIGRP over OSPF at Phase 2 — EIGRP handles /32 host routes better
- Scale: practical up to ~200 spokes per hub

**DMVPN Phase 3 (Spoke-to-spoke with NHRP redirect + summary routes)** - RECOMMENDED for most branch scenarios:
- Hub sends NHRP redirect when spoke traffic arrives destined for another spoke
- Spokes install shortcut route and build direct tunnel
- OSPF summary routes work because routing sees tunnel network, not individual spoke routes
- Hub config: ip nhrp redirect on tunnel interface
- Spoke config: ip nhrp shortcut on tunnel interface
- Routing: BGP recommended at >100 spokes; OSPF works well at Phase 3 for medium scale
- Scale: tested to 1000+ spokes per hub with proper design

**FlexVPN (IKEv2 DVTI)** - RECOMMENDED for new deployments:
- Cisco-proprietary; requires IOS 15.2+ or IOS XE 3.5+
- IKEv2 only (no IKEv1 support) - cleaner, more secure, supports EAP and certificate auth
- Dynamic virtual tunnel interfaces (DVTI): each spoke gets a cloned virtual-access interface
- Supports hub-and-spoke, spoke-to-spoke (via IKEv2 redirect), and remote access in one framework
- Simpler config than DMVPN; no NHRP complexity for spoke-to-spoke
- Recommended over DMVPN for all new deployments where IKEv2 is acceptable
- Scale: similar to DMVPN Phase 3; limited by hub router CPU for IKEv2 session establishment

**GETVPN (Group Encrypted Transport VPN)** - for MPLS networks only:
- Designed specifically for MPLS private WAN — do NOT use over Internet
- No tunnel/overlay headers: preserves original source/destination IP
- Any-to-any encryption at Layer 3 without individual tunnels
- Key Server (KS) manages group keys; Group Members (GMs) are the routers
- Group TEK (Traffic Encryption Key): rotated periodically by KS via rekey
- KEK (Key Encryption Key): protects the rekey message
- Advantages over DMVPN on MPLS: no encapsulation overhead (MPLS QoS markings preserved), no overlay addressing
- Cooperative KS: primary + secondary KS for HA; GMs maintain registration with both
- Scale: hundreds of GMs per KS group

### 3. Phase Selection for DMVPN (if recommended)

Choose Phase based on requirements:
- No spoke-to-spoke needed: Phase 1 (simplest)
- Spoke-to-spoke <200 spokes, Cisco-only, EIGRP: Phase 2
- Spoke-to-spoke at scale, OSPF summarization, >200 spokes: Phase 3
- New deployment, modern platform, IKEv2: FlexVPN instead

### 4. Hub Redundancy Design

**Dual-hub DMVPN**:
- Two hub routers with different tunnel source IPs (e.g., 10.0.0.1 and 10.0.0.2 on different physical routers)
- Both hubs have full connectivity to all spokes
- Spokes configure two NHS entries (primary and secondary): ip nhrp nhs <hub1-tunnel-ip> nbma <hub1-NBMA>; ip nhrp nhs <hub2-tunnel-ip> nbma <hub2-NBMA>  
- Routing protocol prefers one hub (lower metric) with automatic failover
- Each hub uses different tunnel network: Hub1 on 10.1.0.0/24, Hub2 on 10.2.0.0/24

**FlexVPN dual-hub**:
- Each hub is an independent IKEv2 responder
- Spoke connects to both hubs via separate virtual-template-based sessions
- Routing prefers one hub; failover via BFD or routing metric

**GETVPN cooperative KS**:
- Primary KS: crypto gdoi group <name>; identity number <N>; server primary  
- Secondary KS: server secondary; syncs policy from primary
- GMs register with both; if primary fails, secondary promotes

### 5. Routing Protocol Over VPN

- **BGP** (recommended for >100 spokes): iBGP with hub as route reflector; spokes as clients; best path manipulation via local-pref and communities; no split-horizon issues; scales best
- **OSPF Phase 3**: configure hub tunnel as ip ospf network point-to-multipoint; spokes as standard OSPF; summarization works at Phase 3
- **EIGRP Phase 2**: ip summary-address eigrp <AS> <prefix> on hub; ip split-horizon eigrp may need to be disabled on hub tunnel
- **Static routes**: only for very small scale (< 10 spokes); manual, does not scale

### 6. Crypto Design for [Crypto / IKE requirement]

**IKEv2 (recommended)**:
- AES-256-GCM + SHA-384 + DH group 20 (384-bit ECC ECDH) — CCIE-level best practice
- Suite-B profile: AES-128/256-GCM + SHA-256/384 + ECDH group 19/20
- PSK: acceptable for <50 spokes; easy to deploy, hard to rotate at scale
- PKI (certificates): required for >50 spokes; use IOS CA server or external CA (DigiCert, internal PKI)
- PFS: always enable — DH group 14 minimum, prefer group 19 or 20

**IKEv1 (legacy only)**:
- Use only when forced by non-Cisco peer interop
- Phase 1: Main Mode (not Aggressive Mode — AM leaks group identity)
- Minimum: AES-128 + SHA-1 + DH group 5 (absolute minimum); prefer AES-256 + SHA-256 + DH 14

### 7. QoS Over VPN Tunnels
- Apply QoS to the **physical interface**, not the tunnel interface (QoS sees outer header after encryption)
- Exception: use qos pre-classify on the tunnel interface to copy inner DSCP to outer header before encryption
- GETVPN preserves inner DSCP — QoS works transparently on MPLS (no pre-classify needed)
- Three-class minimum: EF for voice (33%), AF41 for video (33%), default for data (remaining)
- Bandwidth reservation: voice and video traffic needs guaranteed minimum bandwidth on WAN uplink

### 8. Routing for Remote Access (if applicable)
- Split tunneling: only corporate subnets go through VPN; internet goes direct — reduces bandwidth on hub
- Full tunnel: all traffic through VPN — required for compliance environments (PCI-DSS, HIPAA)
- Split tunneling security risk: endpoint is connected to both corporate and potentially hostile internet simultaneously

### 9. Scale Limits and When to Re-evaluate
- DMVPN: practical limit ~1000 spokes per hub with BGP; above that, consider hierarchical DMVPN or SD-WAN
- FlexVPN: similar to DMVPN; limited by IKEv2 session setup rate on hub CPU
- GETVPN: hundreds of GMs per KS; cooperative KS for HA; no spoke-to-spoke tunnel setup overhead
- SD-WAN migration trigger: >500 sites, multi-transport (MPLS + Internet + LTE), application-aware routing needed

### 10. Migration from Current to Recommended Architecture
Provide a phased migration plan from [Existing platform] that avoids outages. Include a parallel-run phase where old and new tunnels coexist.