Przekazanie L3VPN: trasy prywatne, trasa domyślna czy pełna tablica?

Łącze działa, VRF jest skonfigurowana, a dostawca zadaje krótkie pytanie, które rozstrzyga resztę projektu: co ma otrzymać brzeg klienta? Trzy odpowiedzi są typowe i żadna nie wynika z faktu, że istnieje stos etykiet. To decyzje usługowe o tym, gdzie ruch opuszcza oddział.

Przejście przez przekazanie w kolejności to najtańszy sposób, by zrobić to dobrze. Zaczyna się od tego, co dzieje się z ruchem, który do niczego nie pasuje, potem zapisuje się prefiksy prywatne i ich zachowanie przy awarii, a dopiero na końcu rozmawia się o tym, jak duży strumień jesteś gotów przenosić.

Zacznij od ruchu, którego nikt nie zaplanował

Zadaj jedno pytanie, zanim pojawi się jakakolwiek lista prefiksów: kiedy pakiet nie pasuje do żadnej trasy prywatnej, dokąd ma trafić? Oddział z własnym łączem internetowym zwykle trzyma lokalną trasę domyślną, więc zwykły ruch webowy wychodzi przez lokalny firewall i nigdy nie dotyka dostawcy. W takim projekcie VPN przenosi tylko zdalne witryny prywatne, a wyboru dokonują bardziej szczegółowe prefiksy.

Oddział, który ma korzystać z wyjścia centralnego, to przypadek odwrotny. Tam trasa domyślna wskazuje do wnętrza usługi, a dostawca lub witryna centralna odpowiada za przekazywanie, routing powrotny i wszelkie tłumaczenie. Powiedzenie "domyślnie do VPN" bez tego właściciela daje oddział, który rozwiązuje nazwy i do niczego nie dociera.

Oba projekty różnią się tym, jak wygląda awaria routingu, dlatego zgadywanie jest kosztowne. Przy lokalnej trasie domyślnej utracona trasa prywatna wysyła ten ruch do internetu, gdzie firewall go odrzuca albo, co gorsza, odpowiada coś, czego nie zamierzałeś. Przy centralnej trasie domyślnej ta sama utrata całkowicie odbiera dostęp do internetu, a zgłoszenie przychodzi jako "cały oddział leży". Żadna z awarii nie jest sama w sobie błędna, ale tylko jedna odpowiada sprzedanej usłudze, a sama konfiguracja BGP nie powie ci, którą zbudowałeś.

Zapisz prefiksy prywatne wraz z ich przypadkiem awarii

Wymień prefiksy, do których oddział musi dotrzeć, i zaznacz, które są agregowane. Agregat o jeden bit za szeroki wciąga nieznane cele do VPN, co jest w porządku tylko wtedy, gdy druga strona naprawdę je posiada i przekazuje.

Następnie opisz zamierzone zachowanie, gdy usługa prywatna zawiedzie. Utrzymana trasa odrzucająca trzyma ruch z dala od nieautoryzowanej ścieżki i daje czystą, oczekiwaną przerwę. Pływająca trasa domyślna może zachować dostępność, przechodząc na ścieżkę zapasową, ale tylko jeśli ta ścieżka jest upoważniona do przenoszenia tego ruchu.

Dostępność i dozwolone obejście trzymaj jako dwa osobne wymagania w dokumencie przekazania. Zespoły, które je scalają, kończą na kłótni o to, czy oddział powinien był paść, zamiast sprawdzać, czy uzgodniona polityka została wdrożona.

Sprawdź, co CE naprawdę zainstalował

Zamiar konfiguracji i stan przekazywania rozchodzą się dość często, by weryfikacja należała do przekazania, a nie do przeglądu incydentu. Na brzegu klienta IOS-XE trzy poniższe polecenia odpowiadają na trzy różne pytania: co zaproponowano, co przyjęto i co jest faktycznie używane.

show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0

Uruchom wszystkie trzy w dniu przekazania, a nie miesiąc później, dopóki ktoś jeszcze pamięta, co uzgodniono. Pierwsze wyjście zależy od soft-reconfiguration inbound albo zapisanego odświeżenia tras; bez jednego lub drugiego CE nie pokaże ci, co odrzucił. Drugie pokazuje trasy przyjęte i najlepsze po polityce. Trzecie mówi, dokąd naprawdę idzie trasa domyślna, i to jest najbardziej użyteczna linia w całym przekazaniu.

Uruchom te same kontrole na drugim CE, jeśli witryna ma dwa łącza. Asymetryczna akceptacja między dwoma brzegami to częsta przyczyna "działa z jednego serwera, a z drugiego nie", i jest niewidoczna w różnicy konfiguracji, która wygląda symetrycznie.

Oceń większy strumień, zamiast go zakładać

Czasem klient naprawdę potrzebuje informacji o trasach internetowych wewnątrz VRF, do routingu politycznego albo do wyjścia centralnego sterującego po prefiksie. To wymaganie, które trzeba zgłosić, ograniczyć i wycenić, a nie ukryta trasa domyślna. Wiąże się z pamięcią na RIB i FIB, CPU na aktualizacje, utrzymaniem filtrów i właścicielem powstałej tablicy.

Argumenty o pojemności mylą się w obu kierunkach. Pełna tablica wewnątrz VRF nie jest zabroniona, ale też nie jest darmowa. Podobnie nie można wywnioskować dzisiejszego kosztu ze starej liczby tras, a mniejszy przydział etykiet nie usuwa kosztu przechowywania tras.

Specyfikacja BGP/MPLS IP VPN omawia kilka rozwiązań dostępu do internetu obok samej usługi VPN i nie ogłasza pełnej tablicy ani trasy domyślnej obowiązkowymi dla każdego klienta, i właśnie na ten rozdział warto wskazać, gdy pojawia się twierdzenie o "standardowej praktyce": RFC 4364.

Zamknij przekazanie, zapisując zbiór ogłaszany, zbiór otrzymany i zbiór wybrany obok uzgodnionej polityki wyjścia oraz testując jeden cel prywatny, jeden zamierzony cel publiczny i jeden przypadek utraty trasy. Podpisany zapis tych trzech testów rozstrzyga więcej sporów niż jakiekolwiek stwierdzenie o tym, co robi większość sieci.