Sąsiad EIGRP czy tranzyt DMVPN? Najpierw sprawdź rolę

Sąsiedztwa brakuje, a router pośrodku wygląda na oczywistego podejrzanego. Może być niewinny. Przekazywanie zewnętrznych pakietów tunelu i udział w protokole routingu overlay to dwa różne zadania, a urządzenie może wykonywać pierwsze bez drugiego. Przejdź przez pięć kontroli poniżej po kolei i zatrzymaj się na pierwszej, która zawiedzie.

Krok 1: narysuj dwie role

Narysuj zamierzone sąsiedztwo EIGRP jako logiczne połączenie między dwoma routerami, a następnie narysuj routery underlay, które przenoszą jego pakiety tunelu. To samo urządzenie nie musi występować na obu listach, a mylenie list to najczęstsza przyczyna oskarżania zdrowego routera tranzytowego o zepsucie sąsiedztwa.

Router tranzytowy przekazuje zewnętrzne pakiety za pomocą zwykłego routingu IP i polityki. Nie musi uruchamiać protokołu przenoszonego wewnątrz chronionego tunelu ani nie potrzebuje procesu EIGRP, aby przekazać te pakiety dalej.

Krok 2: sprawdź, co kończy urządzenie pośrodku

Jeśli środkowy router kończy tunel i ma tworzyć sąsiedztwa EIGRP ze spoke, odpowiedź zmienia się całkowicie. To urządzenie potrzebuje obsługiwanego zachowania routingu overlay, a nazywanie go tranzytem nie usuwa wymagania sąsiada. Przeczytaj konfigurację tunelu przed konfiguracją routingu. Ta odpowiedź decyduje o każdej kolejnej kontroli.

Pierwsze prawdziwe pytanie nie brzmi więc, który protokół dostroić. Brzmi: czy pudełko jest hubem, spoke, czystym przeskokiem underlay czy usługą Layer 2, która przenosi ramki między punktami końcowymi.

Krok 3: zweryfikuj płaszczyznę sterowania sąsiada

Na każdym urządzeniu, które powinno być sąsiadem, potwierdź cztery rzeczy: instancję EIGRP i numer systemu autonomicznego, parametry uwierzytelniania, interfejs uczestniczący w procesie oraz polecenie sieciowe obejmujące ten interfejs. Niezgodność w którymkolwiek z nich utrzymuje sąsiedztwo na dole, podczas gdy interfejs pozostaje w górze, a ping nadal działa.

RFC 7868 opisuje EIGRP jako protokół IP z wymianą sterowania multicast, dlatego relacja sąsiedzka nie jest czymś, co router pośredniczący może zastąpić, routując pakiety do celu. Albo wymiana sterowania dociera do partnera, albo sąsiedztwo nie powstaje.

Krok 4: zweryfikuj, że transport dostarcza wymianę sterowania

Następnie sprawdź, czy overlay naprawdę przenosi ruch sterowania między zamierzonymi punktami końcowymi. Sprawdź mapowanie NHRP dla partnera i trasę zewnętrzną, która do niego prowadzi, a potem potwierdź, że interfejs tunelu jest w górze i przepuszcza ruch. Udany ping underlay dowodzi, że ścieżka zewnętrzna istnieje; nie dowodzi, że wymiana sterowania overlay została dostarczona.

Przezroczysta usługa Layer 2, tunel punkt-punkt i chmura wielopunktowa DMVPN dostarczają multicast w różny sposób. Stosuj obsługiwany model interfejsu, NHRP i multicastu dla tego, co jest faktycznie wdrożone, zamiast zakładać, że wszystkie trzy zachowują się tak samo.

Krok 5: przeprojektuj granicę, jeśli nie może uczestniczyć

Jeśli wymagane urządzenie overlay nie może uruchomić protokołu, zmień projekt wprost. Użyj obsługiwanego protokołu lub modelu wymiany na tej granicy albo zapewnij odpowiedni tunel od końca do końca, aby sąsiadami były punkty końcowe, które naprawdę ze sobą rozmawiają. Nie zakładaj, że trasa statyczna zamienia nieuczestnika w przekaźnik każdego pakietu sterowania.

Zapisz rolę każdego urządzenia na schemacie i zachowaj ją razem z konfiguracją. RFC 7868 definiuje wymianę protokołu i to ta definicja jest odniesieniem, dlaczego relacji sąsiedzkiej nie można symulować przez przekazywanie tranzytowe.

Gdy sąsiedztwo nadal nie działa po wszystkich pięciu kontrolach, pozostałymi podejrzanymi są funkcje platformy, takie jak obsługa multicastu na interfejsie tunelu i polityka filtrująca protokół 88. To konkretne, testowalne przyczyny i są warte więcej niż kolejna runda obwiniania routera pośrodku.