Perché serve un hub cloud
In uno scenario multicloud reale non basta collegare la fabric SD-WAN a una singola VPC: tipicamente esistono decine di VPC (produzione, sviluppo, servizi condivisi) più uno o più data center on-prem. Costruire tunnel punto-punto fra tutti questi elementi genera una topologia full-mesh ingestibile. La soluzione è un hub-and-spoke con un router cloud centrale: in AWS è il Transit Gateway (TGW), in Azure il Virtual WAN hub, in GCP il Network Connectivity Center. Il TGW è un router regionale che aggrega gli attachment e instrada il traffico fra di essi in base a route table dedicate.
Come si inserisce SD-WAN Cloud OnRamp
Cloud OnRamp for Multicloud (gestito da vManage / Catalyst SD-WAN Manager) automatizza il deployment di un Cloud Gateway basato su Catalyst 8000V (C8000V) in una Transit VPC. Il workflow è:
- Discovery: vManage scopre le host VPC dell’account AWS.
- Cloud Gateway: istanzia i C8000V e li aggancia al Transit Gateway già esistente o creato dall’automazione.
- Attachment TGW: il collegamento fra C8000V e TGW usa tipicamente il TGW Connect attachment (tunnel GRE + BGP per lo scambio dinamico delle rotte), preferito alle VPN attachment IPsec per la maggiore banda e la propagazione BGP nativa.
- Intent mapping: nella matrice Intent Management → Connectivity si mappano i segmenti SD-WAN (VPN) ai tag assegnati alle VPC.
Il C8000V diventa così il punto di giunzione fra la fabric OMP del SD-WAN e il piano di routing BGP del cloud.
Attachment e route table del Transit Gateway
Nel TGW due concetti vanno tenuti distinti e non vanno confusi:
| Concetto | Significato |
|---|---|
| Association | Ogni attachment è associato a una sola route table del TGW: determina quale tabella l’attachment consulta per instradare il traffico in uscita. |
| Propagation | Le rotte di un attachment vengono propagate (via BGP o statiche) dentro una route table, rendendole visibili agli altri attachment. |
La segmentazione si realizza usando route table TGW multiple, una per segmento logico. Un attachment di produzione associato e propagato solo nella route table “prod” non vedrà i prefissi di “dev”. Questa struttura deve rispecchiare 1:1 i segmenti (VPN) definiti in SD-WAN: la VPN 10 lato Cisco corrisponde a una specifica route table TGW, la VPN 20 a un’altra, e così via.
Propagazione fra segmenti e on-prem
Le rotte on-prem apprese dai branch arrivano al Cloud Gateway via OMP, vengono ridistribuite in BGP verso il TGW e propagate nelle route table dei segmenti autorizzati. In direzione opposta, i prefissi delle VPC vengono appresi via BGP dal C8000V, importati in OMP e distribuiti ai branch. Il Cloud Gateway agisce quindi da gateway di ridistribuzione OMP↔BGP, applicando la segmentazione end-to-end solo se la mappatura tag↔VPN è coerente con le route table del TGW.
La trappola: loop e perdita di segmentazione
Se le route table del TGW non rispecchiano la segmentazione SD-WAN nascono due classi di problema:
- Perdita di segmentazione: se più VPC di segmenti diversi vengono associate/propagate nella stessa route table (o nella default), i loro prefissi si mescolano e host di “prod” raggiungono host di “dev”, vanificando le VPN SD-WAN.
- Routing loop / rotte fantasma: se un prefisso appreso dal TGW viene ri-propagato verso lo stesso segmento da cui proviene, o se la ridistribuzione OMP→BGP→OMP non filtra le rotte già note, si formano loop o path sub-ottimali. Un uso improprio di rotte statiche/blackhole nel TGW insieme alla propagazione dinamica aggrava il fenomeno.
Trappole tipiche d’esame
- Scenario: due VPC di segmenti diversi comunicano quando non dovrebbero → Risposta: sono associate/propagate nella stessa route table TGW; creare route table separate per segmento e mappare i tag alle VPN corrette.
- Scenario: l’attachment vede le rotte ma non le usa in uscita → Risposta: manca l’association (è configurata solo la propagation). Association e propagation sono indipendenti.
- Scenario: serve throughput elevato e BGP dinamico fra C8000V e TGW → Risposta: usare TGW Connect attachment (GRE+BGP), non la VPN attachment IPsec.
- Scenario: prefissi on-prem non appaiono nelle VPC → Risposta: verificare la ridistribuzione OMP→BGP sul Cloud Gateway e la propagation verso la route table del segmento corretto.
- Scenario: loop dopo aggiunta di una rotta statica → Risposta: la rotta statica sovrascrive/duplica quella BGP propagata; allineare la mappatura segmento↔route table ed evitare ridistribuzione non filtrata.