Miért nem választhat egyetlen VPN-alagutat egy AWS VGW alhálózati útvonal

Két Site-to-Site VPN-kapcsolat végződik egy virtuális privát átjárón, és ugyanazt az ágprefikszt hirdeti. Az alhálózati útvonaltábla egy bejegyzést tart ehhez a prefixhez, amely az átjáróra mutat, és semmilyen mezőt, amely alagutat nevezne meg. A kapcsolatok közötti preferencia tehát ott történik, amit a konzol nem nevez útválasztásnak. Tudni, melyik réteg birtokolja a döntést, a különbség egy működő tartalék és egy semmit nem tevő változtatás között.

Két réteg van játékban: a VPC-útvonal, amely megmondja, melyik átjárót, és az átjáró saját alagút-választása. Összekeverésük olyan szerkesztéseket szül, amelyek az útvonaltáblában helyesnek látszanak, és soha nem mozdítanak egyetlen csomagot sem.

Két réteg, amely egynek látszik

Az alhálózati útvonal egyetlen kérdésre válaszol: ehhez a célhoz melyik csatlakozás? Célja a virtuális privát átjáró, és metrikája csak ugyanazon tábla más útvonalaival versenyez. Semmi abban a bejegyzésben nem különbözteti meg az egyes alagutat a kettes alagúttól, sem az A kapcsolatot a B kapcsolattól. Egy konkrétabb prefix más célilleszkedés, nem finomabb útvonalválasztás.

Az átjáró a következő kérdésre válaszol: az ehhez a prefixhez tartott alagutak közül melyik viszi most a forgalmat. Ez a döntés az alagút egészségéből és az ügyfél átjárójától kapott BGP-attribútumokból ered, és soha nem jelenik meg az alhálózati útvonaltáblában.

Mit hasonlít össze valójában a VGW

Az egészség az első. Egy leállt alagút vagy egy fel nem állt BGP-munkamenet veszít, mielőtt bármely attribútumot megvizsgálnának. Ezért nem változtat semmit az útvonal elé fűzése egy olyan kapcsolaton, amely már eleve sikertelen.

Az azonos prefixhez tartozó jogosult útvonalak közül az AWS a rövidebb AS_PATH-t részesíti előnyben. Ha két útvonal egyforma hosszú, a MED-et hasonlítja össze, az útvonal első AS-ére vonatkozó dokumentált feltétel mellett. A publikált sorrendet olvassa, ne a folklórváltozatot, mert a folklór általában kihagyja az egészség lépését és a statikus útvonalak kivételét. Egy következmény: három előrefűzés a tartalék kapcsolaton szigorúan rövidebbé teszi az elsődlegest, és ez a preferencia kifejezésének szokásos módja.

Előrefűzés, és amikor semmit sem tesz

Az előrefűzés az ügyfél átjárójának kimenő hirdetéseiben történik, nem az AWS-en belül. Kétszer vagy háromszor hozzáadja a saját ASN-jét ahhoz a prefixhez, amelyet szeretne, hogy az AWS elkerüljön, és az AWS ekkor hosszabb útvonalat lát ahhoz a kapcsolathoz. Az elsődleges kapcsolat megtartja az előrefűzés nélküli hirdetést. Ha mindkét kapcsolat ugyanabból az ASN-ből, ugyanannyi előrefűzéssel hirdet, egyáltalán nem fejezett ki preferenciát.

A változtatás után ellenőrizze a kapott útvonalat az AWS oldalán. Az az előrefűzés, amely soha nem hagyta el az ügyfél eszközét, pontosan úgy néz ki, mint amelyet az AWS figyelmen kívül hagyott.

A statikus útvonalak figyelmen kívül hagyják az egész érvelést

Ha a kapcsolat statikus útválasztást használ, nincs mit meghosszabbítani, nincs AS_PATH. Az AWS dokumentálja, hogy a statikus VPN-útvonalak elsőbbséget élveznek az ugyanahhoz a prefixhez BGP-n keresztül tanult útvonalakkal szemben, így a vegyes tervezés nem viselkedik teljesen dinamikusként. Először döntse el az útválasztás típusát, majd válassza ki a hozzá létező preferenciamechanizmust.

Két statikus kapcsolattal, amelyek ugyanazt a prefixet hirdetik, a hasznos kar a prefix: hirdessen konkrétabb tartományt azon a kapcsolaton, amelyet használni szeretne, és fogadja el, hogy azt változtatta meg, melyik cél illeszkedik, nem azt, melyik útvonal nyer.

Miért más válasz a tranzitátjáró

A tranzitátjáró egyenlő költségű többutas útválasztást támogat a VPN-csatlakozások között, így két kapcsolat osztozhat a forgalmon ahelyett, hogy az egyik készenlétben állna. Ennek a tervezésnek más a hiba felülete: a folyamok eloszlanak az alagutak között, és egy alagút kiesése csak a terhelés egy részét mozgatja. A VGW-recept átmásolása egy tranzitátjáróra, vagy fordítva, olyan elvárásokat szül, amelyeket egyik platform sem teljesít.

Válassza a modellt a mechanizmus előtt: aktív és készenlét rögzített preferenciával, vagy aktív és aktív ECMP-vel.

Mit ellenőrizzen a beállítás után

Négy dolgot igazoljon sorrendben. Az alhálózati tábla továbbra is a szándékolt átjáróra oldja fel a prefixet. Az átjáró mindkét alagutat aktívként listázza. A kapott AS_PATH azon a kapcsolaton, amelyet el akar kerülni, hosszabb, mint a másik. És egy valódi folyam az alhálózat egy példányából a várt alagúton halad át, mindkét végén megfigyelve, nem zöld állapotból következtetve.

Ezután futtassa a jóváhagyott átkapcsolási tesztet, és nézze, hogy a túlélő útvonal viszi-e a szolgáltatást. Az a preferencia, amely csak egy konfigurációs diffben létezik, még nem preferencia.