Funktionelle muligheder \u2013 hvad kan \u00e9n teknologi, som en anden ikke kan? Og er det virkelig s\u00e5 vigtigt?<\/li>\n<\/ul>\n<\/p>\n
Hvad er de arkitektoniske forskelle, og er de s\u00e5 vigtige?<\/h3>\n \nHver af de n\u00e6vnte teknologier har mange 'bev\u00e6gelige dele', som har b\u00e5de forskellige roller og interaktionsprincipper. Hvor gennemt\u00e6nkte disse principper er, afh\u00e6nger direkte af l\u00f8sningens skalerbarhed, fejltolerance og samlede effektivitet. <\/p>\n
Lad os se n\u00e6rmere p\u00e5 forskellige aspekter af arkitekturen:<\/p>\n
Data-plane<\/b> \u2013 den del af l\u00f8sningen, der er ansvarlig for transmission af brugertrafik mellem kilden og modtageren. I DMVPN og SD-WAN implementeres det stort set ens p\u00e5 selve routerne via Multipoint GRE-tunneler. Forskellen ligger i, hvordan det n\u00f8dvendige s\u00e6t af parametre for disse tunneler dannes:<\/p>\n\ni DMVPN\/PfR<\/b> \u2013 det er en udelukkende to-niveau hierarki af noder med en 'Stjerne'-topologi eller Hub-n-Spoke. Statisk ops\u00e6tning af Hub og statisk binding af Spoke til Hub er obligatorisk, samt interaktion via NHRP-protokollen for at danne data-plane forbindelser. Som f\u00f8lge af dette, bliver \u00e6ndringer p\u00e5 Hub betydeligt vanskeligere<\/b>, relateret til f.eks. \u00e6ndring\/tilslutning af nye WAN-kanaler eller \u00e6ndring af parametre for eksisterende.<\/li>\ni SD-WAN<\/b> \u2013 det er en fuldst\u00e6ndig dynamisk model for opdagelse af parametrene for oprettede tunneler, baseret p\u00e5 control-plane (OMP-protokollen) og orchestration-plane (interaktion med vBond-controlleren til opgaver s\u00e5som opdagelse af controllere og NAT traversal). De p\u00e5lagte topologier kan v\u00e6re enhver, inklusive hierarkiske. Inden for den etablerede p\u00e5lagte topologi af tunneler er det muligt med fleksibel konfiguration af den logiske topologi i hver enkelt VPN (VRF).<\/li>\n<\/ul>\n Control-plane<\/b> \u2013 funktioner til udveksling, filtrering og modifikation af rute- og anden information mellem komponenterne i l\u00f8sningen. <\/p>\n\ni DMVPN\/PfR<\/b> \u2013 sker kun mellem Hub- og Spoke-routere. Direkte udveksling af ruteinformation mellem Spoke er ikke muligt. Som f\u00f8lge af dette, kan control-plane og data-plane ikke fungere uden en aktiv Hub.<\/b>, hvilket p\u00e5l\u00e6gger Hub ekstra krav til h\u00f8j tilg\u00e6ngelighed, som ikke altid kan opfyldes.<\/li>\ni SD-WAN<\/b> \u2013 kontrolplanet udf\u00f8res aldrig direkte mellem routere \u2013 interaktionen sker p\u00e5 basis af OMP-protokollen og skal ske gennem en s\u00e6rskilt specialiseret type controller vSmart, hvilket muligg\u00f8r belastningsbalancering, geo-redundans og centraliseret h\u00e5ndtering af signalbelastningen. En anden funktion ved OMP-protokollen er dens betydelige modstandsdygtighed over for tab og uafh\u00e6ngighed af hastigheden af forbindelseskanalen til kontrolenhederne (inden for rimelige gr\u00e6nser, selvf\u00f8lgelig). Dette g\u00f8r det liges\u00e5 muligt at placere SD-WAN-controllere i offentlige eller private skyer med adgang via internettet.<\/li>\n<\/ul>\n Policy-plane<\/b> \u2013 den del af l\u00f8sningen, der er ansvarlig for definition, distribution og implementering af trafikstyringspolitikker i det distribuerede netv\u00e6rk.<\/p>\n\nDMVPN <\/b>\u2013 er reelt begr\u00e6nset af kvaliteten af servicepolitikker (QoS), der kan konfigureres individuelt p\u00e5 hver router via CLI eller Prime Infrastructure-skabeloner.<\/li>\nDMVPN\/PfR<\/b> \u2013 PfR-politikker skabes p\u00e5 den centraliserede router Master Controller (MC) gennem CLI og distribueres derefter automatisk til filialernes MC. Her bruges de samme transmissionsveje til politikker som for data-plane. Det er ikke muligt at adskille udvekslingen af politikker, ruteinformation og brugerdata. Distributionen af politikker foruds\u00e6tter, at der er IP-forbindelse mellem Hub og Spoke. Hertil kan MC-funktionen om n\u00f8dvendigt kombineres med DMVPN-routeren. Anvendelse af Prime Infrastructure-skabeloner til centraliseret oprettelse af politikker er muligt (men ikke p\u00e5kr\u00e6vet). En vigtig funktion er, at politikken skabes globalt p\u00e5 hele netv\u00e6rket ensartet \u2013 individuelle politikker for separate segmenter underst\u00f8ttes ikke.<\/b>.<\/li>\nSD-WAN<\/b> \u2013 trafikstyrings- og kvalitetsstyringspolitikker defineres centralt via grafisk brugergr\u00e6nseflade Cisco vManage, der ogs\u00e5 er tilg\u00e6ngelig over internettet (om n\u00f8dvendigt). De distribueres over signalveje direkte eller indirekte gennem vSmart controllere (afh\u00e6ngig af politiktype). De er uafh\u00e6ngige af data-plane forbindelsen mellem routerne, da de bruger alle tilg\u00e6ngelige transmissionsveje mellem controllere og routere.\n For forskellige netv\u00e6rkssegmenter er det muligt at danne fleksible politikker \u2013 anvendelsesomr\u00e5det for politikken defineres af mange unikke identifikatorer, der er tilvejebragt i l\u00f8sningen \u2013 filialnummer, applikationstype, trafikretning mv.\n<\/li>\n<\/ul>\n
Orchestration-plane<\/b> \u2013 mekanismer der g\u00f8r det muligt for komponenterne at opdage hinanden dynamisk, konfigurere og koordinere efterf\u00f8lgende interaktion.<\/p>\n\ni DMVPN\/PfR<\/b> Det gensidige opdagelse mellem routerne er baseret p\u00e5 statisk konfiguration af Hub-enheder og tilsvarende ops\u00e6tning af Spoke-enheder. Dynamisk opdagelse sker kun for Spoke, som informerer Hub-enheden om sine forbindelsesparametre, som p\u00e5 forh\u00e5nd er indf\u00f8rt i Spoke's konfiguration. Uden IP-forbindelse mellem Spoke og mindst \u00e9n Hub er det umuligt at danne hverken data-plane eller control-plane.<\/b><\/li>\ni SD-WAN<\/b> Orkestreringen af komponenterne i l\u00f8sningen foreg\u00e5r ved hj\u00e6lp af controlleren vBond, som hver komponent (routere og controllere vManage\/vSmart) skal have en IP-forbindelse til p\u00e5 forh\u00e5nd.\n Oprindeligt kender komponenterne ikke til hinandens forbindelsesparametre \u2013 de har brug for en mellemmand, orkestratoren vBond. Den overordnede princip er, at hver komponent i den indledende fase kun automatisk eller statisk kender til forbindelsesparametrene til vBond, hvorefter vBond informerer routeren om vManage og vSmart controllere (tidligere opdaget), hvilket muligg\u00f8r automatisk etablering af alle n\u00f8dvendige signalforbindelser. <\/p>\n
N\u00e6ste skridt vil den nye router l\u00e6re om de \u00f8vrige routingssystemer i netv\u00e6rket via OMP-udveksling med vSmart-controlleren. P\u00e5 den m\u00e5de kan routeren, uden at vide noget om netv\u00e6rksparametrene fra starten, automatisk opdage og oprette forbindelse til controllerne og derefter ogs\u00e5 automatisk opdage og danne forbindelser til de \u00f8vrige routingssystemer. I denne forbindelse er tilslutningsparametrene for alle komponenter oprindeligt ukendte og kan \u00e6ndre sig under drift.\n<\/li>\n<\/ul>\n
Management-plane<\/b> \u2013 den del af l\u00f8sningen, der sikrer centraliseret styring og overv\u00e5gning.<\/p>\n\nDMVPN\/PfR<\/b> \u2013 der er ikke forudset nogen specialiseret management-plane l\u00f8sning. For grundl\u00e6ggende automatisering og overv\u00e5gning kan produkter som Cisco Prime Infrastructure anvendes. Hver router har mulighed for at styres via kommandolinjegr\u00e6nsefladen CLI. Integrationer med eksterne systemer via API er ikke forudset.<\/b><\/li>\nSD-WAN<\/b> \u2013 al standard interaktion og overv\u00e5gning foreg\u00e5r centraliseret gennem den grafiske interface p\u00e5 vManage-controlleren. Alle l\u00f8sninger, uden undtagelse, kan konfigureres via vManage samt gennem et fuldt dokumenteret REST API.\n Alle indstillinger for SD-WAN-netv\u00e6rket i vManage reduceres til to hovedkonstruktioner \u2013 oprettelse af enheds skabeloner (Device Template) og formulering af politikker, som bestemmer netv\u00e6rkets logik og trafikbehandling. vManage v\u00e6lger automatisk, hvilken \u00e6ndringer og p\u00e5 hvilke individuelle enheder\/controller der skal foretages, n\u00e5r den administratormdefinerede politik transmitteres, hvilket v\u00e6sentligt \u00f8ger l\u00f8sningen effektivitet og skalerbarhed.<\/p>\n
Gennem vManage-interfacet er der ikke kun mulighed for at konfigurere Cisco SD-WAN-l\u00f8sningen, men ogs\u00e5 en fuld overv\u00e5gning af tilstanden for alle komponenter i l\u00f8sningen, alt fra den aktuelle tilstand af metrikker for individuelle tunneller til statistikker over brugen af forskellige applikationer baseret p\u00e5 DPI-analyse.<\/p>\n
P\u00e5 trods af centraliseringen af interaktionen har alle komponenter (controllere og routere) ogs\u00e5 en fuldt funktionel kommandolinje (CLI), som er n\u00f8dvendig i implementationsfasen eller i tilf\u00e6lde af en n\u00f8dsituation for lokal diagnosticering. I normal drift (n\u00e5r der er en signalforbindelse mellem komponenterne) er kommandolinjen kun tilg\u00e6ngelig for diagnosticering p\u00e5 routerne og kan ikke bruges til at foretage lokale \u00e6ndringer, hvilket sikrer b\u00e5de lokal sikkerhed og en enkelt kilde til \u00e6ndringer i et s\u00e5dant netv\u00e6rk \u2013 vManage.<\/li>\n<\/ul>\n
\nIntegreret sikkerhed<\/b> \u2013 her drejer det sig ikke kun om beskyttelse af brugerdata under transmission over \u00e5bne kanaler, men ogs\u00e5 om den generelle sikkerhed i WAN-netv\u00e6rket baseret p\u00e5 den valgte teknologi.<\/p>\n\ni DMVPN\/PfR<\/b> muligg\u00f8r kryptering af brugerdata og signalprotokoller. Ved brug af bestemte routermodeller er funktioner til firewall med trafikinspektion, IPS\/IDS tilg\u00e6ngelige. Der er mulighed for segmentering af filialnetv\u00e6rk ved hj\u00e6lp af VRF. Der er ogs\u00e5 mulighed for autentificering (en-faktor) af kontrolprotokoller.\n Her betragtes routeren som standard som en betroet enhed i netv\u00e6rket \u2013 dvs. tilf\u00e6lde af fysisk kompromittering af enkelte enheder og ulempen ved uautoriseret adgang tages ikke i betragtning, der er ingen to-faktor autentificering af komponenterne i l\u00f8sningen, hvilket i tilf\u00e6lde af et geografisk distribueret netv\u00e6rk kan indeb\u00e6re alvorlige ekstra risici.<\/b> <\/li>\ni SD-WAN<\/b> Tilsvarende med DMVPN er der mulighed for kryptering af brugerdata, men med v\u00e6sentligt udvidede funktioner til netv\u00e6rkssikkerhed og L3\/VRF-segmentering (MAC, IPS\/IDS, URL-filtrering, DNS-filtrering, AMP\/TG, SASE, TLS\/SSL-proxy osv.). Her sker udveksling af krypteringsn\u00f8gler mere effektivt gennem vSmart controllere (i stedet for direkte), over foruddefinerede signalforbindelser, beskyttet af DTLS\/TLS-kryptering baseret p\u00e5 sikkerhedscertifikater. Dette sikrer sikkerheden af s\u00e5dan udveksling og muligg\u00f8r bedre skalerbarhed af l\u00f8sningen op til titusinder af enheder i et enkelt netv\u00e6rk.\n Alle signalforbindelser (controller-controller, controller-router) er ogs\u00e5 beskyttet baseret p\u00e5 DTLS\/TLS. Routere er udstyret med sikkerhedscertifikater ved fremstillingen med mulighed for udskiftning\/forl\u00e6ngelse. To-faktor-autentifikation opn\u00e5s ved at kr\u00e6ve, at to betingelser skal v\u00e6re opfyldt samtidig for at muligg\u00f8re funktionen af router\/controller i et SD-WAN netv\u00e6rk:<\/p>\n
\nGyldigt sikkerhedscertifikat<\/li>\n Det eksplicitte og bevidste tilf\u00f8jelse af hver komponent til administratorens 'hvide' liste over tilladte enheder.<\/li>\n<\/ul>\n\n<\/li>\n<\/ul>\n
Funktionelle forskelle mellem SD-WAN og DMVPN\/PfR<\/h2>\n \nN\u00e5r vi g\u00e5r videre til diskussionen om funktionelle forskelle, er det vigtigt at bem\u00e6rke, at mange af dem er en forts\u00e6ttelse af de arkitektoniske \u2014 det er ingen hemmelighed, at n\u00e5r man former arkitekturen af l\u00f8sningen, bygger udviklerne p\u00e5 de muligheder, de \u00f8nsker at opn\u00e5 i sidste ende. Lad os se n\u00e6rmere p\u00e5 de mest betydningsfulde forskelle mellem de to teknologier.<\/p>\n
AppQ (Application Quality) \u2013 funktioner til at sikre kvaliteten af dataoverf\u00f8rsel for forretningsapplikationer<\/h3>\n \nDe centrale funktioner for de betragtede teknologier er rettet mod at forbedre brugeroplevelsen ved brugen af forretningskritiske applikationer i et distribueret netv\u00e6rk, s\u00e5 meget som muligt. Dette er s\u00e6rligt vigtigt i situationer, hvor dele af infrastrukturen ikke kontrolleres af IT eller endda ikke garanterer succesfuld dataoverf\u00f8rsel.<\/p>\n
DMVPN tilbyder ikke s\u00e5danne mekanismer af sig selv. Det bedste, der kan g\u00f8res i et klassisk DMVPN-netv\u00e6rk, er at klassificere den udg\u00e5ende trafik baseret p\u00e5 applikationer og prioritere den ved transmission mod WAN-kanalen. Valget af DMVPN-tunnel er i dette tilf\u00e6lde kun baseret p\u00e5 dens tilg\u00e6ngelighed og output fra routingprotokollerne. Her tages der ikke hensyn til den samlede tilstand af stien\/tunnelen og dens mulige delvise degradering med hensyn til n\u00f8glemetrikker, der er betydningsfulde for netv\u00e6rksapplikationer - forsinkelse, varians i forsinkelse (jitter) og tab (%). Derfor mister det enhver mening at sammenligne klassisk DMVPN med SD-WAN i forhold til at l\u00f8se AppQ-opgaver \u2013 DMVPN kan ikke l\u00f8se denne opgave. N\u00e5r Cisco Performance Routing (PfR) tilf\u00f8jes til denne kontekst, \u00e6ndres situationen, og sammenligningen med Cisco SD-WAN bliver mere meningsfuld. <\/p>\n
Inden vi g\u00e5r videre til diskussionen om forskellene, lad os kort se p\u00e5, hvordan teknologierne ligner hinanden. S\u00e5 begge teknologier:<\/p>\n
\nhar en mekanisme, der g\u00f8r det muligt dynamisk at vurdere tilstanden af hver installeret tunnel baseret p\u00e5 bestemte metrikker \u2013 mindst forsinkelse, varians i forsinkelse og tab af pakker (%).<\/li>\n bruger et bestemt s\u00e6t v\u00e6rkt\u00f8jer til at oprette, distribuere og anvende regler (politikker) for trafikstyring i henhold til resultatet af m\u00e5lingerne af de n\u00f8glemetrikker for tunnelerne.<\/li>\n klassificerer applikationstrafik p\u00e5 niveauer L3-L4 (DSCP) i OSI-modellen eller ved hj\u00e6lp af L7-signaturer for applikationer baseret p\u00e5 indbyggede DPI-mekanismer i routeren.<\/li>\n giver mulighed for at fastl\u00e6gge acceptable t\u00e6rskelv\u00e6rdier for metrikker for betydningsfulde applikationer, standard trafikoverf\u00f8rselsregler og regler for omdirigering af trafik, n\u00e5r t\u00e6rskelv\u00e6rdierne overskrides.<\/li>\n ved indkapsling af trafik i GRE\/IPSec anvender en veletableret mekanisme i branchen for at overf\u00f8re intern DSCP-m\u00e6rkning til den eksterne GRE\/IPSec-pakkeheader, hvilket g\u00f8r det muligt at synkronisere QoS-politikker for organisationen og telekommunikationsoperat\u00f8ren (ved passende SLA).<\/li>\n<\/ul>\n\n
Hvordan adskiller mekanismerne til evaluering af end-to-end metrikker sig mellem SD-WAN og DMVPN\/PfR?<\/h3>\n \nDMVPN\/PfR <\/b><\/p>\n\nTil vurdering af standardmetrikker for tunnelens tilstand anvendes b\u00e5de aktive og passive softwareensorer (Probes). Aktive \u2013 baseret p\u00e5 brugertrafik, passive simulerer s\u00e5dan trafik (ved frav\u00e6r). <\/li>\n Finjustering af timere og betingelser for at registrere forringelse er frav\u00e6rende \u2013 algoritmen er fast.<\/li>\n Derudover er der mulighed for at m\u00e5le den anvendte b\u00e5ndbredde i den udg\u00e5ende retning. Dette giver DMVPN\/PfR ekstra fleksibilitet i trafikstyringen.<\/li>\n Nogle PfR-mekanismer er afh\u00e6ngige af omvendt feedback i form af specielle TCA (Threshold Crossing Alert) beskeder, som skal sendes fra modtageren af trafikken til kilden, hvilket i sin tur foruds\u00e6tter, at tilstanden af de m\u00e5lte kanaler mindst skal v\u00e6re tilstr\u00e6kkelig til at sende s\u00e5danne TCA-beskeder. Dette er normalt ikke et problem, men kan selvf\u00f8lgelig ikke garanteres. <\/li>\n<\/ul>\n\nSD-WAN <\/b><\/p>\n\nTil tv\u00e6rg\u00e5ende evaluering af standard tunneltilstande anvendes BFD-protokollen i echo-tilstand. Her kr\u00e6ves der ikke speciel tilbagemelding i form af TCA eller lignende meddelelser - dom\u00e6ner forbundet med fejl opretholdes isoleret. Der er heller ikke behov for tilstedev\u00e6relse af brugertrafik for at vurdere tunnelens tilstand.<\/li>\n Der er mulighed for finjustering af BFD-timerne for at regulere hastigheden af aktivering og f\u00f8lsomheden af algoritmen i forhold til forringelser af kommunikationskanalen fra f\u00e5 sekunder til minutter.\n
P\u00e5 tidspunktet for artiklens skrivning er der kun \u00e9n BFD-session tilg\u00e6ngelig i hver tunnel. Potentielt set skaber dette en lavere granularitet ved analyse af tunnelens tilstand. I praksis kan dette blive en begr\u00e6nsning, kun hvis der bruges WAN-forbindelse baseret p\u00e5 MPLS L2\/L3 VPN med en aftalt QoS SLA - hvis DSCP-m\u00e6rkningen af BFD-trafikken (efter indkapsling i IPSec\/GRE) svarer til en h\u00f8jprioritetsk\u00f8 i operat\u00f8rens netv\u00e6rk, kan det p\u00e5virke n\u00f8jagtigheden og hastigheden af fordrings registrering for lavprioritets trafik. Der er dog mulighed for at \u00e6ndre BFD-standardm\u00e6rkningen for at mindske risikoen for s\u00e5danne situationer. I fremtidige versioner af Cisco SD-WAN forventes der mere finjustering af BFD samt muligheden for at k\u00f8re flere BFD-sessioner inden for en enkelt tunnel med individuelle DSCP-v\u00e6rdier (til forskellige applikationer).<\/li>\n BFD muligg\u00f8r ogs\u00e5 vurdering af den maksimale pakke st\u00f8rrelse, der kan overf\u00f8res gennem en given tunnel uden fragmentering. Dette giver SD-WAN mulighed for dynamisk at justere parametre som MTU og TCP MSS Justering for at maksimere udnyttelsen af den tilg\u00e6ngelige b\u00e5ndbredde p\u00e5 hver kanal.<\/li>\n I SD-WAN er der ogs\u00e5 mulighed for synkronisering af QoS med kommunikationsoperat\u00f8rer, ikke kun baseret p\u00e5 L3 DSCP-feltet, men ogs\u00e5 baseret p\u00e5 L2 CoS-v\u00e6rdier, som kan dannes automatisk i filialnetv\u00e6rket af specialiserede enheder - for eksempel IP-telefoner.<\/li>\n<\/ul>\n<\/p>\n
Hvordan adskiller mulighederne, m\u00e5derne at bestemme og anvende AppQ-politikker sig?<\/h3>\n <\/p>\n
Politikker for DMVPN\/PfR:<\/h4>\n <\/p>\n
\nDefineres p\u00e5 central filialruter (CF) gennem CLI-kommandoen eller CLI-skabeloner til konfiguration. Oprettelse af CLI-skabeloner kr\u00e6ver forberedelse og viden om politikkerens syntaks.\n
Defineres globalt uden mulighed for individuel tilpasning\/\u00e6ndring til kravene fra forskellige netv\u00e6rkssegmenter.<\/b><\/li>\nInteraktiv oprettelse af politikker i det grafiske interface er ikke tilg\u00e6ngeligt.<\/li>\n Overv\u00e5gning af \u00e6ndringer, arv, oprettelse af flere versioner af politikker til hurtig skift er ikke tilg\u00e6ngeligt.<\/li>\n Udbredes automatisk til routere i fjerntliggende filialer. I denne forbindelse anvendes de samme kommunikationskanaler som til overf\u00f8rsel af brugerdata. Hvis der ikke er forbindelse mellem hovedkontoret og den fjerntliggende filial, er udbredelse\/\u00e6ndring af politikker ikke muligt.<\/li>\n Anvendes p\u00e5 hver router og modificerer resultatet af de standard rutingprotokoller, n\u00e5r det er n\u00f8dvendigt, med h\u00f8jere prioritet. <\/li>\n I tilf\u00e6lde hvor alle WAN-kanaler i filialen oplever betydelige tab af trafik, er der ikke forudset nogen kompensationsmekanismer<\/b>.<\/li>\n<\/ul>\n <\/p>\n
SD-WAN politikker:<\/h4>\n <\/p>\n
\nDefineres i det grafiske interface vManage via en interaktiv skabelonassistent.<\/li>\n Underst\u00f8tter oprettelse af flere politikker, kopiering, arv, og skift mellem politikker i realtid.<\/li>\n Underst\u00f8tter individuel tilpasning af politikker til forskellige segmenter (filialer) af netv\u00e6rket.<\/li>\n Udbredes ved hj\u00e6lp af enhver tilg\u00e6ngelig signal kanal mellem controlleren og routeren og\/eller vSmart \u2013 er ikke direkte afh\u00e6ngige af data-plane forbindelsen mellem routerne. Der kr\u00e6ves dog IP-forbindelse mellem selve routeren og controllerne.\n
I tilf\u00e6lde hvor alle tilg\u00e6ngelige kanaler i filialen oplever betydelige tab af data, der overskrider de tilladte t\u00e6rskelv\u00e6rdier for kritiske applikationer, kan der anvendes yderligere mekanismer til at \u00f8ge p\u00e5lideligheden af overf\u00f8rslen:\n\nFEC (Forward Error Correction)<\/b> \u2013 bruger en special algoritme til redundanskodning. Ved overf\u00f8rsel af kritisk trafik over kanaler med en betydelig procentdel af tab, kan FEC aktiveres automatisk og muligg\u00f8re gendannelse af tabte dele af dataene, hvis n\u00f8dvendigt. Dette \u00f8ger dog lidt den anvendte b\u00e5ndbredde, men v\u00e6sentligt p\u00e5lideligheden.\n
Duplicering af datastreams<\/b> \u2013 ud over FEC-politikken kan der v\u00e6re automatiseret duplikering af trafik fra de valgte applikationer i tilf\u00e6lde af et endnu alvorligere tab, der ikke kan kompenseres ved hj\u00e6lp af FEC. I s\u00e5 fald vil de udvalgte data blive sendt gennem alle tunneler til den modtagende filial med efterf\u00f8lgende deduplicering (fjernelse af overfl\u00f8dige kopier af pakker). Denne mekanisme \u00f8ger markant udnyttelsen af kanalerne, men \u00f8ger ogs\u00e5 v\u00e6sentligt p\u00e5lideligheden af transmissionen.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n <\/p>\n
Funktionerne i Cisco SD-WAN, uden direkte analoge i DMVPN\/PfR<\/h3>\n \nArkitekturen af Cisco SD-WAN-l\u00f8sningen muligg\u00f8r i nogle tilf\u00e6lde funktioner, hvis implementering i DMVPN\/PfR er enten ekstremt vanskelig eller ikke omkostningseffektiv p\u00e5 grund af de n\u00f8dvendige ressourcer, eller som slet ikke er mulig. Lad os se n\u00e6rmere p\u00e5 de mest interessante af dem:<\/p>\n
Traffic-Engineering (TE)<\/h4>\n \nTE omfatter mekanismer, der g\u00f8r det muligt at aflede trafik fra den standardvej, der dannes af routingprotokoller. TE bruges ofte til at sikre h\u00f8j tilg\u00e6ngelighed af netv\u00e6rkstjenester ved hurtigt og\/eller p\u00e5 forh\u00e5nd at kunne omdirigere vigtig trafik til en alternativ (ikke-overlappende) transmissionsvej for at forbedre servicekvaliteten eller hastigheden for genopretning i tilf\u00e6lde af fejl p\u00e5 den prim\u00e6re vej. <\/p>\n
Udfordringen ved implementering af TE ligger i n\u00f8dvendigheden af p\u00e5 forh\u00e5nd at beregne og reservere (kontrollere) en alternativ rute. I MPLS-netv\u00e6rk for telekommunikationsoperat\u00f8rer l\u00f8ses denne opgave ved hj\u00e6lp af teknologier som MPLS Traffic-Engineering med udvidelser af IGP-protokoller og RSVP-protokoller. Desuden vinder Segment Routing-teknologien i stigende grad popularitet, da den er mere optimeret til centraliseret konfiguration og orkestrering. I klassiske WAN-netv\u00e6rk er disse teknologier generelt ikke til stede eller reduceret til brugen af hop-by-hop mekanismer som Policy-Based Routing (PBR), som kan dirigere trafik, men implementerer dette p\u00e5 hver router individuelt \u2013 uden hensyntagen til netv\u00e6rkets samlede tilstand eller resultatet af PBR p\u00e5 forrige eller efterf\u00f8lgende trin. Resultatet af anvendelsen af disse TE-alternativer er skuffende \u2013 MPLS TE anvendes p\u00e5 grund af kompleksiteten ved ops\u00e6tning og drift, generelt kun i den mest kritiske del af netv\u00e6rket (kernen), mens PBR anvendes p\u00e5 enkelte routere uden mulighed for at danne en samlet PBR-politik p\u00e5 hele netv\u00e6rket. Dette g\u00e6lder liges\u00e5 for netv\u00e6rk baseret p\u00e5 DMVPN.<\/p>\n
Service-chaining <\/h4>\n \nAt danne service k\u00e6der er det endnu en mere arbejdskr\u00e6vende opgave i klassisk routing end den allerede beskrevede Traffic-Engineering mekanisme. I dette tilf\u00e6lde skal der ikke blot dannes en s\u00e6rlig rute for en bestemt netv\u00e6rksapplikation, men der skal ogs\u00e5 sikres mulighed for at lede trafik ud af netv\u00e6rket p\u00e5 bestemte (eller alle) knudepunkter i SD-WAN-netv\u00e6rket til behandling af en s\u00e6rlig applikation eller tjeneste (MSE, Balancering, Cache, Trafikinspektion, osv.). Samtidig er der behov for at kunne kontrollere status for disse eksterne tjenester for at undg\u00e5 situationer med black-holing, samt mekanismer der muligg\u00f8r at placere s\u00e5danne ensartede eksterne tjenester i forskellige geo-lokationer med mulighed for at netv\u00e6rket automatisk v\u00e6lger den mest optimale service knude til behandling af trafik fra en given filial. I tilf\u00e6ldet med Cisco SD-WAN er det ret let at opn\u00e5 ved at skabe en tilsvarende centraliseret politik, der 'samler' alle aspekter af den \u00f8nskede service k\u00e6de til en helhed og automatisk \u00e6ndrer logikken for data-plane og control-plane pr\u00e6cis der og da, hvor det er n\u00f8dvendigt.<\/p>\n
Hvad ender vi med?<\/h2>\n \nDet er tydeligt, at b\u00e5de DMVPN (sammen med eller uden Performance Routing) og Cisco SD-WAN i sidste ende l\u00f8ser meget lignende opgaver<\/b> i forhold til organisationens distribuerede WAN-netv\u00e6rk. I denne forbindelse bringer de v\u00e6sentlige arkitektoniske og funktionelle forskelle mellem Cisco SD-WAN teknologi processen til at l\u00f8se disse opgaver op p\u00e5 et andet kvalitetsniveau<\/b>. Sammenfattende kan man bem\u00e6rke f\u00f8lgende betydelige forskelle mellem SD-WAN og DMVPN\/PfR teknologier:<\/p>\n\nDMVPN\/PfR bruger generelt velafpr\u00f8vede teknologier til opbygning af overlay VPN-netv\u00e6rk og ligner p\u00e5 data-plan niveau den mere moderne SD-WAN teknologi. Der er dog visse begr\u00e6nsninger, herunder den obligatoriske statiske konfiguration af routere og et begr\u00e6nset valg af topologier, der kun inkluderer Hub-n-Spoke. P\u00e5 den anden side har DMVPN\/PfR nogle funktionelle muligheder, som stadig ikke er tilg\u00e6ngelige inden for SD-WAN (herunder per-application BFD).<\/li>\n N\u00e5r det kommer til control-plane teknologier, er der grundl\u00e6ggende forskelle. Med den centraliserede behandling af signalprotokoller muligg\u00f8r SD-WAN blandt andet en betydelig indsn\u00e6vring af fejlm\u00e6rker og \u2018frig\u00f8r\u2019 brugertrafik fra signalinteraktionen \u2013 midlertidig utilg\u00e6ngelighed af controllere p\u00e5virker ikke muligheden for at overf\u00f8re brugertrafik. Samtidig p\u00e5virker midlertidig utilg\u00e6ngelighed af en hvilken som helst filial (herunder centrale) ikke muligheden for \u00f8vrige filialer at interagere med hinanden og med controllere.<\/li>\n Arkitekturen for opbygning og anvendelse af trafikstyringspolitikker i SD-WAN overg\u00e5r ogs\u00e5 den i DMVPN\/PfR \u2013 geo-redundans er v\u00e6sentligt bedre implementeret, der er ingen binding til en Hub, og der er flere muligheder for finjustering af politikker. Listen over implementerede trafikstyringsscenarier er ogs\u00e5 betydeligt st\u00f8rre.<\/li>\n Processen for orkestrering af l\u00f8sningen adskiller sig ogs\u00e5 v\u00e6sentligt. DMVPN foruds\u00e6tter, at der er kendte parametre, der p\u00e5 en eller anden m\u00e5de skal afspejles i konfigurationen, hvilket begr\u00e6nser fleksibiliteten i l\u00f8sningen og mulighederne for dynamiske \u00e6ndringer. SD-WAN tager derimod udgangspunkt i den id\u00e9, at routeren i starten ikke \u2018ved noget\u2019 om sine controllere, men ved \u2018hvem den kan sp\u00f8rge\u2019 \u2013 dette er tilstr\u00e6kkeligt til automatisk at etablere forbindelse til controllere og til automatisk at danne en fuldt sammenkoblet data-plane topologi, som derefter kan justeres\/\u00e6ndres fleksibelt ved hj\u00e6lp af politikker.<\/li>\n I forhold til centraliseret styring, automatisering og overv\u00e5gning overg\u00e5r SD-WAN forventeligt mulighederne i DMVPN\/PfR, som er resultatet af udviklingen af klassiske teknologier og i h\u00f8jere grad afh\u00e6nger af kommandolinjen CLI og anvendelsen af NMS-systemer baseret p\u00e5 skabeloner. <\/li>\n I SD-WAN sammenlignet med DMVPN er sikkerhedskravene steget til et andet kvalitetsniveau. Hovedprincipperne er nul tillid, skalerbarhed og tofaktorgodkendelse.<\/li>\n<\/ul>\n\nUd fra disse enkle konklusioner kan man f\u00e5 det indtryk, at oprettelse af et netv\u00e6rk baseret p\u00e5 DMVPN\/PfR i dag har mistet al relevans. Det er dog ikke helt rigtigt. For eksempel, i tilf\u00e6lde hvor der i netv\u00e6rket anvendes meget for\u00e6ldet udstyr, og det ikke er muligt at erstatte det, kan DMVPN muligg\u00f8re integration af \"gamle\" og \"nye\" enheder til et samlet geo-spredt netv\u00e6rk med mange af de ovenfor beskrevne fordele.<\/p>\n
P\u00e5 den anden side skal man huske, at alle aktuelle virksomhedsroutere fra Cisco baseret p\u00e5 IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) i dag underst\u00f8tter enhver driftsform \u2013 b\u00e5de klassisk routing, DMVPN og SD-WAN \u2013 valget bestemmes af de aktuelle behov og forst\u00e5elsen af, at man n\u00e5r som helst p\u00e5 det samme udstyr kan begynde at bev\u00e6ge sig mod en mere avanceret teknologi.<\/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