Résumé

  • LOCAL_PREF classe les routes admissibles selon la politique du système autonome qui les reçoit. Une valeur élevée n’est pas une preuve de sécurité ou de performance.
  • Une règle appliquée en bordure peut modifier des choix de sortie à l’intérieur de l’AS, sans que le voisin externe voie l’attribut à l’origine de cette décision.
  • Le contrôle utile porte sur le périmètre de la règle et ses effets observés. Une configuration correcte, voire des valeurs identiques, ne suffit pas à démontrer un acheminement cohérent.

Le trajet court n’a pas le dernier mot

Prenons une situation illustrative, sans l’attribuer à un incident réel. Un AS dispose de deux routes utilisables vers un même préfixe, par les routeurs de bordure A et B. Le chemin d’AS est plus court par A. Les deux routes ont une préférence locale de 100 et les critères précédents sont à égalité, notamment le poids propre à Cisco lorsque cet équipement est concerné. Une règle d’importation attribue désormais 200 à la route par B. Dans cette comparaison, le choix peut basculer vers B avant même d’examiner la longueur du chemin.

Ce qui a changé n’est pas la géographie du réseau. C’est son ordre de priorité. Le détour apparent peut être voulu, par exemple pour privilégier une relation commerciale ou conserver une autre liaison en réserve. Il peut aussi résulter d’une erreur de périmètre. L’entier ne permet pas de distinguer ces deux histoires. Il faut retrouver la décision dont il est l’expression.

Le mécanisme est défini par l’IETF : LOCAL_PREF est un entier non signé de quatre octets, transmis entre voisins internes, dont la valeur supérieure est préférée. La politique locale détermine le classement d’une route externe. Hors du cas particulier des confédérations BGP, l’attribut ne se transmet pas au voisin EBGP et ne doit pas être utilisé s’il vient de lui. RFC 4271, section 5.1.5

Le protocole fixe donc une grammaire commune sans imposer les motifs du choix. Le nombre 100, souvent présenté comme allant de soi, relève lui aussi d’une distinction importante : c’est une valeur par défaut courante dans les implémentations, non une valeur par défaut universelle prescrite par BGP. Une migration entre équipements doit vérifier le comportement effectif plutôt que recopier cette habitude. RFC 4277, section 8

Une frontière d’autorité, pas un jugement de qualité

La préférence intervient parmi des possibilités admissibles. Elle n’autorise pas à elle seule l’origine d’une annonce, n’authentifie pas le voisin et ne garantit pas que les paquets arriveront. La validation d’origine fournit un autre type d’information, ensuite pris en compte dans la politique de routage. Confondre cet examen avec le classement revient à laisser une priorité commerciale répondre à une question de sécurité. RFC 6483, section 3

Les contre-exemples évitent une lecture trop absolue. Une route refusée ne devient pas admissible parce qu’on lui attribue 200. Un prochain saut inaccessible ne se répare pas par une hausse de préférence. Et une route agrégée très favorisée ne remplace pas une route plus spécifique déjà installée pour les destinations qu’elle couvre : la recherche du préfixe le plus long reste déterminante dans l’acheminement. Il faut donc comparer le même préfixe et tester les adresses réellement concernées.

Les constructeurs ajoutent leurs propres précisions. Cisco place son poids local au routeur avant LOCAL_PREF, puis la longueur du chemin d’AS plus loin dans la procédure. Junos commence par la résolution du prochain saut et la préférence du protocole de routage avant la préférence locale BGP. Cette « préférence du protocole » n’est pas LOCAL_PREF, malgré la proximité du vocabulaire. Sélection du meilleur chemin chez Cisco, Sélection des routes dans Junos

Ces documents ne constituent pas deux versions interchangeables d’une règle universelle. Ils indiquent ce qu’il faut vérifier sur les systèmes exploités. Junos décrit notamment la conservation par défaut d’une valeur présente et le traitement de 100 lors de l’exportation des routes vers BGP. Lire seulement la configuration d’entrée ferait perdre une partie du comportement effectif. Documentation Junos sur la préférence locale

La demande du client et la décision du fournisseur

Un client multiraccordé peut vouloir qu’une de ses connexions serve de secours. Les communautés BGP lui permettent de demander un traitement prévu par son fournisseur. RFC 1998 décrit précisément cette association entre communautés reçues et valeurs de préférence appliquées par l’opérateur. La demande voyage ; le pouvoir de lui donner effet reste dans le réseau qui applique la politique. RFC 1998, section 3.2

Cette séparation se retrouve dans les Large Communities. Une étiquette peut demander une action, éventuellement limitée à une zone, mais sa présence ne prouve ni l’autorisation de l’émetteur ni l’exécution de l’action. L’ordre de traitement devient important lorsque plusieurs demandes se rencontrent. Une modification de cet ordre peut changer le résultat sans que le client change son annonce. RFC 8195, sections 2.2 et 4.3

Il serait pourtant excessif d’en conclure que toute influence extérieure est suspecte. Une interface documentée réduit les interventions manuelles et permet au client d’exprimer sa propre connaissance de sa topologie. Le risque apparaît lorsque l’opérateur ne sait plus expliquer quels voisins peuvent demander quelle classe, pour quels préfixes, dans quel périmètre. La simplicité du nombre masque alors la complexité de la délégation.

MED offre au voisin un moyen d’indiquer une préférence d’entrée ; LOCAL_PREF exprime le choix du réseau qui reçoit cette indication. AIGP apporte une métrique accumulée dans un cadre administratif délimité. Ni l’un ni l’autre ne dispense de désigner le responsable du classement local. Ce ne sont pas des notes de qualité comparables sur une même échelle.

L’uniformité des chiffres n’est pas l’objectif final

Une règle peut concerner des milliers de destinations alors que sa démonstration n’en examine qu’une. Sa portée dépend des critères de correspondance, des familles d’adresses et des annonces internes qu’elle influence. « Local » signifie ici interne à un AS, non limité à un équipement. Cette portée explique pourquoi une ancienne association de communauté, ou une exception oubliée, peut avoir des effets éloignés de son point de configuration.

Il faut toutefois éviter de transformer la cohérence en obligation imaginaire d’uniformité. RFC 4272 relève que BGP n’impose pas partout une valeur identique entre locuteurs internes. Une politique régionale peut être intentionnelle. RFC 4271 avertit séparément qu’un recalcul de préférence sur une route apprise en IBGP peut provoquer des boucles persistantes. La question est donc celle du fonctionnement cohérent de la topologie réelle. Analyse de sécurité de BGP, RFC 4271, section 9.1.1

La maintenance rend ce problème concret. Graceful Shutdown prévoit une baisse de préférence, avec zéro comme valeur recommandée, pour laisser apparaître et converger les solutions de remplacement. Zéro ne retire pas la route : elle peut rester utilisée si aucune autre solution admissible n’est disponible. Les réflecteurs de routes peuvent en outre masquer des alternatives. Avant de couper une liaison, il faut constater le déplacement utile du trafic, pas seulement la baisse du chiffre. RFC 8326, sections 3 et 4

L’erreur peut être parfaitement valide

Une valeur excessive, mais correctement encodée, n’est pas un message mal formé. RFC 7606 distingue le rejet de l’attribut reçu d’un voisin externe ordinaire du traitement comme retrait d’une annonce interne dont LOCAL_PREF n’a pas la longueur de quatre octets. Ces protections détectent un défaut de forme, pas une décision d’exploitation mal traduite. RFC 7606, section 7.5

Un réseau peut ainsi conserver ses sessions et ses volumes de routes tout en envoyant du trafic par une sortie inattendue. Ce serait une erreur de chercher uniquement un voisin déconnecté. Les symptômes pertinents pourraient être une concentration nouvelle, une perte sur une liaison chargée ou une différence entre régions. Il s’agit de pistes de diagnostic, non de l’affirmation d’un incident observé.

La preuve commence par la politique : responsable, motif, ensemble des routes visées et condition de retour arrière. Elle se poursuit dans les alternatives reçues en Adj-RIB-In, les valeurs après traitement et les annonces IBGP. Il faut ensuite comparer les choix Loc-RIB à plusieurs endroits pertinents, y compris derrière les réflecteurs. Un collecteur public extérieur ne montre pas directement la préférence interne ayant motivé la sortie.

Enfin viennent le prochain saut résolu, la table de transfert installée, les éventuels chemins à coût égal et les paquets. Des sondes depuis plusieurs points d’entrée, rapprochées des compteurs de sortie, permettent de tester le résultat annoncé. Le retour arrière exige la même vérification : réévaluer les routes, au moyen de l’état conservé ou de Route Refresh lorsque celui-ci est disponible, puis constater le rétablissement. Recharger l’information n’écrit pas la politique à la place de l’opérateur. Une préférence n’est maîtrisée que lorsque son effet l’est aussi.