Miksi AWS VGW:n aliverkkoreitti ei voi valita yhtä VPN-tunnelia

Kaksi Site-to-Site VPN -yhteyttä päättyy yhteen virtuaaliseen yksityiseen yhdyskäytävään ja mainostaa samaa haaraprefiksiä. Aliverkon reititystaulussa on yksi merkintä sille prefiksille, osoittaen yhdyskäytävään, eikä yhtään kenttää, joka nimeäisi tunnelin. Mieltymys yhteyksien välillä tapahtuu siis jossain, mitä konsoli ei nimitä reititykseksi. Tieto siitä, mikä kerros omistaa päätöksen, on ero toimivan varayhteyden ja mitään tekemättömän muutoksen välillä.

Pelissä on kaksi kerrosta: VPC:n reitti, joka kertoo minkä yhdyskäytävän, ja yhdyskäytävän oma tunnelin valinta. Niiden sekoittaminen tuottaa muutoksia, jotka näyttävät reititystaulussa oikeilta eivätkä koskaan siirrä pakettia.

Kaksi kerrosta, jotka näyttävät yhdeltä

Aliverkon reitti vastaa yhteen kysymykseen: tälle kohteelle, mikä liitäntä? Sen kohde on virtuaalinen yksityinen yhdyskäytävä, ja sen metriikka kilpailee vain saman taulun muiden reittien kanssa. Mikään merkinnässä ei erota tunnelia yksi tunnelista kaksi tai yhteyttä A yhteydestä B. Tarkempi prefiksi on eri kohdeosuma, ei hienojakoisempi reitin valinta.

Yhdyskäytävä vastaa seuraavaan kysymykseen: sen prefiksin tunneleista, jotka se pitää, mikä kuljettaa liikennettä nyt. Päätös tulee tunnelin kunnosta ja asiakasyhdyskäytävältä vastaanotetuista BGP-attribuuteista, eikä se koskaan näy aliverkon reititystaulussa.

Mittä VGW todella vertaa

Kunto tulee ensin. Tunneli, joka on alhaalla, tai BGP-istunto, joka ei ole noussut, häviää ennen kuin mitään attribuuttia tutkitaan. Siksi polun esiliittäminen yhteydelle, joka jo epäonnistuu, ei muuta mitään.

Saman prefiksin kelvollisista poluista AWS suosii lyhyempää AS_PATHia. Kun kaksi polkua ovat yhtä pitkiä, se vertaa MEDiä, riippuen dokumentoidusta polun ensimmäistä AS:ää koskevasta ehdosta. Lue julkaistu järjestys, älä kansanperinteen versiota, sillä kansanperinne jättää yleensä pois kuntoaskeleen ja staattisten reittien poikkeuksen. Yksi seuraus: kolme esiliitosta varayhteydellä tekee ensisijaisesta tiukasti lyhyemmän, ja se on tavallinen tapa ilmaista mieltymys.

Esiliittäminen ja milloin se ei tee mitään

Esiliittäminen tapahtuu asiakasyhdyskäytävän lähtevissä ilmoituksissa, ei AWS:n sisällä. Lisäät oman ASN:si kaksi tai kolme kertaa prefiksiin, jonka haluat AWS:n välttävän, ja AWS näkee silloin pidemmän polun kyseiselle yhteydelle. Ensisijainen yhteys pitää ilmoituksen ilman esiliitosta. Jos molemmat yhteydet ilmoittavat samasta ASN:stä samalla esiliitosten määrällä, et ole ilmaissut mitään mieltymystä.

Tarkista vastaanotettu polku AWS:n puolella muutoksen jälkeen. Esiliitos, joka ei koskaan lähtenyt asiakaslaitteesta, näyttää täsmälleen siltä, jonka AWS jätti huomiotta.

Staattiset reitit jättävät koko argumentin huomiotta

Jos yhteys käyttää staattista reititystä, ei ole AS_PATHia pidennettäväksi. AWS dokumentoi staattiset VPN-reitit BGP:n kautta opittujen reittien edelle samalle prefiksille, joten sekamuotoinen suunnittelu ei käyttäydy kuin täysin dynaaminen. Päätä ensin reititystyyppi ja valitse sitten mieltymyksen mekanismi, joka sille on olemassa.

Kun kaksi staattista yhteyttä ilmoittaa saman prefiksin, hyödyllinen vipu on prefiksi: ilmoita tarkempi alue yhteydellä, jota haluat käytettävän, ja hyväksy, että muutit sitä, mikä kohde täsmää, et sitä, mikä polku voittaa.

Miksi transit-yhdyskäytävä on eri vastaus

Transit-yhdyskäytävä tukee samanhintaista monipolkua VPN-liitäntöjen yli, joten kaksi yhteyttä voi jakaa liikennettä sen sijaan, että yksi seisoo varalla. Tässä suunnittelussa on erilainen vikapinta: virrat jakautuvat tunneleille ja yhden tunnelin kaatuminen siirtää vain osan kuormasta. VGW-reseptin kopioiminen transit-yhdyskäytävälle tai päinvastoin luo odotuksia, joita kumpikaan alusta ei täytä.

Valitse malli ennen mekanismia: aktiivinen ja vara kiinnitetyllä mieltymyksellä, tai aktiivinen ja aktiivinen ECMP:llä.

Mittä tarkistaa asetuksen jälkeen

Vahvista neljä asiaa järjestyksessä. Aliverkon taulu ratkaisee prefiksin edelleen aiottuun yhdyskäytävään. Yhdyskäytävä listaa molemmat tunnelit ylös. Vastaanotettu AS_PATH yhteydellä, jota haluat välttää, on pidempi kuin toinen. Ja todellinen virta kyseisen aliverkon instanssista kulkee odotetun tunnelin kautta, havaittuna molemmissa päissä eikä vihreästä tilasta pääteltynä.

Suorita sitten hyväksytty vaihtotesti ja katso, miten selviytyvä polku kantaa palvelun. Mieltymys, joka on olemassa vain konfiguraatioerossa, ei ole vielä mieltymys.