Configurazione e risoluzione dei problemi di FlexVPN Spoke to Spoke tramite EIGRP

Introduzione

In questo documento viene descritta la distribuzione e la risoluzione dei problemi di Cisco FlexVPN spoke-to-spoke con IKEv2 e NHRP per tunnel con crittografia client diretta.

Prerequisiti

• Configurazione hub VPN Flex e client VPN Flex

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• IKEv2
• VPN basata sul percorso
• VTI (Virtual Tunnel Interfaces)
• NHRP
• IPSec
• EIGRP
• VRF-Lite

Componenti usati

Le informazioni fornite in questo documento si basano su: 

• Cisco IOS XE 17.9.4a

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Scalabilità

FlexVPN può essere facilmente espansa dalle reti dei piccoli uffici a quelle delle grandi aziende. È in grado di gestire molte connessioni VPN senza richiedere un lavoro aggiuntivo, il che è ottimo per le organizzazioni in crescita o con molti utenti remoti.

Caratteristiche principali

• Configurazione dinamica e tunnel on-demand:
  • VTI (Virtual Tunnel Interfaces): FlexVPN utilizza VTI che possono essere create e rimosse in base alle esigenze. Ciò significa che i tunnel VPN vengono configurati solo quando c'è traffico e rimossi quando non sono necessari, risparmiando risorse e migliorando la scalabilità.
  • Protocolli di routing dinamico: Funziona con protocolli di routing come OSPF, EIGRP e BGP su tunnel VPN. In questo modo le informazioni di routing vengono aggiornate automaticamente, un aspetto importante per le reti grandi e dinamiche.
• Flessibilità nell'implementazione:
  • Modello hub e spoke: Un hub centrale si connette a più filiali. FlexVPN semplifica la configurazione di queste connessioni con un unico framework, rendendolo ideale per reti di grandi dimensioni.
  • Topologie Mesh completa e Mesh parziale: Tutti i siti possono comunicare direttamente senza passare attraverso un hub centrale, riducendo i ritardi e migliorando le prestazioni.
• Alta disponibilità e ridondanza:
  • Hub ridondanti: Supporto di più hub per il backup. In caso di guasto di un hub, le filiali possono connettersi a un altro hub, garantendo una connettività continua.
  • Bilanciamento del carico: Distribuisce le connessioni VPN su più dispositivi per evitare che un singolo dispositivo diventi sovraccarico, il che è fondamentale per mantenere le prestazioni in installazioni di grandi dimensioni.
• Autenticazione e autorizzazione scalabili:
  • Integrazione AAA: Funziona con server AAA come Cisco ISE o RADIUS per la gestione centralizzata di credenziali e policy utente, essenziali per l'utilizzo su larga scala.
  • PKI e certificati: Supporta PKI (Public Key Infrastructure) e certificati digitali per un'autenticazione sicura, più scalabile rispetto all'utilizzo di chiavi già condivise, soprattutto in ambienti di grandi dimensioni.

Premesse

FlexVPN e NHRP

Il server FlexVPN fornisce la funzionalità sul lato server di FlexVPN. Il client FlexVPN stabilisce un tunnel VPN IPsec sicuro tra un client FlexVPN e un altro server FlexVPN.

NHRP è un protocollo simile al protocollo ARP (Address Resolution Protocol) che riduce i problemi di rete non broadcast multiaccess (NBMA). Con NHRP, le entità NHRP collegate a una rete NBMA apprendono dinamicamente l'indirizzo NBMA delle altre entità che fanno parte di tale rete, consentendo a tali entità di comunicare direttamente senza richiedere al traffico di utilizzare un hop intermedio.

La funzione Spoke-to-Spoke di FlexVPN integra NHRP e il client FlexVPN (spoke) per stabilire un canale di crittografia diretto con un altro client in una rete FlexVPN esistente. Le connessioni vengono create utilizzando interfacce tunnel virtuali (VTI), IKEv2 e NHRP, dove NHRP viene utilizzato per risolvere i client FlexVPN nella rete.

Cisco consiglia di verificare che:

• Le voci di routing non vengono scambiate tra i raggi. Una considerazione chiave, illustrata più avanti, è il progresso nella risoluzione dei problemi relativi alla topologia basata su EIGRP.

• Per gli spoke vengono utilizzati profili diversi e il comando config-exchange non è configurato per gli spoke.

Processo NHRP

L'illustrazione mostra il flusso del traffico tra lo Spoke 1 e lo Spoke 2, con le reti 198.51.100.0/29/24 e 198.51.100.8/29, entrambe pubblicizzate tramite l'EIGRP che effettuano il peering diretto agli Spoke attraverso l'hub. Di seguito viene riportato l'aspetto del flusso del traffico quando viene stabilita la comunicazione tra la spoke 1 (198.51.100.0/29/24) e la spoke 2 (198.51.100.8/29).

1. L'host 1 invia il traffico destinato all'host 2. La ricerca della route sull'host 1 comporta l'inoltro all'interfaccia del tunnel hub perché l'hub annuncia la rete tramite EIGRP.
2. Quando il traffico raggiunge l'hub, la ricerca dell'estremità hub del percorso conferma che la rete spoke 2 198.51.100.8/29 viene appresa tramite l'accesso virtuale spoke 2.
3. L'hub avvia il reindirizzamento NHRP poiché entrambe le interfacce di accesso virtuale (spoke 1 e spoke 2) fanno parte della stessa rete NHRP con lo stesso ID di rete NHRP.
4. Alla ricezione del reindirizzamento, Spoke1 avvia una richiesta di risoluzione per la rete spoke 2 tramite l'interfaccia tunnel (la stessa interfaccia su cui ha ricevuto il reindirizzamento). Spoke 2 ripete la stessa procedura per la richiesta di risoluzione della rete spoke 1.
5. Spoke2 riceve la richiesta di risoluzione sull'interfaccia del tunnel e recupera il numero di modello virtuale definito nella configurazione. Il numero di modello virtuale viene utilizzato per creare l'interfaccia di accesso virtuale per stabilire una sessione crittografica tra due spoke. Una volta attivate le SA crittografiche tra i due spoke, entrambi gli spoke installano percorsi di indirizzi IP dell'hop successivo appresi tramite IPSEC post-definizione di interfacce di accesso virtuale.
6. Entrambi gli spoke quindi procedono a verificare la raggiungibilità dell'hop successivo prima di inviare la risposta di risoluzione attraverso l'interfaccia di accesso virtuale appena creata per la connettività spoke-to-spoke.
7. Quando l'hop successivo è raggiungibile, entrambi gli spoke si inviano una risposta di risoluzione a vicenda.
8. Entrambi gli spoke possono ora sostituire ciascun indirizzo IP dell'hop successivo di rete per l'accesso virtuale tramite NHO.
9. Spoke1 installa le voci della cache necessarie per l'IP dell'hop successivo di Spoke2 e la relativa rete. Spoke1 elimina anche la voce temporanea della cache che punta all'hub per risolvere la rete in tunnel interface1.
10. Lo stesso passaggio viene ripetuto da spoke 2, vengono installate le voci della cache per l'IP dell'hop successivo spoke 1 e la sua rete procede nell'eliminazione della voce dell'hub precedente tramite il tunnel.
11. NHRP aggiunge route di collegamento come route NHO (Next-Hop Override) o NHRP (Next-Hop Override).

Configurazione di FlexVPN Spoke to Spoke tramite EIGRP

Diagramma di topologia

Considerazioni principali per la topologia basata su EIGRP

Prima di procedere alla configurazione, è necessario comprendere alcuni concetti chiave:

• Per qualsiasi distribuzione EIGRP, se gli spoke ricevono una tabella di routing completa di altri spoke o solo route di riepilogo, è necessario installare un elenco di prefissi sul lato hub per gli aggiornamenti del routing in uscita al fine di filtrare gli indirizzi IP tunnel degli spoke da annunciare l'uno all'altro.

• L'orizzonte di divisione in EIGRP funziona in modo diverso rispetto a IBGP. L'EIGRP impedisce solo alle reti pubblicitarie di uscire da un'interfaccia da cui sono state apprese. Ad esempio, l'hub dispone di due spoke, uno connesso tramite l'accesso virtuale 1 e l'altro tramite le interfacce di accesso virtuale 2. Le route apprese dall'hub tramite VA 1 dal spoke 1 vengono pubblicizzate nuovamente in spoke 2 tramite VA 2 e viceversa poiché VA 1 e VA 2 sono interfacce diverse. Nel caso di IBGP, non pubblicizza le reti apprese dal peer di ritorno a un altro peer. In un esempio simile, un hub configurato con IBGP non annuncia le reti posteriori apprese da VA 1 a VA 2 e viceversa.

• Questo comportamento in EIGRP crea un conflitto nell'adiacenza CEF per l'indirizzo IP dell'hop successivo (un indirizzo IP dell'interfaccia di accesso virtuale per un tunnel spoke-to-spoke) poiché viene appreso prima tramite EIGRP utilizzando un'interfaccia del tunnel hub e poi tramite IPsec utilizzando un'interfaccia di accesso virtuale. Ciò causa un routing asimmetrico per il traffico NHRP e produce anche una voce NHRP duplicata nella tabella NHRP e voci NHO duplicate nella tabella di routing, nonché per entrambe le interfacce hop successivo (tunnel tramite hub) e (accesso virtuale tramite spoke).

• Il modello virtuale del lato hub deve avere un indirizzo IP da un pool diverso rispetto alle interfacce del tunnel Spokes, in quanto si desidera filtrare gli aggiornamenti EIGRP in uscita per assicurarsi che il peer EIGRP Hub and Spokes non sia influenzato.

Di seguito sono riportati due esempi che mostrano come configurare FlexVPN spoke con EIGRP sul server FlexVPN e sul client FlexVPN. Abbiamo seguito le best practice per segregare il traffico di sovrimpressione e sovrapposizione inserendole in VRF specifici. VRF A è per l'underlay, mentre B è utilizzato per l'overlay.

Esempio 1 - Utilizzare NHO (Next-Hop-Override) Per La Comunicazione Spoke-To-Spoke

Server 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

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

Esempio 2 - Utilizzo Di Route Installate NHRP Per La Comunicazione Spoke-To-Spoke

Server FlexVPN

L'unica modifica nella configurazione EIGRP consiste nell'introduzione di route di riepilogo anziché di una tabella di routing completa per gli spoke. Assicurarsi di ridurre il modello virtuale per inserire la configurazione di riepilogo nella topologia EIGRP. Fare riferimento all'ID bug 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

Verifica e risoluzione dei problemi

Esempio 1 - Utilizzare NHO (Next-Hop-Override) Per La Comunicazione Spoke-To-Spoke

Spoke 1 (prima della risoluzione NHRP Spoke-to-Spoke e della definizione del tunnel)

Spoke 2 (prima della risoluzione NHRP Spoke-to-Spoke e della definizione del tunnel)

Spoke 1 (dopo la risoluzione NHRP Spoke-to-Spoke e la definizione del tunnel)

Avviare l'ICMP per attivare il tunnel spoke-to-spoke:

Verifica collegamento NHRP:

Verifica creazione collegamento post route NHO:

Verificare i contatori NHRP:

Spoke 2 (dopo la risoluzione NHRP Spoke-to-Spoke e la definizione del tunnel)

Verifica collegamento NHRP:

Verifica creazione collegamento post route NHO:

Verificare i contatori NHRP:

Di seguito viene riportata una spiegazione dettagliata di come impostare un tunnel spoke diretto con l'aiuto di debug da uno dei spoke.

• ICMP avviato dal raggio 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

• L'hub ha ricevuto un messaggio ICMP e ha avviato il reindirizzamento (indicazione del traffico) a entrambi i spoke:

*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

• Entrambi gli spoke hanno attivato una richiesta di risoluzione passata attraverso il 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

• Entrambi gli spoke hanno ricevuto una richiesta di risoluzione tramite 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

• Entrambi gli spoke hanno eseguito una ricerca del percorso per le loro reti locali 198.51.100.0/29/24 e 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 risposta di risoluzione è stata accodata e la creazione di IPSec è stata avviata poiché entrambi gli spoke sono ora a conoscenza l'uno dell'altro indirizzi NBMA:

*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

• Durante la definizione di IPSEC e il processo di creazione dei collegamenti NHRP, entrambi gli spoke hanno appreso e installato gli uni gli altri indirizzi IP del tunnel nella relativa tabella di routing come route IPSEC e hanno sondato la raggiungibilità dell'hop successivo:

*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

• Fino al completamento dell'installazione dei collegamenti e NHO, Spoke A ha eseguito la ricerca hop successiva degli indirizzi IP di accesso virtuale di Spoke B e viceversa, ma la ricerca hope successiva ha restituito "N/A restituito" a causa del quale Spoke A ha inviato un'indicazione di errore a Spoke B confermando che l'hop successivo non è raggiungibile. La ricerca specifica può essere definita ricerca a percorsi multipli:

*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

• Una volta che la NHO è entrata per l'hop successivo ed è stata creata la scorciatoia, entrambi gli oratori hanno inviato di nuovo richieste di risoluzione per ciascuna delle loro reti:

*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

• Dopo che entrambi gli spoke hanno ricevuto richieste di risoluzione per ciascuna delle loro reti, NHO ha sostituito la route EIGRP tramite tunnel (HUB) con accesso virtuale:

*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

• In seguito, entrambi gli spoke inviano una risposta di risoluzione attraverso l'interfaccia di accesso virtuale:

*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 

Esempio 2 - Utilizzo Di Route Installate NHRP Per La Comunicazione Spoke-To-Spoke

Server FlexVPN

È stata introdotta la verifica della topologia EIGRP per la route di riepilogo:

Client FlexVPN

Verificare la presenza della route di riepilogo:

Provare a stabilire un tunnel spoke-to-spoke iniziando il traffico:

Verifica di nuovo:

È presente una modifica molto minore nell'output dei debug per l'installazione della rete Spokes, dove viene indicato che l'installazione della route è riuscita invece che che il guasto RIB e l'aggiunta di 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

Informazioni correlate

• Configurazione di FlexVPN Spoke to Spoke
• Esempio di configurazione del blocco client FlexVPN Spoke in un hub ridondante con FlexVPN