Routing und die Steuerungsebene

Ein Router trifft für jedes eintreffende Datagramm eine lokale Entscheidung: Über welche Ausgangsverbindung soll es als Nächstes übertragen werden? Die Datenebene schlägt dazu in der Weiterleitungstabelle nach. Die Steuerungsebene bestimmt den Inhalt der Tabelle anhand von Informationen über Ziele und das Netz jenseits des Routers.

Zwei Möglichkeiten, die Steuerung zu organisieren

Bei der routerbasierten Steuerung führt jeder Router Routingsoftware aus und tauscht Nachrichten mit anderen Routern aus. OSPF und BGP verwenden diese Anordnung. Bei der logisch zentralisierten Steuerung verschafft sich Software zur Netzsteuerung eine netzweite Sicht und installiert über einen Controller Weiterleitungsregeln in den Geräten. Das ist der SDN-Ansatz. „Logisch zentralisiert“ beschreibt den Steuerungsdienst aus Sicht seiner Nutzer; der Dienst kann auf mehreren physischen Servern laufen.

Weiterleitung ist ein schneller lokaler Vorgang, der häufig in Hardware umgesetzt wird. Routing reagiert in einem langsameren Zeitmaßstab auf Änderungen von Verbindungen, Kosten und Richtlinien. Ein Datagramm wartet nicht an jedem Hop auf eine neue Berechnung des Ende-zu-Ende-Pfades. Es folgt den bereits installierten Einträgen.

Das Netz als gewichteten Graphen darstellen

In einem Graphen $G=(N,E)$ sind die Knoten Router und die Kanten Verbindungen. Ein direkt verbundenes Paar hat Verbindungskosten $c(x,y)$. Eine fehlende direkte Verbindung hat die Kosten $\mathrm{\infty }$. In den durchgerechneten Graphen sind die Kosten symmetrisch: $c(x,y)=c(y,x)$. Der Betreiber legt fest, was die Kosten ausdrücken: Verbindungsgeschwindigkeit, Verzögerung, Geld oder ein anderes sinnvolles Maß.

Addiere die Kosten entlang eines Pfades. Kostet A–B 3 und kosten A–C und C–B jeweils 1, kostet der direkte Pfad 3, während A–C–B 2 kostet. A sendet Verkehr für B an C. Das Zählen der Verbindungen würde hier zur falschen Entscheidung führen; die Hopzahl entspricht nur dann den Pfadkosten, wenn jede Verbindung 1 kostet.

Den Algorithmus nach seinen Informationen einteilen

Ein globaler Algorithmus nutzt vollständige Topologieinformationen. Das erfordert keinen einzelnen Rechner: OSPF führt in jedem Router unabhängig einen globalen Link-State-Algorithmus aus. Ein dezentraler Algorithmus ermittelt sein Ergebnis durch lokalen Austausch, wie beim Distanzvektorrouting.

Andere Einteilungen beschreiben, wann sich Routen ändern. Statische Routen ändern sich langsam, häufig durch manuelle Eingriffe. Dynamische Protokolle reagieren auf Änderungen im Netz. Lastabhängige Kosten richten sich nach der aktuellen Überlastung; lastunabhängige Kosten tun das nicht. OSPF und BGP sind dynamische Protokolle, deren übliche Routenmetriken kurzfristigen Laständerungen nicht folgen.

Routing und Weiterleitung verbinden

Ein Algorithmus ist das Berechnungsverfahren; ein Protokoll stellt Nachrichtenformate, Zeitgeber und Austauschregeln bereit. Der Dijkstra-Algorithmus ist ein Berechnungsverfahren. OSPF ist ein Protokoll, das dessen Eingabedaten bereitstellt.

Der fertige Weiterleitungseintrag ordnet einem Zielpräfix eine Ausgangsverbindung zu. Jeder Router wählt seinen eigenen nächsten Hop, sodass der vollständige Pfad aus den Tabellen der Router entsteht. Während der Konvergenz können widersprüchliche Tabellen Schleifen erzeugen; die TTL sorgt schließlich dafür, dass ein im Kreis laufendes IPv4-Datagramm verworfen wird. Zwischen Organisationen muss eine gute Route auch die Richtlinien erfüllen: Ein Betreiber kann einen kostengünstigen Pfad ablehnen, weil er darüber Verkehr übertragen würde, zu dessen Übertragung er sich nicht bereit erklärt hat.

Beim Link-State-Routing beschreibt jeder Router seine eigenen Verbindungen und flutet diese Beschreibung durch das Netz. Sobald die Datenbanken übereinstimmen, hat jeder Router denselben Graphen. Jeder Router führt den Dijkstra-Algorithmus mit sich selbst als Quelle aus, sodass aus denselben Eingabedaten für jeden Router ein anderer Baum mit eigener Wurzel entsteht.

Vorläufige und endgültige Kosten unterscheiden

Für die Quelle $u$ sind $D(v)$ die bisher gefundenen günstigsten Kosten zu $v$ und $p(v)$ der Vorgänger auf diesem Pfad. Die Menge $N^{\mathrm{\prime }}$ enthält Router, deren minimale Kosten endgültig feststehen. Beginne mit der Quelle in dieser Menge, ihren direkten Nachbarn mit den jeweiligen Verbindungskosten und allen anderen Routern mit unendlichen Kosten.

Wähle in jeder Iteration die kleinsten vorläufigen Kosten außerhalb von $N^{\mathrm{\prime }}$ und füge den zugehörigen Router $w$ zur Menge hinzu. Vergleiche für jeden Nachbarn $v$, der noch außerhalb liegt, den bisherigen Schätzwert mit einer Route über $w$:

Ist die zweite Route günstiger, trage $w$ als Vorgänger ein. Nichtnegative Verbindungskosten sorgen dafür, dass diese Festlegung sicher ist. Ein Wert, der lediglich aktualisiert wurde, bleibt vorläufig, bis sein Router zu $N^{\mathrm{\prime }}$ gehört.

Von Router A aus rechnen

Verwende diese Verbindungen: A–B 3, A–C 1, B–C 1, B–D 4, C–D 6, C–E 2, D–E 1, D–F 3 und E–F 5. Anfangs hat B Kosten von 3, C Kosten von 1 und D, E und F haben unendliche Kosten.

Das Hinzufügen von E ändert zum Beispiel D, weil $3+1=4$ kleiner als 6 ist. D wurde zweimal aktualisiert, bevor sein Wert endgültig wurde. Wer den ersten Schätzwert 7 als Antwort nähme, würde beide Verbesserungen übersehen.

Pfade und erste Hops ermitteln

Folge den Vorgängern rückwärts: F ← D ← E ← C ← A. Kehre die Folge um und erhalte A–C–E–D–F. Die Kosten betragen $1+2+1+3=7$. Die endgültigen Kosten von A aus sind B 2, C 1, D 4, E 3 und F 7.

Eine Weiterleitungstabelle speichert den ersten Hop, nicht den Vorgänger des Ziels. Jeder Pfad in diesem Beispiel beginnt mit A–C, daher ist für A der nächste Hop zu allen fünf Zielen C. Der Vorgänger von F ist D, aber D ist nicht der nächste Hop von A.

Gleiche Kosten, Aufwand und veränderte Last

Haben zwei Kandidaten dieselben kleinsten Kosten, kann jeder von ihnen zuerst endgültig festgelegt werden. Die minimalen Kosten bleiben gleich, obwohl sich ein einzelner gewählter Pfad unterscheiden kann. OSPF kann mehrere gleich teure Pfade zur Lastaufteilung beibehalten.

Der einfache Algorithmus prüft in jeder seiner $n-1$ Iterationen die Kandidaten und erreicht damit eine Laufzeit von $O(n^2)$; eine Prioritätswarteschlange kann dies verbessern. Auch das Link-State-Fluten benötigt Nachrichten, weil geänderte Verbindungsinformationen jeden Router im jeweiligen Flutungsbereich erreichen müssen.

Lastabhängige Kosten können eine Rückkopplung erzeugen. Alle Router erkennen einen wenig belasteten Pfad, verlagern Verkehr dorthin und machen ihn teuer; die nächste Berechnung verlagert den Verkehr zurück. Lastunabhängige Kosten vermeiden diese Art der Rückkopplung. Zufällig gewählte Berechnungszeitpunkte können ebenfalls gleichzeitige Wechsel verringern; Router, die zu unterschiedlichen Zeiten beginnen, können sonst im Laufe der Zeit in denselben Takt geraten.

Ein Router kann brauchbare Pfade lernen, ohne den gesamten Graphen zu kennen. Beim Distanzvektorrouting kennt er die Kosten seiner eigenen Verbindungen und die neuesten Kostenschätzungen, die er von jedem Nachbarn erhalten hat. Aus diesen Schätzungen erstellt er seinen eigenen Distanzvektor, eine Liste der geschätzten Kosten zu allen Zielen.

Die erste Verbindung zur Schätzung des Nachbarn addieren

Für ein Ziel $y\mathrm{\ne }x$ lautet die Bellman-Ford-Gleichung

Prüfe jeden Nachbarn $v$. Addiere die Kosten, um diesen Nachbarn zu erreichen, zu dessen Kosten zum Ziel und wähle dann die kleinste Summe. Der Nachbar, der das Minimum ergibt, wird zum nächsten Hop. Die Kosten eines Routers zu sich selbst bleiben 0; sie werden nicht durch eine Route über einen Nachbarn ersetzt.

Während des Austauschs verwenden Router Schätzwerte $D$ anstelle der endgültigen Distanzen $d$. Diese Schätzwerte können sich ändern, wenn Informationen sich weiter im Netz ausbreiten.

Starten, empfangen, neu berechnen, bekannt geben

Beim Start erfasst ein Router 0 für sich selbst, die direkten Verbindungskosten zu Nachbarn und unendlich für andere Ziele. Er sendet diesen Vektor an seine Nachbarn. Ein neuer Vektor von einem Nachbarn oder eine Änderung einer lokalen Verbindung löst eine Neuberechnung aus. Ändert sich der eigene Vektor des Routers, gibt er den neuen Vektor bekannt; andernfalls hat er keinen geänderten Schätzwert weiterzugeben.

Der Prozess ist verteilt, iterativ und asynchron. Router müssen nicht in aufeinander abgestimmten Runden aktualisieren. Informationen können dennoch entfernte Router erreichen, weil die überarbeitete Schätzung jedes Nachbarn zur Eingabe einer weiteren Berechnung wird.

Ein Beispiel mit drei Routern berechnen

Die Verbindungen A–B 4, B–C 1 und A–C 7 ergeben diese Anfangsvektoren, geordnet nach den Zielen A, B, C:

Nachdem A von B gehört hat, vergleicht A seine beiden Routen zu C:

A wählt B als nächsten Hop. C führt die entsprechende Berechnung für A aus und erhält 5 über B. Ein weiterer Austausch lässt die Vektoren unverändert. Bei festen Verbindungskosten und korrekter Ausführung sind die Router konvergiert.

Die Weiterleitungseinträge von A lauten „B → B, Kosten 4“ und „C → B, Kosten 5“. A weiß, dass B Kosten von 1 zu C bekannt gibt. A braucht weder den vollständigen Pfad von B noch eine Zeichnung der Verbindungen hinter B.

Wie RIP das Protokoll bereitstellt

Das Routing Information Protocol (RIP) implementiert Distanzvektorrouting anhand der Hopzahl. Jede Verbindung kostet 1, der längste nutzbare Pfad hat 15 Hops, und 16 bedeutet nicht erreichbar. RIP sendet alle 30 Sekunden regelmäßige Aktualisierungen über UDP-Port 520. Eine Route, die 180 Sekunden lang nicht erneuert wurde, läuft ab.

Regelmäßige Nachrichten gehören zum Protokoll; die Regel des zugrunde liegenden Algorithmus für geänderte Vektoren beschreibt, wann neue Informationen weiterzugeben sind. RIP nutzt auch ereignisgesteuerte Aktualisierungen, um Änderungen früher zu senden. Werden diese Ebenen verwechselt, kann die falsche Aussage entstehen, ein stabiler RIP-Router sende überhaupt keine Nachrichten.

Distanzvektorschätzungen werden nicht einmal berechnet und dann eingefroren. Eine neue Angabe eines Nachbarn kann den bevorzugten nächsten Hop ändern, selbst wenn alle lokalen Verbindungen unverändert bleiben. Umgekehrt muss der Empfang einer Nachricht den eigenen Vektor des Routers nicht ändern, wenn keine der neuen Summen seine gewählten Routen verbessert oder ersetzt.

Eine Distanzvektoraktualisierung kann einen Pfad beschreiben, der von dem Router abhängt, der sie empfängt. Ist diese Abhängigkeit nicht sichtbar, können zwei Router jeweils annehmen, der andere habe eine nutzbare Route. Deshalb kann es schwieriger sein, eine Erhöhung der Verbindungskosten zu verbreiten als eine Senkung.

Eine günstigere Verbindung wird schnell bekannt

A–B habe Kosten von 2, B–C von 1 und A–C von 20. B erreicht A direkt mit Kosten von 2; C erreicht A über B mit Kosten von 3. Sinken die Kosten von A–B auf 1, gibt B 1 bekannt und C ändert seine Kosten auf 2. Wenn C wiederum 2 bekannt gibt, behält B seine direkte Route. Die Verbesserung stabilisiert sich nach diesen beiden geänderten Aktualisierungen.

Eine teure Verbindung legt veraltete Informationen offen

Beginne erneut mit den Kosten 2, 1 und 20 und erhöhe A–B auf 40. B hat noch die frühere Angabe von C mit Kosten von 3 zu A. B wählt C, weil $1+3=4$ kleiner als 40 ist. C sendet weiterhin an B. Datagramme für A pendeln nun zwischen B und C, bis ihre TTL abläuft.

C erfährt die Kosten 4 von B und berechnet 5. B erfährt 5 und berechnet 6. Die Schätzwerte steigen weiter, obwohl keiner der beiden einen unabhängigen Pfad zu A beschreibt. Das ist Count-to-Infinity: Die schlechte Nachricht verbreitet sich über eine Folge irreführend kleiner Schätzwerte.

Hier beendet eine Alternative schließlich die Schleife. Wenn B 20 bekannt gibt, vergleicht C seine direkten Kosten von 20 mit 21 über B und wählt die direkte Verbindung. B entscheidet sich dann für 21 über C. Ohne nutzbare Alternative oder einen endlichen Wert für unendlich kann das Zählen wesentlich länger weitergehen.

Die Abhängigkeit mit Poisoned Reverse bekannt geben

Bei Poisoned Reverse teilt ein Router dem Nachbarn, den er für ein Ziel nutzt, mit, dass seine Distanz zu diesem Ziel unendlich ist. Anfangs nutzt C den Router B, um A zu erreichen, und gibt B daher unendlich bekannt. B kann C nicht mehr für eine unabhängige Alternative halten.

Nach der Kostenerhöhung wählt B daher seine direkten Kosten von 40. C erfährt 40 und wählt seine direkte Verbindung mit Kosten von 20. Nun kann C dem Router B 20 bekannt geben, und B wählt Kosten von 21 über C. Der bekannt gegebene Wert hängt vom Empfänger ab: C kann anderen Nachbarn seine tatsächlichen Kosten melden und zugleich die Route gegenüber B mit unendlich angeben, wenn B sein nächster Hop ist.

Split Horizon lässt eine solche Route in der Aktualisierung weg, statt unendlich bekannt zu geben. Poisoned Reverse verhindert diese Abhängigkeitsschleife zwischen zwei Routern, längere Schleifen können aber weiterhin auftreten. Ereignisgesteuerte Aktualisierungen beschleunigen die Verbreitung von Änderungen. RIP definiert unendlich außerdem als 16 und begrenzt damit sowohl die Zähldauer als auch die nutzbare Netzgröße.

Die beiden Routingfamilien vergleichen

Eine vollständige Link-State-Verbreitungsrunde verursacht bei $n$ Routern und $e$ Verbindungen einen Nachrichtenaufwand in der Größenordnung von $n\cdot e$. Die einfache lokale Berechnung hat eine quadratische Laufzeit. Der Nachrichtenaufwand beim Distanzvektorrouting hängt davon ab, wie viele aufeinanderfolgende Schätzwerte sich ändern; die Kommunikation nur mit Nachbarn garantiert keine schnelle Konvergenz.

OSPF und IS-IS nutzen Link-State-Routing. RIP nutzt Distanzvektoren. BGP ist ein verwandtes Pfadvektorprotokoll: Die bekannt gegebene AS-Folge legt Abhängigkeiten offen und ermöglicht Routern, Pfade zurückzuweisen, die ihre eigene AS-Nummer enthalten.

Das Internet ist zu groß und wird zu unabhängig verwaltet, um jeden Router als Knoten in einem einzigen flachen Routingsystem zu behandeln. Jede Organisation braucht die Kontrolle über ihr eigenes internes Netz und muss zugleich nutzbare Routen zu anderen Organisationen anbieten. Autonome Systeme ermöglichen diese Aufteilung.

Die administrative Grenze bestimmen

Ein autonomes System, kurz AS, ist eine Gruppe von Routern unter einer einheitlichen Verwaltung, die nach außen eine einheitliche Routingrichtlinie vertritt. Öffentliche AS-Nummern, kurz ASNs, kennzeichnen diese Systeme weltweit. Regionale Internetregistrierungsstellen verteilen AS-Nummernressourcen. Der ursprüngliche Nummernraum umfasste 16 Bits, bis 65.535; heutige AS-Nummern verwenden 32 Bits.

Ein AS ist eine Routingdomäne, ein Internetanbieter dagegen ein Unternehmen. Eine Universität oder ein Inhalteanbieter kann ein AS betreiben, und ein Internetanbieter kann mehrere betreiben. Wer diese Begriffe gleichsetzt, übersieht die tatsächlichen Grenzen der Richtlinien.

Für verschiedene Aufgaben unterschiedliche Protokolle nutzen

Ein Interior Gateway Protocol (IGP) stellt interne Routen bereit. Innerhalb einer Routingdomäne verwenden Router ein gemeinsames IGP, damit sie die dafür benötigten Informationen austauschen können. Verschiedene AS können unterschiedliche IGPs wählen. Ein Anbieter mit IS-IS kann sich mit einer Universität verbinden, die OSPF nutzt, weil ihr externer Routenaustausch über BGP erfolgt.

Die Hierarchie erfüllt zwei Anforderungen. Sie verringert die Menge weltweiter Einzelinformationen, die interne Router verarbeiten müssen, und bewahrt die administrative Autonomie. Eine lokale Verbindungsänderung muss nicht die vollständige interne Topologie gegenüber jedem anderen AS offenlegen.

Die Wahl eines Ausgangs mit einem internen Pfad verbinden

Ein Gateway-Router verbindet sich mit einem anderen AS. Für ein externes Ziel ermittelt BGP eine nutzbare Route und deren Gateway-Adresse als nächsten Hop. Das interne Protokoll liefert den Pfad zu dieser Adresse. Zusammen ergeben diese Entscheidungen den Weiterleitungseintrag für ein eintreffendes Paket.

Angenommen, Router R erfährt, dass 198.51.100.0/24 über Gateway G erreichbar ist. OSPF gibt an, dass der Pfad von R zu G über Nachbar H beginnt. Der Weiterleitungseintrag von R für das externe Präfix nutzt die Verbindung zu H. G ist der Ausgang aus dem AS, während H der unmittelbare nächste Hop von R ist; diese Rollen müssen nicht demselben Router zukommen.

Erkennen, wann ein Ausgang genügt

Ein kleiner Kunde mit einer externen Verbindung hat keine Wahl zwischen Ausgängen. Eine IPv4-Standardroute, 0.0.0.0/0, kann externen Verkehr in Richtung dieser Verbindung senden. Die Kenntnis aller Internetrouten würde keinen alternativen Ausgang schaffen.

Bei mehreren Gateways sind Informationen zur Erreichbarkeit wichtig: Ein Gateway kann ein Präfix anbieten, das ein anderes nicht anbietet, oder eine Richtlinie kann einen Anbieter bevorzugen. BGP verteilt die möglichen Routen; das IGP überträgt die Pakete weiterhin zum gewählten Ausgang.

Innerhalb eines AS kann ein Betreiber Verbindungskosten entsprechend den internen Leistungszielen wählen. Zwischen AS stehen Kosten neben Vereinbarungen über bezahlten Transit, Peering-Partner und den Verkehr, den ein Betreiber überträgt. Deshalb reicht es bei der Wahl einer Internetroute nicht aus, eine Berechnung kürzester Pfade über die nächste administrative Grenze hinaus fortzusetzen.

Open Shortest Path First (OSPF) ist ein Link-State-IGP. Jeder Router erfährt die Topologie innerhalb seines Bereichs, führt den Dijkstra-Algorithmus von sich selbst aus und leitet Routen zu Subnetzen ab. OSPFv2 dient IPv4; OSPFv3 wurde für IPv6 entwickelt.

Kosten wählen und Nachbarn entdecken

Der Betreiber legt die Verbindungsgewichte fest. Sind alle Gewichte gleich 1, entstehen Routen mit minimaler Hopzahl. Eine beispielhafte Regel mit umgekehrt proportionaler Geschwindigkeit und einer Referenz von 10 Gbit/s lautet:

Sie ergibt die Gewichte 1, 10 und 100 für Verbindungen mit 10 Gbit/s, 1 Gbit/s und 100 Mbit/s. Das Gewicht ist ein konfiguriertes Routingmaß, keine Entfernung in Kilometern.

Hello-Pakete dienen dazu, Nachbarn zu entdecken und Nachbarschaften aufrechtzuerhalten. Eine übliche LAN-Einstellung sendet alle 10 Sekunden Hello-Pakete und nutzt ein Ausfallintervall von 40 Sekunden. Ein einzelnes fehlendes Hello ist daher nicht gleichbedeutend damit, dass der Nachbar für ausgefallen erklärt wird. Benachbarte Router synchronisieren ihre Datenbanken mithilfe von Database-Description-Paketen, Link State Requests, Link State Updates und Link State Acknowledgments. Router mit synchronisierten Datenbanken bilden eine Adjazenz.

Aktuelle Verbindungsbeschreibungen fluten

Ein Link State Advertisement (LSA) beschreibt Routinginformationen. Ein Router-LSA erfasst die Verbindungen und Kosten eines Routers. LSAs werden in Link-State-Update-Paketen übertragen; ein LSA ist die bekannt gegebene Information und nicht die Bezeichnung für jedes OSPF-Paket.

Geänderte Verbindungen lösen neue Ankündigungen aus. Router erneuern ihre eigenen LSAs außerdem mindestens alle 30 Minuten. Ein LSA wird entfernt, wenn es das Höchstalter von einer Stunde erreicht. Anhand von Sequenzinformationen und Alter können Router aktuelle von alten Beschreibungen unterscheiden.

OSPF wird mit der Protokollnummer 89 direkt in IP übertragen. Es stellt selbst Quittungen und Übertragungswiederholungen bereit. In Broadcastnetzen erreicht 224.0.0.5 alle OSPF-Router und 224.0.0.6 die Designated Router.

Adjazenzen im LAN verringern

Ein LAN wählt einen Designated Router (DR) und einen Backup Designated Router (BDR). Die anderen Router bilden mit diesen beiden vollständige Adjazenzen, statt dass jedes Paar adjazent wird. Der DR gibt das gemeinsam genutzte LAN in einem Netzwerk-LSA bekannt.

Für sechs Router wären bei vollständiger Vermaschung $6\times 5\mathrm{/}2=15$ Adjazenzen nötig. Vier gewöhnliche Router verbinden sich jeweils logisch mit DR und BDR, hinzu kommt eine Adjazenz zwischen DR und BDR: $4\times 2+1=9$. Nachbarn können einander hören, ohne alle vollständig adjazent zu werden.

Nach einem Verbindungsausfall neu berechnen

Betrachte die Verbindungen A–B 3, A–C 1, B–C 1, B–D 4, C–D 6, C–E 2, D–E 1, D–F 3 und E–F 5. A erreicht E zunächst mit Kosten von 3, D mit 4 und F mit 7 über C und E.

Fällt C–E aus, fluten C und E neue Router-LSAs, in denen die Verbindung entfernt ist. Die Neuberechnung ergibt für A die Kosten B 2, D 6, E 7 und F 9. Die Pfade zu D und F nutzen nun C–B–D. Der erste Hop von A bleibt weiterhin C: Ein geänderter vollständiger Pfad erfordert keinen geänderten ersten Weiterleitungshop.

OSPF unterstützt authentifizierte Routingnachrichten und Equal-Cost Multipath (ECMP). Kryptografische Authentifizierung ist stärker als ein Klartextpasswort; sie prüft den berechtigten Ursprung und die Integrität von Nachrichten. ECMP erlaubt einem Router, mehrere gleich teure Pfade zu behalten. Diese Funktionen arbeiten mit Link-State-Informationen, nicht mit ausgetauschten Tabellen geschätzter Distanzen zu Zielen.

Ein Router in einem großen AS muss nicht jede interne Verbindung als Teil eines einzigen detaillierten Graphen verarbeiten. OSPF-Bereiche teilen die Link-State-Datenbank und die Berechnung kürzester Pfade auf. Router behalten lokale Einzelheiten und lernen Routen kennen, die Ziele außerhalb ihres eigenen Bereichs beschreiben.

Bereiche über den Backbone verbinden

Der Backbone ist Bereich 0, auch 0.0.0.0 geschrieben. Andere Bereiche sind an ihn angebunden. Verkehr zwischen zwei Bereichen außerhalb des Backbones gelangt zunächst zum Backbone und dann in den Zielbereich.

Ein Area Border Router (ABR) verbindet Bereiche, darunter den Backbone. Er verwaltet für jeden angebundenen Bereich eine eigene Datenbank und gibt Routen zwischen ihnen bekannt. Informationen über ein entferntes Subnetz können die Grenze überschreiten, ohne alle Router und Verbindungen des entfernten Bereichs offenzulegen. Eine Zusammenfassung kann außerdem geeignete Präfixe bündeln; sie setzt nicht voraus, dass jedes entfernte Subnetz in einem einzigen Sammelpräfix aufgeht.

Ein AS Boundary Router (ASBR) speist Routen von außerhalb der OSPF-Domäne ein, etwa Routen, die von einem anderen AS gelernt wurden. Ein ABR überquert eine Bereichsgrenze; ein ASBR speist externe Routinginformationen ein. Ein Gerät kann beide Rollen einnehmen.

Ankündigungen ihrem Zweck zuordnen

Typ 1 und 2 beschreiben den detaillierten Graphen des Bereichs. Typ 3 und 4 übertragen Erreichbarkeitsinformationen zwischen Bereichen. Typ 5 verbreitet sich normalerweise im gesamten AS, wobei spezielle Bereichstypen externe Ankündigungen einschränken.

Ein Paket zwischen Bereichen verfolgen

Das Paket eines Hosts startet in Bereich 7 und ist für Bereich 9 bestimmt. Es folgt zunächst Routen innerhalb von Bereich 7 zu einem ABR, durchquert Bereich 0 bis zu einem an Bereich 9 angebundenen ABR und folgt dann Routen innerhalb von Bereich 9. Dies ist eine Hierarchie innerhalb eines AS; durch das Überschreiten einer Bereichsgrenze wird das Paket nicht zu Inter-AS-Verkehr.

Ein interner Router hat alle Schnittstellen in einem Bereich. Ein Backbone-Router hat mindestens eine Schnittstelle in Bereich 0. Ein ABR ist ebenfalls ein Backbone-Router, die Rollenbezeichnungen schließen einander also nicht aus.

Verstehen, was ein lokaler Ausfall andernorts ändert

Die Aufteilung von ungefähr 400 Routern in vier Bereiche mit jeweils etwa 100 Routern kann den detaillierten Graphen jedes Routers erheblich verkleinern, während Routen zwischen Bereichen hinzukommen. Die genaue Datenbankgröße hängt auch von Grenzroutern und bekannt gegebenen Netzen ab.

Fällt eine Verbindung innerhalb eines Bereichs wiederholt aus, bleiben ihre detaillierten LSAs und die vollständige Neuberechnung der kürzesten Pfade auf diesen Bereich beschränkt. Ändert sich dadurch auch die bekannt gegebene Erreichbarkeit oder ändern sich die bekannt gegebenen Kosten eines Ziels, sendet der ABR geänderte Zusammenfassungen. Router andernorts aktualisieren die betroffenen Routen zwischen Bereichen. Bereiche begrenzen somit die Verbreitung von Einzelheiten und Berechnungen; sie verbergen nicht jede Auswirkung eines Ausfalls.

Weniger Einzelheiten haben ihren Preis. Eine Route zwischen Bereichen folgt der Bereichshierarchie und kann sich von der global kostenminimalen Route durch einen flachen Graphen des gesamten AS unterscheiden. Der Betreiber erhält kleinere Datenbanken und stärker begrenzte Änderungen, gibt dafür aber etwas Freiheit bei der Pfadwahl auf.

BGP-4 tauscht Informationen zur Erreichbarkeit von Zielpräfixen aus. Eine Ankündigung besagt, dass das ankündigende Netz eine Route in Richtung dieses Präfixes anbietet. Andere Netze können sie gemäß ihren Richtlinien akzeptieren, gegenüber Alternativen einstufen oder ablehnen.

Eine Sitzung aufbauen

BGP-Router tauschen Nachrichten über eine langlebige TCP-Verbindung an Port 179 aus. eBGP verbindet Router in verschiedenen AS; iBGP verbindet Router im selben AS. Interne Sitzungen verteilen externe Erreichbarkeitsinformationen innerhalb des AS und müssen keinen direkten physischen Verbindungen entsprechen.

Der grundlegende iBGP-Entwurf nutzt eine vollständige Vermaschung der BGP-Router. Größere Netze können Route Reflector einsetzen, um die Zahl der Sitzungen zu verringern. iBGP ersetzt das IGP nicht: Das IGP stellt weiterhin interne Pfade bereit, die zum Erreichen der nächsten BGP-Hops benötigt werden.

Die AS-Nummer bei der Weitergabe einer Route voranstellen

AS 64503 kündigt 203.0.113.0/24 als Ursprung an. Seine Ankündigung an AS 64502 hat den AS-PATH „64503“. AS 64502 verteilt die Route intern über iBGP und kündigt sie dann gegenüber AS 64501 mit dem AS-PATH „64502 64503“ an. Bei der externen Weitergabe wird die Nummer des ankündigenden AS vorangestellt; bei der gewöhnlichen internen Verteilung wird diese Nummer nicht erneut hinzugefügt.

Eine BGP-Route verbindet das Präfix mit Attributen. AS-PATH erfasst die Folge der AS, das letzte zuerst. NEXT-HOP bezeichnet die Routeradresse, an die Verkehr gesendet werden soll, normalerweise eine Schnittstelle am benachbarten Gateway. Ein interner BGP-Router nutzt das IGP, um einen Pfad zu dieser Adresse zu ermitteln.

Eine Schleife auf AS-Ebene zurückweisen

Ein BGP-Router weist eine Route zurück, deren AS-PATH seine eigene AS-Nummer enthält. Empfängt AS 64501 „64502 64501 64503“, würde die Annahme Verkehr entlang einer AS-Folge senden, die zu 64501 zurückführt. Das Mitführen dieser Abhängigkeit macht BGP zu einem Pfadvektorprotokoll und vermeidet das Count-to-Infinity-Problem des einfachen Distanzvektorroutings.

Ein AS-Pfad ist keine Liste aller Router auf dem Paketpfad. Zwei AS-Hops können viele physische Verbindungen umfassen, und Richtlinien können zur Wahl eines längeren AS-Pfades führen. Seine Länge allein sagt wenig über die gemessene Verzögerung aus.

Die grundlegenden Nachrichten interpretieren

Der Standard schlägt eine Haltezeit von 90 Sekunden und Keepalive-Nachrichten alle 30 Sekunden vor. Ausgehandelte Einstellungen können abweichen. Ein BGP-Router nimmt über eine Sitzung gelernte Routen zurück, wenn diese Sitzung ausfällt; eine offene TCP-Verbindung ist kein Nachweis dafür, dass jedes angekündigte Ziel funktioniert.

Nach dem anfänglichen Austausch sendet BGP inkrementelle Änderungen, statt regelmäßig die vollständige Tabelle zu senden. Eine Ratenbegrenzung kann wiederholte Ankündigungen für ein Präfix verringern; der Standard schlägt 30 Sekunden zwischen solchen eBGP-Ankündigungen vor.

TCP sorgt für die Übertragung in der richtigen Reihenfolge zwischen den beiden BGP-Routern. Die BGP-Attribute, Richtlinien und die Verarbeitung von Aktualisierungen bestimmen, welche Routen behalten und weitergegeben werden. Zuverlässiger Transport allein beweist nicht, dass ein Nachbar berechtigt ist, das angekündigte Präfix als Ursprung bekannt zu geben.

Mehrere Gateways können eine Route zum selben Präfix anbieten. Ein BGP-Router wendet zuerst die Importrichtlinie an und vergleicht dann akzeptierte, nutzbare Routen in einer festgelegten Reihenfolge. Er stoppt beim ersten entscheidenden Unterschied; ein späterer Vorteil kann eine frühere Präferenz nicht aufheben.

Attribute der Reihe nach vergleichen

1. Bevorzuge den höchsten LOCAL_PREF, der vom lokalen Betreiber festgelegt wird.
2. Bevorzuge den kürzesten AS-PATH.
3. Bevorzuge den niedrigsten ORIGIN-Wert: IGP, dann EGP, dann INCOMPLETE.
4. Bevorzuge den niedrigsten MED unter Routen aus demselben benachbarten AS.
5. Bevorzuge eine über eBGP gelernte Route gegenüber einer über iBGP gelernten.
6. Bevorzuge die niedrigsten IGP-Kosten zum NEXT-HOP.
7. Bevorzuge die niedrigste BGP-Kennung des ankündigenden Routers, wenn die vorherigen Vergleiche keinen Unterschied ergeben.

Routerimplementierungen können Schritte wie ein herstellerspezifisches lokales Gewicht hinzufügen. LOCAL_PREF wird innerhalb des AS verteilt und bleibt dort. MED ermöglicht einem benachbarten AS, einen bevorzugten Eintrittspunkt vorzuschlagen; MED-Werte verschiedener benachbarter AS werden nach der üblichen Regel nicht verglichen.

Zwei Ausgänge vergleichen

R in AS 64501 erfährt über iBGP zwei Routen zu 203.0.113.0/24. G1 bietet den AS-PATH „64502 64503“ mit IGP-Kosten von 3 an; G2 bietet „64504 64503“ mit IGP-Kosten von 5 an. Beide haben LOCAL_PREF 100 und denselben ORIGIN. Die Pfade enthalten jeweils zwei AS. MED entscheidet nicht zwischen diesen verschiedenen benachbarten AS, und beide Routen sind interne Ankündigungen.

Daher entscheiden die IGP-Kosten: R wählt G1, weil $3<5$. Das ist Hot-Potato-Routing: Sende den Verkehr unter ansonsten gleichwertigen Routen über den intern kostengünstigsten Ausgang.

Erhalten Routen über AS 64504 den LOCAL_PREF 200, gewinnt G2 sofort. Seine höheren internen Kosten spielen dann keine Rolle mehr. Bei gleichem LOCAL_PREF würde ein Pfad, der nur „64503“ enthält, beide Pfade mit zwei AS schlagen, bevor Hot-Potato-Routing berücksichtigt würde.

Den nächsten Hop der gewählten Route auflösen

BGP hat eine Route über G1 gewählt, aber R hat möglicherweise keine direkte Verbindung zu G1. OSPF liefert den kostenminimalen internen Pfad zu dieser Adresse des nächsten Hops. Beginnt der Pfad an Schnittstelle I, lautet der Weiterleitungseintrag „203.0.113.0/24 → I“. Für die Entscheidung sind beide Protokolle nötig: BGP wählt die externe Erreichbarkeit, und das IGP ermittelt die interne Weiterleitung dorthin.

Verschiedene interne Router können unterschiedliche Kosten zu G1 und G2 haben, sodass sie bei ansonsten gleichen BGP-Entscheidungen verschiedene Ausgänge nutzen können. Unabhängige Richtlinien am anderen Ende können außerdem dazu führen, dass sich der Rückweg eines Pakets vom Hinweg unterscheidet. Internetrouting ist häufig asymmetrisch.

Dieselbe Auswahl auf Anycast anwenden

Bei IP-Anycast kündigen mehrere Dienststandorte dasselbe Präfix an. Router wählen unter den Ankündigungen durch die übliche BGP-Auswahl. Ein Client erreicht die Instanz, die aufgrund von Routingrichtlinie, AS-Pfad und internen Kosten bevorzugt wird; dies muss nicht die geografisch nächste Instanz sein.

Das funktioniert gut für kurze Austausche wie DNS-Anfragen. Eine Routingänderung während einer langen TCP-Verbindung kann spätere Pakete zu einer anderen Instanz senden, der der Zustand dieser Verbindung fehlt.

Die Ankündigung einer Route ist eine Einladung, Verkehr in ihre Richtung zu senden. Die Exportrichtlinie eines Betreibers bestimmt daher, welchen Verkehr das Netz zu übertragen anbietet. Kunden-, Anbieter- und Peering-Beziehungen erklären die üblichen Regeln.

Transit und Peering unterscheiden

Ein Kunde bezahlt einen Anbieter für Transit zum und vom restlichen Internet. Zwei Peering-Partner tauschen Verkehr für sich selbst und ihre Kunden aus, häufig ohne gegenseitige Zahlungen. Netze vereinbaren Peering häufig an einem Internetaustauschknoten (IXP).

Peering stellt gewöhnlich keine Route zu allem bereit, was der Peering-Partner über seine eigenen Anbieter erreichen kann. Dieser weiter reichende Dienst ist Transit. Eine Peering-Beziehung beschreibt eine Vereinbarung über Verkehr und nicht nur ein physisches Kabel zwischen Routern.

Import- und Exportentscheidungen unterscheiden

Die Importrichtlinie legt fest, welche empfangenen Ankündigungen akzeptiert werden und welche Präferenz sie erhalten. Die Exportrichtlinie legt fest, welche Routen jedem Nachbarn bekannt gegeben werden. Eine Route kann akzeptiert und lokal genutzt werden, ohne dass sie jedem anderen Nachbarn angeboten wird.

Die üblichen Importpräferenzen bevorzugen Kundenrouten, dann Routen von Peering-Partnern und danach Anbieterrouten. LOCAL_PREF kann diese Reihenfolge abbilden. Kundenverkehr bringt Einnahmen, Verkehr über Peering-Partner vermeidet gewöhnlich Transitgebühren, und Verkehr über Anbieter verursacht Transitkosten. Diese Präferenz kann wichtiger sein als die AS-PATH-Länge.

Die üblichen Exportregeln anwenden

Ein AS gibt auch seine eigenen Ziele gemäß seinen Vereinbarungen bekannt. Die Tabelle beschreibt das übliche kommerzielle Muster; Betreiber setzen Richtlinien durch ausdrückliche Filter und Präferenzen um.

Die breite Bekanntgabe einer Kundenroute zieht Verkehr zum zahlenden Kunden an. Werden von Peering-Partnern und Anbietern gelernte Routen nur Kunden bekannt gegeben, wird kein unbezahlter Transit zwischen externen Netzen angeboten. Entscheidend ist, woher die Route gelernt wurde und wem sie bekannt gegeben wird, nicht in welche Richtung ein einzelnes Paket gerade unterwegs ist.

Einen Kunden mit Multihoming verfolgen

Kunde X, AS 64510, hat die Anbieter B und C. X kündigt beiden sein eigenes Präfix an, um Erreichbarkeit und Ausfallsicherheit zu gewährleisten. X akzeptiert Routen von beiden, nimmt aber eine von B gelernte Route nicht in Ankündigungen an C auf. Ebenso nimmt X die Routen von C nicht in Ankündigungen an B auf. Andernfalls könnte ein Anbieter Verkehr durch X zu Zielen hinter dem anderen Anbieter senden.

Als Beispiel für Peering seien A und B Peering-Partner und W ein Kunde von A. B kann die Route „A W“ nutzen und an seine Kunden exportieren. B hält diese von einem Peering-Partner gelernte Route vor einem anderen Peering-Partner C zurück. Ein Export an C würde Transit zwischen Peering-Partnern über B anbieten.

Innerhalb eines AS kann ein einzelner Betreiber die internen Kosten optimieren. Zwischen AS kontrollieren unabhängige Betreiber Preis, Verpflichtungen zur Verkehrsübertragung und akzeptable Geschäftspartner. Eine fehlende Ankündigung kann eine bewusste Ablehnung der Verkehrsübertragung sein, selbst wenn ein physischer Pfad existiert.

Grundlegende BGP-Ankündigungen beweisen weder den Besitz eines Präfixes noch authentifizieren sie den vollständigen AS-PATH. Eine falsche Ankündigung kann sich durch viele Netze verbreiten, wenn Richtlinien und Validierung sie nicht stoppen. Zwei wichtige Fehler sind Präfix-Hijacking und Route Leaks.

Erkennen, was schiefgeht

Beim Präfix-Hijacking wird ein nicht autorisiertes Präfix oder ein spezifischerer Teil des Präfixes eines anderen angekündigt. Router, die die Route akzeptieren, können Verkehr zum falschen Ursprung senden. Sobald Routen für unterschiedliche Präfixlängen installiert sind, nutzt die Weiterleitung den längsten Präfixabgleich. Eine /24-Route innerhalb eines /22 gewinnt für passende Adressen, selbst wenn das /22 einen kürzeren AS-PATH hat. BGP-Vergleiche zwischen Routen zu einem Präfix und Weiterleitungsvergleiche zwischen verschiedenen Präfixen sind getrennte Entscheidungen.

Ein Route Leak exportiert eine Route über die vorgesehene Richtliniengrenze hinaus. Beispielsweise gibt ein Kunde von einem Anbieter gelernte Routen an einen anderen Anbieter weiter und wird unbeabsichtigt zum Transitnetz. Der Ursprung des Präfixes kann rechtmäßig sein, während die Weitergabe falsch ist.

Aus einem realen Vorfall lernen

Am 24. Februar 2008 kündigte Pakistan Telecom, AS 17557, 208.65.153.0/24 im Rahmen einer YouTube-Sperre im eigenen Land an. Sein Anbieter verbreitete diese spezifischere Route international. Ein großer Teil des Verkehrs für diese YouTube-Adressen wurde nach Pakistan gelenkt.

Der weithin sichtbare Vorfall dauerte von 18:47 bis 21:01 Uhr UTC, etwas mehr als zwei Stunden. YouTube kündigte das /24 selbst und anschließend zwei /25-Präfixe an, um den Verkehr wieder zu empfangen. Der Vorfall endete, als der Anbieter die falsche Route zurücknahm. Eine lokal beabsichtigte Änderung war zu einer internationalen Störung der Erreichbarkeit geworden, weil die Exportfilterung versagt hatte.

Filtern, bevor sich ein Fehler verbreitet

Ein Anbieter kann nur die Präfixe akzeptieren, die ein Kunde als Ursprung ankündigen darf. Eine Präfixobergrenze kann eine Sitzung stoppen, über die plötzlich wesentlich mehr Routen als vereinbart angekündigt werden. Viele Netze filtern außerdem IPv4-Präfixe länger als /24 und IPv6-Präfixe länger als /48. Solche Filter begrenzen die Verbreitung von Ankündigungen; eine technisch spezifischere Route wirkt nur dort, wo sie akzeptiert wird.

Den autorisierten Ursprung mit RPKI prüfen

Die Resource Public Key Infrastructure (RPKI) ermöglicht Adressinhabern, signierte Route Origin Authorizations (ROAs) zu veröffentlichen. Eine ROA nennt die erlaubte Ursprungs-ASN, ein Präfix und die maximal erlaubte Präfixlänge.

Angenommen, AS 64503 ist für 203.0.113.0/24 mit der maximalen Länge /24 autorisiert:

Decken mehrere validierte Autorisierungen eine Route ab, macht eine hinsichtlich Ursprung und Länge passende Autorisierung die Route gültig. Gibt es abdeckende Autorisierungen, aber keine passende, ist die Route ungültig. Netze entscheiden, wie sie auf diese Zustände reagieren; das Zurückweisen ungültiger Routen blockiert viele nicht autorisierte Ursprünge. „Nicht gefunden“ bedeutet, dass eine Autorisierung fehlt, nicht dass ein falscher Ursprung nachgewiesen wurde.

Die Ursprungsvalidierung prüft die letzte Ursprungs-ASN, nicht jedes Transit-AS oder die Exportbeziehung. Ein gefälschter Pfad, der mit einem autorisierten Ursprung endet, kann diese Prüfung daher bestehen, und ein Leak kann einen gültigen Ursprung behalten. BGPsec ergänzt Mechanismen zur Pfadsignierung, doch Ursprungsvalidierung, Routenfilter und Überwachung bleiben unterschiedliche Schutzmaßnahmen.

Software-defined Networking (SDN) trennt die Paketweiterleitung von der Software, die über das Netzwerkverhalten entscheidet. Switches wenden Flow-Regeln an, während Anwendungen einen Controller nutzen, um den Netzzustand zu lesen und die benötigten Regeln zu installieren. Dadurch wird die Steuerung programmierbar.

Die drei Komponenten bestimmen

Switches der Datenebene führen Weiterleitung anhand von Abgleichbedingungen und Aktionen aus. Ein Flow kann auf Felder mehrerer Schichten passen, darunter Ethernet-Adressen, IP-Adressen und Transportports. Aktionen können ein Paket weiterleiten, verwerfen, ändern oder an den Controller senden.

Der Controller verwaltet den Netzzustand und kommuniziert mit den Geräten. Anwendungen zur Netzsteuerung treffen Entscheidungen, etwa indem sie eine Route berechnen oder eine Regel zur Lastverteilung wählen. Eine Routinganwendung kann weiterhin den Dijkstra-Algorithmus nutzen. SDN ändert den Ort und die Schnittstellen der Steuerung, ohne ein neues Verfahren für kürzeste Pfade zu verlangen.

Die kennzeichnenden Merkmale wirken zusammen: Flow-basierte Weiterleitung, getrennte Steuerungs- und Datenebene, Steuerungsfunktionen außerhalb der Switches und Softwareanwendungen, die das Netzwerkverhalten programmieren.

Die Schichten des Controllers verfolgen

Die Southbound-Schnittstelle verbindet den Controller mit Geräten. OpenFlow ist ein bekanntes Beispiel; auch Managementprotokolle wie SNMP und NETCONF können die Gerätekommunikation unterstützen. Die Northbound-Schnittstelle verbindet Anwendungen mit dem Controller, häufig über eine REST-API. „North“ und „South“ beschreiben Rollen der Software, keine physischen Positionen in einem Netzwerkschrank.

Logische und physische Zentralisierung unterscheiden

Anwendungen sehen einen einheitlichen Controllerdienst mit netzweiter Sicht. Dieser Dienst kann auf einem Server oder einem replizierten Cluster laufen. Ein Cluster kann Last aufteilen und nach dem Ausfall eines Servers weiterarbeiten, sofern der Austausch des Zustands und die Ausfallübernahme korrekt funktionieren. Logische Zentralisierung erfordert keine einzelne physische Maschine.

Ein Controller auf einem einzelnen Server ist eine einzelne Ausfallstelle für seinen Steuerungsdienst. Replikation verringert dieses Risiko, der Controller bleibt aber ein kritischer Teil des Netzes. Anwendungen sind auf eine genaue Sicht der Topologie angewiesen, um brauchbare Regeln zu erzeugen.

Eine Routinganfrage verfolgen

Angenommen, ein Controller erfasst die verfügbaren Verbindungen zwischen vier Switches. Eine Routinganwendung liest diese Topologie über die Northbound-API und berechnet einen kostenminimalen Pfad. Sie fordert den Controller auf, die entsprechenden Weiterleitungseinträge zu installieren. Der Controller übersetzt die Anfrage in Southbound-Nachrichten an die betroffenen Switches. Spätere Pakete folgen lokal diesen installierten Einträgen.

Eine Änderung der Routinganwendung kann somit das Netzwerkverhalten ändern, ohne die integrierte Routingsoftware jedes Switches zu ändern. Dieselbe Weiterleitungshardware kann je nach installierten Regeln Routing, Zugriffskontrolle oder Lastverteilung unterstützen.

SDN wird innerhalb von Organisationsnetzen wie Rechenzentren und privaten Weitverkehrsnetzen eingesetzt. Googles B4 ist ein Beispiel für zentralisierte Steuerung eines privaten Netzes, das Rechenzentren verbindet. ONOS und OpenDaylight sind Beispiele für Open-Source-Controllerplattformen. An Grenzen zwischen unabhängigen Netzen tauscht BGP weiterhin Erreichbarkeitsinformationen aus; SDN-Steuerung innerhalb eines AS und BGP zwischen AS können zusammenarbeiten.

OpenFlow überträgt Befehle und Ereignisse zwischen einem Controller und Switches. Es nutzt TCP mit dem registrierten Port 6653 und kann die Verbindung mit TLS schützen. Der Controller benötigt beide Kommunikationsrichtungen: Er ändert den Weiterleitungszustand und erhält Hinweise darauf, dass sich der Zustand oder die Topologie geändert hat.

Einen Flow-Eintrag lesen

Ein Flow-Eintrag hat Abgleichfelder, eine Priorität, Zähler, Aktionen und Zeitlimits. In einer Tabelle bestimmt der passende Eintrag mit der höchsten Priorität, wie das Paket behandelt wird. Ein breit gefasster Eintrag kann daher gegenüber einer spezifischeren Regel mit höherer Priorität unterliegen.

In OpenFlow 1.3 kann ein Table-Miss-Eintrag mit der niedrigsten Priorität ein Paket behandeln, das zu keinem regulären Eintrag passt. Seine Aktion kann das Paket an den Controller senden. Ohne Table-Miss-Eintrag wird ein nicht zugeordnetes Paket standardmäßig verworfen. Ein fehlender Treffer allein erfordert keine Packet-In-Nachricht.

Nachrichten ihren Aufgaben zuordnen

Flow-Mod und Port-Mod ändern beide den Zustand des Switches, aber nur Flow-Mod bearbeitet Weiterleitungseinträge. Packet-Out behandelt ein bestimmtes Paket; es installiert allein keine Regel für spätere Pakete.

Pfade nach einem Ausfall reparieren

Betrachte die Switches S1 bis S4. Die Verbindung S1–S2 fällt aus, während eine andere Route über S3 und S4 verfügbar bleibt.

1. S1 erkennt den Ausfall seines Ports und sendet Port-Status.
2. Der Controller entfernt die ausgefallene Verbindung aus seiner Sicht des Netzzustands.
3. Die Routinganwendung empfängt das Ereignis über ihr Northbound-Abonnement.
4. Die Anwendung berechnet Pfade auf der geänderten Topologie neu.
5. Eine Komponente zur Flow-Tabellenberechnung wandelt diese Pfade in Switch-Regeln um.
6. Der Controller sendet Flow-Mod-Nachrichten an die Switches, deren Einträge geändert werden müssen, etwa S1, S3 und S4.

Der meldende Switch liefert ein Ereignis; er berechnet nicht selbst eine netzweite Reparatur. Die Anwendung benötigt außerdem installierte Regeln auf den betroffenen Switches, nicht nur einen neuen Pfad, der im Controller gespeichert ist.

Vor dem Verkehr installieren oder auf sein erstes Paket reagieren

Bei proaktiver Installation sind Einträge bereit, bevor Pakete eintreffen. Bei reaktiver Installation sendet eine konfigurierte Aktion das erste Paket eines neuen Flows in Packet-In an den Controller. Der Controller kann eine Regel veranlassen und Packet-Out nutzen, wenn er ein Paket aussenden muss.

Die reaktive Einrichtung verzögert das erste Paket und verursacht Arbeit für den Controller. Sobald der Eintrag existiert, bleiben nachfolgende passende Pakete in der Datenebene. Der Controller verarbeitet ausgewählte Ereignisse und Pakete, nicht jedes Paket in jedem Flow. Ablaufende Einträge können später Flow-Removed-Benachrichtigungen erzeugen, sodass Anwendungen Änderungen am installierten Zustand verfolgen können.

ICMP überträgt Meldungen und Testnachrichten der Vermittlungsschicht innerhalb von IP-Datagrammen. ICMPv4 nutzt die IPv4-Protokollnummer 1. Seine Nachrichten haben einen Typ, einen Code und eine Prüfsumme. Der Typ gibt den allgemeinen Zweck an; der Code präzisiert ihn.

Einen Fehler dem verursachenden Paket zuordnen

Eine ICMPv4-Fehlermeldung enthält den ursprünglichen IP-Header und mindestens die ersten 8 Bytes der ursprünglichen Nutzlast. Dieser Ausschnitt liefert gewöhnlich die Transportinformationen, die zur Identifizierung des betroffenen Datenstroms nötig sind. Die Fehlermeldung geht an den ursprünglichen Sender, der sie dann einem gesendeten Paket zuordnen kann.

Typ 4, Source Quench, gilt als veraltet und ist kein moderner Mechanismus zur Überlastkontrolle.

Vom Fehler zur Meldung gelangen

Ein Router, der die TTL auf 0 verringert, verwirft das Datagramm und meldet eine Zeitüberschreitung. Ein Router ohne Route kann melden, dass das Netz nicht erreichbar ist. Ein Zielhost, der UDP-Daten für einen ungenutzten Port empfängt, kann melden, dass der Port nicht erreichbar ist. Dies sind unterschiedliche Fehler: Dass der Host erreichbar ist, garantiert nicht, dass eine lauschende Anwendung erreicht wird.

ICMP-Fehlermeldungen sind keine zuverlässigen Zustellungsbestätigungen. Filterung, Nachrichtenverlust oder Ratenbegrenzung können verhindern, dass eine Meldung den Sender erreicht. Für einen unbeantworteten Test gibt es daher mehrere mögliche Erklärungen.

IPv4 unterdrückt Fehlermeldungen über andere ICMP-Fehlermeldungen, über Broadcast- oder Multicast-Verkehr und über alle Fragmente außer dem ersten. Diese Regeln verhindern Fehlerkaskaden und übermäßige Antworten. Geräte begrenzen außerdem die Rate, mit der sie Fehlermeldungen erzeugen.

ICMPv6 unterscheiden

ICMPv6 verwendet den IPv6-Next-Header-Wert 58. Seine Fehlertypen sind 1 Ziel nicht erreichbar, 2 Paket zu groß, 3 Zeitüberschreitung und 4 Parameterproblem. Echo-Anfrage und Echo-Antwort haben die Typen 128 und 129. Neighbor Discovery verwendet ebenfalls ICMPv6 und übernimmt in IPv6 die Aufgabe der Nachbarauflösung von ARP.

Die Fehlerregeln von IPv6 enthalten Ausnahmen für Multicast: Eine Paket-zu-groß-Meldung kann als Antwort auf ein Multicast-Paket gesendet werden, ebenso bestimmte Fehlermeldungen zu unbekannten Optionen. Würde man die pauschale Multicast-Unterdrückung von IPv4 auf ICMPv6 anwenden, würde erforderliches Verhalten verhindert.

Path MTU Discovery verfolgen

Bei der klassischen Path MTU Discovery für IPv4 setzt der Sender Don't Fragment. Ein Router mit einer kleineren MTU auf der Ausgangsverbindung verwirft ein zu großes Datagramm und sendet Typ 3, Code 4 zurück, wobei er die MTU der nächsten Verbindung meldet. Der Sender kann die Größe späterer Pakete verringern.

Beispielsweise erreicht ein IPv4-Datagramm mit 1.500 Bytes eine Verbindung mit MTU 1.400 Bytes, während Don't Fragment gesetzt ist. Der Router verwirft es und meldet, dass Fragmentierung nötig ist, mit MTU 1.400. Der Sender passt seine IP-Paketgröße an; der Wert 1.400 Bytes umfasst den IP-Header und ist daher nicht die maximale Anwendungsnutzlast.

IPv6-Router fragmentieren weitergeleitete Pakete nie. Sie senden eine Paket-zu-groß-Meldung zurück, damit die Quelle die Größe anpassen kann. Wird sämtliches ICMP blockiert, entfällt diese Rückmeldung und es kann ein Path-MTU-Blackhole entstehen: Kleine Pakete funktionieren, während größere verschwinden. Gezielte Filterung erhält die für den Netzbetrieb nötigen Nachrichten.

Ping fordert ein Ziel zur Antwort auf. Traceroute nutzt Testanfragen, deren Lebensdauer an aufeinanderfolgenden Hops abläuft, um antwortende Router auf dem Hinweg zu finden. Beide melden Umlaufzeiten, die Hinweg, Erzeugung der Antwort und Rückweg umfassen.

Ein Ping-Ergebnis lesen

Für IPv4 sendet Ping Echo-Anfragen vom Typ 8, Code 0, und empfängt Echo-Antworten vom Typ 0. Jeder erfolgreiche Austausch liefert eine RTT. Erhalten drei von vier Testanfragen eine Antwort, bleibt eine von vier unbeantwortet: Der beobachtete Verlust beträgt 25 %.

Eine Antwort belegt, dass ein Austausch mit dem Ziel zu diesem Zeitpunkt funktioniert hat. Eine fehlende Antwort kann auf einen ausgefallenen Zielhost oder Pfad hinweisen, aber auch darauf, dass Echo-Nachrichten gefiltert oder in ihrer Rate begrenzt werden. Ping testet diese Nachrichten, nicht jedes Anwendungsprotokoll, das den Host nutzen könnte.

Aufeinanderfolgende Hops mit begrenzter TTL sichtbar machen

Traceroute sendet zunächst eine Testanfrage mit TTL 1. Der erste Router verringert sie auf 0, verwirft die Anfrage und kann eine ICMP-Zeitüberschreitungsmeldung zurücksenden. TTL 2 erreicht vor ihrem Ablauf den nächsten Router. Durch Erhöhen der TTL wiederholt sich dieser Vorgang weiter entlang des Pfades. Die Quelle zeichnet die Adresse und die verstrichene Zeit für jede Antwort auf.

Das klassische Unix-Traceroute verwendet UDP-Testanfragen an unwahrscheinliche Zielports, beginnend bei 33434. Am Ziel signalisiert Port nicht erreichbar die Ankunft. Windows-Tracert verwendet Echo-Anfragen und erkennt am Ziel eine Echo-Antwort. Drei Testanfragen pro TTL sind üblich; einzelne Anfragen können bei Lastverteilung unterschiedliche Pfade nehmen.

Eine vollständige Ablaufverfolgung interpretieren

Das Ziel antwortet bei Hop 5. Die gemessene RTT steigt von Hop 3 zu Hop 4 um $95-12=83$ ms und bleibt danach hoch. Das ist mit einem langsameren oder längeren Abschnitt in der Nähe dieser Stelle vereinbar, aber die Differenz ist nicht die Verzögerung der dazwischenliegenden Verbindung in einer Richtung. Die Antworten sind unterschiedliche Pakete, können verschiedene Rückwege nutzen und enthalten unterschiedliche Verarbeitungs- und Warteschlangenverzögerungen. Aus diesen RTT-Werten allein ergibt sich keine Verbindungslänge.

Ausbleibende Antworten und ungewöhnlich hohe RTT-Werte bei mittleren Hops erklären

Eine Zeile mit „* * *“ bedeutet, dass die Testanfragen für diese TTL keine rechtzeitige Antwort erhielten. Antworten spätere Hops, gelangen Pakete weiter durch das Netz. Der nicht antwortende Router kann normal weiterleiten und zugleich seine eigenen ICMP-Antworten unterdrücken.

Ein Router in der Mitte kann auch eine höhere RTT als spätere Router anzeigen. Die Erzeugung einer ICMP-Antwort kann eine niedrigere Priorität als die Weiterleitung von Verkehr erhalten. Eine einzelne langsame Antwort der Steuerungsebene belegt daher keine langsame Weiterleitungsverbindung. Anhaltende Anstiege, die sich bei späteren Hops fortsetzen, verdienen eine andere Betrachtung als ein einzelner Ausschlag.

Die Grenzen der Pfadanzeige beachten

Traceroute zeigt antwortende Routerschnittstellen, keine Liste von AS-Nummern. Die Zuordnung dieser Adressen zu den Netzen, die sie ankündigen, ist ein zusätzlicher Schritt. Die Ablaufverfolgung zeigt auch den Rückweg nicht, obwohl dieser zu jeder RTT beiträgt. Routingrichtlinien und Hot-Potato-Entscheidungen können dazu führen, dass die Gegenrichtung anderen Netzen folgt. Eine separate Ablaufverfolgung in Gegenrichtung kann daher ein anderes Bild ergeben.

Netzwerkmanagement verbindet die Ziele eines Betreibers mit Beobachtungen und Änderungen an Geräten. Sein Konzept hat fünf Teile: einen Managementserver, verwaltete Geräte, deren Daten, Agenten, die diese Daten bereitstellen, und ein Protokoll, das die Agenten mit dem Server verbindet.

Objekte und Nachrichten bestimmen

SNMP, das Simple Network Management Protocol, verwendet gewöhnlich UDP. Agenten lauschen auf Port 161; Manager empfangen Benachrichtigungen auf Port 162. GetRequest liest Objekte, GetNextRequest geht ihre Namensreihenfolge durch, und GetBulkRequest liest viele Werte effizient. SetRequest ändert schreibbare Objekte. Response überträgt das Ergebnis.

Ein Trap ist eine unaufgeforderte Benachrichtigung ohne Quittung auf Anwendungsebene. Ein InformRequest wird vom Empfänger quittiert. Ein Agent kann somit ein Ereignis melden, ohne auf die nächste Überwachungsabfrage zu warten.

Eine Management Information Base (MIB) definiert verwaltete Objekte in Modulen mithilfe der Datendefinitionssprache SMI. Jedes Objekt hat einen Objektidentifikator (OID) in einem weltweiten Namensbaum. Der OID identifiziert ein definiertes Objekt; der Agent stellt dessen aktuellen Wert bereit.

Beispielsweise misst sysUpTime, OID 1.3.6.1.2.1.1.3, die Zeit seit dem Neustart des Managementsystems des Geräts. ifInOctets, OID 1.3.6.1.2.1.2.2.1.10, definiert Zähler für empfangene Bytes pro Schnittstelle. Ein Tabelleneintrag benötigt außerdem die jeweilige Schnittstelleninstanz, um zu bestimmen, welcher Schnittstellenwert gelesen wird.

Die Auslastung aus zwei Abfragen berechnen

Der Zähler einer Schnittstelle mit 100 Mbit/s steigt innerhalb von 60 Sekunden von 1.250.000.000 auf 1.475.000.000 Bytes. Bestimme zuerst die empfangene Menge:

Wandle Bytes in Bits um und dividiere durch die verstrichene Zeit:

Die Eingangsauslastung beträgt $30\mathrm{/}100=\mathrm{0,30}$ oder 30 %. Ein Zähler ist eine kumulierte Summe, keine Rate; sowohl die Differenz als auch die verstrichene Zeit werden benötigt. Wer Bytes und Bits unterscheidet, vermeidet einen achtfachen Fehler.

Überlauf und Neustart erkennen

ifInOctets ist ein 32-Bit-Zähler und läuft nach $2^{32}$ Bytes über. Bei 1 Gbit/s dauert das etwa $2^{32}\times 8\mathrm{/}{10}^9\approx 34$ Sekunden. Ein Intervall von 60 Sekunden kann mehrere Überläufe verbergen, sodass sich die Gesamtverkehrsmenge aus den beiden Werten allein nicht ermitteln lässt. Der 64-Bit-Zähler ifHCInOctets eignet sich für schnelle Schnittstellen.

Wenn höchstens ein Überlauf und kein Zurücksetzen stattgefunden hat, addiere $2^{32}$ zu einer negativen Differenz. Ein Neustart des Geräts oder Zählers muss gesondert behandelt werden; wer jede Abnahme als Überlauf deutet, kann eine falsche Verkehrsspitze erzeugen.

Sichere Überwachung und strukturierte Änderungen wählen

SNMPv1 und SNMPv2c verwenden Community-Zeichenfolgen im Klartext. SNMPv3 unterstützt Authentifizierung, Verschlüsselung und Zugriffskontrolle auf Objektebene; wähle die Sicherheitseinstellungen, die diesen Schutz bieten.

SNMP wird häufig zur Überwachung eingesetzt. Ein SetRequest validiert die angeforderten Änderungen, bevor er sie als Gruppe auf einem Gerät anwendet. Schlägt eine Zuweisung fehl, versucht der Agent, die Änderungen rückgängig zu machen; eine undoFailed-Antwort meldet, dass die Wiederherstellung selbst fehlgeschlagen ist. Dadurch entsteht keine Transaktion über mehrere Geräte hinweg. Auch das Bearbeiten einzelner MIB-Objekte ist bei großen Konfigurationen umständlich. Eine CLI kann von Hand oder per Skript bedient werden, doch Textbefehle für einzelne Geräte werden bei großer Zahl schwieriger zu koordinieren; NETCONF bietet stattdessen strukturierte Konfigurationsoperationen.

NETCONF liest und ändert strukturierte Gerätekonfigurationen. YANG definiert Struktur, Typen und Einschränkungen der verwalteten Daten. Das Protokoll überträgt und übernimmt Daten; das Modell beschreibt deren Bedeutung und die erlaubten Werte.

Eine sichere Sitzung öffnen und Fähigkeiten prüfen

NETCONF läuft normalerweise über SSH auf Port 830; als sicherer Transport kann auch TLS verwendet werden. Client und Server tauschen Hello-Nachrichten aus, die unterstützte Fähigkeiten bekannt geben. Anfragen und Antworten sind XML-kodierte entfernte Prozeduraufrufe (RPCs).

Die Fähigkeiten sind entscheidend. Ein Manager muss ermitteln, ob Candidate-Konfiguration, Validierung oder Confirmed Commit unterstützt werden, bevor er sich darauf verlässt.

Aktive, vorbereitete und Startkonfigurationen unterscheiden

Der Running-Datenspeicher ist aktiv. Ein unterstützter Candidate-Datenspeicher ist eine Arbeitskopie für vorgeschlagene Änderungen, und ein unterstützter Startup-Datenspeicher enthält die beim Start geladene Konfiguration. Die Bearbeitung von Candidate allein lässt Running unverändert. Ein Commit übernimmt die vorbereitete Candidate-Konfiguration in den aktiven Betrieb.

Eine Sperre verhindert widersprüchliche Änderungen, während der Manager arbeitet. Die Validierung prüft die Regeln für Candidate; sie belegt nicht, dass sich der Verkehr nach der Aktivierung weiterhin wie beabsichtigt verhält.

Zwei Geräte koordinieren, ohne eine gemeinsame atomare Übernahme anzunehmen

Um die MTU auf einer Verbindung zwischen R1 und R2 zu ändern, sperrt der Manager beide Candidate-Datenspeicher, sendet edit-config an beide und validiert beide. Schlägt eine der Validierungen fehl, verwirft er beide vorbereiteten Änderungen und hebt die Sperren vor der Aktivierung auf.

Ist die Validierung erfolgreich, übernimmt er die Änderungen auf jedem Gerät und prüft die Antworten. Die Übernahmen sind getrennt: R1 kann sich vor R2 ändern, oder eine Übernahme kann gelingen, während die andere fehlschlägt. Der Manager muss dieses Teilergebnis erkennen und beheben, zum Beispiel durch Wiederherstellen der früheren Konfiguration.

Bei einem Confirmed Commit macht ein Gerät die Änderung automatisch rückgängig, wenn der Manager sie nicht innerhalb einer festgelegten Zeit bestätigt. Das hilft, wenn eine neue Konfiguration den Managementzugang unterbricht. Jedes Gerät hat weiterhin seine eigene Operation und seinen eigenen Zeitgeber; Confirmed Commit macht aus beiden keine einzelne netzweite Transaktion.

Mit einem Modell einen ungültigen Wert zurückweisen

Ein YANG-Modul organisiert Daten in Containern, Listen und Blättern. Ein Blatt namens mtu kann den Typ uint16 und den erlaubten Bereich 68–65535 haben. Der Wert 40 verletzt den Wertebereich, obwohl er in den Typ einer vorzeichenlosen Ganzzahl passt. Die Modellvalidierung prüft sowohl den Typ als auch die Einschränkungen.

Werkzeuge können YANG-Modelle nutzen, um NETCONF-XML oder RESTCONF-JSON zu prüfen. Standardisierte IETF-Schnittstellenmodelle, Herstellermodelle und OpenConfig-Modelle bieten unterschiedliche Datendefinitionen. Streaming-Telemetrie kann modellierte Zustandsdaten in Abständen senden und so Abfragen ergänzen.

SNMP bleibt für die Überwachung einzelner Objekte nützlich. NETCONF stellt sitzungsbasierte Konfigurationsoperationen und grundlegende Koordinationsfunktionen auf Geräteebene bereit. Keines der beiden Protokolle garantiert allein, dass separate Geräte eine netzweite Änderung gleichzeitig aktivieren.