Résumé

  • RFC 8092 définit une valeur transitive de douze octets, mais ses deux champs locaux prennent le sens publié par l’opérateur du namespace.
  • Une communauté d’action ne devient effective que si la bonne politique reconnaît la valeur, au bon stade, puis applique l’action prévue.
  • La clôture doit relier route, dictionnaire, révision de politique, résultat du match, attributs après politique, exports et observation en aval.

La bonne étiquette, le mauvais résultat

Une route arrive avec la valeur ASN:fonction:paramètre attendue. Le ticket affirme qu’elle bloque l’export vers une classe de pairs. Pourtant, un collecteur en aval voit encore le préfixe par un pair qui devait être exclu.

La communauté existe bien au premier point d’observation. L’erreur consiste à traduire cette présence par « la politique a été exécutée ». Un dictionnaire périmé, une politique attachée dans le mauvais sens, un match placé après une réécriture, une différence de plateforme ou une règle d’export ultérieure peuvent conserver le premier fait tout en annulant le résultat.

RFC 8092 définit un attribut optionnel et transitif. Chaque valeur comporte un Global Administrator sur quatre octets et deux champs locaux de quatre octets définis par l’opérateur. Le format prend en charge les ASN sur quatre octets, mais ne normalise pas les significations privées.

Voir 64496:100:7 prouve donc que cette valeur a atteint un speaker et un stade précis. Cela ne prouve pas ce que signifient aujourd’hui 100 et 7, quelle politique les a consommés, ni si un autre AS a conservé la valeur.

Le RFC précise aussi qu’aucune intégrité n’est fournie. Un AS intermédiaire peut ajouter, retirer ou modifier une valeur. L’ordre est sans importance, les doublons sont supprimés et une longueur mal formée déclenche treat-as-withdraw. Aucune de ces règles n’est un accusé d’exécution.

L’action dépend du moteur de politique

RFC 8195 distingue les communautés informatives des communautés d’action. Les premières décrivent une propriété, comme le lieu d’import. Les secondes demandent un traitement, par exemple une préférence ou une règle de propagation. C’est la politique de l’AS destinataire qui traduit la valeur en action.

Le document recommande de publier le répertoire des valeurs et l’ordre de traitement. Un code valide lu avec une ancienne version peut produire la mauvaise action. Deux actions correctes peuvent se contredire, et leur ordre décider de la préférence, du filtrage ou de l’export.

RFC 1997 pose le même principe pour les communautés classiques : un speaker peut les utiliser pour accepter, préférer ou distribuer une route et peut les modifier selon sa politique locale. NO_EXPORT et NO_ADVERTISE ont une portée normalisée. Une Large Community définie par un opérateur n’acquiert pas pour autant un sens universel.

Une étape ultérieure peut annuler le succès

RFC 8642 montre que la commande qui « fixe » un ensemble de communautés ne traite pas toujours les communautés bien connues de la même manière selon les plateformes. Deux configurations apparemment identiques peuvent donc produire des attributs différents.

Plus généralement, un match d’import peut réussir puis être neutralisé. La préférence locale peut être correcte tandis que l’ensemble exporté ne l’est pas. Une valeur peut être retirée à la frontière externe. Un route reflector ou un déploiement automatisé peut exécuter une autre révision.

Il faut suivre la route à chaque étape : préfixe et chemin exacts, valeurs reçues, version du dictionnaire, attachement et sens de la politique, trace du match, attributs résultants, chemin choisi, vue advertised-routes par classe de pairs et observation indépendante en aval.

Sources