Funktionale M\u00f6glichkeiten \u2013 was kann eine Technologie, das eine andere nicht kann? Ist das wirklich so wichtig?<\/li>\n<\/ul>\n<\/p>\n
Was sind die architektonischen Unterschiede und wie wichtig sind sie wirklich?<\/h3>\n \nIn jeder der genannten Technologien gibt es viele \u201ebewegliche Teile\u201c, deren Rollen und Interaktionsprinzipien untereinander variieren. Die durchdachten Prinzipien beeinflussen ma\u00dfgeblich die Skalierbarkeit, Fehlertoleranz und Gesamteffizienz der L\u00f6sung. <\/p>\n
Betrachten wir die verschiedenen Aspekte der Architektur n\u00e4her:<\/p>\n
Data-plane<\/b> \u2013 der Teil der L\u00f6sung, der f\u00fcr die \u00dcbertragung des Benutzerverkehrs zwischen Quelle und Empf\u00e4nger verantwortlich ist. In DMVPN und SD-WAN wird dies im Wesentlichen auf den Routern \u00fcber Multipoint GRE-Tunnel gleich umgesetzt. Der Unterschied liegt darin, wodurch die erforderliche Parameterkonfiguration dieser Tunnel erfolgt:<\/p>\n\nin DMVPN\/PfR<\/b> \u2013 es handelt sich um eine ausschliesslich zweistufige Hierarchie von Knoten mit einer Topologie vom Typ \u201eStern\u201c oder Hub-n-Spoke. Eine statische Konfiguration des Hubs und eine statische Bindung des Spokes an den Hub sowie die Interaktion \u00fcber das NHRP-Protokoll zur Bildung der Data-Plane-Konnektivit\u00e4t sind erforderlich. Folglich wird die \u00c4nderung am Hub erheblich erschwert<\/b>, beispielsweise im Zusammenhang mit der \u00c4nderung\/Anbindung neuer WAN-Kan\u00e4le oder der Anpassung bestehender Parameter.<\/li>\nin SD-WAN<\/b> \u2013 ist ein vollst\u00e4ndig dynamisches Modell zur Entdeckung der Parameter der eingerichteten Tunnel, das sich auf das Control-Plane (Protokoll OMP) und das Orchestrierungs-Plane (Interaktion mit dem Controller vBond f\u00fcr die Aufgaben der Controllererkennung und NAT-Traversal) st\u00fctzt. Dabei k\u00f6nnen die \u00fcberlagerten Topologien beliebig sein, einschlie\u00dflich hierarchischer. Innerhalb der etablierten \u00fcberlagerten Topologie der Tunnel ist eine flexible Konfiguration der logischen Topologie in jedem einzelnen VPN (VRF) m\u00f6glich.<\/li>\n<\/ul>\n Control-plane<\/b> \u2013 die Funktionen des Austauschs, der Filterung und der Modifikation von Routing- und anderen Informationen zwischen den Komponenten der L\u00f6sung. <\/p>\n\nin DMVPN\/PfR<\/b> \u2013 erfolgt ausschlie\u00dflich zwischen den Routern Hub und Spoke. Ein direkter Austausch von Routing-Informationen zwischen Spoke ist nicht m\u00f6glich. Folglich kann das Control-plane und Data-plane ohne einen funktionierenden Hub nicht arbeiten.<\/b>, was zus\u00e4tzliche Anforderungen an die Hochverf\u00fcgbarkeit f\u00fcr den Hub stellt, die nicht immer erf\u00fcllt werden k\u00f6nnen.<\/li>\nin SD-WAN<\/b> \u2013 der Steuerungsbereich wird niemals direkt zwischen Routern realisiert \u2013 die Interaktion erfolgt auf Basis des OMP-Protokolls und muss unbedingt \u00fcber einen speziellen Typ von vSmart-Controller erfolgen, was die M\u00f6glichkeit der Lastverteilung, geo-redundanten Sicherung und zentralen Verwaltung der Signallast gew\u00e4hrleistet. Ein weiteres Merkmal des OMP-Protokolls ist seine erhebliche Widerstandsf\u00e4higkeit gegen Verluste und Unabh\u00e4ngigkeit von der \u00dcbertragungsgeschwindigkeit des Kommunikationskanals zu den Controllern (innerhalb vern\u00fcnftiger Grenzen, versteht sich). Das erm\u00f6glicht mit ebenso gro\u00dfem Erfolg die Bereitstellung von SD-WAN-Controllern in \u00f6ffentlichen oder privaten Clouds mit Zugriff \u00fcber das Internet.<\/li>\n<\/ul>\n Policy-Bereich<\/b> \u2013 der Teil der L\u00f6sung, der f\u00fcr die Bestimmung, Verbreitung und Anwendung von Verkehrsteuerungsrichtlinien im verteilten Netzwerk verantwortlich ist.<\/p>\n\nDMVPN <\/b>\u2013 ist tats\u00e4chlich auf die individuell an jedem Router \u00fcber die CLI oder Vorlagen der Prime Infrastructure einstellbaren QoS-Richtlinien beschr\u00e4nkt.<\/li>\nDMVPN\/PfR<\/b> \u2013 PfR-Richtlinien werden auf dem zentralisierten Router Master Controller (MC) \u00fcber die CLI erstellt und anschlie\u00dfend automatisch auf die Zweig-MCs verteilt. Dabei werden die gleichen \u00dcbertragungswege f\u00fcr die Richtlinien wie f\u00fcr die Datenebene verwendet. Eine separate Kommunikation der Richtlinien, Routinginformationen und Benutzerdaten ist nicht m\u00f6glich. Die Verbreitung der Richtlinien setzt die notwendige IP-Konnektivit\u00e4t zwischen Hub und Spoke voraus. Dabei kann die Funktion des MC bei Bedarf mit einem DMVPN-Router kombiniert werden. Die Verwendung von Vorlagen der Prime Infrastructure f\u00fcr die zentralisierte Erstellung von Richtlinien ist m\u00f6glich (aber nicht erforderlich). Eine wichtige Besonderheit ist, dass die Richtlinie global f\u00fcr das gesamte Netzwerk einheitlich erstellt wird \u2013 individuelle Richtlinien f\u00fcr einzelne Segmente werden nicht unterst\u00fctzt<\/b>.<\/li>\nSD-WAN<\/b> \u2013 Die Richtlinien f\u00fcr das Traffic-Management und die Servicequalit\u00e4t werden zentral \u00fcber die grafische Schnittstelle Cisco vManage festgelegt, die auch \u00fcber das Internet zug\u00e4nglich ist (wenn erforderlich). Sie werden entweder \u00fcber Signalkan\u00e4le direkt oder indirekt \u00fcber vSmart-Controller verteilt (abh\u00e4ngig von der Art der Richtlinie). Sie sind nicht von der Data-Plane-Konnektivit\u00e4t zwischen Routern abh\u00e4ngig, da sie alle verf\u00fcgbaren \u00dcbertragungswege zwischen Controller und Router nutzen.\n F\u00fcr verschiedene Netzwerksegmente ist eine flexible Erstellung unterschiedlicher Richtlinien m\u00f6glich \u2013 der Anwendungsbereich der Richtlinie wird durch eine Vielzahl einzigartiger Identifikatoren definiert, die in der L\u00f6sung vorgesehen sind \u2013 Filialnummer, Anwendungsart, Verkehrsrichtung usw.\n<\/li>\n<\/ul>\n
Orchestrierungs-Ebene<\/b> \u2013 Mechanismen, die es Komponenten erm\u00f6glichen, sich dynamisch zu entdecken, sich einzurichten und die nachfolgende Interaktion zu koordinieren.<\/p>\n\nin DMVPN\/PfR<\/b> Die gegenseitige Entdeckung durch Router basiert auf einer statischen Konfiguration der Hub-Ger\u00e4te und der entsprechenden Einrichtung der Spoke-Ger\u00e4te. Die dynamische Entdeckung erfolgt nur f\u00fcr Spoke, das seine Verbindungsparameter an das Hub-Ger\u00e4t meldet, das zuvor in die Konfiguration des Spoke aufgenommen wurde. Ohne IP-Konnektivit\u00e4t zwischen dem Spoke und mindestens einem Hub ist es unm\u00f6glich, sowohl eine Data-Plane- als auch eine Control-Plane-Verbindung herzustellen.<\/b><\/li>\nin SD-WAN<\/b> Die Orchestrierung der Komponenten der L\u00f6sung erfolgt unter Verwendung des Controllers vBond, mit dem jeder Komponente (Router und Controller vManage\/vSmart) zuvor eine IP-Konnektivit\u00e4t hergestellt werden muss.\n Urspr\u00fcnglich wissen die Komponenten nicht \u00fcber die Verbindungsparameter des anderen Bescheid \u2013 hierzu ben\u00f6tigen sie einen Vermittler, den Orchestrator vBond. Das allgemeine Prinzip ist folgendes \u2013 jede Komponente ermittelt in der Anfangsphase (automatisch oder statisch) nur die Verbindungsparameter zu vBond, anschlie\u00dfend informiert vBond den Router \u00fcber die bisher entdeckten vManage- und vSmart-Controller, was die automatische Herstellung aller erforderlichen Signalkonfigurationen erm\u00f6glicht. <\/p>\n
Der n\u00e4chste Schritt besteht darin, dass der neue Router \u00fcber OMP-Austausch mit dem vSmart-Controller Informationen \u00fcber andere Router im Netzwerk erh\u00e4lt. Auf diese Weise kann der Router, der anfangs keinerlei Kenntnisse \u00fcber die Netzwerkkonfiguration hat, vollst\u00e4ndig automatisch die Controller erkennen und sich mit ihnen verbinden und anschlie\u00dfend ebenfalls automatisch die Vernetzung mit anderen Routern erkennen und herstellen. Dabei sind die Verbindungsparameter aller Komponenten zu Beginn unbekannt und k\u00f6nnen sich im Zuge des Betriebs \u00e4ndern.\n<\/li>\n<\/ul>\n
Management-Ebene<\/b> \u2013 der Teil der L\u00f6sung, der eine zentrale Verwaltung und \u00dcberwachung erm\u00f6glicht.<\/p>\n\nDMVPN\/PfR<\/b> \u2013 eine spezialisierte L\u00f6sung f\u00fcr die Management-Ebene ist nicht vorgesehen. F\u00fcr grundlegende Automatisierung und \u00dcberwachung kann die Verwendung von Produkten wie Cisco Prime Infrastructure erfolgen. Jeder Router kann \u00fcber die Kommandozeile CLI verwaltet werden. Integrationen mit externen Systemen \u00fcber API sind nicht vorgesehen.<\/b><\/li>\nSD-WAN<\/b> \u2013 alle regul\u00e4ren Interaktionen und die \u00dcberwachung erfolgen zentral \u00fcber die grafische Benutzeroberfl\u00e4che des Controllers vManage. Alle Funktionen der L\u00f6sung sind ohne Ausnahme \u00fcber vManage einstellbar, ebenso wie \u00fcber eine vollst\u00e4ndig dokumentierte REST API-Bibliothek.\n Alle Konfigurationen des SD-WAN-Netzwerks in vManage beruhen auf zwei Hauptkonstrukten \u2013 der Erstellung von Ger\u00e4tetemplates (Device Template) und der Formulierung von Richtlinien, die die Arbeitslogik des Netzwerks und die Verarbeitung des Datenverkehrs bestimmen. Dabei w\u00e4hlt vManage, basierend auf der vom Administrator festgelegten Richtlinie, automatisch aus, welche \u00c4nderungen an welchen einzelnen Ger\u00e4ten\/Controllern vorgenommen werden m\u00fcssen, was die Effizienz und Skalierbarkeit der L\u00f6sung erheblich steigert.<\/p>\n
\u00dcber die Benutzeroberfl\u00e4che von vManage ist nicht nur die Konfiguration der Cisco SD-WAN-L\u00f6sung zug\u00e4nglich, sondern auch eine umfassende \u00dcberwachung des Zustands aller Komponenten der L\u00f6sung, bis hin zum aktuellen Zustand der Metriken einzelner Tunnel und der Nutzung verschiedener Anwendungen auf Basis von DPI-Analysen.<\/p>\n
Trotz der Zentralisierung der Interaktion verf\u00fcgen alle Komponenten (Controller und Router) \u00fcber eine voll funktionsf\u00e4hige CLI-Befehlszeile, die in der Implementierungsphase oder im Falle einer Notlage f\u00fcr lokale Diagnosen erforderlich ist. Im Normalbetrieb (bei vorhandener Signalisierungsverbindung zwischen den Komponenten) ist die Befehlszeile auf den Routern nur f\u00fcr Diagnosen verf\u00fcgbar und nicht f\u00fcr lokale \u00c4nderungen zug\u00e4nglich, was die lokale Sicherheit garantiert und die \u00c4nderungen in einem solchen Netzwerk \u2013 vManage \u2013 als einzige Quelle definiert.<\/li>\n<\/ul>\n
\nIntegrierte Sicherheit<\/b> \u2013 hier geht es nicht nur um den Schutz der Benutzerdaten bei der \u00dcbertragung \u00fcber offene Kan\u00e4le, sondern auch um die allgemeine Sicherheit des WAN-Netzes, basierend auf der gew\u00e4hlten Technologie.<\/p>\n\nin DMVPN\/PfR<\/b> Es besteht die M\u00f6glichkeit, Benutzerdaten und Signalisierungsprotokolle zu verschl\u00fcsseln. Bei Verwendung bestimmter Modelle von Routern sind zus\u00e4tzlich Funktionen der Firewall mit Traffic-Inspektion, IPS\/IDS verf\u00fcgbar. Es gibt die M\u00f6glichkeit, Filialnetzwerke mit VRF zu segmentieren. Au\u00dferdem gibt es M\u00f6glichkeiten zur Authentifizierung (einfaktorige) von Kontrollprotokollen.\n Hierbei wird der entfernte Router standardm\u00e4\u00dfig als vertrauensw\u00fcrdiges Element des Netzwerks betrachtet \u2013 d.h. es werden keine F\u00e4lle physischer Kompromittierung einzelner Ger\u00e4te und die M\u00f6glichkeit unbefugten Zugriffs darauf ber\u00fccksichtigt, und es gibt keine Zwei-Faktor-Authentifizierung der L\u00f6sungskomponenten, was in einem geografisch verteilten Netzwerk serious additional risks.<\/b> <\/li>\nin SD-WAN<\/b> Analog zum DMVPN besteht die M\u00f6glichkeit, Benutzerdaten zu verschl\u00fcsseln, jedoch mit erheblich erweiterten Funktionen der Netzwerksicherheit und L3\/VRF-Segmentierung (MC, 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 zuvor etablierte Signalisierungskan\u00e4le, die durch DTLS\/TLS-Verschl\u00fcsselung auf der Grundlage von Sicherheitszertifikaten gesch\u00fctzt sind. Dies garantiert die Sicherheit eines solchen Austauschs und erm\u00f6glicht eine bessere Skalierbarkeit der L\u00f6sung bis hin zu Zehntausenden von Ger\u00e4ten in einem Netzwerk.\n Alle Signalverbindungen (Controller-Controller, Controller-Router) sind ebenfalls auf der Grundlage von DTLS\/TLS gesch\u00fctzt. Router werden bei der Herstellung mit Sicherheitszertifikaten ausgestattet, die ein Ersetzen\/Verl\u00e4ngern erm\u00f6glichen. Die Zwei-Faktor-Authentifizierung wird durch die verpflichtende und gleichzeitige Erf\u00fcllung von zwei Bedingungen f\u00fcr die Funktionsf\u00e4higkeit des Routers\/Controllers im SD-WAN-Netzwerk erreicht:<\/p>\n
\nG\u00fcltiges Sicherheitszertifikat<\/li>\n Eindeutige und bewusste Aufnahme jedes Komponenten durch den Administrator in die \u201ewei\u00dfe\u201c Liste der genehmigten Ger\u00e4te.<\/li>\n<\/ul>\n\n<\/li>\n<\/ul>\n
Funktionale Unterschiede zwischen SD-WAN und DMVPN\/PfR<\/h2>\n \nIm Hinblick auf die Diskussion der funktionalen Unterschiede ist anzumerken, dass viele davon eine Fortsetzung der architektonischen Unterschiede darstellen \u2013 es ist kein Geheimnis, dass die Entwickler bei der Gestaltung der Architektur eines L\u00f6sungskonzepts von den M\u00f6glichkeiten ausgehen, die sie letztendlich erhalten m\u00f6chten. Lassen Sie uns die bedeutendsten Unterschiede zwischen diesen beiden Technologien betrachten.<\/p>\n
AppQ (Application Quality) \u2013 Funktionen zur Gew\u00e4hrleistung der Qualit\u00e4t der \u00dcbertragung von Gesch\u00e4ftsanwendungen<\/h3>\n \nDie Kernfunktionen der betrachteten Technologien zielen darauf ab, das Benutzererlebnis bei der Nutzung von gesch\u00e4ftskritischen 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 sogar keine erfolgreiche Daten\u00fcbertragung garantiert.<\/p>\n
DMVPN bietet solche Mechanismen nicht selbst an. Das Beste, was in einem klassischen DMVPN-Netzwerk gemacht werden kann, ist, den ausgehenden Datenverkehr nach Anwendungen zu klassifizieren und ihn bei der \u00dcbertragung 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 jedoch der End-to-End-Zustand des Pfades\/Tunnels und seine m\u00f6gliche teilweise Verschlechterung in Bezug auf Schl\u00fcsselmetriken, die f\u00fcr Netzwerkapplikationen bedeutend sind \u2013 wie Verz\u00f6gerung, Verz\u00f6gerungsvariabilit\u00e4t (Jitter) und Verluste (%) \u2013 nicht ber\u00fccksichtigt. Daher macht ein direkter Vergleich von klassischem DMVPN mit SD-WAN hinsichtlich der L\u00f6sung von AppQ-Aufgaben keinen Sinn \u2013 DMVPN kann diese Aufgabe nicht l\u00f6sen. Mit der Hinzunahme der Technologie Cisco Performance Routing (PfR) ver\u00e4ndert sich die Situation, und der Vergleich mit Cisco SD-WAN wird sinnvoller. <\/p>\n
Bevor wir die Unterschiede besprechen, kurz zu den Gemeinsamkeiten der Technologien. Also, beide Technologien:<\/p>\n
\nverf\u00fcgen \u00fcber einen Mechanismus, der es erm\u00f6glicht, den Zustand jedes installierten Tunnels dynamisch in Bezug auf bestimmte Metriken zu bewerten \u2013 mindestens Latenz, Latenzvariation und Paketverlust (%).<\/li>\n verwenden eine bestimmte Werkzeugauswahl zur Bildung, Verbreitung und Anwendung von Regeln (Politiken) zur Verkehrssteuerung unter Ber\u00fccksichtigung der Ergebnisse der Messung des Zustands der Schl\u00fcsselmetrik der Tunnel.<\/li>\n klassifizieren den Anwendungsverkehr auf den Ebenen L3-L4 (DSCP) des OSI-Modells oder anhand von L7-Signaturen von Anwendungen unter Verwendung der im Router integrierten DPI-Mechanismen.<\/li>\n erm\u00f6glichen es f\u00fcr bedeutende Anwendungen, zul\u00e4ssige Schwellenwerte f\u00fcr die Metriken, die Standard\u00fcbertragungsregeln f\u00fcr den Datenverkehr und die Regeln zur Neurouting des Datenverkehrs bei \u00dcberschreitung der Schwellenwerte zu definieren.<\/li>\n bei der Kapselung des Datenverkehrs in GRE\/IPSec verwenden sie einen etablierten Branchenmechanismus, um die interne DSCP-Markierung in den \u00e4u\u00dferen GRE\/IPSec-Paketheader zu \u00fcbertragen, was es erm\u00f6glicht, die QoS-Politiken der Organisation und des Telekommunikationsanbieters (bei Vorliegen eines entsprechenden SLA) zu synchronisieren.<\/li>\n<\/ul>\n\n
Wie unterscheiden sich die Mechanismen zur Bewertung der End-to-End-Metriken von SD-WAN und DMVPN\/PfR?<\/h3>\n \nDMVPN\/PfR <\/b><\/p>\n\nZur Bewertung der standardm\u00e4\u00dfigen Tunnelzustandsmetriken kommen sowohl aktive als auch passive Software-Sensoren (Probes) zum Einsatz. Aktive basieren auf Benutzerdatenverkehr, passive simulieren solchen Verkehr (bei dessen Abwesenheit). <\/li>\n Eine feine Abstimmung der Timer und Bedingungen zur Erkennung von Leistungsverschlechterungen fehlt \u2013 der Algorithmus ist festgelegt.<\/li>\n Zus\u00e4tzlich steht die Messung der in ausgehender Richtung verwendeten Bandbreite zur Verf\u00fcgung. Das verleiht DMVPN\/PfR zus\u00e4tzliche Flexibilit\u00e4t bei der Verkehrssteuerung.<\/li>\n Dabei verlassen sich einige PfR-Mechanismen bei \u00dcberschreiten der Metriken auf eine r\u00fcckl\u00e4ufige Signalisierung in Form spezieller TCA (Threshold Crossing Alert)-Nachrichten, die vom Empf\u00e4nger des Datenverkehrs in Richtung des Quellen gesendet werden m\u00fcssen, was wiederum vorschreibt, dass die Zust\u00e4nde der gemessenen Kan\u00e4le mindestens ausreichend sein m\u00fcssen, um solche TCA-Nachrichten zu \u00fcbermitteln. Dies ist in den meisten F\u00e4llen kein Problem, kann aber offensichtlich nicht garantiert werden. <\/li>\n<\/ul>\n\nSD-WAN <\/b><\/p>\n\nF\u00fcr die durchgehende Bewertung der Standardmetriken des Tunnelzustands wird das BFD-Protokoll im Echo-Modus verwendet. Dabei ist kein spezielles Feedback in Form von TCA oder \u00e4hnlichen Nachrichten erforderlich \u2013 die Isolierung der Ausfall-Dom\u00e4nen wird eingehalten. Au\u00dferdem ist das Vorhandensein von Benutzerdatenverkehr zur Bewertung des Tunnelzustands nicht notwendig.<\/li>\n Es besteht die M\u00f6glichkeit, die BFD-Timer feinzustellen, um die Ausl\u00f6segeschwindigkeit und die Sensitivit\u00e4t des Algorithmus gegen\u00fcber der Verschlechterung des Kommunikationskanals von mehreren Sekunden bis zu Minuten zu regulieren.\n
Zum Zeitpunkt des Schreibens des Artikels ist in jedem Tunnel nur eine BFD-Sitzung vorgesehen. Dies kann potenziell eine geringere Granularit\u00e4t bei der Analyse des Tunnelzustands schaffen. In der Praxis k\u00f6nnte dies nur bei der Verwendung einer WAN-Verbindung auf Basis von MPLS L2\/L3 VPN mit vereinbartem QoS SLA zur Einschr\u00e4nkung werden \u2013 wenn das DSCP-Tagging des BFD-Verkehrs (nach der Kapselung in IPSec\/GRE) mit einer hochpriorisierten Warteschlange im Netzwerk des Telekommunikationsanbieters \u00fcbereinstimmt, kann dies die Genauigkeit und Geschwindigkeit der Erkennung von Verschlechterungen bei niedrigpriorisiertem Verkehr beeinflussen. Dabei gibt es die M\u00f6glichkeit, das standardm\u00e4\u00dfige BFD-Tagging zu \u00e4ndern, um das Risiko \u00e4hnlicher Situationen zu verringern. In zuk\u00fcnftigen Versionen der Cisco SD-WAN-Software wird eine feinere Einstellung von BFD sowie die M\u00f6glichkeit erwartet, mehrere BFD-Sitzungen innerhalb eines einzelnen Tunnels mit individuellen DSCP-Werten (f\u00fcr verschiedene Anwendungen) zu starten.<\/li>\n BFD erm\u00f6glicht es zudem, die maximale Paketgr\u00f6\u00dfe zu bewerten, die ohne Fragmentierung \u00fcber einen bestimmten Tunnel \u00fcbertragen werden kann. Dies erm\u00f6glicht SD-WAN, solche Parameter wie MTU und TCP MSS Adjust dynamisch zu konfigurieren, um die verf\u00fcgbare Bandbreite an jedem Kanal optimal zu nutzen.<\/li>\n Im SD-WAN steht auch die Option zur Synchronisierung von QoS mit den Telekommunikationsanbietern zur Verf\u00fcgung, nicht nur basierend auf dem L3 DSCP-Feld, sondern auch basierend auf den L2 CoS-Werten, die in den Filialnetzwerken automatisch von spezialisierten Ger\u00e4ten, wie beispielsweise IP-Telefonen, erstellt werden k\u00f6nnen.<\/li>\n<\/ul>\n<\/p>\n
Wie unterscheiden sich die M\u00f6glichkeiten, Methoden zur Bestimmung und Anwendung von AppQ-Richtlinien?<\/h3>\n <\/p>\n
DMVPN\/PfR-Richtlinien:<\/h4>\n <\/p>\n
\nDiese werden an den zentralen Filialrouter(n) (ZFR) \u00fcber die CLI-Befehlszeile oder CLI-Vorlagendateien konfiguriert. Die Erstellung von CLI-Vorlagen erfordert Vorarbeit und Kenntnisse des Syntax der Richtlinien.\n
Werden global festgelegt ohne M\u00f6glichkeit der individuellen Anpassung\/\u00c4nderung an die Anforderungen einzelner Netzsegmente.<\/b><\/li>\nDie interaktive Erstellung von Richtlinien in der grafischen Benutzeroberfl\u00e4che 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 Router in entfernten Niederlassungen verteilt. Dabei werden die gleichen Kommunikationskan\u00e4le verwendet wie f\u00fcr die \u00dcbertragung von Benutzerdaten. Bei Fehlen einer Kommunikationsverbindung zwischen der Zentrale und der entfernten Niederlassung ist die Verbreitung\/\u00c4nderung von Richtlinien nicht m\u00f6glich.<\/li>\n Werden auf jedem Router angewendet und modifizieren bei Bedarf das Ergebnis der Standard-Routingprotokolle, indem sie eine h\u00f6here Priorit\u00e4t haben. <\/li>\n F\u00fcr F\u00e4lle, in denen alle WAN-Kan\u00e4le der Niederlassung erhebliche Verkehrsverluste aufweisen, sind keine Kompensationsmechanismen vorgesehen<\/b>.<\/li>\n<\/ul>\n <\/p>\n
SD-WAN-Richtlinien:<\/h4>\n <\/p>\n
\nWerden \u00fcber die grafische Benutzeroberfl\u00e4che vManage durch einen interaktiven Vorlagenassistenten festgelegt.<\/li>\n Unterst\u00fctzen die Erstellung mehrerer Richtlinien, das Kopieren, die Vererbung 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 von jedem verf\u00fcgbaren Signalkanal zwischen Controller und Router und\/oder vSmart verbreitet \u2013 sie sind nicht direkt von der Datenebene der Router abh\u00e4ngig. Dabei ist nat\u00fcrlich eine IP-Konnektivit\u00e4t zwischen dem Router und den Controllern erforderlich.\n
F\u00fcr F\u00e4lle, in denen alle verf\u00fcgbaren Kan\u00e4le der Niederlassung erhebliche Datenverluste aufweisen, die die zul\u00e4ssigen Schwellenwerte f\u00fcr kritische Anwendungen \u00fcberschreiten, ist die Verwendung zus\u00e4tzlicher Mechanismen zur Verbesserung der \u00dcbertragungszuverl\u00e4ssigkeit m\u00f6glich:\n\nFEC (Forward Error Correction)<\/b> \u2013 verwendet einen speziellen Algorithmus zur Redundanzkodierung. Bei der \u00dcbertragung kritischer Daten \u00fcber Kan\u00e4le mit einem erheblichen Verlustprozentsatz kann FEC automatisch aktiviert werden und erm\u00f6glicht es gegebenenfalls, die verlorenen Daten wiederherzustellen. Dabei wird zwar die genutzte Bandbreite geringf\u00fcgig erh\u00f6ht, jedoch wird die Zuverl\u00e4ssigkeit erheblich gesteigert.\n
Duplikation von Datenstr\u00f6men<\/b> Zus\u00e4tzlich zur FEC kann die Politik eine automatische Dublette des Traffics ausgew\u00e4hlter Anwendungen vorsehen, falls ein noch gravierenderer Verlustgrad auftritt, der nicht durch FEC ausgeglichen werden kann. In diesem Fall werden die ausgew\u00e4hlten Daten \u00fcber alle Tunnel zum empfangenden Zweig \u00fcbertragen, gefolgt von der De-Duplizierung (Entfernung \u00fcberfl\u00fcssiger Kopien von Paketen). Dieser Mechanismus erh\u00f6ht die Auslastung der Kan\u00e4le erheblich, steigert jedoch auch die Zuverl\u00e4ssigkeit der \u00dcbertragung signifikant.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n <\/p>\n
Die M\u00f6glichkeiten von Cisco SD-WAN, die in DMVPN\/PfR keine direkten Entsprechungen haben<\/h3>\n \nDie Architektur der Cisco SD-WAN-L\u00f6sung erm\u00f6glicht in bestimmten F\u00e4llen Funktionen, deren Implementierung im Rahmen von DMVPN\/PfR entweder \u00e4u\u00dferst schwierig oder aufgrund des erforderlichen Aufwands nicht sinnvoll ist, oder die \u00fcberhaupt nicht m\u00f6glich sind. Lassen Sie uns die interessantesten von ihnen betrachten:<\/p>\n
Traffic-Engineering (TE)<\/h4>\n \nTE umfasst Mechanismen, die es erm\u00f6glichen, den Traffic von dem standardm\u00e4\u00dfigen Pfad, der durch Routing-Protokolle gebildet wird, abzuleiten. TE wird h\u00e4ufig eingesetzt, um eine hohe Verf\u00fcgbarkeit von Netzwerkdiensten zu gew\u00e4hrleisten, indem es die F\u00e4higkeit bietet, schnell und\/oder im Voraus wichtigen Traffic auf einen alternativen (nicht sich \u00fcberschneidenden) \u00dcbertragungsweg umzuleiten, um eine bessere Dienstqualit\u00e4t oder Geschwindigkeit der Wiederherstellung im Falle eines Ausfalls des Hauptpfades zu gew\u00e4hrleisten. <\/p>\n
Die Komplexit\u00e4t der Implementierung von TE liegt darin, dass ein alternativer Pfad im Voraus berechnet und reserviert (\u00fcberpr\u00fcft) werden muss. In MPLS-Netzen der Telekommunikationsanbieter wird diese Aufgabe durch Technologien wie MPLS Traffic Engineering mit Erweiterungen zu IGP-Protokollen und dem RSVP-Protokoll gel\u00f6st. Auch die Segment Routing-Technologie gewinnt in letzter Zeit zunehmend an Beliebtheit, da sie besser f\u00fcr die zentralisierte Konfiguration und Orchestrierung optimiert ist. In klassischen WAN-Netzen sind diese Technologien in der Regel nicht vorhanden oder beschr\u00e4nken sich auf die Verwendung von hop-by-hop Mechanismen wie Policy-Based Routing (PBR), die in der Lage sind, den Traffic umzuleiten, dies jedoch auf jedem einzelnen Router ohne Ber\u00fccksichtigung des allgemeinen Netzwerkzustands oder des Ergebnisses von PBR in vorhergehenden oder nachfolgenden Schritten umsetzen. Das Ergebnis dieser Implementierungsvarianten von TE ist wenig erfreulich: 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 ohne die M\u00f6glichkeit verwendet wird, eine einheitliche PBR-Politik f\u00fcr das gesamte Netzwerk zu bilden. Offensichtlich betrifft dies auch Netzwerke auf Basis von DMVPN.<\/p>\n
Service-Chaining <\/h4>\n \nDie Bildung von Servicetransportketten ist eine noch arbeitsintensivere Aufgabe in der klassischen Routenplanung als der bereits beschriebene Traffic Engineering-Mechanismus. In diesem Fall ist es erforderlich, nicht nur eine spezielle Route f\u00fcr eine bestimmte Netzwerkapplikation zu erstellen, sondern auch die M\u00f6glichkeit zu gew\u00e4hrleisten, den Datenverkehr aus dem Netzwerk an bestimmten (oder an allen) Knoten des SD-WAN-Netzwerks zu leiten, um von einer speziellen Anwendung oder Dienstleistung (z. B. MSE, Lastverteilung, Caching, Verkehrs\u00fcberwachung usw.) verarbeitet zu werden. Dabei ist es wichtig, den Zustand dieser externen Dienste zu \u00fcberwachen, um Situationen des Black-Holing zu vermeiden. Dar\u00fcber hinaus sind Mechanismen erforderlich, die es erm\u00f6glichen, solche einheitlichen externen Dienste an verschiedenen geografischen Standorten zu platzieren, mit der M\u00f6glichkeit, dass das Netzwerk automatisch den optimalsten Servicestandort f\u00fcr die Verarbeitung des Verkehrs eines bestimmten Standorts ausw\u00e4hlt. Im Fall von Cisco SD-WAN ist dies recht einfach zu erreichen, indem eine entsprechende zentralisierte Richtlinie erstellt wird, die alle Aspekte der Ziel-Servicekette zu einem Ganzen zusammenf\u00fcgt und die Logik des Data-Planes und Control-Planes nur dort und dann automatisch \u00e4ndert, wo es notwendig ist.<\/p>\n
Was kommt dabei heraus?<\/h2>\n \nEs ist offensichtlich, dass sowohl DMVPN (gemeinsam oder ohne Performance Routing) als auch Cisco SD-WAN letztendlich sehr \u00e4hnliche Aufgaben l\u00f6sen<\/b> im Bezug auf das verteilte WAN-Netzwerk einer Organisation. Dabei f\u00fchren signifikante architektonische und funktionale Unterschiede der Cisco SD-WAN-Technologie den Prozess der L\u00f6sung dieser Aufgaben auf ein qualitativ h\u00f6heres Niveau<\/b>. Zusammenfassend kann man auf folgende wesentliche Unterschiede zwischen den Technologien SD-WAN und DMVPN\/PfR hinweisen:<\/p>\n\nDMVPN\/PfR nutzt insgesamt bew\u00e4hrte Technologien zum Aufbau von virtuellen privaten Netzwerken und weist im Bereich Data-Plane \u00c4hnlichkeiten zur moderneren SD-WAN-Technologie auf, w\u00e4hrend es jedoch Einschr\u00e4nkungen gibt, wie die zwingende statische Konfiguration von Routern und eine begrenzte Auswahl an Topologien (Hub-n-Spoke). Auf der anderen Seite bietet DMVPN\/PfR einige funktionale M\u00f6glichkeiten, die in SD-WAN derzeit nicht verf\u00fcgbar sind (insbesondere per-application BFD).<\/li>\n Im Bereich der Control-Plane-Technologien unterscheiden sie sich grundlegend. Angesichts der zentralisierten Verarbeitung von Signalisierungsprotokollen erm\u00f6glicht SD-WAN unter anderem eine deutliche Verengung der Ausfall-Dom\u00e4nen und \u201eentkoppelt\u201c den Prozess der \u00dcbertragung von Nutzerdatenverkehr von der signalisierenden Interaktion \u2013 die tempor\u00e4re Nichterreichbarkeit von Controllern hat keine Auswirkungen auf die M\u00f6glichkeit, den Nutzerdatenverkehr zu \u00fcbertragen. Gleichzeitig beeinflusst die vor\u00fcbergehende Nichterreichbarkeit einer Niederlassung (einschlie\u00dflich der zentralen) nicht die Interaktion der \u00fcbrigen Niederlassungen untereinander und mit den Controllern.<\/li>\n Die Architektur zur Bildung und Anwendung von Verkehrsmanagementrichtlinien im Falle von SD-WAN \u00fcbertrifft die von DMVPN\/PfR ebenfalls \u2013 Geo-Redundanz ist wesentlich besser umgesetzt, es gibt keine Bindung an ein Hub, mehr M\u00f6glichkeiten zur feinen Anpassung von Richtlinien, und die Liste der umsetzbaren Szenarien zur Verkehrslenkung ist ebenfalls deutlich umfangreicher.<\/li>\n Der Orchestrierungsprozess der L\u00f6sung unterscheidet sich ebenfalls erheblich. DMVPN setzt voraus, dass im Voraus bekannte Parameter in irgendeiner Form in der Konfiguration abgebildet werden, was die Flexibilit\u00e4t der L\u00f6sung und die M\u00f6glichkeit dynamischer \u00c4nderungen etwas einschr\u00e4nkt. Im Gegensatz dazu geht SD-WAN von der Paradigme aus, dass der Router zu Beginn der Verbindung \u201enichts wei\u00df\u201c \u00fcber seine Controller, jedoch wei\u00df, \u201ewen er fragen kann\u201c \u2013 dies reicht nicht nur aus, um eine automatische Verbindung zu den Controllern herzustellen, sondern auch zur automatischen Bildung einer vollst\u00e4ndig verbundenen Data-Plane-Topologie, die dann flexibel angepasst\/\u00e4nderbar ist durch Richtlinien.<\/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 weitgehend auf die Eingabeaufforderung CLI und die Anwendung von NMS-Systemen basieren, die auf Vorlagen beruhen. <\/li>\n Im Vergleich zu DMVPN hat SD-WAN die Sicherheitsanforderungen auf ein neues qualitatives Niveau gehoben. Die Hauptprinzipien sind Nullvertrauen, Skalierbarkeit und Zwei-Faktor-Authentifizierung.<\/li>\n<\/ul>\n\nAus diesen einfachen Schlussfolgerungen k\u00f6nnte der falsche Eindruck entstehen, dass die Erstellung eines Netzwerks auf Basis von DMVPN\/PfR heute g\u00e4nzlich an Relevanz verloren hat. Das ist nat\u00fcrlich nicht ganz richtig. In F\u00e4llen, in denen in einem Netzwerk eine Vielzahl von veralteter Hardware verwendet wird und es keine M\u00f6glichkeit gibt, diese zu ersetzen, kann DMVPN es erm\u00f6glichen, \u201ealte\u201c und \u201eneue\u201c Ger\u00e4te in einem einheitlichen geo-verteilten Netzwerk zu verbinden, das viele der oben beschriebenen Vorteile bietet.<\/p>\n
Auf der anderen Seite sollte man nicht vergessen, dass alle aktuellen Cisco-Router f\u00fcr Unternehmen, die auf IOS XE basieren (ISR 1000, ISR 4000, ASR 1000, CSR 1000v), heute jeden Betriebsmodus unterst\u00fctzen \u2013 sowohl klassische Routing-Methoden als auch DMVPN und SD-WAN. Die Wahl h\u00e4ngt von den aktuellen Bed\u00fcrfnissen ab und dem Verst\u00e4ndnis, dass man jederzeit auf derselben Hardware in Richtung fortschrittlicherer Technologien gehen 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