Le protocole sans base de données
Trois sortes de rien : aucune base à rejoindre, une base que personne n’implémente, et une table qui a les réponses mais pas les entrées
Michel Wijnberg
Les deux articles précédents portaient sur la manière de rejoindre prudemment un protocole à état de liens : entrer sans devenir un chemin, sortir sans laisser de fantôme. Tous deux supposent qu’il y a quelque chose à rejoindre.
Celui-ci porte sur les cas où il n’y a rien, et ce ne sont pas tous le même cas. J’en ai trois, et ils échouent de trois façons véritablement différentes.
Un : il n’y a pas de base de données
EIGRP est un protocole à vecteur de distance avancé. Les voisins échangent des informations d’accessibilité et de distance ; ils ne maintiennent pas de base à état de liens partagée. Il n’existe pas de copie synchronisée que chaque routeur détiendrait, donc il n’y a rien avec quoi se synchroniser. Le geste de rejoindre des deux articles précédents n’existe pas ici, parce que ce qu’on rejoindrait n’a jamais été construit.
Ce qui existe, c’est la vue propre de chaque routeur : ses voisins, et sa table de topologie
des destinations avec les distances qu’il a calculées. Cela se lit par SNMP, depuis
CISCO-EIGRP-MIB, un routeur à la fois, et le graphe d’adjacences est réassemblé à partir
de ce que chaque routeur dit de ses propres voisins.
Réassemblé, pas lu. Personne dans le réseau ne détient l’image. Elle n’existe qu’une fois que vous avez interrogé tout le monde et rassemblé les réponses, ce qui est une position épistémique différente de la lecture d’une LSDB, et cela mérite d’être dit honnêtement même quand le graphe obtenu paraît identique.
Le voisin qui refuse de dire qui il est
Ensuite un problème précis, et il est joli.
Une entrée de voisin EIGRP vous donne l’adresse du voisin. En IPv6 cette adresse est lien-local, et une adresse lien-local identifie une interface sur un lien. Elle n’identifie pas un équipement. Deux routeurs aux extrémités opposées du réseau peuvent porter la même adresse lien-local sans aucun conflit, parce que la portée est le lien.
La table de voisins vous dit donc qu’il y a quelque chose là-bas et refuse de dire quoi.
La résolution vient d’une couche tout autre : les adjacences LLDP et CDP déjà découvertes pour cet équipement, indexées par interface. Rapprochez l’interface du voisin EIGRP du voisin L2 sur la même interface et vous apprenez quel équipement se trouve à l’autre bout.
Ce qui signifie qu’une arête EIGRP dans Osprey est, en dessous, deux observations indépendantes qui concordent : le protocole de routage disant qu’une adjacence existe, et la couche liaison disant qui est à l’autre bout. Quand les données L2 manquent, le voisin reste non résolu. Il n’est pas deviné à partir de l’adressage, ni inféré du nommage, ni apparié sur un sous-réseau. Une arête qui ne peut pas être attribuée à un équipement ne devient pas une arête.
Deux : la table a les réponses mais pas les entrées
La table de topologie EIGRP est l’endroit où vit la deuxième sorte de rien, et c’est celle qui a produit un refus dans le produit.
La table a douze colonnes accessibles. Ensemble elles portent les distances de DUAL : la distance faisable, la distance calculée courante, la distance qu’un successeur a rapportée, plus des compteurs de successeurs et l’état du saut suivant. C’est assez pour vous montrer ce que chaque routeur croit à l’instant présent, et le premier article de ce blog montre exactement cela : le nombre propre de chaque routeur, décroissant le long d’une chaîne.
Ce n’est pas assez pour calculer quoi que ce soit de nouveau.
Pour recalculer une métrique après un changement hypothétique, il faut les composantes dont
les distances rapportées ont été dérivées, et l’état d’interface derrière. Elles sont sur le
routeur : demandez à e-ams1-cr1 un show ip eigrp topology 10.64.0.0/15 et il imprime
bande passante minimale, délai total, fiabilité, charge, MTU et nombre de sauts pour ce
préfixe, ce qui est ainsi que je sais qu’elles existent au lieu de l’inférer.
Elles ne sont pas dans la table MIB qui est lue. Les douze colonnes portent ce que DUAL a décidé. Le routeur garde ce à partir de quoi DUAL l’a décidé, et ne le publie pas ici.
Alors Osprey refuse. Demandez-lui de simuler une panne dans un domaine EIGRP et il décline de projeter une nouvelle chaîne, et dit pourquoi : il ne peut pas prédire la reconvergence de DUAL, parce que les tables qu’il lit portent les distances et non les composantes de métrique dont un recalcul a besoin.
Deux choses à propos de ce refus comptent plus que le refus lui-même.
Il est borné à ce que nous lisons, pas au protocole. Le message est rédigé pour dire qu’il s’agit d’un plafond de collecte de données et non d’une propriété d’EIGRP, car un futur enrichisseur qui lirait les composantes ailleurs le lèverait. Un produit qui dit « EIGRP ne peut pas être simulé » vous dit discrètement de ne plus jamais poser la question, ce qui est une affirmation différente et bien pire que « je ne collecte pas les entrées pour l’instant ».
Il est précis sur le moment où il se déclenche. Si le changement simulé est une pure suppression, et que la chose supprimée n’est démontrablement pas sur la chaîne observée, la vraie chaîne est encore affichée, avec une note disant que la panne ne la touche pas. Retirer de la capacité ailleurs ne peut pas améliorer un chemin à vecteur de distance qui ne s’en servait pas. Mais un changement de coût ou un nouveau lien peut attirer un chemin de n’importe où, donc ceux-là comptent toujours comme touchant. Le moteur refuse là où il le doit, pas catégoriquement, et cette différence fait toute la valeur du refus.
Trois : la base existe dans la norme et nulle part ailleurs
La troisième sorte de rien est la plus frustrante, parce que ce n’est le bug de personne.
IS-IS a une MIB standard : RFC 4444, à .1.3.6.1.2.1.138. La découverte SNMP d’Osprey sonde
cet arbre en premier, et ne retombe sur l’arbre Cisco à .1.3.6.1.4.1.9.10.118 qu’en
second. Les deux jeux d’OID partagent une disposition de colonnes relative à la base et ne
diffèrent que là où les MIB diffèrent réellement, soit un décalage de colonne de circuit ;
les colonnes d’adjacence sont identiques. La conception est délibérément neutre vis-à-vis
des fabricants.
Le chemin standard n’a jamais été prouvé contre du matériel réel.
Non parce qu’il serait non testé au sens unitaire : il a des tests. Mais parce que chaque
équipement que nous pouvons atteindre n’implémente que l’arbre Cisco. Sondez un routeur du
laboratoire pour l’arbre standard .138 et il renvoie No Such Object. Le chemin de code
neutre est exercé par des fixtures et par rien d’autre, et je préfère écrire cette phrase
plutôt que de la laisser être découverte.
Puis Arista a aggravé les choses, de façon instructive. En sondant vEOS-lab 4.29.2F sur le
pod de services : l’arbre standard .138 renvoie No Such Object, et l’arbre Cisco
.9.10.118 aussi. Ni l’un ni l’autre. L’équipement parle parfaitement IS-IS et il n’y a
aucun arbre SNMP auquel poser la question.
Le même agent sert OSPF-MIB sans souci, et LLDP-MIB, et enregistre l’arbre OSPF dynamiquement dès qu’OSPF est configuré. La réponse honnête pour ces nœuds n’est donc pas « la découverte IS-IS a échoué » et certainement pas une topologie vide. C’est cet équipement ne peut pas se voir poser cette question, et les feuilles du pod sont par conséquent découvertes via OSPF.
Je ne vais pas transformer cela en affirmation sur le marché, car deux fabricants ne font pas une étude. Ce que je peux dire est borné et reste utile : sur tous les équipements que nous avons pu tester, la MIB standard n’était pas implémentée, et la MIB entreprise Cisco était le seul arbre qui exposait les données. Une norme que rien de ce que nous atteignons n’implémente n’est pas une norme sur laquelle bâtir une promesse.
Le menu est la version honnête de ce billet. Quatre rapports sont inaccessibles ici parce qu’ils lisent une base qui n’existe pas, et chaque entrée grisée porte sa propre raison au survol, au lieu de s’ouvrir sur un tableau vide. EIGRP reçoit sa propre entrée, parce que ce qu’il peut répondre est une autre question.
Trois sortes de rien
Mettez-les côte à côte, car un produit qui les traite de la même façon ment sur au moins deux d’entre elles :
| Ce qui manque | La tentation | Ce qu’il fait à la place |
|---|---|---|
| aucune base à rejoindre | inventer une source de topologie | reconstruire depuis la vue propre de chaque routeur, et l’étiqueter |
| les entrées, pas les réponses | supposer bande passante et délai par défaut | refuser de simuler, et nommer le plafond comme le nôtre |
| la MIB elle-même | renvoyer une topologie vide | dire que cet équipement ne peut pas être interrogé, et utiliser l’arbre qu’il sert |
Lisez la colonne du milieu. Chacune de ces options produit un écran qui ressemble exactement à l’écran obtenu quand les données étaient réellement là. C’est tout le problème du comblement de lacunes : la sortie n’a aucun moyen de vous dire quelles parties d’elle ont été observées.
L’essentiel
Les deux premiers articles de cette série parlaient d’être un invité attentif dans le protocole d’autrui. Celui-ci parle des pièces où l’on ne vous laisse pas entrer du tout.
Y être un bon invité veut dire autre chose : non pas trouver un moyen d’entrer, mais dire précisément quelle porte était fermée. Une arête EIGRP non résolue, une simulation qui décline, un équipement qu’on ne peut pas interroger. Trois refus, chacun nommant sa propre cause, aucun déguisé en réponse.
Ensuite, et pour finir cette série : l’unique source qui vient à vous plutôt que d’attendre qu’on la sollicite, et les deux façons dont cela change ce que vous pouvez croire. Pousser, ne pas interroger.