Vil Cisco SD-WAN afskære grenen, som DMVPN sidder på?

Siden august 2017, hvor Cisco købte Viptela, er den vigtigste teknologi, der tilbydes til at organisere distribuerede virksomhedsnetværk blevet Cisco SD-WAN. I løbet af de sidste 3 år har SD-WAN teknologien gennemgået mange ændringer, både kvalitative og kvantitative. Således er funktionaliteten udvidet betydeligt, og der er dukket support op på klassiske routere i serien Cisco ISR 1000, ISR 4000, ASR 1000 og Virtual CSR 1000v. Samtidig undrer mange Cisco-kunder og -partnere sig fortsat: hvad er forskellene mellem Cisco SD-WAN og allerede velkendte tilgange baseret på teknologier som f.eks Cisco DMVPN и Cisco Performance Routing og hvor vigtige er disse forskelle?

Her bør vi straks tage forbehold for, at før SD-WANs indtog i Cisco-porteføljen, udgjorde DMVPN sammen med PfR en central del i arkitekturen Cisco IWAN (Intelligent WAN), som igen var forløberen for fuldgyldig SD-WAN-teknologi. På trods af den generelle lighed mellem både de opgaver, der løses, og metoderne til at løse dem, fik IWAN aldrig det niveau af automatisering, fleksibilitet og skalerbarhed, der er nødvendigt for SD-WAN, og over tid er udviklingen af ​​IWAN faldet markant. Samtidig er teknologierne, der udgør IWAN, ikke forsvundet, og mange kunder fortsætter med at bruge dem med succes, også på moderne udstyr. Som et resultat er der opstået en interessant situation - det samme Cisco-udstyr giver dig mulighed for at vælge den bedst egnede WAN-teknologi (klassisk, DMVPN+PfR eller SD-WAN) i overensstemmelse med kundernes krav og forventninger.

Artiklen har ikke til hensigt at analysere i detaljer alle funktionerne i Cisco SD-WAN og DMVPN-teknologier (med eller uden Performance Routing) - der er en enorm mængde tilgængelige dokumenter og materialer til dette. Hovedopgaven er at forsøge at evaluere de vigtigste forskelle mellem disse teknologier. Men før vi går videre til at diskutere disse forskelle, lad os kort huske selve teknologierne.

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

Cisco DMVPN løser problemet med dynamisk (= skalerbar) forbindelse af et eksternt filialnetværk til netværket i en virksomheds hovedkontor ved brug af vilkårlige typer kommunikationskanaler, herunder internettet (= med kryptering af kommunikationskanalen). Teknisk realiseres dette ved at skabe et virtualiseret overlejringsnetværk af L3 VPN-klasse i punkt-til-multipunkt-tilstand med en logisk topologi af typen "Star" (Hub-n-Spoke). For at opnå dette bruger DMVPN en kombination af følgende teknologier:

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

Hvad er de vigtigste fordele ved Cisco DMVPN sammenlignet med klassisk routing ved hjælp af MPLS VPN-kanaler?

• For at skabe et tværgrenet netværk er det muligt at bruge alle kommunikationskanaler - alt, der kan give IP-forbindelse mellem filialer, er egnet, mens trafikken vil være krypteret (hvor det er nødvendigt) og balanceret (hvor det er muligt)
• En fuldt forbundet topologi mellem grene dannes automatisk. I dette tilfælde er der statiske tunneler mellem de centrale og fjerntliggende grene og dynamiske tunneler efter behov mellem de fjerne grene (hvis der er trafik)
• Routerne i den centrale og den eksterne gren har samme konfiguration op til grænsefladernes IP-adresser. Ved at bruge mGRE er der ingen grund til individuelt at konfigurere titusinder, hundreder eller endda tusindvis af tunneler. Som et resultat, anstændig skalerbarhed med det rigtige design.

Hvad er Cisco Performance Routing, og hvorfor er det nødvendigt?

Når du bruger DMVPN på et netværk, er et ekstremt vigtigt spørgsmål stadig uløst - hvordan man dynamisk vurderer tilstanden af ​​hver af DMVPN-tunnelerne for overholdelse af kravene til trafik, der er kritisk for vores organisation, og igen, baseret på en sådan vurdering, dynamisk foretager en beslutning om omlægning? Faktum er, at DMVPN i denne del adskiller sig lidt fra klassisk routing - det bedste, der kan gøres, er at konfigurere QoS-mekanismer, der giver dig mulighed for at prioritere trafik i den udgående retning, men som på ingen måde er i stand til at tage højde for tilstanden af hele vejen på et eller andet tidspunkt.

Og hvad skal man gøre, hvis kanalen nedbrydes delvist og ikke fuldstændigt - hvordan opdager og evaluerer man dette? DMVPN kan ikke selv gøre dette. I betragtning af, at kanalerne, der forbinder filialer, kan passere gennem helt forskellige teleoperatører ved hjælp af helt andre teknologier, bliver denne opgave ekstremt ikke-triviel. Og det er her Cisco Performance Routing-teknologien kommer til undsætning, som på det tidspunkt allerede havde gennemgået flere udviklingsstadier.

Opgaven for Cisco Performance Routing (herefter PfR) kommer ned til at måle tilstanden af ​​stier (tunneler) af trafik baseret på nøglemålinger, der er vigtige for netværksapplikationer - latens, latensvariation (jitter) og pakketab (procent). Derudover kan den brugte båndbredde måles. Disse målinger sker så tæt på realtid som muligt og berettiget, og resultatet af disse målinger gør det muligt for routeren, der bruger PfR, dynamisk at træffe beslutninger om behovet for at ændre ruten for denne eller hin type trafik.

Således kan DMVPN/PfR-kombinationens opgave kort beskrives som følger:

• Tillad kunden at bruge eventuelle kommunikationskanaler på WAN-netværket
• Sikre den højest mulige kvalitet af kritiske applikationer på disse kanaler

Hvad er Cisco SD-WAN?

Cisco SD-WAN er en teknologi, der bruger SDN-tilgangen til at skabe og drive en organisations WAN-netværk. Det betyder især brugen af ​​såkaldte controllere (softwareelementer), som sørger for centraliseret orkestrering og automatiseret konfiguration af alle løsningskomponenter. I modsætning til den kanoniske SDN (Clean Slate-stil) bruger Cisco SD-WAN flere typer controllere, som hver udfører sin egen rolle - dette blev gjort med vilje for at give bedre skalerbarhed og geo-redundans.

I tilfælde af SD-WAN forbliver opgaven med at bruge alle typer kanaler og sikre driften af ​​forretningsapplikationer den samme, men samtidig udvides kravene til automatisering, skalerbarhed, sikkerhed og fleksibilitet i et sådant netværk.

Diskussion af forskelle

Hvis vi nu begynder at analysere forskellene mellem disse teknologier, vil de falde i en af ​​følgende kategorier:

• Arkitektoniske forskelle - hvordan er funktioner fordelt på forskellige komponenter i løsningen, hvordan er samspillet mellem sådanne komponenter organiseret, og hvordan påvirker dette teknologiens muligheder og fleksibilitet?
• Funktionalitet – hvad kan én teknologi, som en anden ikke kan? Og er det virkelig så vigtigt?

Hvad er de arkitektoniske forskelle, og er de vigtige?

Hver af disse teknologier har mange "bevægelige dele", der adskiller sig ikke kun i deres roller, men også i, hvordan de interagerer med hinanden. Hvor godt disse principper er gennemtænkt og den generelle mekanik af løsningen bestemmer direkte dens skalerbarhed, fejltolerance og overordnede effektivitet.

Lad os se mere detaljeret på de forskellige aspekter af arkitekturen:

Data-plan – en del af løsningen, der er ansvarlig for at overføre brugertrafik mellem kilden og modtageren. DMVPN og SD-WAN implementeres generelt identisk på selve routerne baseret på Multipoint GRE-tunneler. Forskellen er, hvordan det nødvendige sæt af parametre for disse tunneler er dannet:

• в DMVPN/PfR er et udelukkende to-niveau hierarki af noder med en stjerne- eller Hub-n-Spoke topologi. Statisk konfiguration af Hub og statisk binding af Spoke til Hub er påkrævet, samt interaktion via NHRP-protokollen for at danne data-plan-forbindelse. Følgelig, gør ændringer i Hub væsentligt vanskeligererelateret til for eksempel ændring/tilslutning af nye WAN-kanaler eller ændring af parametre for eksisterende.
• в SD-WAN er en fuldt dynamisk model til detektering af parametre for installerede tunneler baseret på kontrolplan (OMP-protokol) og orkestreringsplan (interaktion med vBond-controlleren til controllerdetektion og NAT-gennemløbsopgaver). I dette tilfælde kan alle overlejrede topologier bruges, inklusive hierarkiske. Inden for den etablerede overlejringstunneltopologi er fleksibel konfiguration af den logiske topologi i hver enkelt VPN(VRF) mulig.

Kontrol-plan – funktioner til udveksling, filtrering og ændring af routing og anden information mellem løsningskomponenter.

• в DMVPN/PfR – udføres kun mellem Hub- og Spoke-routere. Direkte udveksling af ruteinformation mellem Spokes er ikke mulig. Følgelig, Uden en fungerende Hub kan kontrolplanet og dataplanet ikke fungere, som pålægger Hub'en yderligere høje tilgængelighedskrav, som ikke altid kan opfyldes.
• в SD-WAN – kontrolplan udføres aldrig direkte mellem routere – interaktion sker på basis af OMP-protokollen og udføres nødvendigvis gennem en separat specialiseret type vSmart-controller, som giver mulighed for balancering, georeservation og centraliseret kontrol af signalbelastning. Et andet træk ved OMP-protokollen er dens betydelige modstand mod tab og uafhængighed af kommunikationskanalens hastighed med controllere (naturligvis inden for rimelige grænser). Hvilket lige så vellykket giver dig mulighed for at placere SD-WAN-controllere i offentlige eller private skyer med adgang via internettet.

Politik-plan – en del af løsningen, der er ansvarlig for at definere, distribuere og anvende trafikstyringspolitikker på et distribueret netværk.

• DMVPN – er effektivt begrænset af kvalitetspolitikker (QoS) konfigureret individuelt på hver router via CLI- eller Prime Infrastructure-skabelonerne.
• DMVPN/PfR – PfR-politikker dannes på den centraliserede Master Controller (MC)-router via CLI og distribueres derefter automatisk til filial-MC'er. I dette tilfælde bruges de samme politikoverførselsstier som for dataplanet. Der er ingen mulighed for at adskille udveksling af politikker, routinginformation og brugerdata. Politikudbredelse kræver tilstedeværelsen af ​​IP-forbindelse mellem Hub og Spoke. I dette tilfælde kan MC-funktionen om nødvendigt kombineres med en DMVPN-router. Det er muligt (men ikke påkrævet) at bruge Prime Infrastructure-skabeloner til centraliseret politikgenerering. En vigtig egenskab er, at politikken er udformet globalt i hele netværket på samme måde - Individuelle politikker for individuelle segmenter understøttes ikke.
• SD-WAN – Trafikstyring og servicekvalitetspolitikker fastlægges centralt gennem Cisco vManage grafiske grænseflade, også tilgængelig via internettet (hvis nødvendigt). De distribueres via signaleringskanaler direkte eller indirekte gennem vSmart-controllere (afhængigt af typen af ​​politik). De er ikke afhængige af dataplanforbindelse mellem routere, fordi bruge alle tilgængelige trafikveje mellem controlleren og routeren.

  For forskellige netværkssegmenter er det muligt fleksibelt at formulere forskellige politikker - omfanget af politikken bestemmes af mange unikke identifikatorer i løsningen - filialnummer, applikationstype, trafikretning osv.

Orkestrerings-fly – mekanismer, der tillader komponenter dynamisk at detektere hinanden, konfigurere og koordinere efterfølgende interaktioner.

• в DMVPN/PfR Gensidig opdagelse mellem routere er baseret på den statiske konfiguration af Hub-enheder og den tilsvarende konfiguration af Spoke-enheder. Dynamisk opdagelse sker kun for Spoke, som rapporterer sine Hub-forbindelsesparametre til enheden, som igen er forudkonfigureret med Spoke. Uden IP-forbindelse mellem Spoke og mindst én Hub er det umuligt at danne hverken et dataplan eller et kontrolplan.
• в SD-WAN orkestrering af løsningskomponenter sker ved hjælp af vBond-controlleren, hvormed hver komponent (routere og vManage/vSmart-controllere) først skal etablere IP-forbindelse.

  I første omgang kender komponenterne ikke til hinandens forbindelsesparametre - til dette har de brug for vBond-formidleren. Det generelle princip er som følger - hver komponent i den indledende fase lærer (automatisk eller statisk) kun om forbindelsesparametrene til vBond, derefter informerer vBond routeren om vManage og vSmart controllerne (opdaget tidligere), hvilket gør det muligt automatisk at etablere alle nødvendige signalforbindelser.

  Det næste trin er, at den nye router lærer om de andre routere på netværket gennem OMP-kommunikation med vSmart-controlleren. Således er routeren, uden i første omgang at vide noget som helst om netværksparametrene, fuldautomatisk at detektere og forbinde til controllere og så også automatisk detektere og danne forbindelse med andre routere. I dette tilfælde er forbindelsesparametrene for alle komponenter oprindeligt ukendte og kan ændre sig under drift.

Management-plan – en del af løsningen, der giver centraliseret styring og overvågning.

• DMVPN/PfR – Der tilbydes ingen specialiseret ledelsesplanløsning. Til grundlæggende automatisering og overvågning kan produkter som Cisco Prime Infrastructure bruges. Hver router har mulighed for at blive styret via CLI-kommandolinjen. Integration med eksterne systemer via API er ikke tilvejebragt.
• SD-WAN – al regelmæssig interaktion og overvågning udføres centralt gennem vManage-controllerens grafiske grænseflade. Alle funktioner i løsningen, uden undtagelse, er tilgængelige for konfiguration gennem vManage, samt gennem et fuldt dokumenteret REST API-bibliotek.

  Alle SD-WAN-netværksindstillinger i vManage kommer ned til to hovedkonstruktioner - dannelsen af ​​enhedsskabeloner (Device Template) og dannelsen af ​​en politik, der bestemmer logikken for netværksdrift og trafikbehandling. Samtidig udsender vManage, der udsender politikken genereret af administratoren, automatisk, hvilke ændringer og på hvilke individuelle enheder/controllere der skal laves, hvilket markant øger effektiviteten og skalerbarheden af ​​løsningen.

  Gennem vManage-grænsefladen er ikke kun konfiguration af Cisco SD-WAN-løsningen tilgængelig, men også fuld overvågning af status for alle komponenter i løsningen, ned til den aktuelle tilstand af metrikker for individuelle tunneler og statistik 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 CLI-kommandolinje, som er nødvendig på implementeringsstadiet eller i nødstilfælde for lokal diagnostik. I normal tilstand (hvis der er en signaleringskanal mellem komponenter) på routere er kommandolinjen kun tilgængelig til diagnostik og er ikke tilgængelig til at lave lokale ændringer, hvilket garanterer lokal sikkerhed, og den eneste kilde til ændringer i et sådant netværk er vManage.

Integreret sikkerhed – her skal vi ikke kun tale om beskyttelse af brugerdata, når de transmitteres over åbne kanaler, men også om WAN-netværkets overordnede sikkerhed baseret på den valgte teknologi.

• в DMVPN/PfR Det er muligt at kryptere brugerdata og signaleringsprotokoller. Ved brug af visse routermodeller er firewall-funktioner med trafikinspektion, IPS/IDS yderligere tilgængelige. Det er muligt at segmentere filialnet ved hjælp af VRF. Det er muligt at autentificere (en-faktor) kontrolprotokoller.

  I dette tilfælde betragtes fjernrouteren som et betroet element i netværket som standard - dvs. tilfælde af fysisk kompromittering af individuelle enheder og muligheden for uautoriseret adgang til dem antages eller tages ikke i betragtning; der er ingen to-faktor autentificering af løsningskomponenter, hvilket i tilfælde af et geografisk distribueret netværk kan medføre væsentlige yderligere risici.

• в SD-WAN analogt med DMVPN er der mulighed for at kryptere brugerdata, men med betydeligt udvidet netværkssikkerhed og L3/VRF-segmenteringsfunktioner (firewall, IPS/IDS, URL-filtrering, DNS-filtrering, AMP/TG, SASE, TLS/SSL-proxy, osv.) d.). Samtidig udføres udvekslingen af ​​krypteringsnøgler mere effektivt gennem vSmart-controllere (i stedet for direkte), gennem præ-etablerede signaleringskanaler beskyttet af DTLS/TLS-kryptering baseret på sikkerhedscertifikater. Hvilket igen garanterer sikkerheden ved sådanne udvekslinger og sikrer bedre skalerbarhed af løsningen op til titusindvis af enheder på samme netværk.

  Alle signalforbindelser (controller-til-controller, controller-router) er også beskyttet baseret på DTLS/TLS. Routere er udstyret med sikkerhedscertifikater under produktion med mulighed for udskiftning/udvidelse. To-faktor autentificering opnås gennem den obligatoriske og samtidige opfyldelse af to betingelser for, at routeren/controlleren kan fungere i et SD-WAN-netværk:

  • Gyldigt sikkerhedscertifikat
  • Eksplicit og bevidst medtagelse af administratoren af ​​hver komponent på den "hvide" liste over tilladte enheder.

Funktionelle forskelle mellem SD-WAN og DMVPN/PfR

Går vi videre til at diskutere funktionelle forskelle, skal det bemærkes, at mange af dem er en fortsættelse af arkitektoniske - det er ingen hemmelighed, at når de danner arkitekturen for en løsning, tager udviklere udgangspunkt i de muligheder, de ønsker at få i sidste ende. Lad os se på de væsentligste forskelle mellem de to teknologier.

AppQ (Application Quality) – funktioner til at sikre kvaliteten af ​​transmissionen af ​​forretningsapplikationstrafik

Nøglefunktionerne i de undersøgte teknologier er rettet mod at forbedre brugeroplevelsen så meget som muligt ved brug af forretningskritiske applikationer i et distribueret netværk. Dette er især vigtigt under forhold, hvor en del af infrastrukturen ikke er styret af IT eller ikke engang garanterer en vellykket dataoverførsel.

DMVPN leverer ikke selv sådanne mekanismer. Det bedste, der kan gøres i et klassisk DMVPN-netværk, er at klassificere udgående trafik efter applikation og prioritere det, når det transmitteres mod WAN-kanalen. Valget af en DMVPN-tunnel bestemmes i dette tilfælde kun af dens tilgængelighed og resultatet af driften af ​​routingprotokoller. Samtidig tages der ikke højde for ende-til-ende-tilstanden af ​​stien/tunnelen og dens mulige delvise forringelse med hensyn til nøglemetrikker, der er væsentlige for netværksapplikationer - forsinkelse, forsinkelsesvariation (jitter) og tab (% ). I denne forbindelse mister direkte sammenligning af klassisk DMVPN med SD-WAN med hensyn til løsning af AppQ-problemer al mening - DMVPN kan ikke løse dette problem. Når du tilføjer Cisco Performance Routing-teknologi (PfR) i denne sammenhæng, ændres situationen, og sammenligningen med Cisco SD-WAN bliver mere meningsfuld.

Før vi diskuterer forskellene, er her et hurtigt kig på, hvordan teknologierne ligner hinanden. Så begge teknologier:

• har en mekanisme, der giver dig mulighed for dynamisk at vurdere tilstanden af ​​hver etableret tunnel i form af visse metrikker - som minimum forsinkelse, forsinkelsesvariation og pakketab (%)
• bruge et specifikt sæt værktøjer til at danne, distribuere og anvende trafikstyringsregler (politikker), idet der tages hensyn til resultaterne af måling af tilstanden af ​​nøgletunnelmetrikker.
• klassificere applikationstrafik på niveauerne L3-L4 (DSCP) af OSI-modellen eller ved L7 applikationssignaturer baseret på DPI-mekanismer indbygget i routeren
• For væsentlige applikationer giver de dig mulighed for at bestemme acceptable tærskelværdier for metrikker, regler for transmission af trafik som standard og regler for omdirigering af trafik, når tærskelværdier overskrides.
• Når de indkapsler trafik i GRE/IPSec, bruger de den allerede etablerede industrimekanisme til at overføre interne DSCP-mærkninger til den eksterne GRE/IPSEC-pakkeheader, som gør det muligt at synkronisere QoS-politikkerne for organisationen og teleoperatøren (hvis der er en passende SLA) .

Hvordan adskiller SD-WAN og DMVPN/PfR end-to-end metrics sig?

DMVPN/PfR

• Både aktive og passive softwaresensorer (prober) bruges til at evaluere standard tunnelsundhedsmålinger. Aktive er baseret på brugertrafik, passive efterligner sådan trafik (i dens fravær).
• Der er ingen finjustering af timere og nedbrydningsdetekteringsbetingelser - algoritmen er fast.
• Derudover er måling af brugt båndbredde i udgående retning tilgængelig. Hvilket tilføjer yderligere trafikstyringsfleksibilitet til DMVPN/PfR.
• Samtidig er nogle PfR-mekanismer, når målinger overskrides, afhængige af feedback-signalering i form af særlige TCA-meddelelser (Threshold Crossing Alert), der skal komme fra trafikmodtageren mod kilden, som igen antager, at tilstanden af målte kanaler bør i det mindste være tilstrækkelige til transmission af sådanne TCA-meddelelser. Hvilket i de fleste tilfælde ikke er et problem, men naturligvis ikke kan garanteres.

SD-WAN

• Til end-to-end-evaluering af standard tunneltilstandsmetrikker bruges BFD-protokollen i ekkotilstand. I dette tilfælde kræves der ikke speciel feedback i form af TCA eller lignende beskeder - isolering af fejldomæner opretholdes. Det kræver heller ikke tilstedeværelsen af ​​brugertrafik for at evaluere tunneltilstanden.
• Det er muligt at finjustere BFD-timere for at regulere responshastigheden og følsomheden af ​​algoritmen over for forringelse af kommunikationskanalen fra flere sekunder til minutter.

  

• I skrivende stund er der kun én BFD-session i hver tunnel. Dette skaber potentielt mindre granularitet i tunneltilstandsanalyse. I virkeligheden kan dette kun blive en begrænsning, hvis du bruger en WAN-forbindelse baseret på MPLS L2/L3 VPN med en aftalt QoS SLA - hvis DSCP-mærkningen af ​​BFD-trafik (efter indkapsling i IPSec/GRE) matcher højprioritetskøen i teleoperatørens netværk, så kan dette påvirke nøjagtigheden og hastigheden af ​​nedbrydningsdetektering for lavprioritet trafik. Samtidig er det muligt at ændre standard BFD-mærkningen for at reducere risikoen for sådanne situationer. I fremtidige versioner af Cisco SD-WAN-software forventes flere finjusterede BFD-indstillinger samt muligheden for at starte flere BFD-sessioner inden for den samme tunnel med individuelle DSCP-værdier (til forskellige applikationer).
• BFD giver dig desuden mulighed for at estimere den maksimale pakkestørrelse, der kan transmitteres gennem en bestemt tunnel uden fragmentering. Dette giver SD-WAN mulighed for dynamisk at justere parametre såsom MTU og TCP MSS Adjust for at få mest muligt ud af den tilgængelige båndbredde på hvert link.
• I SD-WAN er muligheden for QoS-synkronisering fra teleoperatører også tilgængelig, ikke kun baseret på L3 DSCP-felter, men også baseret på L2 CoS-værdier, som automatisk kan genereres i filialnettet af specialiserede enheder - for eksempel IP telefoner

Hvordan adskiller mulighederne, metoderne til at definere og anvende AppQ-politikker?

DMVPN/PfR-politikker:

• Defineret på den eller de centrale grenroutere via CLI-kommandolinjen eller CLI-konfigurationsskabeloner. Generering af CLI-skabeloner kræver forberedelse og viden om politiksyntaks.

  

• Defineret globalt uden mulighed for individuel konfiguration/ændring til de enkelte netværkssegmenters krav.
• Interaktiv politikgenerering leveres ikke i den grafiske grænseflade.
• Sporing af ændringer, nedarvning og oprettelse af flere versioner af politikker til hurtig skift er ikke tilvejebragt.
• Distribueres automatisk til routere af fjerntliggende filialer. I dette tilfælde bruges de samme kommunikationskanaler som til overførsel af brugerdata. Hvis der ikke er nogen kommunikationskanal mellem den centrale og den eksterne filial, er distribution/ændring af politikker umulig.
• De bruges på hver router og ændrer om nødvendigt resultatet af standard routingprotokoller, der har en højere prioritet.
• I tilfælde, hvor alle filial WAN-links oplever betydeligt trafiktab, ingen kompensationsmekanismer tilvejebragt.

SD-WAN-politikker:

• Defineret i vManage GUI gennem den interaktive skabelonguide.
• Understøtter oprettelse af flere politikker, kopiering, nedarvning, skift mellem politikker i realtid.
• Understøtter individuelle politikindstillinger for forskellige netværkssegmenter (grene)
• De distribueres ved hjælp af enhver tilgængelig signalkanal mellem controlleren og routeren og/eller vSmart - er ikke direkte afhængige af dataplanforbindelsen mellem routerne. Dette kræver selvfølgelig IP-forbindelse mellem selve routeren og controllerne.

  

• I tilfælde, hvor alle tilgængelige grene af en filial oplever betydelige datatab, der overstiger acceptable tærskler for kritiske applikationer, er det muligt at bruge yderligere mekanismer, der øger transmissionspålidelighed:
  • FEC (Forward Error Correction) – bruger en speciel redundant kodningsalgoritme. Ved transmission af kritisk trafik over kanaler med en betydelig procentdel af tab, kan FEC aktiveres automatisk og giver mulighed for om nødvendigt at gendanne den tabte del af dataene. Dette øger den brugte transmissionsbåndbredde en smule, men forbedrer pålideligheden betydeligt.

    

  • Duplikering af datastrømme – Ud over FEC kan politikken give mulighed for automatisk duplikering af trafik af udvalgte applikationer i tilfælde af et endnu mere alvorligt niveau af tab, som ikke kan kompenseres af FEC. I dette tilfælde vil de valgte data blive transmitteret gennem alle tunneler mod den modtagende gren med efterfølgende de-duplikering (slipning af ekstra kopier af pakker). Mekanismen øger kanaludnyttelsen markant, men øger også transmissionspålideligheden markant.

Cisco SD-WAN-funktioner, uden direkte analoger i DMVPN/PfR

Arkitekturen af ​​Cisco SD-WAN-løsningen giver dig i nogle tilfælde mulighed for at opnå kapaciteter, der enten er ekstremt svære at implementere inden for DMVPN/PfR, eller som er upraktiske på grund af de nødvendige arbejdsomkostninger, eller som er fuldstændig umulige. Lad os se på de mest interessante af dem:

Trafikteknik (TE)

TE inkluderer mekanismer, der tillader trafik at forgrene sig fra standardstien dannet af routingprotokoller. TE bruges ofte til at sikre høj tilgængelighed af netværkstjenester gennem evnen til hurtigt og/eller proaktivt at overføre kritisk trafik til en alternativ (usammenhængende) transmissionssti for at sikre bedre servicekvalitet eller gendannelseshastighed i tilfælde af fejl på hovedstien.

Vanskeligheden ved at implementere TE ligger i behovet for at beregne og reservere (tjekke) en alternativ vej på forhånd. I MPLS-netværk af teleoperatører løses dette problem ved hjælp af teknologier som MPLS Traffic-Engineering med udvidelser af IGP-protokollerne og RSVP-protokollen. Også for nylig er Segment Routing-teknologi, som er mere optimeret til centraliseret konfiguration og orkestrering, blevet stadig mere populær. I klassiske WAN-netværk er disse teknologier normalt ikke repræsenteret eller er reduceret til brugen af ​​hop-by-hop-mekanismer som Policy-Based Routing (PBR), som er i stand til at forgrene trafik, men implementerer dette på hver router separat - uden at tage tage højde for den overordnede tilstand af netværket eller PBR-resultatet i de foregående eller efterfølgende trin. Resultatet af at bruge disse TE-muligheder er skuffende - MPLS TE, på grund af kompleksiteten af ​​konfiguration og drift, bruges som regel kun i den mest kritiske del af netværket (kernen), og PBR bruges på individuelle routere uden muligheden for at skabe en samlet PBR-politik for hele netværket. Det gælder naturligvis også for DMVPN-baserede netværk.

SD-WAN tilbyder i denne henseende en meget mere elegant løsning, der ikke kun er nem at konfigurere, men også skalerer meget bedre. Dette er et resultat af de anvendte kontrolplan- og politikplanarkitekturer. Implementering af et policy-plan i SD-WAN giver dig mulighed for centralt at definere TE-politik - hvilken trafik er interessant? for hvilke VPN'er? Gennem hvilke knudepunkter/tunneler er det nødvendigt eller omvendt forbudt at danne en alternativ rute? Til gengæld giver centraliseringen af ​​kontrolplanstyring baseret på vSmart-controllere dig mulighed for at ændre routingresultater uden at ty til indstillingerne for individuelle enheder - routere ser allerede kun resultatet af den logik, der blev genereret i vManage-grænsefladen og overført til brug til vSmart.

Service-kæde

Dannelse af servicekæder er en endnu mere arbejdskrævende opgave i klassisk routing end den allerede beskrevne Traffic-Engineering-mekanisme. Faktisk er det i dette tilfælde nødvendigt ikke kun at oprette en speciel rute til en specifik netværksapplikation, men også at sikre muligheden for at fjerne trafik fra netværket på visse (eller alle) noder i SD-WAN-netværket til behandling af en speciel applikation eller service (firewall, balancering, cachelagring, inspektionstrafik osv.). Samtidig er det nødvendigt at være i stand til at kontrollere tilstanden af ​​disse eksterne tjenester for at forhindre sorte huller-situationer, og der er også behov for mekanismer, der gør det muligt at placere sådanne eksterne tjenester af samme type på forskellige geo-lokationer med netværkets evne til automatisk at vælge den mest optimale serviceknude til behandling af trafikken i en bestemt filial. I tilfældet med Cisco SD-WAN er dette ret nemt at opnå ved at skabe en passende centraliseret politik, der "limer" alle aspekter af målservicekæden til en enkelt helhed og automatisk ændrer dataplan- og kontrolplanlogikken kun hvor og når det er nødvendigt.

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

Resultatet?

Det er klart, både DMVPN (med eller uden Performance Routing) og Cisco SD-WAN ende med at løse meget lignende problemer i forhold til organisationens distribuerede WAN-netværk. Samtidig fører betydelige arkitektoniske og funktionelle forskelle i Cisco SD-WAN-teknologi til processen med at løse disse problemer til et andet kvalitetsniveau. For at opsummere kan vi bemærke følgende væsentlige forskelle mellem SD-WAN og DMVPN/PfR-teknologier:

• DMVPN/PfR bruger generelt tidstestede teknologier til opbygning af overlay VPN-netværk og, hvad angår dataplan, ligner de mere moderne SD-WAN-teknologi, dog er der en række begrænsninger i form af en obligatorisk statisk konfiguration af routere og valget af topologier er begrænset til Hub-n-Spoke. På den anden side har DMVPN/PfR en eller anden funktionalitet, som endnu ikke er tilgængelig i SD-WAN (vi taler om BFD pr. applikation).
• Inden for kontrolplanet er teknologierne fundamentalt forskellige. Under hensyntagen til den centraliserede behandling af signaleringsprotokoller tillader SD-WAN især at indsnævre fejldomæner betydeligt og "afkoble" processen med at transmittere brugertrafik fra signalinteraktion - midlertidig utilgængelighed af controllere påvirker ikke evnen til at transmittere brugertrafik . Samtidig påvirker den midlertidige utilgængelighed af enhver filial (inklusive den centrale) ikke på nogen måde andre filialers mulighed for at interagere med hinanden og controllere.
• Arkitekturen for dannelse og anvendelse af trafikstyringspolitikker i tilfælde af SD-WAN er også overlegen i forhold til DMVPN/PfR - geo-reservation er meget bedre implementeret, der er ingen forbindelse til Hub, der er flere muligheder for fine -tilpasningspolitikker er listen over implementerede trafikstyringsscenarier også meget større.
• Løsningens orkestreringsprocessen er også væsentlig anderledes. DMVPN antager tilstedeværelsen af ​​tidligere kendte parametre, som på en eller anden måde skal afspejles i konfigurationen, hvilket i nogen grad begrænser løsningens fleksibilitet og muligheden for dynamiske ændringer. Til gengæld er SD-WAN baseret på det paradigme, at routeren i det første forbindelsestidspunkt "ikke ved noget" om sine controllere, men ved "hvem du kan spørge" - dette er nok ikke kun til automatisk at etablere kommunikation med controllerne, men også til automatisk at danne en fuldt tilsluttet dataplantopologi, som derefter kan konfigureres/ændres fleksibelt ved hjælp af politikker.
• Med hensyn til centraliseret styring, automatisering og overvågning forventes SD-WAN at overgå mulighederne i DMVPN/PfR, som har udviklet sig fra klassiske teknologier og er mere afhængige af CLI-kommandolinjen og brugen af ​​skabelonbaserede NMS-systemer.
• I SD-WAN, sammenlignet med DMVPN, har sikkerhedskravene nået et andet kvalitativt niveau. Hovedprincipperne er nul tillid, skalerbarhed og to-faktor autentificering.

Disse simple konklusioner kan give det forkerte indtryk af, at oprettelse af et netværk baseret på DMVPN/PfR har mistet al relevans i dag. Dette er naturligvis ikke helt rigtigt. For eksempel, i tilfælde hvor netværket bruger meget forældet udstyr, og der ikke er nogen måde at erstatte det på, kan DMVPN tillade dig at kombinere "gamle" og "nye" enheder til et enkelt geo-distribueret netværk med mange af de beskrevne fordele over.

På den anden side skal det huskes, at alle nuværende Cisco-virksomhedsroutere baseret på IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) i dag understøtter enhver driftstilstand - både klassisk routing og DMVPN og SD-WAN - valget bestemmes af aktuelle behov og forståelsen af, at du til enhver tid, ved at bruge det samme udstyr, kan begynde at bevæge dig mod mere avanceret teknologi.

Kilde: www.habr.com