Perché una rotta di sottorete in AWS VGW non può scegliere un solo tunnel VPN

Due connessioni Site-to-Site VPN terminano su un unico gateway privato virtuale e annunciano lo stesso prefisso di sede. La tabella delle rotte della sottorete contiene una voce per quel prefisso, puntata al gateway, e nessun campo che nomini un tunnel. La preferenza tra le connessioni avviene quindi in un punto che la console non etichetta come routing. Sapere quale livello possiede la decisione è la differenza tra uno standby che funziona e una modifica che non fa nulla.

Ci sono due livelli in gioco: la rotta della VPC che dice quale gateway, e la scelta del tunnel da parte del gateway stesso. Confonderle produce modifiche che sembrano corrette nella tabella delle rotte e non spostano mai un pacchetto.

Due livelli che sembrano uno

La rotta di sottorete risponde a una sola domanda: per questa destinazione, quale attachment? Il suo bersaglio è il gateway privato virtuale, e la sua metrica compete solo con altre rotte della stessa tabella. Nulla in quella voce distingue il tunnel uno dal tunnel due, né la connessione A dalla connessione B. Un prefisso più specifico è un’altra corrispondenza di destinazione, non una scelta di percorso più fine.

Il gateway risponde alla domanda successiva: tra i tunnel che mantiene per quel prefisso, quale trasporta traffico adesso. Questa decisione deriva dalla salute del tunnel e dagli attributi BGP ricevuti dal gateway del cliente, e non compare mai nella tabella delle rotte della sottorete.

Che cosa confronta davvero il VGW

La salute viene prima. Un tunnel abbassato, o una sessione BGP che non è salita, perde prima che qualsiasi attributo venga esaminato. Per questo anteporre un percorso su una connessione che già fallisce non cambia nulla.

Tra i percorsi idonei per lo stesso prefisso, AWS preferisce l’AS_PATH più corto. Quando due percorsi hanno la stessa lunghezza confronta il MED, soggetto alla condizione documentata sul primo AS del percorso. Legga l’ordine pubblicato e non la versione del folclore, perché il folclore di solito omette il passo della salute e l’eccezione delle rotte statiche. Una conseguenza: tre anteposizioni sulla connessione di backup rendono la primaria strettamente più corta, ed è il modo abituale di esprimere la preferenza.

Anteporre, e quando non fa nulla

L’anteposizione avviene negli annunci in uscita del gateway del cliente, non dentro AWS. Si aggiunge il proprio ASN due o tre volte al prefisso che si vuole che AWS eviti, e AWS vede allora un percorso più lungo per quella connessione. La connessione primaria conserva l’annuncio senza anteposizione. Se entrambe le connessioni annunciano dallo stesso ASN con lo stesso numero di anteposizioni, non si è espressa alcuna preferenza.

Controlli il percorso ricevuto sul lato AWS dopo la modifica. Un’anteposizione che non ha mai lasciato il dispositivo del cliente appare esattamente come una che AWS ha ignorato.

Le rotte statiche ignorano l’intero argomento

Se la connessione usa il routing statico non c’è alcun AS_PATH da allungare. AWS documenta le rotte VPN statiche come prioritarie rispetto alle rotte apprese tramite BGP per lo stesso prefisso, quindi un progetto misto non si comporta come uno completamente dinamico. Decida prima il tipo di routing, poi scelga il meccanismo di preferenza che esiste per esso.

Con due connessioni statiche che annunciano lo stesso prefisso, la leva utile è il prefisso: annunci un intervallo più specifico sulla connessione che vuole usare, e accetti di aver cambiato quale destinazione corrisponde anziché quale percorso vince.

Perché un transit gateway è un’altra risposta

Un transit gateway supporta il multipath a costo uguale tra gli attachment VPN, così due connessioni possono condividere il traffico invece che una restare in standby. Quel progetto ha una superficie di guasto diversa: i flussi si distribuiscono sui tunnel, e un tunnel che cade sposta solo parte del carico. Copiare una ricetta VGW su un transit gateway, o il contrario, crea aspettative che nessuna delle due piattaforme soddisfa.

Scelga il modello prima del meccanismo: attivo e standby con una preferenza fissata, oppure attivo e attivo con ECMP.

Che cosa verificare dopo averlo impostato

Confermi quattro cose in ordine. La tabella della sottorete risolve ancora il prefisso verso il gateway previsto. Il gateway elenca entrambi i tunnel come attivi. L’AS_PATH ricevuto sulla connessione che vuole evitare è più lungo dell’altro. E un flusso reale da un’istanza in quella sottorete attraversa il tunnel atteso, osservato su entrambe le estremità invece che dedotto da uno stato verde.

Poi esegua il test di commutazione approvato e osservi il percorso superstite trasportare il servizio. Una preferenza che esiste solo in un diff di configurazione non è ancora una preferenza.