DMVPN hiérarchique : un cloud par relation de tunnel

Un nœud de branche s'enregistre correctement auprès de son concentrateur régional et n'atteint toujours pas un service dans une autre région. Le tunnel est actif, l'état du NHS semble sain, et la panne n'apparaît que pour les destinations qui franchissent une frontière de niveau. Ce schéma signifie généralement que la conception n'a jamais précisé quels équipements participent à quel cloud DMVPN, si bien que les niveaux ont été construits à l'intuition et ne concordent plus.

Le symptôme apparaît à la frontière des niveaux

Dans une conception hiérarchique, un concentrateur central, plusieurs concentrateurs régionaux et de nombreuses branches occupent chacun une position. Un concentrateur régional peut posséder plus d'une relation de tunnel, et les branches n'ont pas besoin de s'enregistrer auprès de chaque point central. Les chemins qui comptent vont de la branche au service régional, de la branche à un autre nœud régional approuvé, et de la branche à une destination centrale.

Lorsque l'un de ces chemins échoue alors que les autres fonctionnent, le problème est presque toujours une définition de rôle manquante ou contradictoire, et non un tunnel cassé. Écrivez les chemins prévus et comparez-les à ce que les équipements ont réellement construit. Cette comparaison prend une heure et évite une semaine de conjectures. Conservez-la avec le document de conception.

Un cloud, un contrat d'interface

Pour chaque cloud, consignez l'interface du tunnel, l'adressage de superposition, la source locale du réseau sous-jacent, les relations NHS et NBMA, la distribution multicast et la politique de protection. Indiquez aussi quelles routes traversent entre les contextes régional et central, car cette phrase est la conception.

Un concentrateur régional doté de deux interfaces de tunnel a besoin de deux contrats, et non d'un seul avec deux adresses. La source du réseau sous-jacent, le domaine NHRP et les routes peuvent différer selon l'interface, et un document qui les fusionne induira en erreur celui qui configure la seconde.

Les identifiants sont du contexte local, pas un contrôle d'accès

Les identifiants de réseau NHRP et les clés GRE sont les deux valeurs les plus souvent prises à tort pour des réglages globaux. Le guide NHRP d'IOS XE décrit l'identifiant de réseau comme localement significatif, donc des numéros identiques sur des routeurs distants n'authentifient rien et changer le numéro local d'un routeur ne crée pas de frontière d'accès.

Une clé GRE, lorsque la conception en utilise une, aide à identifier le contexte du tunnel récepteur, et elle est convenue entre les extrémités qui partagent ce contexte. Ce n'est pas un mot de passe et elle ne remplace ni l'authentification IKE ni la politique de routage. Traitez les deux valeurs comme un contexte de configuration qui doit correspondre au sein d'une relation, non comme des contrôles de sécurité qui séparent les régions.

Routez délibérément entre les niveaux

Décidez quels préfixes le concentrateur régional annonce vers le haut et quelles destinations centrales il offre à ses branches. Vérifiez ensuite le prochain saut réel et le comportement de raccourci propre à la phase pour chaque chemin, car une route de synthèse et un raccourci peuvent produire un transfert très différent de ce que suggère le schéma.

Utilisez le routage et la politique d'accès pour imposer la séparation régionale. Si une branche ne doit pas atteindre directement une autre région, la route et la politique doivent le dire, plutôt que de compter sur un identifiant qui n'a jamais été conçu pour l'imposer. Écrivez la politique à côté de l'identifiant. Sinon, l'ingénieur suivant supposera que le numéro fait le travail.

Diagnostiquez le raccourci inattendu

Lorsqu'une branche tente de créer une relation directe avec un point central, examinez sa route, son mappage NHRP et le contexte de tunnel sélectionné avant de changer des identifiants au hasard. L'absence de joignabilité, une relation NHS involontaire et un raccourci légitime mais non autorisé appellent trois corrections différentes.

Le guide de configuration DMVPN montre les réglages du tunnel et de NHRP ensemble, et c'est précisément pourquoi les périmètres doivent d'abord être séparés sur le papier. Consignez les contrats du cloud, gardez les routes de niveau explicites, et la prochaine panne de frontière aura où pointer.