Funktionale M\u00f6glichkeiten \u2013 was kann eine Technologie, was die andere nicht kann? Ist das wirklich so wichtig?<\/li>\n<\/ul>\n<\/p>\n
Wo liegen die architektonischen Unterschiede und sind sie wirklich wichtig?<\/h3>\n \nJede der genannten Technologien hat viele \u00abbewegliche Teile\u00bb, bei denen nicht nur die Rolle, sondern auch die Interaktionsprinzipien voneinander abweichen. Die \u00dcberlegungen, wie gut diese Prinzipien durchdacht sind, beeinflussen direkt die Skalierbarkeit, Ausfalltoleranz und die Gesamteffizienz der L\u00f6sung. <\/p>\n
Betrachten wir verschiedene Aspekte der Architektur n\u00e4her:<\/p>\n
Datenebene<\/b> \u2013 der Teil der L\u00f6sung, der f\u00fcr die \u00dcbertragung des Benutzerdatenverkehrs zwischen Sender und Empf\u00e4nger 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:<\/p>\n\nin DMVPN\/PfR<\/b> \u2013 es handelt sich um eine ausschlie\u00dflich 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 \u00fcber das NHRP-Protokoll zur Bildung der Daten\u00fcbertragungs-Pfadverbindung. In der Folge sind \u00c4nderungen am Hub erheblich erschwert<\/b>, beispielsweise durch die \u00c4nderung\/Anbindung neuer WAN-Verbindungen oder die Anpassung bestehender Parameter.<\/li>\nin SD-WAN<\/b> \u2013 es handelt sich um ein vollst\u00e4ndig 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\u00f6nnen beliebige, einschlie\u00dflich hierarchische, Topologien verwendet werden. Innerhalb der festgelegten Overlay-Topologie der Tunnel ist eine flexible Anpassung der logischen Topologie in jedem einzelnen VPN (VRF) m\u00f6glich.<\/li>\n<\/ul>\n Steuerungsebene<\/b> \u2013 Funktionen f\u00fcr den Austausch, die Filterung und die Modifikation von Routing- und anderen Informationen zwischen den Komponenten der L\u00f6sung. <\/p>\n\nin DMVPN\/PfR<\/b> \u2013 erfolgt nur zwischen den Routern Hub und Spoke. Ein direkter Austausch von Routing-Informationen zwischen Spoke ist nicht m\u00f6glich. In der Folge ist ohne einen aktiven Hub die Funktionsf\u00e4higkeit der Steuerungsebene und der Datenebene nicht m\u00f6glich<\/b>, was zus\u00e4tzliche Anforderungen an die Hochverf\u00fcgbarkeit des Hubs stellt, die nicht immer erf\u00fcllt werden k\u00f6nnen.<\/li>\nin SD-WAN<\/b> \u2013 Control Plane wird niemals direkt zwischen den Routern durchgef\u00fchrt \u2013 die Interaktion erfolgt auf Basis des OMP-Protokolls und muss zwingend \u00fcber einen speziellen Typ von Controller, den vSmart-Controller, realisiert werden. Dies erm\u00f6glicht Lastverteilung, Geo-Redundanz und zentrale Steuerung der Signallast. Eine weitere Besonderheit des OMP-Protokolls ist seine erhebliche Robustheit gegen\u00fcber Paketverlusten und seine Unabh\u00e4ngigkeit von der Geschwindigkeit der Verbindung zu den Controllern (innerhalb vern\u00fcnftiger Grenzen). Dies erm\u00f6glicht es, SD-WAN-Controller sowohl in \u00f6ffentlichen als auch in privaten Clouds mit Internetzugang zu hosten.<\/li>\n<\/ul>\n Policy Plane<\/b> \u2013 Teil der L\u00f6sung, der f\u00fcr die Definition, Verteilung und Anwendung von Verkehrsmanagementrichtlinien in einem verteilten Netzwerk verantwortlich ist.<\/p>\n\nDMVPN <\/b>\u2013 ist faktisch auf Qualit\u00e4tssicherungsrichtlinien (QoS) beschr\u00e4nkt, die individuell auf jedem Router \u00fcber die CLI oder Vorlagen in der Prime Infrastructure konfiguriert werden.<\/li>\nDMVPN\/PfR<\/b> \u2013 PfR-Richtlinien werden auf dem zentralen Router, dem Master Controller (MC), \u00fcber die CLI erstellt und anschlie\u00dfend automatisch an die Filial-MCs verteilt. Dabei werden dieselben Pfade zur \u00dcbertragung von Richtlinien genutzt wie f\u00fcr den Data Plane. Es gibt keine M\u00f6glichkeit, den Austausch von Richtlinien, Routing-Informationen und Benutzerdaten getrennt zu handhaben. Die Verbreitung von Richtlinien setzt zwingend IP-Konnektivit\u00e4t 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\u00f6glich (aber nicht erforderlich). Eine wichtige Besonderheit ist, dass die Richtlinie global im gesamten Netzwerk einheitlich erstellt wird \u2013 individuelle Richtlinien f\u00fcr einzelne Segmente werden nicht unterst\u00fctzt.<\/b>.<\/li>\nSD-WAN<\/b> \u2013 Verkehrsmanagement- und QoS-Richtlinien werden zentral \u00fcber die grafische Benutzeroberfl\u00e4che von Cisco vManage definiert, die auch \u00fcber das Internet zug\u00e4nglich ist (falls erforderlich). Sie werden \u00fcber Signalkan\u00e4le direkt oder indirekt \u00fcber vSmart-Controller verteilt (abh\u00e4ngig von der Art der Richtlinie). Sie h\u00e4ngen nicht von der Data Plane-Konnektivit\u00e4t zwischen Routern ab, da sie alle verf\u00fcgbaren Wege zur \u00dcbertragung von Daten zwischen Controller und Router nutzen.\n F\u00fcr verschiedene Netzwerksegmente ist es m\u00f6glich, unterschiedliche Richtlinien flexibel zu gestalten \u2013 der Anwendungsbereich der Richtlinie wird durch viele einzigartige Identifikatoren in der L\u00f6sung bestimmt \u2013 Filialnummer, Typ der Anwendung, Richtung des Datenverkehrs usw.\n<\/li>\n<\/ul>\n
Orchestration Plane<\/b> \u2013 Mechanismen, die es den Komponenten erm\u00f6glichen, sich dynamisch gegenseitig zu entdecken, zu konfigurieren und die anschlie\u00dfende Interaktion zu koordinieren.<\/p>\n\nin DMVPN\/PfR<\/b> Die gegenseitige Entdeckung der Router basiert auf der statischen Konfiguration der Hub-Ger\u00e4te und der entsprechenden Konfiguration der Spoke-Ger\u00e4te. Die dynamische Entdeckung erfolgt nur f\u00fcr Spokes, die ihre Verbindungsparameter an das Hub-Ger\u00e4t melden, welches zuvor in die Konfiguration des Spoke aufgenommen wurde. Ohne IP-Konnektivit\u00e4t zu mindestens einem Hub k\u00f6nnen weder der Data Plane noch der Control Plane gebildet werden.<\/b><\/li>\nin SD-WAN<\/b> Die Orchestrierung der Komponenten der L\u00f6sung erfolgt unter Verwendung des vBond-Controllers, mit dem jeder Komponente (Routern und den vManage\/vSmart-Controllern) eine IP-Konnektivit\u00e4t herzustellen ist.\n Anfangs kennen die Komponenten die Parameter ihrer gegenseitigen Verbindungen nicht \u2013 daf\u00fcr ben\u00f6tigen sie den Vermittler, den Orchestrator vBond. Das allgemeine Prinzip ist folgendes \u2013 jede Komponente erf\u00e4hrt in der Anfangsphase (automatisch oder statisch) nur die Verbindungsparameter zu vBond, danach informiert vBond den Router \u00fcber die zuvor entdeckten vManage- und vSmart-Controller, was die automatische Herstellung aller notwendigen Signalverbindungen m\u00f6glich macht. <\/p>\n
Der n\u00e4chste Schritt ist, dass der neue Router \u00fcber OMP-Austausch mit dem vSmart-Controller Informationen \u00fcber die anderen Router im Netzwerk erh\u00e4lt. Auf diese Weise kann ein Router, der zu Beginn nichts \u00fcber die Netzwerkparameter wei\u00df, vollst\u00e4ndig 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\u00f6nnen sich im Verlauf des Betriebs \u00e4ndern.\n<\/li>\n<\/ul>\n
Management Plane<\/b> \u2013 Teil der L\u00f6sung, die zentralisiertes Management und Monitoring bereitstellt.<\/p>\n\nDMVPN\/PfR<\/b> \u2013 Eine spezialisierte Management Plane-L\u00f6sung ist nicht vorgesehen. F\u00fcr grundlegende Automatisierung und Monitoring kann die Verwendung von Produkten wie Cisco Prime Infrastructure in Betracht gezogen werden. Jeder Router kann \u00fcber die CLI gesteuert werden. Eine Integration mit externen Systemen \u00fcber API ist nicht vorgesehen.<\/b><\/li>\nSD-WAN<\/b> \u2013 alle regul\u00e4ren Interaktionen und \u00dcberwachungen erfolgen zentral \u00fcber die grafische Benutzeroberfl\u00e4che des Controllers vManage. Alle Funktionen der L\u00f6sung sind ohne Ausnahme \u00fcber vManage konfigurierbar, ebenso \u00fcber die vollst\u00e4ndig dokumentierte REST API-Bibliothek.\n Alle Einstellungen des SD-WAN-Netzwerks in vManage beruhen auf zwei Hauptkonzepten \u2013 der Erstellung von Ger\u00e4tetemplates (Device Template) und der Erstellung von Richtlinien, die die Logik des Netzwerks und die Verarbeitung des Verkehrs festlegen. Dabei w\u00e4hlt vManage, indem es die vom Administrator erstellte Richtlinie \u00fcbertr\u00e4gt, automatisch die \u00c4nderungen und welche individuellen Ger\u00e4te\/Controller vorzunehmen sind, was die Effizienz und Skalierbarkeit der L\u00f6sung erheblich steigert.<\/p>\n
\u00dcber die vManage-Oberfl\u00e4che ist nicht nur die Konfiguration der Cisco SD-WAN-L\u00f6sung m\u00f6glich, sondern auch eine umfassende \u00dcberwachung des Status aller Komponenten der L\u00f6sung, bis hin zu den aktuellen Statusmetriken einzelner Tunnel und der Nutzung verschiedener Anwendungen auf Basis der DPI-Analyse.<\/p>\n
Trotz der Zentralisierung der Interaktion verf\u00fcgen alle Komponenten (Controller und Router) auch \u00fcber eine voll funktionsf\u00e4hige CLI, die w\u00e4hrend der Implementierungsphase oder im Falle einer Notfallsituation f\u00fcr lokale Diagnosen erforderlich ist. Im regul\u00e4ren Betrieb (bei bestehender Signalleitung zwischen den Komponenten) ist die Befehlszeile auf den Routern nur f\u00fcr Diagnosen zug\u00e4nglich und nicht f\u00fcr lokale \u00c4nderungen, was sowohl lokale Sicherheit als auch die einzige Quelle f\u00fcr \u00c4nderungen in einem solchen Netzwerk \u2013 vManage \u2013 gew\u00e4hrleistet.<\/li>\n<\/ul>\n
\nIntegrierte Sicherheit<\/b> \u2013 hier geht es nicht nur um den Schutz von Benutzerdaten bei der \u00dcbertragung \u00fcber \u00f6ffentliche Kan\u00e4le, sondern auch um die allgemeine Sicherheit des WAN-Netzwerks, das auf der gew\u00e4hlten Technologie basiert.<\/p>\n\nin DMVPN\/PfR<\/b> Es besteht die M\u00f6glichkeit, Benutzerdaten und Signalisierungsprotokolle zu verschl\u00fcsseln. Bei Verwendung bestimmter Router-Modelle sind zus\u00e4tzlich Funktionen zur Firewall-\u00dcberpr\u00fcfung des Verkehrs, IPS\/IDS verf\u00fcgbar. Es besteht die M\u00f6glichkeit, Zweignetzwerke mithilfe von VRF zu segmentieren. Es gibt die M\u00f6glichkeit zur Authentifizierung (einzelne Faktor) der Kontrollprotokolle.\n Dabei wird der entfernte Router standardm\u00e4\u00dfig als vertrauensw\u00fcrdiges Element des Netzwerks betrachtet \u2013 d.h. physische Kompromittierungen einzelner Ger\u00e4te und unbefugte Zugriffe werden nicht angenommen oder ber\u00fccksichtigt, es gibt keine Zwei-Faktor-Authentifizierung f\u00fcr die Komponenten der L\u00f6sung, was in einem geografisch verteilten Netzwerk ernsthafte zus\u00e4tzliche Risiken mit sich bringen kann.<\/b> <\/li>\nin SD-WAN<\/b> Analog zu DMVPN besteht die M\u00f6glichkeit, Benutzerdaten zu verschl\u00fcsseln, jedoch mit deutlich erweiterten Funktionen f\u00fcr die Netzwerksicherheit und L3\/VRF-Segmentierung (MSS, IPS\/IDS, URL-Filterung, DNS-Filterung, AMP\/TG, SASE, TLS\/SSL-Proxy usw.). Der Austausch von Verschl\u00fcsselungsschl\u00fcsseln erfolgt dabei effizienter \u00fcber vSmart-Controller (und nicht direkt), \u00fcber im Voraus festgelegte Signalleitungen, die durch DTLS\/TLS-Verschl\u00fcsselung basierend auf Sicherheitszertifikaten gesch\u00fctzt sind. Dies garantiert die Sicherheit eines solchen Austauschs und sorgt f\u00fcr eine bessere Skalierbarkeit der L\u00f6sung, auch f\u00fcr Tausende von Ger\u00e4ten in einem Netzwerk.\n Alle Signalanbindungen (Controller-Controller, Controller-Router) sind ebenfalls auf Grundlage von DTLS\/TLS gesch\u00fctzt. Router werden bei der Herstellung mit Sicherheitszertifikaten ausgestattet, die ausgetauscht\/verl\u00e4ngert werden k\u00f6nnen. Die Zwei-Faktor-Authentifizierung wird erreicht, indem gleichzeitig zwei Bedingungen f\u00fcr die Funktionsf\u00e4higkeit des Routers\/Controllers im SD-WAN-Netzwerk erf\u00fcllt sein m\u00fcssen:<\/p>\n
\nG\u00fcltiges Sicherheitszertifikat<\/li>\n Das ausdr\u00fcckliche und bewusste Hinzuf\u00fcgen jedes Komponenten durch den Administrator zur \u201eWhitelist\u201c der erlaubten Ger\u00e4te.<\/li>\n<\/ul>\n\n<\/li>\n<\/ul>\n
Funktionale Unterschiede zwischen SD-WAN und DMVPN\/PfR<\/h2>\n \nWenn wir zu den funktionalen Unterschieden \u00fcbergehen, ist zu beachten, dass viele von ihnen eine Fortsetzung der architektonischen Unterschiede darstellen \u2013 es ist kein Geheimnis, dass die Entwickler bei der Erstellung der Architektur der L\u00f6sung von den M\u00f6glichkeiten ausgehen, die sie schlie\u00dflich erhalten m\u00f6chten. Lassen Sie uns die signifikantesten Unterschiede der beiden Technologien betrachten.<\/p>\n
AppQ (Application Quality) \u2013 Funktionen zur Sicherstellung der Daten\u00fcbertragungsqualit\u00e4t von Gesch\u00e4ftsanwendungen.<\/h3>\n \nDie Schl\u00fcsselmerkmale der betrachteten Technologien zielen darauf ab, das Benutzererlebnis bei der Nutzung gesch\u00e4ftskritischer Anwendungen in einem verteilten Netzwerk so weit wie m\u00f6glich zu verbessern. Dies ist besonders wichtig, wenn ein Teil der Infrastruktur nicht von der IT kontrolliert wird oder nicht einmal eine erfolgreiche Daten\u00fcbertragung garantiert.<\/p>\n
DMVPN bietet nicht selbst solche Mechanismen an. Das Beste, was in einem klassischen DMVPN-Netzwerk m\u00f6glich ist, besteht darin, den ausgehenden Datenverkehr nach Anwendungen zu klassifizieren und ihn beim \u00dcbertragen in Richtung WAN-Kanal zu priorisieren. Die Wahl des DMVPN-Tunnels h\u00e4ngt in diesem Fall nur von seiner Verf\u00fcgbarkeit und dem Ergebnis der Routing-Protokolle ab. Dabei wird der Zustand des Pfads\/Tunnels und seine m\u00f6gliche teilweise Degradation in Bezug auf die wichtigen Kennzahlen, die f\u00fcr Netzwerk-Anwendungen bedeutend sind \u2013 wie Latenz, Latenzvariation (Jitter) und Verluste (%) \u2013 nicht ber\u00fccksichtigt. In diesem Zusammenhang macht es keinen Sinn, klassisches DMVPN mit SD-WAN hinsichtlich der L\u00f6sung von AppQ-Problemen zu vergleichen \u2013 DMVPN kann dieses Problem nicht l\u00f6sen. Mit der Einf\u00fchrung der Technologie Cisco Performance Routing (PfR) \u00e4ndert sich die Situation, und der Vergleich mit Cisco SD-WAN wird sinnvoller. <\/p>\n
Bevor wir auf die Unterschiede eingehen, ein kurzer \u00dcberblick \u00fcber die \u00c4hnlichkeiten der Technologien. Beide Technologien:<\/p>\n
\nverf\u00fcgen \u00fcber einen Mechanismus, der es erm\u00f6glicht, den Zustand jedes etablierten Tunnels dynamisch anhand bestimmter Kennzahlen zu bewerten \u2013 mindestens Latenz, Latenzvariation und Paketverluste (%)<\/li>\n verwenden eine bestimmte Reihe von Werkzeugen zur Erstellung, Verbreitung und Anwendung von Regeln (Politiken) zur Verkehrssteuerung unter Ber\u00fccksichtigung der Ergebnisse der Messung des Zustands der wichtigen Kennzahlen der Tunnel.<\/li>\n 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<\/li>\n erm\u00f6glichen es f\u00fcr relevante Anwendungen, akzeptable Schwellenwerte f\u00fcr Kennzahlen festzulegen, Standardregeln f\u00fcr den Datenverkehr zu definieren und Regeln f\u00fcr die Neurouting von Datenverkehr bei \u00dcberschreitung der Schwellenwerte zu erstellen.<\/li>\n bei der Kapselung des Verkehrs in GRE\/IPSec wird ein branchen\u00fcblicher Mechanismus zur \u00dcbertragung der internen DSCP-Kennzeichnung in den externen GRE\/IPSec-Paketkopf verwendet, was die Synchronisation der QoS-Politiken von Unternehmen und Dienstanbietern erm\u00f6glicht (bei Vorliegen eines entsprechenden SLA).<\/li>\n<\/ul>\n\n
Wie unterscheiden sich die Mechanismen zur Bewertung der End-to-End-Kennzahlen von SD-WAN und DMVPN\/PfR?<\/h3>\n \nDMVPN\/PfR <\/b><\/p>\n\nZur Bewertung der Standardkenngr\u00f6\u00dfen des Tunnelzustands werden sowohl aktive als auch passive Software-Sensoren (Probes) eingesetzt. Aktive Sensoren basieren auf Benutzerdatenverkehr, passive simulieren diesen Verkehr (bei Abwesenheit desselben). <\/li>\n Eine Feinabstimmung der Timer und Bedingungen zur Erkennung von Degradierungen fehlt \u2013 der Algorithmus ist fix.<\/li>\n Zus\u00e4tzlich ist die Messung der genutzten Bandbreite in der Ausrichtung verf\u00fcgbar. Dies verleiht DMVPN\/PfR zus\u00e4tzliche Flexibilit\u00e4t bei der Verkehrssteuerung.<\/li>\n Dabei verlassen sich einige PfR-Mechanismen bei \u00dcberschreitung der Kennzahlen auf R\u00fcckmeldungen in Form von speziellen TCA (Threshold Crossing Alert)-Nachrichten, die vom Empf\u00e4nger des Datenverkehrs in Richtung des Ursprungs gesendet werden m\u00fcssen, was voraussetzt, dass der Zustand der gemessenen Kan\u00e4le zumindest ausreichend ist, um diese TCA-Nachrichten zu \u00fcbermitteln. Dies ist in den meisten F\u00e4llen kein Problem, aber offensichtlich nicht garantiert. <\/li>\n<\/ul>\n\nSD-WAN <\/b><\/p>\n\nF\u00fcr die End-to-End-Bewertung der standardisierten Kennzahlen des Tunnelzustands wird das BFD-Protokoll im Echo-Modus verwendet. Dabei ist keine spezielle R\u00fcckmeldung in Form von TCA oder \u00e4hnlichen Nachrichten erforderlich \u2013 die Isolation der Ausfall-Dom\u00e4nen bleibt gewahrt. Auch ist kein Benutzerdatenverkehr erforderlich, um den Zustand des Tunnels zu bewerten.<\/li>\n Es besteht die M\u00f6glichkeit, die BFD-Timer feinzustellen, um die Reaktionsgeschwindigkeit und die Sensitivit\u00e4t des Algorithmus gegen\u00fcber Degradierungen des Kommunikationskanals von wenigen Sekunden bis zu Minuten zu regulieren.\n
Zum Zeitpunkt der Erstellung des Artikels ist in jedem Tunnel nur eine BFD-Session vorgesehen. Dies k\u00f6nnte eine geringere Granularit\u00e4t bei der Analyse des Tunnelzustands schaffen. In der Tat k\u00f6nnte dies nur ein Problem darstellen, wenn eine WAN-Verbindung auf Basis von MPLS L2\/L3 VPN mit einem vereinbarten QoS SLA verwendet wird \u2013 wenn die DSCP-Kennzeichnung des BFD-Datenverkehrs (nach der Kapselung in IPSec\/GRE) mit der hochpriorisierten Warteschlange im Netzwerk des Dienstanbieters \u00fcbereinstimmt, k\u00f6nnte dies die Genauigkeit und Geschwindigkeit der Erkennung von Degradierungen f\u00fcr niederpriorisierten Datenverkehr beeintr\u00e4chtigen. In diesem Zusammenhang besteht die M\u00f6glichkeit, die standardm\u00e4\u00dfige Kennzeichnung von BFD zu \u00e4ndern, um das Risiko solcher Situationen zu verringern. In zuk\u00fcnftigen Versionen der Cisco SD-WAN-Software wird eine detailliertere Anpassung von BFD sowie die M\u00f6glichkeit erwartet, mehrere BFD-Sitzungen innerhalb eines Tunnels mit individuellen DSCP-Werten (f\u00fcr verschiedene Anwendungen) zu starten.<\/li>\n BFD erm\u00f6glicht zudem die Bewertung der maximalen Paketgr\u00f6\u00dfe, die \u00fcber einen bestimmten Tunnel ohne Fragmentierung \u00fcbertragen werden kann. Dadurch kann SD-WAN dynamisch Parameter wie MTU und TCP MSS Anpassen, um die verf\u00fcgbare Bandbreite an jedem Kanal optimal zu nutzen.<\/li>\n 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\u00fcgung, die von speziellen Ger\u00e4ten in der Zweigstelle automatisch erstellt werden k\u00f6nnen \u2013 beispielsweise IP-Telefonen.<\/li>\n<\/ul>\n<\/p>\n
Wie unterscheiden sich die M\u00f6glichkeiten, die Bestimmung und Anwendung von AppQ-Richtlinien?<\/h3>\n <\/p>\n
DMVPN\/PfR-Richtlinien:<\/h4>\n <\/p>\n
\nWerden an den Routern(-n) der zentralen Niederlassung (ZF) \u00fcber die CLI-Befehlszeile oder CLI-Vorlagen konfiguriert. Die Erstellung von CLI-Vorlagen erfordert Vorbereitung und Kenntnisse \u00fcber die Syntax der Richtlinien.\n
Werden global definiert ohne die M\u00f6glichkeit, Anpassungen f\u00fcr die Anforderungen einzelner Netzwerksegmente vorzunehmen.<\/b><\/li>\nInteraktive Richtlinienerstellung im grafischen Interface ist nicht vorgesehen.<\/li>\n Die Nachverfolgung von \u00c4nderungen, Vererbung und die Erstellung mehrerer Versionen von Richtlinien f\u00fcr einen schnellen Wechsel sind nicht vorgesehen.<\/li>\n Werden automatisch auf die Router der entfernten Niederlassungen verteilt. Dabei werden dieselben Kommunikationskan\u00e4le verwendet, die auch f\u00fcr die \u00dcbertragung von Benutzerdaten genutzt werden. Bei fehlender Verbindung zwischen der zentralen und der entfernten Niederlassung ist die Verteilung\/\u00c4nderung von Richtlinien nicht m\u00f6glich.<\/li>\n Werden auf jedem Router angewendet und modifizieren bei Bedarf das Ergebnis der Standard-Routing-Protokolle mit h\u00f6herer Priorit\u00e4t. <\/li>\n F\u00fcr F\u00e4lle, in denen alle WAN-Kan\u00e4le der Niederlassung erhebliche Datenverluste erleben, sind keine Kompensationsmechanismen vorgesehen.<\/b>.<\/li>\n<\/ul>\n <\/p>\n
SD-WAN-Richtlinien:<\/h4>\n <\/p>\n
\nWerden im grafischen Interface vManage \u00fcber einen interaktiven Vorlagenassistenten definiert.<\/li>\n Unterst\u00fctzen die Erstellung mehrerer Richtlinien, das Kopieren, Vererben und den Wechsel zwischen Richtlinien in Echtzeit.<\/li>\n Unterst\u00fctzen die individuelle Anpassung von Richtlinien f\u00fcr verschiedene Segmente (Niederlassungen) des Netzwerks.<\/li>\n Werden unter Verwendung jedes verf\u00fcgbaren Signalkanals zwischen dem Controller und dem Router und\/oder vSmart verteilt \u2013 sind nicht direkt von der Datenverbindungsf\u00e4higkeit zwischen den Routern abh\u00e4ngig. Dabei ist jedoch eine IP-Verbindung zwischen dem Router und den Controllern erforderlich.\n
F\u00fcr F\u00e4lle, in denen alle verf\u00fcgbaren Kan\u00e4le der Niederlassung erhebliche Datenverluste \u00fcber die zul\u00e4ssigen Schwellenwerte f\u00fcr kritische Anwendungen hinaus erleiden, k\u00f6nnen zus\u00e4tzliche Mechanismen eingesetzt werden, um die Zuverl\u00e4ssigkeit der \u00dcbertragung zu erh\u00f6hen:\n\nFEC (Forward Error Correction)<\/b> \u2013 verwendet einen speziellen Algorithmus zur Redundanzkodierung. W\u00e4hrend der \u00dcbertragung kritischer Daten \u00fcber Kan\u00e4le mit erheblichem Verlustanteil kann FEC automatisch aktiviert werden, um verloren gegangene Daten wiederherzustellen. Dabei erh\u00f6ht sich die genutzte Bandbreite geringf\u00fcgig, jedoch wird die Zuverl\u00e4ssigkeit erheblich gesteigert.\n
Datenstrom-Duplikation<\/b> \u2013 zus\u00e4tzlich zu FEC kann die Richtlinie eine automatische Duplikation des Datenverkehrs ausgew\u00e4hlter Anwendungen im Falle noch schwerwiegenderer Verluste vorsehen, die nicht mit FEC kompensiert werden k\u00f6nnen. In diesem Fall werden die ausgew\u00e4hlten Daten \u00fcber alle Tunnel zur empfangenden Niederlassung mit anschlie\u00dfender De-Duplizierung (Entfernung \u00fcberfl\u00fcssiger Paketkopien) \u00fcbertragen. Dieses Verfahren erh\u00f6ht die Auslastung der Kan\u00e4le erheblich, steigert jedoch auch die Zuverl\u00e4ssigkeit der \u00dcbertragung.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n <\/p>\n
Funktionen von Cisco SD-WAN, ohne direkte Entsprechung in DMVPN\/PfR<\/h3>\n \nDie Architektur der Cisco SD-WAN-L\u00f6sung erm\u00f6glicht in einigen F\u00e4llen Funktionen, deren Umsetzung im Rahmen von DMVPN\/PfR entweder extrem aufwendig, nicht sinnvoll oder v\u00f6llig unm\u00f6glich ist. Betrachten wir die interessantesten davon:<\/p>\n
Traffic-Engineering (TE)<\/h4>\n \nTE umfasst Mechanismen, die es erm\u00f6glichen, den Verkehr vom Standardweg, der durch Routing-Protokolle gebildet wird, abzuleiten. TE wird h\u00e4ufig verwendet, um eine hohe Verf\u00fcgbarkeit von Netzwerkdiensten sicherzustellen, indem die F\u00e4higkeit genutzt wird, wichtigen Datenverkehr schnell und\/oder im Voraus auf einen alternativen (nicht kreuzenden) \u00dcbertragungsweg umzuleiten, um eine bessere Servicequalit\u00e4t oder eine schnellere Wiederherstellung im Falle eines Ausfalls des Hauptwegs zu gew\u00e4hrleisten. <\/p>\n
Die Umsetzung von TE erfordert die vorherige Berechnung und Reservierung (\u00dcberpr\u00fcfung) 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\u00f6st. Zudem gewinnt die Technologie des Segment-Routings in letzter Zeit zunehmend an Beliebtheit, da sie besser f\u00fcr die zentrale Konfiguration und Orchestrierung optimiert ist. In klassischen WAN-Netzen sind diese Technologien in der Regel nicht vertreten oder beschr\u00e4nken sich auf die Nutzung von hop-by-hop Mechanismen wie Policy-Based Routing (PBR), die den Datenverkehr umleiten k\u00f6nnen, jedoch dies an jedem Router einzeln durchf\u00fchren \u2013 ohne das Gesamtzustand des Netzwerks oder das Ergebnis von PBR in vorherigen oder nachfolgenden Schritten zu ber\u00fccksichtigen. Das Ergebnis dieser TE-Varianten ist entt\u00e4uschend \u2013 MPLS TE wird aufgrund der Komplexit\u00e4t der Konfiguration und des Betriebs in der Regel nur im kritischsten Teil des Netzwerks (Kern) eingesetzt, w\u00e4hrend PBR auf einzelnen Routern verwendet wird, ohne eine einheitliche PBR-Politik f\u00fcr das gesamte Netzwerk zu bilden. Dies gilt offensichtlich auch f\u00fcr DMVPN-basierte Netzwerke.<\/p>\n
Service-chaining <\/h4>\n \nDie 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\u00fcr eine bestimmte Netzwerk-Anwendung definiert werden, sondern auch die M\u00f6glichkeit 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 \u00fcberwachen, um Situationen des Black-Holing zu vermeiden. Au\u00dferdem werden Mechanismen ben\u00f6tigt, die es erm\u00f6glichen, solche \u00e4hnlichen externen Dienstleistungen an verschiedenen geografischen Standorten unterzubringen, sodass das Netzwerk automatisch den optimalsten Service-Knoten f\u00fcr die Bearbeitung des Datenverkehrs eines bestimmten Standorts ausw\u00e4hlen kann. Im Fall von Cisco SD-WAN l\u00e4sst sich dies relativ einfach erreichen, indem eine entsprechende zentralisierte Politik erstellt wird, die alle Aspekte der Ziel-Service-Chain zu einem Ganzen zusammenf\u00fcgt und die Logik des Data-Planes und des Control-Planes nur dort und dann \u00e4ndert, wo es notwendig ist.<\/p>\n
Was ist das Ergebnis?<\/h2>\n \nOffensichtlich l\u00f6sen sowohl DMVPN (gemeinsam oder unabh\u00e4ngig von Performance Routing) als auch Cisco SD-WAN letztlich sehr \u00e4hnliche Aufgaben<\/b> im Verh\u00e4ltnis zum verteilten WAN-Netzwerk einer Organisation. Dabei f\u00fchren die wesentlichen architektonischen und funktionalen Unterschiede der Cisco SD-WAN-Technologie zu einem h\u00f6heren qualitativen Niveau<\/b>. Zusammenfassend lassen sich folgende signifikante Unterschiede zwischen den Technologien SD-WAN und DMVPN\/PfR feststellen:<\/p>\n\nDMVPN\/PfR nutzt insgesamt bew\u00e4hrte Technologien zum Aufbau von Overlay-VPN-Netzen und ist im Bereich des Data-Plans mit der moderneren SD-WAN-Technologie vergleichbar, weist jedoch Einschr\u00e4nkungen in Form einer notwendigen statischen Konfiguration der Router auf, und die Auswahl der Topologien ist auf Hub-n-Spoke beschr\u00e4nkt. Andererseits verf\u00fcgt DMVPN\/PfR \u00fcber einige funktionale M\u00f6glichkeiten, die derzeit im Rahmen von SD-WAN noch nicht verf\u00fcgbar sind (gezielt auf per-application BFD).<\/li>\n Die control-plane Technologien unterscheiden sich grundlegend. Mit der zentralisierten Verarbeitung von Signalisierungsprotokollen erm\u00f6glicht SD-WAN insbesondere, die Ausfallzonen erheblich zu verkleinern und den Prozess der \u00dcbertragung des Benutzerdatenverkehrs von der signalisierenden Interaktion zu entkoppeln \u2013 die vor\u00fcbergehende Nichterreichbarkeit von Controllern beeinflusst nicht die M\u00f6glichkeit, Benutzerdatenverkehr zu \u00fcbertragen. Gleichzeitig hat die vor\u00fcbergehende Nichterreichbarkeit eines Standorts (einschlie\u00dflich des zentralen) keinerlei Einfluss auf die M\u00f6glichkeit der anderen Standorte, miteinander und mit den Controllern zu kommunizieren.<\/li>\n Die Architektur der Erstellung und Anwendung von Traffic-Management-Richtlinien bei SD-WAN \u00fcbertrifft auch die in DMVPN\/PfR \u2013 geo-redundante L\u00f6sungen sind deutlich besser umgesetzt, es gibt keine Bindung an einen Hub, bessere M\u00f6glichkeiten zur Feinabstimmung der Politiken und eine gr\u00f6\u00dfere Liste umsetzbarer Szenarien f\u00fcr das Traffic-Management.<\/li>\n Der Orchestrierungsprozess der L\u00f6sung unterscheidet sich ebenfalls erheblich. DMVPN setzt voraus, dass bereits bekannte Parameter in der Konfiguration reflektiert werden m\u00fcssen, was die Flexibilit\u00e4t der L\u00f6sung und die M\u00f6glichkeit dynamischer \u00c4nderungen etwas einschr\u00e4nkt. Im Gegensatz dazu geht SD-WAN von dem Paradigma aus, dass der Router zu Beginn der Verbindung \"nichts wei\u00df\" \u00fcber seine Controller, aber \"wei\u00df, bei wem man nachfragen kann\" \u2013 das ist ausreichend, um nicht nur die Verbindung zu den Controllern automatisch herzustellen, sondern auch eine vollst\u00e4ndig verbundene Data-Plane-Topologie automatisch zu bilden, die dann flexibel mit Politiken angepasst\/\u00e4nderte werden kann.<\/li>\n Im Bereich des zentralisierten Managements, der Automatisierung und der \u00dcberwachung \u00fcbertrifft SD-WAN erwartungsgem\u00e4\u00df die M\u00f6glichkeiten von DMVPN\/PfR, die das Ergebnis der Entwicklung klassischer Technologien sind und gr\u00f6\u00dftenteils auf die Befehlszeile CLI und die Verwendung von NMS-Systemen auf der Grundlage von Vorlagen angewiesen sind. <\/li>\n Die Sicherheitsanforderungen f\u00fcr SD-WAN im Vergleich zu DMVPN haben ein neues Qualit\u00e4tsniveau erreicht. Die Hauptprinzipien sind Nullvertrauen, Skalierbarkeit und Zwei-Faktor-Authentifizierung.<\/li>\n<\/ul>\n\nAus diesen einfachen Schlussfolgerungen k\u00f6nnte der falsche Eindruck entstehen, dass das Erstellen eines Netzwerks auf der Basis von DMVPN\/PfR heute jegliche Relevanz verloren hat. Das ist nat\u00fcrlich nicht ganz richtig. Beispielsweise in F\u00e4llen, wo im Netzwerk viele veraltete Ger\u00e4te verwendet werden und es keine M\u00f6glichkeit gibt, diese zu ersetzen, kann DMVPN es erm\u00f6glichen, \"alte\" und \"neue\" Ger\u00e4te in ein einheitliches geo-verteiltes Netzwerk zu integrieren, mit vielen der oben beschriebenen Vorteile.<\/p>\n
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\u00fctzen \u2013 sowohl klassische Routing- als auch DMVPN- und SD-WAN-Modi. Die Wahl richtet sich nach den aktuellen Bed\u00fcrfnissen und dem Verst\u00e4ndnis, dass jederzeit auf derselben Hardware auf eine fortschrittlichere Technologie umgeschaltet werden kann.<\/b>habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0421 \u0430\u0432\u0433\u0443\u0441\u0442\u0430 2017 \u0433\u043e\u0434\u0430, \u043a\u043e\u0433\u0434\u0430 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f Cisco \u043f\u0440\u0438\u043e\u0431\u0440\u0435\u043b\u0430 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044e Viptela, \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u0439 \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u0435\u043c\u043e\u0439 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0435\u0439 \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u0438 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0445 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0442\u0438\u0432\u043d\u044b\u0445 \u0441\u0435\u0442\u0435\u0439 \u0441\u0442\u0430\u043b\u0430 Cisco SD-WAN. \u0417\u0430 \u043f\u0440\u043e\u0448\u0435\u0434\u0448\u0438\u0435 3 \u0433\u043e\u0434\u0430 SD-WAN \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u044f \u043f\u0440\u043e\u0448\u043b\u0430 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0439, \u043a\u0430\u043a \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0433\u043e, \u0442\u0430\u043a \u0438 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0433\u043e \u0445\u0430\u0440\u0430\u043a\u0442\u0435\u0440\u0430. \u0422\u0430\u043a \u0437\u043d\u0430\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u0440\u0430\u0441\u0448\u0438\u0440\u0438\u043b\u0438\u0441\u044c \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u0435 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u0438 \u043f\u043e\u044f\u0432\u0438\u043b\u0430\u0441\u044c \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0430 \u043d\u0430 \u043a\u043b\u0430\u0441\u0441\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0442\u043e\u0440\u0430\u0445 \u0441\u0435\u0440\u0438\u0439 Cisco ISR 1000, ISR 4000, ASR 1000 \u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91349,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91348","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t