Summary

  • RFC 1574 legte im Februar 1994 eine Grundausstattung zur Fehlersuche für OSI-Dienste auf CLNP fest: Echo, Traceroute und einen Weg, Routingtabellen von Hosts und Routern auszulesen.
  • Ist das Error-Report-Flag gesetzt, kann auch ein CLNP-Knoten ohne Unterstützung für den neuen Echo-Selektor mit einer Fehlermeldung antworten. Die Meldung belegt eine Antwort dieses Knotens; über den Weg zum Ziel sagt sie noch nichts Abschließendes.

Die Verbindung ist gestört. Der Bereitschaftsdienst schickt eine Anfrage ab und erhält eine Fehlermeldung: Diese Art Echo kenne der Router nicht. Ein schlechtes Dashboard zeigt Rot. Ein guter Operator erkennt darin eine Adresse für die nächste Untersuchung: Die Sonde ist bis zu einem antwortenden Gerät vorgedrungen. Susan Hares und Cathy Wittbrodt nahmen solche Unterschiede in RFC 1574 ernst. Als OSI-Protokolle neben TCP/IP eingesetzt wurden, fehlten Werkzeuge für die Netzebene; vorhandene Implementierungen arbeiteten laut den Autoren oft nicht miteinander.

Das erste Werkzeug war ein Echo für CLNP. Die begleitende RFC 1575 definierte die hexadezimalen Selektoren 1E für die Anfrage und 1F für die Antwort. RFC 1574 verlangte zugleich das Error-Report-Flag. Ein älterer Knoten, der CLNP verstand, aber den neuen Selektor nicht kannte, sollte eine Fehlermeldung zurückzuschicken versuchen. Echo-Antwort, Ablehnung und völlige Stille mussten auf der Konsole unterscheidbar bleiben. Deshalb sollte das Ping-Werkzeug jede Laufzeit, die Minimal-, Maximal- und Durchschnittswerte mehrerer Versuche und empfangene Fehlercodes anzeigen.

Für die zweite Frage — auf welchem Weg kam das Paket voran? — nutzte der Entwurf das CLNP-Feld Lifetime. Es erfüllt eine ähnliche Aufgabe wie TTL bei IP. Mit Wert 1 läuft die Lebenszeit am ersten Zwischenknoten ab; mit Wert 2 kann der nächste Knoten antworten. Schrittweise höhere Werte ergeben eine Folge von Rückmeldungen. A0 und A1 kennzeichnen unterschiedliche Abläufe beim Lebenszeitende. B0 weist auf eine nicht unterstützte Option hin, 80 und 81 auf ein unerreichbares oder unbekanntes Ziel. Die Codes sind keine Dekoration: Sie unterscheiden, ob der nächste Blick auf die Strecke, den Zielnamen oder die Fähigkeit des antwortenden Geräts gehört.

Eine angeforderte Zwischenstation konnte die Diagnose zusätzlich täuschen. Bei einem teilweisen Quellweg soll die Sonde über einen bestimmten Punkt laufen. ISO 8473 erlaubte einem Knoten ohne Unterstützung dieser Option jedoch, das Paket einfach weiterzuleiten, als sei der Wunsch nie geäußert worden. Ein am Ziel angekommenes Paket konnte also am gewünschten Prüfpunkt vorbeigegangen sein. RFC 1574 verlangte, Fehler wie eine unbekannte Adresse im Quellweg oder einen unzulässigen Pfad sichtbar zu machen. Die Ankunft allein war keine Quittung für die gewählte Route.

Das dritte Werkzeug öffnete die Sicht des einzelnen Routers. Jeder OSI-Host und -Router sollte seine Routingtabellen auf einem Weg außerhalb des normalen Datenverkehrs ausgeben können. Einträge konnten aus ES-IS, IS-IS, IDRP, statischer Konfiguration oder anderen Quellen stammen. Der Text empfahl show osi routes mit Filtern und verwies auf SNMP oder CMIP. Die damalige CLNS MIB lieferte nach eigener Aussage noch nicht alle benötigten Daten. Die Tabelle zeigte eine lokale Weiterleitungsentscheidung; der Traceroute zeigte Rückmeldungen auf einer tatsächlichen Probe.

RFC 1574 ist eine Informationsschrift über erforderliches Verhalten, keine Messung eines bestimmten Ausfalls. Für die Praxisbilanz einer Implementierung wären datierte Echo-Antworten, Wegspuren und Tabellen nötig. Ihr Vorschlag hatte dennoch einen klaren Einsatzwert: Eine Fehlermeldung ist eine präzise Nachricht, solange ihre Herkunft und ihr Code erhalten bleiben. Der Störungsdienst braucht die Nachricht, nicht bloß die Farbe der Kachel.