Vil Cisco SD-WAN save den gren, som DMVPN sidder på?

Siden august 2017, da Cisco erhvervede Viptela, er den primære teknologi til etablering af distribuerede virksomhednetværk blevet Cisco SD-WAN. I de forgangne 3 år har SD-WAN-teknologien gennemgået mange ændringer, både kvalitativt og kvantitativt. Funktionaliteterne har udvidet sig betydeligt, og der er kommet støtte til de klassiske routere i serierne Cisco ISR 1000, ISR 4000, ASR 1000 og den virtuelle CSR 1000v. Samtidig stiller mange kunder og partnere hos Cisco stadig spørgsmålet – hvad er forskellene mellem Cisco SD-WAN og de mere kendte tilgange baseret på teknologier såsom Cisco DMVPN og Cisco Performance Routing og hvor vigtige er disse forskelle?

Her skal det straks nævnes, at før SD-WAN kom i Ciscos portefølje, udgjorde DMVPN i kombination med PfR en central del af arkitekturen Cisco IWAN (Intelligent WAN), som i sin tur var en forgænger til den fuldt udbyggede SD-WAN-teknologi. På trods af den overordnede lighed i både de opgaver, der løses, og metoderne til løsning af dem, fik IWAN aldrig det nødvendige niveau af automatisering, fleksibilitet og skalerbarhed for SD-WAN, og udviklingen af IWAN er med tiden blevet betydeligt reduceret. Samtidig er selve teknologierne, der udgør IWAN, ikke forsvundet, og mange kunder fortsætter med at bruge dem med succes, herunder på moderne udstyr. Resultatet er en interessant situation – det samme Cisco-udstyr giver mulighed for at vælge den mest passende teknologi til opbygning af WAN (klassisk, DMVPN+PfR eller SD-WAN) i overensstemmelse med kravene og forventningerne fra kunderne.

Artiklen har ikke til formål at gennemgå alle egenskaber ved teknologierne Cisco SD-WAN og DMVPN (sammen eller uden Performance Routing) i detaljer – der findes et væld af tilgængelige dokumenter og materialer til dette. Hovedopgaven er at forsøge at vurdere de vigtigste forskelle mellem disse teknologier. Men inden vi går videre til drøftelsen af disse forskelle, skal vi kort minde om teknologierne i sig selv.

Hvad er Cisco DMVPN, og hvorfor er det nødvendigt?

Cisco DMVPN løser opgaven med dynamisk (dvs. skalerbar) tilslutning af et fjernkontor til virksomhedens centrale netværk ved brug af forskellige typer af forbindelser, herunder internettet (dvs. med kryptering af forbindelsen). Tekniskt opnås dette ved at skabe et virtualiseret lag-3 overlay-netværk. VPN i point-to-multipoint-tilstand med en logisk topologi af typen "Stjerne" (Hub-n-Spoke). DMVPN anvender en kombination af følgende teknologier:

• IP-routing
• Multipoint GRE tunneler (mGRE)
• Next Hop Resolution Protocol (NHRP)
• IPSec Crypto-profiler

Hvad er de primære fordele ved Cisco DMVPN sammenlignet med klassisk routing ved brug af MPLS VPN-kanaler?

• Til opbygning af et interkontor-netværk kan der anvendes enhver kommunikationskanal – alt hvad der kan sikre IP-forbindelse mellem kontorerne, og samtidig vil trafikken blive krypteret (hvor det er nødvendigt) og balanceret (hvor det er muligt).
• Der oprettes automatisk en fuldt sammenhængende topologi mellem kontorerne. Herunder er der statiske tunneler mellem det centrale kontor og det fjerne kontor, mens der mellem de fjerne kontorer er dynamiske tunneler efter behov (ved trafiktilstedeværelse).
• På routerne i det centrale og fjerne kontor er konfigurationen ensartet med henblik på IP-adresser interfaces. Ved at bruge mGRE er der ingen behov for individuel konfiguration af dusinvis, hundreder eller endda tusinder af tunneler. Som følge heraf opnås en god skalerbarhed ved korrekt design.

Hvad er Cisco Performance Routing, og hvad er formålet?

Ved brug af DMVPN i interkontordelen er én meget vigtig opgave ikke løst – hvordan kan man dynamisk vurdere tilstanden af hver af DMVPN-tunnelerne med henblik på at opfylde kravene fra den kritiske trafik i vores organisation og igen basere dynamiske beslutninger om omruting på denne vurdering? Det er sådan, at DMVPN adskiller sig lidt fra klassisk routing – det bedste man kan gøre, er at indstille QoS-mekanismer, der tillader prioritering af trafik i udgående retning, men som ikke kan tage hensyn til tilstanden af hele vejen på et givet tidspunkt.

Og hvad skal man gøre, hvis en kanal delvist degraderes, og ikke helt – hvordan opdager og vurderer man dette? DMVPN kan ikke gøre dette alene. Da kanalerne, der forbinder filialer, kan gå igennem helt forskellige telekommunikationsoperatører, der anvender helt forskellige teknologier, bliver denne opgave ekstremt ikke-traditionel. Her kommer teknologien Cisco Performance Routing til hjælp, som på det tidspunkt allerede har gennemgået flere udviklingsfaser.

Opgaven for Cisco Performance Routing (herefter PfR) er at måle tilstanden af ​​veje (tunneler) for trafikgennemstrømning baseret på nøglemetrikker, som er vigtige for netværksapplikationer – forsinkelse, variation i forsinkelse (jitter) og pakketab (i procent). Derudover kan den anvendte båndbredde også måles. Disse målinger finder sted så tæt på realtid som muligt (så langt det er rimeligt) og resultatet af disse målinger gør det muligt for routeren, der anvender PfR, dynamisk at træffe beslutninger om, hvorvidt det er nødvendigt at ændre routing af en bestemt type trafik.

Således kan opgaven med at kombinere DMVPN/PfR kort karakteriseres som følger:

• Tillade kunden at bruge enhver kommunikationskanal på WAN-netværket
• Sikre det maksimalt mulige kvalitet af vigtige applikationer på disse kanaler

Hvad er Cisco SD-WAN?

Cisco SD-WAN er en teknologi, der bruger SDN-tilgangen til at skabe og drive organisationens WAN-netværk. Dette indebærer blandt andet brugen af såkaldte controllere (softwareenheder), der sikrer centraliseret orkestrering og automatiseret konfiguration af alle komponenter i løsningen. I modsætning til det klassiske SDN (i stil med Clean Slate) bruger Cisco SD-WAN straks flere typer controllere, hvor hver især udfører sin rolle – dette er gjort med vilje for at sikre bedre skalerbarhed og geo-redundans.

I tilfælde af SD-WAN bevares opgaven med at anvende enhver type kanaler og sikre driften af forretningsapplikationer, men kravene til automatisering, skalerbarhed, sikkerhed og fleksibilitet i netværket udvides.

Diskussion af forskelle

Hvis man nu begynder at analysere forskellene mellem disse teknologier, vil de falde ind under en af kategorierne:

• Arkitektoniske forskelle – hvordan er funktionerne fordelt blandt forskellige komponenter af løsningen, hvordan er interaktionen mellem disse komponenter organiseret, og hvordan påvirker dette teknologiens muligheder og fleksibilitet?
• Funktionelle muligheder – hvad kan én teknologi, som en anden ikke kan? Og er det virkelig så vigtigt?

Hvad er de arkitektoniske forskelle, og er de så vigtige?

Hver af de nævnte teknologier har mange 'bevægelige dele', som har både forskellige roller og interaktionsprincipper. Hvor gennemtænkte disse principper er, afhænger direkte af løsningens skalerbarhed, fejltolerance og samlede effektivitet.

Lad os se nærmere på forskellige aspekter af arkitekturen:

Data-plane – den del af løsningen, der er ansvarlig for transmission af brugertrafik mellem kilden og modtageren. I DMVPN og SD-WAN implementeres det stort set ens på selve routerne via Multipoint GRE-tunneler. Forskellen ligger i, hvordan det nødvendige sæt af parametre for disse tunneler dannes:

• i DMVPN/PfR – det er en udelukkende to-niveau hierarki af noder med en 'Stjerne'-topologi eller Hub-n-Spoke. Statisk opsætning af Hub og statisk binding af Spoke til Hub er obligatorisk, samt interaktion via NHRP-protokollen for at danne data-plane forbindelser. Som følge af dette, bliver ændringer på Hub betydeligt vanskeligere, relateret til f.eks. ændring/tilslutning af nye WAN-kanaler eller ændring af parametre for eksisterende.
• i SD-WAN – det er en fuldstændig dynamisk model for opdagelse af parametrene for oprettede tunneler, baseret på control-plane (OMP-protokollen) og orchestration-plane (interaktion med vBond-controlleren til opgaver såsom opdagelse af controllere og NAT traversal). De pålagte topologier kan være enhver, inklusive hierarkiske. Inden for den etablerede pålagte topologi af tunneler er det muligt med fleksibel konfiguration af den logiske topologi i hver enkelt VPN (VRF).

Control-plane – funktioner til udveksling, filtrering og modifikation af rute- og anden information mellem komponenterne i løsningen.

• i DMVPN/PfR – sker kun mellem Hub- og Spoke-routere. Direkte udveksling af ruteinformation mellem Spoke er ikke muligt. Som følge af dette, kan control-plane og data-plane ikke fungere uden en aktiv Hub., hvilket pålægger Hub ekstra krav til høj tilgængelighed, som ikke altid kan opfyldes.
• i SD-WAN – kontrolplanet udføres aldrig direkte mellem routere – interaktionen sker på basis af OMP-protokollen og skal ske gennem en særskilt specialiseret type controller vSmart, hvilket muliggør belastningsbalancering, geo-redundans og centraliseret håndtering af signalbelastningen. En anden funktion ved OMP-protokollen er dens betydelige modstandsdygtighed over for tab og uafhængighed af hastigheden af forbindelseskanalen til kontrolenhederne (inden for rimelige grænser, selvfølgelig). Dette gør det ligeså muligt at placere SD-WAN-controllere i offentlige eller private skyer med adgang via internettet.

Policy-plane – den del af løsningen, der er ansvarlig for definition, distribution og implementering af trafikstyringspolitikker i det distribuerede netværk.

• DMVPN – er reelt begrænset af kvaliteten af servicepolitikker (QoS), der kan konfigureres individuelt på hver router via CLI eller Prime Infrastructure-skabeloner.
• DMVPN/PfR – PfR-politikker skabes på 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ætter, at der er IP-forbindelse mellem Hub og Spoke. Hertil kan MC-funktionen om nødvendigt kombineres med DMVPN-routeren. Anvendelse af Prime Infrastructure-skabeloner til centraliseret oprettelse af politikker er muligt (men ikke påkrævet). En vigtig funktion er, at politikken skabes globalt på hele netværket ensartet – individuelle politikker for separate segmenter understøttes ikke..
• SD-WAN – trafikstyrings- og kvalitetsstyringspolitikker defineres centralt via grafisk brugergrænseflade Cisco vManage, der også er tilgængelig over internettet (om nødvendigt). De distribueres over signalveje direkte eller indirekte gennem vSmart controllere (afhængig af politiktype). De er uafhængige af data-plane forbindelsen mellem routerne, da de bruger alle tilgængelige transmissionsveje mellem controllere og routere.

  For forskellige netværkssegmenter er det muligt at danne fleksible politikker – anvendelsesområdet for politikken defineres af mange unikke identifikatorer, der er tilvejebragt i løsningen – filialnummer, applikationstype, trafikretning mv.

Orchestration-plane – mekanismer der gør det muligt for komponenterne at opdage hinanden dynamisk, konfigurere og koordinere efterfølgende interaktion.

• i DMVPN/PfR Det gensidige opdagelse mellem routerne er baseret på statisk konfiguration af Hub-enheder og tilsvarende opsætning af Spoke-enheder. Dynamisk opdagelse sker kun for Spoke, som informerer Hub-enheden om sine forbindelsesparametre, som på forhånd er indført i Spoke's konfiguration. Uden IP-forbindelse mellem Spoke og mindst én Hub er det umuligt at danne hverken data-plane eller control-plane.
• i SD-WAN Orkestreringen af komponenterne i løsningen foregår ved hjælp af controlleren vBond, som hver komponent (routere og controllere vManage/vSmart) skal have en IP-forbindelse til på forhånd.

  Oprindeligt kender komponenterne ikke til hinandens forbindelsesparametre – 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ør automatisk etablering af alle nødvendige signalforbindelser.

  Næste skridt vil den nye router lære om de øvrige routingssystemer i netværket via OMP-udveksling med vSmart-controlleren. På den måde kan routeren, uden at vide noget om netværksparametrene fra starten, automatisk opdage og oprette forbindelse til controllerne og derefter også automatisk opdage og danne forbindelser til de øvrige routingssystemer. I denne forbindelse er tilslutningsparametrene for alle komponenter oprindeligt ukendte og kan ændre sig under drift.

Management-plane – den del af løsningen, der sikrer centraliseret styring og overvågning.

• DMVPN/PfR – der er ikke forudset nogen specialiseret management-plane løsning. For grundlæggende automatisering og overvågning kan produkter som Cisco Prime Infrastructure anvendes. Hver router har mulighed for at styres via kommandolinjegrænsefladen CLI. Integrationer med eksterne systemer via API er ikke forudset.
• SD-WAN – al standard interaktion og overvågning foregår centraliseret gennem den grafiske interface på vManage-controlleren. Alle løsninger, uden undtagelse, kan konfigureres via vManage samt gennem et fuldt dokumenteret REST API.

  Alle indstillinger for SD-WAN-netværket i vManage reduceres til to hovedkonstruktioner – oprettelse af enheds skabeloner (Device Template) og formulering af politikker, som bestemmer netværkets logik og trafikbehandling. vManage vælger automatisk, hvilken ændringer og på hvilke individuelle enheder/controller der skal foretages, når den administratormdefinerede politik transmitteres, hvilket væsentligt øger løsningen effektivitet og skalerbarhed.

  Gennem vManage-interfacet er der ikke kun mulighed for at konfigurere Cisco SD-WAN-løsningen, men også en fuld overvågning af tilstanden for alle komponenter i løsningen, alt fra den aktuelle tilstand af metrikker for individuelle tunneller til statistikker over brugen af forskellige applikationer baseret på DPI-analyse.

  På trods af centraliseringen af interaktionen har alle komponenter (controllere og routere) også en fuldt funktionel kommandolinje (CLI), som er nødvendig i implementationsfasen eller i tilfælde af en nødsituation for lokal diagnosticering. I normal drift (når der er en signalforbindelse mellem komponenterne) er kommandolinjen kun tilgængelig for diagnosticering på routerne og kan ikke bruges til at foretage lokale ændringer, hvilket sikrer både lokal sikkerhed og en enkelt kilde til ændringer i et sådant netværk – vManage.

Integreret sikkerhed – her drejer det sig ikke kun om beskyttelse af brugerdata under transmission over åbne kanaler, men også om den generelle sikkerhed i WAN-netværket baseret på den valgte teknologi.

• i DMVPN/PfR muliggør kryptering af brugerdata og signalprotokoller. Ved brug af bestemte routermodeller er funktioner til firewall med trafikinspektion, IPS/IDS tilgængelige. Der er mulighed for segmentering af filialnetværk ved hjælp af VRF. Der er også mulighed for autentificering (en-faktor) af kontrolprotokoller.

  Her betragtes routeren som standard som en betroet enhed i netværket – dvs. tilfælde 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øsningen, hvilket i tilfælde af et geografisk distribueret netværk kan indebære alvorlige ekstra risici.

• i SD-WAN Tilsvarende med DMVPN er der mulighed for kryptering af brugerdata, men med væsentligt udvidede funktioner til netværkssikkerhed og L3/VRF-segmentering (MAC, IPS/IDS, URL-filtrering, DNS-filtrering, AMP/TG, SASE, TLS/SSL-proxy osv.). Her sker udveksling af krypteringsnøgler mere effektivt gennem vSmart controllere (i stedet for direkte), over foruddefinerede signalforbindelser, beskyttet af DTLS/TLS-kryptering baseret på sikkerhedscertifikater. Dette sikrer sikkerheden af sådan udveksling og muliggør bedre skalerbarhed af løsningen op til titusinder af enheder i et enkelt netværk.

  Alle signalforbindelser (controller-controller, controller-router) er også beskyttet baseret på DTLS/TLS. Routere er udstyret med sikkerhedscertifikater ved fremstillingen med mulighed for udskiftning/forlængelse. To-faktor-autentifikation opnås ved at kræve, at to betingelser skal være opfyldt samtidig for at muliggøre funktionen af router/controller i et SD-WAN netværk:

  • Gyldigt sikkerhedscertifikat
  • Det eksplicitte og bevidste tilføjelse af hver komponent til administratorens 'hvide' liste over tilladte enheder.

Funktionelle forskelle mellem SD-WAN og DMVPN/PfR

Når vi går videre til diskussionen om funktionelle forskelle, er det vigtigt at bemærke, at mange af dem er en fortsættelse af de arkitektoniske — det er ingen hemmelighed, at når man former arkitekturen af løsningen, bygger udviklerne på de muligheder, de ønsker at opnå i sidste ende. Lad os se nærmere på de mest betydningsfulde forskelle mellem de to teknologier.

AppQ (Application Quality) – funktioner til at sikre kvaliteten af dataoverførsel for forretningsapplikationer

De centrale funktioner for de betragtede teknologier er rettet mod at forbedre brugeroplevelsen ved brugen af forretningskritiske applikationer i et distribueret netværk, så meget som muligt. Dette er særligt vigtigt i situationer, hvor dele af infrastrukturen ikke kontrolleres af IT eller endda ikke garanterer succesfuld dataoverførsel.

DMVPN tilbyder ikke sådanne mekanismer af sig selv. Det bedste, der kan gøres i et klassisk DMVPN-netværk, er at klassificere den udgående trafik baseret på applikationer og prioritere den ved transmission mod WAN-kanalen. Valget af DMVPN-tunnel er i dette tilfælde kun baseret på dens tilgængelighed 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øglemetrikker, der er betydningsfulde for netværksapplikationer - forsinkelse, varians i forsinkelse (jitter) og tab (%). Derfor mister det enhver mening at sammenligne klassisk DMVPN med SD-WAN i forhold til at løse AppQ-opgaver – DMVPN kan ikke løse denne opgave. Når Cisco Performance Routing (PfR) tilføjes til denne kontekst, ændres situationen, og sammenligningen med Cisco SD-WAN bliver mere meningsfuld.

Inden vi går videre til diskussionen om forskellene, lad os kort se på, hvordan teknologierne ligner hinanden. Så begge teknologier:

• har en mekanisme, der gør det muligt dynamisk at vurdere tilstanden af hver installeret tunnel baseret på bestemte metrikker – mindst forsinkelse, varians i forsinkelse og tab af pakker (%).
• bruger et bestemt sæt værktøjer til at oprette, distribuere og anvende regler (politikker) for trafikstyring i henhold til resultatet af målingerne af de nøglemetrikker for tunnelerne.
• klassificerer applikationstrafik på niveauer L3-L4 (DSCP) i OSI-modellen eller ved hjælp af L7-signaturer for applikationer baseret på indbyggede DPI-mekanismer i routeren.
• giver mulighed for at fastlægge acceptable tærskelværdier for metrikker for betydningsfulde applikationer, standard trafikoverførselsregler og regler for omdirigering af trafik, når tærskelværdierne overskrides.
• ved indkapsling af trafik i GRE/IPSec anvender en veletableret mekanisme i branchen for at overføre intern DSCP-mærkning til den eksterne GRE/IPSec-pakkeheader, hvilket gør det muligt at synkronisere QoS-politikker for organisationen og telekommunikationsoperatøren (ved passende SLA).

Hvordan adskiller mekanismerne til evaluering af end-to-end metrikker sig mellem SD-WAN og DMVPN/PfR?

DMVPN/PfR

• Til vurdering af standardmetrikker for tunnelens tilstand anvendes både aktive og passive softwareensorer (Probes). Aktive – baseret på brugertrafik, passive simulerer sådan trafik (ved fravær).
• Finjustering af timere og betingelser for at registrere forringelse er fraværende – algoritmen er fast.
• Derudover er der mulighed for at måle den anvendte båndbredde i den udgående retning. Dette giver DMVPN/PfR ekstra fleksibilitet i trafikstyringen.
• Nogle PfR-mekanismer er afhængige 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ætter, at tilstanden af de målte kanaler mindst skal være tilstrækkelig til at sende sådanne TCA-beskeder. Dette er normalt ikke et problem, men kan selvfølgelig ikke garanteres.

SD-WAN

• Til tværgående evaluering af standard tunneltilstande anvendes BFD-protokollen i echo-tilstand. Her kræves der ikke speciel tilbagemelding i form af TCA eller lignende meddelelser - domæner forbundet med fejl opretholdes isoleret. Der er heller ikke behov for tilstedeværelse af brugertrafik for at vurdere tunnelens tilstand.
• Der er mulighed for finjustering af BFD-timerne for at regulere hastigheden af aktivering og følsomheden af algoritmen i forhold til forringelser af kommunikationskanalen fra få sekunder til minutter.

  

• På tidspunktet for artiklens skrivning er der kun én BFD-session tilgængelig i hver tunnel. Potentielt set skaber dette en lavere granularitet ved analyse af tunnelens tilstand. I praksis kan dette blive en begrænsning, kun hvis der bruges WAN-forbindelse baseret på MPLS L2/L3 VPN med en aftalt QoS SLA - hvis DSCP-mærkningen af BFD-trafikken (efter indkapsling i IPSec/GRE) svarer til en højprioritetskø i operatørens netværk, kan det påvirke nøjagtigheden og hastigheden af fordrings registrering for lavprioritets trafik. Der er dog mulighed for at ændre BFD-standardmærkningen for at mindske risikoen for sådanne situationer. I fremtidige versioner af Cisco SD-WAN forventes der mere finjustering af BFD samt muligheden for at køre flere BFD-sessioner inden for en enkelt tunnel med individuelle DSCP-værdier (til forskellige applikationer).
• BFD muliggør også vurdering af den maksimale pakke størrelse, der kan overføres 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ængelige båndbredde på hver kanal.
• I SD-WAN er der også mulighed for synkronisering af QoS med kommunikationsoperatører, ikke kun baseret på L3 DSCP-feltet, men også baseret på L2 CoS-værdier, som kan dannes automatisk i filialnetværket af specialiserede enheder - for eksempel IP-telefoner.

Hvordan adskiller mulighederne, måderne at bestemme og anvende AppQ-politikker sig?

Politikker for DMVPN/PfR:

• Defineres på central filialruter (CF) gennem CLI-kommandoen eller CLI-skabeloner til konfiguration. Oprettelse af CLI-skabeloner kræver forberedelse og viden om politikkerens syntaks.

  

• Defineres globalt uden mulighed for individuel tilpasning/ændring til kravene fra forskellige netværkssegmenter.
• Interaktiv oprettelse af politikker i det grafiske interface er ikke tilgængeligt.
• Overvågning af ændringer, arv, oprettelse af flere versioner af politikker til hurtig skift er ikke tilgængeligt.
• Udbredes automatisk til routere i fjerntliggende filialer. I denne forbindelse anvendes de samme kommunikationskanaler som til overførsel af brugerdata. Hvis der ikke er forbindelse mellem hovedkontoret og den fjerntliggende filial, er udbredelse/ændring af politikker ikke muligt.
• Anvendes på hver router og modificerer resultatet af de standard rutingprotokoller, når det er nødvendigt, med højere prioritet.
• I tilfælde hvor alle WAN-kanaler i filialen oplever betydelige tab af trafik, er der ikke forudset nogen kompensationsmekanismer.

SD-WAN politikker:

• Defineres i det grafiske interface vManage via en interaktiv skabelonassistent.
• Understøtter oprettelse af flere politikker, kopiering, arv, og skift mellem politikker i realtid.
• Understøtter individuel tilpasning af politikker til forskellige segmenter (filialer) af netværket.
• Udbredes ved hjælp af enhver tilgængelig signal kanal mellem controlleren og routeren og/eller vSmart – er ikke direkte afhængige af data-plane forbindelsen mellem routerne. Der kræves dog IP-forbindelse mellem selve routeren og controllerne.

  

• I tilfælde hvor alle tilgængelige kanaler i filialen oplever betydelige tab af data, der overskrider de tilladte tærskelværdier for kritiske applikationer, kan der anvendes yderligere mekanismer til at øge pålideligheden af overførslen:
  • FEC (Forward Error Correction) – bruger en special algoritme til redundanskodning. Ved overførsel af kritisk trafik over kanaler med en betydelig procentdel af tab, kan FEC aktiveres automatisk og muliggøre gendannelse af tabte dele af dataene, hvis nødvendigt. Dette øger dog lidt den anvendte båndbredde, men væsentligt pålideligheden.

    

  • Duplicering af datastreams – ud over FEC-politikken kan der være automatiseret duplikering af trafik fra de valgte applikationer i tilfælde af et endnu alvorligere tab, der ikke kan kompenseres ved hjælp af FEC. I så fald vil de udvalgte data blive sendt gennem alle tunneler til den modtagende filial med efterfølgende deduplicering (fjernelse af overflødige kopier af pakker). Denne mekanisme øger markant udnyttelsen af kanalerne, men øger også væsentligt pålideligheden af transmissionen.

Funktionerne i Cisco SD-WAN, uden direkte analoge i DMVPN/PfR

Arkitekturen af Cisco SD-WAN-løsningen muliggør i nogle tilfælde funktioner, hvis implementering i DMVPN/PfR er enten ekstremt vanskelig eller ikke omkostningseffektiv på grund af de nødvendige ressourcer, eller som slet ikke er mulig. Lad os se nærmere på de mest interessante af dem:

Traffic-Engineering (TE)

TE omfatter mekanismer, der gør det muligt at aflede trafik fra den standardvej, der dannes af routingprotokoller. TE bruges ofte til at sikre høj tilgængelighed af netværkstjenester ved hurtigt og/eller på forhånd at kunne omdirigere vigtig trafik til en alternativ (ikke-overlappende) transmissionsvej for at forbedre servicekvaliteten eller hastigheden for genopretning i tilfælde af fejl på den primære vej.

Udfordringen ved implementering af TE ligger i nødvendigheden af på forhånd at beregne og reservere (kontrollere) en alternativ rute. I MPLS-netværk for telekommunikationsoperatører løses denne opgave ved hjælp 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ærk 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å hver router individuelt – uden hensyntagen til netværkets samlede tilstand eller resultatet af PBR på forrige eller efterfølgende trin. Resultatet af anvendelsen af disse TE-alternativer er skuffende – MPLS TE anvendes på grund af kompleksiteten ved opsætning og drift, generelt kun i den mest kritiske del af netværket (kernen), mens PBR anvendes på enkelte routere uden mulighed for at danne en samlet PBR-politik på hele netværket. Dette gælder ligeså for netværk baseret på DMVPN.

SD-WAN tilbyder på denne måde en langt mere elegant løsning, som ikke kun er let at konfigurere, men også skalerer betydeligt bedre. Dette er et resultat af de anvendte arkitekturer for control-plane og policy-plane. Implementeringen af policy-plane i SD-WAN gør det muligt at definere politikker for TE centralt – hvilken trafik er interessant? for hvilke VPN? gennem hvilke noder/tunneler er det nødvendigt eller omvendt forbudt at danne en alternativ rute? På sin side muliggør centraliseringen af control-plane management baseret på vSmart-controllere at modificere resultaterne af ruteadministrationen uden at skulle justere individuelle enheder – routerne ser allerede kun resultatet af den logik, der er dannet i vManage-grænsefladen og sendt til anvendelse på vSmart.

Service-chaining

At danne service kæder er det endnu en mere arbejdskrævende opgave i klassisk routing end den allerede beskrevede Traffic-Engineering mekanisme. I dette tilfælde skal der ikke blot dannes en særlig rute for en bestemt netværksapplikation, men der skal også sikres mulighed for at lede trafik ud af netværket på bestemte (eller alle) knudepunkter i SD-WAN-netværket til behandling af en særlig applikation eller tjeneste (MSE, Balancering, Cache, Trafikinspektion, osv.). Samtidig er der behov for at kunne kontrollere status for disse eksterne tjenester for at undgå situationer med black-holing, samt mekanismer der muliggør at placere sådanne ensartede eksterne tjenester i forskellige geo-lokationer med mulighed for at netværket automatisk vælger den mest optimale service knude til behandling af trafik fra en given filial. I tilfældet med Cisco SD-WAN er det ret let at opnå ved at skabe en tilsvarende centraliseret politik, der 'samler' alle aspekter af den ønskede service kæde til en helhed og automatisk ændrer logikken for data-plane og control-plane præcis der og da, hvor det er nødvendigt.

Evnen til at danne geo-distribueret behandling af trafik for udvalgte typer applikationer i en bestemt rækkefølge på specialiseret (men ikke relateret til selve SD-WAN-netværket) udstyr – det er nok den mest illustrative demonstration af fordelene ved Cisco SD-WAN over klassiske teknologier og endda nogle alternative SD-WAN-løsninger fra andre producenter.

Hvad ender vi med?

Det er tydeligt, at både DMVPN (sammen med eller uden Performance Routing) og Cisco SD-WAN i sidste ende løser meget lignende opgaver i forhold til organisationens distribuerede WAN-netværk. I denne forbindelse bringer de væsentlige arkitektoniske og funktionelle forskelle mellem Cisco SD-WAN teknologi processen til at løse disse opgaver op på et andet kvalitetsniveau. Sammenfattende kan man bemærke følgende betydelige forskelle mellem SD-WAN og DMVPN/PfR teknologier:

• DMVPN/PfR bruger generelt velafprøvede teknologier til opbygning af overlay VPN-netværk og ligner på data-plan niveau den mere moderne SD-WAN teknologi. Der er dog visse begrænsninger, herunder den obligatoriske statiske konfiguration af routere og et begrænset valg af topologier, der kun inkluderer Hub-n-Spoke. På den anden side har DMVPN/PfR nogle funktionelle muligheder, som stadig ikke er tilgængelige inden for SD-WAN (herunder per-application BFD).
• Når det kommer til control-plane teknologier, er der grundlæggende forskelle. Med den centraliserede behandling af signalprotokoller muliggør SD-WAN blandt andet en betydelig indsnævring af fejlmærker og ‘frigør’ brugertrafik fra signalinteraktionen – midlertidig utilgængelighed af controllere påvirker ikke muligheden for at overføre brugertrafik. Samtidig påvirker midlertidig utilgængelighed af en hvilken som helst filial (herunder centrale) ikke muligheden for øvrige filialer at interagere med hinanden og med controllere.
• Arkitekturen for opbygning og anvendelse af trafikstyringspolitikker i SD-WAN overgår også den i DMVPN/PfR – geo-redundans er væsentligt bedre implementeret, der er ingen binding til en Hub, og der er flere muligheder for finjustering af politikker. Listen over implementerede trafikstyringsscenarier er også betydeligt større.
• Processen for orkestrering af løsningen adskiller sig også væsentligt. DMVPN forudsætter, at der er kendte parametre, der på en eller anden måde skal afspejles i konfigurationen, hvilket begrænser fleksibiliteten i løsningen og mulighederne for dynamiske ændringer. SD-WAN tager derimod udgangspunkt i den idé, at routeren i starten ikke ‘ved noget’ om sine controllere, men ved ‘hvem den kan spørge’ – dette er tilstrækkeligt til automatisk at etablere forbindelse til controllere og til automatisk at danne en fuldt sammenkoblet data-plane topologi, som derefter kan justeres/ændres fleksibelt ved hjælp af politikker.
• I forhold til centraliseret styring, automatisering og overvågning overgår SD-WAN forventeligt mulighederne i DMVPN/PfR, som er resultatet af udviklingen af klassiske teknologier og i højere grad afhænger af kommandolinjen CLI og anvendelsen af NMS-systemer baseret på skabeloner.
• I SD-WAN sammenlignet med DMVPN er sikkerhedskravene steget til et andet kvalitetsniveau. Hovedprincipperne er nul tillid, skalerbarhed og tofaktorgodkendelse.

Ud fra disse enkle konklusioner kan man få det indtryk, at oprettelse af et netværk baseret på DMVPN/PfR i dag har mistet al relevans. Det er dog ikke helt rigtigt. For eksempel, i tilfælde hvor der i netværket anvendes meget forældet udstyr, og det ikke er muligt at erstatte det, kan DMVPN muliggøre integration af "gamle" og "nye" enheder til et samlet geo-spredt netværk med mange af de ovenfor beskrevne fordele.

På den anden side skal man huske, at alle aktuelle virksomhedsroutere fra Cisco baseret på IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) i dag understøtter enhver driftsform – både klassisk routing, DMVPN og SD-WAN – valget bestemmes af de aktuelle behov og forståelsen af, at man når som helst på det samme udstyr kan begynde at bevæge sig mod en mere avanceret teknologi.

Kilde: habr.com