Bakit hindi makapipili ng isang tunnel ng VPN ang isang rutang subnet sa AWS VGW

Dalawang koneksyon ng Site-to-Site VPN ang nagtatapos sa isang virtual private gateway at nag-aanunsyo ng parehong prefix ng sangay. May isang entry ang talahanayan ng ruta ng subnet para sa prefix na iyon, nakaturo sa gateway, at walang field na nagpangalan ng tunnel. Kaya ang preperensya sa pagitan ng mga koneksyon ay nangyayari sa lugar na hindi tinatawag ng console na routing. Ang pag-alam kung aling layer ang may hawak ng desisyon ang pagkakaiba ng gumaganang standby at ng pagbabagong walang ginagawa.

Dalawang layer ang nasa laro: ang ruta sa VPC na nagsasabi kung aling gateway, at ang sariling pagpili ng tunnel ng gateway. Ang paghaluin ang dalawa ay gumagawa ng mga pagbabagong mukhang tama sa talahanayan ng ruta at hindi kailanman gumagalaw ng packet.

Dalawang layer na mukhang isa

Sinasagot ng rutang subnet ang isang tanong: para sa destinasyong ito, aling attachment? Ang target nito ay ang virtual private gateway, at ang sukatan nito ay nakikipagkumpitensya lamang sa ibang ruta sa parehong talahanayan. Wala sa entry na iyon ang nagtatangi ng tunnel isa sa tunnel dalawa, o ng koneksyon A sa koneksyon B. Ang mas tiyak na prefix ay ibang tugma ng destinasyon, hindi mas pinong pagpili ng landas.

Sinasagot ng gateway ang susunod na tanong: sa mga tunnel na hawak nito para sa prefix na iyon, alin ang nagdadala ng trapiko ngayon. Ang desisyong iyon ay nagmumula sa kalusugan ng tunnel at sa mga attribute ng BGP na natatanggap mula sa gateway ng customer, at hindi ito kailanman lumilitaw sa talahanayan ng ruta ng subnet.

Ano ba talaga ang inihahambing ng VGW

Kalusugan muna. Ang tunnel na nakababa, o ang sesyon ng BGP na hindi umangat, ay natatalo bago suriin ang anumang attribute. Kaya walang nababago kapag naglalagay ng landas sa unahan sa koneksyong nabibigo na.

Sa mga karapat-dapat na landas para sa parehong prefix, mas gusto ng AWS ang mas maikling AS_PATH. Kapag magkapareho ang haba ng dalawang landas, inihahambing nito ang MED, alinsunod sa nakadokumentong kundisyon tungkol sa unang AS sa landas. Basahin ang inilathalang pagkakasunod-sunod at hindi ang bersyon ng alamat, dahil karaniwang inaalis ng alamat ang hakbang ng kalusugan at ang eksepsyon para sa mga static na ruta. Isang kahihinatnan: tatlong paglalagay sa unahan sa backup na koneksyon ang nagpapagaan ng primarya nang mahigpit, at iyon ang karaniwang paraan ng pagpapahayag ng preperensya.

Paglalagay sa unahan, at kung kailan wala itong ginagawa

Ang paglalagay sa unahan ay nangyayari sa mga papalabas na anunsyo ng gateway ng customer, hindi sa loob ng AWS. Nagdadagdag ka ng sarili mong ASN nang dalawa o tatlong beses sa prefix na gusto mong iwasan ng AWS, at pagkatapos ay nakikita ng AWS ang mas mahabang landas para sa koneksyong iyon. Pinapanatili ng primaryang koneksyon ang anunsyong walang paglalagay sa unahan. Kung ang dalawang koneksyon ay nag-aanunsyo mula sa parehong ASN na may parehong bilang ng paglalagay, wala kang naipahayag na preperensya.

Suriin ang natanggap na landas sa panig ng AWS pagkatapos ng pagbabago. Ang paglalagay sa unahan na hindi kailanman umalis sa aparato ng customer ay mukhang eksaktong katulad ng binalewala ng AWS.

Binabalewala ng mga static na ruta ang buong argumento

Kung gumagamit ng static na routing ang koneksyon, walang AS_PATH na pahabain. Nakadokumento sa AWS na ang mga static na ruta ng VPN ay may priyoridad sa mga rutang natutunan sa BGP para sa parehong prefix, kaya ang pinagsamang disenyo ay hindi kumikilos tulad ng ganap na dinamiko. Magpasya muna sa uri ng routing, pagkatapos ay piliin ang mekanismo ng preperensya na umiiral para dito.

Sa dalawang static na koneksyong nag-aanunsyo ng parehong prefix, ang kapaki-pakinabang na lever ay ang prefix: mag-anunsyo ng mas tiyak na saklaw sa koneksyong gusto mong gamitin, at tanggapin na binago mo kung aling destinasyon ang tumutugma at hindi kung aling landas ang mananalo.

Bakit ibang sagot ang transit gateway

Sinusuportahan ng transit gateway ang multipath na magkapareho ang gastos sa mga attachment ng VPN, kaya maaaring maghati ng trapiko ang dalawang koneksyon sa halip na may isang nakatayong standby. Ang disenyong iyon ay may ibang ibabaw ng pagkasira: nagkakalat ang mga daloy sa mga tunnel, at ang pagbagsak ng isang tunnel ay naglilipat lamang ng bahagi ng karga. Ang pagkopya ng recipe ng VGW sa transit gateway, o kabaliktaran, ay lumilikha ng mga inaasahang hindi natutupad ng alinmang plataporma.

Piliin ang modelo bago ang mekanismo: aktibo at standby na may nakapirmeng preperensya, o aktibo at aktibo na may ECMP.

Ano ang i-verify pagkatapos mong i-set up

Kumpirmahin ang apat na bagay sa pagkakasunod-sunod. Ang talahanayan ng subnet ay nagre-resolba pa rin ng prefix sa inilaan na gateway. Inililista ng gateway ang dalawang tunnel bilang nakaupo. Ang natanggap na AS_PATH sa koneksyong gusto mong iwasan ay mas mahaba kaysa sa isa. At ang totoong daloy mula sa isang instance sa subnet na iyon ay dumadaan sa inaasahang tunnel, naobserbahan sa dalawang dulo sa halip na hinihinuha mula sa berdeng status.

Pagkatapos ay patakbuhin ang aprubadong pagsubok ng failover at panoorin ang natitirang landas na nagdadala ng serbisyo. Ang preperensyang umiiral lamang sa pagkakaiba ng configuration ay hindi pa preperensya.