Implementierung des DMVPN Phase3 Multi-Subnetz-Designs

Einleitung

In diesem Dokument werden Routing-Überlegungen in einem DMVPN Phase3-Design mit mehreren Subnetzen beschrieben, um sicherzustellen, dass direkte Spoke-to-Spoke-Tunnel korrekt erstellt werden. 

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Grundkenntnisse von Dynamic Multipoint VPN (DMVPN)
• Grundkenntnisse des Next-Hop Resolution Protocol (NHRP)

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle verstehen.

Hintergrundinformationen

Sowohl die Implementierung von Phase2 als auch Phase3 mit DMVPN ermöglicht einem Spoke-Gerät den Aufbau eines direkten Spoke-to-Spoke-Tunnels und muss nicht durch den Hub geleitet werden. DMVPN Phase 3 bietet jedoch eine wesentlich bessere Skalierbarkeit, da der NHRP-Umleitungsmechanismus für die Spoke-Topologie die Remote-Netzwerke über NHRP dynamisch erkennt und anschließend NHRP-(H)-Routen in die Routing-Tabelle installiert. Dadurch wird die Phase-2-Einschränkung aufgehoben, wonach jede Spoke über spezifische Netzwerkpräfixe für die Remote-Netzwerke in ihrer Routing-Tabelle verfügen muss. In Phase 3 muss die NHRP-Auflösungsantwort von der Ziel-Spoke (NBMA-Austrittspunkt) über den direkten Spoke-to-Spoke-Tunnel laufen. Ein Multi-Subnetz Phase3-Design muss jedoch besonders berücksichtigt werden, damit ein Spoke-to-Spoke-Tunnel richtig gebaut werden kann. In diesem Artikel werden diese Anforderungen ausführlich erläutert.

Problem

DMVPN Phase3 kann entweder in einem einzelnen Subnetz-Overlay oder in einem Multi-Subnetz-Overlay implementiert werden. In einer Overlay-Topologie mit einem Subnetz werden der Hub und alle Spoke-Router-Tunneladressen aus einem einzigen logischen IP-Subnetz zugewiesen. Bei einem Multi-Subnetz-Design hingegen muss ein Spoke-to-Spoke-Tunnel für Stationen erstellt werden, deren Tunneladressen sich in verschiedenen IP-Subnetzen befinden. Das zweite Szenario wird in einem hierarchischen DMVPN-Design verwendet, wie in der Abbildung unten gezeigt.

DMVPN Phase3 Multi-Subnetz-Topologie

Problemdetails

Bei der DMVPN-Phase 3 wird allgemein davon ausgegangen, dass die Ziel-Spoke beim Empfang der NHRP-Auflösungsanforderung den IPsec-Tunnel zur Quell-Spoke initiiert und anschließend die Auflösungsantwort über diesen Tunnel sendet. Dies ist jedoch nur bei einem einzelnen Subnetz-Overlay der Fall. Wenn sich die Tunnelschnittstellen der Stationen in unterschiedlichen logischen IP-Subnetzen befinden, können die NHRP-Steuerungspakete über den Spoke-Hub-Spoke-Pfad anstatt über den direkten Spoke-to-Spoke-Tunnel übertragen werden. Nachfolgend finden Sie die Ereignisabfolge, wenn Spoke1 eine Problemlösungsanforderung an Spoke2 sendet, nachdem es eine NHRP-Umleitung von Hub1 erhalten hat:

1. Spoke2 empfängt Lösungsanforderung
   
   

   *Feb  7 20:57:22.272: NHRP: Receive Resolution Request via Tunnel0 vrf global(0x0), packet size: 144
   *Feb  7 20:57:22.272:  (F) afn: AF_IP(1), type: IP(800), hop: 252, ver: 1
   *Feb  7 20:57:22.272:      shtl: 4(NSAP), sstl: 0(NSAP)
   *Feb  7 20:57:22.272:      pktsz: 144 extoff: 52
   *Feb  7 20:57:22.272:  (M) flags: "router auth src-stable nat ", reqid: 5 
   *Feb  7 20:57:22.272:      src NBMA: 172.16.1.1
   *Feb  7 20:57:22.272:      src protocol: 10.0.1.101, dst protocol: 192.168.101.1
   *Feb  7 20:57:22.272:  (C-1) code: no error(0)
   *Feb  7 20:57:22.272:        prefix: 32, mtu: 17912, hd_time: 900
   *Feb  7 20:57:22.272:        addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 255
   

2. Spoke2 fügt einen impliziten NHRP-Cacheeintrag für 10.0.1.101 hinzu, indem das Auflösungsanforderungspaket gesnoopt wird.
3. Spoke2 fügt eine Adjacency für 10.0.1.101 für Tunnel0 mit der NBMA-Adresse von Spoke1 hinzu.
4. Spoke2 antwortet mit "Resolution Reply". Beachten Sie an dieser Stelle, dass die Route für die anfordernde Spoke-Tunnel-Adresse auf Hub2 verweist:
   
   

   Spoke2#show ip route 10.0.1.101
   Routing entry for 10.0.1.0/24
     Known via "eigrp 1", distance 90, metric 3609600, type internal
     Redistributing via eigrp 1
     Last update from 10.0.2.1 on Tunnel0, 00:17:44 ago
     Routing Descriptor Blocks:
     * 10.0.2.1, from 10.0.2.1, 00:17:44 ago, via Tunnel0
         Route metric is 3609600, traffic share count is 1
         Total delay is 41000 microseconds, minimum bandwidth is 1000 Kbit
         Reliability 255/255, minimum MTU 1400 bytes
         Loading 1/255, Hops 3
   Spoke2#
   Spoke2#
   Spoke2#show ip cef 10.0.1.101
   10.0.1.0/24
     nexthop 10.0.2.1 Tunnel0
   

   Da das NHRP-Steuerungspaket entlang des gerouteten Pfads weitergeleitet wird, wird es an Hub2 anstatt an den neu erstellten Spoke-to-Spoke-Tunnel an Spoke1 gesendet:
   
   

   *Feb  7 20:57:22.360: NHRP: Send Resolution Reply via Tunnel0 vrf global(0x0), packet size: 172
   *Feb  7 20:57:22.360:  src: 10.0.2.101, dst: 10.0.1.101
   *Feb  7 20:57:22.360:  (F) afn: AF_IP(1), type: IP(800), hop: 255, ver: 1
   *Feb  7 20:57:22.360:      shtl: 4(NSAP), sstl: 0(NSAP)
   *Feb  7 20:57:22.360:      pktsz: 172 extoff: 60
   *Feb  7 20:57:22.360:  (M) flags: "router auth dst-stable unique src-stable nat ", reqid: 5 
   *Feb  7 20:57:22.360:      src NBMA: 172.16.1.1
   *Feb  7 20:57:22.360:      src protocol: 10.0.1.101, dst protocol: 192.168.101.1
   *Feb  7 20:57:22.360:  (C-1) code: no error(0)
   *Feb  7 20:57:22.360:        prefix: 24, mtu: 17912, hd_time: 900
   *Feb  7 20:57:22.360:        addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 255
   *Feb  7 20:57:22.360:        client NBMA: 172.16.2.1
   *Feb  7 20:57:22.360:        client protocol: 10.0.2.101
   *Feb  7 20:57:22.360: NHRP: Encapsulation succeeded.  Sending NHRP Control Packet  NBMA Address: 172.17.0.5

Theoretisch muss weiterhin alles funktionieren, solange alle Zwischenstationen das NHRP-Steuerungspaket zurück zum Tunnel von Spoke1 leiten können. Aber dies ist nicht immer notwendigerweise der Fall. Wenn die Behebungsantwort nicht an Spoke1 zurückgeleitet werden kann, kann kein direkter Spoke-to-Spoke-Tunnel erstellt werden. 

Bei einem einzelnen Subnetz-Overlay stellt dies kein Problem dar, da jede Spoke eine direkt verbundene Route zum Tunnelnetzwerk aufweist. Dies führt zu einer Adjacency-Suche nach der anfordernden Spoke-Tunnel-Adresse, bevor die Resolution Reply zurückgesendet wird. Da sich die Tunneladressen der Spokes in einem Multi-Subnetz-Overlay-Netzwerk nicht im selben IP-Subnetz befinden, ist es nicht sicher, dass das Resolution Reply-Paket über den direkten Spoke-to-Spoke-Tunnel gesendet wird.

Lösung

Für ein DMVPN Phase3-Design mit mehreren Subnetzen wird empfohlen, dass eine Station über einen Routing-Eintrag verfügt, der auf die Tunnelschnittstelle für jedes entfernte Station-Tunnel-Subnetz verweist, für das sie einen direkten Spoke-to-Spoke-Tunnel erstellen muss. Beispiele:

Spoke2#show run | in ip route
ip route 10.0.101.0 255.255.255.0 Tunnel0

Dadurch kann der Spoke versuchen, die Adjacency für die anfordernde Spoke-Tunnel-Adresse zu lösen, und anschließend die Resolution Reply (Lösungsantwort) über den Spoke-to-Spoke-Tunnel senden. 

Alternativ kann Resolution Reply (Lösungsantwort) auch die Spoke-Hub-Spoke-Tunnel durchlaufen. In diesem Fall müssen alle zwischengeschalteten Hub(s) eine Route zum anfordernden Spoke-Tunnel-Subnetz aufweisen, um sicherzustellen, dass die NHRP-Steuerungspakete durchgängig übermittelt werden können.

Hinweis: Es wurde eine Bug-Erweiterung geöffnet, um Optionen zu erkunden, um die Resolution-Antwort auch ohne explizite statische Route über den direkten Tunnel senden zu lassen. Cisco Bug-ID CSCvo02022 - Erweiterung: NHRP muss Auflösungsantwort über Spoke-to-Spoke-Tunnel für Multi-Subnetz-DMVPN senden.

Hinweis: Nur registrierte Cisco Kunden können auf interne Fehlerinformationen und Tools von Cisco zugreifen.

Zugehörige Informationen

• Technischer Support und Downloads von Cisco