Wird Cisco SD-WAN den Ast absägen, auf dem DMVPN sitzt?

Seit August 2017, als Cisco das Unternehmen Viptela übernahm, wurde die Haupttechnologie zur Bereitstellung verteilter Unternehmensnetzwerke Cisco SD-WAN. In den vergangenen 3 Jahren hat sich die SD-WAN-Technologie qualitativ und quantitativ erheblich weiterentwickelt. Die Funktionalitäten wurden erheblich erweitert und die Unterstützung für die klassischen Router-Serien Cisco ISR 1000, ISR 4000, ASR 1000 und den virtuellen CSR 1000vwurde eingeführt. Gleichzeitig stellen sich viele Kunden und Partner von Cisco die Frage – worin die Unterschiede zwischen Cisco SD-WAN und den bereits vertrauten Ansätzen auf Basis von Technologien wie Cisco DMVPN und Cisco Performance Routing liegen und wie wichtig diese Unterschiede sind?

Hierbei sollte sofort angemerkt werden, dass die Technologien DMVPN und PfR vor der Einführung von SD-WAN in das Portfolio von Cisco einen zentralen Bestandteil der Architektur Cisco IWAN (Intelligent WAN)darstellten, die wiederum der Vorläufer der vollwertigen SD-WAN-Technologie war. Trotz der allgemeinen Ähnlichkeiten in den zu lösenden Aufgaben und den Lösungsansätzen erreichte IWAN nicht das erforderliche Maß an Automatisierung, Flexibilität und Skalierbarkeit für SD-WAN, und die Weiterentwicklung von IWAN nahm im Laufe der Zeit erheblich ab. Dennoch sind die Technologien, die IWAN bilden, nicht verschwunden, und viele Kunden setzen sie weiterhin erfolgreich, auch auf moderneren Geräten, ein. So ist eine interessante Situation entstanden – dieselbe Cisco-Hardware ermöglicht die Wahl der am besten geeigneten Technologie zur WAN-Erstellung (klassisch, DMVPN+PfR oder SD-WAN) entsprechend den Anforderungen und Erwartungen der Kunden.

Der Artikel hat nicht die Absicht, alle Besonderheiten der Technologien Cisco SD-WAN und DMVPN (gemeinsam oder ohne Performance Routing) im Detail zu erörtern – dafür stehen zahlreiche Dokumente und Materialien zur Verfügung. Die Hauptaufgabe besteht darin, die wesentlichen Unterschiede dieser Technologien zu bewerten. Bevor wir jedoch auf diese Unterschiede eingehen, lassen Sie uns kurz die Technologien selbst in Erinnerung rufen.

Was ist Cisco DMVPN und wozu wird es benötigt?

Cisco DMVPN löst das Problem der dynamischen (= skalierbaren) Anbindung eines entfernten Filialnetzwerks an das Netzwerk des zentralen Unternehmensbüros unter der Verwendung beliebiger Übertragungstechnologien, einschließlich des Internets (= mit Verschlüsselung des Übertragungskanals). Technisch wird dies durch die Schaffung eines virtualisierten, überlagerten Netzwerks der Klasse L3 VPN im Punkt-zu-Mehrpunkt-Modus (point-to-multipoint) mit einer logischen Topologie vom Typ "Stern" (Hub-n-Spoke) realisiert. Dazu nutzt DMVPN eine Kombination der folgenden Technologien:

• IP-Routing
• Multipoint GRE-Tunnel (mGRE)
• Next Hop Resolution Protocol (NHRP)
• IPSec-Krypto-Profile

Was sind die Hauptvorteile von Cisco DMVPN im Vergleich zur klassischen Routing mit MPLS VPN-Kanälen?

• Zur Schaffung eines interfilialen Netzwerks können beliebige Übertragungskanäle verwendet werden – alles, was die IP-Konnektivität zwischen den Filialen sicherstellt, wobei der Datenverkehr an den entsprechenden Stellen sowohl verschlüsselt als auch balanciert wird.
• Es wird automatisch eine voll verbundene Topologie zwischen den Filialen gebildet. Dabei gibt es zwischen der zentralen und der entfernten Filiale statische Tunnel, während zwischen den entfernten Filialen dynamische Tunnel bei Bedarf (bei Vorhandensein von Datenverkehr) bestehen.
• An den Routern der zentralen und entfernten Filiale gibt es eine einheitliche Konfiguration bis hin zu IP-Adressen den Schnittstellen. Durch den Einsatz von mGRE entfällt die Notwendigkeit, Dutzende, Hunderte oder sogar Tausende von Tunneln individuell einzurichten. Dies führt zu einer angemessenen Skalierbarkeit bei richtiger Gestaltung.

Was ist Cisco Performance Routing und wozu wird es benötigt?

Bei der Verwendung von DMVPN bleibt in einem interfilialen Netzwerk eine äußerst wichtige Frage offen – wie kann man den Zustand jedes DMVPN-Tunnels dynamisch bewerten, um sicherzustellen, dass er den Anforderungen des geschäftskritischen Datenverkehrs unserer Organisation entspricht, und auf Grundlage dieser Bewertung dynamische Entscheidungen über die Umleitung treffen? Tatsache ist, dass sich DMVPN in diesem Punkt nur wenig von der klassischen Routing unterscheidet – das Beste, was man tun kann, ist, QoS-Mechanismen einzurichten, die den Datenverkehr in ausgehender Richtung priorisieren, aber nicht in der Lage sind, den Zustand des gesamten Pfades zu einem bestimmten Zeitpunkt zu berücksichtigen.

Und was ist zu tun, wenn der Kanal teilweise und nicht vollständig abgebaut wird – wie kann man das erkennen und bewerten? DMVPN kann das von sich aus nicht. Angesichts der Tatsache, dass die Verbindungen zwischen den Filialen durch verschiedene Dienstanbieter gehen und unterschiedliche Technologien nutzen, wird diese Aufgabe höchst komplex. Hier kommt die Technologie Cisco Performance Routing ins Spiel, die zu diesem Zeitpunkt bereits einige Entwicklungsstufen durchlaufen hatte.

Die Aufgabe von Cisco Performance Routing (PfR) besteht darin, den Zustand der Übertragungspfade (Tunnel) des Datenverkehrs auf der Grundlage von Schlüsselkennzahlen zu messen, die für Netzwerk Anwendungen wichtig sind – Latenz, Latenzvariation (Jitter) und Paketverluste (in Prozent). Darüber hinaus kann die genutzte Bandbreite gemessen werden. Diese Messungen erfolgen so nah wie möglich in Echtzeit (soweit das sinnvoll und gerechtfertigt ist), und das Ergebnis dieser Messungen ermöglicht es dem Router, der PfR verwendet, dynamisch Entscheidungen über die Notwendigkeit zu treffen, die Routing-Strategien für bestimmte Verkehrsarten zu ändern.

Die Aufgabe der Kombination von DMVPN/PfR lässt sich somit kurz wie folgt charakterisieren:

• Dem Kunden zu ermöglichen, alle Arten von Verbindungen in WAN-Netzen zu nutzen
• Die bestmögliche Qualität wichtiger Anwendungen über diese Verbindungen sicherzustellen

Was ist Cisco SD-WAN?

Cisco SD-WAN ist eine Technologie, die den SDN-Ansatz nutzt, um ein WAN-Netzwerk für Unternehmen zu erstellen und zu betreiben. Dies bedeutet insbesondere die Verwendung sogenannter Controller (Softwarekomponenten), die eine zentrale Orchestrierung und automatisierte Konfiguration aller Lösungskomponenten gewährleisten. Im Gegensatz zu einem klassischen SDN (im Clean-Slate-Stil) verwendet Cisco SD-WAN mehrere Typen von Controllern, von denen jeder eine eigene Rolle erfüllt – dies wurde absichtlich so konzipiert, um eine bessere Skalierbarkeit und geo-redundante Architektur zu gewährleisten.

Im Falle von SD-WAN bleibt die Aufgabe, verschiedene Arten von Verbindungen zu nutzen und die Funktionstüchtigkeit von Geschäfts aplikationen sicherzustellen, erhalten. Gleichzeitig erweitern sich jedoch die Anforderungen an Automatisierung, Skalierbarkeit, Sicherheit und Flexibilität des Netzwerks.

Diskussion der Unterschiede

Wenn man nun die Unterschiede dieser Technologien analysiert, fallen sie in eine der folgenden Kategorien:

• Architektonische Unterschiede – wie sind die Funktionen auf verschiedene Komponenten der Lösung verteilt, wie ist die Interaktion dieser Komponenten organisiert und wie wirkt sich dies auf die Möglichkeiten und die Flexibilität der Technologie aus?
• Funktionale Möglichkeiten – was kann eine Technologie, was die andere nicht kann? Ist das wirklich so wichtig?

Wo liegen die architektonischen Unterschiede und sind sie wirklich wichtig?

Jede der genannten Technologien hat viele «bewegliche Teile», bei denen nicht nur die Rolle, sondern auch die Interaktionsprinzipien voneinander abweichen. Die Überlegungen, wie gut diese Prinzipien durchdacht sind, beeinflussen direkt die Skalierbarkeit, Ausfalltoleranz und die Gesamteffizienz der Lösung.

Betrachten wir verschiedene Aspekte der Architektur näher:

Datenebene – der Teil der Lösung, der für die Übertragung des Benutzerdatenverkehrs zwischen Sender und Empfänger verantwortlich ist. In DMVPN und SD-WAN wird dies im Grunde gleich auf den Routern mit Multipoint GRE-Tunneln umgesetzt. Der Unterschied besteht darin, was die erforderliche Parametrierung dieser Tunnel erzeugt:

• in DMVPN/PfR – es handelt sich um eine ausschließlich zweistufige Hierarchie von Knoten mit einer Topologie vom Typ "Stern" oder Hub-n-Spoke. Eine statische Konfiguration des Hubs und eine statische Bindung des Spokes an den Hub sind obligatorisch, ebenso wie die Interaktion über das NHRP-Protokoll zur Bildung der Datenübertragungs-Pfadverbindung. In der Folge sind Änderungen am Hub erheblich erschwert, beispielsweise durch die Änderung/Anbindung neuer WAN-Verbindungen oder die Anpassung bestehender Parameter.
• in SD-WAN – es handelt sich um ein vollständig dynamisches Modell zur Parametererkennung der eingerichteten Tunnel, das auf der Steuerungsebene (OMP-Protokoll) und der Orchestrierungsebene (Interaktion mit dem vBond-Controller zur Erkennung von Controllern und NAT-Traversal) beruht. Dabei können beliebige, einschließlich hierarchische, Topologien verwendet werden. Innerhalb der festgelegten Overlay-Topologie der Tunnel ist eine flexible Anpassung der logischen Topologie in jedem einzelnen VPN (VRF) möglich.

Steuerungsebene – Funktionen für den Austausch, die Filterung und die Modifikation von Routing- und anderen Informationen zwischen den Komponenten der Lösung.

• in DMVPN/PfR – erfolgt nur zwischen den Routern Hub und Spoke. Ein direkter Austausch von Routing-Informationen zwischen Spoke ist nicht möglich. In der Folge ist ohne einen aktiven Hub die Funktionsfähigkeit der Steuerungsebene und der Datenebene nicht möglich, was zusätzliche Anforderungen an die Hochverfügbarkeit des Hubs stellt, die nicht immer erfüllt werden können.
• in SD-WAN – Control Plane wird niemals direkt zwischen den Routern durchgeführt – die Interaktion erfolgt auf Basis des OMP-Protokolls und muss zwingend über einen speziellen Typ von Controller, den vSmart-Controller, realisiert werden. Dies ermöglicht Lastverteilung, Geo-Redundanz und zentrale Steuerung der Signallast. Eine weitere Besonderheit des OMP-Protokolls ist seine erhebliche Robustheit gegenüber Paketverlusten und seine Unabhängigkeit von der Geschwindigkeit der Verbindung zu den Controllern (innerhalb vernünftiger Grenzen). Dies ermöglicht es, SD-WAN-Controller sowohl in öffentlichen als auch in privaten Clouds mit Internetzugang zu hosten.

Policy Plane – Teil der Lösung, der für die Definition, Verteilung und Anwendung von Verkehrsmanagementrichtlinien in einem verteilten Netzwerk verantwortlich ist.

• DMVPN – ist faktisch auf Qualitätssicherungsrichtlinien (QoS) beschränkt, die individuell auf jedem Router über die CLI oder Vorlagen in der Prime Infrastructure konfiguriert werden.
• DMVPN/PfR – PfR-Richtlinien werden auf dem zentralen Router, dem Master Controller (MC), über die CLI erstellt und anschließend automatisch an die Filial-MCs verteilt. Dabei werden dieselben Pfade zur Übertragung von Richtlinien genutzt wie für den Data Plane. Es gibt keine Möglichkeit, den Austausch von Richtlinien, Routing-Informationen und Benutzerdaten getrennt zu handhaben. Die Verbreitung von Richtlinien setzt zwingend IP-Konnektivität zwischen Hub und Spoke voraus. Dabei kann die Funktion des MC, falls erforderlich, mit dem DMVPN-Router kombiniert werden. Die Verwendung von Vorlagen in der Prime Infrastructure zur zentralen Erstellung von Richtlinien ist möglich (aber nicht erforderlich). Eine wichtige Besonderheit ist, dass die Richtlinie global im gesamten Netzwerk einheitlich erstellt wird – individuelle Richtlinien für einzelne Segmente werden nicht unterstützt..
• SD-WAN – Verkehrsmanagement- und QoS-Richtlinien werden zentral über die grafische Benutzeroberfläche von Cisco vManage definiert, die auch über das Internet zugänglich ist (falls erforderlich). Sie werden über Signalkanäle direkt oder indirekt über vSmart-Controller verteilt (abhängig von der Art der Richtlinie). Sie hängen nicht von der Data Plane-Konnektivität zwischen Routern ab, da sie alle verfügbaren Wege zur Übertragung von Daten zwischen Controller und Router nutzen.

  Für verschiedene Netzwerksegmente ist es möglich, unterschiedliche Richtlinien flexibel zu gestalten – der Anwendungsbereich der Richtlinie wird durch viele einzigartige Identifikatoren in der Lösung bestimmt – Filialnummer, Typ der Anwendung, Richtung des Datenverkehrs usw.

Orchestration Plane – Mechanismen, die es den Komponenten ermöglichen, sich dynamisch gegenseitig zu entdecken, zu konfigurieren und die anschließende Interaktion zu koordinieren.

• in DMVPN/PfR Die gegenseitige Entdeckung der Router basiert auf der statischen Konfiguration der Hub-Geräte und der entsprechenden Konfiguration der Spoke-Geräte. Die dynamische Entdeckung erfolgt nur für Spokes, die ihre Verbindungsparameter an das Hub-Gerät melden, welches zuvor in die Konfiguration des Spoke aufgenommen wurde. Ohne IP-Konnektivität zu mindestens einem Hub können weder der Data Plane noch der Control Plane gebildet werden.
• in SD-WAN Die Orchestrierung der Komponenten der Lösung erfolgt unter Verwendung des vBond-Controllers, mit dem jeder Komponente (Routern und den vManage/vSmart-Controllern) eine IP-Konnektivität herzustellen ist.

  Anfangs kennen die Komponenten die Parameter ihrer gegenseitigen Verbindungen nicht – dafür benötigen sie den Vermittler, den Orchestrator vBond. Das allgemeine Prinzip ist folgendes – jede Komponente erfährt in der Anfangsphase (automatisch oder statisch) nur die Verbindungsparameter zu vBond, danach informiert vBond den Router über die zuvor entdeckten vManage- und vSmart-Controller, was die automatische Herstellung aller notwendigen Signalverbindungen möglich macht.

  Der nächste Schritt ist, dass der neue Router über OMP-Austausch mit dem vSmart-Controller Informationen über die anderen Router im Netzwerk erhält. Auf diese Weise kann ein Router, der zu Beginn nichts über die Netzwerkparameter weiß, vollständig automatisch die Controller entdecken und sich mit ihnen verbinden sowie automatisch auch die Verbindung zu den anderen Routern herstellen. Dabei sind die Verbindungsparameter aller Komponenten zu Beginn unbekannt und können sich im Verlauf des Betriebs ändern.

Management Plane – Teil der Lösung, die zentralisiertes Management und Monitoring bereitstellt.

• DMVPN/PfR – Eine spezialisierte Management Plane-Lösung ist nicht vorgesehen. Für grundlegende Automatisierung und Monitoring kann die Verwendung von Produkten wie Cisco Prime Infrastructure in Betracht gezogen werden. Jeder Router kann über die CLI gesteuert werden. Eine Integration mit externen Systemen über API ist nicht vorgesehen.
• SD-WAN – alle regulären Interaktionen und Überwachungen erfolgen zentral über die grafische Benutzeroberfläche des Controllers vManage. Alle Funktionen der Lösung sind ohne Ausnahme über vManage konfigurierbar, ebenso über die vollständig dokumentierte REST API-Bibliothek.

  Alle Einstellungen des SD-WAN-Netzwerks in vManage beruhen auf zwei Hauptkonzepten – der Erstellung von Gerätetemplates (Device Template) und der Erstellung von Richtlinien, die die Logik des Netzwerks und die Verarbeitung des Verkehrs festlegen. Dabei wählt vManage, indem es die vom Administrator erstellte Richtlinie überträgt, automatisch die Änderungen und welche individuellen Geräte/Controller vorzunehmen sind, was die Effizienz und Skalierbarkeit der Lösung erheblich steigert.

  Über die vManage-Oberfläche ist nicht nur die Konfiguration der Cisco SD-WAN-Lösung möglich, sondern auch eine umfassende Überwachung des Status aller Komponenten der Lösung, bis hin zu den aktuellen Statusmetriken einzelner Tunnel und der Nutzung verschiedener Anwendungen auf Basis der DPI-Analyse.

  Trotz der Zentralisierung der Interaktion verfügen alle Komponenten (Controller und Router) auch über eine voll funktionsfähige CLI, die während der Implementierungsphase oder im Falle einer Notfallsituation für lokale Diagnosen erforderlich ist. Im regulären Betrieb (bei bestehender Signalleitung zwischen den Komponenten) ist die Befehlszeile auf den Routern nur für Diagnosen zugänglich und nicht für lokale Änderungen, was sowohl lokale Sicherheit als auch die einzige Quelle für Änderungen in einem solchen Netzwerk – vManage – gewährleistet.

Integrierte Sicherheit – hier geht es nicht nur um den Schutz von Benutzerdaten bei der Übertragung über öffentliche Kanäle, sondern auch um die allgemeine Sicherheit des WAN-Netzwerks, das auf der gewählten Technologie basiert.

• in DMVPN/PfR Es besteht die Möglichkeit, Benutzerdaten und Signalisierungsprotokolle zu verschlüsseln. Bei Verwendung bestimmter Router-Modelle sind zusätzlich Funktionen zur Firewall-Überprüfung des Verkehrs, IPS/IDS verfügbar. Es besteht die Möglichkeit, Zweignetzwerke mithilfe von VRF zu segmentieren. Es gibt die Möglichkeit zur Authentifizierung (einzelne Faktor) der Kontrollprotokolle.

  Dabei wird der entfernte Router standardmäßig als vertrauenswürdiges Element des Netzwerks betrachtet – d.h. physische Kompromittierungen einzelner Geräte und unbefugte Zugriffe werden nicht angenommen oder berücksichtigt, es gibt keine Zwei-Faktor-Authentifizierung für die Komponenten der Lösung, was in einem geografisch verteilten Netzwerk ernsthafte zusätzliche Risiken mit sich bringen kann.

• in SD-WAN Analog zu DMVPN besteht die Möglichkeit, Benutzerdaten zu verschlüsseln, jedoch mit deutlich erweiterten Funktionen für die Netzwerksicherheit und L3/VRF-Segmentierung (MSS, IPS/IDS, URL-Filterung, DNS-Filterung, AMP/TG, SASE, TLS/SSL-Proxy usw.). Der Austausch von Verschlüsselungsschlüsseln erfolgt dabei effizienter über vSmart-Controller (und nicht direkt), über im Voraus festgelegte Signalleitungen, die durch DTLS/TLS-Verschlüsselung basierend auf Sicherheitszertifikaten geschützt sind. Dies garantiert die Sicherheit eines solchen Austauschs und sorgt für eine bessere Skalierbarkeit der Lösung, auch für Tausende von Geräten in einem Netzwerk.

  Alle Signalanbindungen (Controller-Controller, Controller-Router) sind ebenfalls auf Grundlage von DTLS/TLS geschützt. Router werden bei der Herstellung mit Sicherheitszertifikaten ausgestattet, die ausgetauscht/verlängert werden können. Die Zwei-Faktor-Authentifizierung wird erreicht, indem gleichzeitig zwei Bedingungen für die Funktionsfähigkeit des Routers/Controllers im SD-WAN-Netzwerk erfüllt sein müssen:

  • Gültiges Sicherheitszertifikat
  • Das ausdrückliche und bewusste Hinzufügen jedes Komponenten durch den Administrator zur „Whitelist“ der erlaubten Geräte.

Funktionale Unterschiede zwischen SD-WAN und DMVPN/PfR

Wenn wir zu den funktionalen Unterschieden übergehen, ist zu beachten, dass viele von ihnen eine Fortsetzung der architektonischen Unterschiede darstellen – es ist kein Geheimnis, dass die Entwickler bei der Erstellung der Architektur der Lösung von den Möglichkeiten ausgehen, die sie schließlich erhalten möchten. Lassen Sie uns die signifikantesten Unterschiede der beiden Technologien betrachten.

AppQ (Application Quality) – Funktionen zur Sicherstellung der Datenübertragungsqualität von Geschäftsanwendungen.

Die Schlüsselmerkmale der betrachteten Technologien zielen darauf ab, das Benutzererlebnis bei der Nutzung geschäftskritischer Anwendungen in einem verteilten Netzwerk so weit wie möglich zu verbessern. Dies ist besonders wichtig, wenn ein Teil der Infrastruktur nicht von der IT kontrolliert wird oder nicht einmal eine erfolgreiche Datenübertragung garantiert.

DMVPN bietet nicht selbst solche Mechanismen an. Das Beste, was in einem klassischen DMVPN-Netzwerk möglich ist, besteht darin, den ausgehenden Datenverkehr nach Anwendungen zu klassifizieren und ihn beim Übertragen in Richtung WAN-Kanal zu priorisieren. Die Wahl des DMVPN-Tunnels hängt in diesem Fall nur von seiner Verfügbarkeit und dem Ergebnis der Routing-Protokolle ab. Dabei wird der Zustand des Pfads/Tunnels und seine mögliche teilweise Degradation in Bezug auf die wichtigen Kennzahlen, die für Netzwerk-Anwendungen bedeutend sind – wie Latenz, Latenzvariation (Jitter) und Verluste (%) – nicht berücksichtigt. In diesem Zusammenhang macht es keinen Sinn, klassisches DMVPN mit SD-WAN hinsichtlich der Lösung von AppQ-Problemen zu vergleichen – DMVPN kann dieses Problem nicht lösen. Mit der Einführung der Technologie Cisco Performance Routing (PfR) ändert sich die Situation, und der Vergleich mit Cisco SD-WAN wird sinnvoller.

Bevor wir auf die Unterschiede eingehen, ein kurzer Überblick über die Ähnlichkeiten der Technologien. Beide Technologien:

• verfügen über einen Mechanismus, der es ermöglicht, den Zustand jedes etablierten Tunnels dynamisch anhand bestimmter Kennzahlen zu bewerten – mindestens Latenz, Latenzvariation und Paketverluste (%)
• verwenden eine bestimmte Reihe von Werkzeugen zur Erstellung, Verbreitung und Anwendung von Regeln (Politiken) zur Verkehrssteuerung unter Berücksichtigung der Ergebnisse der Messung des Zustands der wichtigen Kennzahlen der Tunnel.
• kategorisieren den Anwendungsverkehr auf den Ebenen L3-L4 (DSCP) des OSI-Modells oder nach L7-Signaturen der Anwendungen basierend auf den im Router integrierten DPI-Mechanismen
• ermöglichen es für relevante Anwendungen, akzeptable Schwellenwerte für Kennzahlen festzulegen, Standardregeln für den Datenverkehr zu definieren und Regeln für die Neurouting von Datenverkehr bei Überschreitung der Schwellenwerte zu erstellen.
• bei der Kapselung des Verkehrs in GRE/IPSec wird ein branchenüblicher Mechanismus zur Übertragung der internen DSCP-Kennzeichnung in den externen GRE/IPSec-Paketkopf verwendet, was die Synchronisation der QoS-Politiken von Unternehmen und Dienstanbietern ermöglicht (bei Vorliegen eines entsprechenden SLA).

Wie unterscheiden sich die Mechanismen zur Bewertung der End-to-End-Kennzahlen von SD-WAN und DMVPN/PfR?

DMVPN/PfR

• Zur Bewertung der Standardkenngrößen des Tunnelzustands werden sowohl aktive als auch passive Software-Sensoren (Probes) eingesetzt. Aktive Sensoren basieren auf Benutzerdatenverkehr, passive simulieren diesen Verkehr (bei Abwesenheit desselben).
• Eine Feinabstimmung der Timer und Bedingungen zur Erkennung von Degradierungen fehlt – der Algorithmus ist fix.
• Zusätzlich ist die Messung der genutzten Bandbreite in der Ausrichtung verfügbar. Dies verleiht DMVPN/PfR zusätzliche Flexibilität bei der Verkehrssteuerung.
• Dabei verlassen sich einige PfR-Mechanismen bei Überschreitung der Kennzahlen auf Rückmeldungen in Form von speziellen TCA (Threshold Crossing Alert)-Nachrichten, die vom Empfänger des Datenverkehrs in Richtung des Ursprungs gesendet werden müssen, was voraussetzt, dass der Zustand der gemessenen Kanäle zumindest ausreichend ist, um diese TCA-Nachrichten zu übermitteln. Dies ist in den meisten Fällen kein Problem, aber offensichtlich nicht garantiert.

SD-WAN

• Für die End-to-End-Bewertung der standardisierten Kennzahlen des Tunnelzustands wird das BFD-Protokoll im Echo-Modus verwendet. Dabei ist keine spezielle Rückmeldung in Form von TCA oder ähnlichen Nachrichten erforderlich – die Isolation der Ausfall-Domänen bleibt gewahrt. Auch ist kein Benutzerdatenverkehr erforderlich, um den Zustand des Tunnels zu bewerten.
• Es besteht die Möglichkeit, die BFD-Timer feinzustellen, um die Reaktionsgeschwindigkeit und die Sensitivität des Algorithmus gegenüber Degradierungen des Kommunikationskanals von wenigen Sekunden bis zu Minuten zu regulieren.

  

• Zum Zeitpunkt der Erstellung des Artikels ist in jedem Tunnel nur eine BFD-Session vorgesehen. Dies könnte eine geringere Granularität bei der Analyse des Tunnelzustands schaffen. In der Tat könnte dies nur ein Problem darstellen, wenn eine WAN-Verbindung auf Basis von MPLS L2/L3 VPN mit einem vereinbarten QoS SLA verwendet wird – wenn die DSCP-Kennzeichnung des BFD-Datenverkehrs (nach der Kapselung in IPSec/GRE) mit der hochpriorisierten Warteschlange im Netzwerk des Dienstanbieters übereinstimmt, könnte dies die Genauigkeit und Geschwindigkeit der Erkennung von Degradierungen für niederpriorisierten Datenverkehr beeinträchtigen. In diesem Zusammenhang besteht die Möglichkeit, die standardmäßige Kennzeichnung von BFD zu ändern, um das Risiko solcher Situationen zu verringern. In zukünftigen Versionen der Cisco SD-WAN-Software wird eine detailliertere Anpassung von BFD sowie die Möglichkeit erwartet, mehrere BFD-Sitzungen innerhalb eines Tunnels mit individuellen DSCP-Werten (für verschiedene Anwendungen) zu starten.
• BFD ermöglicht zudem die Bewertung der maximalen Paketgröße, die über einen bestimmten Tunnel ohne Fragmentierung übertragen werden kann. Dadurch kann SD-WAN dynamisch Parameter wie MTU und TCP MSS Anpassen, um die verfügbare Bandbreite an jedem Kanal optimal zu nutzen.
• In SD-WAN steht auch die Option zur Synchronisierung von QoS mit Telekommunikationsanbietern nicht nur auf Basis des L3 DSCP-Feldes, sondern auch auf Basis der L2 CoS-Werte zur Verfügung, die von speziellen Geräten in der Zweigstelle automatisch erstellt werden können – beispielsweise IP-Telefonen.

Wie unterscheiden sich die Möglichkeiten, die Bestimmung und Anwendung von AppQ-Richtlinien?

DMVPN/PfR-Richtlinien:

• Werden an den Routern(-n) der zentralen Niederlassung (ZF) über die CLI-Befehlszeile oder CLI-Vorlagen konfiguriert. Die Erstellung von CLI-Vorlagen erfordert Vorbereitung und Kenntnisse über die Syntax der Richtlinien.

  

• Werden global definiert ohne die Möglichkeit, Anpassungen für die Anforderungen einzelner Netzwerksegmente vorzunehmen.
• Interaktive Richtlinienerstellung im grafischen Interface ist nicht vorgesehen.
• Die Nachverfolgung von Änderungen, Vererbung und die Erstellung mehrerer Versionen von Richtlinien für einen schnellen Wechsel sind nicht vorgesehen.
• Werden automatisch auf die Router der entfernten Niederlassungen verteilt. Dabei werden dieselben Kommunikationskanäle verwendet, die auch für die Übertragung von Benutzerdaten genutzt werden. Bei fehlender Verbindung zwischen der zentralen und der entfernten Niederlassung ist die Verteilung/Änderung von Richtlinien nicht möglich.
• Werden auf jedem Router angewendet und modifizieren bei Bedarf das Ergebnis der Standard-Routing-Protokolle mit höherer Priorität.
• Für Fälle, in denen alle WAN-Kanäle der Niederlassung erhebliche Datenverluste erleben, sind keine Kompensationsmechanismen vorgesehen..

SD-WAN-Richtlinien:

• Werden im grafischen Interface vManage über einen interaktiven Vorlagenassistenten definiert.
• Unterstützen die Erstellung mehrerer Richtlinien, das Kopieren, Vererben und den Wechsel zwischen Richtlinien in Echtzeit.
• Unterstützen die individuelle Anpassung von Richtlinien für verschiedene Segmente (Niederlassungen) des Netzwerks.
• Werden unter Verwendung jedes verfügbaren Signalkanals zwischen dem Controller und dem Router und/oder vSmart verteilt – sind nicht direkt von der Datenverbindungsfähigkeit zwischen den Routern abhängig. Dabei ist jedoch eine IP-Verbindung zwischen dem Router und den Controllern erforderlich.

  

• Für Fälle, in denen alle verfügbaren Kanäle der Niederlassung erhebliche Datenverluste über die zulässigen Schwellenwerte für kritische Anwendungen hinaus erleiden, können zusätzliche Mechanismen eingesetzt werden, um die Zuverlässigkeit der Übertragung zu erhöhen:
  • FEC (Forward Error Correction) – verwendet einen speziellen Algorithmus zur Redundanzkodierung. Während der Übertragung kritischer Daten über Kanäle mit erheblichem Verlustanteil kann FEC automatisch aktiviert werden, um verloren gegangene Daten wiederherzustellen. Dabei erhöht sich die genutzte Bandbreite geringfügig, jedoch wird die Zuverlässigkeit erheblich gesteigert.

    

  • Datenstrom-Duplikation – zusätzlich zu FEC kann die Richtlinie eine automatische Duplikation des Datenverkehrs ausgewählter Anwendungen im Falle noch schwerwiegenderer Verluste vorsehen, die nicht mit FEC kompensiert werden können. In diesem Fall werden die ausgewählten Daten über alle Tunnel zur empfangenden Niederlassung mit anschließender De-Duplizierung (Entfernung überflüssiger Paketkopien) übertragen. Dieses Verfahren erhöht die Auslastung der Kanäle erheblich, steigert jedoch auch die Zuverlässigkeit der Übertragung.

Funktionen von Cisco SD-WAN, ohne direkte Entsprechung in DMVPN/PfR

Die Architektur der Cisco SD-WAN-Lösung ermöglicht in einigen Fällen Funktionen, deren Umsetzung im Rahmen von DMVPN/PfR entweder extrem aufwendig, nicht sinnvoll oder völlig unmöglich ist. Betrachten wir die interessantesten davon:

Traffic-Engineering (TE)

TE umfasst Mechanismen, die es ermöglichen, den Verkehr vom Standardweg, der durch Routing-Protokolle gebildet wird, abzuleiten. TE wird häufig verwendet, um eine hohe Verfügbarkeit von Netzwerkdiensten sicherzustellen, indem die Fähigkeit genutzt wird, wichtigen Datenverkehr schnell und/oder im Voraus auf einen alternativen (nicht kreuzenden) Übertragungsweg umzuleiten, um eine bessere Servicequalität oder eine schnellere Wiederherstellung im Falle eines Ausfalls des Hauptwegs zu gewährleisten.

Die Umsetzung von TE erfordert die vorherige Berechnung und Reservierung (Überprüfung) eines alternativen Pfades. In MPLS-Netzen der Telekommunikationsanbieter wird diese Aufgabe durch Technologien wie MPLS Traffic Engineering mit Erweiterungen der IGP-Protokolle und des RSVP-Protokolls gelöst. Zudem gewinnt die Technologie des Segment-Routings in letzter Zeit zunehmend an Beliebtheit, da sie besser für die zentrale Konfiguration und Orchestrierung optimiert ist. In klassischen WAN-Netzen sind diese Technologien in der Regel nicht vertreten oder beschränken sich auf die Nutzung von hop-by-hop Mechanismen wie Policy-Based Routing (PBR), die den Datenverkehr umleiten können, jedoch dies an jedem Router einzeln durchführen – ohne das Gesamtzustand des Netzwerks oder das Ergebnis von PBR in vorherigen oder nachfolgenden Schritten zu berücksichtigen. Das Ergebnis dieser TE-Varianten ist enttäuschend – MPLS TE wird aufgrund der Komplexität der Konfiguration und des Betriebs in der Regel nur im kritischsten Teil des Netzwerks (Kern) eingesetzt, während PBR auf einzelnen Routern verwendet wird, ohne eine einheitliche PBR-Politik für das gesamte Netzwerk zu bilden. Dies gilt offensichtlich auch für DMVPN-basierte Netzwerke.

SD-WAN bietet in diesem Kontext eine viel elegantere Lösung, die nicht nur einfach einzurichten ist, sondern auch erheblich besser skalierbar. Dies ist das Ergebnis der verwendeten Architekturen des Control- und Policy-Planes. Die Implementierung des Policy-Plans in SD-WAN ermöglicht es, die TE-Politik zentral festzulegen – welcher Datenverkehr ist von Interesse? Für welche VPNs? Über welche Knoten/Tunnel sollte ein alternativer Weg erzeugt werden, oder ist das sogar verboten? Die Zentralisierung der Control-Plane-Verwaltung auf Basis der vSmart-Controller ermöglicht es, die Routing-Ergebnisse zu modifizieren, ohne Anpassungen an einzelnen Geräten vorzunehmen – die Router sehen lediglich das Ergebnis der Logik, die im vManage-Interface formuliert und für die Anwendung an vSmart übermittelt wurde.

Service-chaining

Die Bildung von Service-Chains ist in der klassischen Routing-Technologie noch arbeitsintensiver als der bereits beschriebene Traffic-Engineering-Mechanismus. Denn hierbei muss nicht nur eine spezielle Route für eine bestimmte Netzwerk-Anwendung definiert werden, sondern auch die Möglichkeit geschaffen werden, den Datenverkehr aus dem Netzwerk an bestimmten (oder an allen) Knoten des SD-WAN-Netzwerks zur Bearbeitung durch eine spezielle Anwendung oder Dienst (z.B. MSE, Lastverteilung, Caching, Paketinspektion usw.) zu leiten. Dabei ist es notwendig, den Zustand dieser externen Dienste zu überwachen, um Situationen des Black-Holing zu vermeiden. Außerdem werden Mechanismen benötigt, die es ermöglichen, solche ähnlichen externen Dienstleistungen an verschiedenen geografischen Standorten unterzubringen, sodass das Netzwerk automatisch den optimalsten Service-Knoten für die Bearbeitung des Datenverkehrs eines bestimmten Standorts auswählen kann. Im Fall von Cisco SD-WAN lässt sich dies relativ einfach erreichen, indem eine entsprechende zentralisierte Politik erstellt wird, die alle Aspekte der Ziel-Service-Chain zu einem Ganzen zusammenfügt und die Logik des Data-Planes und des Control-Planes nur dort und dann ändert, wo es notwendig ist.

Die Fähigkeit, eine geografisch verteilte Bearbeitung von ausgewählten Anwendungstypen in einer bestimmten Reihenfolge auf spezialisierter (aber nicht zur SD-WAN netzwerkgehörigen) Hardware durchzuführen, ist wohl der deutlichste Beweis für die Vorteile von Cisco SD-WAN gegenüber klassischen Technologien und sogar einigen alternativen SD-WAN-Lösungen anderer Anbieter.

Was ist das Ergebnis?

Offensichtlich lösen sowohl DMVPN (gemeinsam oder unabhängig von Performance Routing) als auch Cisco SD-WAN letztlich sehr ähnliche Aufgaben im Verhältnis zum verteilten WAN-Netzwerk einer Organisation. Dabei führen die wesentlichen architektonischen und funktionalen Unterschiede der Cisco SD-WAN-Technologie zu einem höheren qualitativen Niveau. Zusammenfassend lassen sich folgende signifikante Unterschiede zwischen den Technologien SD-WAN und DMVPN/PfR feststellen:

• DMVPN/PfR nutzt insgesamt bewährte Technologien zum Aufbau von Overlay-VPN-Netzen und ist im Bereich des Data-Plans mit der moderneren SD-WAN-Technologie vergleichbar, weist jedoch Einschränkungen in Form einer notwendigen statischen Konfiguration der Router auf, und die Auswahl der Topologien ist auf Hub-n-Spoke beschränkt. Andererseits verfügt DMVPN/PfR über einige funktionale Möglichkeiten, die derzeit im Rahmen von SD-WAN noch nicht verfügbar sind (gezielt auf per-application BFD).
• Die control-plane Technologien unterscheiden sich grundlegend. Mit der zentralisierten Verarbeitung von Signalisierungsprotokollen ermöglicht SD-WAN insbesondere, die Ausfallzonen erheblich zu verkleinern und den Prozess der Übertragung des Benutzerdatenverkehrs von der signalisierenden Interaktion zu entkoppeln – die vorübergehende Nichterreichbarkeit von Controllern beeinflusst nicht die Möglichkeit, Benutzerdatenverkehr zu übertragen. Gleichzeitig hat die vorübergehende Nichterreichbarkeit eines Standorts (einschließlich des zentralen) keinerlei Einfluss auf die Möglichkeit der anderen Standorte, miteinander und mit den Controllern zu kommunizieren.
• Die Architektur der Erstellung und Anwendung von Traffic-Management-Richtlinien bei SD-WAN übertrifft auch die in DMVPN/PfR – geo-redundante Lösungen sind deutlich besser umgesetzt, es gibt keine Bindung an einen Hub, bessere Möglichkeiten zur Feinabstimmung der Politiken und eine größere Liste umsetzbarer Szenarien für das Traffic-Management.
• Der Orchestrierungsprozess der Lösung unterscheidet sich ebenfalls erheblich. DMVPN setzt voraus, dass bereits bekannte Parameter in der Konfiguration reflektiert werden müssen, was die Flexibilität der Lösung und die Möglichkeit dynamischer Änderungen etwas einschränkt. Im Gegensatz dazu geht SD-WAN von dem Paradigma aus, dass der Router zu Beginn der Verbindung "nichts weiß" über seine Controller, aber "weiß, bei wem man nachfragen kann" – das ist ausreichend, um nicht nur die Verbindung zu den Controllern automatisch herzustellen, sondern auch eine vollständig verbundene Data-Plane-Topologie automatisch zu bilden, die dann flexibel mit Politiken angepasst/änderte werden kann.
• Im Bereich des zentralisierten Managements, der Automatisierung und der Überwachung übertrifft SD-WAN erwartungsgemäß die Möglichkeiten von DMVPN/PfR, die das Ergebnis der Entwicklung klassischer Technologien sind und größtenteils auf die Befehlszeile CLI und die Verwendung von NMS-Systemen auf der Grundlage von Vorlagen angewiesen sind.
• Die Sicherheitsanforderungen für SD-WAN im Vergleich zu DMVPN haben ein neues Qualitätsniveau erreicht. Die Hauptprinzipien sind Nullvertrauen, Skalierbarkeit und Zwei-Faktor-Authentifizierung.

Aus diesen einfachen Schlussfolgerungen könnte der falsche Eindruck entstehen, dass das Erstellen eines Netzwerks auf der Basis von DMVPN/PfR heute jegliche Relevanz verloren hat. Das ist natürlich nicht ganz richtig. Beispielsweise in Fällen, wo im Netzwerk viele veraltete Geräte verwendet werden und es keine Möglichkeit gibt, diese zu ersetzen, kann DMVPN es ermöglichen, "alte" und "neue" Geräte in ein einheitliches geo-verteiltes Netzwerk zu integrieren, mit vielen der oben beschriebenen Vorteile.

Andererseits sollte man bedenken, dass alle aktuellen Unternehmensrouter von Cisco auf Basis von IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) heute jeden Betriebsmodus unterstützen – sowohl klassische Routing- als auch DMVPN- und SD-WAN-Modi. Die Wahl richtet sich nach den aktuellen Bedürfnissen und dem Verständnis, dass jederzeit auf derselben Hardware auf eine fortschrittlichere Technologie umgeschaltet werden kann.

Quelle: habr.com