Dieser Abschnitt bietet eine Übersicht über die Routingfunktionalität von VMware SASE, einschließlich Routentypen, verbundener und statischer Routen sowie dynamischer Routen mit entsprechenden Tie-Breaking-Szenarien und Voreinstellungswerten für Overlay-Flow-Steuerung (Overlay Flow Control, OFC) mit verteilter Kostenberechnung (Distributed Cost Calculation, DCC).

Übersicht

VMware SASE-Routing basiert auf einem proprietären Protokoll namens VCRP, das mehrfachpfadfähig und durch VCMP-Transport gesichert ist. Die SD-WAN-Endpoints sind über VCRP ähnlich wie bei iBGP Full Mesh verbunden. Das SD-WAN Gateway fungiert als BGP-Routen-Reflector, der die Routen von einem SD-WAN-Edge zu einem anderen SD-WAN Edge innerhalb des Kundenunternehmens basierend auf den Profileinstellungen reflektiert.

Das folgende Diagramm zeigt eine typische SD-WAN-Bereitstellung mit Multi-Cloud-Nicht-SD-WAN-Zielen, bei denen der Orchestrator die Routenberechnung durchführt (im Gegensatz zur neueren und bevorzugten Methode mit dynamischer Kostenberechnung (Dynamic Cost Calculation, DCC)).

SD-WAN-Komponenten für Routing-Zwecke

VMware SD-WAN-Routing verwendet die Komponenten „Edge“, „Gateway“ und „Orchestrator“, die unten beschrieben werden.
  • Der SD-WAN Edge ist ein Gerät der Enterprise-Klasse oder eine virtualisierte Cloud-Instanz, die sichere und optimierte Konnektivität zu privaten, öffentlichen und hybriden Anwendungen und virtualisierten Diensten bereitstellt. Beim SD-WAN-Routing ist der Edge ein Border Gateway. Ein Edge kann als regulärer Edge (ohne Hub-Konfiguration), als Hub allein oder als Teil eines Clusters oder als Spoke (wenn Hubs konfiguriert sind) fungieren.
  • Das SD-WAN Gateway ist ein autonomes, zustandsloses, horizontal skalierbares und in der Cloud bereitgestelltes Gateway, mit dem Edges von mehreren Mandanten eine Verbindung herstellen können. Bei jeder SD-WAN-Bereitstellung werden mehrere SD-WAN Gateways als geografisch verteiltes (für geringere Latenz) und horizontal skalierbares (für Kapazität) Netzwerk bereitgestellt. Dabei fungiert jedes Gateway als Routen-Reflector für seine verbundenen Edges.

    Alle Routen, die lokal auf einem Edge erlernt werden, werden basierend auf der Konfiguration an das Gateway gesendet. Das Gateway gibt diese Routen dann an andere Edges im Unternehmen weiter und ermöglicht so eine effiziente Full-Mesh-VPN-Konnektivität, ohne ein komplettes Netz von Tunneln aufzubauen.

  • Der SASE Orchestrator ist ein mandantenfähiges cloudbasiertes Konfigurations- und Überwachungsportal. Beim SD-WAN-Routing verwaltet der Orchestrator die Routen für alle Unternehmen und kann das Standard-Routingverhalten überschreiben.

    In der folgenden Abbildung finden Sie eine Darstellung der VMware SD-WAN-Komponenten für Routing-Zwecke.

Routentypen

Es gibt zwei grundlegende Routentypen für SD-WAN:
  • Lokale Routen (Local Routes): Jede Route, die lokal auf einem SD-WAN Edge gelernt wird. Dabei kann es sich entweder um ein verbundenes Subnetz, eine statisch konfigurierte Route oder eine Route handeln, die aus einem Routingprotokoll wie BGP oder OSPF gelernt wurde.
  • Remote-Routen (Remote Routes): Jede Route, die aus VCRP gelernt wird, d. h. eine Route, die nicht lokal auf einem Edge vorhanden ist, ist eine Remote-Route. Diese Route stammt von einem anderen Edge und wird vom Gateway je nach Konfiguration an andere Edges im Kundenunternehmen weitergegeben.

SD-WAN verwendet eine strenge Reihenfolge beim Routen von Datenverkehr für nicht-dynamische Routen (BGP und OSPF), die nicht geändert werden kann. In bestimmten Szenarien können Sie jedoch die Technik Längste Präfixübereinstimmung (Longest Prefix Match) verwenden, um den Ablauf des Routings zu ändern.

Routensortierung in einem Edge:
  1. Längstes Präfix.
  2. Lokal verbunden.
  3. Lokal statisch, wenn die bevorzugte Option (LAN statisch < WAN statisch) aktiviert ist.
    • Wenn die bevorzugte Option nicht aktiviert ist, werden Overlay-Routen bevorzugt.
  4. Statische NSD-Routen lokal.
    • NSD IPsec vor NSD GRE.
  5. Remote-NSD statisch.
  6. Remote-Edge verbunden.
  7. Remote-Edge-LAN/WAN statisch.
  8. PG statisch.
    • PG sicher statisch > PG nicht sicher statisch.
  9. Dynamische Routen (von OFC (Overlay Flow Control, Overlay-Flow-Steuerung) oder DCC (Distributed Cost Calculation) gesteuerte Reihenfolge).
    • Site lokal (OSPF-Inter/-Intra, BGP-Nicht-Uplink) wird gegenüber dynamischen Routen bevorzugt.
    • Lokale OSPF-Inter-/Intra-Area-Routen haben eine höhere Gewichtung als lokales BGP.
    • Lokales BGP hat eine höhere Gewichtung als OSPF-external (OE1/OE2).
    • Remote-Routen mit bevorzugten Kosten haben eine höhere Gewichtung als nicht bevorzugte lokale Routen (OE1, OE2, UPLINK BGP).
    • Innerhalb der dynamischen Remote-Routen wird die Voreinstellung berücksichtigt (niedrigere Voreinstellung hat höhere Gewichtung).
    • Bei identischer Voreinstellung werden BGP-Attribute und OSPF-Metriken verglichen.
      • OSPF INTRA> INTER > OE1 > OE2
      • BGP
        1. Höhere lokale Voreinstellung
        2. Kleinere AS_PATH-Länge
        3. Kleinere BGP-Metrik
    • Weitere Informationen zur Berechnung der Voreinstellungen finden Sie im Abschnitt „DCC“.

Verbundene und statische Routen

Dieser Abschnitt enthält wichtige Informationen zu verbundenen und statischen Routen. Bei einer verbundenen Route handelt es sich um eine Route, die für ein direkt an die Schnittstelle angeschlossenes Netzwerk konfiguriert ist. Eine statische Route eignet sich für spezielle Fälle, in denen statische Routen für vorhandene angeschlossene Netzwerkgeräte (z. B. Drucker) benötigt werden. Weitere Informationen zu statischen Routen finden Sie unter Konfigurieren von statischen Routeneinstellungen.

Verbundene Routen

  • Damit eine verbundene Route in SD-WAN sichtbar ist, konfigurieren Sie die folgenden Einstellungen im Orchestrator:
    • Cloud-VPN muss aktiviert sein.
    • Die verbundene Route muss mit einer gültigen IP-Adresse konfiguriert werden.
    • Die Edge-Schnittstelle für diese Route muss auf Schicht 1 aktiviert sein und auf den Layern 2 und 3 funktionsfähig sein.
    • Die mit dieser Edge-Schnittstelle verbundenen VLANs müssen ebenfalls aktiviert sein.
    • Das Flag Annoncieren (Advertise) muss auf der Edge-Schnittstelle unter Schnittstellen-IP-Einstellungen (Interface IP settings) für die konfigurierte verbundene Route festgelegt werden.
Statische Routen
  • Damit eine statische Route in SD-WAN angezeigt wird, konfigurieren Sie die folgenden Einstellungen im Orchestrator:
    • Cloud-VPN muss aktiviert sein.
    • Bei der Konfiguration der statischen Route muss die Option Annonciert (Advertised) aktiviert sein.
  • Statische Routen können den Datenverkehr an das WAN-Underlay oder das LAN weiterleiten.
  • Das Hinzufügen einer statischen Route umgeht die NAT auf der Edge-Schnittstelle.
  • ECMP (Equal-Cost-Multi-Path-Routing) mit einer statischen Route wird nicht unterstützt, und nur die erste statische Route würde verwendet werden.
  • Verwenden Sie einen ICMP-Test, um zu vermeiden, dass der Datenverkehr bei einem Ausfall im nächsten Hop unterbrochen wird.
  • Eine statische Route mit aktiviertem Flag Bevorzugt (Preferred) wird gegenüber jeder VPN-Route bevorzugt, die über das Overlay erlernt wurde.
Hinweis: Der Unterschied zwischen dem Flag Bevorzugt (Preferred) und dem Flag Annonciert (Advertised):

Wenn das Kontrollkästchen Bevorzugt (Preferred) aktiviert ist, wird die statische Route immer zuerst abgeglichen, selbst wenn eine VPN-Route mit niedrigeren Kosten verfügbar ist.

Wenn Sie diese Option nicht auswählen, wird jede verfügbare VPN-Route abgeglichen, selbst wenn die VPN-Route höhere Kosten verursacht als die statische Route. Die statische Route wird nur abgeglichen, wenn die entsprechenden VPN-Routen nicht verfügbar sind.

Wenn das Kontrollkästchen Annoncieren (Advertise) aktiviert ist, wird die statische Route über VPN annonciert, und andere SD-WAN Edges im Netzwerk haben Zugriff auf die Ressource. Dies ermöglicht auch statische Route Redistribution in ein Routing-Protokoll, wie z. B. lokales BGP/OSPF.

Wählen Sie diese Option nicht aus, wenn eine private Ressource wie der persönliche Drucker eines Remote-Mitarbeiters als statische Route konfiguriert ist und andere Benutzer daran gehindert werden sollen, auf die Ressource zuzugreifen.

Die OFC Globale Annoncierte Flags (Global Advertise Flags) steuern, welche Routen dem Overlay hinzugefügt werden. Standardmäßig werden die folgenden Routentypen nicht im Overlay angekündigt: „Externes OSPF (Externes OSPF)“ und „Nicht-SD-WAN-Ziel-iBGP (Non SD-WAN Destination iBGP)“. Wenn ein Edge als Hub und Zweigstelle fungiert, werden darüber hinaus die Flags über Globale Annoncierte Flags (Global Advertise Flags) verwendet, die für die Zweigstelle konfiguriert sind, und nicht der Hub.

Hinweis: Es gibt zwei zusätzliche Routentypen: Direkte Routen (Self Routes) und Cloud-Routen (Cloud Routes), die auf einem Edge je nach dessen Konfiguration installiert werden. Jede Route hat einen engen Anwendungsbereich, der im Folgenden skizziert wird und über die Erwähnung hier hinaus nicht weiter behandelt werden muss:

Eine Direkte Route (Self Route) bezieht sich auf ein schnittstellenbasiertes Präfix, das die IP-Längste-Präfixübereinstimmung (Longest Prefix Match, LPM) verwendet (z. B. 172.16.1.10/32). Diese Route ist lokal auf dem Edge installiert, wird aber nicht auf Remote-Edges annonciert. Ein anderer Begriff für „Direkte Routen“ ist „Schnittstellenrouten“. In den Edge-Protokollen werden direkte Routen mit dem Routen-Flag „s“ angezeigt.

Eine direkte Route unterscheidet sich von einer verbundenen Route, da eine verbundene Route im Overlay annonciert werden kann, sodass die Remote-Edge-Clients zurück zu den Clients gelangen können, die zur verbundenen Route auf der Edge-Quellseite gehören. Direkte Routen sind ausschließlich auf den Edge selbst beschränkt.

Eine Cloud-Route ist mit einem „v“-Flag gekennzeichnet und bezieht sich auf eine auf einem Edge installierte Route, die auf ein primäres VMware SD-WAN Gateway für Mehrfachpfad-Datenverkehr verweist, der für das Internet bestimmt ist (mit anderen Worten: Internetdatenverkehr mit dynamischer Mehrfachpfadoptimierung (Dynamic Multi-Path Optimization, DMPO), der ein Gateway nutzt, bevor er das Internet erreicht).

Der Edge verwendet auch eine Cloud-Route über ein entsprechendes Gateway für den Verwaltungsdatenverkehr, der für einen in der Public Cloud gehosteten VMware Orchestrator bestimmt ist.

Overlay-Flow-Steuerung (Overlay Flow Control, OFC) mit verteilter Kostenberechnung (Distributed Cost Calculation, DCC)

In diesem Abschnitt wird erläutert, wie eine Routenreihenfolge unter Verwendung von OFC mit DCC funktioniert.
Wichtig: Dieses Material gilt nur für Kunden, für die Distributed Cost Control (DCC) aktiviert ist. DCC wurde erstmals in SD-WAN Version 3.4.0 zur Verfügung gestellt und sollte jetzt empfehlungsgemäß für alle Kunden aktiviert werden. Diese Funktion wird in einer kommenden Version automatisch für neue Kunden aktiviert. Weitere Informationen zu DCC, einschließlich Best Practices, finden Sie unter Konfigurieren von DCC (Distributed Cost Calculation).

DCC (Distributed Cost Calculation) – Übersicht

Verteilte Kostenberechnung (Distributed Cost Calculation, DCC) ist eine Funktion, die die SD-WAN-Edges und -Gateways für die Berechnung von Routenvoreinstellungen nutzt, anstatt sich auf den SASE Orchestrator zu verlassen. Der Edge und das Gateway fügen die Routen jeweils sofort nach dem Erlernen ein und übermitteln diese Voreinstellungen dann an den Orchestrator.

DCC behebt ein Problem, das in großen Bereitstellungen auftritt, in denen der Orchestrator allein die rechtzeitige Aktualisierung von Routenvoreinstellungen verhindern kann, entweder weil er nicht von einem Edge oder Gateway erreicht werden kann, um aktualisierte Routenvoreinstellungen zu erhalten, oder weil der Orchestrator nicht in der Lage ist, Routenaktualisierungen schnell zu liefern, wenn er eine große Anzahl von ihnen gleichzeitig berechnet. Die Verteilung der Verantwortlichkeiten für die Berechnung von Routenvoreinstellungen auf die Edges und Gateways gewährleistet schnelle und zuverlässige Routenaktualisierungen.

Berechnen von Voreinstellungen mit verteilter Kostenberechnung (DCC)

Tabelle 1-2 enthält eine Auflistung der in SD-WAN unterstützten dynamischen Routentypen. Tabelle 1-3 ist ein Glossar der Routentypen. Eine dynamische Route wird zunächst danach kategorisiert, ob sie auf dem Edge oder dem Gateway erlernt wurde.
Tabelle 1. Dynamische Routentypen
Edge Partner-Gateway/gehostetes Gateway
NSD-E-BGP NSD-E/I-BGP
NSD-I-BGP E/I-BGP
NSD-Uplink-BGP
OSPF-O
OSPF-IA
E-BGP
I-BGP
OSPF-OE1
OSPF-OE2
Uplink-BGP
Tabelle 2. Bedeutung der Routentypen
O = OSPF-Intrabereich
IA = OSPF-Interbereich
OE1 = Externer OSPF-Typ-1
OE2 = Externer OSPF-Typ-2
E BGP = Externes BGP
I BGP = Internes BGP
NSD = Nicht-SD-WAN-Ziel
Hinweis: Unterstützung für Nicht-SD-WAN-Ziel (NSD) mit OFC ist ab Version 4.3.0 und höher verfügbar. Weitere Informationen zu NSDs finden Sie unter Konfigurieren eines Nicht-SD-WAN-Ziels.

Jeder Routentyp weist einen Voreinstellungswert auf (betrachten Sie die Voreinstellung in diesem Dokument als die Kosten), und jeder erlernten Route wird ein Voreinstellungswert auf Basis des Routentyps zugewiesen. Je niedriger der Voreinstellungswert, desto höher ist die Priorität. In Tabelle 1 bis 3 wird der Standardvoreinstellungswert für jeden Routentyp aufgeführt.

Tabelle 3. Voreinstellungswerte
Gerät (Device) Routentyp (Route Type) Standardvoreinstellung (Default Preference)
Edge/Hub NSD-E-BGP 997
Edge/Hub NSD-I-BGP 998
Gateway NSD-E/I-BGP 999
Edge/Hub NSD-Uplink-BGP 1000
Edge/Hub OSPF-O 1001
Edge/Hub OSPF-IA 1002
Edge/Hub E-BGP 1003
Edge/Hub I-BGP 1004
Partner-Gateway E/I-BGP 1005
Edge/Hub OSFP OE1 1001006
Edge/Hub OSPF-OE2 1001007
Hub/Edge BGP-Uplink 1001008

Die in der obigen Tabelle angezeigten Voreinstellungswerte basieren auf der standardmäßigen Prioritätsreihenfolge in der Konfiguration der Overlay-Flow-Steuerung. Die Werte werden entsprechend angepasst, wenn die Standardreihenfolge geändert wird.

Workflow für dynamische Routen

  1. Der Edge oder das Gateway erlernt eine dynamische Route.
  2. SD-WAN erkennt intern, um welche Art von Route es sich handelt und welchen Voreinstellungswert sie hat.
  3. SD-WAN weist den richtigen Voreinstellungswert zu und installiert die Route in der Routing Information Base (RIB) und Forwarding Information Base (FIB).
  4. SD-WAN berücksichtigt die für diese Route konfigurierte Standard-Annoncierungsaktion. Auf der Grundlage der Annoncierungsaktion annonciert SD-WAN die Route entweder im gesamten Kundenunternehmen (annonciert) oder ergreift keine weiteren Maßnahmen als das lokale Hinzufügen der Route in die RIB und FIB (nicht annonciert).
  5. SD-WAN synchronisiert diese Route dann mit dem Orchestrator, der sie im Orchestrator anzeigt.

Bevorzugte VPN-Exit-Points

Dieser Abschnitt behandelt Bevorzugte VPN-Exit-Points (Preferred VPN Exit Points): was sie sind, welche Routen in welche Kategorien fallen können und die Verwendung von Routen-Anheftung, um Standardwerte zu überschreiben.

Wenn Sie im SD-WAN-Dienst des Unternehmensportals zu Konfigurieren (Configure) > Overlay-Flow-Steuerung (Overlay Flow Control) navigieren, wird ein Abschnitt mit dem Titel Bevorzugte VPN-Beendigungen (Preferred VPN Exits) angezeigt. Dieser Abschnitt zeigt Standardprioritäten an und markiert einige Routenkategorien, die gegenüber anderen bevorzugt werden sollen.

Screenshot des Bildschirms „Overlay-Flow-Steuerung (Overlay Flow Control)“ mit bevorzugten VPN-Beendigungen.

Die Kategorien der bevorzugten VPN-Beendigungen:
  • Edge: Jede interne Route, die entweder auf einem Hub oder einem Spoke-Edge erlernt werden kann, fällt in diese Kategorie und ist mit der höchsten Priorität gekennzeichnet. Eine interne Route kann keine OSPF OE 1-/OE 2- oder BGP-Uplink-Route sein.
  • Hub: Jede externe Route, die auf einem Edge/Hub erlernt wird, fällt in die Hub-Kategorie und hat in der Regel eine niedrigere Priorität. Hub-Routen umfassen OSPF OE1/2 und BGP-Uplink.
  • Partner-Gateway: Jede Route, die auf einem Partner-Gateway erlernt wird.
  • Router: Ein Router stellt jedes Routenpräfix dar, das von einem Edge mit BGP oder OSPF erlernt wird, und bestimmt die Voreinstellung, die einer dynamischen Route zugewiesen ist. In der Regel erhalten alle Exit-Points oberhalb von Router im VPN-Exit einen niedrigen Voreinstellungswert (bevorzugte Kosten) und werden stärker bevorzugt. Allen Exit-Points unterhalb von Router wird ein höherer Voreinstellungswert zugewiesen, weshalb diese weniger bevorzugt werden.
    • Beispiel: Wenn DCC aktiviert ist, erhalten alle Routen, die zu VPN-Exit-Points (Edge, Partner Gateway oder Hub) gehören, die oberhalb von Router liegen, einen Voreinstellungswert von weniger als 1.000.000, und die Routen, die unterhalb von Router liegen, erhalten einen Voreinstellungswert von mehr als 1.000.000.
    • Im folgenden Beispiel erhalten die VPN-Exit-Points oberhalb von Router, d. h. NSD, Edge und Partner Gateway, einen Voreinstellungswert von weniger als 1.000.000 und Hub einen Voreinstellungswert von mehr als 1.000.000.Ein weiterer Screenshot der Overlay-Flow-Steuerung. In diesem Screenshot wird jedoch „Router“ hervorgehoben, um die Voreinstellungswerte oberhalb und unterhalb des Router-Typs zu verdeutlichen.

Anheften einer Route, um einen Standard-Voreinstellungswert zu überschreiben

SD-WAN verfügt über eine Funktion zum Anheften von Routen, mit der ein Benutzer den Standard-Voreinstellungswert, der einer dynamischen Route zugewiesen wurde, überschreiben kann. Sobald eine dynamische Route erlernt und mit dem Orchestrator synchronisiert wurde, kann der Benutzer zur Seite Overlay-Flow-Steuerung (Overlay Flow Control) navigieren und die Standardreihenfolge für diese Route überschreiben. Der Workflow hierfür lautet wie folgt:
  1. Ein Benutzer pinnt eine Route auf der Seite Overlay-Flow-Steuerung (Overlay Flow Control) anhand einer der folgenden Möglichkeiten an:
    1. Wählen Sie auf der Routenliste (Routes List) eine oder mehrere Routen aus und klicken Sie dann auf die Option Erlernte Routenvoreinstellung anheften (Pin Learned Route Preference).
    2. Ändern der Reihenfolge der Bevorzugte VPN-Beendigungen (Preferred VPN Exits) indem Sie in der Tabelle auf Bearbeiten (Edit) klicken.
  2. Der Orchestrator sendet dieses Routing-Ereignis an die relevanten Edges im Kundenunternehmen.
  3. Die Edges überschreiben den vorherigen Voreinstellungswert entsprechend der angehefteten Reihenfolge.
  4. Die Voreinstellungswerte, die angehefteten Routen zugewiesen werden, beginnen bei 1, 2, 3 usw. (die niedrigsten Werte und somit die höchsten Einstellungen). Dies entspricht der Reihenfolge der Routen auf der Seite Overlay-Flow-Steuerung (Overlay Flow Control).
    Hinweis: Weitere Informationen zum Anheften einer Route finden Sie unter Konfigurieren von Subnetzen.

Tie-Breaking-Szenarien für alle Routentypen

Was passiert, wenn ein Edge dasselbe Präfix für zwei oder mehr Quellen/Nachbarn erhält?

Ein mögliches Szenario in SD-WAN-Bereitstellungen ist, dass dasselbe Präfix von zwei verschiedenen Edges oder Partner-Gateways annonciert wird. Wenn sich die Subnetze bei VMware SD-WAN innerhalb derselben Kategorie (Edge, Hub oder Partner-Gateway) befinden und denselben Voreinstellungswert aufweisen, werden die BGP-Attribute oder OSPF-Metriken zuerst für die Routensortierung berücksichtigt.

Wenn immer noch ein Tie vorhanden ist, verwendet SD-WAN die logische ID (die von der universell eindeutigen Kennung (UUID) des Edge oder Gateways abgeleitet ist) des Geräts für den nächsten Hop, um den Tie zu brechen. Das Gerät für den nächsten Hop kann ein Gateway oder ein Hub-Edge sein, je nach Typ des verwendeten Zweigstelle-zu-Zweigstelle-VPN. Wenn das Kundenunternehmen Zweigstelle-zu-Zweigstelle über Gateway verwendet, ist der nächste Hop ein Gateway, während bei einem Kunden, der Zweigstelle-zu-Hub verwendet, der nächste Hop ein Hub Edge ist.

Wenn mehrere Gateways genau denselben Routentyp und dieselbe Präferenz bekannt geben, kommt es zu einer endgültigen Entscheidungsfindung. Bei dieser letzten Entscheidung wird die älteste gelernte Route bevorzugt. Um das gewünschte Routing-Ergebnis zu erzielen, können Sie entweder bestimmte Routen festlegen oder die BGP-Attribute und -Kosten so konfigurieren, dass einige Routen gegenüber anderen bevorzugt werden.

Hinweis: Kunden haben keine Kontrolle darüber, wie eine logische ID (LID) generiert wird, und Sie können ihren Wert nicht ändern. LID-Werte sind nicht direkt vergleichbar. Stattdessen werden sie mit einem internen Softwarealgorithmus verglichen, der einen LID in vier Blöcke aufschlüsselt und nacheinander vergleicht. Beispielsweise ist „lid1-data1“ größer als „lid1-data2“ und „lid1-data2“ größer als „lid2-data2“.

In der folgenden Abbildung werden die Berechnung der Voreinstellungen und die Routensortierung für dynamische Routen veranschaulicht.

Betrachten Sie die obige Topologie, bei der dieselbe Route 9.9.9.9/32 von zwei Spokes erlernt wird.
  1. Spoke1 und Spoke2 erlernen die Route als BGP-Routen (Nicht-Uplink).
  2. Hub1 und Hub2 erlernen die Routen als Uplink-BGP-Routen.
  3. PG1 erlernt ebenfalls dieselbe Route.
  4. Zweigstelle-zu-Zweigstelle über Hub1 und Hub2 ist im Spoke-Profil aktiviert.
Routensortierung in Spokes mit Nicht-Uplink-Routen:
  1. Da Spoke1 und Spoke2 die Route als BGP erlernen, wählen sie 1003 als bevorzugten Kostenwert (der Voreinstellungswert wird in diesem Abschnitt als Kosten bezeichnet) gemäß der Angaben in der Zuordnungstabelle für DCC-Voreinstellungen aus.
  2. Route 9.9.9.9/32 wird in FIB von Spoke1 und Spoke2 mit Referenzkosten von 1000000 installiert. Wie immer wird die Underlay-Route lediglich mit Referenzkosten in FIB installiert. Die aus der DCC-Voreinstellungstabelle abgeleiteten Kosten/Voreinstellungen sind für Remote-SD-WAN-Einheiten (Edges/Gateway) vorgesehen, die für die Routensortierung verwendet werden.
  3. Spoke1 und Spoke2 verteilen die Route über VCRP mit abgeleiteten Kosten von 1003 an das Gateway und die Remote-Edges/Hubs neu. In der folgenden Abbildung werden die abgeleiteten Kosten/Voreinstellungen in Spokes angezeigt.
  4. Auf ähnliche Weise erlernen Hub1 und Hub2 die Route und leiten die nicht bevorzugten Kosten (1001008) ab, da sie die Route als Uplink-Route erlernen. Hubs verteilen die Route mit diesen Kosten an Gateways und andere Edges neu. In der folgenden Ausgabe werden die abgeleiteten Kosten/Voreinstellungen in Hubs angezeigt.
  5. PG1 erlernt dieselbe Route von BGP, verwendet die Kosten 1005 und verteilt sie an die Edges neu. In der folgenden Ausgabe werden die abgeleiteten Kosten/Voreinstellungen in PG angezeigt.
  6. Spoke1 empfängt die Route von Hub1 und Hub2 mit den nicht bevorzugten Kosten von 1001008. Spoke1 weist die bevorzugten Kosten von 003 auf. Daher wird die Underlay-Route von Spoke1 bevorzugt, und Hub-Routen werden unterhalb der Underlay-Route (SB) installiert. Wenn die Voreinstellung (Kosten) innerhalb der Hub-Routen identisch ist, werden BGP-Attribute für die Routensortierung verglichen. Wenn auch die BGP-Attribute identisch sind, wird die Hub-Reihenfolge zum Installieren der Routen verwendet.
  7. Spoke1 erhält eine Route von Spoke2 und PG1 mit den jeweiligen Kosten 1003 und 1005. Da Spoke1 die bevorzugten Kosten 1003 aufweist und Routen von Spoke2 und PG1 mit bevorzugten Kosten (< 100000) empfängt, fügt Spoke1 die Referenzkosten 1000000 zu den eingehenden bevorzugten Kosten hinzu und installiert die Routen in FIB. In diesem Fall wird die Route von Spoke2 mit Kosten von 1001003 und die Route von PG1 mit Kosten von 1001005 installiert.
  8. Dieselbe Routensortierungslogik wird in Spoke2 oder sogar in Hubs angewendet, wenn diese die Route als Nicht-Uplink-Route erlernen.
  9. Wenn in keiner Einheit eine Underlay-Route erlernt wurde, werden die empfangenen Routenvoreinstellungen/-kosten nicht korrigiert. Die Routen werden entsprechend den erhaltenen Voreinstellungen/Kosten installiert.
Routensortierung in Hub mit Uplink-Routen:
  1. Hubs installieren ihre eigene Underlay-Route (SB) mit Referenzkosten von 1000000 in FIB.
  2. Hubs empfangen Spoke-Routen mit bevorzugten Kosten von 1003. Da die Kosten für die Spokes identisch sind, werden die BGP-Attribute verglichen und auf dieser Basis sortiert. Wenn die BGP-Attribute ebenfalls identisch sind, wird die logische Spoke-ID für die Sortierung verwendet (niedrigere logische Ziel-ID hat eine höhere Gewichtung als der Tie Breaker). Die Routen des Spokes werden mit den erhaltenen Kosten unverändert installiert.
  3. Der Hub empfängt die PG1-Route mit bevorzugten Kosten. Daher wird sie mit diesen Kosten unverändert installiert.
Routensortierung in PG:
  1. PG1 installiert seine eigene Underlay-Route (PB) mit der Voreinstellung 100000.
  2. PG1 empfängt Spoke-Routen und die Hub-Route mit der entsprechenden Voreinstellung. Routen werden basierend auf dem Voreinstellungswert in der FIB platziert. Wenn die Einstellungen identisch sind, werden BGP-Attribute berücksichtigt. Wenn diese ebenfalls identisch sind, wird die logische ID für die Sortierung verwendet.
  3. In PG findet keine Korrektur der Voreinstellungen/Kosten statt.
Verhalten bei nicht aktivierter DCC:
  • Wenn DCC nicht aktiviert ist, werden die Bewertung der Ankündigung und die Berechnung der Voreinstellungen vom Orchestrator durchgeführt. Jede Einheit (Edge oder Gateway) sendet die erlernten Routen an den Orchestrator und erwartet eine Antwort von diesem. Nach Erhalt der Antwort vom Orchestrator beginnt der Edge oder das Gateway mit der Neuverteilung der Routen an andere SDWAN-Entitäten, wenn das Ankündigungs-Flag in der Antwort auf „true“ festgelegt ist.
  • Die Reihenfolge der Routen entspricht derjenigen bei aktivierter DCC. Die Voreinstellungswerte werden in diesem Szenario mit deaktivierter DCC jedoch nicht festgelegt.
  • Die Referenzvoreinstellungen/-kosten betragen 512 für die Orchestrator-basierte Berechnung der Voreinstellungen. Die Voreinstellungen/Kosten < 512 gelten als bevorzugte Kosten, während > 512 nicht bevorzugten Routen (UPLINK-Routen, externe OSPF-Routen) zugewiesen wird. Weitere Routensortierungslogiken bleiben dieselben wie bei aktivierter DCC.
  • Wenn Spoke2 die Route erstmals erlernt und an den Orchestrator sendet, beginnt der Orchestrator mit der Zuweisung der Voreinstellung auf Basis der Einheit und des Routentyps. Da Spoke2 als Nicht-Uplink erkannt wird, weist der Orchestrator den Voreinstellungswert zu (z. B. 64). Wenn Spoke1 dieselbe Route später an den Orchestrator sendet, vergleicht der Orchestrator die Einheit, den Routentyp und die Routenattribute. Wenn sie besser ist, wird die Voreinstellung < 64 zugewiesen. Wenn sie schlechter ist, wird die Voreinstellung > 64 zugewiesen.
  • Hubs erlernen die Routen als Uplink-Routen und senden sie an den Orchestrator. Der Orchestrator weist nicht bevorzugte Kosten zu (> 512), in diesem Beispiel 4096. Bei identischer Voreinstellung wird die Hub-Reihenfolge verwendet, um die Routen in den Spokes zu sortieren.
  • Wenn DCC deaktiviert ist, entspricht die Routenreihenfolge in Spoke1 (mit einer Nicht-Uplink-Route) der folgenden Abbildung.
  • Die Routenreihenfolge in Hubs mit einer Uplink-Route entspricht der folgenden Abbildung.
  • Die Routenreihenfolge in PG entspricht der folgenden Abbildung.
Routensortierung im Gateway:
  1. Längstes Präfix.
  2. Statische NSD-Routen lokal.
  3. Remote-NSD statisch.
  4. PG sicher statisch.
    1. Die statische PG-Route auf Unternehmensebene hat eine höhere Gewichtung als die statische PG-Route auf der globalen Ebene.
  5. Remote verbunden/statisch.
    1. Edge-logical_id ist der Tie Breaker (höhere logische ID hat höhere Gewichtung).
  6. Dynamische Routen (von OFC (Overlay Flow Control, Overlay-Flow-Steuerung) oder DCC (Distributed Cost Calculation) gesteuerte Reihenfolge).
    1. Die dynamische Routensortierung basiert auf dem Voreinstellungswert. Niedrigere Voreinstellungen haben eine höhere Gewichtung.
    2. Im Gegensatz zu einem Edge gibt es keine Voreinstellung in der automatischen Korrektur im Gateway. Für dynamische Routen installiert das Gateway die Routen mit der empfangenen Voreinstellung. Die lokale Route wird immer mit der Referenzvoreinstellung 1000000 installiert.
    Hinweis: Weitere Informationen zur Berechnung von Voreinstellungen finden Sie im Abschnitt „Overlay-Flow-Steuerung (Overlay Flow Control, OFC) mit DCC (Distributed Cost Calculation)“.
  7. PG nicht sicher statisch.
Hinweis: Im Gateway hängt die Routenauswahl für die Datenverkehrsweiterleitung von anderen Bedingungen ab, z. B. Einstellungen des Edge-Profils, Richtung des Flows usw.