Type de route OSPF à travers un VPN : pas toujours externe

Un préfixe client traverse le cloud du fournisseur comme une route BGP VPN et arrive sur le site distant avec l’apparence d’une route OSPF externe, ce que beaucoup d’ingénieurs attendent et qui n’est pas le seul résultat possible. Ce que voit le CE distant dépend du domaine OSPF d’où provient le préfixe et de son type de route d’origine, et les deux voyagent avec la route VPN. Supposer que chaque préfixe redistribué devient de type 5 conduit à des changements de préférence qui ne peuvent pas fonctionner. Comparez d’abord l’identifiant de domaine, pas la distance administrative.

Le modèle PE-CE porte assez de contexte pour que le PE récepteur reconstruise une annonce OSPF au lieu de l’inventer.

Ce qui voyage avec la route

La RFC 4577 définit les attributs OSPF qui accompagnent une route VPN : l’identifiant de domaine, la métrique et le type de route du site d’origine. Le PE récepteur les utilise pour décider comment un préfixe éligible doit apparaître à son processus OSPF local. Sans ces attributs, le PE distant n’aurait aucune base pour autre chose qu’une redistribution externe. C’est pourquoi une route peut arriver comme une LSA inter-zone alors que BGP l’a transportée entre-temps.

Le type de zone compte aussi. Une zone stub ou NSSA limite les LSA qui peuvent entrer, de sorte que la même route VPN peut être présentée différemment selon l’emplacement de l’instance OSPF réceptrice. La politique d’exportation configurée peut également remplacer la présentation par défaut, ce qui est un choix délibéré et non un effet secondaire.

Même domaine, présentation différente

Une route intra-zone ou inter-zone du même domaine arrive normalement sur le site distant comme une route inter-zone, une LSA de type 3. Un préfixe d’un autre domaine, une origine qui n’a jamais parlé OSPF ou une annonce OSPF initialement externe suivent plutôt les règles externes, et c’est là qu’apparaissent le type 5 et son équivalent NSSA. Les deux comportements sont corrects ; l’entrée diffère. Comparez les identifiants de domaine et les attributs annoncés avant de toucher aux valeurs de préférence.

La distance administrative choisit entre des sources sur un seul routeur. Elle ne réécrit pas un type de LSA et ne crée pas la relation de domaine manquante.

Quand un sham link est la bonne réponse

Imaginez deux sites dans la même zone reliés par un lien de secours direct. OSPF conserve ce chemin intra-zone plutôt que le chemin inter-zone offert par le fournisseur, même lorsque les coûts configurés rendraient le chemin du fournisseur attractif. Un sham link représente une relation intra-zone à travers le VPN afin que les coûts puissent participer à la décision. Il existe pour ce problème précis de sélection de chemin, non pour faire paraître interne chaque route du même domaine.

Un sham link nécessite des extrémités joignables et une configuration réciproque sur les deux PE. Le configurer d’un seul côté produit une relation qui ne se forme jamais, et la table de routage conserve son ancienne préférence, ce qui donne l’impression que la fonction n’a rien fait.

Ne cassez pas la protection contre les boucles

Le modèle PE-CE positionne le bit DN sur les routes qu’il distribue afin qu’un préfixe ne puisse pas revenir par un autre CE et être redistribué une seconde fois. Cette protection empêche un préfixe de boucler entre des sites qui partagent un domaine OSPF. La supprimer ou l’ignorer pour faire paraître une route interne peut créer exactement la boucle qu’elle était censée éviter. Lorsqu’un préfixe semble incorrect, traitez le bit DN comme une information et non comme un obstacle.

La même prudence s’applique aux filtres de redistribution et aux cartes de routes qui suppriment des communautés. Chacun retire un contexte dont le côté distant a besoin, et l’annonce résultante peut sembler plausible tout en étant fausse. Modifiez un attribut à la fois et vérifiez ce que le CE distant installe réellement.

Vérifiez ensuite depuis le site distant : le type de LSA, le routeur annonceur et le chemin choisi. Cette preuve répond à la question posée par le ticket.