Sąsiedzi EIGRP nie wstają na nakładce DMVPN

Unicast przez nakładkę działa, a sąsiedztwo nadal zawodzi, więc sprawdź replikację multicast NHRP, politykę EIGRP tunelu i IPsec jako trzy osobne warstwy.

Tunel jest podniesiony, jeden spoke może pingować drugi, a EIGRP nadal nie pokazuje żadnego sąsiada na hubie. Ta kombinacja jest normalna, nie tajemnicza: ping dowodzi osiągalności unicast przez NHRP, a hello EIGRP są multicastem. W nakładce DMVPN model dostarczania protokołu routingu to druga płaszczyzna konfiguracji i właśnie ją ludzie pomijają, bo pierwsza płaszczyzna już wygląda zdrowo. Każda warstwa poniżej jest sprawdzana własnym poleceniem, więc awaria w jednej nie odsyła cię na początek listy.

Zapisz sąsiedztwa, których oczekujesz

Przed jakimkolwiek poleceniem show zrób krótką listę: który spoke ma peering z którym hubem, przez który interfejs tunelu i w którym systemie autonomicznym EIGRP. Projekty z wieloma hubami zawodzą w lukach między hubami, a lista zamienia „EIGRP jest zepsuty” na „spoke 3 nie rejestruje się na hubie 2”. Uwzględnij podsieci tunelu, których oczekujesz na każdym łączu, bo niezgodność adresów między dwoma końcami wygląda dokładnie jak awaria protokołu. Zapisz listę w zgłoszeniu, żeby następna zmiana porównywała z projektem, a nie z ostatnim zrzutem ekranu.

Sprawdź NHRP, potem ścieżkę multicast

Zacznij od stanu rejestracji i mapowań, które hub rzeczywiście trzyma. Spoke bez dynamicznego wpisu na hubie nie zarejestrował się i żaden protokół routingu tego nie naprawi. Następnie potwierdź, że spoke przyjmuje multicast z adresu NBMA huba, co jest osobnym wierszem od wpisu NHS.

show dmvpn
show ip nhrp
show ip nhrp nhs detail
interface Tunnel0
 ip nhrp network-id 1
 ip nhrp nhs 203.0.113.1 nbma 198.51.100.1
 ip nhrp map multicast 198.51.100.1
 tunnel mode gre multipoint
 tunnel key 100

To właśnie wiersz ip nhrp map multicast pozwala spoke wysyłać swoje hello do huba jako replikowany multicast przez nakładkę i pozwala multicastowi huba docierać do zarejestrowanych spoke’ów. Bez niego unicast przez NHRP działa, a multicast nie, i to właśnie ten podział sprawia, że ping wygląda jak dowód. Przewodnik Cisco IOS XE DMVPN dokumentuje zachowanie multicasting po stronie huba i spoke’ów dla każdej fazy, więc dopasuj konfigurację do fazy, którą naprawdę wdrożyłeś, zamiast kopiować fragment z innej topologii.

Sprawdź własną politykę interfejsu EIGRP

Tunel, którego nie ma w procesie EIGRP albo który jest passive, nigdy nie utworzy sąsiedztwa, niezależnie od tego, jak zdrowa jest nakładka. Czytaj udział interfejsu i tablicę sąsiadów razem, bo pierwsze wyjaśnia drugie.

show ip eigrp interfaces detail Tunnel0
show ip eigrp neighbors detail
show run | section router eigrp
router eigrp 100
 network 10.10.0.0 0.0.0.255
 passive-interface default
 no passive-interface Tunnel0

Uwierzytelnianie i wagi metryki muszą się zgadzać po obu stronach. Łańcuch kluczy w złym trybie albo niezgodność wartości K wyrzuca hello bez wyraźnego wiersza syslog u odbiorcy. Jeśli projekt używa jawnie skonfigurowanych sąsiadów unicast, trzymaj się tego modelu w całości, zamiast dokładać go na ustawienia multicast, aż coś wstanie.

Trzymaj transport GRE i ochronę IPsec osobno

DMVPN przenosi multicast wewnątrz GRE, a IPsec chroni pakiety GRE, a nie wewnętrzny multicast bezpośrednio. Dlatego ogólne twierdzenie, że IPsec nie może przenosić multicasting, jest w tym projekcie błędne i bezużyteczne jako diagnoza. Sprawdź profil IPsec na tunelu, asocjacje bezpieczeństwa dla każdego peera i stan interfejsu tunelu jako trzy osobne fakty.

show crypto ipsec sa peer 198.51.100.1
show interfaces Tunnel0 | include line protocol
show ip nhrp multicast

SA, które jest podniesione i którego liczniki rosną, podczas gdy EIGRP zostaje na dole, zawraca twoje dochodzenie wyżej w stosie: pakiety są chronione i dostarczane, więc problem polega na tym, które pakiety protokół wybiera do wysłania.

Weryfikuj trasy, nie tylko liczbę sąsiadów

Gdy sąsiedztwo się uformuje, przeczytaj, co ogłasza i instaluje. Na tunelu wielopunktowym split horizon i zachowanie next-hop decydują, czy spoke dotrze do innego spoke’a przez hub, a agregacja może ukryć prefiks nawet przy idealnej relacji sąsiedztwa.

Zakończ dozwoloną aplikacją między dwiema lokalizacjami i potwierdź ścieżkę, którą obiera. Bezpośrednie skróty spoke-to-spoke to wymóg przekazywania z własnym stanem NHRP i bezpieczeństwa, a dodawanie ich, żeby liczba sąsiadów wyglądała lepiej, zwykle tworzy drugi problem.

Zapisz projekt fazowy, mapowanie multicast i politykę EIGRP w jednym miejscu. Następny inżynier będzie potrzebował projektu, a nie transkrypcji.

Powiązane artykuły