De ce o rută de subrețea în AWS VGW nu poate alege un singur tunel VPN

Două conexiuni Site-to-Site VPN se termină pe un singur gateway privat virtual și anunță același prefix de sucursală. Tabelul de rute al subrețelei are o singură intrare pentru acel prefix, îndreptată spre gateway, și niciun câmp care să numească un tunel. Prin urmare, preferința între conexiuni se produce într-un loc pe care consola nu îl numește rutare. Să știi care strat deține decizia este diferența dintre un standby funcțional și o modificare care nu face nimic.

Două straturi sunt în joc: ruta din VPC care spune care gateway, și alegerea tunelului de către gateway însuși. Confundarea lor produce modificări care par corecte în tabelul de rute și nu mișcă niciodată un pachet.

Două straturi care par unul

Ruta de subrețea răspunde la o singură întrebare: pentru această destinație, ce atașament? Ținta ei este gateway-ul privat virtual, iar metrica ei concurează doar cu alte rute din același tabel. Nimic din acea intrare nu distinge tunelul unu de tunelul doi, nici conexiunea A de conexiunea B. Un prefix mai specific este o altă potrivire de destinație, nu o alegere de cale mai fină.

Gateway-ul răspunde la următoarea întrebare: dintre tunelurile pe care le ține pentru acel prefix, care transportă trafic acum. Decizia vine din sănătatea tunelului și din atributele BGP primite de la gateway-ul clientului, și nu apare niciodată în tabelul de rute al subrețelei.

Ce compară de fapt VGW

Sănătatea vine prima. Un tunel căzut, sau o sesiune BGP care nu a urcat, pierde înainte de a fi examinat orice atribut. De aceea adăugarea unei căi în față pe o conexiune care deja eșuează nu schimbă nimic.

Dintre căile eligibile pentru același prefix, AWS preferă AS_PATH mai scurt. Când două căi au aceeași lungime, compară MED, sub rezerva condiției documentate despre primul AS din cale. Citiți ordinea publicată, nu versiunea folclorică, pentru că folclorul omite de obicei pasul de sănătate și excepția rutelor statice. O consecință: trei adăugări în față pe conexiunea de rezervă fac conexiunea primară strict mai scurtă, iar acesta este modul obișnuit de a exprima preferința.

Adăugarea în față, și când nu face nimic

Adăugarea în față are loc în anunțurile de ieșire ale gateway-ului clientului, nu în interiorul AWS. Adăugați propriul ASN de două sau trei ori la prefixul pe care doriți ca AWS să îl evite, iar AWS vede atunci o cale mai lungă pentru acea conexiune. Conexiunea primară păstrează anunțul fără adăugare. Dacă ambele conexiuni anunță din același ASN cu același număr de adăugări, nu ați exprimat nicio preferință.

Verificați calea primită pe partea AWS după modificare. O adăugare care nu a părăsit niciodată echipamentul clientului arată exact ca una pe care AWS a ignorat-o.

Rutele statice ignoră întregul argument

Dacă conexiunea folosește rutare statică, nu există AS_PATH de lungit. AWS documentează rutele VPN statice ca având prioritate față de rutele învățate prin BGP pentru același prefix, așa că un design mixt nu se comportă ca unul complet dinamic. Decideți mai întâi tipul de rutare, apoi alegeți mecanismul de preferință care există pentru aceasta.

Cu două conexiuni statice care anunță același prefix, pârghia utilă este prefixul: anunțați un interval mai specific pe conexiunea pe care vreți să o folosiți, și acceptați că ați schimbat care destinație se potrivește, nu care cale câștigă.

De ce un gateway de tranzit este un alt răspuns

Un gateway de tranzit suportă multipath cu cost egal între atașamentele VPN, așa că două conexiuni pot împărți traficul în loc ca una să stea în rezervă. Acel design are o altă suprafață de eșec: fluxurile se împrăștie pe tuneluri, iar căderea unui tunel mută doar o parte a încărcării. Copierea unei rețete VGW pe un gateway de tranzit, sau invers, creează așteptări pe care niciuna dintre platforme nu le îndeplinește.

Alegeți modelul înaintea mecanismului: activ și rezervă cu o preferință fixată, sau activ și activ cu ECMP.

Ce trebuie verificat după ce îl configurați

Confirmați patru lucruri în ordine. Tabelul subrețelei rezolvă în continuare prefixul către gateway-ul dorit. Gateway-ul listează ambele tuneluri ca active. AS_PATH primit pe conexiunea pe care vreți să o evitați este mai lung decât celălalt. Și un flux real dintr-o instanță din acea subrețea traversează tunelul așteptat, observat la ambele capete în loc de dedus dintr-un status verde.

Apoi rulați testul de comutare aprobat și urmăriți calea supraviețuitoare purtând serviciul. O preferință care există doar într-un diff de configurație nu este încă o preferință.