La disponibilità di una connessione ibrida verso il cloud non dipende da un singolo tunnel IPsec, ma da come si combinano più tunnel, più endpoint e più edge on-prem. L’obiettivo di design è eliminare ogni single point of failure lungo l’intero percorso e definire in anticipo come il traffico si sposta quando un componente cade.

I due endpoint del gateway cloud

Il gateway VPN gestito del cloud provider espone tipicamente due endpoint su indirizzi pubblici distinti (spesso in due availability zone). Ogni endpoint termina un tunnel IPsec separato: si ottengono così due tunnel indipendenti per la stessa connessione. La regola di design è terminarli su infrastruttura fisica diversa lato on-prem, altrimenti la ridondanza è solo apparente.

Sopra i tunnel si costruisce il routing dinamico con eBGP: il gateway cloud e l’edge on-prem si scambiano prefissi, così il failover diventa una riconvergenza di routing invece che una riconfigurazione manuale. Si preferisce la route-based VPN (tunnel interface, VTI) proprio perché associa naturalmente una sessione BGP a ciascun tunnel.

Active/standby vs active/active

Modello Come si realizza Uso della banda Comportamento al guasto
Active/standby Un tunnel primario preferito, il secondario in backup Solo il tunnel primario porta traffico Riconvergenza sul secondario
Active/active Entrambi i tunnel installati e usati insieme Somma della banda dei due tunnel Il traffico resta sui tunnel superstiti

In active/standby si forza la preferenza con gli attributi BGP: local preference (o weight, locale a Cisco) per il traffico in uscita verso il cloud, e AS-path prepend o MED per influenzare il traffico in ingresso dal cloud verso on-prem. Il tunnel secondario resta up ma non è nel best path finché il primario non cade.

In active/active si punta al load-sharing con ECMP.

ECMP e load-sharing

BGP installa di default un solo best path. Per attivare il multipath serve maximum-paths N sotto address-family (e bgp bestpath as-path multipath-relax quando i due percorsi hanno AS-path diversi ma stessa lunghezza). Condizione perché ECMP funzioni: i percorsi devono essere equal-cost, quindi stessi attributi determinanti (weight, local preference, AS-path length, origin, MED). Se un design “active/active” applica un prepend o un local-pref asimmetrico, BGP degrada silenziosamente a un solo path e il secondo tunnel resta inutilizzato.

router bgp 65010
 address-family ipv4
  maximum-paths 2
  bgp bestpath as-path multipath-relax

Convergenza BGP e rilevamento guasti

Il punto debole del failover è quanto ci mette BGP ad accorgersi del guasto. Con i timer di default (keepalive 60s, holdtime 180s), un tunnel morto può restare nel best path per minuti. Le tecniche di accelerazione:

  • BFD: rilevamento sub-secondo del guasto di forwarding; BGP registra BFD e ritira subito la sessione. È il metodo preferito.
  • IPsec DPD (Dead Peer Detection): rileva il peer IKE morto, ma è più lento di BFD e agisce a livello di tunnel, non di next-hop.
  • Timer BGP ridotti: utili ma meno deterministici e più costosi in CPU rispetto a BFD.

In active/active con ECMP la convergenza è spesso migliore: la caduta di un tunnel non richiede di eleggere un nuovo best path, ma solo di rimuovere un path dal set già installato, mentre il traffico continua sui superstiti.

Il single edge on-prem

L’errore progettuale più comune: curare meticolosamente l’HA lato cloud (due endpoint, due tunnel, ECMP) e terminare tutto su un solo router edge on-prem. Quel router — o il suo unico link ISP — diventa il vero single point of failure e vanifica l’intera ridondanza a monte.

Il design corretto prevede due edge on-prem, ciascuno con tunnel verso entrambi gli endpoint cloud (topologia a maglia), sessioni BGP indipendenti e, dove possibile, ISP e alimentazione diversi. Il failover diventa così resiliente sia al guasto di un tunnel, sia alla perdita di un intero apparato on-prem.

Trappole tipiche d’esame

  • Scenario: cloud con due endpoint ridondati ma un solo router on-prem → la topologia NON è ad alta disponibilità; l’edge on-prem è un SPOF. Vanno raddoppiati anche gli apparati on-prem.
  • Scenario: si vuole load-sharing su entrambi i tunnel ma passa uno solo → manca maximum-paths (default 1) o i path non sono equal-cost per attributi BGP asimmetrici.
  • Scenario: richiesto failover deterministico active/standby → usare local preference in uscita e AS-path prepend/MED in ingresso, non lasciare i due tunnel a parità di attributi.
  • Scenario: failover troppo lento (minuti) con timer BGP di default → introdurre BFD per convergenza sub-secondo, non affidarsi al solo holdtime di 180s o al DPD.
  • Scenario: ECMP con AS-path di uguale lunghezza ma AS diversi che non bilancia → serve bgp bestpath as-path multipath-relax.