Politique d’export Junos : le nom n’est pas la condition de correspondance

Une politique nommée EXPORT-STATIC ne sélectionne rien par son nom. Lisez le rattachement, les termes ordonnés et les actions, puis comparez la vue annoncée.

Quelqu’un a nommé une politique EXPORT-STATIC, l’a rattachée, et se demande maintenant pourquoi un préfixe de l’instance de routage VPN n’atteint jamais l’extrémité distante. Le nom n’a aucun effet sur la sélection. Une politique est une définition plus un rattachement, et ce qu’elle exporte est décidé par ses conditions de correspondance, ses termes ordonnés et le contexte qui l’utilise. Lisez ces trois dans cet ordre, et le mystère se réduit généralement à un terme qui n’a jamais correspondu.

Le nom est une étiquette, pas une condition

Junos n’interprète pas les noms des politiques. Une politique qu’on appellerait raisonnablement export statique peut correspondre au protocole static, ou correspondre à un préfixe d’adresse, ou ne correspondre à rien et accepter tout ce qui passe. L’étiquette est une documentation écrite par celui qui l’a créée, et elle est exactement aussi fiable que la mémoire que cette personne a de l’intention.

Traitez un résultat d’export surprenant comme une demande de lire la définition, non comme la preuve que le rattachement est cassé. Lisez la définition et laissez-la contredire l’étiquette.

Trouvez le rattachement avant les termes

Une définition correcte rattachée au mauvais endroit modifie un autre échange. Déterminez quelle instance de routage, quel protocole et quel voisin ou groupe référencent réellement la politique, car une politique rattachée sous un groupe BGP n’affecte pas un autre, et une politique rattachée à l’instance ne s’applique pas forcément à tous les protocoles qu’elle contient. Junos distingue ces niveaux, et une exportation absente au niveau du groupe est courante lorsque l’intention a été exprimée au niveau de l’instance.

Notez le chemin du rattachement avant de lire un seul terme. La moitié de ces enquêtes s’arrêtent là, avec la définition intacte et l’instruction d’export déplacée. Consignez la différence dans le journal des modifications pour que personne ne la révoque comme une erreur.

Les termes s’évaluent dans l’ordre, et la première décision l’emporte

Les termes s’exécutent du premier au dernier, et un terme qui accepte ou rejette est une décision finale. Un terme ultérieur qui ressemble à l’exception prévue ne s’exécute jamais si un terme antérieur a déjà décidé du sort de la route, ce qui explique qu’une politique puisse se lire correctement de haut en bas et pourtant se comporter à l’inverse de l’intention. Vérifiez l’ordre par rapport à la route qui vous intéresse, non par rapport à l’ordre dans lequel les termes ont été saisis.

Un terme qui omet son action ne termine pas ; l’évaluation se poursuit vers le terme suivant, et le résultat final dépend de ce qui suit et de la valeur par défaut applicable. C’est une construction réellement utile et une source fiable de surprise lorsqu’elle est involontaire.

Un exemple qui n’exporte que des routes statiques, avec le rattachement sur le groupe :

policy-options {
    policy-statement EXPORT-STATIC {
        term statics { from protocol static; then accept; }
    }
}
protocols bgp group TO-PEER { export EXPORT-STATIC; }

Un préfixe appris par OSPF plutôt que configuré comme route statique échoue à la correspondance et est écarté, quel que soit le nom de la politique.

Les actions modifient une copie, pas la route d’origine

Les actions de politique s’appliquent à la route telle qu’elle est évaluée pour cette annonce, c’est-à-dire à une copie et non à l’entrée de la table de routage. Une commande locale show route peut donc afficher une route avec un jeu d’attributs tandis que la version exportée en porte d’autres, et l’original n’est pas réécrit par l’exportation. Cette distinction explique plusieurs discussions sur la sortie qui est correcte : les deux le sont, et elles décrivent des objets différents. Dites quelle vue vous citez chaque fois que deux ingénieurs sont en désaccord sur un attribut de route.

Accepter et rejeter sont des décisions finales ; les changements d’attributs ne le sont pas nécessairement. Ne supposez pas qu’établir une community met fin à la politique, car l’évaluation peut se poursuivre dans des termes que vous n’avez pas envisagés.

Comparez la vue annoncée à l’attente

Utilisez la vue propre au protocole sur le pair réel, par exemple show route advertising-protocol bgp 192.0.2.1, et lisez-la dans le bon contexte d’instance de routage. Une route présente dans un VRF n’a pas forcément passé la politique d’export, et une route qui apparaît dans la sortie annoncée n’a pas forcément été acceptée par l’extrémité distante. Ce sont trois états distincts, et ils échouent différemment.

Acceptez la conception avec un préfixe qui doit être annoncé et un qui doit rester local. Cela donne à la politique un contrat que vous pouvez tester, et évite le correctif alternatif consistant à élargir l’export jusqu’à ce qu’une route nommée finisse par apparaître.

Articles similaires