Requisiti di routing e indirizzamento IP

Routing verso il cloud: la decisione di fondo

Quando estendi la rete on-prem verso una VPC/VNet, la prima scelta di design è come far conoscere i prefissi ai due lati. Le opzioni sono due: routing dinamico con BGP oppure rotte statiche. Non è una preferenza estetica: determina la scalabilità, la resilienza e il costo operativo dell’intera connettività cloud.

BGP dinamico vs rotte statiche

Con BGP (tipicamente eBGP verso il border/gateway del provider, spesso via IPsec VPN o Direct Connect/ExpressRoute-like), i prefissi vengono annunciati e ritirati automaticamente. Il vantaggio principale è la reattività: se un tunnel cade, BGP ritira le rotte e il traffico converge sul path alternativo senza intervento manuale. È la scelta obbligata quando:

• hai più tunnel/circuiti ridondati e vuoi failover automatico;
• il numero di subnet cambia nel tempo (annunci un summary e aggiungi subnet senza toccare la config);
• vuoi fare traffic engineering con AS-path prepending, LOCAL_PREF, MED o filtri con route-map/prefix-list.

Le rotte statiche restano valide per topologie piccole e stabili: un singolo tunnel, pochi prefissi, nessun requisito di failover dinamico. Sono deterministiche e semplici, ma richiedono un object-tracking (es. IP SLA) per rilevare i guasti, altrimenti la rotta resta installata anche a tunnel morto (black-hole).

Come il provider propaga i prefissi: route table e UDR

Nel cloud il forwarding non è governato dal solo routing protocol: ogni subnet è associata a una route table gestita dal provider. Il sistema installa automaticamente le rotte per il CIDR locale della VPC/VNet e per le rotte apprese via BGP dal gateway. Il punto critico d’esame è che puoi sovrascrivere quel comportamento con le User Defined Routes (UDR): rotte statiche a livello di subnet che forzano il next-hop (tipicamente un’appliance NVA come un firewall Firepower, un router IOS-XE o un load balancer).

Le UDR servono a:

• forzare il traffico attraverso un’ispezione (default route 0.0.0.0/0 verso l’NVA per far passare tutto da un firewall);
• realizzare topologie hub-and-spoke, dove gli spoke non hanno peering diretto e il transito passa dall’hub;
• preferire un path rispetto a quello che il provider sceglierebbe di default.

Ricorda la longest-prefix match: una UDR più specifica batte sempre la rotta di sistema o quella BGP, e questo è spesso la causa di traffico che “sparisce” verso un next-hop sbagliato.

Overlapping CIDR: il problema strutturale

Se on-prem usa 10.0.0.0/16 e la VNet usa anche 10.0.0.0/16 (o un blocco che si sovrappone), il peering/VPN non funziona: gli indirizzi non sono univoci e il routing non può distinguere le destinazioni. Molti provider rifiutano direttamente il peering con address space sovrapposti. Le mitigazioni, in ordine di preferenza:

1. Ridisegno dell’address space (la soluzione pulita): riallocare uno dei due lati su un range non sovrapposto. Costoso se già in produzione, ma elimina il problema alla radice.
2. NAT (statico o pool): tradurre gli indirizzi sovrapposti in un range “shadow” non conflittuale su un’appliance NAT (IOS-XE, firewall). Funziona ma aggiunge complessità, rompe la visibilità end-to-end e complica troubleshooting e servizi che embeddano IP nel payload.
3. Limitare l’esposizione: annunciare solo le subnet che devono comunicare, riducendo la superficie di sovrapposizione.

Perché il dimensionamento è la decisione più costosa

L’indirizzamento IP nel cloud è difficile da cambiare a posteriori: rinumerare subnet significa toccare NSG/security group, UDR, DNS, endpoint, firewall rule e spesso ricreare risorse. Sottodimensionare un blocco (es. /27 dove servirà un /24) porta a frammentazione o a nuovi CIDR aggiunti in modo disordinato, che rompono la summarization BGP. Riserva spazio in eccesso, allinea la gerarchia dei prefissi (blocchi contigui summarizzabili) e coordina l’IPAM tra on-prem e cloud prima del deployment.

Trappole tipiche d’esame

• Scenario: due tunnel ridondati verso il cloud, serve failover automatico → BGP dinamico, non rotte statiche (le statiche non convergono da sole senza IP SLA/tracking).
• Scenario: on-prem e VNet condividono lo stesso CIDR e il peering non si stabilisce → soluzione corretta è ridisegnare l’address space; il NAT è la mitigazione ripiego solo quando la rinumerazione è impraticabile.
• Scenario: il traffico deve passare da un firewall NVA per ispezione → UDR con default route 0.0.0.0/0 verso il next-hop dell’appliance, sfruttando la precedenza delle UDR sulle rotte di sistema.
• Scenario: aggiungi molte subnet nel tempo → annuncia un summary via BGP invece di gestire decine di statiche; richiede però blocchi contigui pianificati in anticipo.
• Scenario: traffico verso una destinazione finisce nel next-hop sbagliato → una UDR più specifica (longest-prefix match) sta scavalcando la rotta BGP/di sistema; verifica la route table della suballa subnet.