Hierarchiczny DMVPN: jedna chmura na każdą relację tunelu

Węzeł oddziału rejestruje się pomyślnie w swoim regionalnym koncentratorze i nadal nie dociera do usługi w innym regionie. Tunel działa, stan NHS wygląda zdrowo, a awaria pojawia się tylko dla celów przekraczających granicę warstwy. Ten wzorzec zwykle oznacza, że projekt nigdy nie określił, które urządzenia uczestniczą w której chmurze DMVPN, więc warstwy zbudowano intuicyjnie i teraz się nie zgadzają.

Objaw pojawia się na granicy warstw

W projekcie hierarchicznym koncentrator centralny, kilka koncentratorów regionalnych i wiele oddziałów zajmują każdy swoją pozycję. Koncentrator regionalny może mieć więcej niż jedną relację tunelu, a oddziały nie muszą rejestrować się w każdym centralnym punkcie końcowym. Ważne ścieżki to oddział do usługi regionalnej, oddział do innego zatwierdzonego węzła regionalnego i oddział do celu centralnego.

Gdy jedna z tych ścieżek zawodzi, a pozostałe działają, problemem prawie zawsze jest brakująca lub sprzeczna definicja roli, a nie uszkodzony tunel. Zapisz zamierzone ścieżki i porównaj je z tym, co urządzenia faktycznie zbudowały. To porównanie zajmuje godzinę i zapobiega tygodniowi zgadywania. Przechowuj je razem z dokumentem projektu.

Jedna chmura, jeden kontrakt interfejsu

Dla każdej chmury zapisz interfejs tunelu, adresację nakładki, lokalne źródło sieci bazowej, relacje NHS i NBMA, dostarczanie multicast oraz politykę ochrony. Wskaż też, które trasy przechodzą między kontekstem regionalnym a centralnym, bo właśnie to zdanie jest projektem.

Koncentrator regionalny z dwoma interfejsami tunelu potrzebuje dwóch kontraktów, a nie jednego z dwoma adresami. Źródło sieci bazowej, domena NHRP i trasy mogą się różnić dla każdego interfejsu, a dokument, który je łączy, wprowadzi w błąd tego, kto konfiguruje drugi.

Identyfikatory to kontekst lokalny, a nie kontrola dostępu

Identyfikatory sieci NHRP i klucze GRE to dwie wartości najczęściej mylone z ustawieniami globalnymi. Przewodnik NHRP w IOS XE opisuje identyfikator sieci jako lokalnie istotny, więc zgodne numery na zdalnych routerach niczego nie uwierzytelniają, a zmiana lokalnego numeru jednego routera nie tworzy granicy dostępu.

Klucz GRE, gdy projekt go używa, pomaga rozpoznać kontekst tunelu odbierającego i jest uzgadniany między punktami końcowymi, które dzielą ten kontekst. Nie jest hasłem i nie zastępuje uwierzytelniania IKE ani polityki routingu. Traktuj obie wartości jako kontekst konfiguracji, który musi być zgodny w ramach relacji, a nie jako mechanizmy bezpieczeństwa oddzielające regiony.

Routuj między warstwami świadomie

Zdecyduj, które prefiksy koncentrator regionalny ogłasza w górę i jakie cele centralne oferuje swoim oddziałom. Następnie sprawdź rzeczywisty następny skok i zachowanie skrótu specyficzne dla fazy dla każdej ścieżki, ponieważ trasa podsumowana i skrót mogą dawać zupełnie inne przekazywanie, niż sugeruje diagram.

Użyj routingu i polityki dostępu, aby wymusić separację regionalną. Jeśli oddział nie może bezpośrednio osiągnąć innego regionu, muszą to powiedzieć trasa i polityka, zamiast polegać na identyfikatorze, który nigdy nie był do tego przeznaczony. Zapisz politykę obok identyfikatora. W przeciwnym razie następny inżynier założy, że numer wykonuje tę pracę.

Zdiagnozuj nieoczekiwany skrót

Gdy oddział próbuje utworzyć bezpośrednią relację z centralnym punktem końcowym, zanim losowo zmienisz identyfikatory, sprawdź jego trasę, mapowanie NHRP i wybrany kontekst tunelu. Brak osiągalności, niezamierzona relacja NHS i legalny, ale nieautoryzowany skrót wymagają trzech różnych poprawek.

Przewodnik konfiguracji DMVPN pokazuje ustawienia tunelu i NHRP razem, i właśnie dlatego zakresy trzeba najpierw rozdzielić na papierze. Zapisz kontrakty chmury, utrzymuj jawne trasy warstw, a następna awaria granicy będzie miała na co wskazać.