Résumé

  • Maximum-prefix borne une quantité d’état de routage ; il ne détermine pas si la route qui franchit la limite est légitime ou dangereuse. Une action de fermeture peut supprimer toutes les routes apprises par la session, pas seulement l’annonce excédentaire.
  • Une politique maîtrisée relie chaque plafond à une relation et une famille d’adresses, documente le point de comptage, prévoit la croissance normale, choisit une action proportionnée et démontre l’effet dans la RIB, la FIB et les paquets.

Quand le budget cesse d’être une promesse

Le problème commence souvent bien avant l’alerte. Un nombre est choisi lors de la mise en service d’un voisin, puis copié dans un groupe de configuration. La population de routes évolue, le logiciel change, de nouveaux clients arrivent, mais la valeur conserve l’apparence d’une décision récente. Le jour où le compteur la dépasse, le réseau exécute une hypothèse dont personne ne possède plus les données.

La route supplémentaire n’est pas nécessairement exceptionnelle. Elle peut être correctement formée, autorisée et conforme à la relation. Ce qui change est uniquement le total. Si l’action associée au plafond est une fermeture, la conséquence ne se limite pas au surplus : la session disparaît et toutes les routes qui dépendaient d’elle doivent être remplacées ou retirées.

Maximum-prefix est donc un budget d’admission doté d’un pouvoir de rupture. Il peut empêcher un export accidentel de table complète d’épuiser le processus de routage. Il peut aussi transformer une croissance normale mal anticipée en panne. Le nombre protège seulement si l’organisation sait quelle ressource il borne et accepte explicitement la forme d’échec qu’il impose.

Ce que BGP autorise

RFC 4271 permet à un locuteur BGP de fixer une borne locale au nombre de préfixes acceptés d’un voisin. À la borne, la configuration peut rejeter de nouveaux préfixes en maintenant la connexion, ou terminer la connexion BGP. Si la terminaison résulte du dépassement, le locuteur envoie une notification Cease.

RFC 4486 attribue à cette cause le sous-code 1, Maximum Number of Prefixes Reached. Des données facultatives peuvent indiquer l’AFI, le SAFI et la borne sur quatre octets. Cette précision transforme une fermeture observée en preuve exploitable : elle distingue une décision de volume d’un arrêt administratif, d’une collision ou d’une erreur de ressource plus générale.

Le protocole ne choisit ni le chiffre ni le coût acceptable de la fermeture. Un client qui annonce quelques réseaux, un pair qui livre une vue partielle et un fournisseur de transit qui livre une table complète n’ont pas la même population attendue. La capacité du routeur, les chemins de secours et les services exposés sont eux aussi locaux. Cette liberté exige que chaque valeur puisse être rattachée à des faits locaux vérifiables.

Un compteur ne juge pas les routes

Le dépassement ne prouve pas une fuite, une attaque ou une erreur. Une décomposition autorisée pendant un incident, une migration, une acquisition de clients ou un changement d’agrégation peuvent accroître le total sans rendre les routes illégitimes. À l’inverse, une annonce non autorisée peut rester très en dessous du plafond.

Les filtres de préfixes, les politiques d’AS_PATH, la validation d’origine RPKI, les règles de prochain saut et les communautés évaluent des propriétés du contenu. Maximum-prefix observe une quantité. Il complète ces contrôles parce que même un état valide consomme de la mémoire et du temps de convergence. Il ne reçoit pas pour autant leur capacité à interpréter l’autorisation.

Le qualifier de mécanisme de sécurité n’a de sens qu’en nommant la ressource protégée. Il peut limiter la mémoire du processus, le travail d’analyse des mises à jour ou le risque qu’un voisin dégrade le reste du routeur par un volume inattendu. Il ne confirme pas l’intention commerciale du voisin et ne garantit pas que les routes sous le plafond sont sûres.

La définition du compteur appartient à la politique

Un même plafond peut viser des états différents.

La documentation BGP de FRRouting décrit un comptage par défaut des préfixes acceptés. Avec force, les préfixes reçus puis rejetés par la politique entrante sont également comptés, ce qui suppose de conserver l’état entrant nécessaire. FRRouting souligne en outre que détruire la session est nettement plus destructeur que rejeter les routes indésirables.

Junos sépare les deux intentions. prefix-limit porte sur les préfixes reçus ; accepted-prefix-limit porte sur ceux que la politique accepte. Les actions documentées comprennent la fermeture, le rejet du surplus et sa mise à l’écart, avec des conséquences de récupération différentes.

Compter avant politique montre le volume que le voisin tente d’imposer, même si un filtre en refuse la majorité. Cette mesure peut détecter un export massif très tôt, mais elle peut aussi fermer la session pour un état qui n’aurait jamais participé au routage local. Compter après politique correspond mieux à l’état admis, tout en laissant la politique masquer la pression brute reçue.

Le mot « préfixe » lui-même demande une vérification. ADD-PATH, les familles VPN ou les structures propres à une version peuvent maintenir plusieurs chemins vers une destination. Le coût interne ne suit alors pas nécessairement le nombre de destinations uniques. Le réglage n’est portable que si sa sémantique l’est ; le nom de commande ne suffit pas.

Quatre réponses et quatre risques

Avertir conserve la session et l’ensemble des routes. Cela crée un délai de décision mais ne borne pas la croissance. L’efficacité dépend de la livraison de l’alerte, de son propriétaire et du temps restant avant épuisement. Une alerte sans capacité d’action documente le risque sans le réduire.

Rejeter le surplus maintient la relation et les routes déjà admises. L’effet global est plus faible qu’une fermeture, mais la vue devient partielle. L’ordre d’arrivée peut influencer les destinations retenues et la baisse ultérieure du compteur ne garantit pas que les routes rejetées seront réévaluées sans route refresh.

Masquer le surplus préserve des informations pour une utilisation ultérieure tout en les excluant de la sélection normale. Cette solution peut faciliter le retour, mais elle continue éventuellement à consommer la mémoire que la limite devait préserver. Son intérêt doit être établi sur le comportement réel de la plate-forme.

Fermer la session arrête sans ambiguïté la source. Toutes les routes dont elle était l’unique chemin utilisable disparaissent cependant avec elle. Le trafic peut se déplacer vers des liens moins dimensionnés, choisir des chemins plus longs ou perdre toute alternative.

Les mots des constructeurs ne décrivent pas toujours le même état final. Cisco documente un pourcentage d’avertissement, une fermeture par défaut, un mode d’avertissement seul et un délai de reprise optionnel. Arista EOS décrit une limite pouvant désactiver le peering, tandis qu’un mode d’avertissement peut maintenir la session et abandonner les routes suivantes. Il faut comparer les routes restantes, pas les libellés.

Construire le nombre à partir de la relation

RFC 7454 recommande une limite propre à chaque peering. Pour un voisin censé fournir un ensemble restreint, une valeur inférieure à la table Internet complète peut détecter un export accidentel de grande ampleur. Pour un transit qui doit justement fournir une table complète, la limite doit dépasser la population attendue sans franchir la capacité sûre du récepteur.

Le calcul commence par l’inventaire légitime, pas par un pourcentage de marché. Il ajoute la variance observée, la croissance crédible, les décompositions prévues, les migrations et l’arrivée de clients. Il confronte ensuite cette projection à la capacité de la plate-forme et au coût de l’action choisie. Enfin, il fixe un propriétaire et une date de révision.

RFC 4778 recommande de coordonner le nombre attendu de préfixes et de prévoir une marge pour les variations valides. Une protection inconnue de l’autre partie peut sanctionner une évolution parfaitement autorisée. RFC 7454 rappelle que la valeur doit être revue régulièrement, puisque la population routée change.

La marge se comprend mieux en durée et en variance qu’en pourcentage abstrait. Une même proportion peut couvrir des années sur une relation stable ou quelques semaines pendant une intégration. Trop faible, elle rend la protection fragile ; trop large, elle rend la limite décorative. Sa fonction est de préserver un temps de décision compatible avec la capacité réelle.

Reprendre exige une condition nouvelle

Un délai de redémarrage automatique peut remettre rapidement en service une session après un dépassement transitoire. Si le voisin continue d’envoyer le même ensemble, il automatise au contraire une oscillation : ouverture, dépassement, fermeture, attente, nouvelle ouverture.

Le temps écoulé n’est pas une preuve de correction. Une reprise défendable s’appuie sur un retrait du surplus, une politique d’export réparée, une hausse explicitement approuvée ou une capacité nouvelle. Une commande manuelle sans justification ne change pas la qualité de la décision ; elle remplace seulement la minuterie par un opérateur.

RFC 8538 suggère de traiter le Cease maximum-prefix comme un hard reset dans le cadre de Graceful Restart. Une fermeture volontaire pour volume ne devrait pas être rendue ambiguë par la conservation silencieuse de routes périmées comme s’il s’agissait d’un redémarrage ordinaire.

Relier le seuil au service

La preuve commence par la configuration effective par voisin et AFI/SAFI, y compris les valeurs héritées, le seuil d’avertissement et l’action. Elle inclut la version logicielle et la documentation qui définit le comptage reçu ou accepté, ainsi que la différence entre chemins et destinations lorsque celle-ci existe.

Au moment du dépassement, il faut conserver la dernière mise à jour admise, le passage du compteur, le code et sous-code Cease, les éventuelles données AFI/SAFI/borne, l’état de session, la minuterie et les journaux susceptibles d’être limités en fréquence. Les routes retirées, rejetées, masquées ou conservées doivent être distinguées.

La preuve se termine dans le plan de données. Quelles destinations changent de meilleur chemin ? Les candidats de remplacement existent-ils dans la RIB et sont-ils installés dans la FIB ? Les interfaces de secours disposent-elles de capacité ? Des sondes vers les classes critiques confirment-elles la livraison ? Un total identique après reprise ne prouve ni le même ensemble ni les mêmes attributs.

La protection a réussi seulement si la ressource nommée reste dans son objectif et si l’état de service correspond au compromis approuvé. Le compteur ne peut démontrer seul aucune de ces deux affirmations.

Sources