Per què una ruta de subxarxa a AWS VGW no pot triar un sol túnel VPN

Dues connexions Site-to-Site VPN acaben en una passarel·la privada virtual i anuncien el mateix prefix de seu. La taula de rutes de la subxarxa té una entrada per a aquest prefix, apuntant a la passarel·la, i cap camp que nomeni un túnel. Per tant, la preferència entre les connexions passa en un lloc que la consola no etiqueta com a encaminament. Saber quina capa posseeix la decisió és la diferència entre un standby que funciona i un canvi que no fa res.

Hi ha dues capes en joc: la ruta de VPC que diu quina passarel·la, i l’elecció pròpia del túnel per part de la passarel·la. Confondre-les produeix edicions que semblen correctes a la taula de rutes i que no mouen mai cap paquet.

Dues capes que semblen una

La ruta de subxarxa respon una sola pregunta: per a aquesta destinació, quin adjunt? El seu objectiu és la passarel·la privada virtual, i la seva mètrica només competeix amb altres rutes de la mateixa taula. Res en aquesta entrada no distingeix el túnel u del túnel dos, ni la connexió A de la connexió B. Un prefix més específic és una coincidència de destinació diferent, no una elecció de camí més fina.

La passarel·la respon la pregunta següent: entre els túnels que té per a aquest prefix, quin transporta trànsit ara. Aquesta decisió ve de la salut del túnel i dels atributs BGP rebuts de la passarel·la del client, i no apareix mai a la taula de rutes de la subxarxa.

Què compara realment la VGW

La salut va primer. Un túnel caigut, o una sessió BGP que no ha pujat, perd abans que s’examini cap atribut. Per això anteposar un camí en una connexió que ja falla no canvia res.

Entre camins elegibles per al mateix prefix, AWS prefereix l’AS_PATH més curt. Quan dos camins tenen la mateixa longitud, compara el MED, subjecte a la condició documentada sobre el primer AS del camí. Llegeixi l’ordre publicat i no la versió del folklore, perquè el folklore normalment omet el pas de salut i l’excepció de les rutes estàtiques. Una conseqüència: tres anteposicions a la connexió de reserva fan la primària estrictament més curta, que és la manera habitual d’expressar la preferència.

Anteposar, i quan no fa res

L’anteposició passa als anuncis de sortida de la passarel·la del client, no dins d’AWS. Afegeix el seu propi ASN dues o tres vegades al prefix que vol que AWS eviti, i llavors AWS veu un camí més llarg per a aquesta connexió. La connexió primària conserva l’anunci sense anteposar. Si les dues connexions anuncien des del mateix ASN amb el mateix nombre d’anteposicions, no ha expressat cap preferència.

Comprovi el camí rebut a la banda d’AWS després del canvi. Una anteposició que no va sortir mai del dispositiu del client sembla exactament una que AWS va ignorar.

Les rutes estàtiques ignoren tot l’argument

Si la connexió fa servir encaminament estàtic, no hi ha cap AS_PATH per allargar. AWS documenta les rutes VPN estàtiques com a prioritàries sobre les rutes apreses per BGP per al mateix prefix, així que un disseny mixt no es comporta com un de completament dinàmic. Decideixi primer el tipus d’encaminament i després triï el mecanisme de preferència que existeix per a ell.

Amb dues connexions estàtiques que anuncien el mateix prefix, la palanca útil és el prefix: anunciï un rang més específic a la connexió que vol utilitzar, i accepti que ha canviat quina destinació coincideix i no quin camí guanya.

Per què una passarel·la de trànsit és una resposta diferent

Una passarel·la de trànsit admet multipath d’igual cost entre adjunts VPN, així que dues connexions poden compartir trànsit en lloc que una quedi en reserva. Aquest disseny té una superfície de fallada diferent: els fluxos es reparteixen pels túnels, i un túnel que cau només mou part de la càrrega. Copiar una recepta de VGW en una passarel·la de trànsit, o al revés, genera expectatives que cap de les dues plataformes compleix.

Triï el model abans del mecanisme: actiu i reserva amb una preferència fixada, o actiu i actiu amb ECMP.

Què verificar després de configurar-ho

Confirmi quatre coses en ordre. La taula de subxarxa encara resol el prefix a la passarel·la prevista. La passarel·la llista els dos túnels com a actius. L’AS_PATH rebut a la connexió que vol evitar és més llarg que l’altre. I un flux real des d’una instància d’aquella subxarxa travessa el túnel esperat, observat en tots dos extrems i no inferit d’un estat verd.

Després executi la prova de commutació aprovada i miri com el camí supervivent porta el servei. Una preferència que només existeix en un diff de configuració encara no és una preferència.