Mise en oeuvre de la conception DMVPN phase3 multisous-réseau

Options de téléchargement

PDF (315.1 KB)
Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
ePub (127.7 KB)
Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
Mobi (Kindle) (96.3 KB)
Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils

Mis à jour:13 février 2023

ID du document:220217

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

Table des matières

Introduction

Conditions préalables

Exigences

Composants utilisés

Informations générales

Problème

Détails du problème

Solution

Informations connexes

Introduction

Ce document décrit les considérations de routage dans une conception DMVPN phase3 multi-sous-réseau afin de garantir que les tunnels rayon à rayon directs sont correctement construits.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

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.

Informations générales

Les mises en oeuvre DMVPN phase2 et phase3 permettent à un périphérique satellite de construire un tunnel satellite à satellite direct sans avoir à passer par le concentrateur. Cependant, DMVPN phase3 offre une bien meilleure évolutivité en utilisant le mécanisme de redirection NHRP pour que le rayon découvre dynamiquement les réseaux distants via NHRP, et installe ensuite les routes NHRP (H) dans la table de routage. Cela supprime la restriction de phase2 qui exige que chaque rayon ait des préfixes réseau spécifiques pour les réseaux distants dans sa table de routage. Avec la phase3, la réponse de résolution NHRP du rayon cible (point de sortie NBMA) doit passer par le tunnel direct de rayon à rayon. Cependant, une attention particulière doit être accordée à une conception de phase3 multisous-réseau afin que le tunnel de rayon à rayon puisse être construit correctement. Cet article traite en détail de ces exigences.

Problème

DMVPN phase3 peut être implémenté en superposition de sous-réseau unique ou en superposition de sous-réseau multiple. Dans une topologie de superposition à un seul sous-réseau, les adresses de tunnel du concentrateur et de tous les routeurs en étoile sont attribuées à partir d'un sous-réseau IP logique unique ; alors que dans une conception à plusieurs sous-réseaux, le tunnel en étoile doit être construit pour les rayons avec leurs adresses de tunnel dans différents sous-réseaux IP. Ce dernier scénario est couramment utilisé dans une conception DMVPN hiérarchique illustrée dans l'image ci-dessous.

DMVPN Phase3 Multi-subnet Topology

Topologie DMVPN phase3 à sous-réseaux multiples

Détails du problème

Avec DMVPN phase3, il est généralement admis que lorsque la requête de résolution NHRP est reçue, le rayon cible initie le tunnel IPsec vers le rayon source, puis envoie la réponse de résolution sur ce tunnel. Cependant, cela n'est le cas qu'avec une superposition de sous-réseau unique. Lorsque les interfaces de tunnel des rayons se trouvent dans des sous-réseaux logiques IP différents, les paquets de contrôle NHRP peuvent traverser le chemin rayon-concentrateur-rayon au lieu du tunnel direct rayon à rayon. Voici la séquence des événements lorsque Spoke1 envoie une demande de résolution à Spoke2 après avoir reçu une redirection NHRP de Hub1 :

Spoke2 reçoit une demande de résolution

*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

Spoke2 ajoute une entrée de cache NHRP implicite pour 10.0.1.101 en surveillant le paquet de demande de résolution.
Spoke2 ajoute une contiguïté pour 10.0.1.101 pour Tunnel0 avec l'adresse NBMA de Spoke1.

Spoke2 répond avec Resolution Reply. Notez à ce stade que la route de l'adresse de tunnel en étoile demandeuse pointe vers le concentrateur 2 :

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

Puisque le paquet de contrôle NHRP est transféré le long du chemin routé, il est envoyé au concentrateur 2 au lieu du tunnel de rayon à rayon nouvellement créé vers 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

En théorie, tant que tous les concentrateurs intermédiaires peuvent router le paquet de contrôle NHRP vers le tunnel de Spoke1, alors tout doit encore fonctionner. Mais ce n'est pas toujours nécessairement le cas. Si la réponse de résolution ne peut pas être retransmise à Spoke1, alors le tunnel de rayon à rayon direct ne peut pas être construit.

Avec une superposition de sous-réseau unique, ce n'est pas un problème car chaque rayon a une route connectée directement au réseau du tunnel. Il en résulte une recherche de contiguïté pour l'adresse de tunnel en étoile demandeuse avant que la réponse de résolution ne soit renvoyée. Dans un réseau de superposition à plusieurs sous-réseaux, comme les adresses de tunnel des rayons ne se trouvent pas sur le même sous-réseau IP, l'envoi du paquet de réponse de résolution n'est pas garanti sur le tunnel rayon à rayon direct.

Solution

Pour une conception DMVPN phase3 à plusieurs sous-réseaux, il est recommandé qu'un rayon ait une entrée de routage qui pointe vers l'interface de tunnel pour tout sous-réseau de tunnel en rayon distant vers lequel il a besoin de construire un tunnel de rayon à rayon direct. Exemple :

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

Cela permet au rayon d'essayer de résoudre la contiguïté pour l'adresse du tunnel en rayon demandeur, puis d'envoyer la réponse de résolution sur le tunnel de rayon à rayon.

La réponse de résolution peut également traverser les tunnels rayon-concentrateur-rayon. Dans ce cas, tous les concentrateurs intermédiaires doivent avoir une route vers le sous-réseau du tunnel en étoile demandeur pour garantir que les paquets de contrôle NHRP peuvent être livrés de bout en bout.

Remarque : une amélioration du bogue a été ouverte pour explorer les options pour que la réponse de résolution soit envoyée sur le tunnel direct même sans route statique explicite. ID de bogue Cisco CSCvo02022 - Amélioration : NHRP doit envoyer une réponse de résolution sur le tunnel satellite à satellite pour DMVPN multisous-réseau.

Remarque : seuls les clients Cisco enregistrés peuvent accéder aux informations de bogue et aux outils internes de Cisco.