Implementazione della progettazione di più subnet DMVPN fase 3

Introduzione

Questo documento descrive le considerazioni relative al routing in una progettazione multi-subnet DMVPN fase 3 per garantire la corretta generazione dei tunnel spoke diretti. 

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• Conoscenze base di DMVPN (Dynamic Multipoint VPN)
• Conoscenze base del protocollo NHRP (Next-Hop Resolution Protocol)

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

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.

Premesse

Entrambe le implementazioni DMVPN fase 2 e fase 3 consentono a un dispositivo spoke di costruire un tunnel spoke diretto e non è necessario passare attraverso l'hub. Tuttavia, DMVPN fase3 fornisce una maggiore scalabilità grazie al meccanismo di reindirizzamento NHRP per il spoke che individua dinamicamente le reti remote attraverso NHRP e successivamente installa le route NHRP (H) nella tabella di routing. In questo modo viene eliminata la restrizione della fase 2, in base alla quale ogni spoke deve avere prefissi di rete specifici per le reti remote nella relativa tabella di routing. Con la fase 3, la risposta di risoluzione NHRP dal punto di uscita spoke di destinazione (punto di uscita NBMA) deve passare attraverso il tunnel spoke diretto. Tuttavia, è necessario prestare particolare attenzione alla progettazione di una fase 3 con più subnet, in modo che il tunnel spoke-to-spoke possa essere costruito correttamente. In questo articolo vengono illustrati in dettaglio tali requisiti.

Problema

DMVPN fase3 può essere implementata in una singola subnet overlay o in una multi subnet overlay. In una topologia di sovrimpressione a subnet singola, l'hub e tutti gli indirizzi del tunnel del router spoke vengono allocati da una singola subnet IP logica; mentre in una progettazione a più subnet, il tunnel spoke deve essere costruito per gli spoke con i loro indirizzi del tunnel in diverse subnet IP. Quest'ultimo è uno scenario comune utilizzato in una progettazione DMVPN gerarchica illustrata nell'immagine seguente.

DMVPN Phase3 Multi-Subnet Topology

Dettagli problema

Con DMVPN fase 3, è comunemente noto che quando si riceve la richiesta di risoluzione NHRP, il spoke di destinazione avvia il tunnel IPsec al spoke di origine e, successivamente, invia la risposta alla risoluzione su tale tunnel. Tuttavia, questo è il caso solo di una singola subnet overlay. Quando le interfacce del tunnel spoke si trovano in subnet logiche IP diverse, i pacchetti di controllo NHRP possono attraversare il percorso spoke-hub anziché il tunnel spoke diretto. Di seguito è riportata la sequenza di eventi in cui Spoke1 invia una richiesta di risoluzione a Spoke2 dopo aver ricevuto un reindirizzamento NHRP da Hub1:

1. Spoke2 riceve una richiesta di risoluzione
   
   

   *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 aggiunge una voce implicita della cache NHRP per 10.0.1.101 snooping del pacchetto di richiesta di risoluzione.
3. Spoke2 aggiunge un'adiacenza per 10.0.1.101 per Tunnel0 con l'indirizzo NBMA di Spoke1.
4. Spoke2 risponde con Resolution Reply. A questo punto, il percorso dell'indirizzo del tunnel spoke richiedente punta all'hub2:
   
   

   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
   

   Poiché il pacchetto di controllo NHRP viene inoltrato lungo il percorso indirizzato, viene inviato all'hub 2 anziché al tunnel spoke appena creato a Spoke1:
   
   

   *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

In teoria, finché tutti gli hub intermedi possono instradare il pacchetto di controllo NHRP al tunnel Spoke1, tutto deve ancora funzionare. Ma non è sempre così. Se non è possibile inoltrare la risposta di risoluzione a Spoke1, non sarà possibile creare il tunnel spoke diretto. 

Con una singola subnet overlay, questo non è un problema perché ogni spoke ha un percorso direttamente connesso alla rete del tunnel. Il risultato è una ricerca adiacente dell'indirizzo del tunnel spoke richiedente prima che venga inviata indietro la risposta alla risoluzione. In una rete di sovrimpressione multi-subnet, poiché gli indirizzi del tunnel degli spoke non si trovano sulla stessa subnet IP, non è garantito che il pacchetto Risposta risoluzione venga inviato tramite il tunnel spoke diretto.

Soluzione

Per una progettazione DMVPN fase 3 su più subnet, si consiglia di assegnare a uno spoke una voce di routing che indichi l'interfaccia del tunnel per qualsiasi subnet del tunnel spoke remoto a cui deve costruire un tunnel spoke diretto. Ad esempio:

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

In questo modo il router spoke può tentare di risolvere l'adiacenza per l'indirizzo del tunnel spoke richiedente e, successivamente, inviare la risposta alla risoluzione attraverso il tunnel spoke to spoke. 

In alternativa, la risposta alla risoluzione può attraversare i tunnel spoke-hub. In tal caso, tutti gli hub intermedi devono disporre di un percorso alla subnet del tunnel spoke richiedente per garantire che i pacchetti di controllo NHRP possano essere consegnati end-to-end.

Nota: è stato aperto un miglioramento del bug per esplorare le opzioni in modo che la risposta alla risoluzione venga inviata sul tunnel diretto anche senza un percorso statico esplicito. ID bug Cisco CSCvo02022 - Miglioramento: NHRP deve inviare una risposta di risoluzione tramite tunnel spoke per DMVPN a più subnet.

Nota: solo i client Cisco registrati possono accedere alle informazioni e agli strumenti interni del bug Cisco.

Informazioni correlate

• Supporto tecnico e download Cisco