Session BGP établie, chemin du client cassé : MPLS sur DMVPN

Le peering est établi depuis des semaines, le nombre de préfixes semble correct, et pourtant le trafic d'un client emprunte toujours le long chemin ou n'arrive jamais. Deux choses différentes sont jugées par le même indicateur. Une session BGP indique que deux peers peuvent échanger des messages sur une connexion TCP ; elle ne dit rien sur la capacité de l'overlay à transporter un paquet étiqueté pour ce client précis.

Cet écart se voit le plus facilement dans une conception MPLS sur DMVPN, où le chemin par le hub et le chemin direct par le spoke peuvent se comporter différemment pour des raisons sans rapport avec le peering.

Ce que la session prouve réellement

BGP s'exécute sur TCP, donc chaque peer a besoin d'une route vers l'adresse de l'autre extrémité avant que quoi que ce soit d'autre puisse se produire. Choisissez un loopback comme extrémité et vous avez créé une exigence de joignabilité, pas une garantie de transfert. La session peut alors rester établie via une interface que le trafic du client n'utiliserait jamais.

Notez quatre faits aux deux extrémités avant de conclure : l'adresse source de la session, son adresse de destination, le contexte de routage dans lequel elle se trouve, et quelle interface le noyau ou le routeur choisirait pour cette paire. Ces faits décrivent le plan de contrôle. Les paquets du client y ajoutent un VRF, une pile d'étiquettes et un mapping d'overlay.

Quatre mécanismes, pas un

La documentation Cisco sur MPLS sur DMVPN sépare proprement les pièces. MP-BGP distribue les étiquettes d'overlay du client entre les équipements de bord du fournisseur. MPLS utilise ces étiquettes pour choisir le contexte de transfert d'un paquet. NHRP associe une adresse d'overlay à l'extrémité de transport dont un tunnel dynamique a besoin. IPsec protège le chemin entre peers là où il s'applique.

N'importe lequel des quatre peut être correct alors qu'un autre est faux, et c'est la combinaison qui transporte le trafic. Un échange de routes peut aboutir alors que la liaison d'étiquette pour un VRF manque, que le mapping NHRP pointe vers une adresse de transport obsolète, ou que le tunnel existe mais qu'aucune politique n'autorise le paquet interne. Aucune de ces conditions ne fait tomber la session.

Comparez le chemin par le hub et le raccourci, une variable à la fois

Fixez l'hôte source, l'hôte de destination et le VRF, puis suivez deux fois le même flux. Sur le chemin par le hub, notez le saut suivant, l'étiquette de service qui identifie le contexte client distant et le mapping overlay-vers-transport utilisé. Sur le chemin direct prévu, notez les mêmes trois éléments. La différence entre les deux listes est la panne, ou son absence.

Gardez le flux constant pendant la comparaison. Changer l'hôte source, le VRF ou la destination entre les observations produit deux récits sans rapport, et c'est la façon la plus courante dont cet exercice tourne mal.

Gardez les tests de loopback dans leur propre compartiment

Un ping émis depuis le loopback d'un routeur est un test utile, et il exerce un cas différent de celui d'un flux depuis un hôte. L'adresse source appartient au routeur, son contexte de routage peut être global plutôt qu'un VRF, et le chemin de retour peut différer de celui qu'emprunterait un préfixe client. Donc le loopback qui répond et l'application qui fonctionne par le raccourci sont deux résultats distincts, et seul le second décrit le client.

Testez les deux, puis étiquetez-les séparément dans vos notes. Quand ils ne concordent pas, vous avez appris quelque chose de précis sur l'endroit où la conception diverge, et c'est plus qu'une seule coche verte ne vous dira jamais.

Les affirmations sur les versions et sur les défauts exigent leurs propres preuves

Les rapports de terrain recommandent parfois de changer un masque d'hôte ou une adresse source BGP, et ces rapports ne valent la peine d'être lus qu'avec le défaut sur lequel ils ont été écrits et les versions concernées. Un contournement issu d'une version n'est pas l'affirmation que l'architecture ne prend en charge aucun préfixe /32.

Utilisez la documentation correspondant à votre phase DMVPN, votre plateforme et votre version, et rappelez-vous qu'un chapitre peut couvrir plusieurs arrangements, y compris FlexVPN. Un exemple tiré d'un arrangement ne se transpose pas silencieusement à un autre. Choisissez les extrémités de session pour la conception du plan de contrôle dont vous avez réellement besoin, puis vérifiez séparément le chemin de transfert du client, car réécrire chaque masque de loopback ne remplace pas la détermination de la tâche qui a échoué.