Le réseau a une mémoire
Reconstruire ce que le réseau croyait à 14 h 02, et la différence entre ce qui a changé et ce que vous avez appris
Michel Wijnberg
Tous les outils de cette série répondent jusqu’ici à des questions sur le maintenant. C’est le mauvais temps grammatical pour les deux moments où un ingénieur a le plus besoin d’aide.
Le premier est pendant un incident : le réseau se comporte mal, et ce dont vous avez besoin n’est pas son état actuel mais son état d’il y a vingt minutes, avant que quelqu’un ne commence à réparer. Le second est après : le réseau va de nouveau bien, tout le monde a une théorie, et personne ne peut produire la topologie telle qu’elle était au moment de la casse.
La réponse d’Osprey est une horloge.
Ce n’est pas la relecture d’un enregistrement. Chaque élément de ce canvas a été
reconstruit pour un horodatage : les équipements, les liens, leurs coûts et leurs
états, les appartenances d’area. Le curseur en dessous indique Jul 29, 14:02 et
(30/36) : le trentième de trente-six états de topologie distincts dans la fenêtre
de 24 heures sélectionnée.
Chaque point sur cette piste est un moment où le réseau était réellement différent.
Tout outil de supervision conserve un historique, cette phrase a donc besoin d’un tranchant plus net. Ce qu’ils conservent, ce sont des mesures : le CPU était à 83 %, l’interface faisait 4 Gbit, l’interrogation a réussi. Ce sont des relevés pris sur le réseau, et à 14:02 ils vous disent qu’un équipement était occupé. Ils ne peuvent pas vous dire ce qu’il croyait. Ce qu’Osprey conserve, c’est l’état : quelles adjacences existaient, quelles routes étaient installées et avec quelle métrique, à quelles areas un routeur appartenait, quels chemins BGP étaient sélectionnés et pourquoi. La différence apparaît dès que vous posez une vraie question. Un historique de mesures peut vous dire qu’un lien était saturé à 14:02. Un historique d’état peut vous dire qu’il était saturé parce qu’un ABR avait retiré un summary quatre minutes plus tôt et que la moitié de la région prenait soudain le chemin long. L’un est un symptôme horodaté. L’autre est le raisonnement du réseau lui-même, conservé.
Des instantanés qui n’existent que s’il s’est passé quelque chose
L’implémentation naïve écrit un instantané sur minuterie. Toutes les cinq minutes, vider la topologie. C’est simple, et cela produit une base essentiellement remplie de copies identiques, plus une limite de résolution au-delà de laquelle vous ne voyez rien.
Osprey écrit un instantané quand la topologie change, et jamais autrement.
Chaque événement de topologie venant d’un collecteur est d’abord haché :
// computeTopologyHash computes an FNV-64a hash over the topology snapshot data.
// Uses addition accumulation of per-element hashes for order-independence.Les équipements contribuent leur router ID et leurs bits ABR/ASBR, les liens une paire de routeurs normalisée en direction plus les deux coûts et leur état, les réseaux stub et les interfaces les leurs. L’accumulation est additive pour que le hachage ne dépende pas de l’ordre d’arrivée des éléments : deux collecteurs rapportant la même area dans un ordre différent doivent produire le même hachage, sinon chaque relevé ressemblerait à un changement.
Le hachage est comparé au dernier pour cette area, en mémoire. Égal : rien n’est écrit. Différent : une ligne d’instantané est insérée.
Le résultat est une chronologie dense en information par construction. Mon laboratoire a produit sur les 30 derniers jours 478 instantanés sur 51 areas : environ 16 par jour sur l’ensemble du parc, chacun étant une vraie différence. Les points du curseur ne sont pas des échantillons. Ce sont des événements.
Cela veut aussi dire qu’une area stable peut passer de longues heures sans ligne, et c’est correct plutôt qu’un trou : il ne s’est rien passé, il n’y a donc rien à enregistrer. L’instantané le plus proche à ou avant votre horodatage est l’état à cet horodatage.
Le voyage dans le temps n’est pas une fonctionnalité
L’horloge est la partie visible. Ce qui la rend utile, c’est qu’une vingtaine de
points d’API acceptent le même paramètre at= et répondent à cet instant : le graphe
de topologie, le navigateur de LSDB, le calcul de chemin, les arbres SPF, les RIB par
routeur, les routes inter-area et externes, les entrées ASBR, les interfaces, les
réseaux stub, les voisins BGP, les meilleurs chemins BGP, les chemins reçus par
voisin.
BGP reçoit un traitement plus fort que les instantanés, parce que BGP change bien
plus souvent que la topologie. Il est stocké comme un journal de changements
bitemporel : chaque meilleur chemin, chaque session de voisinage et (en option)
chaque entrée de RIB reçue est un intervalle avec un valid_from et un valid_to,
où un valid_to ouvert signifie « toujours vrai ». Poser une question à l’instant T
devient alors un prédicat plutôt qu’une reconstruction : valid_from <= T AND (valid_to IS NULL OR valid_to > T).
Deux détails là-dedans sont ceux qui ont demandé le plus de temps à faire correctement, et les deux consistent à ne pas enregistrer des choses :
- Le tremblement des intervalles est supprimé par un hachage d’attributs qui exclut délibérément la métrique IGP et l’équipement de saut suivant résolu. Ceux-ci changent dès que l’IGP reconverge, et s’ils ouvraient un nouvel intervalle, chaque préfixe BGP du réseau semblerait battre à chaque fois qu’un coût de lien sans rapport bouge.
- Un voisin qui tombe est enregistré comme un trou de supervision, pas comme un retrait massif. Quand une session BMP tombe, le routeur n’a pas retiré cent mille préfixes. On a simplement cessé de m’en parler. L’écrire comme un retrait fabriquerait le plus gros événement de routage de l’histoire du réseau, chaque fois qu’une session de supervision hoquette.
Dans les deux cas, l’implémentation facile invente un événement. Un historique qui invente des événements est pire que pas d’historique, parce que vous allez enquêter dessus.
Simuler dans le passé
Les deux modes se composent, et c’est ce que je préfère dans le produit.
Vous pouvez entrer dans le voyage dans le temps, positionner l’horloge, puis entrer
en simulation. Le canvas porte un filigrane SIMULATION @ <timestamp>, et le « et
si » tourne sur la topologie telle qu’elle existait à ce moment-là.
Ce qui veut dire que la question que vous pouvez poser est :
Cette panne aurait-elle été survivable, étant donné le réseau tel qu’il était réellement à 14 h 02 ?
Pas face à la topologie d’aujourd’hui, depuis réparée, remétrée et étendue. Face à celle qui était réellement là. Pour le travail d’après-incident, c’est la différence entre une réponse défendable et une réponse plausible.
Elle respecte aussi ses propres limites. L’analyse de panne de voisin BGP à un instant passé exige que l’historique RIB complet ait été enregistré pour cette portée ; là où il ne l’a pas été, le résultat n’est pas une approximation silencieuse mais une omission déclarée :
BGP effects (peer failure, hot-potato exit shifts, BGP traffic) are not evaluated at this time: no full-RIB history (history_mode=‘full’) is recorded for the scope. Enable full history mode on a BMP target to time-travel BGP.
Ce message nomme l’entrée manquante et le réglage qui la fournirait. C’est un message sur lequel vous pouvez agir.
Ce qui n’est pas dans le passé, dit à voix haute
Plusieurs choses n’ont réellement pas d’historique, et les points d’API qui les touchent le disent au lieu de servir discrètement des données vivantes déguisées en données historiques.
Demandez au navigateur de LSDB un moment passé et la réponse porte :
Topology and route LSAs reflect the selected time; LSA header metadata (age/seq/ checksum) is not historized and shows live values.
Demandez un chemin interdomaine à un moment passé et, seulement là où la réponse s’est réellement appuyée sur des preuves vivantes, l’explication gagne des étapes supplémentaires :
Time travel: L2 detail is live: L2/port annotations on this path reflect current LLDP/CDP wiring, not the selected time. L2 adjacency is not historized.
Time travel: entry resolved via current router-id: identity attributes (router-id, local address) are not historized and were borrowed from the live session record.
La conditionnalité compte. Un assemblage prouvé entièrement par l’historique ne porte aucune de ces notes, si bien que les notes veulent dire quelque chose quand elles apparaissent. Un avertissement général « certaines données peuvent être vivantes » sur chaque vue historique serait techniquement vrai, définitivement ignoré et inutile.
Il y a une limite de plus que j’énonce franchement parce que vous la découvririez sinon dans la confusion : la coloration par utilisation des liens est désactivée pendant le voyage dans le temps. La carte de chaleur du trafic reste vide plutôt que de vous montrer la charge actuelle sur une topologie historique. C’est le comportement sûr et le mauvais. Vide se lit « pas de trafic » là où il devrait se lire « non disponible à cet instant ». Le lecteur qui corrigerait cela est planifié, pas construit.
La différence entre ce qui a changé et ce que vous avez appris
Le voyage dans le temps a un rapport compagnon : comparer deux moments et lister les différences.
Sur les dernières 24 heures dans l’AS 200 : aucun équipement ajouté, retiré ou
modifié. Aucun lien ajouté ou retiré. Et 56 réseaux stub ajoutés, chacun étant une
boucle locale IPv6 en /128.
Cela ressemble à un changement de réseau. Ce n’en est pas un.
J’ai vérifié quand ces 56 préfixes sont entrés pour la première fois dans la base, et
chacun est arrivé entre 10:00:49 et 10:01:14 ce matin : une fenêtre de
25 secondes. Aucun réseau ne reconfigure 56 boucles locales sur 64 routeurs en
25 secondes. Ce qui s’est passé, c’est une passe de découverte : ces préfixes étaient
dans la base OSPFv3 depuis le début, et c’est le moment où Osprey a commencé à les
enregistrer.
Cette distinction mérite un nom, parce que confondre les deux envoie les gens chasser un changement qui n’a jamais eu lieu :
Un diff de topologie vous dit ce que le modèle a appris. Ce n’est pas la même chose que ce que le réseau a fait.
Parfois les deux coïncident : un lien tombe, le modèle enregistre un lien qui tombe. Parfois non, et l’indice est en général la forme des horodatages : les vrais changements de réseau arrivent au rythme de la convergence protocolaire, et les changements de modèle au rythme d’un cycle d’interrogation. Cinquante-six préfixes identiques en 25 secondes, c’est un cycle d’interrogation déguisé en changement.
Un produit d’observabilité incapable de vous dire lequel des deux vous regardez finira par coûter un après-midi à quelqu’un. Osprey ne l’étiquette pas automatiquement. Le diff montre ce que le modèle a enregistré, et le raisonnement ci-dessus est le mien, pas celui de l’outil. Mais chaque ligne porte les horodatages dont vous avez besoin pour trancher vous-même, et c’est le minimum qu’un outillage honnête vous doit, selon moi.
Où s’arrête cette série
Trois séries, et en réalité un seul argument, atteint par trois directions.
La série 1 portait sur la question de savoir si le modèle est vrai : modéliser le réseau tel qu’il est réellement, l’observer sans en faire partie, reproduire l’acheminement saut par saut, et refuser de deviner.
La série 2 portait sur la question de savoir si les preuves sont classables : tenir plusieurs vérités à la fois, noter des sources contradictoires, trouver ses propres erreurs avant ses clients.
La série 3 portait sur ce que cela vous apporte : un modèle assez correct pour raisonner avec. Casser quelque chose et voir ce qui se passe. Demander ce qui dépend de quoi. Estimer ce qu’on ne peut pas mesurer, et dire qu’on estime. Demander ce que le réseau croyait une heure avant de casser.
Rien de tout cela ne fonctionne sur un modèle auquel vous ne faites pas confiance. Chaque refus honnête de la série 1 et chaque preuve graduée de la série 2 existent pour que les réponses de la série 3 veuillent dire quelque chose : un « et si » bâti sur une topologie fictive à 9 % n’est pas un outil de planification, c’est un générateur de nombres aléatoires avec un joli canvas.
Le billet huit a donné à cet argument sa forme la plus courte : un moteur de topologie est un compilateur d’état réseau, entrée désordonnée et contradictoire, modèle déterministe en sortie, et les routeurs eux-mêmes comme oracle. Les compilateurs se jugent à la conformité plutôt qu’à la plausibilité, et chaque refus de ces douze billets est ce que coûte la conformité sur les cas où la réponse n’est pas disponible.
Posez le modèle correctement. Dites comment vous le savez. Et alors, seulement alors, commencez à lui poser des questions.
La série complète : Confiance : Trois IGP, une seule carte · Empreinte nulle · La vérité saut par saut · Ce qu’Osprey refuse de deviner. Construire la vérité : Le même routeur, trois vérités différentes · Quand le réseau se contredit lui-même · Le jour où ma topologie m’a menti · Les tests unitaires d’un ingénieur réseau. De voir à raisonner : Et si je casse ça ? · Le rayon d’impact · Estimer ce qu’on ne peut pas mesurer · celui-ci.