Maksymalna metryka OSPF: zniechęcenie do tranzytu przez oddział bez jego usuwania

Dwa biura łączą się przez oddział, który powinien nieść własny ruch i bardzo niewiele innego. Oddział potrzebuje tras do obu lokalizacji, a żadna z nich nie powinna go preferować jako drogi między nimi. Usunięcie oddziału z topologii rozwiązałoby problem tranzytu i złamało wymaganie, ponieważ oddział nadal musi docierać do obu lokalizacji, a obie lokalizacje nadal muszą docierać do oddziału.

Potrzebna jest preferencja wyrażona w protokole routingu, która pozostawia oddział w pełni osiągalny i czyni go złym wyborem dla wszystkiego, co przez niego przechodzi. Przejdź problem w kolejności, w jakiej widzą go routery.

Zacznij od ścieżki, której chcesz uniknąć

Narysuj topologię tak, jak widzi ją protokół, a nie jak widzi ją diagram. Które interfejsy tworzą sąsiedztwa, które są w tym samym obszarze i które z tych sąsiedztw niosłyby ruch między dwoma biurami, gdyby oddział był preferowany? To trzy osobne pytania, a diagram nie odpowiada wiarygodnie na żadne z nich.

Następnie znajdź ścieżkę alternatywną. Jeśli jedyna trasa między biurami prowadzi przez oddział, żadna metryka nie może przenieść z niego ruchu, ponieważ ruch nie ma dokąd pójść. Nadmiarowość nie jest szczegółem tego projektu; jest warunkiem wstępnym. Druga ścieżka istniejąca tylko na papierze się nie liczy.

show ip ospf neighbor
show ip ospf interface brief
show ip route 10.40.0.0

Te trzy widoki odpowiadają na różne pytania: kto jest sąsiadem, które interfejsy uczestniczą i za jaką cenę, oraz którą ścieżkę wybiera urządzenie w tej chwili. Wdrożenie tunelu dodaje czwarty: linia na diagramie nie jest dowodem, że sąsiedztwo powstało przez nią, a powstałe sąsiedztwo nie jest dowodem, że przekazywanie idzie tą samą ścieżką. Właśnie w projektach tuneli ta luka ujawnia się najczęściej.

Co ogłasza metryka maksymalna

RFC 6987 opisuje router, który ogłasza swoje łącza niebędące stub z maksymalną metryką łącza, zdefiniowaną jako 0xffff. Router nadal opisuje siebie i swoje łącza; po prostu wycenia je na górnym końcu zakresu, więc każdy inny router oblicza ścieżkę przez niego jako kosztowną.

To zmiana router-LSA, a nie usunięcie topologii. Rozróżnienie ma znaczenie: wyczyszczenie router-LSA wycofuje samą informację o topologii, co może też wycofać relacje potrzebne do dotarcia do routera i prefiksów za nim. Zachowanie ogłoszenia i podniesienie jego ceny zachowuje te relacje. To cała różnica między tą techniką a usunięciem.

Mechanizm RFC 6987 nie ma też nic wspólnego z typami obszarów ani z wyborem routera wyznaczonego. Obszar stub blokuje kategorię ogłoszeń stanu łącza na granicy obszaru, a router stub wycenia własne łącza. Podobne słowa, niepowiązana maszyneria.

Dlaczego osiągalność przetrwa, a tranzyt nie

Inne routery nadal mają trasę do podłączonych prefiksów oddziału, ponieważ oddział nadal je ogłasza, a łącza nadal istnieją. Zmienia się całkowity koszt każdej ścieżki przechodzącej przez oddział w drodze gdzie indziej. Prefiksy się nie przesuwają; zmienia się tylko cena przejścia przez router.

Dla ruchu, którego źródłem lub celem jest sam oddział, drogie łącze nadal leży na jedynej rozsądnej ścieżce, więc jest używane. Dla ruchu między dwoma biurami ścieżka alternatywna wygrywa teraz kosztem, a oddział wypada z decyzji o przekazywaniu, nie znikając z topologii. Dwa kierunki, dwie różne odpowiedzi, i obie oznaczają, że mechanizm działa.

To zachowanie należy zweryfikować, a nie założyć. Spójrz na router-LSA generowany przez oddział, potem na ścieżkę, którą inny router wybiera dla celu za oddziałem i dla celu w drugim biurze. Obie odpowiedzi powinny się różnić, a jeśli się nie różnią, zmiana metryki nie dociera do decyzji, o której myślisz.

Problem ostatniej ścieżki

Ten sam RFC wyraźnie stwierdza, że technika nie zabrania użycia. Gdy ścieżka alternatywna zawiedzie, routery wracają do drogiej ścieżki przez oddział, ponieważ nadal jest ważna i protokół przedkłada drogą trasę nad brak trasy.

Czy ten powrót jest akceptowalny, to pytanie polityki, na które trzeba odpowiedzieć przed wdrożeniem. Oddział na małym łączu wyjściowym, który nagle niesie ruch między biurami, może być gorszy niż awaria i może być dokładnie tym, czego chcesz w oknie serwisowym. Obie odpowiedzi są uprawnione; cisza nie.

Jeśli wymaganiem jest ścisły zakaz, a nie preferencja, sam projekt metryki go nie da. Potrzebne jest egzekwowanie przekazywania zgodne z intencją oraz zdefiniowane zachowanie dla przypadku, gdy ruch i tak dotrze. Ogłaszanie ścieżki jako użytecznej, a potem porzucanie ruchu tworzy czarną dziurę, którą trudniej zdiagnozować niż pętlę routingu.

Dla OSPFv3 RFC omawia bit R jako inny sposób wykluczenia udziału w tranzycie. Nie zakładaj, że dziedziczy to samo zachowanie ostatniej ścieżki co technika maksymalnej metryki, i nie kopiuj ustawień między dwiema rodzinami adresów, jakby to była ta sama funkcja.

Udowodnij to w warunkach normalnych i awaryjnych

Przetestuj dwa razy: raz z obiema dostępnymi ścieżkami i raz z usuniętą ścieżką preferowaną. Pierwszy test pokazuje, że preferencja działa, a drugi pokazuje, co robi sieć, gdy preferencji nie można dochować. Pominięcie drugiego testu pozostawia ważną połowę niezbadaną.

show ip ospf database router 10.0.0.3
show ip route 172.20.8.0
traceroute 172.20.8.1

Widok bazy danych pokazuje ogłoszoną metrykę, wyszukanie trasy pokazuje wybrany następny skok, a śledzenie pokazuje, dokąd pakiety faktycznie poszły. Gdy te trzy się zgadzają, masz zweryfikowany projekt, a nie konfigurację, która wygląda poprawnie.

Następnie przywróć preferowaną ścieżkę i potwierdź, że oddział wraca do niesienia tylko własnego ruchu. Krok przywracania należy do testu, a nie do sprzątania, bo projekt, który działa tylko do następnej zmiany, nie jest projektem. Zapisz oba wyniki, w tym powrót, ponieważ drugi to odpowiedź, której ktoś będzie potrzebować o trzeciej nad ranem.