Perché un C8000V invece del gateway VPN nativo

Ogni hyperscaler offre un gateway VPN nativo (managed) capace di terminare tunnel IPsec verso l’on-prem. È semplice e senza manutenzione, ma il suo set di funzioni è volutamente limitato: crypto e IKE fissi, poche opzioni di routing, nessun supporto per GRE, DMVPN/FlexVPN/GETVPN, VRF multiple, QoS, NAT avanzato o firewall integrato, e spesso un tetto rigido al numero di tunnel e alle policy BGP.

Il Catalyst 8000V è la versione virtuale della piattaforma edge Catalyst 8000 e porta IOS-XE completo dentro la rete virtuale del cloud. Lo si sceglie quando lo scenario richiede feature che il gateway nativo non espone: overlay DMVPN/FlexVPN verso molte sedi, GRE-over-IPsec per trasportare multicast, VRF-aware IPsec, route-map e policy BGP granulari, o l’inserimento del router cloud in un design SD-WAN. In pratica: serve funzionalità IOS-XE superiore al gateway nativo → C8000V.

Terminazione IPsec: VTI e route-based VPN

Il C8000V termina i tunnel con approccio route-based su Virtual Tunnel Interface (VTI) e IKEv2, non policy-based. Il traffico da cifrare è quello instradato verso la Tunnel interface, non selezionato da una crypto ACL. Questo abilita il routing dinamico dentro il tunnel.

crypto ikev2 profile PROF
 match identity remote address 203.0.113.10
interface Tunnel1
 ip address 169.254.1.1 255.255.255.252
 tunnel source GigabitEthernet1
 tunnel mode ipsec ipv4
 tunnel destination 203.0.113.10
 tunnel protection ipsec profile IPSEC_PROF

La coppia in High Availability

In cloud il C8000V è un’istanza singola: per eliminare il single point of failure si deploya una coppia in HA, tipicamente in due Availability Zone diverse. La ridondanza IOS-XE per il cloud (redundancy group / cloudha) fa sì che, al failover, il nodo superstite chiami le API del cloud provider per riscrivere la route table e puntare il next-hop su di sé. Il rilevamento del guasto avviene via BFD, tunnel monitoring o perdita del peering BGP.

Requisito spesso trascurato: l’istanza deve avere una identity/role con i permessi IAM per modificare le route table via API, altrimenti il failover non aggiorna il routing e il traffico resta orfano. In alternativa (o in aggiunta) si usa BGP come meccanismo di convergenza: entrambe le istanze annunciano i prefissi e la rimozione dell’annuncio del nodo guasto sposta il traffico, senza dipendere dalla riscrittura via API.

Route table del cloud e integrazione BGP

La cifratura è solo metà del lavoro: i workload nella rete virtuale devono instradare verso il C8000V. Nella route table delle subnet, le rotte verso i prefissi on-prem devono avere come next-hop l’interfaccia (ENI) del C8000V. Va inoltre disabilitato il source/destination check sull’interfaccia, altrimenti il cloud scarta i pacchetti in transito che non sono destinati all’istanza stessa.

Il piano di controllo è BGP sulla VTI (IP link-local 169.254.x.x): il C8000V fa peering con il router on-prem, riceve i prefissi aziendali e annuncia le subnet cloud. Così il routing è dinamico e coerente con l’HA.

router bgp 65010
 neighbor 169.254.1.2 remote-as 65001
 address-family ipv4
  network 10.20.0.0 mask 255.255.0.0

Attenzione alla distinzione dei piani: BGP popola la routing table dentro IOS-XE, mentre la route table del cloud governa il traffico dei workload verso l’ENI. Sono due tabelle diverse e vanno allineate entrambe.

Il compromesso: controllo vs overhead operativo

Il C8000V dà pieno controllo e ricchezza funzionale, ma trasforma il gateway in un’istanza da gestire: sizing di vCPU/throughput, smart licensing con tier di throughput che limita la banda cifrata a prescindere dalla taglia della VM, patching di IOS-XE, monitoraggio, e la necessità di progettare l’HA. Il gateway nativo è PaaS — zero manutenzione ma controllo minimo. La scelta è di design: si accetta l’overhead operativo solo quando le feature IOS-XE sono realmente richieste; altrimenti il nativo è la risposta corretta.

Trappole tipiche d’esame

  • Serve DMVPN/FlexVPN, GRE, VRF-aware IPsec o policy BGP avanzate che il gateway nativo non supporta → deploy del C8000V, non il gateway managed.
  • Traffico dei workload non raggiunge l’on-prem pur con tunnel UP → nella route table del cloud il next-hop non punta all’ENI del C8000V e/o il source/dest check è abilitato.
  • Failover HA non riinstrada il traffico → all’istanza manca il ruolo/permesso IAM per riscrivere le route table via API; in alternativa usa BGP per la convergenza.
  • Throughput inferiore all’atteso su VM grande → limite del tier di licenza throughput, non della CPU.
  • Serve routing dinamico ridondante nel tunnel → VPN route-based su VTI con BGP, non policy-based con crypto ACL (che è statica e mal si presta all’HA).