Ce qu'Osprey refuse de deviner
La chose la plus importante que j'aie construite est un ensemble de refus
Michel Wijnberg
Un outil réseau qui devine est pire qu’un outil qui admet son ignorance, et la raison n’est pas philosophique. Elle est opérationnelle.
Si un outil dit « je ne sais pas », vous allez vérifier. S’il produit une réponse plausible, vous agissez dessus. Et rien à l’écran ne distingue une réponse correcte d’une réponse confiante : le mode de défaillance n’est donc pas « l’outil s’est trompé », mais « l’outil s’est trompé et je n’avais aucune raison de vérifier ».
Osprey a donc une règle qui prime sur tous mes instincts de produit : énoncer la preuve, ou énoncer qu’il n’y en a pas. Jamais d’interpolation. Jamais un espace réservé qui ressemble à des données.
Voici à quoi cela ressemble dans un produit réellement livré.
1. « Je ne peux pas calculer ce chemin de la bonne façon »
Le billet précédent portait sur la chaîne d’acheminement saut par saut, qui suit la table de routage propre de chaque routeur au lieu de tracer un couloir enraciné à la source, validée exactement face aux 4 032 paires de routeurs de l’AS 200.
Ce moteur fonctionne pour OSPFv2. Il ne fonctionne pas pour IS-IS, et Osprey le dit au lieu de retomber discrètement en arrière :
4. Hop-by-hop forwarding chain unavailable Showing the source’s own shortest-path view, which every intermediate router may legitimately disagree with. Osprey does not model this protocol’s inter-area reachability hop-by-hop (IS-IS carries inter-level reachability differently from OSPF and has no Type-3 equivalent to persist, so Osprey stores nothing from which L1↔L2 route leaking could be reconstructed. An L1-only source in particular forwards on the attached-bit default toward its nearest L1/L2 router, not by end-to-end cost; EIGRP has its own observed chain).
Trois choses à propos de ce message.
Il nomme le modèle qui a répondu : la vue en plus court chemin de la source, pour que vous sachiez lequel des deux moteurs vous regardez. Il nomme la raison : Osprey ne stocke rien à partir de quoi reconstruire la fuite de routes entre L1 et L2. C’est une limite du modèle d’Osprey, pas du protocole : IS-IS n’a pas de summary-LSA de type 3 parce qu’il n’en a jamais eu besoin, portant la joignabilité inter-niveaux dans les LSP L2 et le bit attached. Et il nomme la conséquence concrète, qui est la partie qui vous mordrait vraiment : une source L1 seule n’achemine pas du tout selon un coût de bout en bout. Elle suit le bit attached vers son routeur L1/L2 le plus proche, conformément à l’ISO 10589. Son véritable premier saut peut n’avoir aucun rapport avec le chemin dessiné.
Le chemin reste affiché, parce qu’une vue en plus court chemin est réellement utile. Elle n’a simplement pas le droit de se faire passer pour la réponse la plus forte.
La même discipline s’applique à OSPFv3, à une portée ne contenant qu’une partie des areas d’une instance, aux areas portant un lien virtuel, et aux routeurs vivant dans deux instances de protocole capables toutes deux de porter la famille d’adresses. Chacun reçoit sa propre raison nommée. Aucun ne rétablit silencieusement l’ancienne image.
2. « Ce nombre ne voudrait rien dire »
EIGRP n’est pas un protocole à état de liens. Il n’y a pas de base à rejoindre, pas de SPF à faire tourner et, surtout, aucune manière sensée d’additionner des coûts de saut, parce que la métrique composite d’EIGRP décrit un chemin entier plutôt qu’un lien isolé.
Osprey n’imprime donc pas de total :
Observed EIGRP forwarding chain EIGRP has no link-state database; this path follows the routers’ own DUAL result (per-hop topology tables), so there is no summed cost to show: 3 RIB-installed variant(s) shown alongside (the RIB holds equal next-hops).
Ce que vous obtenez à la place, c’est la distance calculée propre à chaque routeur vers la destination, décroissante le long de la chaîne : 712704 → 710144 → 658944 → 556544 → 505344 → 428544 → 223744 → 133120 → 128256.
Chacun de ces nombres vient d’un routeur. Aucun n’a été dérivé. Le champ « coût total » vide n’est pas un trou dans l’implémentation. C’est le rendu correct d’une quantité qui n’existe pas.
La même règle se déclenche au-delà d’une frontière d’AS, où un coût OSPF et un coût IS-IS sont des nombres dans des espaces de métriques sans rapport :
Per-segment costs (never summed) | 15 hops
3. « Voici exactement mon degré de confiance, par segment »
Les chemins interdomaines ne peuvent pas être calculés. Ils ne peuvent qu’être assemblés à partir de preuves, et les preuves ne sont pas uniformément bonnes : Osprey les note donc par segment plutôt que d’émettre une confiance globale pour tout le chemin :
AS 200 ospfv2/1 cost 20051 est resolved. AS 300 isis/LAB cost 1320 est
inferred. Même chemin, même écran, statut épistémique différent, les deux
étiquetés.
Derrière ces badges se trouve une échelle stricte, essayée dans l’ordre :
| Barreau | Preuve | Confiance |
|---|---|---|
| a | Une ligne de RIB sur un routeur de bordure de ce domaine couvrant la destination | resolved |
| a2 | Un serveur de routes dont la RIB BMP couvre la destination via l’AS suivant | inferred (bmp-rib-rs) |
| b | Une session eBGP établie vers l’AS suivant de la chaîne | inferred |
| c | Rien | opaque : rendu comme segment avec une note, aucun saut dessiné |
Le barreau (c) est celui qui compte. Quand Osprey ne peut pas établir comment le trafic entre dans un domaine, il n’interpole pas une suite de sauts d’apparence plausible. Il dessine un segment explicitement opaque et s’explique, et là où la cause est actionnable, il dit la chose actionnable plutôt qu’une excuse générique. Le message prend cette forme :
AS 65000 has no areas in the selected scope. Include its areas to trace through this domain
C’est un message avec lequel vous pouvez faire quelque chose. « Point d’entrée inconnu » ne l’est pas. (Les chemins de laboratoire de ces billets se résolvent tous, cette note-là n’est donc pas parmi les captures ici. Elle se déclenche quand une portée omet réellement un AS de transit.)
Le barreau (a2) existe pour une raison précise qui mérite d’être nommée : un serveur de routes transparent n’apparaît jamais dans l’AS_PATH. Sans lire la RIB propre du serveur de routes, il n’y a aucun moyen de voir un détour par un IX. Le chemin paraîtrait direct alors qu’il ne l’est pas.
4. « Ces ports sont un fait / une supposition / vraiment ambigus »
Quand Osprey annote une transition eBGP avec des ports physiques, il distingue quatre situations plutôt que de les réduire à une seule réponse confiante :
- Exactement une paire de liens, pas d’alternative par fabric → ports énoncés
comme un fait :
jfk1-gw1 Et1/1 → i-jfk1-gw1 Et1/2 - Liens parallèles → un agrégat, avec l’incertitude nommée : “3 parallel L2 links: Gi2↔Et1/0, … (session link undetermined)”
- Les deux bordures sur un bridge partagé, sans lien direct → la présence de la fabric avec les ports de raccordement, c’est-à-dire l’affirmation qu’un bridge existe entre elles, jamais l’affirmation que la session le traverse
- À la fois un lien direct et une fabric partagée → ambiguïté explicite nommant les deux et n’en choisissant aucun
Plus les règles de soutien : les lignes doivent être plus fraîches que 13 heures, l’âge est divulgué au-delà de 6 heures, et un bridge apparié uniquement sur le sysname oppose son veto à une affirmation de port sans jamais être affiché comme un fait.
Le barreau le plus fort transforme une supposition en fait : lorsque les deux
adresses de session BGP se résolvent sur des ports précis via les liaisons IP-MIB
des équipements, l’annotation devient ip-bound et prime sur les garde-fous
d’ambiguïté, car à ce stade ce n’est plus une inférence.
5. « Ces champs ne sont pas disponibles »
Le plus subtil, et mon préféré :
13382 LSAs reconstructed (LSAge, SeqNo, Checksum not available)
Ces LSA ont été reconstruits à partir de parcours SNMP plutôt que reçus par une adjacence protocolaire, et un parcours SNMP de la MIB OSPF vous donne le contenu des LSA mais pas les champs d’en-tête vivants.
L’implémentation tentante, ce sont trois colonnes de zéros. Elles s’afficheraient magnifiquement, se trieraient très bien, et seraient un mensonge. Pire, un mensonge indétectable, car un LSA d’âge 0 ressemble à un LSA fraîchement inondé plutôt qu’à une mesure manquante.
Les colonnes sont donc absentes et la raison est imprimée en haut du panneau.
6. Refuser d’utiliser mon meilleur moteur
Celui dont je suis le plus content, parce qu’il m’a coûté une fonctionnalité.
Le mode simulation d’Osprey vous laisse couper des liens, retirer des nœuds, changer des métriques et observer le trafic se déplacer. Le geste évident serait de faire tourner le tout nouveau moteur de chaîne saut par saut sur la topologie mutée.
Osprey ne le fait délibérément pas.
Une chaîne d’acheminement après mutation n’est pas calculable. Suivre la table propre de chaque routeur suppose de savoir ce que la table de chaque routeur serait après le changement, et cela dépend des summary-LSA de type 3 que les ABR survivants réémettraient. Ces LSA n’existent pas encore. Ils ne peuvent pas être synthétisés sans deviner, et les deviner produirait un chemin saut par saut avec toute l’autorité du moteur validé et rien de sa validation.
Les deux côtés de la simulation restent donc sur la projection SPF clairement étiquetée, et le disent dans les avis. La réponse la plus belle était disponible. Elle n’aurait simplement pas été vraie.
Pourquoi c’est une fonctionnalité et pas une excuse
Je vends un produit de topologie réseau. Chacun des comportements ci-dessus rend une capture d’écran légèrement moins impressionnante que celle d’un concurrent, et j’ai eu la conversation où quelqu’un fait remarquer qu’une réponse confiante se démontre mieux.
C’est vrai. Elle détruit aussi la seule chose qui rende l’outil digne d’être possédé.
Une ingénieure à 3 h du matin devant une area partitionnée n’a pas besoin d’une belle image. Elle a besoin de savoir sur quelles parties de l’image elle peut parier. Un produit qui note ses propres preuves (resolved, inferred, opaque, unavailable, not computable) lui permet de placer son scepticisme là où il faut, au lieu de le répartir uniformément sur tout ce qui est à l’écran.
La mesure du billet précédent est ce qui mérite cette confiance : 4 032 paires de routeurs sur 4 032 reproduites exactement face à la vérité relevée sur les routeurs. Les refus de ce billet-ci sont ce qui la protège. Un outil qui a raison 4 032 fois puis bluffe discrètement à la 4 033e ne vous a rien appris sur le cas dans lequel vous vous trouvez.
Dites ce que vous savez. Dites comment vous le savez. Dites quand vous ne savez pas.
Ceci clôt la première série. La visite du laboratoire est ici, l’architecture de découverte passive ici, et le moteur de chemin saut par saut ici. Une deuxième série, sur le fait de tenir plusieurs vérités à la fois, de classer des preuves contradictoires et de prouver que son propre produit a tort, commence avec Le même routeur, trois vérités différentes.