SD-WAN-Überlagerungsrouting

Citrix SD-WAN bietet robuste und robuste Konnektivität zwischen Remotestandorten, Rechenzentren und Cloud-Netzwerken. Die SD-WAN-Lösung kann dies erreichen, indem Tunnel zwischen SD-WAN-Appliances im Netzwerk eingerichtet werden, die die Konnektivität zwischen Standorten ermöglichen, indem Routentabellen angewendet werden, die das vorhandene Unterlagennetzwerk überlagern. SD-WAN-Routingtabellen können die vorhandene Routinginfrastruktur vollständig ersetzen oder mit ihr koexistieren.

Citrix SD-WAN Appliances messen die unidirektional verfügbaren Pfade in Bezug auf Verfügbarkeit, Verlust, Latenz, Jitter und Überlastung und wählen den besten Pfad pro Paket aus. Das bedeutet, dass der von Standort A nach Standort B gewählte Pfad nicht notwendigerweise der Pfad von Standort B zu Standort A sein muss. Der beste Pfad zu einem bestimmten Zeitpunkt wird unabhängig in jede Richtung ausgewählt. Citrix SD-WAN bietet paketbasierte Pfadauswahl zur schnellen Anpassung an alle Netzwerkänderungen. SD-WAN-Appliances können Pfadausfälle nach nur zwei oder drei fehlenden Paketen erkennen, was ein nahtloses Failover des Anwendungsdatenverkehrs in einer Subsekundenzeit zum nächstbesten WAN-Pfad ermöglicht. SD-WAN-Appliances berechnen jeden WAN-Verbindungsstatus in etwa 50 ms neu. Der folgende Artikel enthält eine detaillierte Routingkonfiguration im Citrix SD-WAN Netzwerk.

Citrix SD-WAN-Routingtabelle

Das SD-WAN ermöglicht statische Routeneinträge für bestimmte Standorte und Routeneinträge, die über unterstützte Routing-Protokolle wie OSPF, eBGP und iBGP aus dem Underlay-Netzwerk gelernt wurden. Routen werden nicht nur durch ihren nächsten Hop, sondern auch durch ihren Servicetyp definiert. Dies bestimmt, wie die Route weitergeleitet wird. Im Folgenden werden die wichtigsten verwendeten Service-Typen aufgeführt:

• Lokaler Dienst: Gibt jede Route oder Subnetz an, die zur SD-WAN-Appliance lokal sind. Dazu gehören die Virtual Interface-Subnetze (erstellt automatisch lokale Routen) und jede in der Routentabelle definierte lokale Route (mit einem lokalen nächsten Hop). Die Route wird anderen SD-WAN-Appliances angekündigt, die über einen virtuellen Pfad zu diesem lokalen Standort verfügen, an dem diese Route konfiguriert wird, wenn sie als Partner vertraut wird.

Hinweis

Seien Sie vorsichtig beim Hinzufügen von Standardrouten und Zusammenfassungsrouten als lokale Routen, da diese zu virtuellen Pfadrouten an anderen Standorten führen können. Überprüfen Sie immer die Routingtabellen, um sicherzustellen, dass das korrekte Routing wirksam ist.

• Virtueller Pfad — Bezeichnet jede lokale Route, die von einem Remote-SD-WAN-Site gelernt wurde, der über die virtuellen Pfade erreichbar ist. Diese Routen sind normalerweise automatisch, aber eine virtuelle Pfadroute kann manuell an einem Standort hinzugefügt werden. Jeder Datenverkehr für diese Route wird an den definierten virtuellen Pfad für diese Zielroute (Subnetz) weitergeleitet.

• Intranet — Bezeichnet Routen, die über eine private WAN-Verbindung (MPLS, P2P, VPN usw.) erreichbar sind. Ein Remote-Zweig, der sich im MPLS-Netzwerk befindet, aber keine SD-WAN-Appliance hat. Es wird davon ausgegangen, dass diese Routen an einen bestimmten WAN-Router weitergeleitet werden müssen. Der Intranetdienst ist standardmäßig nicht aktiviert. Jeder Datenverkehr, der dieser Route (Subnetz) entspricht, wird als Intranet für diese Appliance für die Zustellung an einen Standort klassifiziert, der keine SD-WAN-Lösung hat.

Hinweis

Beachten Sie, dass es beim Hinzufügen einer Intranet-Route keinen nächsten Hop gibt, sondern eine Weiterleitung zu einem Intranetdienst. Der Dienst ist mit einer bestimmten WAN-Verbindung verknüpft.

• Internet - Dies ähnelt Intranet, wird jedoch verwendet, um den Datenverkehr zu definieren, der zu öffentlichen Internet-WAN-Verbindungen und nicht zu privaten WAN-Verbindungen fließt. Ein einzigartiger Unterschied besteht darin, dass der Internetdienst mehreren WAN-Verbindungen zugeordnet und auf Lastausgleich (pro Fluss) oder Aktiv/Backup eingestellt werden kann. Eine Standard-Internetroute wird erstellt, wenn der Internetdienst aktiviert ist (standardmäßig ist sie ausgeschaltet). Jeder Datenverkehr, der dieser Route (Subnetz) entspricht, wird für diese Appliance als Internet für die Zustellung an öffentliche Internetressourcen klassifiziert.

Hinweis

Internetdienstrouten können für die anderen SD-WAN-Appliances angekündigt oder am Exportieren gehindert werden, je nachdem, ob Sie den Internetzugang über die virtuellen Pfade zurückziehen.

• Passthrough — Dieser Dienst fungiert als letzter Ausweg oder Override-Dienst, wenn sich eine Appliance im Inline-Modus befindet. Wenn eine Ziel-IP-Adresse nicht mit einer anderen Route übereinstimmt, leitet die SD-WAN-Appliance sie einfach an die WAN-Verbindung im nächsten Hop weiter. Eine Standardroute: 0.0.0.0/0 Kosten von 16 Pass-Through-Routen werden automatisch erstellt. Passthrough funktioniert nicht, wenn die SD-WAN-Appliance außerhalb des Pfades oder im Edge/Gateway-Modus bereitgestellt wird. Jeder Datenverkehr, der dieser Route (Subnetz) entspricht, wird als Passthrough für diese Appliance klassifiziert. Es wird empfohlen, dass der Passthrough-Verkehr so weit wie möglich begrenzt ist.

Hinweis

Passthrough kann nützlich sein, wenn Sie einen POC durchführen, um zu vermeiden, dass zahlreiche Routings konfiguriert werden müssen. Seien Sie jedoch vorsichtig in der Produktion, da SD-WAN die WAN-Link-Auslastung für Datenverkehr, der an Passthrough gesendet wird, nicht berücksichtigt. Es ist auch hilfreich, wenn Sie Probleme beheben und einen bestimmten IP-Fluss über den virtuellen Pfad aus der Zustellung herausnehmen möchten.

• Verwerfen - Dies ist kein Dienst, sondern eine letzte Ausweg, die die Pakete fallen lassen, wenn sie übereinstimmen. Normalerweise tritt dies nicht auf, wenn die SD-WAN-Appliance außerhalb des Pfades bereitgestellt wird. Sie müssen einen Intranetdienst oder eine lokale Route als Catch all Route haben, andernfalls wird der Datenverkehr verworfen, da kein Passthrough-Dienst vorhanden ist (obwohl eine Passthrough-Standardroute vorhanden ist).

Die Routing-Tabelle für den lokalen Client-Knoten kann auf der Seite Überwachung > Statistiken überwacht werden, wobei Routen für die Dropdownliste Anzeigen ausgewählt sind.

Jede Route für Subnetze von Remote-Zweigstellen wird über den virtuellen Pfad, der über den MCN verbunden ist, als Dienst beworben, wobei die Spalte Site mit dem Client-Knoten gefüllt ist, in dem sich das Ziel als lokales Subnetz befindet.

Im folgenden Beispiel hat Zweig A bei aktivierter WAN-to-WAN-Weiterleitung (Routes Export) einen Routingtabelleneintrag für das Branch B-Subnetz (10.2.2.0/24) durch den MCN als nächsten Hop.

Übereinstimmung mit dem Citrix SD-WAN Datenverkehr auf definierten Routen

Der Abgleichsprozess für definierte Routen auf Citrix SD-WAN basiert auf der längsten Präfixübereinstimmung für das Zielsubnetz (ähnlich wie bei einem Routervorgang). Je spezifischer die Route ist, desto höher ist die Änderung. Die Sortierung erfolgt in der folgenden Reihenfolge:

1. Längste Präfix-Übereinstimmungen
2. Kosten
3. Service

Daher geht eine /32-Route immer einer /31-Route voraus. Bei zwei /32-Strecken geht eine kostengünstige 4-Route immer einer Route mit Kosten 5 voraus. Für zwei /32 kosten 5 Routen werden Routen basierend auf dem bestellten IP-Host ausgewählt. Serviceauftrag ist wie folgt: Lokal, Virtueller Pfad, Intranet, Internet, Passthrough, Verwerfen.

Betrachten Sie als Beispiel die folgenden beiden Routen wie folgt:

• 192.168.1.0/24 Kosten 5

• 192.168.1.64/26 Kosten 10

Ein Paket, das für den Host 192.168.1.65 bestimmt ist, würde die letztere Route verwenden, obwohl die Kosten höher sind. Auf dieser Grundlage ist es üblich, dass die Konfiguration nur für die Routen vorhanden ist, die über das Virtual Path Overlay bereitgestellt werden sollen, wobei anderer Datenverkehr alle Routen abfangen, z. B. eine Standardroute zum Passthrough-Service.

Routen können in einer Standortknoten-Tabelle konfiguriert werden, die das gleiche Präfix haben. Der Unterbrechung geht dann zu den Routenkosten, dem Diensttyp (Virtueller Pfad, Intranet, Internet usw.) und der nächsten Hop-IP.

Citrix SD-WAN Routingpaketfluss

• LAN zu WAN (virtueller Pfad) Traffic Route Matching:

  1. Eingehender Verkehr wird von der LAN-Schnittstelle empfangen und verarbeitet.

  2. Der empfangene Frame wird mit der Routentabelle für die längste Präfixübereinstimmung verglichen.

  3. Wenn eine Übereinstimmung gefunden wird, wird der Frame von der Regelengine verarbeitet und ein Flow in der Flow-Datenbank erstellt.

• WAN zu LAN (virtueller Pfad) Traffic Route Matching:

  1. Virtual Path Traffic wird von SD-WAN vom Tunnel empfangen und verarbeitet.

  2. Die Appliance vergleicht die Quell-IP-Adresse, um festzustellen, ob die Quelle lokal ist.

     • Wenn ja, dann ist WAN berechtigt und passt das IP-Ziel mit der Routingtabelle/dem virtuellen Pfad an.

     • Wenn nein - dann wurde die Überprüfung der WAN-zu-WAN-Weiterleitung aktiviert.

  3. (WAN-zu-WAN-Weiterleitung deaktiviert) Weiterleiten an LAN basierend auf lokalen Routen.

  4. (WAN-zu-WAN-Weiterleitung aktiviert) Weiterleiten an virtuellen Pfad basierend auf der Routingtabelle.

• Nicht-virtueller Pfadverkehr:

  1. Eingehender Datenverkehr wird über die LAN-Schnittstelle empfangen und verarbeitet.

  2. Der empfangene Frame wird mit der Routentabelle für die längste Präfixübereinstimmung verglichen.

  3. Wenn eine Übereinstimmung gefunden wird, wird der Frame von der Regelengine verarbeitet und ein Flow in der Flow-Datenbank erstellt.

Unterstützung für Citrix SD-WAN Routingprotokoll

Citrix SD-WAN Version 9.1 führte OSPF- und BGP-Routingprotokolle in die Konfiguration ein. Die Einführung von Routing-Protokollen in SD-WAN ermöglichte eine einfachere Integration von SD-WAN in komplexere Unterlagsnetzwerke, in denen Routing-Protokolle aktiv verwendet werden. Da dieselben Routingprotokolle im SD-WAN Orchestrator Service aktiviert waren, wurde die Konfiguration von Subnetzen, die für die Verwendung des SD-WAN-Overlays angegeben sind, vereinfacht. Darüber hinaus ermöglichen die Routing-Protokolle die Kommunikation zwischen SD-WAN- und Nicht-SD-WAN-Standorten mit direkter Kommunikation mit bestehenden Kunden-Edge-Routern unter Verwendung des gemeinsamen Routing-Protokolls. Citrix SD-WAN, die an Routingprotokollen im Unterlagennetzwerk teilnehmen, kann unabhängig vom Bereitstellungsmodus von SD-WAN (Inline-Modus, Virtual Inline-Modus oder Edge/Gateway-Modus) durchgeführt werden. Außerdem kann SD-WAN im “Nur lernen” -Modus bereitgestellt werden, in dem SD-WAN Routen empfangen, aber keine Routen zur Unterlage ankündigen kann. Dies ist nützlich, wenn die SD-WAN-Lösung in ein Netzwerk eingeführt wird, in dem die Routinginfrastruktur komplex oder unsicher ist.

Wichtig

Es ist einfach, den unerwünschten Weg zu lecken, wenn Sie nicht vorsichtig sind.

Die SD-WAN Virtual Path Routen-Tabelle funktioniert wie ein External Gateway Protocol (EGP), ähnlich wie BGP (Think Site-to-Site). Wenn SD-WAN beispielsweise Routen von der SD-WAN-Appliance zu OSPF anmeldet, werden sie normalerweise als extern für Standort und Protokoll betrachtet.

Hinweis

Beachten Sie Umgebungen mit IGPs über die gesamte Infrastruktur (über das WAN), da dies die Verwendung von SD-WAN-angekündigten Routen erschwert. EIGRP wird in großem Umfang auf dem Markt verwendet, und SD-WAN arbeitet nicht mit diesem Protokoll zusammen.

Eine Herausforderung bei der Einführung von Routingprotokollen in eine SD-WAN-Bereitstellung besteht darin, dass die Routingtabelle erst verfügbar ist, wenn der SD-WAN-Dienst aktiviert und im Netzwerk ausgeführt wird. Daher wird es nicht empfohlen, zuerst Ankündigungsrouten von der SD-WAN-Appliance zu aktivieren. Verwenden Sie die Import- und Exportfilter für eine schrittweise Einführung von Routing-Protokollen auf SD-WAN.

Lassen Sie uns einen genaueren Blick, indem Sie das folgende Beispiel überprüfen:

In diesem Beispiel untersuchen wir einen Anwendungsfall des Routingprotokolls. Das vorhergehende Netzwerk hat vier Standorte: New York, Dallas, London und San Francisco. Wir stellen SD-WAN-Appliances an drei dieser Standorte bereit und verwenden SD-WAN, um ein hybrides WAN-Netzwerk zu erstellen, in dem MPLS- und Internet-WAN-Links verwendet werden, um ein virtualisiertes WAN bereitzustellen. Da Dallas kein SD-WAN-Gerät haben wird, müssen wir überlegen, wie Sie am besten in bestehende Routenprotokolle zu diesem Standort integrieren können, um eine vollständige Konnektivität zwischen Unterlagen- und SD-WAN-Overlay-Netzwerken zu gewährleisten.

Im Beispielnetzwerk wird eBGP zwischen allen vier Standorten im MPLS-Netzwerk verwendet. Jeder Standort hat seine eigene Autonome Systemnummer (ASN).

Im New Yorker Rechenzentrum wird OSPF ausgeführt, um die Kernsubnetze des Rechenzentrums an die Remotestandorte anzukündigen und außerdem eine Standardroute von der New York Firewall (E) anzukündigen. In diesem Beispiel wird der gesamte Internetverkehr in das Rechenzentrum zurückgeführt, obwohl die Niederlassungen in London und San Francisco über einen Pfad zum Internet verfügen.

Der Standort San Francisco muss ebenfalls darauf hingewiesen werden, dass er keinen Router hat. SD-WAN wird im Edge/Gateway-Modus bereitgestellt, wobei diese Appliance das Standard-Gateway für das San Francisco-Subnetz ist und auch an eBGP zum MPLS beteiligt ist.

• Beachten Sie beim New Yorker Rechenzentrum, dass das SD-WAN im virtuellen Inline-Modus bereitgestellt wird. Die Absicht besteht darin, am vorhandenen OSPF-Routing-Protokoll teilzunehmen, um den Datenverkehr als bevorzugtes Gateway an die Appliance weiterzuleiten.
• Der Standort London wird im traditionellen Inline-Modus eingesetzt. Der Upstream-WAN-Router (C) wird weiterhin das Standardgateway für das Londoner Subnetz sein.
• Der Standort San Francisco ist ein neu eingeführter Standort für dieses Netzwerk, und das SD-WAN soll im Edge/Gateway-Modus bereitgestellt werden und als Standardgateway für das neue San Francisco-Subnetz fungieren.

Überprüfen Sie einige der vorhandenen Unterlagen-Routentabellen, bevor Sie SD-WAN implementieren.

New York Core Router B:

Die lokalen New Yorker Subnetze (172.x.x.x) sind auf Router B als direkt verbunden verfügbar, und aus der Routingtabelle erkennen wir, dass die Standardroute 172.10.10.3 (Firewall E) ist. Außerdem können wir sehen, dass Subnetze von Dallas (10.90.1.0/24) und London (10.100.1.0/24) über 172.10.10.1 (MPLS Router A) verfügbar sind. Die Streckenkosten deuten darauf hin, dass sie von eBGP gelernt wurden.

Hinweis

Im angegebenen Beispiel wird San Francisco nicht als Route aufgeführt, da wir die Site noch nicht mit SD-WAN im Edge/Gateway-Modus für dieses Netzwerk bereitgestellt haben.

Für den New York WAN Router (A) sind OSPF erlernte Routen und Routen aufgelistet, die über das MPLS durch eBGP gelernt wurden. Beachten Sie die Routenkosten. BGP ist eine niedrigere administrative Domäne und kostet standardmäßig 20/1 im Vergleich zu OSPF 110/10.

Dallas Router D:

Für den Dallas WAN Router (D) werden alle Routen über das MPLS erlernt.

Hinweis

In diesem Beispiel können Sie das Subnetz 192.168.65.0/24 ignorieren. Dies ist ein Management-Netzwerk und nicht relevant für das Beispiel. Alle Router sind mit dem Management-Subnetz verbunden, werden jedoch in keinem Routingprotokoll angekündigt.

Der eBGP-Peers untereinander. Jede ASN ist anders.

Es ist wichtig zu verstehen, wie die Routen zwischen der Routingtabelle des virtuellen Pfades und den verwendeten dynamischen Routenprotokollen übergeben werden. Es ist einfach, Routingschleifen zu erstellen oder Routen in einer ungünstigen Weise zu werben. Der Filtermechanismus gibt uns die Möglichkeit zu steuern, was in die Routing-Tabelle ein- und ausgeht. Wir betrachten jeden Standort nacheinander.

• Der Standort San Francisco verfügt über zwei lokale Subnetze 10.80.1.0/24 und 10.81.1.0/24. Wir wollen sie über eBGP bewerben, damit Standorte wie Dallas noch über das Unterlay-Netzwerk den Standort San Francisco erreichen können und auch Standorte wie London und New York über das Virtual Path Overlay-Netzwerk weiterhin San Francisco erreichen können. Wir möchten auch von der Erreichbarkeit von eBGP auf alle Standorte lernen, falls das SD-WAN Virtual Path Overlay ausfällt und die Umgebung auf die Verwendung von MPLS zurückgreifen muss. Wir wollen auch nichts lesen, was SD-WAN von eBGP bis zu den SD-WAN-Routern lernt. Um dies zu erreichen, müssen die Filter wie folgt konfiguriert werden:

• Importieren Sie alle Routen aus eBGP. Routen nicht in SD-WAN-Appliances lesen/exportieren.

• Lokale Routen nach eBGP exportieren

Die Standardregel für den Export lautet, alles zu exportieren. Regel 200 wird verwendet, um die Fehlerregel außer Kraft zu setzen, um die Routen nicht neu zu anzukündigen. Jede Route, die mit einem Präfix SD-WAN übereinstimmt, hat über die virtuellen Pfade gelernt.

Nachdem die Citrix SD-WAN Appliances bereitgestellt wurden, können wir einen aktualisierten Blick auf die Routentabellen für den BGP-Router am Standort Dallas werfen. Wir sehen, dass 10.80.1.0/24 und 10.81.1.0/24 Subnetze korrekt durch eBGP vom San Francisco SD-WAN aus gesehen werden.

Dallas Router D:

Darüber hinaus kann die Citrix SD-WAN Routentabelle auf der Seite Überwachung > Statistiken > Routen anzeigen angezeigt werden.

San Francisco Citrix SD-WAN:

Citrix SD-WAN zeigt alle erlernten Routen an, einschließlich Routen, die über das virtuelle Pfad-Overlay verfügbar sind.

Betrachten wir 172.10.10.0/24, die sich im New York Data Center befindet. Diese Route wird auf zwei Arten erlernt:

• Als Virtual Path Route (Nummer 3), Service = NYC-SFO mit einem Preis von 5 und Typ statisch. Dies ist ein lokales Subnetz, das von der SD-WAN-Appliance in New York angekündigt wird. Es ist insofern statisch, als es entweder direkt mit der Appliance verbunden ist oder es sich um eine manuelle statische Route handelt, die in die Konfiguration eingegeben wurde. Es ist erreichbar, da sich der virtuelle Pfad zwischen den Sites in einem funktionieren/aufbereitenden Zustand befindet.

• Als beworbene Route durch BGP (Nummer 6), mit einem Preis von 6. Dies gilt jetzt als Fallback-Route.

Da das Präfix gleich ist und die Kosten unterschiedlich sind, verwendet SD-WAN die virtuelle Pfadroute, es sei denn, sie wird nicht verfügbar. In diesem Fall wird die Fallback-Route über BGP erlernt.

Betrachten wir nun die Route 172.20.20.0/24.

• Dies wird als Virtual Path Route (Nummer 9) erlernt, hat aber eine Art von Dynamik und einen Preis von 6. Dies bedeutet, dass die Remote-SD-WAN-Appliance diese Route über ein Routingprotokoll, in diesem Fall OSPF, gelernt hat. Standardmäßig sind die Routenkosten höher.

• SD-WAN lernt diese Route auch über BGP mit den gleichen Kosten, so dass in diesem Fall diese Route möglicherweise gegenüber der Virtual Path Route bevorzugt wird.

Um ein korrektes Routing zu gewährleisten, müssen wir die BGP-Routenkosten erhöhen, um sicherzustellen, ob wir eine Virtual Path Route haben und es ist die bevorzugte Route. Dies kann getan werden, indem Sie das Gewicht der Import-Filter-Route so anpassen, dass es höher ist als der Standardwert 6 ist.

Nach der Anpassung können wir die SD-WAN-Routentabelle auf der San Francisco-Appliance aktualisieren, um die angepassten Routenkosten anzuzeigen. Verwenden Sie die Filteroption, um die angezeigte Liste zu fokussieren.

Lassen Sie uns schließlich die erlernte Standardroute auf dem San Francisco SD-WAN betrachten. Wir wollen den gesamten Internetverkehr nach New York zurückholen. Wir können sehen, dass wir es mit dem virtuellen Pfad senden, wenn es oben ist, oder durch das MPLS-Netzwerk als Fallback.

Wir sehen auch eine Passthrough und verwerfen Route mit Kosten 16. Dies sind automatische Routen, die nicht entfernt werden können. Wenn das Gerät inline ist, wird die Passthrough-Route als letzter Ausweg verwendet. Wenn also ein Paket nicht mit einer spezifischeren Route abgeglichen werden kann, leitet SD-WAN es an den nächsten Hop der Schnittstellengruppe weiter. Wenn sich das SD-WAN außerhalb des Pfades befindet oder sich im Edge-/Gateway-Modus befindet, gibt es keinen Passthrough-Dienst. In diesem Fall verlässt SD-WAN das Paket mithilfe der standardmäßigen Discard-Route. Die Anzahl der Treffer gibt die Anzahl der Pakete an, die jede Route erreichen, was bei der Fehlerbehebung wertvoll sein kann.

Wenn wir uns jetzt auf die New Yorker Site konzentrieren, möchten wir den Datenverkehr für entfernte Standorte (London und San Francisco) an die SD-WAN-Appliance weiterleiten, wenn der virtuelle Pfad aktiv ist.

Auf der New Yorker Site sind mehrere Subnetze verfügbar:

• 172.10.10.0/24 (direkt angeschlossen)

• 172.20.20.0/24 (über OSPF vom Core-Router B aus beworben)

• 172.30.30.0/24 (über OSPF vom Core-Router B aus beworben)

Wir müssen auch den Verkehrsfluss nach Dallas (10.100.1.0/24) über MPLS bereitstellen.

Schließlich wollen wir die gesamte internetgebundene Verkehrsroute zur Firewall E bis 172.10.10.3 als nächsten Hop. SD-WAN lernt diese Standardroute über OSPF und kündigt über den virtuellen Pfad an. Die Filter für die New Yorker Site sind:

Der New York SD-WAN-Standort importiert alle Routen für das Management-Netzwerk. Dies kann ignoriert werden. Wir können uns auf Filter 200 konzentrieren.

Filter 200 wird verwendet, um 192.168.10.0/24 (unser MPLS-Kern) für Erreichbarkeit zu importieren, aber nicht um ihn in den virtuellen Pfad zu exportieren. Aktivieren Sie das Kontrollkästchen Einschließen, und stellen Sie sicher, dass das Kontrollkästchen Route zu Citrix Appliances exportieren deaktiviert ist. Alle anderen Routen sind dann eingeschlossen.

Für die Exportfilter können wir die Route für 192.168.10.0/24 ausschließen. Dies liegt daran, dass wir als direkt verbundenes Subnetz am Standort San Francisco diese Route nicht an der Quelle herausfiltern können, so dass sie an diesem Ende unterdrückt wird.

Lassen Sie uns nun die aktualisierte Routen-Tabelle überprüfen, die an der Kernroute in New York beginnt.

New York Router B:

Die Subnetze für San Francisco (10.80.1.0 & 10.81.1.0) und London (10.90.1.0) werden nun über die New York SD-WAN Appliance (172.10.10.10) beworben. Die Route 10.100.1.0/24 wird immer noch über die Unterlage MPLS Router A beworben. Lassen Sie uns die SD-WAN-Routentabelle des New Yorker Standorts überprüfen.

New Yorker Standort SD-WAN Routentabelle:

Wir können die richtigen Routen für die lokalen Subnetze sehen, die über OSPF gelernt wurden, eine Route zum Standort Dallas, die vom MPLS Router A gelernt wurde, und die Remote-Subnetze für die Standorte San Francisco und London. Schauen wir uns den MPLS Router A an. Dieser Router beteiligt sich an OSPF und BGP.

Aus der Routentabelle lernt dieser Router A die entfernten Subnetze über BGP und OSPF mit der administrativen Entfernung und Kosten der BGP-Route (20/5) niedriger als OSPF (110/10) und daher bevorzugt. In diesem Beispiel kann das Netzwerk, in dem nur eine Kernroute vorhanden ist, keine Bedenken verursachen. Der hier ankommende Datenverkehr würde jedoch über das MPLS-Netzwerk zugestellt und nicht an die SD-WAN-Appliance gesendet werden (172.10.10.10). Wenn wir eine vollständige Routing-Symmetrie beibehalten möchten, benötigen wir eine Routenkarte, um die AD/Metrik-Kosten so anzupassen, dass es Routenpräferenz von der Route kommt aus 172.10.10.10 statt der Route, die über eBGP gelernt wurde.

Alternativ kann eine “Backdoor” -Route konfiguriert werden, um den Router zu zwingen, die OSPF-Route der BGP-Route vorzuziehen. Beachten Sie die statische Route für die virtuelle SD-WAN-IP-Adresse zur SD-WAN-Appliance des Londoner Standorts.

Dies ist erforderlich, um sicherzustellen, dass der virtuelle Pfad wieder an die SD-WAN-Appliance des New Yorker Standortes weitergeleitet wird, wenn der MPLS-Pfad ausfällt. Da gibt es eine Route für den 10.90.1.0/24, der über 172.10.10.10 (New York SD-WAN) beworben wird. Es wird auch empfohlen, eine Override-Dienstregel zu erstellen, um alle 4.980-Pakete von UDP auf der SD-WAN-Appliance zu verwerfen, um zu verhindern, dass der virtuelle Pfad zu sich selbst zurückkehrt.

Dynamische virtuelle Pfade

Dynamische virtuelle Pfade können zwischen zwei Clientknoten erlaubt werden, virtuelle Pfade auf Anforderung für die direkte Kommunikation zwischen den beiden Standorten zu erstellen. Der Vorteil eines dynamischen virtuellen Pfads besteht darin, dass der Datenverkehr direkt von einem Clientknoten zum zweiten fließen kann, ohne das MCN oder zwei virtuelle Pfade durchlaufen zu müssen, wodurch der Verkehrsfluss Latenz ermöglicht wird. Dynamische virtuelle Pfade werden basierend auf benutzerdefinierten Datenverkehrsschwellenwerten dynamisch erstellt und entfernt. Diese Schwellenwerte werden entweder als Pakete pro Sekunde (pps) oder Bandbreite (kbps) definiert. Diese Funktion ermöglicht eine dynamische Full-Mesh-SD-WAN-Overlay-Topologie.

Sobald die Schwellenwerte für dynamische virtuelle Pfade erreicht sind, erstellen die Clientknoten dynamisch ihren virtualisierten Pfad zueinander unter Verwendung aller verfügbaren WAN-Pfade zwischen den Standorten und nutzen ihn auf folgende Weise voll aus:

• Senden Sie Massendaten, falls vorhanden, und überprüfen Sie dann keinen Verlust

• Senden Sie interaktive Daten und überprüfen Sie dann keinen Verlust

• Senden Sie Echtzeitdaten, nachdem die Bulk- und interaktiven Daten als stabil angesehen wurden (kein Verlust oder akzeptable Werte)

• Wenn keine Massen- oder interaktive Daten vorhanden sind, senden Sie Echtzeitdaten, nachdem der dynamische virtuelle Pfad für einen Zeitraum stabil war

• Wenn die Benutzerdaten für einen benutzerdefinierten Zeitraum unter die konfigurierten Schwellenwerte fallen, wird der dynamische virtuelle Pfad abgerissen

Dynamische virtuelle Pfade haben das Konzept einer Zwischen-Site. Der Zwischenstandort kann ein MCN-Standort oder ein anderer Standort im Netzwerk sein, für den der statische virtuelle Pfad konfiguriert und mit zwei oder mehr anderen Clientknoten verbunden ist. Eine weitere Anforderung zur Entwurfsüberlegung besteht darin, dass die WAN-zu-WAN-Weiterleitung aktiviert ist, sodass alle Routen von allen Standorten an die Clientknoten angekündigt werden können, auf denen der dynamische virtuelle Pfad gewünscht wird.

In SD-WAN sind mehrere WAN-zu-WAN-Weiterleitungsgruppen zulässig, wodurch die vollständige Kontrolle über die Pfadeinrichtung zwischen bestimmten Clientknoten und nicht anderen ermöglicht wird.

Jedes SD-WAN-Gerät verfügt über eine eigene eindeutige Routentabelle mit den folgenden Details für jede Route:

• Num — Reihenfolge der Route dieser Appliance basierend auf dem Übereinstimmungsprozess (niedrigste zuerst verarbeitete Num)

• Netzwerkadresse — Subnetz- oder Hostadresse

• Gateway bei Bedarf

• Service — welcher Dienst wird für diese Route angewendet

• Firewallzone — die Firewallzonenklassifizierung der Route

• Erreichbar — Identifiziert, ob der Status des virtuellen Pfads für diese Site aktiv ist

• Standort — Der Name des Standorts, an dem die Route voraussichtlich existieren wird

• Typ — Identifizierung des Routentyps (statisch oder dynamisch)

• Nachbar Direkt

• Kosten - Kosten der spezifischen Route

• Anzahl der Treffer — wie oft wurde die Route pro Paket verwendet. Dies würde verwendet, um zu überprüfen, ob eine Route korrekt getroffen wird.

• Berechtigt

• Art der Teilnahmeberechtigung

• Berechtigungswert

Der folgende Code ist ein Beispiel für eine SD-WAN-Standortroute:

Beachten Sie aus der vorangegangenen SD-WAN-Routentabelle, dass in herkömmlichen Routern normalerweise mehr Elemente nicht verfügbar sind. Am bemerkenswertesten ist die Spalte Erreichbar, die die Route je nach WAN-Pfadstatus entweder aktiv oder inaktiv (ja/nein) macht. Die hier aufgelisteten Routen werden basierend auf verschiedenen Zuständen des Dienstes unterdrückt (der virtuelle Pfad ist als Beispiel heruntergefahren). Andere Ereignisse, die erzwingen können, dass eine Route nicht berechtigt ist, sind Pfad-Down-Status, nächster Hop nicht erreichbar oder WAN-Link down.

Aus der obigen Tabelle können wir 14 definierte Routen sehen. Eine Beschreibung der Routen oder Streckengruppen wird wie folgt beschrieben:

• Route 0 — Auf dem MCN handelt es sich um eine Host-Subnetzroute, die sich am DC-Standort befindet. 172.16.10.0/24 befindet sich im DC-LAN und 192.168.15.1 ist das Gateway im LAN, das der nächste Hop ist, der zu diesem Subnetz gelangen wird.

• Route 1 — Dies ist eine lokale Route zu diesem SD-WAN-Gerät, die die Routentabelle anzeigt.

• Route 2—4 — Dies sind die Subnetze, die Teil der virtuellen Schnittstellen sind, die für das DC-Standort SD-WAN konfiguriert sind. Diese Subnetze werden von den definierten vertrauenswürdigen virtuellen Schnittstellen abgeleitet.

• Route 5 — Dies ist eine gemeinsame Route zu einem anderen Clientknoten, der vom MCN mit dem Erreichbarkeitsstatus Nein aufgrund des virtuellen Pfads nach unten zwischen diesem Standort und dem MCN gemeinsam genutzt wird.

• Route 6—9 — Diese Routen existieren an einem anderen Kundenstandort. Für diese Route wird eine virtuelle Pfadroute für den passenden WAN-Datenverkehr erstellt, der für die Remotesite auf dem virtuellen Pfad bestimmt ist.

• Route 10 — Wenn der Internetdienst definiert ist, fügt das System eine Catch All Route für direkte Internetausbrüche für diese lokale Site hinzu.

• Route 11 — Passthrough ist die Standardroute, die das System immer hinzufügt, damit Pakete durchfließen können, falls es keine Übereinstimmung auf vorhandenen Routen gibt. Der Passthrough wird nicht gepflegt, normalerweise werden lokale Broadcasts und ARP-Datenverkehr diesem Dienst zugeordnet.

• Route 12 — Verwerfen ist die Standardroute, die das System immer hinzufügt, um etwas undefiniertes zu löschen.

Die Standardwerte für die Routenkosten:

• WAN-zu-WAN-Weiterleitung — 10

• Standardkosten für direkte Routen — 5

• Automatisch generierte Routen — 5

• Virtueller Pfad — 5

• Lokal — 5

• Intranet — 5

• Internet — 5

• Passthrough — 5

• Optional — Route ist 0.0.0.0/0 definiert als Service-Level

Nach der Definition dieser Routen ist es wichtig zu verstehen, wie der Verkehr über die definierten Routen fließt. Diese Verkehrsströme sind in folgende Flüsse unterteilt:

• LAN zu WAN (virtueller Pfad) — Verkehr in den SD-WAN-Overlay-Tunnel

• WAN zu LAN (Virtual Path) — Verkehr, der den SD-WAN-Overlay-Tunnel existiert

• Nicht-virtueller Pfadverkehr — Verkehr wird an das Unterlagennetzwerk weitergeleitet

Intranet und Internetrouten

Für die Intranet- und Internetdiensttypen muss der Benutzer einen SD-WAN-WAN-Link definiert haben, um diese Arten von Diensten zu unterstützen. Es ist eine Voraussetzung für alle definierten Strecken für einen dieser Dienste. Wenn die WAN-Verbindung nicht zur Unterstützung des Intranetdienstes definiert ist, wird sie als lokale Route betrachtet. Die Intranet-, Internet- und Passthrough-Routen sind nur für die Site/Appliance relevant, für die sie konfiguriert sind.

Bei der Definition von Intranet-, Internet- oder Passthrough-Routen sind folgende Entwurfsüberlegungen:

• Muss Dienst auf der WAN-Verbindung definiert haben (Intranet/Internet — erforderlich)

• Intranet/Internet muss ein Gateway für die WAN-Verbindung definiert haben

• Relevant für lokales SD-WAN-Gerät

• Intranet-Routen können über den virtuellen Pfad erlernt werden, werden jedoch zu höheren Kosten durchgeführt

• Mit Internet Service wird automatisch eine Standard-Route erstellt (0.0.0.0/0) fangen alle Route mit einem maximalen Preis

• Gehen Sie nicht davon aus, dass Passthrough funktioniert, es muss getestet/verifiziert werden, auch testen Sie mit Virtual Path herunter/deaktiviert, um das gewünschte Verhalten zu überprüfen

• Routentabellen sind statisch, es sei denn, die Routenlernfunktion ist aktiviert

  Der maximal unterstützte Grenzwert für mehrere Routingparameter lautet wie folgt:

• Maximale Routingdomänen: 255

• Maximale Zugriffsschnittstellen pro WAN-Link: 64

• Maximale BGP-Nachbarn pro Standort: 255

• Maximale OSPF-Fläche pro Standort: 255

• Maximale virtuelle Schnittstellen pro OSPF-Bereich: 255

• Maximale Route Learning-Importfilter pro Standort: 512

• Maximale Exportfilter für Route Learning pro Standort: 512

• Maximale BGP-Routing-Richtlinien: 255

• Maximale BGP-Community-String-Objekte: 255