Il Cisco Catalyst 8000V (abbreviato C8000V) è un’istanza software di IOS-XE — lo stesso sistema operativo dei router fisici della serie Catalyst 8000 — impacchettata come macchina virtuale. È il successore diretto del CSR 1000V e viene deployato come workload all’interno di una VPC (AWS/GCP) o di una VNet (cloud provider generico), dove agisce da router perimetrale programmabile. Il valore chiave è portare il set di feature enterprise di IOS-XE dentro un ambiente cloud in cui, nativamente, esistono solo gateway gestiti con funzionalità limitate.
Ruolo nella cloud connectivity
Nel design ENCC il C8000V svolge tre funzioni fondamentali:
- Terminazione IPsec: stabilisce tunnel site-to-site verso il data center on-premise, verso altri cloud o verso rami remoti. Sfrutta l’accelerazione crittografica AES-NI della CPU host per throughput elevato.
- Routing dinamico con BGP: instaura peering eBGP/iBGP per scambiare prefissi con il resto della rete e con i gateway del provider, con controllo pieno su route-map, prefix-list, AS-path prepending e comunità.
- Integrazione SD-WAN: può operare in autonomous mode (IOS-XE tradizionale) oppure in controller mode, registrandosi a Catalyst SD-WAN Manager (vManage) come edge cloud all’interno del fabric SD-WAN.
Sizing e throughput licenziato
Il throughput non dipende solo dalle risorse assegnate ma è capato dalla licenza. Più vCPU si allocano, più sessioni crypto e code il router può gestire; la licenza definisce poi il tetto aggregato.
| Aspetto | Comportamento |
|---|---|
| Modelli di licenza | BYOL (Bring Your Own License, tramite Smart Licensing) e PAYG (Pay As You Go, a consumo dal marketplace del cloud) |
| Tier di throughput | Scalabili da poche decine di Mbps fino a più Gbps; il tier scelto limita la banda utile |
| Livelli di feature | Network Essentials, Advantage, Premier (DNA licensing) |
| Fattore di scala | Il throughput reale cresce con il numero di vCPU/vNIC assegnate alla VM |
Regola pratica: se un tunnel IPsec non raggiunge la banda attesa, la causa più frequente è il tier di licenza o un numero di vCPU insufficiente, non la rete del provider.
Posizionamento: hub o edge
Il C8000V è tipicamente collocato in una transit VPC/VNet con topologia hub-and-spoke: i workload delle VPC/VNet spoke instradano verso l’hub, dove il C8000V concentra tunnel, policy e routing verso l’esterno. In alternativa funge da edge di una singola VPC/VNet quando serve un’uscita cifrata e controllata. Per alta disponibilità si deployano due istanze in availability zone diverse, con failover gestito via BGP e, sui cloud che lo supportano, riprogrammazione delle route table del provider.
Cloud router Cisco vs gateway nativi
I gateway nativi del provider (VPN gateway, transit gateway) sono semplici da attivare ma limitati. Conviene un C8000V quando servono feature IOS-XE avanzate o uniformità operativa con l’infrastruttura esistente.
| Criterio | Gateway nativo provider | Catalyst 8000V |
|---|---|---|
| Routing | BGP con opzioni ridotte | BGP completo + route-map, policy-based routing |
| Feature avanzate | Limitate | QoS, NAT, NetFlow, ZBFW, IPsec granulare, GRE |
| Uniformità operativa | Modello per-cloud diverso | Stessa CLI/IOS-XE on-prem e multicloud |
| SD-WAN | Non nativo | Edge integrato nel fabric Catalyst SD-WAN |
| Automazione | API proprietarie | NETCONF/RESTCONF, modelli YANG, template SD-WAN |
Il vantaggio decisivo è operativo: un unico modello di configurazione e di troubleshooting valido su on-premise e su qualsiasi cloud, con lo stesso strumentario (SD-WAN Manager, ThousandEyes, Model-Driven Telemetry).
Integrazione con Cloud OnRamp
In scenari multicloud, Cloud OnRamp for Multicloud automatizza il deployment del C8000V dentro una transit VPC/VNet, agganciandolo al fabric SD-WAN e programmando l’interconnessione con le VPC/VNet host. Questo trasforma il cloud router in un gateway SD-WAN cloud gestito centralmente, con application-aware routing e policy coerenti end-to-end.
Trappole tipiche d’esame
- Scenario: il throughput IPsec è inferiore alle attese pur avendo banda disponibile → Risposta: verificare il tier di licenza e il numero di vCPU assegnate; il cap è imposto dalla licenza, non dal cloud.
- Scenario: serve routing avanzato (route-map, PBR, NAT complesso) tra cloud e on-prem → Risposta: Catalyst 8000V, non il VPN gateway nativo, che non offre quelle feature.
- Scenario: si vuole gestire il router cloud dallo stesso controller degli edge fisici → Risposta: deployarlo in controller mode registrato a Catalyst SD-WAN Manager, non in autonomous mode.
- Scenario: requisito di HA in una regione cloud → Risposta: due istanze C8000V in AZ separate con failover via BGP e aggiornamento delle route table del provider, non una singola istanza più grande.
- Scenario: il cliente cerca uniformità operativa e riuso delle competenze IOS-XE su più cloud → Risposta: cloud router Cisco per CLI e feature set identici, evitando modelli operativi diversi per ogni provider.