Zusammenfassung

  • RFC 1222 ließ zwei logische Routinginstanzen in einem Gerät laufen: eine im Subscriber-IGP, eine im Backbone-IGP, verbunden durch EGP oder BGP.
  • NSFNET-Organisation und angeschlossener Provider blieben jeweils für die Integrität ihrer eigenen Routinginformationen zuständig; Ethernet blieb die administrative Demarkation.
  • Zwei laufende Daemons und eine lokale Session belegten weder Kernel-Isolation noch korrekte Installation, Weiterleitung oder Erreichbarkeit.

Ein gemeinsames Erscheinungsbild verteilte fremde Schwankungen

RFC 1222 von H-W. Braun und Y. Rekhter erschien im Mai 1991 als Vorschlag für einen einfacheren, günstigeren NSFNET-Anschluss. Der RFC Editor führt ihn als Informational, der IETF Datatracker im Legacy stream. Das Memo war kein Internetstandard und kein Einsatzbericht.

In Phase 1 nutzte das 56-Kbps-Backbone Fuzzball und Hello, die Mid-Level-Netze meist RIP; gated übersetzte dazwischen. Das Ganze wirkte wie ein Routingraum. Metrikänderungen konnten jedoch mehrere Verwaltungen durchqueren. Mit wachsender Vermaschung erleichterten fehlende Schranken Schleifen und Instabilität.

Die T1-Phase trennte Backbone-IGP und Client-IGPs. RFC 1093 beschrieb die Schnittstelle; RFC 1092 ergänzte Vertretungsabkommen, Policy-Datenbank und das Verwerfen unberechtigter Ankündigungen. Exterior Routing begrenzte interne Metrikschwankungen. Es bewies weder Berechtigung jeder Route noch Pakettransport.

Zwei logische Stellen mussten nicht zwei Geräte sein

Die saubere Trennung verlangte bislang einen eigenen Peer des Subscribers, der seinem IGP angehörte und EGP/BGP mit dem NSFNET-Knoten sprach. Für viele kleine T3-Standorte waren Gerät und Betriebskomplexität eine unnötig hohe Eintrittskosten.

RFC 1222 formulierte das Minimum: zwei logische Routingentitäten und ein Inter-Domain-Mechanismus dazwischen. Eine Instanz gehörte zum Subscriber-IGP, die andere zum Backbone-IGP. Zwei Daemons konnten in einem Unix-Rechner über Loopback oder IPC kommunizieren.

BGP nach RFC 1163 tauschte Erreichbarkeit zwischen autonomen Systemen. Eine Session auf lo0 verkürzte die Leitung, nicht die Zuständigkeit. Importregeln, Herkunft und Konfigurationsbesitz blieben getrennt.

Der gemeinsame Kernel verband Ausfallflächen

Das Memo warnte vor unerwünschter gleichzeitiger Kernel-Interaktion beider Daemons. Gemeinsame Tabellen, Schnittstellen, Ressourcen und Neustarts konnten logisch getrennte Prozesse operativ koppeln.

Darum ist die Beweiskette gestuft: Prozessstart, Session, Routenannahme, Kernel-Installation, Datenweiterleitung und Zielbeobachtung sind verschiedene Ereignisse. Kein früher Eintrag darf einen späteren ersetzen.

Starke Firewalls zwischen den IGPs und Exterior-Tags an importierten Informationen sollten den Kontext bewahren. Ein Tag authentifizierte die Route nicht und bewies nicht, dass spätere Software ihn erhielt oder richtig nutzte.

Konfiguration blieb bei der beschriebenen Seite

Die Kontrolle sollte verteilt bleiben. Backbone-Organisation und angeschlossener Provider waren je für die Integrität eigener Informationen verantwortlich. Der regionale Client konnte die Konfiguration des zu seinem IGP gerichteten Daemons liefern und damit den Eintritt in seine Domäne steuern.

Der Ethernet-Anschluss blieb administrative und betriebliche Demarkation. Ein Backbone-Protokoll konnte nicht allein die Client-Konfiguration bezeugen; dessen Routingtabelle wiederum nicht das Backbone-Forwarding. Zugewiesene Verantwortung war noch keine beobachtete Integrität.

Langfristig konnte die Grenze zur C-NSS-Cloud wandern. Dann mussten zwei Organisationen das Medium zum E-NSS verwalten. PPP und Leitungsmessung halfen, doch heterogene Geräte erschwerten die Fehlerzuordnung. Link-up war weder Ursachenbeweis noch Servicebeleg.

RFC 1222 erlaubte physische Verdichtung nur mit sachlicher Trennung. Routenursprung, Entscheidung, Kernelzustand, Hardwarefehler, Weiterleitung und Ergebnis blieben eigene Aufzeichnungen.

Quellen