Résumé

  • Le multipath autorise plusieurs routes qualifiées dans le transfert local ; il ne garantit ni capacité égale, ni diversité physique, ni partage égal des octets.
  • BGP décide de l'admissibilité, la récursion et le matériel construisent le groupe, puis le hachage et la population de flux déterminent son usage.
  • Une validation sérieuse relie Adj-RIB-In, RIB, FIB, compteurs par membre, files d'attente et essais de panne. Une capture de la table de routes ne couvre qu'une étape.

Le faux confort du chiffre deux

Prenons un scénario explicatif, pas un incident réel. Deux routes vers un même préfixe satisfont les critères multipath d'un équipement. Les deux next-hops apparaissent dans le groupe ECMP. Le compte rendu conclut à un partage égal de la charge. Un transfert massif et durable est ensuite haché vers le membre A : sa file se remplit alors que B conserve de la marge.

Rien n'impose que BGP soit en panne. Les deux routes peuvent rester installées et le groupe peut se comporter exactement comme prévu. L'erreur consiste à transformer l'égalité du nombre de membres en égalité de volume. Un hachage distribue des identifiants de flux ; il ne normalise pas la taille de ces flux.

RFC 4271 décrit une sélection parmi les routes éligibles, l'installation dans la Loc-RIB et la détermination du prochain saut immédiat. Les implémentations multipath étendent localement ce résultat en conservant d'autres routes qualifiées. Elles ne créent pas une promesse interdomaines obligeant tous les pairs à annoncer ou utiliser le même ensemble. RFC 4271, section 9.1.2

Le mot « égal » dépend d'ailleurs du produit. Cisco documente ses comparaisons multipath tout en gardant un best path désigné pour l'annonce. FRRouting effectue son contrôle multipath après des critères antérieurs et permet de relâcher, avec multipath-relax, l'identité exacte de l'AS_PATH. Arista documente encore un comportement par défaut différent pour ce relâchement dans le contexte EOS cité. Ces règles expriment une admissibilité locale ; elles ne certifient ni capacité, ni indépendance, ni valeur commerciale identiques. Documentation Cisco, documentation FRRouting, documentation BGP d'Arista EOS

Trois verdicts à ne pas confondre

Le premier porte sur les candidats : quelles routes sont utilisables, conformes à la politique et suffisamment équivalentes ? maximum-paths fixe un plafond, pas le nombre effectivement programmé.

Le deuxième porte sur la construction. Chaque route doit résoudre son prochain saut, atteindre la FIB et entrer dans les limites du matériel. Deux adresses différentes peuvent traverser la même carte, le même tunnel ou le même circuit distant. Un inventaire des domaines de panne reste donc nécessaire.

Le troisième verdict est rendu par le hachage pour chaque flux. RFC 2991 explique l'intérêt de maintenir les paquets d'un flux sur un chemin afin d'éviter le désordre, et le risque associé aux changements de membres. RFC 2992 analyse l'algorithme hash-threshold : une bonne distribution de l'espace de hachage n'est pas une garantie d'égalité des octets lorsque les flux ont des tailles très différentes. RFC 2991, RFC 2992

Il faut donc prouver séparément l'éligibilité des routes, l'existence des membres matériels et l'usage réel de chaque membre.

L'entropie disponible n'est jamais abstraite

Le routeur ne peut hacher que les champs qu'il voit. Avec IPv6, le flow label peut fournir de l'entropie lorsque les en-têtes de transport sont masqués. RFC 6438 montre aussi pourquoi tunnels, fragments et charges opaques restreignent cette information. Des milliers de conversations internes peuvent présenter le même tuple externe et se comporter comme un flux unique pour un équipement qui ne regarde pas plus loin. RFC 6438

Il est donc insuffisant d'écrire « hachage cinq-tuple » sans préciser plateforme, famille d'adresses, encapsulation, graine et granularité. Les commandes Arista sur les graines, la polarisation et l'ECMP résilient illustrent une surface de contrôle propre à l'implémentation, non un défaut universel. Documentation Arista

La population de flux pèse autant que l'algorithme. RFC 7424 décrit une correspondance plusieurs-vers-un entre flux et liens et souligne l'effet des elephant flows. Une multitude de sessions courtes peut produire une moyenne lisse ; un flux de sauvegarde ou de réplication peut occuper un membre pendant des heures. Paquets, octets, files, pertes et latence rendent chacun un verdict différent. RFC 7424

Des membres de capacités différentes posent enfin un problème de politique. L'ECMP ordinaire n'apprend pas spontanément qu'un lien vaut dix fois l'autre. Pondération et routage adaptatif sont des mécanismes distincts, avec leurs propres preuves et risques.

Annoncer plusieurs chemins n'est pas les utiliser

ADD-PATH sépare nettement visibilité et transfert. RFC 7911 autorise l'annonce de plusieurs chemins pour un préfixe sans remplacement implicite. Le destinataire n'est pas obligé de tous les installer ni de répartir son trafic d'une manière donnée. Inversement, un routeur peut utiliser plusieurs chemins localement tout en n'annonçant que son best path ordinaire. RFC 7911

PIC répond à une autre question : préparer une réparation rapide après panne. Un chemin de secours préprogrammé n'est pas nécessairement un membre qui transporte du trafic en régime normal. Junos montre encore une frontière locale en séparant la sélection multipath BGP de la politique de load balancing dans la table de transfert. Son vocabulaire historique « per-packet » décrit couramment un hachage par flux et doit être lu dans le contexte exact de la plateforme. Documentation Junos

Une preuve qui descend jusqu'aux paquets

Le dossier commence par la portée : préfixes, familles, pairs, plafond de membres, propriétaire et condition de retour. Il conserve les candidats Adj-RIB-In et le résultat précis de la comparaison. Si multipath-relax intervient, il précise ce qui a été relâché au lieu de traduire « même longueur » par « même risque ».

Il suit ensuite la récursion, inventorie les domaines de panne et lit l'objet ECMP effectivement programmé. Une RIB à deux chemins face à une FIB à un membre indique un problème de résolution, de capacité ou de programmation, pas encore un problème de hachage.

Enfin, il mesure sur une durée représentative les paquets, octets, pertes et files de chaque membre, identifie les grands flux et lance des sondes avec de nombreuses clés depuis les vrais points d'entrée. La suppression puis le rétablissement d'un membre font partie du test : un algorithme résilient réduit certains déplacements, il ne supprime ni tout remappage ni tout risque de désordre.

Le rollback suit la même chaîne. Annuler la configuration n'est qu'une action ; retrouver l'ensemble de candidats, le groupe matériel et le comportement des paquets constitue le résultat.