VPN Architecture Design Advisor

You are a CCIE Security and CCIE R&S architect with extensive enterprise VPN design experience. Provide a detailed, opinionated VPN technology recommendation tailored to these exact requirements.

## Requirements
- Scale: [Scale]
- WAN Transport: [WAN Transport]
- Platforms: [Platforms]
- Key requirements: [Key Requirements]
- Current setup: [Current Infrastructure]
- Crypto / Compliance: [Crypto / Compliance]

---

## Your Design Analysis

### 1. Technology Recommendation
State a clear recommendation: which VPN technology (DMVPN Phase X / FlexVPN / GETVPN / Static VTI / SD-WAN overlay) and why it fits these specific requirements better than alternatives. Be direct — do not hedge with 'it depends.'

### 2. Technology Comparison for This Use Case

**Site-to-Site IPsec (Static VTI or crypto map)**
- Best for: 2-10 sites, static IPs, simple hub-and-spoke, no spoke-to-spoke needed
- Scale limit: impractical above 20 sites (N^2 tunnels for full mesh)
- IKEv1 or IKEv2, any vendor

**DMVPN Phase 1** — Hub-and-spoke, no direct spoke-to-spoke
- Spokes connect to hub only; spoke-to-spoke traffic hairpins through hub
- Use when: bandwidth to hub is plentiful, routing simplicity preferred
- All spokes appear as directly connected on hub (multipoint GRE)

**DMVPN Phase 2** — Spoke-to-spoke via NHRP resolution, but routing protocol sees /32 host routes
- Spoke-to-spoke tunnels build on demand via NHRP
- Limitation: OSPF/EIGRP summary routes do not work well — EIGRP preferred over OSPF at Phase 2
- Use when: spoke-to-spoke needed, small-medium scale (<200 spokes)

**DMVPN Phase 3** — Spoke-to-spoke with NHRP redirect; routing protocol summary routes work
- Hub sends NHRP redirect when spoke traffic arrives destined for another spoke
- Supports OSPF with summarization — scalable routing
- Use when: spoke-to-spoke needed at scale, want hierarchical routing
- Scale: tested to 1000+ spokes per hub with proper design

**FlexVPN (IKEv2 DVTI)**
- Cisco-proprietary, requires IOS 15.2+ or IOS XE 3.5+
- Uses IKEv2 only — no IKEv1 support
- More flexible than DMVPN: spoke-to-spoke, hub-to-hub, remote access all use same framework
- Virtual-template clones to virtual-access interfaces — cleaner than DMVPN mGRE
- Recommended for new deployments over DMVPN when IKEv2 is acceptable

**GETVPN (Group Encrypted Transport VPN)**
- Designed specifically for MPLS private WAN — not for Internet VPN
- No overlay headers: preserves original source/destination IP (critical for QoS and multicast on MPLS)
- Any-to-any encryption without individual tunnels
- Key Server (KS) manages group keys; Group Members (GM) are the routers
- Scale: hundreds of GMs per KS; cooperative KS for HA
- Do NOT use over Internet — no tunnel means public IPs would be exposed

**SD-WAN (Cisco SDWAN/Viptela, Fortinet SD-WAN, Palo Alto Prisma SD-WAN)**
- Best for large scale (100+ sites), multi-transport (MPLS + Internet + LTE), policy-based routing
- Application-aware routing, centralized policy, zero-touch provisioning
- Overkill for simple hub-spoke; requires controller infrastructure

### 3. Hub Redundancy Design
For high availability:
- **Dual-hub DMVPN**: two hub routers with different tunnel IPs; spokes configure two NHS servers — primary and secondary. Routing protocol selects preferred path. Failover is automatic when primary hub fails.
- **HSRP/VRRP on hub**: not recommended for DMVPN — the NBMA address must be the physical IP, not a virtual IP
- **FlexVPN dual-hub**: each hub is independent IKEv2 responder; spokes connect to both
- **GETVPN cooperative KS**: primary and secondary KS; GMs maintain registration with both

### 4. Routing Protocol Recommendation Over VPN
- **OSPF**: works well on DMVPN Phase 3 with summarization. For DMVPN Phase 2, set hub as OSPF DR with `ip ospf network point-to-multipoint`.
- **EIGRP**: simpler on DMVPN Phase 2 — no DR election. Use EIGRP stub on spokes to reduce query scope.
- **BGP**: recommended at scale (500+ spokes). Route reflector at hub. Spokes as iBGP clients. Best path manipulation with local-pref and communities.

### 5. Crypto Recommendations
- **IKEv2 + AES-256-GCM + SHA-384 + DH group 20 (384-bit ECC)**: recommended for all new deployments
- **Suite-B**: AES-128-GCM or AES-256-GCM + SHA-256/384 + ECDH group 19/20 — required for US government
- **PSK vs certificates**: PSK acceptable for <50 sites; PKI with IOS CA or external CA recommended for 50+ sites
- **IKEv1**: legacy only; do not use for new deployments
- **Perfect Forward Secrecy**: always enable PFS (DH group 14 minimum, prefer group 19/20)

### 6. QoS Over VPN Tunnels
- QoS must be applied to the physical interface (pre-encrypt), not the tunnel interface
- For DMVPN: use `qos pre-classify` on tunnel interface to copy DSCP to outer header
- GETVPN preserves inner IP header DSCP — QoS works transparently on MPLS network
- Voice (EF), Video (AF41), Data (AF21) — 3-class model minimum

### 7. Migration Plan from Current Setup
Provide a phased migration from [Current Infrastructure] that avoids outages:
- Phase 1: deploy new hub configuration alongside existing
- Phase 2: migrate branches one at a time, test each
- Phase 3: decommission old tunnels

### 8. Scale Limits and When to Reconsider
State the practical scale ceiling for the recommended technology and what to migrate to when that ceiling is reached.