Kāpēc AWS VGW apakštīkla maršruts nevar izvēlēties vienu VPN tuneli

Divi Site-to-Site VPN savienojumi beidzas vienā virtuālajā privātajā vārtejā un paziņo to pašu filiāles prefiksu. Apakštīkla maršrutu tabulā ir viens ieraksts šim prefiksam, kas norāda uz vārteju, un nav neviena lauka, kas nosauktu tuneli. Tāpēc priekšroka starp savienojumiem notiek vietā, ko konsole ne sauc par maršrutēšanu. Zināšana, kura slānis pārvalda lēmumu, ir atšķirība starp strādājošu rezervi un izmaiņām, kas neko nedara.

Spēlē ir divi slāņi: VPC maršruts, kas pasaka, kura vārteja, un pašas vārtejas tuneļa izvēle. To sajaukšana rada labojumus, kas maršrutu tabulā izskatās pareizi un nekad nepārvieto nevienu paketi.

Divi slāņi, kas izskatās kā viens

Apakštīkla maršruts atbild uz vienu jautājumu: šim galamērķim kura piesaiste? Tā mērķis ir virtuālā privātā vārteja, un tās metrika sacenšas tikai ar citiem tās pašas tabulas maršrutiem. Nekas šajā ierakstā neatšķir tuneli viens no tuneļa divi vai savienojumu A no savienojuma B. Konkrētāks prefikss ir cita galamērķa atbilstība, nevis smalkāka ceļa izvēle.

Vārteja atbild uz nākamo jautājumu: starp tuneļiem, ko tā tur šim prefiksam, kurš tagad nes satiksmi. Šis lēmums nāk no tuneļa veselības un no klienta vārtejas saņemtajiem BGP atribūtiem, un tas nekad neparādās apakštīkla maršrutu tabulā.

Ko VGW patiešām salīdzina

Veselība nāk pirmā. Tunelis, kas ir izslēgts, vai BGP sesija, kas nav pacēlusies, zaudē pirms jebkura atribūta izskatīšanas. Tāpēc ceļa priekšā pievienošana savienojumā, kas jau neizdodas, neko nemaina.

Starp derīgiem ceļiem vienam un tam pašam prefiksam AWS dod priekšroku īsākam AS_PATH. Kad divi ceļi ir vienādi gari, tā salīdzina MED, ievērojot dokumentēto nosacījumu par pirmo AS ceļā. Lasiet publicēto kārtību, nevis folkloras versiju, jo folklora parasti izlaiž veselības soli un statisko maršrutu izņēmumu. Viens secinājums: trīs priekšā pievienošanas rezerves savienojumā padara primāro stingri īsāku, un tas ir parastais veids, kā izteikt priekšroku.

Pievienošana priekšā, un kad tā neko nedara

Pievienošana priekšā notiek klienta vārtejas izejošajos paziņojumos, nevis AWS iekšienē. Jūs pievienojat savu ASN divas vai trīs reizes prefiksam, no kura vēlaties, lai AWS izvairītos, un tad AWS redz garāku ceļu šim savienojumam. Primārais savienojums saglabā paziņojumu bez pievienošanas. Ja abi savienojumi paziņo no tā paša ASN ar tādu pašu pievienošanu skaitu, jūs neesat izteicis nekādu priekšroku.

Pēc izmaiņām pārbaudiet saņemto ceļu AWS pusē. Pievienošana, kas nekad nav atstājusi klienta ierīci, izskatās tieši tāpat kā tā, ko AWS ignorēja.

Statiskie maršruti ignorē visu argumentu

Ja savienojums izmanto statisko maršrutēšanu, nav AS_PATH, ko pagarināt. AWS dokumentē, ka statiskie VPN maršruti ir prioritāri pār BGP apgūtiem maršrutiem tam pašam prefiksam, tāpēc jaukts dizains neuzvedas kā pilnīgi dinamisks. Vispirms izlemiet maršrutēšanas tipu, pēc tam izvēlieties priekšrokas mehānismu, kas tam pastāv.

Ar diviem statiskiem savienojumiem, kas paziņo to pašu prefiksu, noderīgā svira ir prefikss: paziņojiet konkrētāku diapazonu tajā savienojumā, kuru vēlaties izmantot, un pieņemiet, ka esat mainījis to, kurš galamērķis atbilst, nevis tas, kurš ceļš uzvar.

Kāpēc tranzīta vārteja ir cita atbilde

Tranzīta vārteja atbalsta vienādu izmaksu vairāku ceļu maršrutēšanu pāri VPN piesaistēm, tāpēc divi savienojumi var dalīt satiksmi, nevis viens stāvēt rezervē. Šim dizainam ir cita atteices virsma: plūsmas izkliedējas pa tuneļiem, un viena tuneļa kritums pārvieto tikai daļu slodzes. VGW receptes kopēšana uz tranzīta vārteju vai otrādi rada gaidas, ko neviena no abām platformām neizpilda.

Izvēlieties modeli pirms mehānisma: aktīvs un rezerves ar fiksētu priekšroku, vai aktīvs un aktīvs ar ECMP.

Kas jāpārbauda pēc iestatīšanas

Apstipriniet četras lietas pēc kārtas. Apakštīkla tabula joprojām atrisina prefiksu uz paredzēto vārteju. Vārteja uzrāda abus tuneļus kā aktīvus. Saņemtais AS_PATH savienojumā, no kura vēlaties izvairīties, ir garāks nekā otrs. Un reāla plūsma no instances šajā apakštīklā iet caur gaidīto tuneli, novērota abos galos, nevis secināta no zaļa statusa.

Pēc tam palaidiet apstiprināto pārslēgšanās testu un vērojiet, kā izdzīvojušais ceļš nes pakalpojumu. Priekšroka, kas pastāv tikai konfigurācijas starpībā, vēl nav priekšroka.