D'une route RIP CE vers un VRF distant : où se fait l'export

Une mise à jour RIPv2 arrive sur le PE de bord, atterrit dans une table de routage VRF et s'y arrête, sauf si quelque chose l'exporte explicitement. Trois décisions se succèdent, et chacune peut refuser le préfixe pour sa propre raison. C'est de les lire comme un seul événement qui pousse à chercher le mauvais équipement lorsqu'un site distant n'atteint pas un réseau que le CE annonce clairement. Suivez la route à travers le PE et la séquence devient évidente.

Ce que le PE fait d'une mise à jour RIP

Le PE reçoit la mise à jour sur l'interface VRF, vérifie que la source est un voisin autorisé et installe le préfixe dans la table de routage VRF avec un nombre de sauts dérivé de l'annonce. Cette table est une table de routage ordinaire, avec ses propres distances administratives et sa propre élection du meilleur chemin. Si le CE annonce deux fois le même préfixe avec des métriques différentes, seul le meilleur survit dans la table. Rien dans cette étape ne concerne le backbone de l'opérateur.

Le préfixe existe désormais dans le contexte de routage d'un seul client, ce qui est très loin d'être joignable ailleurs.

L'export est un acte de politique, pas une conséquence du protocole

Pour quitter le VRF, une route doit être redistribuée dans le processus MP-BGP qui transporte les routes VPN, et il lui faut une communauté étendue de type route target qui identifie quels VRF distants peuvent l'importer. L'architecture de RFC 4364 garde ces échanges séparés du protocole CE-vers-PE exactement pour cette raison. Utiliser RIP en bordure ne dit rien de ce qui doit traverser le réseau de l'opérateur.

Écrivez le contrat d'export avant de configurer quoi que ce soit : les préfixes client qui doivent être joignables à distance, les routes qui doivent rester locales, et tout défaut, route plus spécifique ou exception de service partagé. Confrontez ce contrat au VRF réel et non à un VRF au nom similaire appartenant à un autre client.

Le côté import est une seconde politique avec ses propres route targets, et un export correspondant avec un import qui ne correspond pas produit un préfixe qui existe dans le backbone et n'apparaît dans aucune table distante.

Redistribution et origine explicite se comportent différemment

La redistribution reprend les routes déjà présentes dans la table VRF et les copie dans BGP, filtrées par une route map. La map décide quels préfixes sont éligibles et quels attributs ils portent, et la métrique doit être fixée explicitement car un nombre de sauts RIP n'a aucun sens comme métrique BGP. Tout ce que vous laissez non défini est hérité d'une manière qui surprend généralement la personne qui relit la configuration six mois plus tard.

La redistribution mutuelle est là où les dégâts silencieux se produisent. Un préfixe exporté vers BGP peut revenir par un second point de redistribution, et sans tags ni filtres la route oscille alors que les deux tables paraissent plausibles à tout instant. Filtrez sur les tags appliqués en bordure plutôt que de compter sur la topologie pour empêcher le chemin de retour.

L'origine explicite paraît plus propre et n'est pas inconditionnelle. Une instruction network requiert normalement une route correspondante dans la table de routage avant que le préfixe soit originaire, si bien que l'annonce disparaît dès que le CE cesse de l'annoncer. C'est souvent le comportement souhaité, et ce n'est pas la même chose qu'une route statique qui reste configurée pour toujours. Vérifiez la règle réelle de la plate-forme au lieu de supposer l'un ou l'autre comportement.

Quoi qu'il en soit, la question à poser pour chaque préfixe est quelle source active le rend éligible et ce qui se passe lorsque cette source disparaît.

Vérifiez la chaîne à quatre endroits

Regardez l'annonce du CE, la table de routage VRF, la table des routes VPN avec son route target et l'import du VRF distant, dans cet ordre. Sur IOS, cela signifie la sortie du voisin CE, show ip route vrf CUSTOMER, show ip bgp vpnv4 vrf CUSTOMER, et la même commande sur le PE distant. Sur IOS-XR, la sortie équivalente se trouve sous show bgp vrf CUSTOMER ipv4 unicast. Les noms des commandes diffèrent, les quatre points de contrôle non.

Vérifiez un préfixe qui devrait être rejeté avec autant de soin qu'un préfixe qui devrait passer, car une politique qui autorise tout est identique à une politique correcte jusqu'à la première exception. Observez ensuite un retrait : coupez l'interface du CE et confirmez que l'entrée distante disparaît dans le délai attendu au lieu de subsister.

Notez qui est propriétaire de chaque politique. Quand l'opérateur exploite le CE, le comportement livré relève du contrat de service, et un protocole ou une politique de retrait différents sur l'équipement géré sont un problème de documentation avant d'être un problème de routage.