Dlaczego trasa podsieci w AWS VGW nie może wybrać jednego tunelu VPN

Dwa połączenia Site-to-Site VPN kończą się na jednej wirtualnej bramie prywatnej i ogłaszają ten sam prefiks oddziału. Tabela tras podsieci ma jeden wpis dla tego prefiksu, wskazujący bramę, i żadnego pola, które nazywałoby tunel. Preferencja między połączeniami odbywa się więc tam, gdzie konsola nie nazywa tego routingiem. Wiedza o tym, która warstwa posiada decyzję, to różnica między działającym standby a zmianą, która nic nie robi.

W grze są dwie warstwy: trasa w VPC, która wskazuje bramę, oraz własny wybór tunelu przez bramę. Mylenie ich daje zmiany, które w tabeli tras wyglądają poprawnie i nigdy nie przenoszą pakietu.

Dwie warstwy, które wyglądają jak jedna

Trasa podsieci odpowiada na jedno pytanie: dla tego celu, które przyłączenie? Jej celem jest wirtualna brama prywatna, a jej metryka konkuruje tylko z innymi trasami w tej samej tabeli. Nic w tym wpisie nie odróżnia tunelu jeden od tunelu dwa ani połączenia A od połączenia B. Bardziej szczegółowy prefiks to inne dopasowanie celu, a nie drobniejszy wybór ścieżki.

Brama odpowiada na następne pytanie: spośród tuneli, które trzyma dla tego prefiksu, który niesie ruch teraz. Ta decyzja pochodzi ze stanu tunelu i atrybutów BGP otrzymanych z bramy klienta, i nigdy nie pojawia się w tabeli tras podsieci.

Co VGW faktycznie porównuje

Stan jest pierwszy. Tunel, który jest wyłączony, albo sesja BGP, która nie wstała, przegrywa zanim zostanie zbadany jakikolwiek atrybut. Dlatego dodanie ścieżki z przodu na połączeniu, które już zawodzi, niczego nie zmienia.

Wśród kwalifikujących się ścieżek dla tego samego prefiksu AWS preferuje krótszy AS_PATH. Gdy dwie ścieżki są równej długości, porównuje MED, z zastrzeżeniem udokumentowanego warunku dotyczącego pierwszego AS w ścieżce. Czytaj opublikowaną kolejność, a nie wersję z folkloru, bo folklor zwykle pomija krok stanu i wyjątek dla tras statycznych. Jedna konsekwencja: trzy dodania z przodu na połączeniu zapasowym czynią główne ściśle krótszym, i to jest zwykły sposób wyrażania preferencji.

Dodawanie z przodu, i kiedy nic nie robi

Dodawanie z przodu odbywa się w ogłoszeniach wychodzących bramy klienta, nie wewnątrz AWS. Dodajesz własny ASN dwa albo trzy razy do prefiksu, którego AWS ma unikać, i AWS widzi wtedy dłuższą ścieżkę dla tego połączenia. Połączenie główne zachowuje ogłoszenie bez dodania. Jeśli oba połączenia ogłaszają z tego samego ASN z tą samą liczbą dodań, nie wyraziłeś żadnej preferencji.

Sprawdź otrzymaną ścieżkę po stronie AWS po zmianie. Dodanie, które nigdy nie opuściło urządzenia klienta, wygląda dokładnie jak to, które AWS zignorował.

Trasy statyczne ignorują cały argument

Jeśli połączenie używa routingu statycznego, nie ma AS_PATH do wydłużenia. AWS dokumentuje trasy statyczne VPN jako mające priorytet nad trasami poznanymi przez BGP dla tego samego prefiksu, więc projekt mieszany nie zachowuje się jak w pełni dynamiczny. Najpierw zdecyduj o typie routingu, potem wybierz mechanizm preferencji, który dla niego istnieje.

Przy dwóch połączeniach statycznych ogłaszających ten sam prefiks użyteczną dźwignią jest prefiks: ogłoś bardziej szczegółowy zakres na połączeniu, którego chcesz użyć, i zaakceptuj, że zmieniłeś to, który cel pasuje, a nie to, która ścieżka wygrywa.

Dlaczego brama tranzytowa to inna odpowiedź

Brama tranzytowa obsługuje wielościeżkowość o równym koszcie między przyłączeniami VPN, więc dwa połączenia mogą dzielić ruch zamiast jedno stać w gotowości. Ten projekt ma inną powierzchnię awarii: przepływy rozkładają się na tunele, a upadek jednego tunelu przenosi tylko część obciążenia. Kopiowanie recepty VGW na bramę tranzytową, albo odwrotnie, tworzy oczekiwania, których nie spełnia żadna z platform.

Wybierz model przed mechanizmem: aktywny i zapasowy z ustaloną preferencją, albo aktywny i aktywny z ECMP.

Co sprawdzić po skonfigurowaniu

Potwierdź cztery rzeczy po kolei. Tabela podsieci nadal rozwiązuje prefiks na zamierzoną bramę. Brama wymienia oba tunele jako aktywne. Otrzymany AS_PATH na połączeniu, którego chcesz unikać, jest dłuższy niż drugi. I prawdziwy przepływ z instancji w tej podsieci przechodzi oczekiwanym tunelem, zaobserwowany na obu końcach, a nie wywnioskowany z zielonego statusu.

Następnie uruchom zatwierdzony test przełączenia i obserwuj, jak ocalała ścieżka niesie usługę. Preferencja, która istnieje tylko w różnicy konfiguracji, jeszcze nie jest preferencją.