🥇Vil Cisco kutte av SD-WAN-grenen som DMVPN sitter på?

Siden august 2017, da Cisco kjøpte Viptela, har hovedteknologien som tilbys for å organisere distribuerte bedriftsnettverk blitt Cisco SD-WAN. I løpet av de siste 3 årene har SD-WAN-teknologien gått gjennom mange endringer, både kvalitative og kvantitative. Dermed har funksjonaliteten utvidet seg betydelig og støtte har dukket opp på klassiske rutere i serien Cisco ISR 1000, ISR 4000, ASR 1000 og Virtual CSR 1000v. Samtidig fortsetter mange Cisco-kunder og partnere å lure på: hva er forskjellene mellom Cisco SD-WAN og allerede kjente tilnærminger basert på teknologier som f.eks Cisco DMVPN и Cisco ytelsesruting og hvor viktige er disse forskjellene?

Her bør vi umiddelbart ta forbehold om at før SD-WAN kom i Cisco-porteføljen, utgjorde DMVPN sammen med PfR en sentral del i arkitekturen Cisco IWAN (Intelligent WAN), som igjen var forgjengeren til fullverdig SD-WAN-teknologi. Til tross for den generelle likheten mellom både oppgavene som løses og metodene for å løse dem, fikk IWAN aldri det nivået av automatisering, fleksibilitet og skalerbarhet som er nødvendig for SD-WAN, og over tid har utviklingen av IWAN avtatt betydelig. Samtidig har ikke teknologiene som utgjør IWAN forsvunnet, og mange kunder fortsetter å bruke dem med suksess, inkludert på moderne utstyr. Som et resultat har en interessant situasjon oppstått - det samme Cisco-utstyret lar deg velge den mest passende WAN-teknologien (klassisk, DMVPN+PfR eller SD-WAN) i samsvar med kundenes krav og forventninger.

Artikkelen har ikke til hensikt å analysere i detalj alle funksjonene til Cisco SD-WAN- og DMVPN-teknologier (med eller uten Performance Routing) - det er en enorm mengde tilgjengelige dokumenter og materialer for dette. Hovedoppgaven er å prøve å evaluere de viktigste forskjellene mellom disse teknologiene. Men før vi går videre til å diskutere disse forskjellene, la oss kort huske selve teknologiene.

Hva er Cisco DMVPN og hvorfor er det nødvendig?

Cisco DMVPN løser problemet med dynamisk (= skalerbar) tilkobling av et eksternt filialnettverk til nettverket til sentralkontoret til en bedrift ved bruk av vilkårlige typer kommunikasjonskanaler, inkludert Internett (= med kryptering av kommunikasjonskanalen). Teknisk sett realiseres dette ved å lage et virtualisert overleggsnettverk av L3 VPN-klasse i punkt-til-multipunkt-modus med en logisk topologi av typen "Star" (Hub-n-Spoke). For å oppnå dette bruker DMVPN en kombinasjon av følgende teknologier:

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

Hva er de viktigste fordelene med Cisco DMVPN sammenlignet med klassisk ruting ved bruk av MPLS VPN-kanaler?

For å lage et grennettverk er det mulig å bruke alle kommunikasjonskanaler - alt som kan gi IP-tilkobling mellom grener er egnet, mens trafikken vil være kryptert (der det er nødvendig) og balansert (der det er mulig)
En fullt koblet topologi mellom grener dannes automatisk. I dette tilfellet er det statiske tunneler mellom de sentrale og eksterne grenene, og dynamiske tunneler på forespørsel mellom de eksterne grenene (hvis det er trafikk)
Ruterne til den sentrale og den eksterne grenen har samme konfigurasjon opp til IP-adressene til grensesnittene. Ved å bruke mGRE er det ikke nødvendig å individuelt konfigurere titalls, hundrevis eller til og med tusenvis av tunneler. Som et resultat anstendig skalerbarhet med riktig design.

Hva er Cisco Performance Routing og hvorfor er det nødvendig?

Når du bruker DMVPN på et grennettverk, forblir et ekstremt viktig spørsmål uløst - hvordan du dynamisk vurderer tilstanden til hver av DMVPN-tunnelene for samsvar med kravene til trafikk som er kritiske for organisasjonen vår, og igjen, basert på en slik vurdering, dynamisk foreta vedtak om omlegging? Faktum er at DMVPN i denne delen skiller seg lite fra klassisk ruting - det beste som kan gjøres er å konfigurere QoS-mekanismer som lar deg prioritere trafikk i utgående retning, men som på ingen måte er i stand til å ta hensyn til tilstanden til hele veien på et eller annet tidspunkt.

Og hva skal man gjøre hvis kanalen degraderes delvis og ikke helt - hvordan oppdager og evaluerer man dette? DMVPN selv kan ikke gjøre dette. Tatt i betraktning at kanalene som forbinder grener kan passere gjennom helt forskjellige teleoperatører ved å bruke helt andre teknologier, blir denne oppgaven ekstremt ikke-triviell. Og det er her Cisco Performance Routing-teknologien kommer til unnsetning, som på den tiden allerede hadde gått gjennom flere utviklingsstadier.

Oppgaven til Cisco Performance Routing (heretter PfR) kommer ned til å måle tilstanden til stier (tunneler) for trafikk basert på nøkkeltall som er viktige for nettverksapplikasjoner - ventetid, latensvariasjon (jitter) og pakketap (prosent). I tillegg kan den brukte båndbredden måles. Disse målingene skjer så nær sanntid som mulig og berettiget, og resultatet av disse målingene gjør at ruteren som bruker PfR, dynamisk kan ta beslutninger om behovet for å endre rutingen til denne eller den typen trafikk.

Dermed kan oppgaven til DMVPN/PfR-kombinasjonen kort beskrives som følger:

La kunden bruke eventuelle kommunikasjonskanaler på WAN-nettverket
Sikre høyest mulig kvalitet på kritiske applikasjoner på disse kanalene

Hva er Cisco SD-WAN?

Cisco SD-WAN er en teknologi som bruker SDN-tilnærmingen til å opprette og drifte en organisasjons WAN-nettverk. Dette betyr spesielt bruk av såkalte kontrollere (programvareelementer), som gir sentralisert orkestrering og automatisert konfigurasjon av alle løsningskomponenter. I motsetning til den kanoniske SDN (Clean Slate-stilen), bruker Cisco SD-WAN flere typer kontrollere, som hver utfører sin egen rolle - dette ble gjort med vilje for å gi bedre skalerbarhet og geo-redundans.

Når det gjelder SD-WAN, forblir oppgaven med å bruke alle typer kanaler og sikre driften av forretningsapplikasjoner den samme, men samtidig utvides kravene til automatisering, skalerbarhet, sikkerhet og fleksibilitet til et slikt nettverk.

Diskusjon av forskjeller

Hvis vi nå begynner å analysere forskjellene mellom disse teknologiene, vil de falle inn i en av følgende kategorier:

Arkitektoniske forskjeller – hvordan er funksjoner fordelt på ulike komponenter i løsningen, hvordan er samspillet mellom slike komponenter organisert, og hvordan påvirker dette teknologiens muligheter og fleksibilitet?
Funksjonalitet – hva kan en teknologi gjøre som en annen ikke kan? Og er det virkelig så viktig?

Hva er de arkitektoniske forskjellene og er de viktige?

Hver av disse teknologiene har mange "bevegelige deler" som ikke bare er forskjellige i rollene deres, men også i hvordan de samhandler med hverandre. Hvor godt disse prinsippene er gjennomtenkt og den generelle mekanikken til løsningen bestemmer direkte dens skalerbarhet, feiltoleranse og generelle effektivitet.

La oss se på de ulike aspektene ved arkitekturen mer detaljert:

Data-plan – del av løsningen ansvarlig for overføring av brukertrafikk mellom kilde og mottaker. DMVPN og SD-WAN implementeres generelt identisk på selve ruterne basert på Multipoint GRE-tunneler. Forskjellen er hvordan det nødvendige settet med parametere for disse tunnelene er dannet:

в DMVPN/PfR er et eksklusivt to-nivå hierarki av noder med en stjerne eller Hub-n-Spoke topologi. Statisk konfigurasjon av huben og statisk binding av Spoke til huben er nødvendig, samt interaksjon via NHRP-protokollen for å danne dataplan-tilkobling. Følgelig gjør endringer i Huben betydelig vanskeligereknyttet til for eksempel å endre/koble til nye WAN-kanaler eller endre parametrene til eksisterende.
в SD WAN er en fullt dynamisk modell for å oppdage parametere for installerte tunneler basert på kontrollplan (OMP-protokoll) og orkestreringsplan (interaksjon med vBond-kontrolleren for kontrollerdeteksjon og NAT-traverseringsoppgaver). I dette tilfellet kan alle overlagrede topologier brukes, inkludert hierarkiske. Innenfor den etablerte overleggstunneltopologien er fleksibel konfigurasjon av den logiske topologien i hver enkelt VPN(VRF) mulig.

Kontroll-plan – funksjoner for utveksling, filtrering og modifikasjon av ruting og annen informasjon mellom løsningskomponenter.

в DMVPN/PfR – utføres kun mellom Hub- og Spoke-rutere. Direkte utveksling av ruteinformasjon mellom Spokes er ikke mulig. Følgelig Uten en fungerende hub kan ikke kontrollplanet og dataplanet fungere, som pålegger huben ytterligere høye tilgjengelighetskrav som ikke alltid kan oppfylles.
в SD WAN – kontrollplan utføres aldri direkte mellom rutere – samhandling skjer på grunnlag av OMP-protokollen og utføres nødvendigvis gjennom en egen spesialisert type vSmart-kontroller, som gir mulighet for balansering, georeservasjon og sentralisert kontroll av signalbelastning. En annen funksjon ved OMP-protokollen er dens betydelige motstand mot tap og uavhengighet fra hastigheten til kommunikasjonskanalen med kontrollere (innenfor rimelige grenser, selvfølgelig). Som like vellykket lar deg plassere SD-WAN-kontrollere i offentlige eller private skyer med tilgang via Internett.

Politikk-plan – en del av løsningen ansvarlig for å definere, distribuere og anvende retningslinjer for trafikkstyring på et distribuert nettverk.

DMVPN – er effektivt begrenset av Quality of Service (QoS)-policyer som er konfigurert individuelt på hver ruter via CLI- eller Prime Infrastructure-malene.
DMVPN/PfR – PfR-policyer dannes på den sentraliserte Master Controller (MC)-ruteren via CLI og distribueres deretter automatisk til gren-MC-er. I dette tilfellet brukes de samme policyoverføringsbanene som for dataplanet. Det er ingen mulighet for å skille utveksling av policyer, rutinginformasjon og brukerdata. Formidling av policy krever tilstedeværelse av IP-tilkobling mellom Hub og Spoke. I dette tilfellet kan MC-funksjonen om nødvendig kombineres med en DMVPN-ruter. Det er mulig (men ikke nødvendig) å bruke Prime Infrastructure-maler for sentralisert policygenerering. En viktig funksjon er at policyen er utformet globalt i hele nettverket på samme måte - Individuelle retningslinjer for individuelle segmenter støttes ikke.
SD WAN – trafikkstyring og retningslinjer for tjenestekvalitet bestemmes sentralt gjennom Cisco vManage grafiske grensesnitt, også tilgjengelig via Internett (om nødvendig). De distribueres gjennom signalkanaler direkte eller indirekte gjennom vSmart-kontrollere (avhengig av type policy). De er ikke avhengige av data-fly-tilkobling mellom rutere, fordi bruke alle tilgjengelige trafikkveier mellom kontrolleren og ruteren.
For ulike nettverkssegmenter er det mulig å fleksibelt formulere ulike policyer - omfanget av policyen bestemmes av mange unike identifikatorer gitt i løsningen - filialnummer, applikasjonstype, trafikkretning, etc.

Orkestreringsfly – mekanismer som lar komponenter dynamisk oppdage hverandre, konfigurere og koordinere påfølgende interaksjoner.

в DMVPN/PfR Gjensidig oppdagelse mellom rutere er basert på den statiske konfigurasjonen av Hub-enheter og den tilsvarende konfigurasjonen av Spoke-enheter. Dynamisk oppdagelse skjer bare for Spoke, som rapporterer Hub-tilkoblingsparameterne til enheten, som igjen er forhåndskonfigurert med Spoke. Uten IP-tilkobling mellom Spoke og minst én Hub, er det umulig å danne verken et dataplan eller et kontrollplan.
в SD WAN orkestrering av løsningskomponenter skjer ved hjelp av vBond-kontrolleren, som hver komponent (rutere og vManage/vSmart-kontrollere) først må etablere IP-tilkobling med.
Til å begynne med vet ikke komponentene om hverandres tilkoblingsparametere - for dette trenger de vBond-formidleren. Det generelle prinsippet er som følger - hver komponent i startfasen lærer (automatisk eller statisk) kun om tilkoblingsparametrene til vBond, deretter informerer vBond ruteren om vManage- og vSmart-kontrollerne (oppdaget tidligere), noe som gjør det mulig å automatisk etablere alle nødvendige signalforbindelser.

Det neste trinnet er at den nye ruteren lærer om de andre ruterne på nettverket gjennom OMP-kommunikasjon med vSmart-kontrolleren. Dermed er ruteren, uten i utgangspunktet å vite noe i det hele tatt om nettverksparametrene, i stand til å helt automatisk oppdage og koble til kontrollere og deretter automatisk oppdage og danne tilkobling med andre rutere. I dette tilfellet er tilkoblingsparametrene til alle komponentene i utgangspunktet ukjente og kan endres under drift.

Management-plan – en del av løsningen som gir sentralisert styring og overvåking.

DMVPN/PfR – ingen spesialisert styringsplanløsning tilbys. For grunnleggende automatisering og overvåking kan produkter som Cisco Prime Infrastructure brukes. Hver ruter har muligheten til å kontrolleres via CLI-kommandolinjen. Integrasjon med eksterne systemer via API er ikke gitt.
SD WAN – all regelmessig interaksjon og overvåking utføres sentralt gjennom det grafiske grensesnittet til vManage-kontrolleren. Alle funksjoner i løsningen, uten unntak, er tilgjengelige for konfigurasjon gjennom vManage, samt gjennom et fullt dokumentert REST API-bibliotek.
Alle SD-WAN-nettverksinnstillinger i vManage kommer ned til to hovedkonstruksjoner - dannelsen av enhetsmaler (Device Template) og dannelsen av en policy som bestemmer logikken for nettverksdrift og trafikkbehandling. Samtidig velger vManage, som kringkaster policyen generert av administratoren, automatisk hvilke endringer og hvilke individuelle enheter/kontrollere som skal gjøres, noe som øker effektiviteten og skalerbarheten til løsningen betydelig.

Gjennom vManage-grensesnittet er ikke bare konfigurasjon av Cisco SD-WAN-løsningen tilgjengelig, men også full overvåking av statusen til alle komponentene i løsningen, opp til gjeldende status for beregninger for individuelle tunneler og statistikk om bruk av ulike applikasjoner basert på DPI-analyse.

Til tross for sentralisering av interaksjon, har alle komponenter (kontrollere og rutere) også en fullt funksjonell CLI-kommandolinje, som er nødvendig på implementeringsstadiet eller i nødstilfelle for lokal diagnostikk. I normal modus (hvis det er en signaleringskanal mellom komponenter) på rutere, er kommandolinjen kun tilgjengelig for diagnostikk og er ikke tilgjengelig for å gjøre lokale endringer, noe som garanterer lokal sikkerhet og den eneste kilden til endringer i et slikt nettverk er vManage.

Integrert sikkerhet – her bør vi snakke ikke bare om beskyttelse av brukerdata når de overføres over åpne kanaler, men også om den generelle sikkerheten til WAN-nettverket basert på den valgte teknologien.

в DMVPN/PfR Det er mulig å kryptere brukerdata og signaleringsprotokoller. Ved bruk av enkelte rutermodeller er brannmurfunksjoner med trafikkinspeksjon, IPS/IDS i tillegg tilgjengelig. Det er mulig å segmentere filialnett ved hjelp av VRF. Det er mulig å autentisere (en-faktor) kontrollprotokoller.
I dette tilfellet anses den eksterne ruteren som et pålitelig element i nettverket som standard - dvs. tilfeller av fysisk kompromittering av individuelle enheter og muligheten for uautorisert tilgang til dem er ikke antatt eller tatt i betraktning; det er ingen tofaktorautentisering av løsningskomponenter, som i tilfelle av et geografisk distribuert nettverk kan medføre betydelige tilleggsrisikoer.
в SD WAN analogt med DMVPN er muligheten til å kryptere brukerdata gitt, men med betydelig utvidet nettverkssikkerhet og L3/VRF-segmenteringsfunksjoner (brannmur, IPS/IDS, URL-filtrering, DNS-filtrering, AMP/TG, SASE, TLS/SSL-proxy, osv.) d.). Samtidig utføres utvekslingen av krypteringsnøkler mer effektivt gjennom vSmart-kontrollere (snarere enn direkte), gjennom forhåndsetablerte signalkanaler beskyttet av DTLS/TLS-kryptering basert på sikkerhetssertifikater. Noe som igjen garanterer sikkerheten til slike sentraler og sikrer bedre skalerbarhet av løsningen opp til titusenvis av enheter på samme nettverk.
Alle signalforbindelser (kontroller-til-kontroller, kontroller-ruter) er også beskyttet basert på DTLS/TLS. Rutere er utstyrt med sikkerhetssertifikater under produksjon med mulighet for utskifting/utvidelse. Tofaktorautentisering oppnås gjennom obligatorisk og samtidig oppfyllelse av to betingelser for at ruteren/kontrolleren skal fungere i et SD-WAN-nettverk:
- Gyldig sikkerhetssertifikat
- Eksplisitt og bevisst inkludering av administratoren av hver komponent i den "hvite" listen over tillatte enheter.

Funksjonelle forskjeller mellom SD-WAN og DMVPN/PfR

Når vi går videre til å diskutere funksjonelle forskjeller, bør det bemerkes at mange av dem er en fortsettelse av arkitektoniske - det er ingen hemmelighet at når de danner arkitekturen til en løsning, starter utviklere fra egenskapene de ønsker å få til slutt. La oss se på de viktigste forskjellene mellom de to teknologiene.

AppQ (Application Quality) – funksjoner for å sikre kvaliteten på overføringen av trafikk for forretningsapplikasjoner

Nøkkelfunksjonene til teknologiene som vurderes er rettet mot å forbedre brukeropplevelsen så mye som mulig ved bruk av forretningskritiske applikasjoner i et distribuert nettverk. Dette er spesielt viktig i forhold der deler av infrastrukturen ikke er kontrollert av IT eller ikke engang garanterer vellykket dataoverføring.

DMVPN gir ikke selv slike mekanismer. Det beste som kan gjøres i et klassisk DMVPN-nettverk er å klassifisere utgående trafikk etter applikasjon og prioritere den når den overføres mot WAN-kanalen. Valget av en DMVPN-tunnel bestemmes i dette tilfellet bare av tilgjengeligheten og resultatet av driften av rutingprotokoller. Samtidig blir ikke ende-til-ende-tilstanden til banen/tunnelen og dens mulige delvise degradering tatt i betraktning når det gjelder nøkkeltall som er viktige for nettverksapplikasjoner - forsinkelse, forsinkelsesvariasjon (jitter) og tap (% ). I denne forbindelse, direkte sammenligning av klassisk DMVPN med SD-WAN når det gjelder å løse AppQ-problemer mister all mening - DMVPN kan ikke løse dette problemet. Når du legger til Cisco Performance Routing-teknologi (PfR) i denne sammenhengen, endres situasjonen og sammenligningen med Cisco SD-WAN blir mer meningsfull.

Før vi diskuterer forskjellene, her er en rask titt på hvordan teknologiene er like. Så begge teknologiene:

har en mekanisme som lar deg dynamisk vurdere tilstanden til hver etablert tunnel i form av visse beregninger - som et minimum, forsinkelse, forsinkelsesvariasjon og pakketap (%)
bruke et spesifikt sett med verktøy for å utforme, distribuere og anvende trafikkstyringsregler (policyer), og ta hensyn til resultatene av måling av tilstanden til viktige tunnelberegninger.
klassifisere applikasjonstrafikk på nivåene L3-L4 (DSCP) av OSI-modellen eller ved L7 applikasjonssignaturer basert på DPI-mekanismer innebygd i ruteren
For betydelige applikasjoner lar de deg bestemme akseptable terskelverdier for beregninger, regler for overføring av trafikk som standard og regler for omdirigering av trafikk når terskelverdier overskrides.
Når de kapsler inn trafikk i GRE/IPSec, bruker de den allerede etablerte industrimekanismen for å overføre interne DSCP-merkinger til den eksterne GRE/IPSEC-pakkehodet, som tillater synkronisering av QoS-policyene til organisasjonen og teleoperatøren (hvis det er en passende SLA) .

Hvordan skiller SD-WAN og DMVPN/PfR ende-til-ende-beregninger seg?

DMVPN/PfR

Både aktive og passive programvaresensorer (prober) brukes til å evaluere standard tunnelhelsemålinger. Aktive er basert på brukertrafikk, passive emulerer slik trafikk (i fravær).
Det er ingen finjustering av tidtakere og nedbrytningsdeteksjonsbetingelser - algoritmen er fikset.
I tillegg er måling av brukt båndbredde i utgående retning tilgjengelig. Noe som gir ekstra trafikkstyringsfleksibilitet til DMVPN/PfR.
Samtidig er noen PfR-mekanismer, når beregninger overskrides, avhengige av tilbakemeldingssignalering i form av spesielle TCA-meldinger (Threshold Crossing Alert) som må komme fra trafikkmottakeren mot kilden, som igjen antar at tilstanden til målte kanaler bør minst være tilstrekkelig for overføring av slike TCA-meldinger. Noe som i de fleste tilfeller ikke er et problem, men selvsagt ikke kan garanteres.

SD WAN

For ende-til-ende-evaluering av standard tunneltilstandsmålinger, brukes BFD-protokollen i ekkomodus. I dette tilfellet er det ikke nødvendig med spesiell tilbakemelding i form av TCA eller lignende meldinger - isolasjon av feildomener opprettholdes. Det krever heller ikke tilstedeværelse av brukertrafikk for å evaluere tunneltilstanden.
Det er mulig å finjustere BFD-timere for å regulere responshastigheten og følsomheten til algoritmen for degradering av kommunikasjonskanalen fra flere sekunder til minutter.
I skrivende stund er det kun én BFD-økt i hver tunnel. Dette skaper potensielt mindre granularitet i tunneltilstandsanalyse. I realiteten kan dette kun bli en begrensning dersom du bruker en WAN-forbindelse basert på MPLS L2/L3 VPN med en avtalt QoS SLA - dersom DSCP-merkingen av BFD-trafikk (etter innkapsling i IPSec/GRE) samsvarer med høyprioritetskøen i teleoperatørens nettverk, så kan dette påvirke nøyaktigheten og hastigheten på degraderingsdeteksjon for lavprioritet trafikk. Samtidig er det mulig å endre standard BFD-merking for å redusere risikoen for slike situasjoner. I fremtidige versjoner av Cisco SD-WAN-programvare forventes mer finjusterte BFD-innstillinger, samt muligheten til å starte flere BFD-økter innenfor samme tunnel med individuelle DSCP-verdier (for forskjellige applikasjoner).
BFD lar deg i tillegg anslå den maksimale pakkestørrelsen som kan overføres gjennom en bestemt tunnel uten fragmentering. Dette lar SD-WAN dynamisk justere parametere som MTU og TCP MSS Adjust for å få mest mulig ut av den tilgjengelige båndbredden på hver lenke.
I SD-WAN er muligheten for QoS-synkronisering fra teleoperatører også tilgjengelig, ikke bare basert på L3 DSCP-felt, men også basert på L2 CoS-verdier, som automatisk kan genereres i filialnettet av spesialiserte enheter - for eksempel IP telefoner

Hvordan er mulighetene, metodene for å definere og bruke AppQ-policyer forskjellige?

DMVPN/PfR-retningslinjer:

Definert på den sentrale grenruteren(e) via CLI-kommandolinjen eller CLI-konfigurasjonsmaler. Generering av CLI-maler krever forberedelse og kunnskap om policysyntaks.
Definert globalt uten mulighet for individuell konfigurering/endring av kravene til individuelle nettsegmenter.
Generering av interaktiv policy er ikke gitt i det grafiske grensesnittet.
Sporing av endringer, arv og oppretting av flere versjoner av policyer for raskt bytte er ikke gitt.
Distribueres automatisk til rutere til eksterne grener. I dette tilfellet brukes de samme kommunikasjonskanalene som for overføring av brukerdata. Hvis det ikke er noen kommunikasjonskanal mellom den sentrale og den eksterne grenen, er distribusjon/endring av policyer umulig.
De brukes på hver ruter og modifiserer om nødvendig resultatet av standard rutingprotokoller, med høyere prioritet.
For tilfeller der alle WAN-koblinger opplever betydelig trafikktap, ingen kompensasjonsmekanismer gitt.

SD-WAN retningslinjer:

Definert i vManage GUI gjennom den interaktive malveiviseren.
Støtter opprettelse av flere policyer, kopiering, arving, veksling mellom policyer i sanntid.
Støtter individuelle policyinnstillinger for forskjellige nettverkssegmenter (grener)
De distribueres ved hjelp av en hvilken som helst tilgjengelig signalkanal mellom kontrolleren og ruteren og/eller vSmart - er ikke direkte avhengig av dataplanforbindelsen mellom ruterne. Dette krever selvfølgelig IP-tilkobling mellom selve ruteren og kontrollerene.
For tilfeller der alle tilgjengelige grener av en gren opplever betydelige datatap som overskrider akseptable terskler for kritiske applikasjoner, er det mulig å bruke tilleggsmekanismer som øker overføringspåliteligheten:
- FEC (Forward Error Correction) – bruker en spesiell redundant kodealgoritme. Ved overføring av kritisk trafikk over kanaler med en betydelig prosentandel av tap, kan FEC aktiveres automatisk og lar om nødvendig gjenopprette den tapte delen av dataene. Dette øker den brukte overføringsbåndbredden litt, men forbedrer påliteligheten betydelig.
- Duplisering av datastrømmer – I tillegg til FEC, kan policyen sørge for automatisk duplisering av trafikk av utvalgte applikasjoner i tilfelle et enda mer alvorlig nivå av tap som ikke kan kompenseres av FEC. I dette tilfellet vil de valgte dataene bli overført gjennom alle tunneler mot mottaksgrenen med påfølgende deduplisering (slipp av ekstra kopier av pakker). Mekanismen øker kanalutnyttelsen betydelig, men øker også overføringssikkerheten betydelig.

Cisco SD-WAN-funksjoner, uten direkte analoger i DMVPN/PfR

Arkitekturen til Cisco SD-WAN-løsningen lar deg i noen tilfeller oppnå funksjoner som enten er ekstremt vanskelige å implementere innenfor DMVPN/PfR, eller er upraktiske på grunn av de nødvendige arbeidskostnadene, eller er helt umulige. La oss se på de mest interessante av dem:

Trafikkteknikk (TE)

TE inkluderer mekanismer som lar trafikken forgrene seg fra standardbanen dannet av rutingprotokoller. TE brukes ofte for å sikre høy tilgjengelighet av nettverkstjenester, gjennom muligheten til raskt og/eller proaktivt å overføre kritisk trafikk til en alternativ (usammenhengende) overføringsvei, for å sikre bedre kvalitet på tjenesten eller gjenopprettingshastighet ved feil. på hovedstien.

Vanskeligheten med å implementere TE ligger i behovet for å beregne og reservere (sjekke) en alternativ vei på forhånd. I MPLS-nettverk av teleoperatører løses dette problemet ved hjelp av teknologier som MPLS Traffic-Engineering med utvidelser av IGP-protokollene og RSVP-protokollen. Også nylig har Segment Routing-teknologi, som er mer optimalisert for sentralisert konfigurasjon og orkestrering, blitt stadig mer populær. I klassiske WAN-nettverk er disse teknologiene vanligvis ikke representert eller er redusert til bruk av hop-by-hop-mekanismer som Policy-Based Routing (PBR), som er i stand til å forgrene trafikk, men implementerer dette på hver ruter separat - uten å ta ta hensyn til den generelle tilstanden til nettverket eller PBR-resultatet i forrige eller påfølgende trinn. Resultatet av å bruke disse TE-alternativene er skuffende - MPLS TE, på grunn av kompleksiteten i konfigurasjon og drift, brukes som regel bare i den mest kritiske delen av nettverket (kjerne), og PBR brukes på individuelle rutere uten muligheten til å lage en enhetlig PBR-policy for hele nettverket. Dette gjelder selvsagt også DMVPN-baserte nettverk.

SD-WAN i denne forbindelse tilbyr en mye mer elegant løsning som ikke bare er enkel å konfigurere, men også skalerer mye bedre. Dette er et resultat av kontrollplan- og policy-planarkitekturene som er brukt. Ved å implementere et policy-plan i SD-WAN kan du sentralt definere TE-policy - hvilken trafikk er av interesse? for hvilke VPN-er? Gjennom hvilke noder/tunneler er det nødvendig eller omvendt forbudt å danne en alternativ trasé? På sin side lar sentraliseringen av kontrollplanstyring basert på vSmart-kontrollere deg endre rutingresultater uten å ty til innstillingene til individuelle enheter - rutere ser allerede bare resultatet av logikken som ble generert i vManage-grensesnittet og overført for bruk til vSmart.

Tjenestekjeding

Å danne servicekjeder er en enda mer arbeidskrevende oppgave i klassisk ruting enn den allerede beskrevne Traffic-Engineering-mekanismen. I dette tilfellet er det faktisk nødvendig ikke bare å lage en spesiell rute for en spesifikk nettverksapplikasjon, men også for å sikre muligheten til å fjerne trafikk fra nettverket på visse (eller alle) noder i SD-WAN-nettverket for behandling av en spesiell applikasjon eller tjeneste (brannmur, balansering, bufring, inspeksjonstrafikk, etc.). Samtidig er det nødvendig å kunne kontrollere tilstanden til disse eksterne tjenestene for å forhindre svarte hull-situasjoner, og det er også behov for mekanismer som gjør at slike eksterne tjenester av samme type kan plasseres på forskjellige geolokasjoner med nettverkets evne til automatisk å velge den mest optimale tjenestenoden for å behandle trafikken til en bestemt gren. Når det gjelder Cisco SD-WAN, er dette ganske enkelt å oppnå ved å lage en passende sentralisert policy som "limer" alle aspekter av måltjenestekjeden til en enkelt helhet og automatisk endrer dataplan- og kontrollplanlogikken bare der og når det er nødvendig.

Muligheten til å lage geo-distribuert behandling av trafikk av utvalgte typer applikasjoner i en viss rekkefølge på spesialisert (men ikke relatert til selve SD-WAN-nettverket) utstyr er kanskje den mest tydelige demonstrasjonen av fordelene med Cisco SD-WAN fremfor klassiske teknologier og til og med noen alternative SD-løsninger -WAN fra andre produsenter.

Resultatet?

Tydeligvis både DMVPN (med eller uten Performance Routing) og Cisco SD-WAN ende opp med å løse svært like problemer i forhold til det distribuerte WAN-nettverket til organisasjonen. Samtidig fører betydelige arkitektoniske og funksjonelle forskjeller i Cisco SD-WAN-teknologi til prosessen med å løse disse problemene til et annet kvalitetsnivå. For å oppsummere kan vi merke oss følgende betydelige forskjeller mellom SD-WAN og DMVPN/PfR-teknologier:

DMVPN/PfR bruker generelt tidtestede teknologier for å bygge overliggende VPN-nettverk og, når det gjelder dataplan, ligner de mer moderne SD-WAN-teknologi, men det er en rekke begrensninger i form av en obligatorisk statisk konfigurasjon av rutere og valget av topologier er begrenset til Hub-n-Spoke. På den annen side har DMVPN/PfR en del funksjonalitet som ennå ikke er tilgjengelig innenfor SD-WAN (vi snakker om BFD per applikasjon).
Innen kontrollplanet er teknologiene fundamentalt forskjellige. Tatt i betraktning den sentraliserte behandlingen av signaleringsprotokoller, tillater SD-WAN spesielt å betydelig begrense feildomener og "frikoble" prosessen med å overføre brukertrafikk fra signaleringsinteraksjon - midlertidig utilgjengelighet av kontrollere påvirker ikke muligheten til å overføre brukertrafikk . Samtidig påvirker ikke den midlertidige utilgjengeligheten til noen gren (inkludert den sentrale) på noen måte muligheten til andre grener til å samhandle med hverandre og kontrollere.
Arkitekturen for dannelse og anvendelse av trafikkstyringspolicyer i tilfelle av SD-WAN er også overlegen den i DMVPN/PfR - geo-reservasjon er mye bedre implementert, det er ingen forbindelse til Hub, det er flere muligheter for fine -justeringspolicyer, listen over implementerte trafikkstyringsscenarier er også mye større.
Løsningsorkestreringsprosessen er også vesentlig annerledes. DMVPN antar tilstedeværelsen av tidligere kjente parametere som på en eller annen måte må reflekteres i konfigurasjonen, noe som begrenser fleksibiliteten til løsningen og muligheten for dynamiske endringer. På sin side er SD-WAN basert på paradigmet om at ruteren i det første tilkoblingsøyeblikket "ikke vet noe" om kontrollerene sine, men vet "hvem du kan spørre" - dette er nok ikke bare for automatisk å etablere kommunikasjon med kontrollerene, men også til automatisk å danne en fullstendig tilkoblet dataplantopologi, som deretter kan konfigureres/endres fleksibelt ved hjelp av policyer.
Når det gjelder sentralisert styring, automatisering og overvåking, forventes SD-WAN å overgå mulighetene til DMVPN/PfR, som har utviklet seg fra klassiske teknologier og er mer avhengig av CLI-kommandolinjen og bruk av malbaserte NMS-systemer.
I SD-WAN, sammenlignet med DMVPN, har sikkerhetskravene nådd et annet kvalitativt nivå. Hovedprinsippene er null tillit, skalerbarhet og tofaktorautentisering.

Disse enkle konklusjonene kan gi feil inntrykk av at å opprette et nettverk basert på DMVPN/PfR har mistet all relevans i dag. Dette er selvsagt ikke helt sant. For eksempel, i tilfeller der nettverket bruker mye utdatert utstyr og det ikke er mulig å erstatte det, kan DMVPN tillate deg å kombinere "gamle" og "nye" enheter til et enkelt geo-distribuert nettverk med mange av fordelene beskrevet ovenfor.

På den annen side bør det huskes at alle nåværende Cisco bedriftsrutere basert på IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) i dag støtter enhver driftsmodus - både klassisk ruting og DMVPN og SD-WAN - valget bestemmes av dagens behov og forståelsen av at du når som helst, ved å bruke det samme utstyret, kan begynne å bevege deg mot mer avansert teknologi.

Kilde: www.habr.com

Vil Cisco SD-WAN kutte av grenen som DMVPN sitter på?