BGP poznał prefiks, ale ruch nadal omija tunel

Brama oddziału pokazuje prefiks chmury w swojej tablicy BGP, sesja z dostawcą jest nawiązana, a mimo to żądanie użytkownika do tego prefiksu wychodzi przez niewłaściwy interfejs. Nic nie jest zepsute tak, jak sugeruje monitoring, bo „BGP się tego nauczył” to stwierdzenie o płaszczyźnie sterowania. Między tą tablicą a pakietem są cztery odrębne przejścia, a przepływ zatrzymuje się dokładnie na jednym z nich. Przejdź bramy po kolei i zatrzymaj się na pierwszej, która zawodzi.

Pierwsza brama: co sąsiad faktycznie wysłał

Zacznij od prefiksu takiego, jaki został odebrany, a nie streszczonego. Znajdź dokładną sieć i maskę w tablicy BGP i zapisz następny skok, ścieżkę AS oraz każdą społeczność, którą polityka importu może dopasować. Trasa zbiorcza na pulpicie może ukryć fakt, że konkretny prefiks nigdy nie został zaakceptowany.

Polityka importu to zwykłe miejsce, w którym trasa znika bez błędu. Lista prefiksów, filtr społeczności lub mapa tras przychodzących mogą odrzucić aktualizację, podczas gdy sesja pozostaje w górze i zdrowa, dlatego zielone światło sąsiada dowodzi tak niewiele. Brak linii w logu nie oznacza braku decyzji. Zwykle oznacza, że decyzja została podjęta cicho, dokładnie tak, jak skonfigurowano.

show ip bgp 10.60.20.0/24
show ip bgp neighbors 203.0.113.5 advertised-routes
show ip route 10.60.20.0
show ip cef 10.60.20.0

Czytaj wynik w tej kolejności. Pierwsze dwa polecenia mówią, czy informacja dotarła i co partner twierdzi, że wysłał; ostatnie dwa, czy coś dotarło do tablic routingu i przekazywania. Prefiks obecny w pierwszym poleceniu i nieobecny w trzecim to problem wyboru lub instalacji, a nie łączności.

Druga brama: wybór, potem instalacja

BGP wybiera najlepszą ścieżkę, a wybrana ścieżka nie jest instalowana automatycznie. Następny skok musi się rozwiązać, a inne źródło tras może już posiadać ten prefiks z lepszą odległością administracyjną. Trasa statyczna pozostała po migracji łatwo pokona prawidłową ścieżkę BGP i wyśle ruch gdzie indziej.

RFC 4271 trzyma trzy idee osobno: co wysłał partner, co ten mówca wybrał jako najlepsze i co będzie dalej ogłaszać. To role pojęciowe, a nie trzy fizyczne bazy danych, które dostawca musi ujawnić, ale właśnie ten rozdział czyni „to jest w BGP” niepełną odpowiedzią.

Sprawdź też, który kontekst routingu czytasz. Trasa zainstalowana w VRF, do której nie należy interfejs użytkownika, jest niewidoczna dla pakietów tego użytkownika, a tablica przez cały czas wygląda poprawnie.

Trzecia brama: wyszukiwanie właściwe dla tego przepływu

Teraz przestań pytać o trasę i zacznij pytać o pakiet. Zapisz adres źródłowy użytkownika, cel, protokół, port i interfejs wejściowy, bo każdy z nich może wybrać inną politykę. Potem spójrz na wyszukiwanie właściwe dla tej kombinacji, a nie na ogólną tablicę routingu.

ip route get 10.60.20.25 from 10.60.10.40
ip rule show
sudo tcpdump -ni tun0 'host 10.60.20.25'

Bardziej szczegółowy prefiks to najczęstsza niespodzianka, a trasa polityki jest druga. Oba nadpisują agregat, na który patrzyłeś, i żadne nie jest widoczne w podsumowaniu tablicy BGP.

Ping wysłany z samej bramy nie jest dowodem w sprawie sesji użytkownika. Inny adres źródłowy, inna ścieżka polityki i często inny wynik. Testuj z tym samym źródłem, którego używa aplikacja, albo przyjmij, że test odpowiada na inne pytanie.

Czwarta brama: odległa połowa ścieżki

Jeśli lokalne wyszukiwanie rzeczywiście wybiera tunel, pakiet nadal musi zostać zaakceptowany przez politykę ochrony, dopuszczony przez regułę przekazywania i obsłużony odpowiedzią po drugiej stronie. ACL kryptograficzny bez pary adresów porzuci ruch, podczas gdy tunel zgłasza się jako aktywny, co daje przekroczenie czasu nieodróżnialne od awarii routingu.

Droga powrotna liczy się tak samo jak wychodząca. Strona chmury musi wiedzieć, jak dotrzeć do źródła oddziału, albo przez trasę, albo przez tłumaczenie skonfigurowane celowo. Asymetryczne drogi powrotne są częste w projektach testowanych tylko w jednym kierunku.

Powiąż świeże autoryzowane połączenie z trzema obserwacjami: dopasowaną polityką lokalną, poruszonymi licznikami tunelu i odbiorem po stronie zdalnej, gdzie jest widoczny. Jeśli liczniki się nie ruszają, pakiet nigdy nie wszedł do tunelu, cokolwiek mówi tablica tras. Jeśli się ruszają, a nic nie dociera, strona zdalna go porzuca lub źle routuje. Te dwa wyniki prowadzą do zupełnie innych zespołów.

Nazwij przejście, które zawiodło

Zapisz wynik jako jeden z pięciu stanów: nie odebrano, nie zaakceptowano przez politykę, nie wybrano, nie zainstalowano lub nie dopasowano do tego przepływu. Dodaj szósty dla przypadku, gdy ścieżka lokalna jest poprawna, a zdalny koniec nie może odpowiedzieć. To zdanie jest rezultatem i jest znacznie bardziej użyteczne niż zrzut ekranu nawiązanego sąsiedztwa.

Utrzymuj też test negatywny w planie odbioru: cel, który nie powinien przechodzić przez tunel, sprawdzony po zmianie. Lista kontrolna dowodząca tylko szczęśliwej ścieżki nie wychwyci szerokiej reguły polityki, którą ktoś doda w następnym oknie serwisowym.