La resilienza WAN è un tema centrale in ENSLD: il progettista deve scegliere la tecnologia di overlay/encryption più adatta al trasporto (Internet vs MPLS privato) e garantire che nessun componente singolo comprometta l’intera connettività di sito. Vediamo DMVPN, il confronto con IPsec e GETVPN, e i pattern di alta disponibilità.
DMVPN: overlay scalabile hub-and-spoke
DMVPN (Dynamic Multipoint VPN) risolve il problema della scalabilità delle VPN site-to-site combinando tre ingredienti:
- mGRE (multipoint GRE): una singola interfaccia tunnel sull’hub serve tutti gli spoke, eliminando la configurazione point-to-point per ogni sito.
- NHRP (Next Hop Resolution Protocol): gli spoke si registrano dinamicamente presso l’hub (NHS) e risolvono l’indirizzo pubblico (NBMA) di un altro spoke per costruire tunnel diretti on-demand.
- IPsec (opzionale ma consigliato): protegge il traffico dell’overlay, tipicamente in transport mode con profili IPsec.
Un routing protocol (EIGRP, OSPF, BGP) gira sopra l’overlay per distribuire le rotte delle LAN interne.
Le tre Phase
| Phase | Spoke-to-spoke | Summarization sull’hub | Scalabilità |
|---|---|---|---|
| 1 | No (tutto via hub) | Sì | Bassa |
| 2 | Sì (diretto) | No (next-hop deve essere preservato) | Media |
| 3 | Sì (via NHRP redirect/shortcut) | Sì | Alta |
Phase 1 forza tutto il traffico attraverso l’hub: semplice ma l’hub diventa collo di bottiglia. Phase 2 abilita tunnel spoke-to-spoke diretti, ma richiede che l’hub preservi il next-hop (quindi niente summarization e, con EIGRP, no ip next-hop-self). Phase 3 è la scelta di design moderna: l’hub invia messaggi NHRP redirect, lo spoke installa una shortcut route verso l’altro spoke, e questo permette di rimettere la summarization sull’hub. Il risultato è la topologia più scalabile per reti con centinaia di sedi.
IPsec puro vs GETVPN
- IPsec site-to-site classico (crypto map o VTI): ottimo per pochi tunnel punto-punto, ma in una full mesh richiede n·(n-1)/2 tunnel — ingestibile oltre poche sedi.
- GETVPN (Group Encrypted Transport VPN): tunnel-less. Usa GDOI con un Key Server che distribuisce chiavi di gruppo ai Group Members. La caratteristica chiave è la IP header preservation: l’header IP originale resta intatto, quindi il routing any-to-any del transport gestisce direttamente il traffico cifrato. È la soluzione ideale su MPLS L3VPN privato dove serve cifratura any-to-any senza overlay routing.
Regola di design: DMVPN vince su trasporti Internet/pubblici (gli indirizzi interni non sono routabili nella rete del provider, serve l’overlay). GETVPN vince su reti private any-to-any (MPLS), ma non è adatto a Internet perché l’header preservato espone indirizzi privati non instradabili e mal si concilia con il NAT.
Alta disponibilità WAN
Il design resiliente combina più livelli:
- Dual-homing: un CE con due uplink, verso due PE dello stesso provider o verso due provider diversi (provider diversity), sfruttando BGP multihoming per la selezione dei path.
- Dual-router / dual-CE: due router di edge con HSRP/VRRP lato LAN per eliminare il SPOF sul dispositivo.
- Backup link e failover: un link primario MPLS con un secondario DMVPN su Internet. Il failover si governa con metriche/AD del routing, floating static route e soprattutto IP SLA + object tracking per rilevare guasti “soft” (il link è up ma il path è down).
- Dual-hub DMVPN: per evitare che l’hub sia SPOF, si usano due hub — in dual-cloud (due tunnel separati, uno per hub) o single-cloud dual-hub — con preferenze di routing che designano hub primario e secondario.
La logica di progetto è sempre la stessa: identificare ogni SPOF (dispositivo, link, provider, sito hub) e neutralizzarlo con ridondanza appropriata al livello di criticità e al budget.
Trappole tipiche d’esame
- Scenario: full mesh cifrata su Internet per centinaia di sedi, con esigenza di summarization sull’hub → risposta: DMVPN Phase 3 (redirect/shortcut abilitano spoke-to-spoke e summarization; Phase 2 non permette summarization).
- Scenario: cifratura any-to-any su MPLS privato senza gestire tunnel/overlay → risposta: GETVPN (tunnel-less, header preservation), non DMVPN.
- Scenario: il cliente ha un solo hub DMVPN in un solo datacenter → risposta: introdurre un secondo hub (dual-hub/dual-cloud): l’hub singolo è un SPOF che isola tutti gli spoke.
- Scenario: due link WAN ma verso lo stesso provider → risposta: usare provider diversi (provider diversity): un guasto di backbone o una manutenzione del provider abbatte entrambi i link se il fornitore è unico.
- Scenario: link di backup che non entra in servizio benché “up” durante un blackout applicativo → risposta: aggiungere IP SLA con object tracking, perché il solo stato di interfaccia non rileva i guasti end-to-end del path.