Was Osprey nicht raten will
Das Wichtigste, das ich gebaut habe, ist eine Reihe von Verweigerungen
Michel Wijnberg
Ein Netzwerkwerkzeug, das rät, ist schlimmer als eines, das seine Unwissenheit zugibt, und der Grund dafür ist nicht philosophisch. Er ist betrieblich.
Sagt ein Werkzeug “ich weiß es nicht”, gehen Sie es herausfinden. Liefert es eine plausible Antwort, handeln Sie danach. Und nichts auf dem Bildschirm unterscheidet eine richtige Antwort von einer selbstbewussten, der Fehlermodus lautet also nicht “das Werkzeug lag falsch”, sondern “das Werkzeug lag falsch und ich hatte keinen Anlass nachzuprüfen”.
Deshalb hat Osprey eine Regel, die jeden Produktinstinkt überstimmt, den ich habe: Nenne die Belege, oder nenne ihr Fehlen. Niemals interpolieren. Niemals einen Platzhalter zeichnen, der wie Daten aussieht.
So sieht das in einem ausgelieferten Produkt tatsächlich aus.
1. “Diesen Pfad kann ich nicht auf die gute Art berechnen”
Im vorherigen Beitrag ging es um die Hop-für-Hop-Weiterleitungskette, die der eigenen Routing-Tabelle jedes Routers folgt statt einen von der Quelle gewurzelten Korridor zu zeichnen, exakt validiert gegen alle 4.032 Routerpaare in AS 200.
Diese Engine funktioniert für OSPFv2. Für IS-IS funktioniert sie nicht, und Osprey sagt das, statt stillschweigend zurückzufallen:
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).
Drei Dinge zu dieser Meldung.
Sie benennt das Modell, das geantwortet hat: die Kürzeste-Pfad-Sicht der Quelle, damit Sie wissen, welche der beiden Engines Sie gerade vor sich haben. Sie benennt den Grund: Osprey speichert nichts, woraus sich das Leaking von Routen zwischen L1 und L2 rekonstruieren ließe. Das ist eine Grenze von Ospreys Modell, nicht des Protokolls: IS-IS hat kein Summary-LSA vom Typ 3, weil es nie eines brauchte, und trägt Erreichbarkeit zwischen den Leveln stattdessen in L2-LSPs und im Attached-Bit. Und sie benennt die konkrete Folge, und das ist der Teil, der Sie tatsächlich treffen würde: Eine reine L1-Quelle leitet überhaupt nicht nach Ende-zu-Ende-Kosten weiter. Sie folgt gemäß ISO 10589 dem Attached-Bit zu ihrem nächstgelegenen L1/L2-Router. Ihr echter erster Hop hat möglicherweise nichts mit dem gezeichneten Pfad zu tun.
Der Pfad wird trotzdem gezeigt, denn eine Kürzeste-Pfad-Sicht ist wirklich nützlich. Sie darf sich nur nicht als die stärkere Antwort ausgeben.
Dieselbe Disziplin gilt für OSPFv3, für einen Bereich, der nur einen Teil der Areas einer Protokollinstanz enthält, für Areas mit einem Virtual Link und für Router, die in zwei Protokollinstanzen leben, die beide die Adressfamilie tragen können. Jeder Fall bekommt seine eigene benannte Begründung. Keiner setzt stillschweigend das alte Bild wieder ein.
2. “Diese Zahl würde nichts bedeuten”
EIGRP ist kein Link-State-Protokoll. Es gibt keine Datenbank zum Beitreten, kein SPF zum Rechnen und, was wichtig ist, keine sinnvolle Art, Hop-Kosten zu addieren, denn die zusammengesetzte Metrik von EIGRP beschreibt einen ganzen Pfad und nicht einen einzelnen Link.
Also gibt Osprey keine Summe aus:
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).
Was Sie stattdessen bekommen, ist die eigene berechnete Distanz jedes Routers zum Ziel, fallend entlang der Kette: 712704 → 710144 → 658944 → 556544 → 505344 → 428544 → 223744 → 133120 → 128256.
Jede dieser Zahlen stammt von einem Router. Keine davon wurde abgeleitet. Das leere Feld “Gesamtkosten” ist keine Lücke in der Implementierung. Es ist die korrekte Darstellung einer Größe, die es nicht gibt.
Dieselbe Regel greift über eine AS-Grenze hinweg, wo eine OSPF-Metrik und eine IS-IS-Metrik Zahlen aus unverwandten Metrikräumen sind:
Per-segment costs (never summed) | 15 hops
3. “Hier steht genau, wie sicher ich bin, je Segment”
Domänenübergreifende Pfade lassen sich nicht berechnen. Sie lassen sich nur aus Belegen zusammenfügen, und die Belege sind nicht gleichmäßig gut, also stuft Osprey sie je Segment ein, statt eine pauschale Sicherheit für den ganzen Pfad auszugeben:
AS 200 ospfv2/1 cost 20051 ist resolved. AS 300 isis/LAB cost 1320 ist
inferred. Derselbe Pfad, derselbe Bildschirm, unterschiedlicher
Erkenntnisstand, beides gekennzeichnet.
Hinter diesen Kennzeichen steht eine strenge Leiter, die der Reihe nach probiert wird:
| Sprosse | Beleg | Verlässlichkeit |
|---|---|---|
| a | Eine RIB-Zeile an einem Border-Router in dieser Domäne, die das Ziel abdeckt | resolved |
| a2 | Ein Route Server, dessen eigene BMP-RIB das Ziel über das nächste AS abdeckt | inferred (bmp-rib-rs) |
| b | Eine bestehende eBGP-Sitzung in Richtung des nächsten AS auf der Kette | inferred |
| c | Nichts | opaque: als Segment mit Hinweis dargestellt, keine Hops gezeichnet |
Sprosse (c) ist die entscheidende. Wenn Osprey nicht feststellen kann, wie Verkehr in eine Domäne eintritt, interpoliert es keine plausibel aussehende Reihe von Hops. Es zeichnet ein ausdrücklich undurchsichtiges Segment und erklärt sich, und wo die Ursache behebbar ist, sagt es das Behebbare statt einer allgemeinen Entschuldigung. Die Meldung hat diese Form:
AS 65000 has no areas in the selected scope. Include its areas to trace through this domain
Das ist eine Meldung, mit der Sie etwas anfangen können. “Einstiegspunkt unbekannt” ist es nicht. (Die Laborpfade in diesen Beiträgen lassen sich alle auflösen, dieser Hinweis ist hier also nicht als Screenshot dabei. Er erscheint, wenn ein Bereich wirklich ein Transit-AS auslässt.)
Sprosse (a2) gibt es aus einem bestimmten Grund, den man benennen sollte: Ein transparenter Route Server taucht nie im AS_PATH auf. Ohne die eigene RIB des Route Servers zu lesen, gibt es keine Möglichkeit, einen Umweg über einen IX überhaupt zu sehen. Der Pfad sähe direkt aus, obwohl er es nicht ist.
4. “Diese Ports sind eine Tatsache / eine Vermutung / wirklich mehrdeutig”
Wenn Osprey einen eBGP-Übergang mit physischen Ports annotiert, unterscheidet es vier Situationen, statt sie zu einer selbstbewussten Antwort zusammenzuziehen:
- Genau ein Linkpaar, keine Fabric-Alternative → Ports als Tatsache genannt:
jfk1-gw1 Et1/1 → i-jfk1-gw1 Et1/2 - Parallele Links → eine Zusammenfassung, mit benannter Unsicherheit: “3 parallel L2 links: Gi2↔Et1/0, … (session link undetermined)”
- Beide Border-Router an einer gemeinsamen Bridge, kein direkter Link → Vorhandensein der Fabric mit den Anschlussports, also die Aussage, dass es zwischen ihnen eine Bridge gibt, niemals die Behauptung, dass die Sitzung darüber läuft
- Sowohl ein direkter Link als auch eine gemeinsame Fabric → ausdrückliche Mehrdeutigkeit, die beides benennt und sich für keines entscheidet
Dazu die flankierenden Regeln: Zeilen müssen jünger als 13 Stunden sein, ab 6 Stunden wird das Alter offengelegt, und eine Bridge, die nur über den Sysname zugeordnet wurde, verhindert eine Port-Aussage, ohne je selbst als Tatsache angezeigt zu werden.
Die stärkste Sprosse macht aus einer Vermutung eine Tatsache: Wenn sich beide
Adressen der BGP-Sitzung über die IP-MIB-Bindungen der Geräte konkreten Ports
zuordnen lassen, wird die Annotation zu ip-bound und überstimmt die
Mehrdeutigkeitsschranken, denn an dieser Stelle ist es keine Schlussfolgerung
mehr.
5. “Diese Felder sind nicht verfügbar”
Die subtilste, und meine liebste:
13382 LSAs reconstructed (LSAge, SeqNo, Checksum not available)
Diese LSAs wurden aus SNMP-Walks rekonstruiert und nicht über eine Protokollnachbarschaft empfangen, und ein SNMP-Walk der OSPF-MIB liefert Ihnen den Inhalt der LSAs, aber nicht die aktuellen Header-Felder.
Die verlockende Implementierung sind drei Spalten Nullen. Sie würden wunderbar aussehen, ließen sich sauber sortieren und wären eine Lüge. Und schlimmer: eine unentdeckbare Lüge, denn ein LSA mit Alter 0 sieht aus wie ein frisch geflutetes LSA und nicht wie eine fehlende Messung.
Also fehlen die Spalten, und der Grund steht oben im Panel.
6. Die eigene beste Engine verweigern
Die, über die ich mich am meisten freue, weil sie mich eine Funktion gekostet hat.
Der Simulationsmodus von Osprey lässt Sie Links ausfallen lassen, Knoten entfernen, Metriken ändern und beobachten, wie sich der Verkehr verschiebt. Der naheliegende Schritt wäre, die glänzende neue Hop-für-Hop-Engine gegen die veränderte Topologie laufen zu lassen.
Osprey tut das bewusst nicht.
Eine Weiterleitungskette nach der Veränderung ist nicht berechenbar. Der eigenen Tabelle jedes Routers zu folgen setzt voraus zu wissen, wie die Tabelle jedes Routers nach der Änderung aussehen würde, und das hängt von den Summary-LSAs vom Typ 3 ab, die die überlebenden ABRs neu erzeugen würden. Diese LSAs existieren noch nicht. Sie lassen sich nicht ohne Raten erzeugen, und sie zu raten ergäbe einen Hop-für-Hop-Pfad mit der ganzen Autorität der validierten Engine und ohne jede Validierung.
Also bleiben beide Seiten der Simulation bei der klar gekennzeichneten SPF-Projektion und sagen das in den Hinweisen. Die schöner aussehende Antwort war verfügbar. Sie wäre nur nicht wahr gewesen.
Warum das eine Funktion ist und keine Entschuldigung
Ich verkaufe ein Produkt für Netzwerktopologie. Jedes der oben beschriebenen Verhalten macht einen Screenshot ein wenig weniger beeindruckend als den eines Wettbewerbers, und ich habe das Gespräch geführt, in dem jemand darauf hinweist, dass sich eine selbstbewusste Antwort besser vorführen lässt.
Das stimmt. Sie zerstört auch das Einzige, was das Werkzeug überhaupt brauchbar macht.
Eine Ingenieurin, die um 03:00 Uhr vor einer partitionierten Area sitzt, braucht kein schönes Bild. Sie muss wissen, auf welche Teile des Bildes sie wetten kann. Ein Produkt, das seine eigenen Belege einstuft (resolved, inferred, opaque, unavailable, not computable), lässt sie ihre Skepsis dort einsetzen, wo sie hingehört, statt sie gleichmäßig über alles auf dem Bildschirm zu verteilen.
Die Messung im vorherigen Beitrag ist das, was dieses Vertrauen verdient: 4.032 von 4.032 Routerpaaren exakt reproduziert, gegen die von den Routern abgelesene Wahrheit. Die Verweigerungen in diesem Beitrag sind das, was es schützt. Ein Werkzeug, das 4.032-mal recht hat und beim 4.033. Mal still blufft, hat Ihnen nichts darüber beigebracht, in welchem der beiden Fälle Sie sich gerade befinden.
Sagen Sie, was Sie wissen. Sagen Sie, woher Sie es wissen. Sagen Sie, wann Sie es nicht wissen.
Damit endet die erste Serie. Die Labortour steht hier, die Architektur der passiven Erkennung hier und die Hop-für-Hop-Pfad-Engine hier. Eine zweite Serie, über das gleichzeitige Halten mehrerer Wahrheiten, das Einstufen widersprüchlicher Belege und das Widerlegen des eigenen Produkts, beginnt mit Derselbe Router, drei verschiedene Wahrheiten.