BGP e route propagation sugli interconnect privati

Sui circuiti dedicati verso il cloud provider — che si tratti di Direct Connect, ExpressRoute, Cloud Interconnect o Megaport/equinix come intermediari — il routing dinamico si realizza quasi sempre con BGP su una sessione eBGP stabilita sul private peering. Comprendere quali prefissi vengono annunciati, come vengono propagati verso le VPC/VNet e come si controlla l’inbound è il cuore del dominio “cloud connectivity” dell’esame ENCC.

eBGP sul private peering

Sull’interconnect privato l’on-prem (o l’edge router del cliente) e il cloud edge appartengono ad AS diversi, quindi la sessione è eBGP. Tipicamente:

• il cliente usa un ASN privato (64512–65534, o 32-bit 4200000000+) oppure il proprio ASN pubblico;
• il cloud provider espone un ASN lato provider (es. Amazon usa 7224 su DX, Google 16550 su Interconnect, il provider Azure MSEE per ExpressRoute);
• la sessione gira su una /30 o /31 di transit dedicata al peering, spesso una coppia ridondata per l’alta disponibilità.

router bgp 65010
 neighbor 169.254.10.1 remote-as 7224
 address-family ipv4 unicast
  neighbor 169.254.10.1 activate
  network 10.0.0.0 mask 255.255.0.0

Punto chiave: l’eBGP di default ha ebgp-multihop 1, quindi il peer deve essere direttamente adiacente sul segmento di interconnect. Se si frappone un provider L3 il design cambia.

Prefissi annunciati e ricevuti

La direzione dei prefissi va tenuta ben distinta:

I provider impongono limiti sul numero di prefissi (es. ordine di poche centinaia a 1000 route per sessione): superarli fa cadere la sessione. Di qui l’importanza dell’aggregazione (summarization) lato on-prem. Attenzione anche al fatto che molti cloud non ripropagano i prefissi ricevuti da un peering verso un altro (no transit tra due connessioni distinte senza servizi come Transit Gateway/vWAN/Cloud Router).

Route propagation verso VPC/VNet

I prefissi appresi via BGP non finiscono automaticamente in ogni subnet: devono essere propagati nelle route table della VPC/VNet. In genere è un’associazione esplicita tra il gateway (VGW/Transit Gateway, ExpressRoute Gateway, Cloud Router) e la route table, con route propagation abilitata. Una subnet con propagation disattivata semplicemente non “vede” l’on-prem, anche se BGP è up.

BGP community e controllo dell’inbound

Le BGP community sono lo strumento principale per influenzare il comportamento su circuiti multipli:

• alcuni provider usano community per marcare la regione o il livello di ridondanza del prefisso ricevuto (utile per preferire l’accesso locale);
• lato outbound il cliente può taggare i propri annunci per segnalare la preferenza.

Per controllare l’inbound (come il cloud/Internet-side sceglie di raggiungere l’on-prem) gli attributi disponibili sono:

• AS-path prepending: allunga l’AS-path sull’annuncio meno preferito → rende quel percorso meno appetibile per il peer remoto;
• MED: suggerisce la preferenza tra più link verso lo stesso AS (ma è confrontato solo a parità di AS di provenienza e spesso ignorato cross-provider);
• community concordate con il provider.

Ricorda: local-preference è locale al proprio AS e governa solo l’outbound; non lo si “esporta” al peer.

Interconnect + VPN backup: il rischio asimmetria

Lo scenario classico d’esame: interconnect privato come primario e VPN IPsec come backup, entrambi attivi. Se non si manipolano gli attributi, il traffico può uscire dall’interconnect e rientrare dalla VPN (o viceversa) → routing asimmetrico, che rompe stateful firewall e NAT.

Il design corretto:

• Outbound (on-prem → cloud): alza la local-preference sui prefissi ricevuti dall’interconnect così che sia sempre preferito rispetto alla VPN.
• Inbound (cloud → on-prem): fai AS-path prepending sugli annunci mandati via VPN, così il cloud preferisce l’interconnect per rientrare. In alternativa, community/weight lato provider dove supportato.

Entrambe le direzioni vanno allineate: agire su una sola metà lascia l’asimmetria.

Trappole tipiche d’esame

• Sessione BGP up ma subnet non raggiunge l’on-prem → la route propagation non è abilitata sulla route table della VPC/VNet; BGP funziona ma le route non sono installate nella subnet.
• Traffico simmetrico sul primario ma asimmetrico al failover parziale → è stata impostata solo la local-preference (outbound) e non l’AS-path prepending sulla VPN (inbound): correggi entrambe le direzioni.
• Vuoi che il cloud preferisca l’interconnect per rientrare on-prem → AS-path prepending sull’annuncio VPN, NON local-preference (che è locale e non influenza il peer).
• La sessione BGP cade dopo aver aggiunto molte subnet on-prem → superato il maximum-prefix del provider: aggrega/summarizza gli annunci.
• Due interconnect distinti e ci si aspetta transito tra loro → il cloud provider non fa transit tra peering separati senza un servizio dedicato (Transit Gateway/vWAN/Cloud Router hub); non basta il BGP end-to-end.