Question de phase 3 de Cisco DMVPN

10

J'espérais que quelqu'un pourrait faire la lumière sur un problème que j'ai. J'ai un laboratoire que j'ai créé qui est un réseau Hub and Spoke multi-région. Il y a 5 centres régionaux ainsi qu'un centre central. Chaque Région a 4 rayons.

Mon problème survient lorsque j'essaie d'utiliser la phase 3 pour DMVPN. Je pense que je sais ce qui se passe, je ne sais pas trop comment y remédier. Fondamentalement, j'essaierai de faire un ping depuis un ordinateur hors du rayon vers le hub central. Le premier couple de pings passe, puis aucun autre ping ne passe. Lorsque les premiers pings sont envoyés, ils doivent traverser l'ensemble du réseau (Host-Spoke-Regional Hub-Central Hub). Au fur et à mesure que les mappages NHRP sont établis, il tente d'aller point à point pour cette connexion et il rompt le réseau car les tunnels se trouvent sur des sous-réseaux différents. Voici les informations réseau pertinentes:

Tous les routeurs exécutent EIGRP (AS 1). Tous les voisinages sont créés correctement et la table de routage est remplie comme je m'y attendais.

Le réseau Hub régional à central est le réseau Tunnel 0. 172.16.0.0/24.

Le réseau régional à rayons est le réseau du tunnel 1. 172.16.1.0/24.

Toutes les interfaces externes se trouvent sur le réseau 192.168.1.0/24.

Les interfaces internes suivent le schéma suivant: 10.region.spoke.0 / 24 (Central est 10.0.0.0/24, Regional Hubs est 10.region.0.0 / 24).

Tout aperçu que vous pouvez fournir est grandement apprécié.

cisco

— Ryan
source

Une réponse vous a-t-elle aidé? si c'est le cas, vous devez accepter la réponse afin que la question ne s'affiche pas indéfiniment, à la recherche d'une réponse. Alternativement, vous pouvez fournir et accepter votre propre réponse.

— Ron Maupin

1

Nous avons donc eu CenterHubx1-> RegionHubx5-> Spokesx4-> Computer

Pings informatiques -> Hub, recherche nhrp sur Spoke, configure un nouveau tunnel vers CenterHub.

Problème a parlé de VPN dans le sous-réseau 172.16.1 / 24 et le concentrateur 172.16.0 / 24

Le Rayon ne doit pas essayer de configurer la connexion directe au CenterHub, mais uniquement aux autres rayons de son RegionHub

Pour éviter cela, utilisez différents identifiants de réseau NHRP pour différents sous-réseaux de tunnel.

Citation:

L'ID de réseau NHRP est utilisé pour définir le domaine NHRP pour une interface NHRP

— Pieter
source

Merci pour la réponse. L'utilisation de différents identifiants de réseau permet au trafic de traverser, mais il vainc la phase 3 (le trafic inter-rayons doit passer par un concentrateur plutôt que par le biais de rayons). J'ai réussi à résoudre mon problème à l'aide de PBR, mais cette solution ne s'adapte pas bien.

— Ryan

Vous avez donc besoin de pouvoir configurer un tunnel dynamique entre n'importe lequel des appareils. Je peux penser à deux options. A. Avez-vous essayé de mettre tous les vpn dans le même sous-réseau - désordonné B. ip un-numberd et ospf pour la connectivité aux LB

— Pieter

Ouais, c'était une autre façon de le résoudre. J'ai conçu la topologie pour avoir des tunnels hiérarchiques tous sur le même sous-réseau. Pas vraiment comment la Phase 3 a été conçue pour être utilisée, mais elle permet au réseau de mieux évoluer que les autres déploiements DMVPN.

— Ryan

0

Le problème peut être dû aux touches GRE.

Tous les tunnels sur les routeurs concentrateurs DOIVENT avoir la même clé GRE (sinon un rayon ne peut pas envoyer un paquet à un concentrateur non connecté - réfléchissez-y), ce qui signifie que vous DEVEZ avoir plusieurs adresses IP sur les routeurs concentrateurs pour terminer les tunnels GRE ( car vous ne pouvez pas les différencier par les touches GRE).

— ioshints
source