Mga anunsyo ng BGP ng VGW kumpara sa talahanayan ng ruta ng VPC: ano ang binabago ng ano

Ang nawawalang prefix sa talahanayan ng ruta ng isang subnet ng VPC at ang nawawalang prefix sa router ng kliyente ay dalawang magkaibang sira, at isa lamang sa kanila ang naaayos sa loob ng mga talahanayan ng ruta ng AWS. Inaanunsyo ng virtual private gateway ang mga bloke ng CIDR na nauugnay sa VPC nito; ang talahanayan ng ruta ng subnet ang nagpapasya kung saan ipapadala ng workload ang sagot. Ang ituring ang pangalawa bilang paraan upang baguhin ang una ang pinakakaraniwang maling liko sa diagnosis na ito. Isagawa ang mga pagsusuring nasa ibaba nang sunod-sunod at panatilihing hiwalay ang dalawang direksyon.

Pangalanan ang attachment bago magbasa ng anumang talahanayan

Ang site-to-site VPN ay nagtatapos sa virtual private gateway o sa transit gateway, at ang mga ID ng resource ang nagpapasya kung aling modelo ng pagruruta ang naaangkop. Basahin muna ang mga ito: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. Sinasabi ng sagot kung ang susunod na talahanayang susuriin ay talahanayan ng ruta ng VPC o talahanayan ng ruta ng transit gateway.

Kung ang VPN ay nakakabit sa isang transit gateway, itigil ang pagtrato sa talahanayan ng ruta ng VPC bilang control plane. Doon ang talahanayan ng VPC ay tumuturo sa attachment ng gateway, at ang asosasyon at pagpapalaganap ay nangyayari sa talahanayan ng ruta ng transit gateway. Ang paghahalo ng dalawang pananaw ay gumagawa ng kumpiyansang konklusyon tungkol sa maling bagay.

Ang direksyon mula AWS patungo sa opisina ay isang anunsyo

Para sa attachment ng VGW, inaanunsyo ng gateway ang mga bloke ng CIDR na nauugnay sa VPC nito sa gateway ng kliyente sa pamamagitan ng BGP. Ang pagdaragdag ng isang solong ruta ng subnet, o pagturo ng ruta patungo sa peer na VPC o sa isang appliance, ay hindi nagdaragdag ng isa pang nauugnay na CIDR at hindi lumilitaw sa anunsyong iyon. Kung kulang ang prefix sa opisina, ihambing ang listahan ng mga natanggap na ruta sa mga asosasyon ng VPC bago i-edit ang anumang talahanayan ng ruta.

Ang simpleng tuntunin ay may mga eksepsiyon, kaya panatilihin ito sa saklaw nito. Ang isang setup na VPN CloudHub ay maaaring mag-anunsyo muli ng mga prefix ng site sa pagitan ng mga gateway ng kliyente, at ang transit gateway ay sumusunod sa sarili nitong mga tuntunin sa pagpapalaganap. Ang pahayag na ang VGW ay nag-anunsyo lamang ng sarili nitong VPC ay isang kapaki-pakinabang na default, hindi isang batas na sumasakop sa bawat topolohiyang makikita mo.

Ang direksyon mula opisina patungo sa AWS ay pagpapalaganap at pagpili

Sa kabaligtarang direksyon, natututuhan ng VGW ang prefix ng opisina, ngunit hindi nito nagagalaw ang isang workload nang mag-isa. Ang talahanayan ng ruta ng subnet ay dapat may paganang pagpapalaganap para sa attachment o may static na ruta patungo sa parehong destinasyon. Kapag pareho ang umiiral para sa isang prefix, ang static na ruta ang nananalo, at ang pagtutugma ng pinakamahabang prefix ay tumatakbo bago ang dalawa.

Basahin ang pinagmulan sa halip na ipagpalagay ito: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. Ang entry na may pinagmulang EnableVgwRoutePropagation ay nagmula sa BGP; ang entry na may pinagmulang CreateRoute ay tinipa ng isang tao at patuloy na mananalo hanggang may magbura nito.

Isang runbook na nagpapanatiling hiwalay ang dalawang direksyon

Itala ang apat na katotohanan sa panig ng AWS bago magbago ng anuman: ang uri ng attachment, ang mga nauugnay na CIDR ng VPC, ang pinagmulan ng ruta ng subnet para sa prefix na pinag-uusapan, at ang kalagayan ng tunnel at BGP. Ang parehong tawag na describe ay nagbabalik ng VgwTelemetry na may bilang ng mga tinanggap na ruta bawat tunnel, na nagsasabi kung may tinanggap ba ang AWS na anumang ruta. Pagkatapos ay ihambing iyon sa aktwal na inininstala ng aparato ng kliyente. Ang prefix na nasa BGP ngunit wala sa talahanayan ng pagpapasa ay problema sa lokal na pag-import o pinakamainam na landas, hindi problema sa talahanayan ng ruta ng AWS.

Kung wala talaga ang prefix sa talahanayan ng subnet, paganahin ang pagpapalaganap o magdagdag ng static na ruta, pagkatapos ay basahin muli ang parehong query pagkatapos ng agwat ng pagpapalaganap sa halip na ipagpalagay na agad ang pagbabago. Kung umiiral ang prefix at nabigo pa rin ang trapiko, iwanan ang control plane at lumipat sa landas ng data.

Ano ang hindi dapat baguhin habang naroon ka

Huwag i-on o i-off ang pagpapalaganap sa mga walang kaugnayang talahanayan ng ruta para ayusin ang isang nawawalang prefix, at huwag magdagdag ng default na ruta para takpan ang isang nawawalang CIDR. Ang dalawang pagbabago ay nagpapalawak ng saklaw ng epekto at nagpapahirap sa susunod na diagnosis. Limitahan ang pag-edit sa talahanayang nagsisilbi sa subnet ng workload na pinag-uusapan.

Ang landas ng data ay hiwalay sa lahat ng ito. Ang mga security group ay stateful, ang mga network ACL ay hindi, at ang firewall ng host o asimetrikong landas ng pagbabalik ay maaaring magtapon ng trapikong inihatid nang tama ng pagruruta. Ang inanunsyong aggregate ay hindi rin nagbibigay ng pahintulot sa bawat serbisyo sa loob nito, kaya limitahan ang pag-access sa hangganan ng patakaran sa halip na umasa kung ang isang address ay nagkataong lumilitaw sa isang anunsyo ng BGP.

I-save ang bago at pagkatapos ng bawat query sa talahanayan ng ruta sa talaan ng pagbabago. Kung ang pagbabago ay nagpapalala ng sitwasyon, ibalik ang mga dating ruta at kumpirmahin gamit ang parehong query, dahil ang rollback na hindi mo maaaring i-verify ay hula lamang.