Résumé

  • Anja Feldmann et cinq coauteurs ont décrit la demande comme un volume entrant par un lien et destiné à un ensemble de sorties possibles, afin de ne pas confondre le besoin de transport avec le chemin choisi à cet instant.
  • Leur étude du réseau IP d’AT&T a rapproché NetFlow, tables de transfert, configurations et compteurs SNMP ; les pertes, les instantanés périmés et les entrées ambiguës restaient visibles dans le résultat.

La console montre un lien à 95 %. L’information paraît suffisante : il faut soulager ce lien. Mais déplacer un poids OSPF sans connaître les demandes qui le traversent peut seulement déplacer l’alerte. Le compteur additionne des octets après que la topologie et le routage ont décidé de leurs chemins. Il ne raconte pas comment cette somme s’est formée.

C’est précisément le changement de perspective proposé par Anja Feldmann, Albert Greenberg, Carsten Lund, Nick Reingold, Jennifer Rexford et Fred True dans leur étude des réseaux IP opérationnels. La matrice de trafic n’était pas une vérité déjà inscrite dans un routeur. Elle devait être reconstruite à partir de sources qui ne voyaient chacune qu’une partie du réseau.

La charge d’un lien est une conséquence. La demande est ce que le réseau doit transporter. Si les deux sont confondues, le modèle reproduit le routage actuel au moment même où l’opérateur veut en essayer un autre.

Détacher la demande du chemin

Une matrice complète entre chaque adresse source et chaque adresse destination aurait été gigantesque. Elle aurait surtout supposé une visibilité de bout en bout qu’un fournisseur n’avait pas : une grande partie du trafic traversait plusieurs domaines administratifs.

Les chercheurs ont retenu un objet moins ambitieux et plus opératoire. Une demande associait un lien d’entrée, un volume et l’ensemble des liens de sortie susceptibles d’atteindre le préfixe visé. Elle était donc de type point-à-multipoint. Le choix final parmi les sorties restait l’affaire de BGP, du routage interne et de la configuration du moment.

Cette séparation permettait de poser une vraie question contrefactuelle. Si un poids OSPF change, la demande demeure, tandis que son parcours peut être recalculé. Si une annonce BGP disparaît, l’ensemble des sorties possibles change et le modèle doit être daté de ce nouvel état. Le système NetScope, développé par une partie de la même équipe, utilisait cette vue globale pour retrouver les demandes présentes sur un lien chargé et simuler une nouvelle configuration avant de toucher au réseau réel.

Le degré de détail répondait à la décision recherchée. Pour l’ingénierie de trafic, des fenêtres de plusieurs dizaines de minutes étaient plus utiles qu’une chronologie de chaque paquet. Les enregistrements de flux pouvaient être ventilés dans ces fenêtres, puis regroupés par entrée et ensemble de sorties.

Une matrice faite de quatre jeux de données

À l’entrée du réseau, un enregistrement de flux donnait l’interface, l’adresse de destination, les heures de début et de fin ainsi que le nombre d’octets. La table de transfert associait le préfixe de destination à des sorties. Les fichiers de configuration fournissaient les noms, les rôles, les capacités, les filtres et les paramètres OSPF. Un modèle de routage transformait enfin cette connaissance en chemins possibles.

Mesurer chaque lien d’accès aurait été préférable, mais ce n’était pas réalisable sur ce réseau. Certains routeurs ne proposaient pas la fonction ; sur d’autres, son coût pouvait gêner les tâches de contrôle. L’équipe a donc concentré la collecte sur les liens de peering, équipés de routeurs plus puissants et traversés par une part importante du trafic inter-fournisseurs.

Ce compromis créait trois lacunes clairement nommées. Le trafic interne entre deux accès pouvait ne jamais passer par un peering. Pour un flux sortant, l’observation avait lieu à la sortie et non à son entrée d’origine. Quant au transit multisegment, il pouvait produire deux enregistrements, qu’il fallait empêcher de compter deux fois.

L’entrée d’un flux sortant était donc une hypothèse à tester. Son adresse source pouvait correspondre à plusieurs liens client. Pour chacun, le modèle calculait si le chemin aurait pu rejoindre l’interface de peering où le flux avait été vu, compte tenu de la topologie et de la configuration datées. Les candidats impossibles étaient retirés. Il pouvait rester une entrée, plusieurs, ou aucune.

Lorsque plusieurs entrées demeuraient compatibles, le volume était partagé au lieu d’être affecté arbitrairement à l’une d’elles. Cette modestie compte : « observé à la sortie », « compatible avec une entrée » et « compatible avec plusieurs » ne constituent pas le même niveau de preuve.

La perte de télémétrie faisait partie de la mesure

Les enregistrements NetFlow étaient envoyés en UDP vers un serveur de collecte. Aux périodes de forte charge, jusqu’à 90 % de ces paquets d’export pouvaient se perdre sur le lien du collecteur. Le flux reçu continuait pourtant à produire des courbes crédibles. Sans contrôle extérieur, une fraction aurait pu passer pour le total.

Les numéros de séquence ont permis d’étudier les trous. Leur distribution était compatible avec une perte approximativement indépendante. Les auteurs ont alors calculé une probabilité par intervalle de dix minutes et corrigé le volume des enregistrements reçus. Ce facteur ne ressuscitait pas les flux absents ; il extrapolait un échantillon selon une hypothèse explicitée.

Le test provenait des compteurs SNMP d’interface, relevés toutes les cinq minutes. Après correction, les utilisations déduites de NetFlow suivaient d’assez près les séries SNMP. SNMP ne révélait toujours pas la matrice. Il vérifiait que la somme reconstruite ne s’éloignait pas d’un total mesuré par une voie indépendante.

Les identités et les horloges posaient leur propre difficulté. NetFlow nommait une interface par un indice SNMP, tandis que les configurations employaient des noms et des adresses. Certaines cartes d’interface n’avaient pas exactement l’heure du processeur de route. Les fichiers de configuration, les tables de transfert et les mesures n’étaient pas toujours capturés au même instant.

Une journée anormale a rendu le problème visible. Un lien d’accès avait été remplacé après la copie de la configuration ; une table de transfert plus récente connaissait déjà le nouveau lien. Les préfixes client ne rejoignaient plus les deux identités. Une fois ce changement réel réconcilié, les échecs sont revenus vers le niveau des autres journées. Le désaccord n’était pas un défaut cosmétique de données : il signalait que les sources décrivaient deux états différents du réseau.

Couverture élevée, certitude incomplète

Sur quatre journées de novembre 1999, l’agrégation a généralement attribué plus de 98 % des octets vus sur les peerings à une forme de demande. Pour le trafic sortant, au moins une entrée candidate était trouvée pour plus de 99,3 % des octets. Pourtant, environ 35 à 45 % des octets sortants avaient d’abord plusieurs entrées possibles.

Le routage en supprimait une partie. Selon les essais, environ un quart à un tiers du volume ambigu pouvait être ramené à une entrée unique. Les accès redondants d’un même client dans une même ville restaient souvent indiscernables, sans forcément changer beaucoup le chemin intérieur. Au terme du calcul, environ 2,5 à 4 % des octets sortants ne pouvaient toujours pas être associés à une ou plusieurs demandes point-à-multipoint.

Ces taux décrivent quatre jours d’un réseau de 1999. Ils ne sont pas une norme contemporaine. Leur intérêt est ailleurs : une couverture presque complète n’efface pas l’ambiguïté, et une faible proportion de résidus peut concentrer précisément les changements de routage qu’il importe de comprendre.

L’analyse a aussi fait apparaître un petit nombre de demandes très lourdes, des profils horaires différents et une certaine stabilité d’un jour à l’autre parmi les plus importantes. Mesurer sélectivement les grands flux pouvait donc apporter beaucoup. Mais les concentrer sur les mêmes liens augmentait aussi la gravité d’une erreur de routage ou du changement de comportement d’une seule source.

Une preuve datée, pas une photographie parfaite

Le parcours d’Anja Feldmann associe analyse de trafic, modélisation et routage parce que cette matrice avait besoin des trois. Une mesure sans état de routage ne pouvait prévoir une modification. Un modèle de routage sans demande observée calculait des chemins pour un trafic imaginaire. Une configuration périmée pouvait expliquer avec précision un réseau qui n’existait plus.

La matrice restait une construction, marquée par ses dates, ses pertes et ses choix d’agrégation. Elle était néanmoins plus honnête et plus utile qu’un compteur isolé : elle donnait une origine possible à la charge, permettait de tester un autre chemin et conservait la frontière entre ce qui avait été vu et ce qui avait été déduit.

Une observabilité digne d’une décision doit garder cette frontière. Le total brut, l’état de route, l’identité de l’instantané, le facteur de correction, les candidats non départagés et l’écart avec un compteur indépendant sont autant de reçus. Sans eux, la carte montre où le réseau souffre. Elle ne permet pas encore de savoir ce que la prochaine décision lui fera.

Sources