Af hverju BGP-lotan þín birtist ekki í leiðartöflu VPC-sins

Sagan sem er endurtekin er að routing-dæmon á EC2 VPN-tæki muni kenna VPC-inu fjarlægu forskeytin sín um leið og BGP kemur upp. Helmingur af því er satt. Lotan kemur upp, og ekkert breytist í leiðartöflu VPC-sins vegna þess, og þess vegna er fyrsta einkennið venjulega undirnet sem hendir umferðinni hljóðlaust í svarthol.

Hér er verið að rugla saman tveimur mismunandi hlutum: peering við leiðarþjón og uppsetningu leiða í töflu.

Goðsögnin: komdu BGP upp og VPC-ið lærir forskeytin

BGP er samtal milli tveggja mælenda, og í þessari hönnun eru mælendurnir routing-dæmonið á tækinu þínu og endapunktur VPC Route Server sem AWS setur í undirnet sem þú átt. Þetta samtal ber forskeyti. Það snertir ekki leiðartöflu vinnuundirnetanna þinna, því þær töflur læra aðeins með dreifingu sem verður að virkja á hverri þeirra. Þangað til lærir VPC-efnið ekkert um það sem tækið veit.

Uppsetningarþrepin eru aðskilin af ástæðu: tengja, búa til endapunktinn, gera peering, virkja svo dreifingu.

Route Server er stjórnplan, ekki göng

Route Server dulkóðar, sendir eða skoðar ekki eitt einasta pakka. Það er til til að skiptast á BGP við tækið og afhenda leiðartöflunum sem eru stilltar til að taka við þeim forskeytin sem verða til. Gagnasviðið er óbreytt: pakkar fara enn út um netviðmót tækisins, ferðast um VPN þess og koma aftur sömu leið.

Það þýðir að uppruna- og áfangastaðaathugun á sendingareintakinu skiptir enn máli, því reintakið sendir nú umferð sem er beint til einhvers annars.

Öryggishópar og undirnetsstýringar gilda líka um sent flæði. Route Server mun ekki þvinga tæki sem sleppir umferð til að senda hana, og það lagar ekki vantaða afturleið hinum megin.

Dreifing er fyrir hverja leiðartöflu, ekki fyrir allt VPC-ið

Að tengja leiðarþjóninn við VPC-ið og virkja dreifingu á leiðartöflu eru tvær ákvarðanir, og aðeins sú seinni breytir því sem undirnet gerir. VPC með sex leiðartöflum getur tekið við dreifðu forskeyti í einni og ekki í hinum fimm, sem er einmitt rétt fyrir hub-undirnet og einmitt það sem framleiðir ráðgátu-útkornuna «virkar hálfa leið». Jafnvel þar sem dreifing er virk getur keppinautarleið unnið, því leiðarval VPC-sins kýs lengsta forskeytið og, við jafna lengd, kýs kyrra leið fram yfir dreifða. Þessi forgangsröðun er beitt hljóðlaust.

Athugaðu virku töfluna fyrir tiltekið undirnet frekar en listann yfir forskeyti sem tækið auglýsir. API-ið svarar þeirri spurningu beint: aws ec2 associate-route-server og aws ec2 enable-route-server-propagation --route-table-id <id> eru þrepin tvö sem fólk gleymir, og aws ec2 describe-route-tables --route-table-ids <id> sýnir hvort forskeytið hafi yfirhöfuð komið sem route server-færsla.

Tækið ber enn hvern pakka

Að auglýsa aðgengi er ekki það sama og að hafa það. BGP-lota getur verið uppi á meðan VPN tækisins er niðri, og kyrr auglýsing sem breytist aldrei heldur áfram að draga umferð að dauðri leið. Route Server styður bilanatöktun eins og BFD, en það prófar lífvænleika jafningjans, ekki heilsu alls sem er fyrir aftan hann.

Bindu auglýsinguna við raunverulegu fjarlægu leiðina: auglýstu forskeytið þegar göngin og fjarnetið eru uppi, og dragðu það til baka þegar þau eru það ekki.

Dragðu forskeyti til baka og fylgstu með hvað gerist

Prófaðu í áföngum, og gerðu síðasta áfangann að fjarlægingu. Staðfestu að auglýsingin berist, forskeytið birtist í hverri fyrirhugaðri töflu, tækið sé næsta stökk, sendingin fari um virk göngin og fjarlægi endinn svari. Dragðu svo prófunarforskeyti til baka, eða lokaðu samþykktum göngum, og fylgstu með hvort umferðin færist þangað sem hönnunin segir. Skráðu töflurnar fyrir og eftir á meðan prófunin er enn opin.

Að færa leið yfir á annað tæki færir ekki loturnar sem hún bar, því NAT- og eldveggsstaða verður á fyrra tækinu.

Fyrir fastan hóp af tylft forskeyta eru kyrrar leiðir í VPC-töflunum enn ódýrara svarið. Route Server á skilið sinn stað þegar forskeytalistinn breytist í raun og veru og afturköllunarstefnan er eitthvað sem þú getur útskýrt fyrir þeim sem er á vakt.