Pytanie 3 fazy Cisco DMVPN

10

Miałem nadzieję, że ktoś może rzucić nieco światła na problem, który mam. Mam utworzone przez siebie laboratorium, które jest wieloregionalną siecią Hub i Spoke. Istnieje 5 węzłów regionalnych wraz z jednym węzłem centralnym. Każdy region ma 4 szprychy.

Mój problem pojawia się, gdy próbuję użyć fazy 3 dla DMVPN. Myślę, że wiem, co się dzieje, po prostu nie jestem pewien, jak to naprawić. Zasadniczo spróbuję pingować z komputera poza szprychą do centralnego hubu. Przebywa pierwsza para pingów, a następnie nie przechodzą kolejne pingi. Gdy wysyłane są pierwsze sygnały ping, powinny one przemierzać całą sieć (Host-Spoke-Regional Hub-Central Hub). Po utworzeniu mapowań NHRP próbuje ono przejść punkt-punkt dla tego połączenia i przerywa sieć, ponieważ tunele znajdują się w różnych podsieciach. Oto odpowiednie informacje o sieci:

Wszystkie routery korzystają z EIGRP (AS 1). Wszystkie sąsiedzi są tworzone poprawnie, a tabela routingu jest zapełniana zgodnie z oczekiwaniami.

Sieć od regionalnego do centralnego hubu to tunel 0. 172.16.0.0/24.

Sieć regionalna do Spoke to tunel 1. Sieć 172.16.1.0/24.

Wszystkie interfejsy zewnętrzne znajdują się w sieci 192.168.1.0/24.

Wewnątrz interfejsów postępuj zgodnie z następującym schematem: 10. region.spoke.0 / 24 (Central to 10.0.0.0/24, Regional Hubs to 10.region.0.0 / 24).

Wszelkie informacje, które możesz dostarczyć, są bardzo mile widziane.

cisco Ryan
źródło
Czy jakaś odpowiedź ci pomogła? jeśli tak, powinieneś zaakceptować odpowiedź, aby pytanie nie wyskakiwało wiecznie, szukając odpowiedzi. Alternatywnie możesz podać i zaakceptować własną odpowiedź.
Ron Maupin

Odpowiedzi:

1

Mamy więc CenterHubx1-> RegionHubx5-> Spokesx4-> Komputer

Pingi komputerowe -> Hub, nie wyszukują nhrp w Spoke, konfigurują nowy tunel do CenterHub.

Problem Mówiono VPN w podsieci 172.16.1 / 24 i Hub 172.16.0 / 24

Spoke nie powinien próbować konfigurować bezpośredniego połączenia z CenterHub, tylko z innymi szprychami swojego RegionHub

Aby temu zapobiec, używaj różnych identyfikatorów sieci NHRP dla różnych podsieci tunelu.

Zacytować:

Identyfikator sieci NHRP służy do zdefiniowania domeny NHRP dla interfejsu NHRP

Pieter
źródło
Dziękuję za odpowiedź. Użycie różnych identyfikatorów sieci pozwala na przejście ruchu, ale pokonuje fazę 3 (ruch między palcami musi przechodzić przez koncentrator, a nie od głosu do mówcy). Udało mi się rozwiązać problem za pomocą PBR, ale to rozwiązanie nie skaluje się dobrze.
Ryan
Potrzebujesz więc możliwości skonfigurowania dynamicznego tunelu między dowolnym urządzeniem. Mogę wymyślić dwie opcje. A. Czy próbowałeś umieścić wszystkie sieci VPN w tej samej podsieci - niechlujny B. ip un-numberd i ospf dla łączności z LB
Pieter
Tak, to był inny sposób, w jaki to rozwiązałem. Zaprojektowałem topologię, aby wszystkie tunele hierarchiczne znajdowały się w tej samej podsieci. Nie do końca tak, jak zaprojektowano fazę 3, ale pozwala ona skalować sieć lepiej niż inne wdrożenia DMVPN.
Ryan,
0

Problemem mogą być klucze GRE.

Wszystkie tunele w routerach koncentrujących MUSZĄ mieć ten sam klucz GRE (w przeciwnym razie szprycha nie może wysłać pakietu do niepodłączonego koncentratora - przemyśl to), co oznacza, że MUSISZ mieć wiele adresów IP na routerach koncentrujących, aby zakończyć tunele GRE ( ponieważ nie można ich rozróżnić według kluczy GRE).

ioshints
źródło