Bakit hindi lumalabas ang iyong BGP session sa routing table ng VPC

Ang kuwentong paulit-ulit na ikinukuwento ay ang routing daemon sa isang EC2 VPN appliance ay magtuturo sa VPC ng malalayong prefix nito kapag umangat ang BGP. Kalahati niyan ay totoo. Umaangat ang session, at walang nagbabago sa routing table ng VPC dahil dito, kaya ang unang sintomas ay kadalasang isang subnet na tahimik na nagtatapon ng traffic sa isang itim na butas.

Dalawang magkaibang bagay ang pinaghahalo dito: peering sa isang route server, at pag-install ng mga ruta sa isang table.

Ang mito: iangat ang BGP at matututunan ng VPC ang mga prefix

Ang BGP ay usapan sa pagitan ng dalawang tagapagsalita, at sa disenyong ito ang mga tagapagsalita ay ang routing daemon sa iyong appliance at isang VPC Route Server endpoint na inilalagay ng AWS sa isang subnet na pag-aari mo. Dinadala ng usapang iyon ang mga prefix. Hindi nito hinahawakan ang routing table ng iyong workload subnets, dahil ang mga table na iyon ay natututo lamang sa pamamagitan ng propagation na dapat i-enable sa bawat isa. Hangga't hindi iyon nangyayari, wala pang alam ang fabric ng VPC tungkol sa alam ng appliance.

Ang mga hakbang sa setup ay hiwalay dahil sa isang dahilan: i-associate, gawin ang endpoint, mag-peer, pagkatapos ay i-enable ang propagation.

Ang Route Server ay isang control plane, hindi isang tunnel

Hindi ine-encrypt, ipinapasa, o sinusuri ng Route Server ang kahit isang packet. Umiiral ito upang makipagpalitan ng BGP sa appliance at ibigay ang mga resultang prefix sa mga routing table na naka-configure upang tanggapin ang mga ito. Walang pagbabago sa data plane: lumalabas pa rin ang mga packet sa network interface ng appliance, dumadaan sa VPN nito, at bumabalik sa parehong daan.

Ibig sabihin, mahalaga pa rin ang pagsusuri ng source at destination sa forwarding instance, dahil nagpapasa na ngayon ang instance ng traffic na naka-address sa ibang tao.

Nalalapat din ang mga security group at kontrol ng subnet sa ipinapasang flow. Hindi pipilitin ng Route Server ang isang appliance na nagtatapon ng traffic na ipasa ito, at hindi nito aayusin ang nawawalang return route sa malayong panig.

Ang propagation ay kada routing table, hindi kada VPC

Ang pag-associate ng route server sa VPC at ang pag-enable ng propagation sa isang routing table ay dalawang desisyon, at ang pangalawa lamang ang nagbabago sa ginagawa ng isang subnet. Ang VPC na may anim na routing table ay maaaring makatanggap ng propagated prefix sa isa at hindi sa iba pang lima, na eksaktong tama para sa isang hub subnet at eksaktong nagbubunga ng nakakalitong resulta na «kalahati lang ang gumagana». Kahit saan nakabukas ang propagation, maaaring manalo ang isang karibal na ruta, dahil pinipili ng VPC route selection ang pinakamahabang prefix at, sa pantay na haba, pinipili ang static route kaysa propagated. Tahimik na inilalapat ang preference na iyon.

Suriin ang epektibong table para sa partikular na subnet kaysa sa listahan ng mga prefix na inaanunsyo ng appliance. Direktang sinasagot ng API ang tanong na iyon: aws ec2 associate-route-server at aws ec2 enable-route-server-propagation --route-table-id <id> ang dalawang hakbang na nakakalimutan ng mga tao, at ipinapakita ng aws ec2 describe-route-tables --route-table-ids <id> kung dumating man ang prefix bilang route server entry.

Dinadala pa rin ng appliance ang bawat packet

Ang pag-anunsyo ng maabot ay hindi katulad ng pagkakaroon nito. Maaaring manatiling nakatayo ang isang BGP session habang bagsak ang VPN ng appliance, at ang isang static na anunsyo na hindi kailanman nagbabago ay patuloy na humihila ng traffic patungo sa isang patay na landas. Sinusuportahan ng Route Server ang failure detection tulad ng BFD, ngunit sinusubukan niyon ang pagiging buhay ng peer, hindi ang kalusugan ng lahat sa likod nito.

Itali ang anunsyo sa tunay na malayong ruta: ianunsyo ang prefix kapag nakataas ang tunnel at malayong network, at bawiin ito kapag hindi.

Bawiin ang isang prefix at tingnan ang mangyayari

Subukan nang paunti-unti, at gawing pagtanggal ang huling yugto. Kumpirmahin na dumarating ang anunsyo, lumalabas ang prefix sa bawat nilalayong table, ang appliance ang susunod na hop, tumatawid ang forwarding sa aktibong tunnel, at sumasagot ang malayong dulo. Pagkatapos ay bawiin ang isang test prefix, o isara ang isang aprubadong tunnel, at obserbahan kung lumilipat ang traffic sa lugar na sinasabi ng disenyo. Itala ang mga table bago at pagkatapos habang bukas pa ang test.

Ang paglipat ng ruta sa pangalawang appliance ay hindi naglilipat ng mga session na dinadala nito, dahil nananatili sa unang device ang estado ng NAT at firewall.

Para sa isang fixed na set ng isang dosenang prefix, ang mga static na ruta sa mga table ng VPC ang nananatiling mas murang sagot. Nakukuha ng Route Server ang lugar nito kapag tunay na nagbabago ang listahan ng prefix at ang patakaran sa pagbawi ay isang bagay na maipapaliwanag mo sa taong naka-duty.