Perché BGP sopra il tunnel

Nelle architetture di cloud connectivity il tunnel IPsec fornisce la confidenzialità del trasporto, ma da solo è statico. Aggiungendo eBGP sopra il tunnel (tipicamente su interfaccia VTI — Virtual Tunnel Interface — o su un GRE-over-IPsec) otteniamo scambio dinamico dei prefissi, failover automatico tra tunnel ridondanti e la possibilità di fare traffic engineering. Il router on-prem (spesso un IOS-XE, es. cloud router virtuale) stabilisce una sessione eBGP verso l’ASN annunciato dal gateway VPN del provider: essendo AS differenti, si usa eBGP, non iBGP.

Il peering avviene sugli inside address del tunnel (le APIPA / link-local assegnate dal provider) oppure sugli endpoint VTI. Punti chiave:

  • eBGP ha distanza amministrativa 20 e per default richiede TTL adiacente (il neighbor deve essere direttamente raggiungibile sul tunnel).
  • I timer di default IOS sono keepalive 60s / holdtime 180s; su link cloud instabili si abbina spesso BFD per convergenza sub-secondo.
  • Il provider annuncia i prefissi del VPC/VNet; noi annunciamo i prefissi on-prem.
router bgp 65001
 neighbor 169.254.21.1 remote-as 64512
 address-family ipv4
  neighbor 169.254.21.1 activate
  network 10.10.0.0 mask 255.255.0.0

Advertising controllato e ricezione

Non bisogna annunciare “tutto”. L’advertising va filtrato e sommarizzato:

  • Summarization: aggregare i subnet on-prem in poche supernet (es. un singolo 10.10.0.0/16 invece di 64 /24). Questo riduce la dimensione della tabella del gateway del provider, che ha limiti rigidi sul numero di prefissi accettati (tipicamente circa 100 rotte).
  • Prefix-list / route-map in uscita per controllare esattamente quali blocchi escono verso il cloud, evitando di ri-annunciare rotte apprese da Internet o da altri peer.
  • In ingresso, si accettano i prefissi del VPC/VNet e, se serve, si applica un filtro per non importare rotte indesiderate.

Route propagation nella route table del provider

Ricevere il prefisso via BGP sul gateway non basta: nella maggior parte dei provider occorre abilitare esplicitamente la route propagation sulle route table associate alle subnet, altrimenti le istanze non installano le rotte BGP e il traffico di ritorno non trova la via on-prem. È una configurazione lato provider (checkbox/attributo sulla subnet route table), non lato IOS-XE, ma è parte integrante del disegno end-to-end.

Traffic engineering con AS-path e local-preference

Con più tunnel/più connessioni si governa la selezione del percorso:

Attributo Direzione influenzata Comportamento
local-preference outbound (on-prem → cloud) valore più alto preferito; sceglie il tunnel di uscita
AS-path prepend inbound (cloud → on-prem) path più lungo meno preferito; si allunga sul tunnel di backup
MED inbound (se onorato) valore più basso preferito

Local-preference agisce solo internamente al nostro AS, quindi è lo strumento per decidere quale tunnel usiamo noi in uscita. Per influenzare quale tunnel il provider usa per raggiungerci (ritorno), non possiamo imporre local-pref al provider: usiamo AS-path prepending in uscita sul link secondario, così il gateway del cloud vede quel percorso più lungo e preferisce il primario. Progettare i due lati in modo coerente evita il routing asimmetrico (andata su un tunnel, ritorno sull’altro), che rompe stateful firewall e NAT.

route-map TO-CLOUD-BACKUP permit 10
 set as-path prepend 65001 65001 65001

Trappole tipiche d’esame

  • Scenario: instabilità e tabella del gateway cloud satura per centinaia di /24 annunciati → Risposta: applicare summarization (aggregate/supernet) in uscita e ridurre i prefissi sotto il limite del provider, non aumentare i timer.
  • Scenario: le istanze nel VPC/VNet non raggiungono l’on-prem pur avendo il peering BGP UP → Risposta: manca l’abilitazione della route propagation sulla route table della subnet lato provider.
  • Scenario: traffico che esce da un tunnel e rientra dall’altro, con drop sul firewall → Risposta: routing asimmetrico da attributi incoerenti; usare AS-path prepend sul backup per il ritorno e local-preference per l’uscita, allineando primario/secondario.
  • Scenario: si vuole che il cloud preferisca un percorso di ritorno specifico → Risposta: AS-path prepending in uscita (o MED se onorato), NON local-preference, che è locale al proprio AS e non transita verso il provider.
  • Scenario: sessione eBGP che non sale sul VTI → Risposta: verificare inside address del tunnel, remote-as corretto verso l’ASN del provider e adiacenza diretta (eBGP TTL), non la ridistribuzione dei prefissi.