8. Zusätzliche Designoptionen

8.1. Injektion von Routen durch Dritte

BGP erlaubt es einem « Drittanbieter »-BGP-Speaker, d. h. einem direkt angeschlossenen Speaker, Routen beliebig in der Netzwerktopologie zu injizieren und erfüllt damit REQ5. Dies kann über Multi-Hop-BGP-Peering mit einigen oder sogar allen Geräten der Topologie erreicht werden. Außerdem könnte die BGP diverse path distribution [RFC6774] genutzt werden, um mehrere BGP-Next-Hops für dasselbe Präfix zu injizieren und Lastausgleich zu erleichtern, oder die BGP-ADD-PATH-Fähigkeit [RFC7911], falls von der Implementierung unterstützt. Leider unterstützt ADD-PATH in vielen Implementierungen nur IBGP ordentlich für die ursprünglich optimierten Anwendungsfälle ; dies beschränkt « Drittanbieter »-Peering auf IBGP.

Zur Routeninjektion im vorgeschlagenen Design kann ein Drittanbieter-BGP-Speaker mit Tier-3- und Tier-1-Switches peeren, dasselbe Präfix injizieren, aber mit einem speziellen Satz BGP-Next-Hops für Tier-1-Geräte. Diese Next Hops sollen rekursiv via BGP auflösbar sein und könnten z. B. IP-Adressen auf Tier-3-Geräten sein. Die resultierende Forwarding-Tabellenprogrammierung kann die gewünschte Trafficverteilung zwischen Clustern liefern.

8.2. Routenzusammenfassung innerhalb der Clos-Topologie

Wie zuvor erwähnt, ist Routenzusammenfassung in der vorgeschlagenen Clos-Topologie nicht möglich, da das Netz anfällig für Routing-Black-Holes bei Ausfall eines einzelnen Links wird. Das Hauptproblem ist die begrenzte Anzahl redundanter Pfade zwischen Netzelementen, z. B. gibt es nur einen Pfad zwischen jedem Paar Tier-1- und Tier-3-Geräte. Einige Betreiber mögen jedoch Routenaggregation zur Verbesserung der Steuerflächenstabilität wünschen.

Ist eine Zusammenfassungstechnik innerhalb der Topologie geplant, sollten Routingverhalten und Black-Hole-Potenzial nicht nur für einzelne oder mehrere Linkausfälle modelliert werden, sondern auch für Glasfaserverbindungs- oder optische Domänenausfälle, wenn die Topologie über einen physischen Standort hinausgeht. Einfache Modellierung kann durch Erreichbarkeitsprüfung auf zusammenfassenden Geräten unter Bedingung eines Link- oder Pfadausfalls zwischen Gerätesätzen jeder Ebene sowie zu WAN-Routern bei externer Konnektivität erfolgen.

Routenzusammenfassung wäre mit einer kleinen Änderung der Netztopologie möglich, der Kompromiss wäre jedoch Verkleinerung der Gesamtnetzgröße sowie Netzüberlastung bei bestimmten Ausfällen. Dieser Ansatz ist dem oben beschriebenen sehr ähnlich, der Border Routers erlaubt, den gesamten Rechenzentrums-Adressraum zusammenzufassen.

8.2.1. Zusammenlegung der Tier-1-Geräteschicht

Um mehr Pfade zwischen Tier-1- und Tier-3-Geräten hinzuzufügen, Tier-2-Geräte paarweise gruppieren und die Paare mit derselben Gruppe von Tier-1-Geräten verbinden. Das ist logisch gleichbedeutend mit dem « Zusammenlegen » von Tier-1-Geräten zu einer halb so großen Gruppe unter Zusammenführung der Links auf den « zusammengelegten » Geräten. Das Ergebnis zeigt Abbildung 6. In dieser Topologie verbinden sich z. B. DEV C und DEV D mit derselben Menge Tier-1-Geräte (DEV 1 und DEV 2), während sie zuvor unterschiedlichen Tier-1-Gruppen angeschlossen waren.

              Tier 2       Tier 1       Tier 2
             +-----+      +-----+      +-----+
+------------| DEV |------| DEV |------|     |-------------+
|       +----|  C  |--++--|  1  |--++--|     |-----+       |
|       |    +-----+  ||  +-----+  ||  +-----+     |       |
|       |             ||           ||             |       |
|       |    +-----+  ||  +-----+  ||  +-----+     |       |
| +-----+----| DEV |--++--| DEV |--++--|     |-----+-----+ |
| |     | +--|  D  |------|  2  |------|     |---+ |     | |
| |     | |  +-----+      +-----+      +-----+   | |     | |
| |     | |                                      | |     | |
+-----+ +-----+                                +-----+ +-----+
| DEV | | DEV |                                |     | |     |
|  A  | |  B  | Tier 3                  Tier 3 |     | |     |
+-----+ +-----+                                +-----+ +-----+
  | |     | |                                    | |     | |
  O O     O O          <- Servers ->             O O     O O

                Figure 6: 5-Stage Clos Topology

Mit diesem Design können Tier-2-Geräte so konfiguriert werden, dass sie nur eine Standardroute zu Tier-3-Geräten annoncieren. Fällt ein Link zwischen Tier 2 und Tier 3 aus, wird der Verkehr über den zweiten verfügbaren Pfad am Tier-2-Switch umgeleitet. Es ist weiterhin unmöglich, eine Summary-Route zu annoncieren, die Präfixe eines einzelnen Clusters von Tier-2-Geräten abdeckt, da jedes nur einen Pfad zu diesem Präfix hat. Dafür wären dual angebundene Server nötig. Dieses Design ist nur gegen einzelne Linkausfälle resilient. Ein doppelter Linkausfall kann ein Tier-2-Gerät von allen Pfaden zu einem bestimmten Tier-3-Gerät isolieren und ein Routing-Black-Hole verursachen.

Eine Folge der vorgeschlagenen Topologieänderung wäre eine Verringerung der Portkapazität der Tier-1-Geräte. Das begrenzt die maximale Anzahl angeschlossener Tier-2-Geräte und damit die maximale DC-Netzgröße. Ein größeres Netz erforderte andere Tier-1-Geräte mit höherer Portdichte, um diese Änderung umzusetzen.

Ein weiteres Problem ist Traffic-Rebalancing bei Linkausfällen. Da es zwei Pfade von Tier 1 zu Tier 3 gibt, führt ein Ausfall des Links zwischen Tier 1 und Tier-2-Switch dazu, dass der gesamte Verkehr, der den ausgefallenen Link nutzte, auf den verbleibenden Pfad wechselt, was die Linkauslastung dort verdoppelt.

8.2.2. Einfache virtuelle Aggregation

Ein völlig anderer Ansatz zur Routenzusammenfassung ist möglich, wenn das Hauptziel die FIB-Größe reduzieren soll, während die Steuerfläche vollständige Routinginformation verbreitet. Zunächst fällt auf, dass in vielen Fällen mehrere Präfixe, teils weniger spezifisch, denselben Next-Hop-Satz (dieselbe ECMP-Gruppe) teilen. Aus Sicht der Tier-3-Geräte teilen z. B. alle von stromaufwärtigen Tier-2-Geräten gelernten Routen, einschließlich der Standardroute, denselben BGP-Next-Hop-Satz, solange keine Netzausfälle vorliegen. Damit lässt sich eine Technik ähnlich [RFC6769] nutzen und nur die am wenigsten spezifische Route in der FIB installieren, spezifischere ignorieren, wenn sie denselben Next-Hop-Satz teilen. Unter normalen Bedingungen muss z. B. nur die Standardroute in die FIB programmiert werden.

Sind Tier-2-Geräte mit Summary-Präfixen konfiguriert, die alle Präfixe ihrer angeschlossenen Tier-3-Geräte abdecken, lässt sich dieselbe Logik auch auf Tier-1-Geräte anwenden und induktiv auf Tier-2/Tier-3-Switches in verschiedenen Clustern. Diese Summary-Routen sollten trotzdem spezifischere Präfixe zu Tier-1-Geräten durchsickern lassen, um Diskrepanzen in den Next-Hop-Sätzen zu erkennen, wenn ein bestimmter Link ausfällt und den Next-Hop-Satz eines Präfixes ändert.

Nochmals: Diese Technik reduziert nicht die Steuerflächenzustandsmenge (d. h. BGP-UPDATEs, BGP Loc-RIB-Größe), sondern ermöglicht nur effizientere FIB-Nutzung, indem spezifischere Präfixe erkannt werden, die ihren Next-Hop-Satz mit einem sie umfassenden weniger spezifischen Präfix teilen.

8.3. Maskerade von ICMP Destination Unreachable

Dieser Abschnitt behandelt operative Aspekte der Nicht-Ankündigung von Punkt-zu-Punkt-Link-Subnetzen in BGP, wie zuvor in Abschnitt 5.2.3 als Option genannt. Der operative Einfluss zeigt sich bei Nutzung des bekannten Werkzeugs « traceroute ». Die angezeigten IP-Adressen sind die Punkt-zu-Punkt-Adressen der Verbindung und daher für Management-Konnektivität nicht erreichbar. Das erschwert einige Fehleranalysen.

Eine Möglichkeit ist das DNS-Subsystem zu nutzen, um « Reverse »-Einträge für diese Punkt-zu-Punkt-IP-Adressen anzulegen, die auf denselben Namen wie die Loopback-Adresse zeigen. Konnektivität kann dann durch Auflösung dieses Namens zur « primären » IP-Adresse des Geräts, z. B. Loopback-Schnittstelle, die immer in BGP annonciert wird, hergestellt werden. Das schafft jedoch eine Abhängigkeit vom DNS, das während eines Ausfalls unverfügbar sein kann.

Eine andere Option ist, das Netzgerät IP-Adress-Maskerade durchführen zu lassen, d. h. die Quell-IP-Adressen geeigneter ICMP-Nachrichten des Geräts mit der « primären » IP-Adresse des Geräts zu überschreiben. Insbesondere ICMP Destination Unreachable (Typ 3) Code 3 (port unreachable) und ICMP Time Exceeded (Typ 11) Code 0 sind für korrektes « traceroute » nötig. Mit dieser Änderung werden « traceroute »-Sonden zu den Geräten stets mit der « primären » IP-Adresse als Quelle zurückgesendet, sodass der Betreiber die « erreichbare » Adresse der Box ermitteln kann. Nachteil ist, dass die Adresse des « Einstiegspunkts » ins Gerät verborgen bleibt. Unterstützen die Geräte [RFC5837], kann das Beste aus beiden Welten geliefert werden, indem Informationen über die eingehende Schnittstelle bereitgestellt werden, auch wenn die Rückadresse die « primäre » IP-Adresse ist.