Funktionaliteter \u2013 vad kan en teknologi som den andra inte kan? Och hur viktigt \u00e4r det?<\/li>\n<\/ul>\n<\/p>\n
Vad ligger bakom de arkitektoniska skillnaderna och \u00e4r de verkligen viktiga?<\/h3>\n \nI varje av de angivna teknologierna finns det m\u00e5nga 'r\u00f6rliga delar', vars roller och samverkan med varandra skiljer sig. Hur v\u00e4l dessa principer \u00e4r utformade p\u00e5verkar direkt skalbarheten, motst\u00e5ndskraften mot fel och den \u00f6vergripande effektiviteten hos l\u00f6sningen. <\/p>\n
L\u00e5t oss granska olika aspekter av arkitekturen mer i detalj:<\/p>\n
Data-plane<\/b> \u2013 en del av l\u00f6sningen som ansvarar f\u00f6r att \u00f6verf\u00f6ra anv\u00e4ndartrafik mellan k\u00e4lla och mottagare. I DMVPN och SD-WAN implementeras det i grunden likadant p\u00e5 sj\u00e4lva routrarna som \u00e4r baserade p\u00e5 Multipoint GRE-tunnlar. Skillnaden ligger i hur den n\u00f6dv\u00e4ndiga upps\u00e4ttningen av parametrar f\u00f6r dessa tunnlar bildas:<\/p>\n\np\u00e5 DMVPN\/PfR<\/b> \u2013 det \u00e4r en strikt tv\u00e5-niv\u00e5 hierarki av noder med en stj\u00e4rntopologi eller Hub-n-Spoke. Statisk konfiguration av Hub och statisk koppling av Spoke till Hub \u00e4r obligatoriskt, liksom samverkan via NHRP-protokollet f\u00f6r att bilda data-plane-konnektivitet. Som en f\u00f6ljd, blir f\u00f6r\u00e4ndringar p\u00e5 Hub<\/b>, relaterat till exempelvis \u00e4ndringar\/koppling av nya WAN-kanaler eller f\u00f6r\u00e4ndringar av befintliga parametrar, betydligt sv\u00e5rare.<\/li>\np\u00e5 SD-WAN<\/b> \u2013 det \u00e4r en helt dynamisk modell f\u00f6r att uppt\u00e4cka parametrarna f\u00f6r de etablerade tunnlarna med st\u00f6d av control-plane (OMP-protokollet) och orchestration-plane (samverkan med vBond-kontrollern f\u00f6r uppt\u00e4cktsuppgifter av kontroller och NAT-traversering). De p\u00e5lagda topologierna kan vara vilka som helst, inklusive hierarkiska. Inom ramen f\u00f6r den etablerade p\u00e5lagda tunneltopologin \u00e4r det m\u00f6jligt att flexibelt konfigurera den logiska topologin i varje individuell VPN (VRF).<\/li>\n<\/ul>\n Control-plane<\/b> \u2013 funktioner f\u00f6r utbyte, filtrering och modifiering av routing- och annan information mellan komponenterna i l\u00f6sningen. <\/p>\n\np\u00e5 DMVPN\/PfR<\/b> \u2013 sker endast mellan routrarna Hub och Spoke. Direkt utbyte av routinginformation mellan Spoke \u00e4r om\u00f6jligt. Som en f\u00f6ljd, utan en fungerande Hub kan control-plane och data-plane inte fungera.<\/b>, vilket st\u00e4ller ytterligare krav p\u00e5 Hub f\u00f6r h\u00f6g tillg\u00e4nglighet, som inte alltid kan uppfyllas.<\/li>\np\u00e5 SD-WAN<\/b> \u2013 kontrollplanet utf\u00f6rs aldrig direkt mellan routrar \u2013 interaktionen sker baserat p\u00e5 OMP-protokollet och m\u00e5ste alltid ske via en separat specialiserad typ av vSmart-kontroller, vilket m\u00f6jligg\u00f6r lastbalansering, geo-redundans och centraliserad hantering av signalbelastningen. En annan egenskap hos OMP-protokollet \u00e4r dess betydande motst\u00e5ndskraft mot f\u00f6rluster och oberoende av hastigheten p\u00e5 kommunikationskanalen med kontrollerna (inom rimliga gr\u00e4nser, s\u00e5 klart). Detta g\u00f6r det m\u00f6jligt att placera SD-WAN-kontroller i offentliga eller privata moln med \u00e5tkomst via Internet.<\/li>\n<\/ul>\n Policy-plan<\/b> \u2013 den del av l\u00f6sningen som ansvarar f\u00f6r definiering, spridning och till\u00e4mpning av trafikstyrningspolicyer \u00f6ver det distribuerade n\u00e4tverket.<\/p>\n\nDMVPN <\/b>\u2013 \u00e4r faktiskt begr\u00e4nsat av kvalitetsservicepolicyer (QoS), som konfigureras individuellt p\u00e5 varje router via CLI eller Prime Infrastructure-mallar.<\/li>\nDMVPN\/PfR<\/b> \u2013 PfR-policyer skapas p\u00e5 den centraliserade routern Master Controller (MC) via CLI och sprids automatiskt till filialernas MC. H\u00e4r anv\u00e4nds samma v\u00e4gar f\u00f6r spridning av policyn som f\u00f6r dataplanen. Det finns inga m\u00f6jligheter att separera utbyte av policyer, ruttinformation och anv\u00e4ndardata. Spridningen av policyer f\u00f6ruts\u00e4tter att det finns IP-kontinuitet mellan Hub och Spoke. Dessutom kan MC:s funktion kombineras med DMVPN-routern vid behov. Anv\u00e4ndning av Prime Infrastructure-mallar f\u00f6r centraliserad policyformulering \u00e4r m\u00f6jligt (men inte obligatoriskt). En viktig egenskap \u00e4r att policyn formuleras globalt p\u00e5 hela n\u00e4tverket p\u00e5 samma s\u00e4tt \u2013 individuella policyer f\u00f6r separata segment st\u00f6ds inte.<\/b>.<\/li>\nSD-WAN<\/b> \u2013 trafik- och servicemekanismer styrs centralt via det grafiska gr\u00e4nssnittet Cisco vManage, vilket \u00e4ven \u00e4r tillg\u00e4ngligt \u00f6ver Internet (vid behov). De sprids \u00f6ver signal kanaler direkt eller indirekt genom vSmart-kontroller (beroende p\u00e5 typ av policy). De beror inte p\u00e5 data-plane-anslutning mellan routrarna, eftersom de anv\u00e4nder alla tillg\u00e4ngliga v\u00e4gar f\u00f6r att \u00f6verf\u00f6ra trafik mellan kontroller och router.\n F\u00f6r olika n\u00e4tverkssegment \u00e4r det m\u00f6jligt att flexibelt utforma olika policys \u2013 till\u00e4mpningsomr\u00e5det f\u00f6r policyn definieras av ett antal unika identifierare som finns i l\u00f6sningen \u2013 kontorsnummer, typ av applikation, trafikfl\u00f6desriktning, etc.\n<\/li>\n<\/ul>\n
Orkestreringsplan<\/b> \u2013 mekanismer som g\u00f6r det m\u00f6jligt f\u00f6r komponenter att dynamiskt uppt\u00e4cka varandra, konfigurera och samordna efterf\u00f6ljande interaktioner.<\/p>\n\np\u00e5 DMVPN\/PfR<\/b> \u00d6msesidig uppt\u00e4ckte mellan routrarna baseras p\u00e5 statisk konfiguration av Hub-enheter och motsvarande inst\u00e4llningar av Spoke-enheter. Dynamisk uppt\u00e4ckte sker endast f\u00f6r Spoke, som rapporterar sina anslutningsparametrar till Hub-enheten, som i sin tur redan \u00e4r inlagd i Spokes konfiguration. Utan IP-anslutning mellan Spoke och minst en Hub \u00e4r det om\u00f6jligt att bilda varken data-plane eller control-plane.<\/b><\/li>\np\u00e5 SD-WAN<\/b> Orkestreringen av l\u00f6sningens komponenter sker med hj\u00e4lp av kontrollern vBond, med vilken varje komponent (routrar och kontroller vManage\/vSmart) m\u00e5ste f\u00f6rst etablera IP-anslutning.\n Inledningsvis k\u00e4nner komponenterna inte till varandras anslutningsparametrar \u2013 f\u00f6r detta beh\u00f6ver de en f\u00f6rmedlare, orkestratorn vBond. Den allm\u00e4nna principen \u00e4r f\u00f6ljande \u2013 varje komponent i det inledande skedet f\u00e5r (automatiskt eller statiskt) endast information om anslutningsparametrarna till vBond, sedan meddelar vBond routern om kontrollerna vManage och vSmart (som uppt\u00e4cktes tidigare), vilket g\u00f6r det m\u00f6jligt att automatiskt etablera alla n\u00f6dv\u00e4ndiga signalanslutningar. <\/p>\n
N\u00e4sta steg \u00e4r att den nya routern l\u00e4r sig om de \u00f6vriga routrarna i n\u00e4tverket genom OMP-utbyte med vSmart-kontrollern. P\u00e5 s\u00e5 s\u00e4tt kan routern, utan att fr\u00e5n b\u00f6rjan veta n\u00e5got om n\u00e4tverksparametrarna, helt automatiskt uppt\u00e4cka och ansluta till kontrollorna samt d\u00e4refter ocks\u00e5 automatiskt uppt\u00e4cka och skapa anslutningar med de \u00f6vriga routrarna. Vid det h\u00e4r laget \u00e4r anslutningsparametrarna f\u00f6r alla komponenter ursprungligen ok\u00e4nda och kan f\u00f6r\u00e4ndras under drift.\n<\/li>\n<\/ul>\n
Management-plan<\/b> \u2013 den del av l\u00f6sningen som m\u00f6jligg\u00f6r centraliserad hantering och \u00f6vervakning.<\/p>\n\nDMVPN\/PfR<\/b> \u2013 en specialiserad management-planl\u00f6sning \u00e4r inte tillg\u00e4nglig. F\u00f6r grundl\u00e4ggande automatisering och \u00f6vervakning kan produkter som Cisco Prime Infrastructure anv\u00e4ndas. Varje router har m\u00f6jlighet till hantering via kommandoradsgr\u00e4nssnittet CLI. Integrationer med externa system via API \u00e4r inte tillg\u00e4ngliga.<\/b><\/li>\nSD-WAN<\/b> \u2013 all typisk interaktion och \u00f6vervakning sker centraliserat via det grafiska gr\u00e4nssnittet vManage. Alla l\u00f6sningens funktioner, utan undantag, \u00e4r tillg\u00e4ngliga f\u00f6r konfiguration via vManage, s\u00e5v\u00e4l som genom ett fullst\u00e4ndigt dokumenterat REST API-bibliotek.\n Alla inst\u00e4llningar f\u00f6r SD-WAN-n\u00e4tverket i vManage sammanfattas i tv\u00e5 grundl\u00e4ggande konstruktioner \u2013 skapande av enhetsmallar (Device Template) och skapande av policyer som definierar n\u00e4tverkslogiken och trafikhantering. Genom att vManage, efter att ha \u00f6versatt den av administrat\u00f6ren skapade policyn, automatiskt v\u00e4ljer vilka \u00e4ndringar och p\u00e5 vilka individuella enheter\/kontroller som beh\u00f6ver g\u00f6ras, f\u00f6rb\u00e4ttras effektiviteten och skalbarheten av l\u00f6sningen avsev\u00e4rt.<\/p>\n
Genom vManage-gr\u00e4nssnittet \u00e4r det inte bara m\u00f6jligt att konfigurera Cisco SD-WAN-l\u00f6sningen, utan \u00e4ven att helt \u00f6vervaka statusen f\u00f6r alla komponenter i l\u00f6sningen, inklusive den aktuella statusen f\u00f6r m\u00e4tv\u00e4rdena f\u00f6r enskilda tunnlar och anv\u00e4ndningsstatistik f\u00f6r olika applikationer baserat p\u00e5 DPI-analys.<\/p>\n
Trots att interaktionen \u00e4r centraliserad, har alla komponenter (kontroller och routrar) ocks\u00e5 en fullt fungerande kommandorad CLI, som \u00e4r n\u00f6dv\u00e4ndig under implementeringsfasen eller vid n\u00f6dsituationer f\u00f6r lokal diagnostik. I normall\u00e4ge (med en signal kanal mellan komponenterna) \u00e4r kommandoraden p\u00e5 routrarna endast tillg\u00e4nglig f\u00f6r diagnostik och inte f\u00f6r att g\u00f6ra lokala \u00e4ndringar, n\u00e5got som garanterar b\u00e5de lokal s\u00e4kerhet och en enda k\u00e4lla f\u00f6r f\u00f6r\u00e4ndringar i ett s\u00e5dant n\u00e4tverk \u2013 vManage.<\/li>\n<\/ul>\n
\nIntegrerad s\u00e4kerhet<\/b> \u2013 h\u00e4r handlar det inte bara om att skydda anv\u00e4ndardata under \u00f6verf\u00f6ring via \u00f6ppna kanaler, utan ocks\u00e5 om den \u00f6vergripande s\u00e4kerheten f\u00f6r WAN-n\u00e4tverket baserat p\u00e5 den valda teknologin.<\/p>\n\np\u00e5 DMVPN\/PfR<\/b> det finns m\u00f6jlighet till kryptering av anv\u00e4ndardata och signalprotokoll. Vid anv\u00e4ndning av vissa modeller av routrar \u00e4r \u00e4ven brandv\u00e4ggsfunktioner med trafikinspektion, IPS\/IDS tillg\u00e4ngliga. Det finns m\u00f6jlighet till segmentering av filialn\u00e4tverken med hj\u00e4lp av VRF. Det finns m\u00f6jlighet till autentisering (enfaktor) av kontrollprotokollen.\n Samtidigt betraktas den fj\u00e4rranslutna routern som en betrodd enhet i n\u00e4tverket som standard \u2013 dvs. fall av fysisk kompromettering av enskilda enheter och m\u00f6jligheten f\u00f6r obeh\u00f6rig \u00e5tkomst till dem beaktas inte, det finns ingen tv\u00e5faktorsautentisering av komponenterna i l\u00f6sningen, vilket i fallet med ett geografiskt distribuerat n\u00e4tverk kan medf\u00f6ra allvarliga ytterligare risker.<\/b> <\/li>\np\u00e5 SD-WAN<\/b> P\u00e5 liknande s\u00e4tt som DMVPN erbjuder kryptering av anv\u00e4ndardata, men med betydligt utvidgade funktioner f\u00f6r n\u00e4tverkss\u00e4kerhet och L3\/VRF-segmentering (MSP, IPS\/IDS, URL-filtrering, DNS-filtrering, AMP\/TG, SASE, TLS\/SSL-proxy osv.). Samtidigt sker nyckelutbytet f\u00f6r kryptering mer effektivt via vSmart-kontroller (inte direkt), genom f\u00f6rutbest\u00e4mda signal kanaler som skyddas av DTLS\/TLS-kryptering baserat p\u00e5 s\u00e4kerhetscertifikat. Detta s\u00e4kerst\u00e4ller s\u00e4kerheten f\u00f6r s\u00e5dant utbyte och m\u00f6jligg\u00f6r b\u00e4ttre skalbarhet av l\u00f6sningen, upp till tiotusentals enheter i ett och samma n\u00e4tverk.\n Alla signalanslutningar (kontroller-kontroller, kontroller-router) \u00e4r ocks\u00e5 skyddade med hj\u00e4lp av DTLS\/TLS. Routrar levereras med s\u00e4kerhetscertifikat vid tillverkning, med m\u00f6jlighet till byte\/f\u00f6rl\u00e4ngning. Tv\u00e5faktorsautentisering uppn\u00e5s genom att tv\u00e5 villkor m\u00e5ste uppfyllas samtidigt f\u00f6r att routern\/kontrollern ska kunna fungera i ett SD-WAN-n\u00e4tverk:<\/p>\n
\nGiltigt s\u00e4kerhetscertifikat<\/li>\n Tydligt och medvetet att varje komponent ska l\u00e4ggas till av administrat\u00f6ren i den \"vita\" listan \u00f6ver till\u00e5tna enheter.<\/li>\n<\/ul>\n\n<\/li>\n<\/ul>\n
Funktionsskillnader mellan SD-WAN och DMVPN\/PfR<\/h2>\n \nN\u00e4r vi b\u00f6rjar diskutera funktionsskillnaderna, \u00e4r det viktigt att notera att m\u00e5nga av dessa \u00e4r en forts\u00e4ttning p\u00e5 arkitektur \u2014 det \u00e4r ingen hemlighet att utvecklarna baserar arkitekturen p\u00e5 de funktioner de vill uppn\u00e5 i slut\u00e4ndan. L\u00e5t oss titta p\u00e5 de mest betydelsefulla skillnaderna mellan de tv\u00e5 teknologierna.<\/p>\n
AppQ (Application Quality) \u2013 funktioner f\u00f6r att s\u00e4kerst\u00e4lla kvaliteten p\u00e5 trafik\u00f6verf\u00f6ring f\u00f6r aff\u00e4rsapplikationer<\/h3>\n \nDe centrala funktionerna hos de behandlade teknologierna syftar till att f\u00f6rb\u00e4ttra anv\u00e4ndarupplevelsen s\u00e5 mycket som m\u00f6jligt n\u00e4r man anv\u00e4nder aff\u00e4rskritiska applikationer i ett distribuerat n\u00e4tverk. Detta \u00e4r s\u00e4rskilt viktigt under omst\u00e4ndigheter d\u00e4r en del av infrastrukturen inte kontrolleras av IT eller ens garanterar en framg\u00e5ngsrik data\u00f6verf\u00f6ring.<\/p>\n
DMVPN tillhandah\u00e5ller inte s\u00e5dana mekanismer p\u00e5 egen hand. Det b\u00e4sta som kan g\u00f6ras i ett klassiskt DMVPN-n\u00e4tverk \u00e4r att klassificera utg\u00e5ende trafik efter applikationer och prioritera den vid \u00f6verf\u00f6ring mot WAN-kanalen. Valet av DMVPN-tunnel baseras i detta fall enbart p\u00e5 dess tillg\u00e4nglighet och resultatet av routningsprotokollen. Samtidigt beaktas inte det \u00f6vergripande tillst\u00e5ndet f\u00f6r v\u00e4gen\/tunneln och dess m\u00f6jliga partiella nedgradering utifr\u00e5n viktiga m\u00e4tv\u00e4rden som \u00e4r signifikanta f\u00f6r n\u00e4tverksapplikationer \u2013 f\u00f6rdr\u00f6jning, f\u00f6rdr\u00f6jningsvariation (jitter) och f\u00f6rluster (%). D\u00e4rf\u00f6r f\u00f6rlorar en direkt j\u00e4mf\u00f6relse av klassisk DMVPN med SD-WAN i termer av att l\u00f6sa AppQ-uppgifter all mening \u2013 DMVPN kan inte l\u00f6sa den uppgiften. N\u00e4r Cisco Performance Routing (PfR) l\u00e4ggs till i denna kontext f\u00f6r\u00e4ndras situationen och j\u00e4mf\u00f6relsen med Cisco SD-WAN blir mer meningsfull. <\/p>\n
Innan vi g\u00e5r vidare till att diskutera skillnaderna, l\u00e5t oss kort sammanfatta vad teknologierna har gemensamt. S\u00e5, b\u00e5da teknologierna:<\/p>\n
\nhar en mekanism som g\u00f6r det m\u00f6jligt att dynamiskt bed\u00f6ma tillst\u00e5ndet f\u00f6r varje etablerad tunnel utifr\u00e5n vissa m\u00e4tv\u00e4rden \u2013 \u00e5tminstone f\u00f6rdr\u00f6jning, variation i f\u00f6rdr\u00f6jning och paketf\u00f6rluster (%)<\/li>\n anv\u00e4nder en viss upps\u00e4ttning verktyg f\u00f6r att skapa, distribuera och till\u00e4mpa regler (policyer) f\u00f6r trafikhantering med h\u00e4nsyn till resultatet av m\u00e4tningarna av de nyckelmetrik som r\u00f6r tunnlarna.<\/li>\n klassificerar applikationstrafik p\u00e5 niv\u00e5erna L3-L4 (DSCP) i OSI-modellen eller enligt L7-signaturer f\u00f6r applikationer baserat p\u00e5 inbyggda DPI-mekanismer i routern.<\/li>\n m\u00f6jligg\u00f6r f\u00f6r betydande applikationer att definiera acceptabla tr\u00f6skelv\u00e4rden f\u00f6r metrik, standardregler f\u00f6r trafik\u00f6verf\u00f6ring och regler f\u00f6r omdirigering av trafik vid \u00f6verskridande av tr\u00f6skelv\u00e4rden.<\/li>\n vid inkapsling av trafik i GRE\/IPSec anv\u00e4nder den en redan etablerad mekanism i branschen f\u00f6r att \u00f6verf\u00f6ra den interna DSCP-m\u00e4rkningen till det externa GRE\/IPSec-paketets huvud, vilket g\u00f6r det m\u00f6jligt att synkronisera QoS-policyer mellan organisationen och tj\u00e4nsteleverant\u00f6ren (om en motsvarande SLA finns).<\/li>\n<\/ul>\n\n
Hur skiljer sig mekanismerna f\u00f6r att bed\u00f6ma de end-to-end-metrik som SD-WAN och DMVPN\/PfR anv\u00e4nder?<\/h3>\n \nDMVPN\/PfR <\/b><\/p>\n\nF\u00f6r att bed\u00f6ma de standardiserade metrik som r\u00f6r tunnelns tillst\u00e5nd anv\u00e4nds b\u00e5de aktiva och passiva mjukvarusensorer (Probes). Aktiva - baserat p\u00e5 anv\u00e4ndartj\u00e4nstetrafik, passiva emulerar s\u00e5dan trafik (n\u00e4r ingen finns). <\/li>\n Fina inst\u00e4llningar av tidtagare och villkor f\u00f6r att uppt\u00e4cka f\u00f6rs\u00e4mringar saknas \u2013 algoritmen \u00e4r fast.<\/li>\n Dessutom finns m\u00f6jligheten att m\u00e4ta den anv\u00e4nda bandbredden i ut\u00e5tg\u00e5ende riktning. Detta ger DMVPN\/PfR ytterligare flexibilitet i trafikhantering.<\/li>\n Samtidigt f\u00f6rlitar sig vissa mekanismer i PfR vid \u00f6verskridande av metrik p\u00e5 \u00e5terkopplande signalering i form av speciella TCA (Threshold Crossing Alert) meddelanden, som m\u00e5ste komma fr\u00e5n trafikmottagaren tillbaka till k\u00e4llan, vilket i sin tur f\u00f6ruts\u00e4tter att tillst\u00e5nden hos de m\u00e4tkanaler som \u00e4r aktuella m\u00e5ste vara \u00e5tminstone tillr\u00e4ckliga f\u00f6r att kunna \u00f6verf\u00f6ra s\u00e5dana TCA-meddelanden. Det \u00e4r i de flesta fall inget problem, men kan uppenbarligen inte garanteras. <\/li>\n<\/ul>\n\nSD-WAN <\/b><\/p>\n\nF\u00f6r att g\u00f6ra en helhetsbed\u00f6mning av standardmetrik f\u00f6r tunnelns tillst\u00e5nd anv\u00e4nds BFD-protokollet i echo-l\u00e4ge. H\u00e4r kr\u00e4vs ingen speciell \u00e5terkoppling i form av TCA eller liknande meddelanden \u2013 dom\u00e4nerna f\u00f6r felhantering h\u00e5lls isolerade. Anv\u00e4ndartrafik beh\u00f6ver inte vara n\u00e4rvarande f\u00f6r att bed\u00f6ma tunnelns tillst\u00e5nd.<\/li>\n Det finns m\u00f6jlighet till finjustering av BFD-timerar f\u00f6r att reglera hastigheten av reaktioner och algoritmens k\u00e4nslighet f\u00f6r nedg\u00e5ngar i kommunikationskanalen fr\u00e5n n\u00e5gra sekunder till minuter.\n
Vid tidpunkten f\u00f6r artikelns skrivande finns det endast en BFD-session i varje tunnel. Detta kan potentiellt skapa en l\u00e4gre granuleringsniv\u00e5 vid analysen av tunnelns tillst\u00e5nd. I praktiken kan detta bli en begr\u00e4nsning endast vid anv\u00e4ndning av WAN-anslutning baserad p\u00e5 MPLS L2\/L3 VPN med ett \u00f6verenskommet QoS SLA \u2013 om DSCP-m\u00e4rkning av BFD-trafiken (efter inkapsling i IPSec\/GRE) sammanfaller med h\u00f6gprioriterad k\u00f6 i operat\u00f6rens n\u00e4tverk, kan detta p\u00e5verka noggrannheten och hastigheten f\u00f6r att uppt\u00e4cka nedg\u00e5ngar f\u00f6r l\u00e5gprioriterad trafik. Det finns emellertid m\u00f6jlighet att \u00e4ndra BFD-m\u00e4rket som standard f\u00f6r att minska risken f\u00f6r s\u00e5dana situationer. I framtida versioner av Cisco SD-WAN f\u00f6rv\u00e4ntas mer finslipning av BFD, samt m\u00f6jlighet att starta flera BFD-sessioner inom en tunnel med individuella DSCP-v\u00e4rden (f\u00f6r olika applikationer).<\/li>\n BFD m\u00f6jligg\u00f6r dessutom bed\u00f6mning av den st\u00f6rsta paketstorleken som kan \u00f6verf\u00f6ras genom en tunnel utan fragmentering. Detta g\u00f6r att SD-WAN kan justera parametrar som MTU och TCP MSS Adjust dynamiskt f\u00f6r att effektivt utnyttja den tillg\u00e4ngliga bandbredden p\u00e5 varje kanal.<\/li>\n I SD-WAN finns \u00e4ven alternativet att synkronisera QoS med operat\u00f6rer inte bara baserat p\u00e5 L3 DSCP-f\u00e4ltet, utan \u00e4ven baserat p\u00e5 L2 CoS-v\u00e4rden, som kan bildas automatiskt i det lokala n\u00e4tverket av specialiserade enheter \u2014 till exempel IP-telefoner.<\/li>\n<\/ul>\n<\/p>\n
Hur skiljer sig m\u00f6jligheterna, metoderna f\u00f6r best\u00e4mning och till\u00e4mpning av AppQ-policys?<\/h3>\n <\/p>\n
Policys f\u00f6r DMVPN\/PfR:<\/h4>\n <\/p>\n
\nDefinieras p\u00e5 central filialrouter(-arna) (CF) via kommandoradsgr\u00e4nssnittet CLI eller CLI-mallkonfigurationer. Skapande av CLI-mallar kr\u00e4ver f\u00f6rberedelse och kunskap om policyernas syntax.\n
Definieras globalt utan m\u00f6jlighet till anpassning\/\u00e4ndringar f\u00f6r individuella n\u00e4tverkssegment.<\/b><\/li>\nInteraktivt skapande av policys via grafiskt gr\u00e4nssnitt st\u00f6ds inte.<\/li>\n \u00c4ndringar, arv, skapande av flera versioner av policys f\u00f6r snabb omkoppling st\u00f6ds inte.<\/li>\n Sprids automatiskt p\u00e5 routrar i fj\u00e4rrkontor. Samma kommunikationskanaler anv\u00e4nds som f\u00f6r \u00f6verf\u00f6ring av anv\u00e4ndardata. Om det inte finns n\u00e5gon kommunikationskanal mellan huvudkontoret och det fj\u00e4rrkontor, \u00e4r spridning\/\u00e4ndring av policys om\u00f6jlig.<\/li>\n Till\u00e4mpas p\u00e5 varje router och modifierar vid behov resultaten av standard routingprotokoll med h\u00f6gre prioritet. <\/li>\n F\u00f6r fall d\u00e4r alla WAN-kanaler p\u00e5 kontoret upplever betydande trafikf\u00f6rluster, finns inga kompensationsmekanismer.<\/b>.<\/li>\n<\/ul>\n <\/p>\n
SD-WAN-policys:<\/h4>\n <\/p>\n
\nDefinieras i det grafiska gr\u00e4nssnittet vManage genom en interaktiv mallguid.<\/li>\n St\u00f6der skapande av flera policys, kopiering, arv, samt omkoppling mellan policys i realtid.<\/li>\n St\u00f6der anpassning av policyn f\u00f6r olika n\u00e4tverkssegment (kontor).<\/li>\n Sprids via vilken tillg\u00e4nglig signal kanal som helst mellan kontrollern och routern och\/eller vSmart \u2013 de \u00e4r inte direkt beroende av dataplansanslutning mellan routrarna. Det kr\u00e4vs dock IP-anslutning mellan routern och kontrollerna.\n
F\u00f6r fall d\u00e4r alla tillg\u00e4ngliga kanaler p\u00e5 kontoret upplever betydande datarf\u00f6rluster, som \u00f6verstiger acceptabla tr\u00f6skelv\u00e4rden f\u00f6r kritiska applikationer, kan ytterligare mekanismer som \u00f6kar tillf\u00f6rlitligheten f\u00f6r \u00f6verf\u00f6ring anv\u00e4ndas:\n\nFEC (Forward Error Correction)<\/b> \u2013 anv\u00e4nder en speciell algoritm f\u00f6r \u00f6verskottkodning. Vid \u00f6verf\u00f6ring av kritisk trafik \u00f6ver kanaler med en betydande procentandel f\u00f6rluster kan FEC automatiskt aktiveras och till\u00e5ta \u00e5terst\u00e4llande av f\u00f6rlorad data vid behov. Anv\u00e4ndningen av bandbredd \u00f6kar n\u00e5got men tillf\u00f6rlitligheten \u00f6kar avsev\u00e4rt.\n
Duplicering av datastreamar<\/b> \u2013 ut\u00f6ver FEC kan policyn inkludera automatisk duplikering av trafik f\u00f6r valda applikationer i h\u00e4ndelse av en \u00e4nnu allvarligare f\u00f6rlustniv\u00e5 som inte kan kompenseras av FEC. I detta fall kommer de valda uppgifterna att skickas \u00f6ver alla tunnlar mot mottagande filial med efterf\u00f6ljande deduplicering (borttagning av \u00f6verfl\u00f6diga paketkopior). Mekanismen \u00f6kar avsev\u00e4rt utnyttjandet av kanaler, men st\u00e4rker ocks\u00e5 avsev\u00e4rt p\u00e5litligheten i \u00f6verf\u00f6ringen.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n <\/p>\n
M\u00f6jligheter med Cisco SD-WAN, utan direkta motsvarigheter i DMVPN\/PfR<\/h3>\n \nArkitekturen f\u00f6r Cisco SD-WAN-l\u00f6sningen m\u00f6jligg\u00f6r i vissa fall funktioner vars implementering inom DMVPN\/PfR antingen \u00e4r extremt sv\u00e5r, inte kostnadseffektiv p\u00e5 grund av n\u00f6dv\u00e4ndigt arbete, eller helt om\u00f6jlig. L\u00e5t oss titta p\u00e5 de mest intressanta av dem:<\/p>\n
Traffic-Engineering (TE)<\/h4>\n \nTE inkluderar mekanismer som g\u00f6r det m\u00f6jligt att avleda trafik fr\u00e5n den standardv\u00e4g som skapats av routningsprotokoll. TE anv\u00e4nds ofta f\u00f6r att s\u00e4kerst\u00e4lla h\u00f6g tillg\u00e4nglighet av n\u00e4tverkstj\u00e4nster, genom att snabbt och\/eller i f\u00f6rv\u00e4g omdirigera viktig trafik till en alternativ (icke-\u00f6verlappande) \u00f6verf\u00f6ringsv\u00e4g, med syftet att f\u00f6rb\u00e4ttra kvaliteten p\u00e5 tj\u00e4nsten eller hastigheten f\u00f6r \u00e5terst\u00e4llning vid ett fel p\u00e5 huvudv\u00e4gen. <\/p>\n
Sv\u00e5righeten med att implementera TE ligger i att det kr\u00e4ver att en alternativ v\u00e4g ber\u00e4knas och reserveras i f\u00f6rv\u00e4g. I MPLS-n\u00e4tverk f\u00f6r teleoperat\u00f6rer hanteras denna uppgift genom att anv\u00e4nda teknologier som MPLS Traffic Engineering med utvidgningar av IGP-protokoll och RSVP-protokollet. P\u00e5 senaste tid har \u00e4ven Segment Routing-teknologin blivit alltmer popul\u00e4r, vilket \u00e4r mer optimerat f\u00f6r centraliserad konfiguration och orkestrering. I klassiska WAN-n\u00e4tverk \u00e4r 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\u00e5 varje router separat \u2013 utan att ta h\u00e4nsyn till n\u00e4tverkets \u00f6vergripande tillst\u00e5nd eller resultatet av PBR i tidigare eller senare steg. Resultatet av dessa TE-alternativ \u00e4r nedsl\u00e5ende \u2013 MPLS TE anv\u00e4nds vanligtvis bara i den mest kritiska delen av n\u00e4tverket (k\u00e4rnan) p\u00e5 grund av den komplexitet som kr\u00e4vs f\u00f6r konfiguration och drift, och PBR anv\u00e4nds p\u00e5 enskilda routrar utan m\u00f6jlighet att formulera en enhetlig PBR-policy f\u00f6r hela n\u00e4tverket. Detta g\u00e4ller uppenbarligen ocks\u00e5 n\u00e4tverk baserade p\u00e5 DMVPN.<\/p>\n
Service-chaining (Sertj\u00e4nster) <\/h4>\n \nAtt bilda tj\u00e4nstekedjor \u00e4r en \u00e4nnu mer arbetsintensiv uppgift i klassisk routing \u00e4n den redan beskrivna mekanismen Traffic Engineering. I detta fall \u00e4r det n\u00f6dv\u00e4ndigt att inte bara skapa en speciell rutt f\u00f6r en viss n\u00e4tverksapplikation, utan \u00e4ven m\u00f6jligg\u00f6ra trafikavledning fr\u00e5n n\u00e4tverket vid best\u00e4mda (eller alla) noder inom SD-WAN-n\u00e4tverket f\u00f6r behandling av en specifik applikation eller tj\u00e4nst (MPLS, Belastningsbalansering, Caching, Trafikinspektion osv.). Samtidigt kr\u00e4vs m\u00f6jlighet att \u00f6vervaka tillst\u00e5ndet hos dessa externa tj\u00e4nster f\u00f6r att undvika black-holing-situationer, samt mekanismer som till\u00e5ter placering av s\u00e5dana homogena externa tj\u00e4nster p\u00e5 olika geo-lokationer med m\u00f6jlighet f\u00f6r n\u00e4tverket att automatiskt v\u00e4lja den mest optimala servicepunkten f\u00f6r behandling av trafik fr\u00e5n olika filialer. I fallet med Cisco SD-WAN \u00e4r det ganska enkelt att uppn\u00e5 genom att skapa en motsvarande centraliserad policy som<\/p>\n
Vad blir resultatet?<\/h2>\n \nDet \u00e4r uppenbart att b\u00e5de DMVPN (tillsammans med eller utan Performance Routing) och Cisco SD-WAN l\u00f6ser i slut\u00e4ndan mycket liknande uppgifter<\/b> i f\u00f6rh\u00e5llande till organisationens distribuerade WAN-n\u00e4t. De betydande arkitektoniska och funktionella skillnaderna i Cisco SD-WAN-teknologin h\u00f6jer processen f\u00f6r att l\u00f6sa dessa problem till en annan kvalitetsniv\u00e5<\/b>. Sammanfattningsvis kan f\u00f6ljande viktiga skillnader mellan SD-WAN och DMVPN\/PfR noteras:<\/p>\n\nDMVPN\/PfR anv\u00e4nder i allm\u00e4nhet bepr\u00f6vade teknologier f\u00f6r att bygga \u00f6verlagrade VPN-n\u00e4tverk och \u00e4r i fr\u00e5ga om data-plan liknande den mer moderna SD-WAN-teknologin, men det finns vissa begr\u00e4nsningar i form av obligatorisk statisk konfiguration av routrar och valet av topologier \u00e4r begr\u00e4nsat till Hub-n-Spoke. \u00c5 andra sidan har DMVPN\/PfR vissa funktioner som \u00e4nnu inte \u00e4r tillg\u00e4ngliga inom SD-WAN (det handlar om per-application BFD).<\/li>\n Inom control-plane skiljer sig teknologierna grundligt \u00e5t. Med centraliserad behandling av signalprotokoll g\u00f6r SD-WAN det m\u00f6jligt att bland annat avsev\u00e4rt minska felf\u00e4lt och \u2019koppla loss\u2019 processen f\u00f6r \u00f6verf\u00f6ring av anv\u00e4ndartrafik fr\u00e5n signalinteraktionen \u2013 tillf\u00e4llig otillg\u00e4nglighet av kontrollerarna p\u00e5verkar inte m\u00f6jligheten att \u00f6verf\u00f6ra anv\u00e4ndartrafik. Samtidigt p\u00e5verkar tillf\u00e4llig otillg\u00e4nglighet av n\u00e5gon filial (inklusive den centrala) inte m\u00f6jligheten f\u00f6r de \u00f6vriga filialerna att interagera med varandra och kontrollerarna.<\/li>\n Arkitekturen f\u00f6r att skapa och till\u00e4mpa trafikhanteringspolicyer vid SD-WAN \u00f6vertr\u00e4ffar ocks\u00e5 den i DMVPN\/PfR \u2013 geo-redundans \u00e4r betydligt b\u00e4ttre implementerad, det finns ingen koppling till Hub, fler m\u00f6jligheter f\u00f6r finjustering av policyer, och listan \u00f6ver genomf\u00f6rda trafikhanteringsscenarier \u00e4r ocks\u00e5 betydligt st\u00f6rre.<\/li>\n Processen f\u00f6r orkestrering av l\u00f6sningen skiljer sig ocks\u00e5 avsev\u00e4rt. DMVPN f\u00f6ruts\u00e4tter att det finns i f\u00f6rv\u00e4g k\u00e4nda parametrar som p\u00e5 n\u00e5got s\u00e4tt m\u00e5ste \u00e5terspeglas i konfigurationen, vilket n\u00e5got begr\u00e4nsar flexibiliteten i l\u00f6sningen och m\u00f6jligheten till dynamiska f\u00f6r\u00e4ndringar. \u00c5 sin sida utg\u00e5r SD-WAN fr\u00e5n en paradigm d\u00e4r routern i den initiala tidpunkten f\u00f6r anslutning \u2019inte vet n\u00e5got\u2019 om sina kontrollerare, men vet \u2019vem man kan fr\u00e5ga\u2019 \u2013 detta \u00e4r tillr\u00e4ckligt f\u00f6r inte bara att automatiskt etablera kontakt med kontrollerarna, utan \u00e4ven f\u00f6r att automatiskt s\u00e4tta upp en helt sammanl\u00e4nkad data-plan topologi som sedan kan justeras\/\u00e4ndras flexibelt med hj\u00e4lp av policyer.<\/li>\n N\u00e4r det g\u00e4ller centraliserad hantering, automatisering och \u00f6vervakning \u00f6vertr\u00e4ffar SD-WAN f\u00f6rv\u00e4ntat m\u00f6jligheterna hos DMVPN\/PfR, som \u00e4r resultatet av utvecklingen av klassiska teknologier och i st\u00f6rre utstr\u00e4ckning f\u00f6rlitar sig p\u00e5 kommandoradsgr\u00e4nssnitt (CLI) samt anv\u00e4ndning av NMS-system baserade p\u00e5 mallar. <\/li>\n I j\u00e4mf\u00f6relse med DMVPN har s\u00e4kerhetskraven i SD-WAN n\u00e5tt en annan kvalitetsniv\u00e5. De fr\u00e4msta principerna \u00e4r nolltillit, skalbarhet och tv\u00e5faktorsautentisering.<\/li>\n<\/ul>\n\nAv dessa enkla slutsatser kan man f\u00e5 en felaktig uppfattning om att skapandet av n\u00e4tverk baserat p\u00e5 DMVPN\/PfR idag har f\u00f6rlorat all relevans. Det \u00e4r dock inte helt sant. Till exempel, i fall d\u00e4r det finns ett flertal gammalt utrustning och inget s\u00e4tt att ers\u00e4tta det, kan DMVPN m\u00f6jligg\u00f6ra en integration av \"gamla\" och \"nya\" enheter i ett enhetligt geo-distribuerat n\u00e4tverk med m\u00e5nga av de f\u00f6rdelar som beskrivits ovan.<\/p>\n
\u00c5 andra sidan b\u00f6r man komma ih\u00e5g att alla nuvarande f\u00f6retagsroutrar fr\u00e5n Cisco baserade p\u00e5 IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) idag st\u00f6der alla drifts\u00e4tt \u2013 b\u00e5de klassisk routing, DMVPN och SD-WAN. Valet baseras p\u00e5 aktuella behov och f\u00f6rst\u00e5elsen av att p\u00e5 samma utrustning kan man n\u00e4r som helst b\u00f6rja g\u00e5 mot en mer avancerad teknologi.<\/b>habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0421 \u0430\u0432\u0433\u0443\u0441\u0442\u0430 2017 \u0433\u043e\u0434\u0430, \u043a\u043e\u0433\u0434\u0430 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f Cisco \u043f\u0440\u0438\u043e\u0431\u0440\u0435\u043b\u0430 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044e Viptela, \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u0439 \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u0435\u043c\u043e\u0439 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0435\u0439 \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u0438 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0445 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0442\u0438\u0432\u043d\u044b\u0445 \u0441\u0435\u0442\u0435\u0439 \u0441\u0442\u0430\u043b\u0430 Cisco SD-WAN. \u0417\u0430 \u043f\u0440\u043e\u0448\u0435\u0434\u0448\u0438\u0435 3 \u0433\u043e\u0434\u0430 SD-WAN \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u044f \u043f\u0440\u043e\u0448\u043b\u0430 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0439, \u043a\u0430\u043a \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0433\u043e, \u0442\u0430\u043a \u0438 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0433\u043e \u0445\u0430\u0440\u0430\u043a\u0442\u0435\u0440\u0430. \u0422\u0430\u043a \u0437\u043d\u0430\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u0440\u0430\u0441\u0448\u0438\u0440\u0438\u043b\u0438\u0441\u044c \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u0435 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u0438 \u043f\u043e\u044f\u0432\u0438\u043b\u0430\u0441\u044c \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0430 \u043d\u0430 \u043a\u043b\u0430\u0441\u0441\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0442\u043e\u0440\u0430\u0445 \u0441\u0435\u0440\u0438\u0439 Cisco ISR 1000, ISR 4000, ASR 1000 \u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91349,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91348","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t