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

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