Konfiguration und Fehlerbehebung bei FlexVPN-Spoke-to-Spoke über EIGRP

Einleitung

Dieses Dokument beschreibt die Bereitstellung und Fehlerbehebung bei Cisco FlexVPN-Spoke-to-Spoke-Verbindungen mit IKEv2 und NHRP für direkte Client-Krypto-Tunnel.

Voraussetzungen

• Konfiguration von Flex VPN-Hub und Flex VPN-Client

Anforderungen

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

• IKEv2
• Routenbasiertes VPN
• Virtuelle Tunnelschnittstellen (VTI)
• NHRP
• IPsec
• EIGRP
• VRF-Lite

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf: 

• Cisco IOS XE 17.9.4a

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 kennen.

Skalierbarkeit

FlexVPN kann problemlos von kleinen Büros auf große Unternehmensnetzwerke erweitert werden. Es kann viele VPN-Verbindungen verwalten, ohne dass viel zusätzlicher Aufwand erforderlich ist. Dies ist besonders für Unternehmen mit wachsenden Anforderungen oder mit vielen Remote-Benutzern geeignet.

Wichtigste Funktionen

• Dynamische Konfiguration und On-Demand-Tunnel:
  • Virtual Tunnel Interfaces (VTI): FlexVPN verwendet VTIs, die nach Bedarf erstellt und entfernt werden können. Das bedeutet, dass VPN-Tunnel nur dann eingerichtet und entfernt werden, wenn sie nicht benötigt werden. Dadurch werden Ressourcen gespart und die Skalierbarkeit verbessert.
  • Dynamic Routing-Protokolle: Er arbeitet mit Routing-Protokollen wie OSPF, EIGRP und BGP über VPN-Tunnel zusammen. Dadurch werden Routing-Informationen automatisch aktualisiert, was für große und dynamische Netzwerke wichtig ist.
• Flexible Bereitstellung:
  • Hub-and-Spoke-Modell: Ein zentraler Hub ist mit mehreren Zweigstellen verbunden. FlexVPN vereinfacht die Einrichtung dieser Verbindungen in einem einzigen Framework und eignet sich somit ideal für große Netzwerke.
  • Vollständige und teilweise vermaschte Topologien: Alle Standorte können direkt miteinander kommunizieren, ohne einen zentralen Hub zu durchlaufen. Dies reduziert Verzögerungen und verbessert die Leistung.
• Hohe Verfügbarkeit und Redundanz:
  • Redundante Hubs: Unterstützt mehrere Hubs für Backups. Wenn ein Hub ausfällt, können Zweigstellen eine Verbindung zu einem anderen Hub herstellen, um eine kontinuierliche Verbindung sicherzustellen.
  • Lastenausgleich: Verteilt VPN-Verbindungen auf mehrere Geräte, um zu verhindern, dass einzelne Geräte überlastet werden, was für die Aufrechterhaltung der Leistung in großen Bereitstellungen entscheidend ist.
• Skalierbare Authentifizierung und Authentifizierung:
  • AAA-Integration: Kann mit AAA-Servern wie Cisco ISE oder RADIUS für die zentralisierte Verwaltung von Benutzeranmeldeinformationen und -richtlinien verwendet werden, die für eine umfangreiche Nutzung unerlässlich sind.
  • PKI und Zertifikate: Unterstützt die Public Key Infrastructure (PKI) und digitale Zertifikate für eine sichere Authentifizierung, die skalierbarer ist als die Verwendung von Pre-Shared Keys, insbesondere in großen Umgebungen.

Hintergrundinformationen

FlexVPN und NHRP

Der FlexVPN-Server bietet die serverseitige Funktionalität von FlexVPN. Der FlexVPN-Client erstellt einen sicheren IPsec-VPN-Tunnel zwischen einem FlexVPN-Client und einem anderen FlexVPN-Server.

NHRP ist ein Address Resolution Protocol (ARP)-ähnliches Protokoll, das NBMA-Netzwerkprobleme (Nonbroadcast Multiaccess) behebt. Mit NHRP erfassen NHRP-Einheiten, die an ein NBMA-Netzwerk angeschlossen sind, dynamisch die NBMA-Adresse der anderen Einheiten, die Teil dieses Netzwerks sind. So können diese Einheiten direkt kommunizieren, ohne dass Datenverkehr für die Nutzung eines Zwischen-Hop benötigt wird.

Die FlexVPN Spoke-to-Spoke-Funktion integriert NHRP und FlexVPN-Client (Spoke), um einen direkten Krypto-Kanal mit einem anderen Client in einem bestehenden FlexVPN-Netzwerk einzurichten. Die Verbindungen werden mithilfe von virtuellen Tunnelschnittstellen (VTI), IKEv2 und NHRP erstellt, wobei NHRP zum Auflösen der FlexVPN-Clients im Netzwerk verwendet wird.

Cisco empfiehlt Folgendes:

• Routingeinträge werden nicht zwischen Speichen ausgetauscht. Ein wichtiger Punkt, der später im Rahmen der Fehlerbehebung bei der EIGRP-basierten Topologie erläutert wird.

• Für die Stationen werden unterschiedliche Profile verwendet, und der Befehl config-exchange ist nicht für die Stationen konfiguriert.

NHRP-Prozess

Die Abbildung veranschaulicht den Datenverkehrsfluss zwischen Spoke 1 und Spoke 2. Die Netzwerke 198.51.100.0/29/24 und 198.51.100.8/29 werden beide über EIGRP-Peering angekündigt und über den Hub direkt an die Stationen weitergeleitet. So sieht der Datenverkehrsfluss aus, wenn die Kommunikation zwischen Spoke 1 (198.51.100.0/29/24) und Spoke 2 (198.51.100.8/29) stattfindet.

1. Host 1 sendet Datenverkehr an Host 2. Die Routensuche bei Host 1 führt zu einer Weiterleitung an die Hub-Tunnelschnittstelle, da der Hub dieses Netzwerk über EIGRP meldet.
2. Wenn der Datenverkehr den Hub erreicht, bestätigt die Hub-End-Routensuche, dass das Spoke 2-Netzwerk 198.51.100.8/29 über den virtuellen Spoke 2-Zugriff erfasst wird.
3. Der Hub initiiert die NHRP-Umleitung, da beide Virtual-Access-Schnittstellen (Spoke 1 und Spoke 2) Teil desselben NHRP-Netzwerks mit derselben NHRP-Netzwerk-ID sind.
4. Beim Empfang der Umleitung initiiert Spoke1 eine Auflösungsanforderung für das Spoke 2-Netzwerk über die Tunnelschnittstelle (die Schnittstelle, über die die Umleitung empfangen wurde). Spoke 2 wiederholt den gleichen Prozess für die Lösungsanforderung des Spoke 1-Netzwerks.
5. Spoke2 empfängt die Auflösungsanforderung an der Tunnelschnittstelle und ruft die Nummer der virtuellen Vorlage gemäß der Konfiguration ab. Die Nummer der virtuellen Vorlage dient zum Erstellen der Schnittstelle für den virtuellen Zugriff, um eine Krypto-Sitzung zwischen zwei Stationen einzurichten. Sobald die Krypto-SAs zwischen den beiden Stationen aktiv sind, installieren beide Stationen Routen der Next-Hop-IP-Adresse, die nach der Einrichtung der virtuellen Zugriffsschnittstellen über die IPSEC ermittelt wurden.
6. Beide Stationen überprüfen dann die Next-Hop-Erreichbarkeit, bevor sie die Lösungsantwort über die neu erstellte Schnittstelle für Spoke-to-Spoke-Verbindungen senden.
7. Sobald der nächste Hop erreichbar ist, senden sich beide Stationen eine Lösungsantwort.
8. Beide Stationen können nun ihre jeweiligen Next-Hop-IP-Netzwerkadressen für den virtuellen Zugriff über NHO überschreiben.
9. Spoke1 installiert die erforderlichen Cache-Einträge für die Next-Hop-IP von Spoke2 und dessen Netzwerk. Spoke1 löscht auch den temporären Cache-Eintrag, der auf den Hub verweist, um das Netzwerk unter tunnel interface1 aufzulösen.
10. Der gleiche Schritt wird durch Spoke 2 wiederholt. Es werden auch Cache-Einträge für Spoke 1 Next-Hop IP installiert, und das Netzwerk bewegt sich vorwärts, indem der alte Hub-Eintrag über den Tunnel gelöscht wird.
11. NHRP fügt Verknüpfungsrouten als NHO- (Next-Hop Override) oder H- (NHRP)-Route hinzu.

Konfigurieren von FlexVPN-Spoke zu Spoke mithilfe von EIGRP

Topologiediagramm

Wichtige Überlegungen für eine EIGRP-basierte Topologie

Bevor Sie mit der Konfiguration fortfahren, müssen Sie zunächst einige Grundkonzepte verstehen:

• Wenn Stationen bei einer EIGRP-Bereitstellung eine vollständige Routing-Tabelle mit anderen Stationen oder nur zusammengefasste Routen empfangen, muss auf der Hub-Seite eine Präfixliste installiert werden, damit ausgehende Routing-Updates die Tunnel-IP-Adressen der Stationen filtern können, die untereinander angekündigt werden sollen.

• Der Split Horizon im EIGRP funktioniert anders als im IBGP. EIGRP verhindert nur, dass Werbenetzwerke eine Schnittstelle verlassen, von der sie gelernt wurden. Der Hub verfügt beispielsweise über zwei Stationen, von denen die eine über Virtual-Access-Schnittstellen 1 und die andere über Virtual-Access-Schnittstellen 2 verbunden ist. Die vom Hub über VA 1 von Spoke 1 empfangenen Routen werden über VA 2 an Spoke 2 zurückgemeldet und umgekehrt, da VA 1 und VA 2 unterschiedliche Schnittstellen sind. Im Fall von IBGP kündigt es die von seinem Peer bezogenen Netzwerke nicht an einen anderen Peer an. In einem ähnlichen Beispiel kündigt ein mit IBGP konfigurierter Hub keine Netzwerke von VA 1 zu VA 2 an und umgekehrt.

• Dieses Verhalten in EIGRP erzeugt einen Konflikt in der CEF-Adjacency für die Next-Hop-IP-Adresse (eine IP-Adresse der Virtual-Access-Schnittstelle für einen Spoke-to-Spoke-Tunnel), da diese zuerst über EIGRP mithilfe einer Hub-Tunnel-Schnittstelle und dann über IPsec mithilfe einer Virtual-Access-Schnittstelle erfasst wird. Dies führt zu asymmetrischem Routing für den NHRP-Datenverkehr und führt außerdem zu einem doppelten NHRP-Eintrag in der NHRP-Tabelle und doppelten NHO-Einträgen in der Routing-Tabelle sowie für beide Next-Hop-Schnittstellen (Tunnel über Hub) und (virtueller Zugriff über Spoke).

• Die virtuelle Hub-Vorlage muss über eine IP-Adresse aus einem anderen Pool verfügen als die Spoke-Tunnelschnittstellen, da wir ausgehende EIGRP-Updates filtern möchten, um sicherzustellen, dass das Hub-and-Spoke-EIGRP-Peering nicht beeinträchtigt wird.

Im Folgenden finden Sie zwei Beispiele, die zeigen, wie FlexVPN Spoke-to-Spoke mithilfe von EIGRP auf dem FlexVPN-Server und dem FlexVPN-Client konfiguriert wird. Wir haben Best Practices für die Trennung von Underlay- und Overlay-Datenverkehr befolgt, indem wir beide in spezifische VRFs einbetten. VRF A steht für Underlay, B für Overlay.

Beispiel 1 - NHO (Next-Hop-Override) für Spoke-to-Spoke-Kommunikation verwenden

FlexVPN-Server

ip local pool FLEXPOOL 192.0.2.129 192.0.2.254

crypto ikev2 authorization policy CISCO_FLEX
 pool FLEXPOOL
 def-domain cisco.com
 route set interface

crypto ikev2 proposal CISCO_PROP
 encryption aes-gcm-256
 prf sha256
 group 21

crypto ikev2 policy CISCO_POL 
 match fvrf A
 proposal CISCO_PROP

crypto ikev2 profile CISCO_IKEV2
 match fvrf A
 match identity remote fqdn domain cisco.com
 identity local fqdn hub.cisco.com
 authentication remote pre-share key cisco
 authentication local pre-share key cisco
 aaa authorization group psk list default CISCO_FLEX
 virtual-template 1

crypto ipsec transform-set CISCO_TRANSFORM esp-aes 256 esp-sha256-hmac 
 mode transport

crypto ipsec profile CISCO_PROF
 set transform-set CISCO_TRANSFORM 
 set pfs group19
 set ikev2-profile CISCO_IKEV2

interface Loopback0
 ip vrf forwarding B
 ip address 192.0.2.1 255.255.255.255

interface GigabitEthernet1
 ip vrf forwarding A
 ip address 203.0.113.2 255.255.255.252

interface Virtual-Template1 type tunnel
 ip vrf forwarding B
 ip unnumbered Loopback0
 ip nhrp network-id 1
 ip nhrp redirect
 tunnel vrf A
 tunnel protection ipsec profile CISCO_PROF

ip prefix-list CISCO_PREFIX seq 5 deny 192.0.2.128/25 le 32
ip prefix-list CISCO_PREFIX seq 6 permit 0.0.0.0/0 le 32

router eigrp B
!
address-family ipv4 unicast vrf B autonomous-system 1
!
af-interface default
hello-interval 2
hold-time 10
exit-af-interface
!
topology base
distribute-list prefix CISCO_PREFIX out 
exit-af-topology
network 192.0.2.128 0.0.0.127
network 192.0.2.1 0.0.0.0
exit-address-family

FlexVPN-Client 1

ip host vrf A hub.cisco.com 203.0.113.2

crypto ikev2 authorization policy CISCO_FLEX
 route set interface

crypto ikev2 proposal CISCO_PROP
 encryption aes-gcm-256
 prf sha256
 group 21

crypto ikev2 policy CISCO_POL 
 match fvrf A
 proposal CISCO_PROP

crypto ikev2 client flexvpn CISCO_CLIENT
 peer 1 fqdn hub.cisco.com dynamic
 client connect Tunnel1

crypto ikev2 profile CISCO_IKEV2
 match fvrf A
 match identity remote fqdn domain cisco.com
 identity local fqdn spoke1.cisco.com
 authentication remote pre-share key cisco
 authentication local pre-share key cisco
 aaa authorization group psk list default CISCO_FLEX
 virtual-template 1

crypto ipsec transform-set CISCO_TRANSFORM esp-aes 256 esp-sha256-hmac 
 mode transport

crypto ipsec profile CISCO_PROF
 set transform-set CISCO_TRANSFORM 
 set pfs group19
 set ikev2-profile CISCO_IKEV2

interface Tunnel1
 ip vrf forwarding B
 ip address negotiated
 ip nhrp network-id 1
 ip nhrp shortcut virtual-template 1
 tunnel source GigabitEthernet1
 tunnel destination dynamic
 tunnel vrf A
 tunnel protection ipsec profile CISCO_PROF
end

interface GigabitEthernet1
 ip vrf forwarding A
 ip address 203.0.113.6 255.255.255.252

interface Loopback1
 ip vrf forwarding B
 ip address 198.51.100.1 255.255.255.248

interface Virtual-Template1 type tunnel
 ip vrf forwarding B
 ip unnumbered Tunnel1
 ip nhrp network-id 1
 ip nhrp shortcut virtual-template 1
 tunnel vrf A
 tunnel protection ipsec profile CISCO_PROF

router eigrp B
 address-family ipv4 unicast vrf B autonomous-system 1

 af-interface default
  hello-interval 2
  hold-time 10
  passive-interface
 exit-af-interface

 af-interface Tunnel1
  no passive-interface
 exit-af-interface

  topology base
  exit-af-topology
  network 198.51.100.0 0.0.0.7
  network 192.0.2.128 0.0.0.127
 exit-address-family

FlexVPN-Client 2

ip host vrf A hub.cisco.com 203.0.113.2

crypto ikev2 authorization policy CISCO_FLEX
 route set interface

crypto ikev2 proposal CISCO_PROP
 encryption aes-gcm-256
 prf sha256
 group 21

crypto ikev2 policy CISCO_POL 
 match fvrf A
 proposal CISCO_PROP

crypto ikev2 client flexvpn CISCO_CLIENT
 peer 1 fqdn hub.cisco.com dynamic
 client connect Tunnel1

crypto ikev2 profile CISCO_IKEV2
 match fvrf A
 match identity remote fqdn domain cisco.com
 identity local fqdn spoke2.cisco.com
 authentication remote pre-share key cisco
 authentication local pre-share key cisco
 aaa authorization group psk list default CISCO_FLEX
 virtual-template 1

crypto ipsec transform-set CISCO_TRANSFORM esp-aes 256 esp-sha256-hmac 
 mode transport

crypto ipsec profile CISCO_PROF
 set transform-set CISCO_TRANSFORM 
 set pfs group19
 set ikev2-profile CISCO_IKEV2

interface Tunnel1
 ip vrf forwarding B
 ip address negotiated
 ip nhrp network-id 1
 ip nhrp shortcut virtual-template 1
 tunnel source GigabitEthernet1
 tunnel destination dynamic
 tunnel vrf A
 tunnel protection ipsec profile CISCO_PROF
end

interface GigabitEthernet1
 ip vrf forwarding A
 ip address 203.0.113.10 255.255.255.252

interface Loopback1
 ip vrf forwarding B
 ip address 198.51.100.9 255.255.255.248

interface Virtual-Template1 type tunnel
 ip vrf forwarding B
 ip unnumbered Tunnel1
 ip nhrp network-id 1
 ip nhrp shortcut virtual-template 1
 tunnel vrf A
 tunnel protection ipsec profile CISCO_PROF

router eigrp B
 address-family ipv4 unicast vrf B autonomous-system 1

 af-interface default
  hello-interval 2
  hold-time 10
  passive-interface
 exit-af-interface

 af-interface Tunnel1
  no passive-interface
 exit-af-interface

  topology base
  exit-af-topology
  network 198.51.100.8 0.0.0.7
  network 192.0.2.128 0.0.0.127
 exit-address-family

Beispiel 2 - NHRP-Installationsrouten für die Kommunikation zwischen Spoke und Spoke verwenden

FlexVPN-Server

Die einzige Änderung in der EIGRP-Konfiguration besteht in der Einführung von zusammengefassten Routen anstelle einer vollständigen Routing-Tabelle für Stationen. Bringen Sie die Virtual-Template-Datei nach unten, um die zusammenfassende Konfiguration in die EIGRP-Topologie zu verschieben. Weitere Informationen finden Sie unter Cisco Bug-ID CSCwn84303.

router eigrp B
!
address-family ipv4 unicast vrf B autonomous-system 1
!
af-interface default
hello-interval 2
hold-time 10
exit-af-interface
!
af-interface Virtual-Template1
summary-address 198.51.100.0 255.255.255.0 <<<<<<<<<<< Summary address
exit-af-interface
!
topology base
distribute-list prefix CISCO_PREFIX out 
exit-af-topology
network 192.0.2.128 0.0.0.127
network 192.0.2.1 0.0.0.0
exit-address-family

Verifizierung und Fehlerbehebung

Beispiel 1 - NHO (Next-Hop-Override) für Spoke-to-Spoke-Kommunikation verwenden

Spoke 1 (Vor Spoke-to-Spoke-NHRP-Auflösung und Tunnelaufbau)

Spoke 2 (vor Spoke-to-Spoke-NHRP-Auflösung und Tunnelaufbau)

Spoke 1 (nach Spoke-to-Spoke-NHRP-Auflösung und Tunnelaufbau)

Initiieren Sie ICMP, um einen Spoke-to-Spoke-Tunnel auszulösen:

NHRP-Verknüpfung überprüfen:

NHO-Routen nach dem Erstellen der Verknüpfung überprüfen:

NHRP-Zähler überprüfen:

Spoke 2 (nach Spoke-to-Spoke-NHRP-Auflösung und Tunnelaufbau)

NHRP-Verknüpfung überprüfen:

NHO-Routen nach dem Erstellen der Verknüpfung überprüfen:

NHRP-Zähler überprüfen:

Im Folgenden wird Schritt für Schritt erklärt, wie ein direkter Spoke-to-Spoke-Tunnel mithilfe von Fehlermeldungen aus einem der Speichen aufgebaut wird.

• Von Spoke 1 initiierter ICMP:

Spoke1#ping vrf B 198.51.100.9 source 198.51.100.1 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 198.51.100.9, timeout is 2 seconds:
Packet sent with a source address of 198.51.100.1 
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 111/111/111 ms

• Der Hub hat ICMP empfangen und eine Umleitung (Datenverkehrsanzeige) zu beiden Stationen initiiert:

*Feb 3 16:15:35.280: NHRP: Receive Traffic Indication via Tunnel1 vrf: B(0x4), packet size: 104
.
*Feb 3 16:15:35.280: (M) traffic code: redirect(0)
*Feb 3 16:15:35.280: src NBMA: 203.0.113.2
*Feb 3 16:15:35.280: src protocol: 192.0.2.1, dst protocol: 198.51.100.1
.
*Feb 3 16:15:35.281: NHRP-DETAIL: NHRP traffic indication for afn 1 received on interface Tunnel1 , for vrf: B(0x4) label: 0

• Beide Stationen lösten eine Lösungsanforderung aus, die durch Tunnel1 ging:

*Feb 3 16:15:35.295: NHRP: Sending NHRP Resolution Request for dest: 198.51.100.9 to nexthop: 198.51.100.9 using our src: 192.0.2.130 vrf: B(0x4)
*Feb 3 16:15:35.295: NHRP: Attempting to send packet through interface Tunnel1 via DEST dst 198.51.100.9
*Feb 3 16:15:35.295: NHRP-DETAIL: First hop route lookup for 198.51.100.9 yielded 192.0.2.1, Tunnel1
*Feb 3 16:15:35.295: NHRP: Send Resolution Request via Tunnel1 vrf: B(0x4), packet size: 72
*Feb 3 16:15:35.295: src: 192.0.2.130, dst: 198.51.100.9
.
*Feb 3 16:15:35.296: src NBMA: 203.0.113.6
*Feb 3 16:15:35.296: src protocol: 192.0.2.130, dst protocol: 198.51.100.9

• Beide Stationen erhielten über Tunnel1 eine Problemlösung:

*Feb 3 16:15:35.392: NHRP: Receive Resolution Request via Tunnel1 vrf: B(0x4), packet size: 92
.
*Feb 3 16:15:35.392: src NBMA: 203.0.113.10
*Feb 3 16:15:35.392: src protocol: 192.0.2.129, dst protocol: 198.51.100.1
*Feb 3 16:15:35.392: (C-1) code: no error(0), flags: none
.
*Feb 3 16:15:35.392: NHRP-DETAIL: Resolution request for afn 1 received on interface Tunnel1 , for vrf: B(0x4) label: 0

• Beide Stationen führten eine Routen-Suche für ihre lokalen Netzwerke 198.51.100.0/29/24 und 198.51.100.8/29 durch:

*Feb 3 16:15:35.392: NHRP-DETAIL: Multipath IP route lookup for 198.51.100.1 in vrf: B(0x4) yielded Loopback1, pfx:198.51.100.0/29 (netid_in:1 if_in:Tunnel1)
*Feb 3 16:15:35.392: NHRP: Route lookup for destination 198.51.100.1 in vrf: B(0x4) yielded interface Loopback1, prefixlen 29
.
*Feb 3 16:15:35.392: NHRP: We are egress router. Process the NHRP Resolution Request.
.
*Feb 3 16:15:35.393: NHRP-DETAIL: Multipath IP route lookup for 198.51.100.1 in vrf: B(0x4) yielded Loopback1, pfx:198.51.100.0/29 (netid_in:1 if_in:Tunnel1)
*Feb 3 16:15:35.393: NHRP: nhrp_rtlookup for 198.51.100.1 in vrf: B(0x4) yielded interface Loopback1, prefixlen 29, label none(0)
*Feb 3 16:15:35.393: NHRP-DETAIL: netid_out 0, netid_in 1
*Feb 3 16:15:35.393: NHRP: We are egress router for target 198.51.100.1, recevied via Tunnel1 vrf: B(0x4)

• Die Auflösungsantwort wurde in die Warteschlange gestellt, und die IPsec-Einrichtung wurde gestartet, da beide Stationen nun die NBMA-Adressen der anderen Stationen kennen:

*Feb 3 16:15:35.393: NHRP: Checking for delayed event 192.0.2.129/198.51.100.1 on list (Tunnel1 vrf: B(0x4))
*Feb 3 16:15:35.393: NHRP: No delayed event node found.
*Feb 3 16:15:35.394: NHRP-DETAIL: Updated delayed event with ep src:203.0.113.6 dst:203.0.113.10 ivrf:B
*Feb 3 16:15:35.394: NHRP: Enqueued Delaying resolution request nbma src:203.0.113.6 nbma dst:203.0.113.10 reason:IPSEC-IFC: need to wait for IPsec SAs.
*Feb 3 16:15:35.394: NHRP: Interface: Tunnel1 configured with FlexVPN. Deferring cache creation for nhop 192.0.2.129
*Feb 3 16:15:35.406: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down
*Feb 3 16:15:35.456: NHRP: Virtual-Access1: Tunnel mode changed from 
'Uninitialized tunnel mode' to 'GRE over point to point IPV4 tunnel mode'
*Feb 3 16:15:35.456: NHRP: Virtual-Access1: NHRP not enabled in delay_if_up
*Feb 3 16:15:35.511: NHRP: Registration with Tunnels Decap Module succeeded
*Feb 3 16:15:35.511: NHRP: Rejecting addr type 1
*Feb 3 16:15:35.511: NHRP: Adding all static maps to cache
*Feb 3 16:15:35.511: NHRP-DETAIL: Adding summary-prefix entry: nhrp router block not configured
*Feb 3 16:15:35.512: NHRP: 
*Feb 3 16:15:35.512: Instructing NHRP to create Virtual-Access from Virtual template 1 for interface Virtual-Access1
*Feb 3 16:15:35.537: %SYS-5-CONFIG_P: Configured programmatically by process Crypto INT from console as console
*Feb 3 16:15:35.539: NHRP-CACHE: Virtual-Access1: Cache add for target 192.0.2.130/32 vrf: B(0x4) label none next-hop 192.0.2.130
*Feb 3 16:15:35.540: 203.0.113.6 (flags:0x20)
.
*Feb 3 16:15:35.548: NHRP: Updating delayed event with destination 203.0.113.10 on interfaceTunnel1 with the new interface Virtual-Access1 
*Feb 3 16:15:35.788: NHRP: 
*Feb 3 16:15:35.788: Fetched address from underlying IKEv2 for interfaceVirtual-Access1. Pre-NATed = 203.0.113.6, Post-NATed = UNKNOWN
*Feb 3 16:15:35.788: %DMVPN-5-CRYPTO_SS: Virtual-Access1: local address : 203.0.113.6 remote address : 203.0.113.10 socket is UP

• Während der IPSEC-Einrichtung und der Erstellung von NHRP-Verknüpfungen erfuhren beide Stationen, dass die anderen Stationen Tunnel-IP-Adressen in ihrer Routing-Tabelle als IPSEC-Route installiert hatten, und testeten die Verfügbarkeit des nächsten Hop:

*Feb 3 16:15:35.788: NHRP: Processing delayed event on interface Tunnel1 with NBMA 203.0.113.10
.
*Feb 3 16:15:35.789: NHRP-CACHE: Virtual-Access1: Cache add for target 192.0.2.129/32 vrf: B(0x4) label none next-hop 192.0.2.129
*Feb 3 16:15:35.789: 203.0.113.10 (flags:0x2080)
*Feb 3 16:15:35.789: NHRP-RT: Adding route entry for 192.0.2.129/32 via 192.0.2.129, Virtual-Access1 vrf: B(0x4)) to RIB
*Feb 3 16:15:35.791: NHRP-RT: Route addition to RIB Successful 
*Feb 3 16:15:35.791: NHRP-EVE: NHP-UP: 192.0.2.129, NBMA: 203.0.113.10
*Feb 3 16:15:35.791: %DMVPN-5-NHRP_NHP_UP: Virtual-Access1: Next Hop NHP : (Tunnel: 192.0.2.129 NBMA: 203.0.113.10) for (Tunnel: 192.0.2.130 NBMA: 203.0.113.6) is UP
*Feb 3 16:15:35.791: NHRP-CACHE: 
*Feb 3 16:15:35.791: Next-hop not reachable for 192.0.2.129
*Feb 3 16:15:35.791: %NHRP-5-NHOP_UNREACHABLE: Nexthop address 192.0.2.129 for 192.0.2.129/32 is not routable

• Bis zum Abschluss der Shortcut-Installation und NHO führte Spoke A die Next-Hop-Suche nach IP-Adressen mit virtuellem Zugriff von Spoke B durch und umgekehrt. Bei der Next-Hop-Suche wurde jedoch "N/A" zurückgegeben, da Spoke A eine Fehlermeldung an Spoke B schickte, die bestätigte, dass der nächste Hop nicht erreichbar ist. Die spezielle Suche kann auch als Multi-Path-Suche bezeichnet werden:

*Feb 3 16:15:35.791: NHRP-DETAIL: Multipath recursive nexthop lookup(if_in:, netid:1) for 192.0.2.129 in vrf: B(0x4) yielded N/A, Virtual-Access1
*Feb 3 16:15:35.791: NHRP: Sending error indication. Reason: 'Cache pak failure' LINE: 13798
*Feb 3 16:15:35.791: NHRP: Attempting to send packet through interface Virtual-Access1 via DEST dst 192.0.2.129
*Feb 3 16:15:35.791: NHRP-DETAIL: Multipath recursive nexthop lookup(if_in:, netid:1) for 192.0.2.129 in vrf: B(0x4) yielded 192.0.2.129, Virtual-Access1
*Feb 3 16:15:35.791: NHRP: Send Error Indication via Virtual-Access1 vrf: B(0x4), packet size: 132
*Feb 3 16:15:35.791: src: 192.0.2.130, dst: 192.0.2.129
.
*Feb 3 16:15:35.791: (M) error code: protocol address unreachable(6), offset: 0 
*Feb 3 16:15:35.791: src NBMA: 203.0.113.6
*Feb 3 16:15:35.791: src protocol: 192.0.2.130, dst protocol: 192.0.2.129

• Sobald NHO den nächsten Hop startete und die Verknüpfung erstellt wurde, schickten beide Stationen erneut Lösungsanforderungen für jedes ihrer Netzwerke:

*Feb 3 16:15:35.813: NHRP: No need to delay processing of resolution event nbma src:203.0.113.6 nbma dst:203.0.113.10
*Feb 3 16:15:35.813: NHRP-CACHE: Virtual-Access1: Cache update for target 192.0.2.129/32 vrf: B(0x4) label none next-hop 192.0.2.129
*Feb 3 16:15:35.813: 203.0.113.10 (flags:0x2280)
*Feb 3 16:15:35.813: NHRP-RT: Adding route entry for 192.0.2.129/32 via 192.0.2.129, Virtual-Access1 vrf: B(0x4)) to RIB
*Feb 3 16:15:35.814: NHRP-RT: Route addition to RIB Successful 
.
*Feb 3 16:15:35.841: NHRP-RT: Route entry 192.0.2.129/32 via 192.0.2.129 (Vi1) clobbered by distance
*Feb 3 16:15:35.847: NHRP-RT: Unable to stop route watch for 192.0.2.129/32 interface Virtual-Access1 . No handle
*Feb 3 16:15:35.847: NHRP-RT: Adding route entry for 192.0.2.129/32 via 192.0.2.129, Virtual-Access1 vrf: B(0x4)) to RIB
*Feb 3 16:15:35.847: NHRP-RT: Route addition failed (admin-distance) 
*Feb 3 16:15:35.847: NHRP-RT: nexthop-override added to RIB 
.
*Feb 3 16:15:37.167: NHRP: Sending NHRP Resolution Request for dest: 198.51.100.9 to nexthop: 198.51.100.9 using our src: 192.0.2.130 vrf: B(0x4)
*Feb 3 16:15:37.167: NHRP: Attempting to send packet through interface Tunnel1 via DEST dst 198.51.100.9
*Feb 3 16:15:37.167: NHRP-DETAIL: First hop route lookup for 198.51.100.9 yielded 192.0.2.1, Tunnel1
*Feb 3 16:15:37.167: NHRP: Send Resolution Request via Tunnel1 vrf: B(0x4), packet size: 72
*Feb 3 16:15:37.167: src: 192.0.2.130, dst: 198.51.100.9
.
*Feb 3 16:15:37.167: src NBMA: 203.0.113.6
*Feb 3 16:15:37.167: src protocol: 192.0.2.130, dst protocol: 198.51.100.9

• Nachdem beide Stationen Auflösungsanforderungen für jedes ihrer Netzwerke erhalten hatten, ersetzte NHO die EIGRP-Route über Tunnel (HUB) durch virtuellen Zugriff:

*Feb 3 16:30:57.768: NHRP-CACHE: Virtual-Access1: Cache add for target 198.51.100.8/29 vrf: B(0x4) label none next-hop 192.0.2.129
*Feb 3 16:30:57.768: 203.0.113.10 (flags:0x1000)
*Feb 3 16:30:57.768: NHRP-RT: Adding route entry for 198.51.100.8/29 via 192.0.2.129, Virtual-Access1 vrf: B(0x4)) to RIB
*Feb 3 16:30:57.769: NHRP-RT: Route addition failed (admin-distance) 
*Feb 3 16:30:57.769: NHRP-RT: nexthop-override added to RIB 
*Feb 3 16:30:57.769: NHRP-EVE: NHP-UP: 192.0.2.129, NBMA: 203.0.113.10
*Feb 3 16:30:57.769: %DMVPN-5-NHRP_NHP_UP: Virtual-Access1: Next Hop NHP : (Tunnel: 192.0.2.129 NBMA: 203.0.113.10) for (Tunnel: 192.0.2.130 NBMA: 203.0.113.6) is UP
*Feb 3 16:30:57.769: NHRP-CACHE: Deleting incomplete entry for 198.51.100.9/32 interface Tunnel1 vrf: B(0x4)
*Feb 3 16:30:57.769: NHRP-EVE: NHP-DOWN: 198.51.100.9, NBMA: 198.51.100.9

• Danach senden beide Stationen eine Lösungsantwort über die Virtual-Access-Schnittstelle:

*Feb 3 16:30:57.436: NHRP-CACHE: Virtual-Access1: Internal Cache add for target 198.51.100.0/29 vrf: B(0x4) label none next-hop 192.0.2.130
*Feb 3 16:30:57.436: 203.0.113.6 (flags:0x20)
*Feb 3 16:30:57.436: NHRP: Attempting to send packet through interface Virtual-Access1 via DEST dst 192.0.2.129
*Feb 3 16:30:57.436: NHRP-DETAIL: Multipath recursive nexthop lookup(if_in:, netid:1) for 192.0.2.129 in vrf: B(0x4) yielded 192.0.2.129, Virtual-Access1
*Feb 3 16:30:57.436: NHRP: Send Resolution Reply via Virtual-Access1 vrf: B(0x4), packet size: 120
*Feb 3 16:30:57.436: src: 192.0.2.130, dst: 192.0.2.129
.
*Feb 3 16:30:57.437: src NBMA: 203.0.113.10
*Feb 3 16:30:57.437: src protocol: 192.0.2.129, dst protocol: 198.51.100.1
.
*Feb 3 16:30:57.437: client NBMA: 203.0.113.6
*Feb 3 16:30:57.437: client protocol: 192.0.2.130
*Feb 3 16:30:57.437: NHRP: 144 bytes out Virtual-Access1 

Beispiel 2 - NHRP-Installationsrouten für die Kommunikation zwischen Spoke und Spoke verwenden

FlexVPN-Server

Überprüfung der EIGRP-Topologie für die eingeführte Route Summary:

FlexVPN-Clients

Überprüfen Sie, ob eine Route für die Zusammenfassung vorhanden ist:

Versuchen Sie, einen Spoke-to-Spoke-Tunnel einzurichten, indem Sie Datenverkehr initiieren:

Überprüfen Sie erneut:

Es gibt eine sehr geringfügige Änderung in der Debug-Ausgabe für die Stationen-Netzwerkinstallation, bei der angezeigt wird, dass die Routing-Installation erfolgreich war, anstatt dass ein RIB-Fehler aufgetreten ist, und bei der NHO hinzugefügt wurde:

*Feb 3 16:43:38.957: NHRP-CACHE: Virtual-Access1: Cache add for target 198.51.100.8/29 vrf: B(0x4) label none next-hop 192.0.2.131
*Feb 3 16:43:38.957: 203.0.113.10 (flags:0x1000)
*Feb 3 16:43:38.957: NHRP-RT: Adding route entry for 198.51.100.8/29 via 192.0.2.131, Virtual-Access1 vrf: B(0x4)) to RIB
*Feb 3 16:43:38.957: NHRP-RT: Route addition to RIB Successful 
*Feb 3 16:43:38.957: NHRP-EVE: NHP-UP: 192.0.2.131, NBMA: 203.0.113.10

Zugehörige Informationen

• Konfigurieren von FlexVPN Spoke zu Spoke
• FlexVPN-Spoke im redundanten Hub-Design mit FlexVPN-Client-Baustein - Konfigurationsbeispiel