Configuration et dépannage de FlexVPN Spoke to Spoke via EIGRP

Introduction

Ce document décrit le déploiement et le dépannage de Cisco FlexVPN satellite à satellite à l'aide d'IKEv2 et de NHRP pour les tunnels de cryptage client direct.

Conditions préalables

• Configuration du concentrateur Flex VPN et du client Flex VPN

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• IKEv2
• VPN reposant sur des routes
• Interfaces de tunnel virtuel (VTI)
• NHRP
• IPSEC
• EIGRP
• VRF-Lite

Composants utilisés

Les informations contenues dans ce document sont basées sur : 

• Cisco IOS XE 17.9.4a

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Évolutivité

FlexVPN peut facilement s'étendre des petits bureaux aux grands réseaux d'entreprise. Il peut gérer de nombreuses connexions VPN sans nécessiter beaucoup de travail supplémentaire, ce qui est idéal pour les entreprises en pleine croissance ou ayant de nombreux utilisateurs distants.

Fonctionnalités principales

• Configuration dynamique et tunnels à la demande :
  • Interfaces de tunnel virtuel (VTI) : FlexVPN utilise des VTI qui peuvent être créées et supprimées selon les besoins. Cela signifie que les tunnels VPN sont configurés uniquement en cas de trafic et supprimés lorsqu'ils ne sont pas nécessaires, ce qui permet d'économiser des ressources et d'améliorer l'évolutivité.
  • Protocoles de routage dynamique: Il fonctionne avec des protocoles de routage tels que OSPF, EIGRP et BGP sur des tunnels VPN. Les informations de routage sont ainsi mises à jour automatiquement, ce qui est important pour les grands réseaux dynamiques.
• Flexibilité de déploiement :
  • Modèle Hub-and-Spoke : Un concentrateur central se connecte à plusieurs filiales. FlexVPN simplifie la configuration de ces connexions avec une structure unique, ce qui en fait la solution idéale pour les grands réseaux.
  • Topologies à maillage global et à maillage partiel : Tous les sites peuvent communiquer directement sans passer par un concentrateur central, ce qui réduit les délais et améliore les performances.
• Haute disponibilité et redondance :
  • Concentrateurs redondants : Prend en charge plusieurs concentrateurs pour la sauvegarde. Si un concentrateur tombe en panne, les filiales peuvent se connecter à un autre concentrateur, assurant ainsi une connectivité continue.
  • Équilibrage de charge : Répartit les connexions VPN sur plusieurs périphériques pour éviter qu'un seul périphérique ne soit surchargé, ce qui est essentiel pour maintenir les performances dans les grands déploiements.
• Authentification et autorisation évolutives :
  • Intégration AAA : Fonctionne avec des serveurs AAA tels que Cisco ISE ou RADIUS pour une gestion centralisée des informations d'identification et des politiques des utilisateurs, essentielle pour une utilisation à grande échelle.
  • PKI et certificats : Prend en charge l'infrastructure à clé publique (PKI) et les certificats numériques pour une authentification sécurisée, plus évolutive que l'utilisation de clés prépartagées, en particulier dans les environnements de grande taille.

Informations générales

FlexVPN et NHRP

Le serveur FlexVPN fournit la fonctionnalité côté serveur de FlexVPN. Le client FlexVPN établit un tunnel VPN IPsec sécurisé entre un client FlexVPN et un autre serveur FlexVPN.

NHRP est un protocole de type ARP (Address Resolution Protocol) qui atténue les problèmes de réseau NBMA (nonbroadcast multiaccess). Avec le protocole NHRP, les entités NHRP reliées à un réseau NBMA apprennent dynamiquement l'adresse NBMA des autres entités qui font partie de ce réseau, ce qui permet à ces entités de communiquer directement sans que le trafic doive utiliser un saut intermédiaire.

La fonctionnalité Spoke to Spoke de FlexVPN intègre NHRP et le client FlexVPN (spoke) pour établir un canal de chiffrement direct avec un autre client dans un réseau FlexVPN existant. Les connexions sont établies à l'aide des interfaces de tunnel virtuel (VTI), IKEv2 et NHRP, où NHRP est utilisé pour résoudre les clients FlexVPN dans le réseau.

Cisco recommande de s'assurer que :

• Les entrées de routage ne sont pas échangées entre les rayons. Une considération clé, expliquée plus loin à mesure que nous progressons dans le dépannage de la topologie basée sur EIGRP.

• Différents profils sont utilisés pour les rayons et la commande config-exchange n'est pas configurée pour les rayons.

Processus NHRP

L'illustration montre le flux de trafic entre Spoke 1 et Spoke 2, avec les réseaux 198.51.100.0/29/24 et 198.51.100.8/29, tous deux annoncés via l'appairage EIGRP directement aux rayons via le concentrateur. Voici à quoi ressemble le flux de trafic lorsque la communication est établie entre Spoke 1 (198.51.100.0/29/24) et Spoke 2 (198.51.100.8/29).

1. L’hôte 1 envoie le trafic destiné à l’hôte 2. La recherche de route sur l’hôte 1 entraîne son transfert vers l’interface du tunnel du concentrateur, car le concentrateur annonce ce réseau via le protocole EIGRP.
2. Lorsque le trafic atteint le concentrateur, la recherche de route d'extrémité du concentrateur confirme que le réseau 198.51.100.8/29 du rayon 2 est appris via l'accès virtuel du rayon 2.
3. Le concentrateur lance la redirection NHRP, car les deux interfaces d'accès virtuel (rayon 1 et rayon 2) font partie du même réseau NHRP ayant le même ID réseau NHRP.
4. À la réception de la redirection, Spoke1 lance une requête de résolution pour le réseau en étoile 2 sur l'interface de tunnel (la même interface sur laquelle il a reçu la redirection). Spoke 2 répète le même processus pour la demande de résolution du réseau Spoke 1.
5. Spoke2 reçoit la demande de résolution sur l'interface du tunnel et récupère le numéro de modèle virtuel tel que défini dans la configuration. Le numéro de modèle virtuel est utilisé pour créer l'interface d'accès virtuelle afin d'établir une session de chiffrement entre deux rayons. Une fois que les SA de chiffrement entre les deux rayons sont actives, les deux rayons installent des routes d'adresse IP de tronçon suivant apprises via IPSEC après l'établissement des interfaces d'accès virtuel.
6. Les deux rayons procèdent ensuite à la vérification de l'accessibilité du tronçon suivant avant d'envoyer la réponse de résolution via la nouvelle interface d'accès virtuel pour la connectivité satellite à satellite.
7. Une fois que le saut suivant est accessible, les deux rayons s'envoient une réponse de résolution.
8. Les deux rayons peuvent désormais remplacer l'adresse IP de tronçon suivant de leur réseau pour l'accès virtuel via NHO.
9. Spoke1 installe les entrées de cache nécessaires pour l'adresse IP de tronçon suivant de Spoke2 et son réseau. Spoke1 supprime également l'entrée de cache temporaire pointant vers le concentrateur pour résoudre le réseau sous l'interface de tunnel 1.
10. La même étape est répétée par le rayon 2, il installe également des entrées de cache pour l'IP de tronçon suivant du rayon 1 et son réseau va de l'avant en supprimant l'ancienne entrée de concentrateur via le tunnel.
11. Le protocole NHRP ajoute des routes de raccourci en tant que route de remplacement du tronçon suivant (NHO) ou H (NHRP).

Configurer FlexVPN Spoke to Spoke à l'aide du protocole EIGRP

Schéma de topologie

Considérations clés pour la topologie basée sur EIGRP

Avant de procéder à la configuration, nous devons comprendre certains concepts clés :

• Pour tout déploiement EIGRP, si les satellites reçoivent une table de routage complète d'autres satellites ou seulement des routes récapitulatives, une liste de préfixes doit être installée côté concentrateur pour les mises à jour de routage sortantes afin de filtrer les adresses IP des satellites à annoncer les unes aux autres.

• Le découpage d'horizon dans EIGRP fonctionne différemment de dans IBGP. Le protocole EIGRP arrête uniquement d’annoncer les réseaux à partir d’une interface d’où ils ont été appris. Par exemple, le concentrateur a deux rayons, l'un connecté via l'accès virtuel 1 et l'autre via les interfaces d'accès virtuel 2. Les routes apprises par le concentrateur via VA 1 à partir du rayon 1 sont annoncées au rayon 2 via VA 2 et vice versa puisque VA 1 et VA 2 sont des interfaces différentes. Dans le cas d'IBGP, il n'annonce aucun réseau appris de son homologue à un autre homologue. Dans un exemple similaire, un concentrateur configuré avec IBGP n'annonce pas les réseaux de retour qu'il a appris de VA 1 à VA 2 et vice versa.

• Ce comportement dans EIGRP crée un conflit dans la contiguïté CEF pour l'adresse IP de tronçon suivant (une adresse IP d'interface d'accès virtuel pour un tunnel de rayon à rayon) car elle est d'abord apprise via EIGRP à l'aide d'une interface de tunnel de concentrateur, puis via IPsec à l'aide d'une interface d'accès virtuel. Cela entraîne un routage asymétrique pour le trafic NHRP et entraîne également une entrée NHRP dupliquée dans la table NHRP et des entrées NHO dupliquées dans la table de routage ainsi que pour les interfaces de tronçon suivant (tunnel via concentrateur) et (accès virtuel via rayon).

• Le modèle virtuel côté concentrateur doit avoir une adresse IP provenant d'un pool différent des interfaces de tunnel en étoile, car nous voulons filtrer les mises à jour EIGRP sortantes pour nous assurer que l'appairage EIGRP en étoile n'est pas affecté.

Voici deux exemples montrant comment configurer FlexVPN spoke to spoke à l'aide du protocole EIGRP sur le serveur FlexVPN et le client FlexVPN. Nous avons suivi les meilleures pratiques pour séparer le trafic sous-jacent et le trafic de superposition en les plaçant tous deux dans des VRF spécifiques. Le VRF A est utilisé pour le calque sous-jacent tandis que le VRF B est utilisé pour le calque.

Exemple 1 : utilisation de NHO (Next-Hop-Override) pour la communication satellite à satellite

Serveur FlexVPN

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

Client FlexVPN 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

Client FlexVPN 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

Exemple 2 : utilisation des routes installées par NHRP pour la communication satellite à satellite

Serveur FlexVPN

La seule modification apportée à la configuration EIGRP consiste à introduire des routes récapitulatives au lieu d’une table de routage complète sur les rayons. Assurez-vous d'arrêter virtual-template pour insérer la configuration récapitulative dans la topologie EIGRP. Reportez-vous à l'ID de bogue Cisco 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

Vérification et dépannage

Exemple 1 : utilisation de NHO (Next-Hop-Override) pour la communication satellite à satellite

Spoke 1 (résolution NHRP avant Spoke to Spoke et établissement du tunnel)

Spoke 2 (résolution NHRP avant Spoke to Spoke et établissement du tunnel)

Satellite 1 (après résolution NHRP satellite à satellite et établissement de tunnel)

Lancez le protocole ICMP pour déclencher le tunnel satellite à satellite :

Vérifiez le raccourci NHRP :

Vérifiez les routes NHO après la création du raccourci :

Vérifiez les compteurs NHRP :

Spoke 2 (après résolution NHRP Spoke to Spoke et établissement du tunnel)

Vérifiez le raccourci NHRP :

Vérifiez les routes NHO après la création du raccourci :

Vérifiez les compteurs NHRP :

Voici une explication étape par étape de la façon dont un tunnel de rayon à rayon direct est établi à l'aide de débogages à partir de l'un des rayons.

• ICMP initié par Spoke 1 :

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

• Le concentrateur a reçu ICMP et a initié la redirection (indication de trafic) vers les deux rayons :

*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

• Les deux rayons ont déclenché une demande de résolution qui a traversé le tunnel1 :

*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

• Les deux rayons ont reçu une demande de résolution via Tunnel1 :

*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

• Les deux rayons ont effectué une recherche de route pour leurs réseaux locaux 198.51.100.0/29/24 et 198.51.100.8/29 :

*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)

• La réponse de résolution a été mise en file d'attente et l'établissement d'IPsec a commencé puisque les deux rayons connaissent maintenant leurs adresses NBMA respectives :

*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

• Lors de l'établissement d'IPSEC et du processus de création de raccourcis NHRP, les deux satellites ont appris et installé les adresses IP de tunnel dans leur table de routage en tant que route IPSEC et ont sondé l'accessibilité du tronçon suivant :

*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

• Jusqu'à la fin de l'installation du raccourci et de la NHO, le satellite A a effectué la recherche du tronçon suivant d'adresses IP d'accès virtuel du satellite B et vice versa, mais la recherche d'espoir suivante a renvoyé « produit N/A » grâce auquel le satellite A a envoyé une indication d'erreur au satellite B confirmant que le tronçon suivant est inaccessible. La recherche particulière peut être appelée recherche par trajets multiples :

*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

• Une fois que NHO est entré pour le saut suivant et que le raccourci a été créé, les deux satellites ont envoyé à nouveau des demandes de résolution pour chacun de leurs réseaux :

*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

• Une fois que les deux rayons ont reçu des demandes de résolution pour chacun de leurs réseaux, NHO a remplacé la route EIGRP via un tunnel (HUB) par un accès virtuel :

*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

• Ensuite, les deux rayons envoient une réponse de résolution via l'interface d'accès virtuel :

*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 

Exemple 2 : utilisation des routes installées par NHRP pour la communication satellite à satellite

Serveur FlexVPN

Vérification de la topologie EIGRP pour la route récapitulative présentée :

Clients FlexVPN

Vérifiez la présence de la route récapitulative :

Essayez d'établir un tunnel de rayon à rayon en initiant le trafic :

Vérifiez à nouveau :

Il y a une modification très mineure dans le résultat des débogages pour l'installation du réseau en étoile où il montre que l'installation de la route a réussi au lieu de l'échec RIB et l'ajout de NHO :

*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

Informations connexes

• Configuration de FlexVPN Spoke to Spoke
• Exemple de configuration de configuration de satellite FlexVPN dans une conception de concentrateur redondant avec un bloc client FlexVPN