Das Protokoll ohne Datenbank

Drei verschiedene Arten von Nichts: keine Datenbank zum Beitreten, eine Datenbank, die niemand implementiert, und eine Tabelle mit den Antworten, aber nicht den Eingaben

4. September 2026 Michel Wijnberg

Die letzten beiden Beiträge handelten davon, einem Link-State-Protokoll vorsichtig beizutreten: hineinkommen, ohne ein Pfad zu werden, hinausgehen, ohne einen Geist zu hinterlassen. Beide setzen voraus, dass es etwas gibt, dem man beitreten kann.

Dieser handelt von den Fällen, in denen es das nicht gibt, und es sind nicht alles dieselben Fälle. Ich habe drei, und sie versagen auf drei wirklich verschiedene Arten.

Eins: Es gibt keine Datenbank

EIGRP ist ein fortgeschrittenes Distanzvektor-Protokoll. Nachbarn tauschen Erreichbarkeits- und Distanzinformationen aus; sie pflegen keine gemeinsame Link-State-Datenbank. Es gibt keine synchronisierte Kopie, die jeder Router hält, also gibt es nichts, womit man sich synchronisieren könnte. Der Beitrittszug aus den beiden vorigen Beiträgen existiert hier nicht, denn das, dem man beitreten würde, wurde nie gebaut.

Was es gibt, ist die eigene Sicht jedes Routers: seine Nachbarn und seine Topologietabelle von Zielen mit den Distanzen, die er berechnet hat. Das wird über SNMP gelesen, aus CISCO-EIGRP-MIB, Router für Router, und der Adjazenzgraph wird daraus zusammengesetzt, was jeder Router über seine eigenen Nachbarn sagt.

Zusammengesetzt, nicht gelesen. Niemand im Netz hält das Bild. Es existiert erst, wenn Sie alle gefragt und die Antworten zusammengelegt haben, was eine andere erkenntnismäßige Position ist als das Lesen einer LSDB, und die es wert ist, ehrlich benannt zu werden, selbst wenn der resultierende Graph identisch aussieht.

Der Nachbar, der nicht sagen will, wer er ist

Dann ein spezifisches Problem, und es ist ein schönes.

Ein EIGRP-Nachbareintrag gibt Ihnen die Adresse des Nachbarn. Für IPv6 ist diese Adresse link-lokal, und eine link-lokale Adresse identifiziert ein Interface an einem Link. Sie identifiziert kein Gerät. Zwei Router an entgegengesetzten Enden des Netzes können dieselbe link-lokale Adresse tragen, ohne dass es einen Konflikt gibt, weil der Gültigkeitsbereich der Link ist.

Die Nachbartabelle sagt Ihnen also, dort drüben ist etwas, und weigert sich zu sagen, was.

Die Auflösung kommt aus einer ganz anderen Schicht: den LLDP- und CDP-Adjazenzen, die für dieses Gerät bereits entdeckt wurden, indiziert nach Interface. Gleichen Sie das Interface des EIGRP-Nachbarn gegen den L2-Nachbarn am selben Interface ab, und Sie erfahren, welches Gerät am anderen Ende hängt.

Das heißt, eine EIGRP-Kante in Osprey ist darunter die Übereinstimmung zweier unabhängiger Beobachtungen: das Routing-Protokoll sagt, dass eine Adjazenz existiert, und die Sicherungsschicht sagt, wer am anderen Ende ist. Fehlen die L2-Daten, bleibt der Nachbar unaufgelöst. Er wird nicht aus der Adressierung geraten, nicht aus Benennung geschlossen, nicht über ein Subnetz abgeglichen. Eine Kante, die keinem Gerät zugeordnet werden kann, wird keine Kante.

Zwei: Die Tabelle hat die Antworten, aber nicht die Eingaben

Die EIGRP-Topologietabelle ist der Ort der zweiten Art von Nichts, und es ist die, die im Produkt eine Verweigerung erzeugt hat.

Die Tabelle hat zwölf zugreifbare Spalten. Zusammen tragen sie die Distanzen von DUAL: die Feasible Distance, die aktuelle berechnete Distanz, die von einem Successor gemeldete Distanz, dazu Successor-Zähler und Next-Hop-Zustand. Das reicht, um Ihnen zu zeigen, was jeder Router derzeit glaubt, und der erste Beitrag dieses Blogs zeigt genau das: die eigene Zahl jedes Routers, entlang einer Kette abnehmend.

Es reicht nicht, um irgendetwas Neues zu berechnen.

Um eine Metrik nach einer hypothetischen Änderung neu zu berechnen, brauchen Sie die Komponenten, aus denen die gemeldeten Distanzen abgeleitet wurden, und den Interface-Zustand dahinter. Die liegen auf dem Router: Fragen Sie e-ams1-cr1 nach show ip eigrp topology 10.64.0.0/15, und er druckt minimale Bandbreite, Gesamtverzögerung, Zuverlässigkeit, Last, MTU und Hop-Anzahl für dieses Präfix, weshalb ich weiß, dass es sie gibt, statt es zu schließen.

Sie stehen nicht in der gelesenen MIB-Tabelle. Die zwölf Spalten tragen, was DUAL entschieden hat. Der Router behält, woraus DUAL es entschieden hat, und veröffentlicht das hier nicht.

Also verweigert Osprey. Bitten Sie es, einen Ausfall in einer EIGRP-Domäne zu simulieren, und es lehnt es ab, eine neue Kette zu projizieren, und sagt warum: Es kann DUAL-Rekonvergenz nicht vorhersagen, weil die Tabellen, die es liest, die Distanzen tragen und nicht die Metrikkomponenten, die eine Neuberechnung braucht.

Zwei Dinge an dieser Verweigerung wiegen mehr als die Verweigerung selbst.

Sie ist auf das begrenzt, was wir lesen, nicht auf das Protokoll. Die Meldung ist so formuliert, dass dies eine Datenerhebungsgrenze ist und keine Eigenschaft von EIGRP, denn ein zukünftiger Enricher, der die Komponenten anderswoher liest, würde sie aufheben. Ein Produkt, das sagt “EIGRP kann nicht simuliert werden”, sagt Ihnen stillschweigend, nie wieder zu fragen, was eine andere und viel schlechtere Aussage ist als “ich erhebe die Eingaben derzeit nicht”.

Sie ist präzise darin, wann sie greift. Ist die simulierte Änderung eine reine Entfernung, und liegt das Entfernte nachweislich nicht auf der beobachteten Kette, wird die echte Kette weiterhin gezeigt, mit einem Hinweis, dass der Ausfall sie nicht berührt. Anderswo Kapazität wegzunehmen kann einen Distanzvektor-Pfad, der sie nicht benutzte, nicht verbessern. Aber eine Kostenänderung oder ein neuer Link kann einen Pfad von überall anziehen, also zählen die immer als berührend. Die Engine verweigert dort, wo sie muss, nicht kategorisch, und dieser Unterschied ist der ganze Wert der Verweigerung.

Drei: Die Datenbank existiert im Standard und sonst nirgends

Die dritte Art von Nichts ist die frustrierendste, weil sie niemandes Bug ist.

IS-IS hat eine Standard-MIB: RFC 4444, unter .1.3.6.1.2.1.138. Ospreys SNMP-Discovery sondiert diesen Baum zuerst und fällt nur dann auf den Cisco-Baum unter .1.3.6.1.4.1.9.10.118 zurück. Die beiden OID-Mengen teilen sich ein basisrelatives Spaltenlayout und unterscheiden sich nur dort, wo sich die MIBs wirklich unterscheiden, was eine Circuit-Spaltenverschiebung ist; die Adjazenzspalten sind identisch. Der Entwurf ist bewusst herstellerneutral.

Der Standardpfad wurde nie gegen echte Hardware bewiesen.

Nicht weil er im Unit-Sinn ungetestet wäre: Er hat Tests. Sondern weil jedes Gerät, das wir erreichen können, nur den Cisco-Baum implementiert. Sondieren Sie einen Laborrouter nach dem Standard-.138-Baum, und er antwortet mit No Such Object. Der herstellerneutrale Codepfad wird von Fixtures ausgeübt und von sonst nichts, und ich schreibe diesen Satz lieber, als ihn entdecken zu lassen.

Dann hat Arista es schlimmer gemacht, auf lehrreiche Weise. Sondierung von vEOS-lab 4.29.2F auf dem Services-Pod: Der Standard-.138-Baum liefert No Such Object, und der Cisco-.9.10.118-Baum auch. Keiner von beiden. Das Gerät spricht IS-IS völlig einwandfrei, und es gibt überhaupt keinen SNMP-Baum, den man dazu fragen könnte.

Derselbe Agent bedient OSPF-MIB anstandslos, und LLDP-MIB, und registriert den OSPF-Baum dynamisch, sobald OSPF konfiguriert ist. Die ehrliche Antwort für diese Knoten ist also nicht “IS-IS-Discovery fehlgeschlagen” und schon gar nicht eine leere Topologie. Sie ist dieses Gerät kann dazu nicht befragt werden, und die Leaves des Pods werden folglich über OSPF entdeckt.

Ich werde daraus keine Aussage über den Markt machen, denn zwei Hersteller sind keine Erhebung. Was ich sagen kann, ist begrenzt und trotzdem nützlich: Über jedes Gerät, das wir testen konnten, war die Standard-MIB nicht implementiert, und die Cisco-Enterprise-MIB war der einzige Baum, der die Daten überhaupt bereitstellte. Ein Standard, den nichts Erreichbares implementiert, ist kein Standard, auf den man ein Versprechen bauen kann.

Das Reports-Menü, geöffnet im EIGRP-Netz. LSDB Browser, Neighbor Table, Inter-Area Routes und External Routes sind ausgegraut; IGP Prefixes, die BGP-Berichte und ein eigener Eintrag EIGRP Topology sind verfügbar

Das Menü ist die ehrliche Fassung dieses Beitrags. Vier Berichte sind hier nicht erreichbar, weil sie eine Datenbank lesen, die es nicht gibt, und jeder ausgegraute Eintrag trägt seinen Grund beim Überfahren mit der Maus, statt eine leere Tabelle zu öffnen. EIGRP bekommt stattdessen einen eigenen Eintrag, weil das, was es beantworten kann, eine andere Frage ist.

Drei Arten von Nichts

Nebeneinandergestellt, denn ein Produkt, das sie gleich behandelt, lügt über mindestens zwei:

Was fehlt	Die Versuchung	Was es stattdessen tut
keine Datenbank zum Beitreten	eine Topologiequelle erfinden	aus der Eigensicht jedes Routers rekonstruieren und es kennzeichnen
die Eingaben, nicht die Antworten	Standard-Bandbreite und -Verzögerung annehmen	die Simulation verweigern und die Grenze als unsere benennen
die MIB selbst	eine leere Topologie zurückgeben	sagen, dass dieses Gerät nicht befragt werden kann, und den Baum nutzen, den es bedient

Lesen Sie die mittlere Spalte. Jede davon erzeugt einen Bildschirm, der genau so aussieht wie der Bildschirm, den Sie bekommen, wenn die Daten wirklich da waren. Das ist das ganze Problem mit dem Füllen von Lücken: Die Ausgabe hat keine Möglichkeit, Ihnen zu sagen, welche Teile von ihr beobachtet wurden.

Der Punkt

Die ersten beiden Beiträge dieser Reihe handelten davon, ein sorgfältiger Gast im Protokoll eines anderen zu sein. Dieser handelt von den Räumen, in die man gar nicht hineingelassen wird.

Dort ein guter Gast zu sein bedeutet etwas anderes: nicht einen Weg hinein zu finden, sondern genau zu sagen, welche Tür verschlossen war. Eine unaufgelöste EIGRP-Kante, eine Simulation, die ablehnt, ein Gerät, das nicht befragt werden kann. Drei Verweigerungen, jede benennt ihre eigene Ursache, keine davon als Antwort verkleidet.

Als Nächstes und zuletzt in dieser Reihe: die eine Quelle, die zu Ihnen kommt, statt darauf zu warten, gefragt zu werden, und die zwei Arten, wie das verändert, was Sie glauben dürfen. Push statt Poll.