Et si je casse ça ?

Un modèle auquel vous faites confiance ne vaut la peine que si vous pouvez lui poser des questions qu'on ne lui a jamais posées

22 août 2026 Michel Wijnberg

Les huit premiers billets de cette série portaient sur la justesse du modèle : découvrir le réseau sans en faire partie, reproduire l’acheminement saut par saut, refuser de deviner, et découvrir à la dure que mon propre outil dessinait de la fiction.

Tout cela est de la préparation. Un modèle de réseau qui est seulement exact est une photographie très coûteuse. La raison d’y consacrer cet effort, c’est de pouvoir lui poser la question qu’on ne peut pas poser au vrai réseau :

Et si je casse ça ?

Cette question décide des fenêtres de maintenance. Quelqu’un doit dire si retirer une carte à 03:00 est survivable, et d’ordinaire il répond à partir d’un modèle mental et du souvenir de la dernière panne. Ce qui suit n’est pas intéressant parce qu’Osprey possède un simulateur. C’est intéressant parce que la panne n’a plus besoin de se produire avant qu’on puisse raisonner dessus.

Sept choses que vous pouvez changer

Le mode simulation d’Osprey prend le modèle vivant, le clone, applique des mutations et recalcule. La liste complète de ce qu’il vous laisse changer est courte, et cette brièveté est délibérée :

Mutation	Ce qu’elle fait
`link_failure`	Couper un lien
`node_failure`	Arrêter un routeur
`cost_change`	Remétrer un lien, aller et retour indépendamment
`hypothetical_link`	Ajouter un lien qui n’existe pas, avec un coût et un débit
`hypothetical_node`	Ajouter un routeur qui n’existe pas
`srlg`	Faire tomber un groupe de risque partagé : une action, N pannes de liens corrélées
`peer_failure`	Couper une session BGP

Tout le reste est rejeté avec unknown mutation type. Il n’y a pas de mutation de restructuration d’areas, pas de mutation de redistribution et pas de mutation de panne en cascade, parce que je ne pouvais implémenter aucune d’entre elles sans inventer des données. J’y reviens.

Un câble, et ce que le réseau en fait

Voici un cas réel du laboratoire. nrt1-cr1 ↔ sea1-cr1 est un lien de backbone transpacifique dans l’AS 200, coût 10 sous OSPFv2, l’un des 275 liens qu’Osprey tient sur les deux instances OSPF de ce tenant. J’ai fait un clic droit dessus et choisi Simulate Failure :

L'onglet Impact de la simulation : 0 isolé, 56 chemins modifiés, 0 nouveau SPOF

Lisez les trois nombres en haut. Rien n’est devenu injoignable. 56 chemins ont changé. Aucun nouveau point de défaillance unique n’est apparu. Toute l’évaluation a pris 57 ms, côté serveur.

Lisez maintenant l’en-tête Failed Links, parce qu’il fait quelque chose que les gens ratent : 2 links. J’ai cliqué un câble et Osprey a coupé deux liens, parce que ce câble porte OSPFv2 et OSPFv3 comme deux instances de protocole indépendantes avec deux coûts indépendants. Couper le câble le coupe dans les deux. Un outil qui modélise une arête par câble doit décider laquelle de ses deux vies il met fin.

La partie intéressante est la ventilation de ces 56 :

L'onglet Paths : 15 chemins au coût augmenté, 41 reroutés à coût identique

15 augmentés : le chemin est devenu plus cher. sea1-cr1 → nrt1-cr1 passe du coût 1 au coût 11, le lien direct remplacé par un chemin à trois sauts.
41 reroutés : le chemin a changé de sauts et le coût n’a pas bougé du tout.

C’est ce second nombre qu’il faut fixer. Quarante-deux paires source/destination ont pris une autre route à travers le réseau sans rien payer, parce qu’une alternative à coût égal était déjà là. Voilà à quoi ressemble la redondance quand on l’exprime en mesure plutôt qu’en adjectif. « Nous avons des chemins diversifiés » est une affirmation. « 41 des 56 paires affectées reroutent à coût identique » est un nombre, et c’est le nombre qui vous dit si la fenêtre de maintenance doit être à 3 h du matin.

Rien de tout cela n’a été tapé dans un routeur. Le laboratoire n’a pas perdu de lien. J’ai interrogé le modèle.

Le refus en haut de l’écran

Regardez maintenant la bannière ambre de la première capture, parce que c’est un aveu, et c’est la raison pour laquelle je fais confiance au reste du panneau :

simulated paths are shown as an SPF projection (source-rooted least-cost tree) so before and after stay comparable; the live path panel shows the hop-by-hop forwarding chain, which can differ where an intermediate router’s own routing table disagrees with the source’s view

Le billet trois soutenait qu’un couloir enraciné à la source est le mauvais modèle de l’acheminement IP, appuyé par une mesure : 360 des 2 839 paires de routeurs inter-area avaient un couloir contenant un saut qu’aucun paquet ne prendrait jamais. J’ai remplacé ce moteur par un autre qui parcourt la table de routage propre de chaque routeur, et je l’ai validé sur les 4 032 paires.

Et puis, en simulation, je choisis délibérément de ne pas l’utiliser.

La raison est dans le code, et c’est la phrase dont je suis le plus fier dans ce produit :

// The panel shows the hop-by-hop forwarding chain (path_chain.go): every
// router's OWN routing table, read from the per-area LSDBs. A what-if topology
// has no such tables. The Type-3 summaries the surviving ABRs would
// re-originate after the mutation are exactly the thing that cannot be
// synthesised, and inventing them would make the simulation's numbers agree with
// nothing. So both simulation sides stay on the source-rooted SPF projection,
// consistently with each other, and say so. A labelled projection is honest; a
// baseline that disagrees with the baseline is not.

Parcourir la table propre de chaque routeur suppose de savoir ce que la table de chaque routeur serait après le changement. En OSPF cela dépend des summary-LSA de type 3 que les ABR survivants réémettraient : des LSA qui n’existent pas, puisque la panne n’a pas eu lieu. Je peux les deviner. Je ne peux pas les deviner correctement, et une chaîne saut par saut bâtie sur des summaries devinés aurait toute l’autorité du moteur validé et rien de sa validation.

Les deux côtés de la comparaison restent donc sur la projection clairement étiquetée. L’image « avant » est délibérément dégradée pour qu’elle corresponde encore à l’image « après ». Un « 56 chemins modifiés » qui vaut en réalité « 36 changements réels plus 20 artefacts dus au fait que les deux côtés utilisent des moteurs différents » n’est pas un diff. C’est du bruit avec un nombre dessus.

EIGRP : le plafond, ce sont mes données, pas le protocole

Cassez quelque chose dans le locataire EIGRP et Osprey s’arrête au lieu de projeter :

the simulated change affects the observed EIGRP chain (forward and reverse). Osprey cannot predict DUAL re-convergence: the topology tables it reads carry the DUAL distances, not the metric components (bandwidth, delay) a recomputation needs. After a real event the live view shows the new chain.

EIGRP n’a pas de base à état de liens sur laquelle recalculer. Ce qu’Osprey a, c’est la table de topologie propre à chaque routeur, lue depuis CISCO-EIGRP-MIB, et ces douze colonnes portent les distances DUAL (feasible distance, computed distance, reported distance), pas les composantes à partir desquelles les distances ont été construites.

Pour recalculer DUAL après un changement, il faut la bande passante minimale, le délai total, la fiabilité, la charge, la MTU et le nombre de sauts. Ces valeurs existent sur l’équipement ; j’ai vérifié, sur e-ams1-cr1, avec show ip eigrp topology 10.64.0.0/15. Elles ne sont simplement pas dans la table MIB qu’Osprey lit.

Cette distinction est écrite exprès dans le commentaire du code :

// Scoped to what Osprey READS, deliberately not to what SNMP can carry: … A future
// CLI enricher could lift part of this ceiling, so the sentence must not read as a
// permanent property of the protocol.

Il y a une vraie différence entre « ce protocole ne peut pas être simulé » et « je ne collecte pas actuellement les entrées », et un produit qui brouille les deux vous dit discrètement de ne plus poser la question. Ici c’est un plafond de collecte de données, et il est levable. Quand je le lèverai, le message disparaîtra.

Il y a en dessous une règle plus petite et plus fine. Si la mutation est une pure suppression (une panne de lien ou de nœud), et que l’élément supprimé n’est manifestement pas sur la chaîne observée, Osprey continue d’afficher la vraie chaîne et dit pourquoi : “observed live EIGRP chain: the simulated failure does not touch it (EIGRP re-convergence itself is not modelled)”. Retirer de la capacité ailleurs ne peut jamais améliorer un chemin à vecteur de distance qui ne l’utilisait pas. Mais un changement de coût ou un nouveau lien peut attirer un chemin de n’importe où, ceux-là comptent donc toujours comme touchant. Le moteur refuse précisément quand il le doit, pas par principe.

Ce qui n’est pas dans la liste des mutations, et pourquoi

Les sept mutations sont ce que j’ai pu implémenter sans fabriquer d’entrées. Celles qui manquent manquent pour des raisons énoncées :

Restructuration d’areas. Déplacer un ABR ou redessiner une frontière d’area change quels summary-LSA existent tout court. Ce n’est pas une mutation de la topologie, c’est une autre topologie.
Changements de redistribution. Ils dépendent de route-maps et de prefix-lists qu’Osprey ne voit pas. Je modéliserais une politique que je ne peux pas lire.
Pannes en cascade. Prédire la seconde panne exige une dynamique de files d’attente et de TCP qu’un outil de topologie n’a pas à prétendre modéliser. Signalez le risque ; ne prédisez pas la cascade.

Chacune se démontrerait magnifiquement. Chacune serait un nombre avec rien derrière.

Le fond de l’affaire

La simulation est l’endroit où un produit de topologie soit rentabilise le travail de modélisation, soit l’expose. Chaque raccourci pris dans le modèle de données ressurgit ici sous forme de réponse fausse et confiante, parce qu’un « et si » n’a pas de vérité de terrain à laquelle se confronter. La panne n’a pas eu lieu, donc rien ne peut vous contredire. C’est exactement pourquoi c’est la fonctionnalité où la prudence vaut le plus.

La version honnête est moins impressionnante par capture d’écran et bien plus utile à 3 h du matin : sept choses que vous pouvez changer, quatre nombres qui en sortent, et une bannière expliquant quel moteur les a produits.

Ensuite : un lien tombe, mais quelles parties du réseau en dépendaient vraiment ? Le rayon d’impact.