Zusammenfassung

  • RFC 1266 dokumentierte drei unabhängig entwickelte BGP-Implementierungen und trennte 56 beobachtete Router in sieben autonomen Systemen von den 49 Routern in sechs Systemen des operativen Internets.
  • Mehr als 2.000 Netze sowie unterschiedliche Leitungen, Rechner und Topologien belegten eine konkrete BGP-3-Umgebung von 1991, nicht die weltweite Verbreitung oder spätere Leistungsfähigkeit.
  • Bei CA*Net lautete die Kette Überlastung, Verlust von Routing-Kontrollpaketen und langsame Konvergenz; der Bericht diskutierte Priorisierung und warnte ausdrücklich davor, diesen Extremfall als normal anzusehen.

Die Konfiguration gehörte zur Aussage

RFC 1266 sollte zeigen, wie BGP die damaligen Anforderungen für den Aufstieg zum Draft Standard erfüllt hatte. Das Informationsdokument definierte selbst keinen Internetstandard. Statt einen Reifegrad zu behaupten, legte es die Bestandteile des Nachweises offen.

Die Verbindungen reichten von 56 Kbit/s bis 45 Mbit/s. Die Rechnerklassen reichten von PC/RT bis RS/6000, hinzu kamen spezialisierte cisco-Router und allgemeine Unix-Workstations. Die Topologien umfassten dünn besetzte Ringe und Bäume ebenso wie dichte Backbones. Der vollständige, über BGP geführte Satz externer Routen umfasste deutlich mehr als 2.000 Netze.

Diese Unterschiede sind nicht bloß dekorative Vielfalt. Eine langsame Leitung beansprucht Warteschlangen anders als eine schnelle. Betriebssystem und Hardware beeinflussen Pufferung und Ablaufplanung. Ein Ring erzeugt andere Abhängigkeiten als ein dichtes Backbone. Ein Messwert für Konvergenz lässt sich daher nicht von der Topologie, dem Verkehr und der Behandlung von Kontrollpaketen lösen und anschließend als Eigenschaft des Protokollnamens weiterreichen.

Sieben Router blieben im Bericht, aber nicht im Betriebsnenner

Der Bericht führte die Population einzeln auf: CA*Net stellte 10 Border-Router, das T1 NSFNET Backbone 20, das T3 NSFNET Backbone 15, das T3 NSFNET Test Network 7, CICNET 2 sowie MERIT und PSC je einen. Zusammen ergab das 56 Router in sieben autonomen Systemen.

Anschließend zog der Text die Testumgebung ab. Zum operativen Internet gehörten 49 Router in sechs autonomen Systemen. Die sieben Router des T3-Testnetzes waren weiterhin erprobte Systeme, aber kein Produktionsnenner. Wer von „56 operativen Routern“ spricht, macht aus zwei sauber bezeichneten Populationen eine größere, aber ungenauere Zahl.

Der Unterschied wertet einen Test nicht ab. Er schützt die Art des Schlusses. Ein Testsystem kann eine Implementierung, eine Verbindung oder einen Fehlerzustand belegen. Ein Betriebssystem belegt zusätzlich, dass diese Konstellation in laufender Nutzung stand. Beides darf in einem Bericht erscheinen, nur nicht unter demselben Etikett.

Drei Implementierungen bedeuteten drei Herkünfte

RFC 1266 nannte drei vollständig unabhängig entwickelte und interoperable Implementierungen. cisco betrieb BGP in seinem eigenen Router-Betriebssystem. Das gemeinfreie gated lief auf mehreren Betriebssystemen, darunter BSD und AIX. Die NSFNET/IBM-Implementierung arbeitete in den T1- und T3-Backbones.

Drei unabhängige Codebasen sind aussagekräftiger als drei Installationen desselben Programms. Sie zwingen verschiedene Teams, Nachrichtenformat, Zustand und Übergänge aus derselben Spezifikation zu rekonstruieren. Interoperabilität zeigt dann eine tatsächlich geprüfte Beziehung zwischen diesen Ausführungen.

Sie beweist jedoch weder identische Qualität noch vollständige Sicherheit. Teams können dieselbe Unklarheit gleich missverstehen. Seltene Fehlerpfade können in allen drei Umgebungen unberührt bleiben. Und dass zwei Nachbarn Nachrichten austauschen, bestätigt nicht automatisch jede lokale Auswahlregel oder jedes spätere Weiterleitungsergebnis.

BGP-3 bewahrte eine Verbindungsgeschichte

RFC 1164 macht die unsichtbare Ausführungsarbeit sichtbar. TCP liefert einen Byte-Strom, keine fertigen BGP-Nachrichten pro Lesevorgang. Eine Implementierung muss Header und Länge prüfen, Teilnachrichten puffern und auf die fehlenden Bytes warten, ohne den Routingprozess zu blockieren.

Auch die Updates sind zustandsbehaftet. Eine angekündigte Route bleibt bestehen, bis sie ausdrücklich zurückgezogen oder ersetzt wird. Zuverlässiger Transport übernimmt Reihenfolge und Wiederholung, doch dadurch wird die pro Nachbar gespeicherte Historie Teil der Korrektheit.

RFC 1267 beschreibt den BGP-3-Vertrag: Zu Beginn einer Verbindung wird der vollständige Zustand übertragen, danach nur noch die Änderungen. Es gibt keinen regelmäßigen vollständigen Abgleich, der eine stille Abweichung automatisch heilt. Fällt die Transportverbindung aus, kehren die Nachbarn in den Zustand Idle zurück und bauen ihren gemeinsamen Zustand neu auf.

Darum besteht „BGP lief“ aus mehreren Nachweisen. Nachrichtenrahmung, gespeicherte Updates, Timer, Routenwahl, lokale Richtlinie und Wiederaufbau können getrennt richtig oder falsch sein. Ein erfolgreicher Verbindungsaufbau deckt diese Flächen nicht gemeinsam ab.

Mehr als 2.000 Netze waren eine Zeitangabe

Der Bericht verzeichnete Produktionseinsatz seit 1989, alle drei Implementierungen, alle wesentlichen Funktionen, Transit-zu-Stub- und Transit-zu-Transit-Beziehungen, regionale Netze, Backbones und Mehrherstellerbetrieb. Auch Authentisierung und Unterdrückung von Routing-Schleifen seien ausgeübt worden.

Das ist ein gewichtiger Nachweis, weil Systeme, Population und Bedingungen benannt sind. Für die zugrunde liegenden CA*Net- und NSFNET-Messungen verwies RFC 1266 auf Vorträge in den Proceedings der zwanzigsten IETF-Sitzung. Der Verweis erlaubt aber nicht, nachträglich Rohdaten, Effektgrößen, Fehlergrenzen oder Wiederholungen zu erfinden, die im RFC selbst nicht stehen.

Ebenso ist die Zahl von mehr als 2.000 Netzen an Protokollversion und Zeitpunkt gebunden. Sie zeigt, dass die damaligen Implementierungen den damaligen externen Routensatz trugen. Sie ist kein Kapazitätstest für BGP-4, spätere Attribute, heutige Richtlinien oder gegenwärtige Produkte.

CA*Net lieferte eine Kausalkette, keinen Schuldigen

Bei CA*Net waren zehn Router über stark genutzte 56-Kbit/s-Leitungen zu einem Ring verbunden. Unter Überlastung verwarfen die Router viele Pakete mit BGP-Informationen. Der Verlust dieser Kontrollinformation verlangsamte die Konvergenz.

Die Reihenfolge war somit Überlastung, Paketverlust, langsame Konvergenz. RFC 1266 widersprach der Vorstellung, ein Austausch von TCP könne die Ursache beseitigen. TCP konnte erneut senden, bestimmte aber nicht, welche Pakete ein überlasteter Router verwarf; BGP hatte die zugrunde liegende Überlastung nicht erzeugt.

Der Bericht nannte zwei Eingriffsflächen. Die Überlastung selbst zu verringern lag außerhalb von BGP. Alternativ ließ sich der Anteil verworfener BGP-Pakete senken, indem Router sie kennzeichneten und bevorzugt behandelten. Als Merkmale kamen IP Precedence, der TCP-Port oder Quell- und Zieladressen in Betracht. CA*Net nutzte Adressen.

Aggressivere TCP-Wiederholung konnte den nächsten Versuch vorziehen, ein kleineres Fenster die Menge möglicherweise veralteter Daten begrenzen. Doch der Bericht bezeichnete das nicht als Heilung. Schnelleres Wiederholen ändert keine Warteschlange, die weiterhin dieselben Kontrollpakete verwirft.

Auch Priorisierung ist zunächst nur eine Entscheidung. Sie verändert, welches Paket Zugang zu einer knappen Ressource erhält. Ein Ergebnisnachweis muss danach Verlust, Update-Verarbeitung, Routenauswahl, Konvergenz und tatsächlich erreichbare Weiterleitung beobachten. Die Konfiguration ist nicht ihr eigener Erfolgsbeleg.

Der Extremfall trug ein Warnschild

CA*Net maß der BGP-Konvergenz ungewöhnlich großes Gewicht bei, weil externe Routen nicht im internen Gateway-Protokoll geführt wurden. BGP-Informationen wirkten dadurch auf das interne Routing im Ring. RFC 1266 bezeichnete die Anordnung als extremen Belastungsfall und erklärte, ihre Ergebnisse sollten nicht als Normalfall gelten. Üblichere Netze würden externe Routinginformationen über ein IGP transportieren.

Diese Einschränkung schwächt die Beobachtung nicht. Sie macht sie nutzbar. Ein Extremfall kann eine Abhängigkeit früher sichtbar machen, ohne zur durchschnittlichen Topologie, zum universellen TCP-Fehler oder zur zeitlosen BGP-Eigenschaft zu werden.

RFC 1268 zieht eine weitere Grenze. Ausgetauschte AS-Pfade und lokale Konfiguration unterstützten Entscheidungen für Stub-, mehrfach angebundene Nicht-Transit- und Transit-Systeme. Eine Routenankündigung war damit weder eine Autorisierung noch ein Geschäftsvertrag oder Lieferversprechen. Der Betriebsbericht belegte die Entscheidungsoberfläche, nicht die Legitimität jeder Entscheidung und nicht den Ausgang jedes Pakets.

Quellen und Grenzen der Schlussfolgerung

Diese Quellen belegen die damalige Spezifikation, Implementierungshinweise, Einsatzannahmen, Codeherkünfte, Population, Routengröße und CA*Net-Beobachtung. Sie belegen keine vollständigen Proceedings-Daten, weltweite Einführung, heutiges BGP-Verhalten, aktuelle Produktkonformität, gegenwärtige Sicherheit, universelle Konvergenz, Erreichbarkeit, Lieferung oder Nutzerwirkung.