Kommer Cisco SD-WAN att avlägsna grenen den sitter på, DMVPN?

Sedan augusti 2017, när Cisco förvärvade Viptela, blev den huvudsakliga teknik som erbjuds för organisationer med distribuerade företagsnätverk Cisco SD-WAN. Under de senaste tre åren har SD-WAN-teknologin genomgått många förändringar, både kvalitativa och kvantitativa. Funktionaliteten har utvidgats avsevärt och stöd har tillkommit för klassiska routrar av serierna Cisco ISR 1000, ISR 4000, ASR 1000 och den virtuella CSR 1000v. Samtidigt fortsätter många av Ciscos kunder och partners att fråga sig – vad är skillnaderna mellan Cisco SD-WAN och de mer traditionella metoderna baserade på teknologier som Cisco DMVPN och Cisco Performance Routing och hur viktiga är dessa skillnader?

Här bör ett förtydligande göras: innan SD-WAN kom in i Ciscos portfölj, utgjorde DMVPN i kombination med PfR en central del av arkitekturen Cisco IWAN (Intelligent WAN), som å sin sida var föregångaren till den fullfjädrade SD-WAN-teknologin. Trots den allmänna likheten, både när det gäller de problem som löses och sätten att lösa dem, så uppnådde IWAN aldrig den nödvändiga nivån av automatisering, flexibilitet och skalbarhet för SD-WAN, och med tiden minskade utvecklingen av IWAN avsevärt. Samtidigt har själva teknologierna som ingår i IWAN inte försvunnit, och många kunder fortsätter att framgångsrikt använda dem, även på modern utrustning. Resultatet är en intressant situation – samma Cisco-utrustning gör det möjligt att välja den mest lämpliga tekniken för att bygga WAN (klassisk, DMVPN+PfR eller SD-WAN) i enlighet med kundernas krav och förväntningar.

Artikeln syftar inte till att noggrant gå igenom alla funktioner i teknologierna Cisco SD-WAN och DMVPN (tillsammans eller utan Performance Routing) – det finns en mängd tillgängliga dokument och material för det. Huvudsyftet är att försöka bedöma de viktigaste skillnaderna mellan dessa teknologier. Men innan vi går vidare till diskussionen om dessa skillnader, låt oss kort påminna om själva teknologierna.

Vad är Cisco DMVPN och vad används det till?

Cisco DMVPN löser uppgiften att dynamiskt (dvs. skalbart) ansluta ett avlägset kontorsnät till centralkontorets nätverk genom användning av olika typer av kommunikationskanaler, inklusive Internet (med kryptering av kommunikationskanalen). Teknisk implementering sker genom att skapa ett virtualiserat överlagrat nätverk av klass L3. VPN i punkt-till-flera läge (point-to-multipoint) med en logisk topology av typen "Stjärna" (Hub-n-Spoke). För detta använder DMVPN en kombination av följande teknologier:

• IP-routing
• Multipoint GRE-tunnlar (mGRE)
• Next Hop Resolution Protocol (NHRP)
• IPSec-kryptoprofiler

Vad är de huvudsakliga fördelarna med Cisco DMVPN jämfört med klassisk routing med MPLS VPN-kanaler?

• För att skapa ett interkontorsnät kan alla kommunikationskanaler användas – allt som kan säkerställa IP-koppling mellan kontoren passar, samtidigt som trafiken kommer att krypteras (där det behövs) och lastbalanseras (där det är möjligt).
• En fullständigt kopplad topologi mellan kontoren formar sig automatiskt. Härvidlag finns det statiska tunnlar mellan centrala och avlägsna kontor, och mellan de avlägsna kontoren finns det dynamiska tunnlar på begäran (vid trafikflöde).
• På routrar för det centrala och avlägsna kontoret är konfigurationen identisk förutom IP-adresser gränssnitten. Genom användning av mGRE finns det inget behov av att individuellt konfigurera tiotals, hundratals eller till och med tusentals tunnlar. Som en konsekvens blir det en god skalbarhet vid korrekt design.

Vad är Cisco Performance Routing och varför behövs det?

Vid användning av DMVPN i interkontorsnätet kvarstår en extremt viktig fråga som inte har besvarats – hur kan man dynamiskt bedöma tillståndet för varje DMVPN-tunnel med avseende på att uppfylla kraven för kritisk trafik inom vår organisation och på grundval av denna bedömning dynamiskt besluta om omdirigering? Det är så att DMVPN i detta avseende skiljer sig lite från klassisk routing – det bästa man kan göra är att konfigurera QoS-mekanismer som möjliggör prioritering av utgående trafik, men som inte kan ta hänsyn till tillståndet för hela vägen vid ett specifikt ögonblick.

Vad ska man göra om kanalen delvis degraderas och inte helt – hur upptäcker och bedömer man detta? DMVPN kan inte hantera detta på egen hand. Eftersom kanalerna som kopplar samman filialer kan gå genom helt olika operatörer som använder olika teknologier, blir detta en ganska komplex uppgift. Här kommer teknologin Cisco Performance Routing till hjälp, som vid det här laget redan har genomgått flera utvecklingsstadier.

Uppgiften för Cisco Performance Routing (hädanefter PfR) handlar om att mäta tillståndet för vägar (tunnlar) som trafiken passerar genom baserat på nyckelmetrik, viktiga för nätverksapplikationer – fördröjning, jitter (variationen i fördröjningen) och paketförluster (i procent). Dessutom kan den använda bandbredden mätas. Dessa mätningar görs så nära realtid som möjligt (i den mån det är rimligt) och resultaten av dessa mätningar gör att routern som använder PfR kan fatta dynamiska beslut om att ändra routing av viss typ av trafik.

Således kan uppdraget med kombinationen DMVPN/PfR kort sammanfattas som följer:

• Möjliggöra för kunden att använda alla typer av kommunikationskanaler på WAN-nätverket.
• Säkerställa bästa möjliga kvalitet för viktiga applikationer över dessa kanaler.

Vad är Cisco SD-WAN?

Cisco SD-WAN är en teknologi som använder SDN-ansatsen för att skapa och driva organisationens WAN-nätverk. Detta innebär bland annat användning av så kallade kontroller (programkomponenter) som möjliggör centraliserad orkestrering och automatiserad konfiguration av alla komponenter i lösningen. Till skillnad från den klassiska SDN (i stil med Clean Slate) används flera olika typer av kontroller i Cisco SD-WAN, där varje har sin egen roll – detta görs med avsikt att säkerställa bättre skalbarhet och geo-redundans.

I fallet med SD-WAN kvarstår uppgiften att använda vilken typ av kanaler som helst och säkerställa driften av affärsapplikationer, men samtidigt utvidgas kraven på automatisering, skalbarhet, säkerhet och flexibilitet i nätverket.

Diskussion om skillnader

Om man nu börjar analysera skillnaderna mellan dessa teknologier, så kommer de att falla in under en av kategorierna:

• Arkitektoniska skillnader – hur är funktionerna fördelade mellan olika komponenter i lösningen, hur är samarbetet mellan dessa komponenter organiserat och hur påverkar detta teknikens möjligheter och flexibilitet?
• Funktionaliteter – vad kan en teknologi som den andra inte kan? Och hur viktigt är det?

Vad ligger bakom de arkitektoniska skillnaderna och är de verkligen viktiga?

I varje av de angivna teknologierna finns det många 'rörliga delar', vars roller och samverkan med varandra skiljer sig. Hur väl dessa principer är utformade påverkar direkt skalbarheten, motståndskraften mot fel och den övergripande effektiviteten hos lösningen.

Låt oss granska olika aspekter av arkitekturen mer i detalj:

Data-plane – en del av lösningen som ansvarar för att överföra användartrafik mellan källa och mottagare. I DMVPN och SD-WAN implementeras det i grunden likadant på själva routrarna som är baserade på Multipoint GRE-tunnlar. Skillnaden ligger i hur den nödvändiga uppsättningen av parametrar för dessa tunnlar bildas:

• på DMVPN/PfR – det är en strikt två-nivå hierarki av noder med en stjärntopologi eller Hub-n-Spoke. Statisk konfiguration av Hub och statisk koppling av Spoke till Hub är obligatoriskt, liksom samverkan via NHRP-protokollet för att bilda data-plane-konnektivitet. Som en följd, blir förändringar på Hub, relaterat till exempelvis ändringar/koppling av nya WAN-kanaler eller förändringar av befintliga parametrar, betydligt svårare.
• på SD-WAN – det är en helt dynamisk modell för att upptäcka parametrarna för de etablerade tunnlarna med stöd av control-plane (OMP-protokollet) och orchestration-plane (samverkan med vBond-kontrollern för upptäcktsuppgifter av kontroller och NAT-traversering). De pålagda topologierna kan vara vilka som helst, inklusive hierarkiska. Inom ramen för den etablerade pålagda tunneltopologin är det möjligt att flexibelt konfigurera den logiska topologin i varje individuell VPN (VRF).

Control-plane – funktioner för utbyte, filtrering och modifiering av routing- och annan information mellan komponenterna i lösningen.

• på DMVPN/PfR – sker endast mellan routrarna Hub och Spoke. Direkt utbyte av routinginformation mellan Spoke är omöjligt. Som en följd, utan en fungerande Hub kan control-plane och data-plane inte fungera., vilket ställer ytterligare krav på Hub för hög tillgänglighet, som inte alltid kan uppfyllas.
• på SD-WAN – kontrollplanet utförs aldrig direkt mellan routrar – interaktionen sker baserat på OMP-protokollet och måste alltid ske via en separat specialiserad typ av vSmart-kontroller, vilket möjliggör lastbalansering, geo-redundans och centraliserad hantering av signalbelastningen. En annan egenskap hos OMP-protokollet är dess betydande motståndskraft mot förluster och oberoende av hastigheten på kommunikationskanalen med kontrollerna (inom rimliga gränser, så klart). Detta gör det möjligt att placera SD-WAN-kontroller i offentliga eller privata moln med åtkomst via Internet.

Policy-plan – den del av lösningen som ansvarar för definiering, spridning och tillämpning av trafikstyrningspolicyer över det distribuerade nätverket.

• DMVPN – är faktiskt begränsat av kvalitetsservicepolicyer (QoS), som konfigureras individuellt på varje router via CLI eller Prime Infrastructure-mallar.
• DMVPN/PfR – PfR-policyer skapas på den centraliserade routern Master Controller (MC) via CLI och sprids automatiskt till filialernas MC. Här används samma vägar för spridning av policyn som för dataplanen. Det finns inga möjligheter att separera utbyte av policyer, ruttinformation och användardata. Spridningen av policyer förutsätter att det finns IP-kontinuitet mellan Hub och Spoke. Dessutom kan MC:s funktion kombineras med DMVPN-routern vid behov. Användning av Prime Infrastructure-mallar för centraliserad policyformulering är möjligt (men inte obligatoriskt). En viktig egenskap är att policyn formuleras globalt på hela nätverket på samma sätt – individuella policyer för separata segment stöds inte..
• SD-WAN – trafik- och servicemekanismer styrs centralt via det grafiska gränssnittet Cisco vManage, vilket även är tillgängligt över Internet (vid behov). De sprids över signal kanaler direkt eller indirekt genom vSmart-kontroller (beroende på typ av policy). De beror inte på data-plane-anslutning mellan routrarna, eftersom de använder alla tillgängliga vägar för att överföra trafik mellan kontroller och router.

  För olika nätverkssegment är det möjligt att flexibelt utforma olika policys – tillämpningsområdet för policyn definieras av ett antal unika identifierare som finns i lösningen – kontorsnummer, typ av applikation, trafikflödesriktning, etc.

Orkestreringsplan – mekanismer som gör det möjligt för komponenter att dynamiskt upptäcka varandra, konfigurera och samordna efterföljande interaktioner.

• på DMVPN/PfR Ömsesidig upptäckte mellan routrarna baseras på statisk konfiguration av Hub-enheter och motsvarande inställningar av Spoke-enheter. Dynamisk upptäckte sker endast för Spoke, som rapporterar sina anslutningsparametrar till Hub-enheten, som i sin tur redan är inlagd i Spokes konfiguration. Utan IP-anslutning mellan Spoke och minst en Hub är det omöjligt att bilda varken data-plane eller control-plane.
• på SD-WAN Orkestreringen av lösningens komponenter sker med hjälp av kontrollern vBond, med vilken varje komponent (routrar och kontroller vManage/vSmart) måste först etablera IP-anslutning.

  Inledningsvis känner komponenterna inte till varandras anslutningsparametrar – för detta behöver de en förmedlare, orkestratorn vBond. Den allmänna principen är följande – varje komponent i det inledande skedet får (automatiskt eller statiskt) endast information om anslutningsparametrarna till vBond, sedan meddelar vBond routern om kontrollerna vManage och vSmart (som upptäcktes tidigare), vilket gör det möjligt att automatiskt etablera alla nödvändiga signalanslutningar.

  Nästa steg är att den nya routern lär sig om de övriga routrarna i nätverket genom OMP-utbyte med vSmart-kontrollern. På så sätt kan routern, utan att från början veta något om nätverksparametrarna, helt automatiskt upptäcka och ansluta till kontrollorna samt därefter också automatiskt upptäcka och skapa anslutningar med de övriga routrarna. Vid det här laget är anslutningsparametrarna för alla komponenter ursprungligen okända och kan förändras under drift.

Management-plan – den del av lösningen som möjliggör centraliserad hantering och övervakning.

• DMVPN/PfR – en specialiserad management-planlösning är inte tillgänglig. För grundläggande automatisering och övervakning kan produkter som Cisco Prime Infrastructure användas. Varje router har möjlighet till hantering via kommandoradsgränssnittet CLI. Integrationer med externa system via API är inte tillgängliga.
• SD-WAN – all typisk interaktion och övervakning sker centraliserat via det grafiska gränssnittet vManage. Alla lösningens funktioner, utan undantag, är tillgängliga för konfiguration via vManage, såväl som genom ett fullständigt dokumenterat REST API-bibliotek.

  Alla inställningar för SD-WAN-nätverket i vManage sammanfattas i två grundläggande konstruktioner – skapande av enhetsmallar (Device Template) och skapande av policyer som definierar nätverkslogiken och trafikhantering. Genom att vManage, efter att ha översatt den av administratören skapade policyn, automatiskt väljer vilka ändringar och på vilka individuella enheter/kontroller som behöver göras, förbättras effektiviteten och skalbarheten av lösningen avsevärt.

  Genom vManage-gränssnittet är det inte bara möjligt att konfigurera Cisco SD-WAN-lösningen, utan även att helt övervaka statusen för alla komponenter i lösningen, inklusive den aktuella statusen för mätvärdena för enskilda tunnlar och användningsstatistik för olika applikationer baserat på DPI-analys.

  Trots att interaktionen är centraliserad, har alla komponenter (kontroller och routrar) också en fullt fungerande kommandorad CLI, som är nödvändig under implementeringsfasen eller vid nödsituationer för lokal diagnostik. I normalläge (med en signal kanal mellan komponenterna) är kommandoraden på routrarna endast tillgänglig för diagnostik och inte för att göra lokala ändringar, något som garanterar både lokal säkerhet och en enda källa för förändringar i ett sådant nätverk – vManage.

Integrerad säkerhet – här handlar det inte bara om att skydda användardata under överföring via öppna kanaler, utan också om den övergripande säkerheten för WAN-nätverket baserat på den valda teknologin.

• på DMVPN/PfR det finns möjlighet till kryptering av användardata och signalprotokoll. Vid användning av vissa modeller av routrar är även brandväggsfunktioner med trafikinspektion, IPS/IDS tillgängliga. Det finns möjlighet till segmentering av filialnätverken med hjälp av VRF. Det finns möjlighet till autentisering (enfaktor) av kontrollprotokollen.

  Samtidigt betraktas den fjärranslutna routern som en betrodd enhet i nätverket som standard – dvs. fall av fysisk kompromettering av enskilda enheter och möjligheten för obehörig åtkomst till dem beaktas inte, det finns ingen tvåfaktorsautentisering av komponenterna i lösningen, vilket i fallet med ett geografiskt distribuerat nätverk kan medföra allvarliga ytterligare risker.

• på SD-WAN På liknande sätt som DMVPN erbjuder kryptering av användardata, men med betydligt utvidgade funktioner för nätverkssäkerhet och L3/VRF-segmentering (MSP, IPS/IDS, URL-filtrering, DNS-filtrering, AMP/TG, SASE, TLS/SSL-proxy osv.). Samtidigt sker nyckelutbytet för kryptering mer effektivt via vSmart-kontroller (inte direkt), genom förutbestämda signal kanaler som skyddas av DTLS/TLS-kryptering baserat på säkerhetscertifikat. Detta säkerställer säkerheten för sådant utbyte och möjliggör bättre skalbarhet av lösningen, upp till tiotusentals enheter i ett och samma nätverk.

  Alla signalanslutningar (kontroller-kontroller, kontroller-router) är också skyddade med hjälp av DTLS/TLS. Routrar levereras med säkerhetscertifikat vid tillverkning, med möjlighet till byte/förlängning. Tvåfaktorsautentisering uppnås genom att två villkor måste uppfyllas samtidigt för att routern/kontrollern ska kunna fungera i ett SD-WAN-nätverk:

  • Giltigt säkerhetscertifikat
  • Tydligt och medvetet att varje komponent ska läggas till av administratören i den "vita" listan över tillåtna enheter.

Funktionsskillnader mellan SD-WAN och DMVPN/PfR

När vi börjar diskutera funktionsskillnaderna, är det viktigt att notera att många av dessa är en fortsättning på arkitektur — det är ingen hemlighet att utvecklarna baserar arkitekturen på de funktioner de vill uppnå i slutändan. Låt oss titta på de mest betydelsefulla skillnaderna mellan de två teknologierna.

AppQ (Application Quality) – funktioner för att säkerställa kvaliteten på trafiköverföring för affärsapplikationer

De centrala funktionerna hos de behandlade teknologierna syftar till att förbättra användarupplevelsen så mycket som möjligt när man använder affärskritiska applikationer i ett distribuerat nätverk. Detta är särskilt viktigt under omständigheter där en del av infrastrukturen inte kontrolleras av IT eller ens garanterar en framgångsrik dataöverföring.

DMVPN tillhandahåller inte sådana mekanismer på egen hand. Det bästa som kan göras i ett klassiskt DMVPN-nätverk är att klassificera utgående trafik efter applikationer och prioritera den vid överföring mot WAN-kanalen. Valet av DMVPN-tunnel baseras i detta fall enbart på dess tillgänglighet och resultatet av routningsprotokollen. Samtidigt beaktas inte det övergripande tillståndet för vägen/tunneln och dess möjliga partiella nedgradering utifrån viktiga mätvärden som är signifikanta för nätverksapplikationer – fördröjning, fördröjningsvariation (jitter) och förluster (%). Därför förlorar en direkt jämförelse av klassisk DMVPN med SD-WAN i termer av att lösa AppQ-uppgifter all mening – DMVPN kan inte lösa den uppgiften. När Cisco Performance Routing (PfR) läggs till i denna kontext förändras situationen och jämförelsen med Cisco SD-WAN blir mer meningsfull.

Innan vi går vidare till att diskutera skillnaderna, låt oss kort sammanfatta vad teknologierna har gemensamt. Så, båda teknologierna:

• har en mekanism som gör det möjligt att dynamiskt bedöma tillståndet för varje etablerad tunnel utifrån vissa mätvärden – åtminstone fördröjning, variation i fördröjning och paketförluster (%)
• använder en viss uppsättning verktyg för att skapa, distribuera och tillämpa regler (policyer) för trafikhantering med hänsyn till resultatet av mätningarna av de nyckelmetrik som rör tunnlarna.
• klassificerar applikationstrafik på nivåerna L3-L4 (DSCP) i OSI-modellen eller enligt L7-signaturer för applikationer baserat på inbyggda DPI-mekanismer i routern.
• möjliggör för betydande applikationer att definiera acceptabla tröskelvärden för metrik, standardregler för trafiköverföring och regler för omdirigering av trafik vid överskridande av tröskelvärden.
• vid inkapsling av trafik i GRE/IPSec använder den en redan etablerad mekanism i branschen för att överföra den interna DSCP-märkningen till det externa GRE/IPSec-paketets huvud, vilket gör det möjligt att synkronisera QoS-policyer mellan organisationen och tjänsteleverantören (om en motsvarande SLA finns).

Hur skiljer sig mekanismerna för att bedöma de end-to-end-metrik som SD-WAN och DMVPN/PfR använder?

DMVPN/PfR

• För att bedöma de standardiserade metrik som rör tunnelns tillstånd används både aktiva och passiva mjukvarusensorer (Probes). Aktiva - baserat på användartjänstetrafik, passiva emulerar sådan trafik (när ingen finns).
• Fina inställningar av tidtagare och villkor för att upptäcka försämringar saknas – algoritmen är fast.
• Dessutom finns möjligheten att mäta den använda bandbredden i utåtgående riktning. Detta ger DMVPN/PfR ytterligare flexibilitet i trafikhantering.
• Samtidigt förlitar sig vissa mekanismer i PfR vid överskridande av metrik på återkopplande signalering i form av speciella TCA (Threshold Crossing Alert) meddelanden, som måste komma från trafikmottagaren tillbaka till källan, vilket i sin tur förutsätter att tillstånden hos de mätkanaler som är aktuella måste vara åtminstone tillräckliga för att kunna överföra sådana TCA-meddelanden. Det är i de flesta fall inget problem, men kan uppenbarligen inte garanteras.

SD-WAN

• För att göra en helhetsbedömning av standardmetrik för tunnelns tillstånd används BFD-protokollet i echo-läge. Här krävs ingen speciell återkoppling i form av TCA eller liknande meddelanden – domänerna för felhantering hålls isolerade. Användartrafik behöver inte vara närvarande för att bedöma tunnelns tillstånd.
• Det finns möjlighet till finjustering av BFD-timerar för att reglera hastigheten av reaktioner och algoritmens känslighet för nedgångar i kommunikationskanalen från några sekunder till minuter.

  

• Vid tidpunkten för artikelns skrivande finns det endast en BFD-session i varje tunnel. Detta kan potentiellt skapa en lägre granuleringsnivå vid analysen av tunnelns tillstånd. I praktiken kan detta bli en begränsning endast vid användning av WAN-anslutning baserad på MPLS L2/L3 VPN med ett överenskommet QoS SLA – om DSCP-märkning av BFD-trafiken (efter inkapsling i IPSec/GRE) sammanfaller med högprioriterad kö i operatörens nätverk, kan detta påverka noggrannheten och hastigheten för att upptäcka nedgångar för lågprioriterad trafik. Det finns emellertid möjlighet att ändra BFD-märket som standard för att minska risken för sådana situationer. I framtida versioner av Cisco SD-WAN förväntas mer finslipning av BFD, samt möjlighet att starta flera BFD-sessioner inom en tunnel med individuella DSCP-värden (för olika applikationer).
• BFD möjliggör dessutom bedömning av den största paketstorleken som kan överföras genom en tunnel utan fragmentering. Detta gör att SD-WAN kan justera parametrar som MTU och TCP MSS Adjust dynamiskt för att effektivt utnyttja den tillgängliga bandbredden på varje kanal.
• I SD-WAN finns även alternativet att synkronisera QoS med operatörer inte bara baserat på L3 DSCP-fältet, utan även baserat på L2 CoS-värden, som kan bildas automatiskt i det lokala nätverket av specialiserade enheter — till exempel IP-telefoner.

Hur skiljer sig möjligheterna, metoderna för bestämning och tillämpning av AppQ-policys?

Policys för DMVPN/PfR:

• Definieras på central filialrouter(-arna) (CF) via kommandoradsgränssnittet CLI eller CLI-mallkonfigurationer. Skapande av CLI-mallar kräver förberedelse och kunskap om policyernas syntax.

  

• Definieras globalt utan möjlighet till anpassning/ändringar för individuella nätverkssegment.
• Interaktivt skapande av policys via grafiskt gränssnitt stöds inte.
• Ändringar, arv, skapande av flera versioner av policys för snabb omkoppling stöds inte.
• Sprids automatiskt på routrar i fjärrkontor. Samma kommunikationskanaler används som för överföring av användardata. Om det inte finns någon kommunikationskanal mellan huvudkontoret och det fjärrkontor, är spridning/ändring av policys omöjlig.
• Tillämpas på varje router och modifierar vid behov resultaten av standard routingprotokoll med högre prioritet.
• För fall där alla WAN-kanaler på kontoret upplever betydande trafikförluster, finns inga kompensationsmekanismer..

SD-WAN-policys:

• Definieras i det grafiska gränssnittet vManage genom en interaktiv mallguid.
• Stöder skapande av flera policys, kopiering, arv, samt omkoppling mellan policys i realtid.
• Stöder anpassning av policyn för olika nätverkssegment (kontor).
• Sprids via vilken tillgänglig signal kanal som helst mellan kontrollern och routern och/eller vSmart – de är inte direkt beroende av dataplansanslutning mellan routrarna. Det krävs dock IP-anslutning mellan routern och kontrollerna.

  

• För fall där alla tillgängliga kanaler på kontoret upplever betydande datarförluster, som överstiger acceptabla tröskelvärden för kritiska applikationer, kan ytterligare mekanismer som ökar tillförlitligheten för överföring användas:
  • FEC (Forward Error Correction) – använder en speciell algoritm för överskottkodning. Vid överföring av kritisk trafik över kanaler med en betydande procentandel förluster kan FEC automatiskt aktiveras och tillåta återställande av förlorad data vid behov. Användningen av bandbredd ökar något men tillförlitligheten ökar avsevärt.

    

  • Duplicering av datastreamar – utöver FEC kan policyn inkludera automatisk duplikering av trafik för valda applikationer i händelse av en ännu allvarligare förlustnivå som inte kan kompenseras av FEC. I detta fall kommer de valda uppgifterna att skickas över alla tunnlar mot mottagande filial med efterföljande deduplicering (borttagning av överflödiga paketkopior). Mekanismen ökar avsevärt utnyttjandet av kanaler, men stärker också avsevärt pålitligheten i överföringen.

Möjligheter med Cisco SD-WAN, utan direkta motsvarigheter i DMVPN/PfR

Arkitekturen för Cisco SD-WAN-lösningen möjliggör i vissa fall funktioner vars implementering inom DMVPN/PfR antingen är extremt svår, inte kostnadseffektiv på grund av nödvändigt arbete, eller helt omöjlig. Låt oss titta på de mest intressanta av dem:

Traffic-Engineering (TE)

TE inkluderar mekanismer som gör det möjligt att avleda trafik från den standardväg som skapats av routningsprotokoll. TE används ofta för att säkerställa hög tillgänglighet av nätverkstjänster, genom att snabbt och/eller i förväg omdirigera viktig trafik till en alternativ (icke-överlappande) överföringsväg, med syftet att förbättra kvaliteten på tjänsten eller hastigheten för återställning vid ett fel på huvudvägen.

Svårigheten med att implementera TE ligger i att det kräver att en alternativ väg beräknas och reserveras i förväg. I MPLS-nätverk för teleoperatörer hanteras denna uppgift genom att använda teknologier som MPLS Traffic Engineering med utvidgningar av IGP-protokoll och RSVP-protokollet. På senaste tid har även Segment Routing-teknologin blivit alltmer populär, vilket är mer optimerat för centraliserad konfiguration och orkestrering. I klassiska WAN-nätverk är dessa teknologier vanligtvis inte representerade eller reducerade till hop-by-hop-mekanismer som Policy-Based Routing (PBR), som kan styra trafik men implementerar detta på varje router separat – utan att ta hänsyn till nätverkets övergripande tillstånd eller resultatet av PBR i tidigare eller senare steg. Resultatet av dessa TE-alternativ är nedslående – MPLS TE används vanligtvis bara i den mest kritiska delen av nätverket (kärnan) på grund av den komplexitet som krävs för konfiguration och drift, och PBR används på enskilda routrar utan möjlighet att formulera en enhetlig PBR-policy för hela nätverket. Detta gäller uppenbarligen också nätverk baserade på DMVPN.

SD-WAN erbjuder i detta avseende en mycket mer elegant lösning som inte bara är lätt att konfigurera, utan också skalar betydligt bättre. Detta är resultatet av de använda arkitekturerna för control-plane och policy-plane. Implementeringen av policy-plane i SD-WAN gör det möjligt att centralt definiera TE-policyn – vilken trafik är av intresse? För vilka VPN? Genom vilka noder/tunnlar är det nödvändigt eller förbjudet att skapa en alternativ rutt? Å sin sida gör centraliseringen av control-plane-hanteringen baserad på vSmart-kontrollrar att routingresultaten kan modifieras utan att kräva inställningar på enskilda enheter – routrarna ser bara resultatet av den logik som har skapats i vManage-gränssnittet och överförts för tillämpning på vSmart.

Service-chaining (Sertjänster)

Att bilda tjänstekedjor är en ännu mer arbetsintensiv uppgift i klassisk routing än den redan beskrivna mekanismen Traffic Engineering. I detta fall är det nödvändigt att inte bara skapa en speciell rutt för en viss nätverksapplikation, utan även möjliggöra trafikavledning från nätverket vid bestämda (eller alla) noder inom SD-WAN-nätverket för behandling av en specifik applikation eller tjänst (MPLS, Belastningsbalansering, Caching, Trafikinspektion osv.). Samtidigt krävs möjlighet att övervaka tillståndet hos dessa externa tjänster för att undvika black-holing-situationer, samt mekanismer som tillåter placering av sådana homogena externa tjänster på olika geo-lokationer med möjlighet för nätverket att automatiskt välja den mest optimala servicepunkten för behandling av trafik från olika filialer. I fallet med Cisco SD-WAN är det ganska enkelt att uppnå genom att skapa en motsvarande centraliserad policy som

överbryggar alla aspekter av den målsatta tjänstekedjan till en helhet och automatiskt ändrar logiken för dataplanen och kontrollplanen endast där och när det behövs.

Vad blir resultatet?

Det är uppenbart att både DMVPN (tillsammans med eller utan Performance Routing) och Cisco SD-WAN löser i slutändan mycket liknande uppgifter i förhållande till organisationens distribuerade WAN-nät. De betydande arkitektoniska och funktionella skillnaderna i Cisco SD-WAN-teknologin höjer processen för att lösa dessa problem till en annan kvalitetsnivå. Sammanfattningsvis kan följande viktiga skillnader mellan SD-WAN och DMVPN/PfR noteras:

• DMVPN/PfR använder i allmänhet beprövade teknologier för att bygga överlagrade VPN-nätverk och är i fråga om data-plan liknande den mer moderna SD-WAN-teknologin, men det finns vissa begränsningar i form av obligatorisk statisk konfiguration av routrar och valet av topologier är begränsat till Hub-n-Spoke. Å andra sidan har DMVPN/PfR vissa funktioner som ännu inte är tillgängliga inom SD-WAN (det handlar om per-application BFD).
• Inom control-plane skiljer sig teknologierna grundligt åt. Med centraliserad behandling av signalprotokoll gör SD-WAN det möjligt att bland annat avsevärt minska felfält och ’koppla loss’ processen för överföring av användartrafik från signalinteraktionen – tillfällig otillgänglighet av kontrollerarna påverkar inte möjligheten att överföra användartrafik. Samtidigt påverkar tillfällig otillgänglighet av någon filial (inklusive den centrala) inte möjligheten för de övriga filialerna att interagera med varandra och kontrollerarna.
• Arkitekturen för att skapa och tillämpa trafikhanteringspolicyer vid SD-WAN överträffar också den i DMVPN/PfR – geo-redundans är betydligt bättre implementerad, det finns ingen koppling till Hub, fler möjligheter för finjustering av policyer, och listan över genomförda trafikhanteringsscenarier är också betydligt större.
• Processen för orkestrering av lösningen skiljer sig också avsevärt. DMVPN förutsätter att det finns i förväg kända parametrar som på något sätt måste återspeglas i konfigurationen, vilket något begränsar flexibiliteten i lösningen och möjligheten till dynamiska förändringar. Å sin sida utgår SD-WAN från en paradigm där routern i den initiala tidpunkten för anslutning ’inte vet något’ om sina kontrollerare, men vet ’vem man kan fråga’ – detta är tillräckligt för inte bara att automatiskt etablera kontakt med kontrollerarna, utan även för att automatiskt sätta upp en helt sammanlänkad data-plan topologi som sedan kan justeras/ändras flexibelt med hjälp av policyer.
• När det gäller centraliserad hantering, automatisering och övervakning överträffar SD-WAN förväntat möjligheterna hos DMVPN/PfR, som är resultatet av utvecklingen av klassiska teknologier och i större utsträckning förlitar sig på kommandoradsgränssnitt (CLI) samt användning av NMS-system baserade på mallar.
• I jämförelse med DMVPN har säkerhetskraven i SD-WAN nått en annan kvalitetsnivå. De främsta principerna är nolltillit, skalbarhet och tvåfaktorsautentisering.

Av dessa enkla slutsatser kan man få en felaktig uppfattning om att skapandet av nätverk baserat på DMVPN/PfR idag har förlorat all relevans. Det är dock inte helt sant. Till exempel, i fall där det finns ett flertal gammalt utrustning och inget sätt att ersätta det, kan DMVPN möjliggöra en integration av "gamla" och "nya" enheter i ett enhetligt geo-distribuerat nätverk med många av de fördelar som beskrivits ovan.

Å andra sidan bör man komma ihåg att alla nuvarande företagsroutrar från Cisco baserade på IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) idag stöder alla driftsätt – både klassisk routing, DMVPN och SD-WAN. Valet baseras på aktuella behov och förståelsen av att på samma utrustning kan man när som helst börja gå mot en mer avancerad teknologi.

Källa: habr.com