Le rayon d'impact
Chaque lien et chaque routeur testés d'un coup, et pourquoi la théorie des graphes ramène cela à 13 millisecondes
Michel Wijnberg
« Et si je casse ça ? » est une question sur une seule chose. La question à laquelle une architecte a réellement besoin d’une réponse est l’inverse, et elle est bien plus difficile :
Dans tout ce réseau, quelles parties comptent ?
Vous n’y arriverez pas en cliquant les liens un par un. L’AS 200 de mon laboratoire a 275 liens et 64 routeurs. Tester chaque panne à la main, c’est 339 expériences, et il faut tout refaire à chaque changement de topologie.
Osprey les fait donc toutes d’un coup. Ce que cela rapporte, c’est une liste courte : sur 339 choses susceptibles de tomber, la poignée qui vous coûterait vraiment quelque chose. C’est la différence entre une revue de résilience que l’on planifie pour le trimestre prochain et une que l’on lance avant d’approuver un changement.
Chaque lien, chaque routeur, treize millisecondes
Lisez l’en-tête : “1 with impact in 13ms”, et en dessous l’explication de ce qui a été testé : “Links whose failure causes device isolation. Redundant links omitted.”
Chaque lien du tenant a été évalué. Exactement un d’entre eux,
mia1-cr1 ↔ mia1-gw1, isole quoi que ce soit, et ce qu’il isole est un routeur :
mia1-gw1. Basculez sur Node Failures et la réponse est l’image miroir : sur
64 routeurs, exactement un (mia1-cr1) en laisse exactement un autre en rade.
C’est le résultat que veut une architecte : pas une liste de 275 lignes à lire, mais l’affirmation que 274 d’entre elles sont manifestement sans intérêt.
La même faiblesse, trouvée trois fois, à travers trois protocoles
La vue structurelle du même fait a son propre rapport :
64 équipements, 275 liens analysés, 1 point d’articulation (mia1-cr1,
172.16.4.31) et 1 lien-pont. Un point d’articulation est un sommet dont le
retrait augmente le nombre de composantes connexes, le nom en théorie des graphes de
« si ce routeur meurt, le réseau se scinde ».
Voici la partie que je n’avais pas prévue et que je préfère. J’ai lancé le même rapport sur les deux autres locataires :
| Locataire | IGP | Point d’articulation | Lien-pont |
|---|---|---|---|
| Harrier-Broadband | OSPFv2 | mia1-cr1 | mia1-cr1 ↔ mia1-gw1 |
| Kestrel-Dynamics | EIGRP | e-mia1-cr1 | e-mia1-cr1 ↔ e-mia1-gw1 |
| Merlin-Carrier | IS-IS | i-mia1-cr1 | i-mia1-cr1 ↔ i-mia1-gw1 |
Trois opérateurs. Trois IGP différents. Trois chemins de découverte complètement
séparés : parcours de LSDB OSPF, tables de voisins CISCO-EIGRP-MIB, LSP IS-IS. La
même faiblesse structurelle dans chacun, au même endroit.
L’explication honnête est que j’ai bâti le laboratoire à partir d’un gabarit et que
j’ai donné à Miami une passerelle mono-attachée trois fois. Mais c’est exactement ce
qui en fait un contrôle utile : la même erreur physique, décrite à Osprey via trois
modèles protocolaires sans rapport, a produit les mêmes trois réponses. Si
l’extraction de topologie IS-IS avait un bug, i-mia1-cr1 est l’endroit où le
désaccord se serait manifesté.
Je ne savais pas que c’était dans le laboratoire avant que l’outil ne me le dise. C’était là depuis des semaines, dans un laboratoire que j’ai construit spécifiquement pour attraper des choses.
C’est la partie qu’il faut distinguer de la théorie des graphes, car la théorie est la moitié banale. Points d’articulation et ponts sont dans les manuels, et n’importe quel outil sait les calculer sur n’importe quel dessin. Ce qui décide si la réponse veut dire quelque chose, c’est ce que sont les sommets et les arêtes. Le graphe d’Osprey n’est pas un schéma entretenu par quelqu’un : il est reconstruit à partir de ce que les routeurs inondent eux-mêmes, si bien qu’un pont y est un énoncé sur l’acheminement et non sur une image. Lancez le même algorithme sur un vieux fichier Visio et vous obtiendrez les mêmes formes et rien de la vérité.
Pourquoi la réponse arrive avant que vous ayez lâché la souris
Treize millisecondes pour 275 scénarios de panne n’est pas le fruit d’un parallélisme malin. C’est le fruit du fait de ne pas faire le travail.
Un lien dont le retrait déconnecte un graphe est un pont : une arête qui n’est sur aucun cycle. L’algorithme de recherche de ponts de Tarjan les identifie tous en un seul parcours en profondeur, O(V+E), pour tout le graphe d’un coup. Et un lien qui n’est pas un pont ne peut absolument pas isoler quoi que ce soit : par définition il est sur un cycle, il existe donc un autre chemin.
L’évaluation trouve donc d’abord les ponts, et ne simule que ceux-là :
// Precompute bridges in O(V+E). These are the only links that can
// cause unreachable devices when removed.
bridgeLinks := spf.FindBridges(baselineMerged)Puis elle retire encore une classe. Si deux routeurs sont reliés par plusieurs liens parallèles, aucun ne peut être un pont au sens qui compte, puisque en couper un laisse les autres :
// Parallel links: if a device pair has multiple links, failing any one
// cannot disconnect them. Remove such links from the bridge set.274 liens sont éliminés par un théorème plutôt que par un test de joignabilité. Un lien est simulé. C’est tout le tour de passe-passe, et c’est pourquoi la réponse arrive avant que vous n’ayez relâché la souris. Sur un réseau cent fois plus grand, c’est toujours un parcours plus une poignée de vérifications.
La théorie des graphes n’est pas décorative ici. C’est la différence entre un rapport qu’on lance et un rapport qu’on consulte d’un coup d’œil.
Ce que « critique » veut dire quand rien n’est critique
L’onglet Critical Pairs répond à une question un cran plus loin : quels deux liens, dont aucun n’est un point de défaillance unique, sont fatals ensemble ?
C’est une classe de risque réellement vicieuse. Aucun des deux liens n’apparaît dans un rapport SPOF. Aucun seul ne fait rien. Prenez les deux (même fourreau, même carte, même fenêtre de maintenance) et le réseau se scinde.
Les trouver signifie, pour chaque arête non-pont, la retirer et relancer la détection de ponts sur ce qui reste. C’est O(L·(V+E)), et c’est la chose la plus coûteuse du rapport.
Dans les trois locataires la réponse est zéro, et le panneau le dit en toutes lettres :
No critical link pairs detected — your topology has good redundancy.
Un zéro qui a demandé un vrai travail de calcul vaut plus qu’une longue liste. Celui-ci dit : il n’existe dans ce réseau aucune paire de liens dont la perte simultanée le partitionne, et cela a été vérifié exhaustivement plutôt que supposé.
Le rayon d’impact n’est pas que de la topologie
La structure est une forme de dépendance. L’autre est la joignabilité, et elle se mesure en espace d’adressage :
| AS voisin | Voisins | Préfixes | Espace IP | Équivalent CIDR |
|---|---|---|---|---|
| 100 | 2 | 3 | 131 328 | /15 |
| 300 | 2 | 3 | 131 074 | /15 |
Trois préfixes, ça ne semble pas beaucoup, jusqu’à ce que ce soit rendu comme 131 328 adresses, soit un équivalent /15, joignables uniquement via l’AS 100. Les comptes de préfixes sont un très mauvais indicateur d’exposition (un /15 et un /32 comptent tous deux pour « 1 »), le rapport convertit donc en espace d’adressage puis en équivalent CIDR, qui est l’unité dans laquelle une architecte raisonne réellement.
À côté, le rapport croise chaque paire de liens critiques avec les groupes SRLG auxquels appartiennent ses membres, de sorte que deux liens qui paraissent indépendants sur la carte mais partagent un fourreau sont signalés comme corrélés plutôt que diversifiés.
Ce qui m’amène au manque que je préfère énoncer plutôt que vous laisser le trouver.
La partie honnête et inachevée
La prise en charge SRLG d’Osprey est complète dans toutes les directions sauf une. Vous pouvez définir des groupes, y rattacher des liens, faire tomber un groupe entier comme une seule mutation de simulation, et voir la corrélation de risque partagé dans le rapport de dépendances. Ce que vous ne pouvez pas faire, c’est les découvrir.
Rien n’alimente la table SRLG. Chaque groupe est saisi à la main. Osprey stocke les sous-TLV d’ingénierie de trafic de la RFC 5305 qu’il voit en IS-IS sous forme d’octets bruts, mais ne décode pas encore le sous-TLV SRLG : un réseau qui annonce déjà ses groupes de risque partagé dans son IGP n’en tire donc aucun bénéfice.
Le consommateur a été construit avant la source. C’est le mauvais ordre, c’est sur la feuille de route, et jusqu’à ce que ce soit fait, la description honnête de la fonctionnalité est « simulation SRLG, à partir des groupes que vous lui indiquez », et non « découverte SRLG ».
Je préfère écrire cette phrase que laisser quelqu’un la découvrir pendant une évaluation.
Pourquoi c’est le rapport que je lancerais en premier
Si j’héritais d’un réseau demain, la première chose que je voudrais ne serait pas une carte. Ce serait la réponse à trois questions :
- Quelles pannes uniques isolent réellement quelque chose ? (Un lien. Un routeur.)
- Quelles paires de pannes le font, qu’aucun rapport de panne unique ne montrerait ? (Aucune : vérifié, pas supposé.)
- Combien d’espace d’adressage se trouve derrière chaque dépendance externe ? (Un /15 par AS voisin.)
Les trois sont calculables à partir d’un modèle déjà correct, en bien moins d’une seconde, sans toucher un routeur. C’est tout l’argument en faveur de quatre billets consacrés à d’abord bien poser le modèle : un modèle exact n’est pas le produit, c’est le substrat sur lequel tournent les questions utiles.
Ensuite : le nombre que ce billet a discrètement évité. Combien de trafic se déplace réellement quand ce lien tombe, et pourquoi mon laboratoire ne peut pas me le dire. Estimer ce qu’on ne peut pas mesurer.