← Tous les articles

Pousser, ne pas interroger

L’unique source qui vient à vous, et les deux choses que cela change dans ce que vous avez le droit de croire

Michel Wijnberg

Jusqu’ici, chaque source de cette série est quelque chose qu’Osprey va demander. Un enregistreur GRE rejoint une zone et demande une base de données. Un parcours SNMP demande une table à un équipement. Demander, attendre, recevoir, recommencer.

BMP est la seule qui arrive d’elle-même. Le routeur ouvre une session TCP vers la station de supervision et se met à parler, et il continue tant qu’il a quelque chose à dire (RFC 7854). Personne n’interroge quoi que ce soit.

Cela paraît strictement meilleur, et sur une dimension ça l’est. Sur deux autres, cela change ce que vous êtes fondé à conclure, et ces deux-là sont plus intéressantes que la rapidité.


Ce que rapporte le fait d’arriver tout seul

L’interrogation a un intervalle d’échantillonnage, et un intervalle d’échantillonnage a toutes les propriétés d’un intervalle d’échantillonnage. Tout ce qui se produit et s’inverse à l’intérieur d’un cycle n’a pas eu lieu, du point de vue de vos données. Une route qui bat deux fois entre deux parcours ressemble à une route qui n’a jamais bougé.

Un flux poussé n’a pas de cycle. Un retrait arrive parce qu’un retrait a eu lieu, et l’horodatage dessus est celui du routeur, pas celui de l’interrogateur.

Pour BGP cela compte plus que pour presque tout le reste, car BGP change bien plus souvent que la topologie. Un parcours de cinq minutes sur une table complète est à la fois extrêmement coûteux et, pour tout ce qui est éphémère, aveugle. Le modèle push est le seul où la question « quand ce préfixe a-t-il changé » a une réponse digne de confiance.


Coût numéro un : le silence cesse de vouloir dire quelque chose

Voici maintenant ce que l’interrogation obtient gratuitement.

Un interrogateur qui demande et ne reçoit rien sait précisément ce qui s’est passé : il a demandé et n’a rien reçu. L’absence est elle-même une observation, horodatée, et elle peut être retentée.

Un écouteur qui n’entend rien n’a pas ce luxe. Le silence est le même sur le fil que le réseau soit calme ou que la session ait disparu, et le second cas est indiscernable du premier jusqu’à ce que quelque chose d’autre vous dise le contraire.

Le danger précis mérite d’être nommé, car il inverse la métrique vers laquelle vous iriez naturellement. Si vous traitez une session tombée comme une absence de changement, alors le pair dont vous n’entendez plus rien devient le pair le plus stable de votre rapport. La ligne la plus silencieuse à l’écran est celle que vous avez perdue. Tout classement qui trie par churn place votre angle mort en tête, étiqueté comme votre relation la plus saine.

L’article douze traite de ce qu’Osprey fait à ce sujet, c’est-à-dire enregistrer une chute de session comme un trou de supervision plutôt que comme un retrait massif, et je ne vais pas le redire ici. Le point pour cette série est plus étroit : le push déplace la charge d’interpréter le silence du protocole vers vous. Le modèle d’interrogation vous donnait cette réponse et vous n’aviez pas à y penser.


Coût numéro deux : vous lisez la conversation de quelqu’un d’autre

Le second coût est plus subtil et produit de vrais bugs d’analyse.

BMP ne vous donne pas une session BGP. Il vous donne une copie des messages de la session de quelqu’un d’autre, encapsulés et retransmis. Vous n’étiez pas présent à la négociation, et les messages BGP ne sont pas autodescriptifs : la façon de décoder un UPDATE dépend de ce que les deux pairs ont convenu dans leur OPEN.

L’approche évidente est de reconstruire le contexte. Peer Up transporte les deux messages OPEN, vous pouvez donc lire ce qui a été négocié et le retenir pour la session. Osprey le fait.

Et puis l’en-tête par pair de chaque message suivant porte un drapeau A, indiquant si la PDU encapsulée utilise l’ancien format d’AS_PATH sur deux octets (RFC 7854 §4.2). Il est par message, donc l’analyseur décode ce message d’après lui plutôt que de supposer le format d’après le contexte du Peer Up.

Ces deux-là peuvent se contredire. Quand c’est le cas, Osprey décode d’après le drapeau et journalise l’écart au lieu de le résoudre en silence, et le raisonnement mérite d’être énoncé parce qu’il se généralise : la capacité consigne ce que deux routeurs ont convenu de faire, et le drapeau décrit ce que cet exportateur a fait de ce message. Là où une preuve sur un accord et une preuve sur les octets en main s’opposent, ce sont les octets en main qui sont en train d’être analysés.

Il y a une subtilité correspondante à propos d’Add-Path, et elle a la même forme. Que le NLRI encapsulé porte ou non des identifiants de chemin dépend d’une négociation qui est directionnelle, et la direction qui s’applique dépend de la RIB supervisée : l’Adj-RIB-In par défaut, ou l’Adj-RIB-Out ajoutée par le RFC 8671 et signalée par un autre drapeau du même en-tête par pair. L’analyseur lit donc ce drapeau d’abord et choisit d’après lui quelle négociation croire. Même champ, deux lectures, sélectionnées par un bit que vous ne consulteriez pas si vous étiez partie à la session.

Rien de cela ne se pose quand vous interrogez un équipement. Vous interrogez un équipement sur lui-même, dans un protocole dont vous êtes partie de plein droit. BMP vous tend la vue propre du routeur et vous retire le contexte dans lequel elle a été négociée, et chaque champ qui reconstruit ce contexte est porteur.

Le tableau BGP Peers avec une colonne Source où les marqueurs BMP et SNMP figurent dans la même liste. Les lignes BMP ont été vues pour la dernière fois il y a un jour et portent des temporisateurs négociés et un router ID ; les lignes SNMP disent « à l'instant » et laissent les deux vides
Le tableau BGP Peers avec une colonne Source où les marqueurs BMP et SNMP figurent dans la même liste. Les lignes BMP ont été vues pour la dernière fois il y a un jour et portent des temporisateurs négociés et un router ID ; les lignes SNMP disent « à l'instant » et laissent les deux vides

Les deux modes d’acquisition arrivent dans un seul tableau, et la différence se voit dans deux colonnes. Les lignes BMP ont été vues pour la dernière fois il y a un jour, et ce n’est pas un défaut : rien n’a changé sur ces sessions, et une source qui pousse se tait quand rien ne change. Les lignes SNMP disent à l’instant parce que quelqu’un est allé demander. La même affirmation, deux raisons très différentes d’y croire, et dans un seul des deux cas le silence est une information.


Le rapport qui n’arrive jamais si vous ne le demandez pas

Une dernière chose, et c’est la plus petite et la plus agaçante.

BMP définit les Statistics Reports : des compteurs périodiques par pair, y compris les compteurs de rejet et de traitement-comme-retrait qui vous disent ce que la politique d’un pair écarte. Excellentes données. Exactement ce qu’il faut pour un tableau de bord.

Ils n’arrivent pas.

Pas à cause d’un bug d’analyse, et pas parce que l’exportateur serait cassé. IOS n’envoie tout simplement pas de Statistics Reports tant qu’on ne lui a pas indiqué une période de report, et il n’y a pas de valeur par défaut. Sans stats-reporting-period sous la configuration du serveur BMP, ce type de message n’apparaît jamais sur le fil, et chaque champ statistique par pair reste vide à jamais sans la moindre erreur nulle part.

Le laboratoire a tourné ainsi un moment, et la lecture honnête des colonnes vides n’était pas « ce pair ne rejette rien ». C’était « personne n’a jamais dit à ce routeur de le dire ». Le correctif tenait en une ligne de configuration sur six routeurs, écrite dans la startup-config pour qu’un redémarrage ne défasse pas silencieusement la mesure.

C’est un petit détail d’exploitation à la forme générale : une source push ne peut vous dire que ce qu’on l’a configurée pour envoyer. Avec l’interrogation, vous contrôlez le moment où la question est posée. Avec le push, vous n’observez que ce que l’exportateur a été réglé pour émettre, et un message non envoyé est indiscernable d’un message jamais généré.


L’essentiel

Le push est meilleur et il n’est pas gratuit.

Vous gagnez la seule chronologie digne de confiance pour quelque chose qui change aussi vite que BGP, et vous abandonnez les deux choses auxquelles l’interrogation ne vous a jamais fait penser : que le silence était autrefois une observation, et que vous étiez autrefois partie à la conversation que vous lisiez.

Toutes deux apparaissent dans ce code sous forme de petites attentions précises. Une chute de session enregistrée comme un trou. Une largeur d’AS_PATH prise au drapeau plutôt qu’à la capacité. Une colonne de statistiques qui reste vide et sait pourquoi. Aucune n’est astucieuse. Ce sont toutes le même aveu, à savoir qu’un message qui arrive de lui-même vous en dit moins sur sa propre absence qu’une question que vous avez posée vous-même.


Cela clôt cette série. Le fil conducteur, s’il y en a un, est que chaque réponse de ce produit vaut exactement autant que le compte rendu qu’elle peut donner de la façon dont elle a été obtenue.