Funkcionalne mo\u017enosti \u2013 kaj ena tehnologija zmore, \u010desar druga ne? In ali je to res pomembno?<\/li>\n<\/ul>\n<\/p>\n
Kak\u0161ne so arhitekturne razlike in ali so pomembne?<\/h3>\n \nVsaka od navedenih tehnologij ima \u0161tevilne 'premikajo\u010de se dele', ki se razlikujejo ne le po vlogi, temve\u010d tudi po principih sodelovanja med seboj. Od tega, kako premi\u0161ljeni so ti principi, sta neposredno odvisna njegova skalabilnost, odpornost na napake in splo\u0161na u\u010dinkovitost re\u0161itve. <\/p>\n
Poglejmo razli\u010dne vidike arhitekture podrobneje:<\/p>\n
Data-plane<\/b> \u2013 del re\u0161itve, odgovoren za prenos uporabni\u0161kega prometa med virom in prejemnikom. V DMVPN in SD-WAN je to v splo\u0161nem enako izvedeno na samih usmerjevalnikih, ki temeljijo na Multipoint GRE tunelih. Razlika je v tem, na kak\u0161en na\u010din se oblikuje potreben niz parametrov teh tunelov:<\/p>\n\nu DMVPN\/PfR<\/b> \u2013 to je strogo dvotaktna hierarhija vozli\u0161\u010d s topologijo 'Zvezda' ali Hub-n-Spoke. Obvezna je stati\u010dna nastavitev Huba in stati\u010dna vezava Spoke na Hub, prav tako pa tudi sodelovanje po protokolu NHRP za oblikovanje povezljivosti data-plane. Kot posledica, so spremembe na Hubu<\/b>pomembno ote\u017eene, povezane na primer s spremembo\/povezovanjem novih WAN-kanalov ali spremembo parametrov obstoje\u010dih.<\/li>\nu SD-WAN<\/b> \u2013 to je popolnoma dinami\u010dni model za odkrivanje parametrov vzpostavljenih tunelov, ki temelji na control-plane (protokol OMP) in orchestration-plane (sodelovanje z nadzornikom vBond za naloge odkrivanja nadzornikov in NAT traversal). Pri tem so lahko nalagane topologije kakr\u0161nekoli, vklju\u010dno hierarhi\u010dne. V okviru vzpostavljene nalagane topologije tunelov je mo\u017ena fleksibilna nastavitev logi\u010dne topologije v vsakem posameznem VPN (VRF).<\/li>\n<\/ul>\n Control-plane<\/b> \u2013 funkcije izmenjave, filtriranja in modificiranja usmerjevalnih in drugih informacij med komponentami re\u0161itve. <\/p>\n\nu DMVPN\/PfR<\/b> \u2013 poteka samo med usmerjevalniki Hub in Spoke. Neposredna izmenjava usmerjevalnih informacij med Spoke je onemogo\u010dena. Kot posledica, brez delujo\u010dega Huba ni mogo\u010de delovanje control-plane in data-plane.<\/b>, kar nalaga na Hub dodatne zahteve za visoko razpolo\u017eljivost, ki jih ne moremo vedno izpolniti.<\/li>\nu SD-WAN<\/b> \u2013 kontrolna plo\u0161\u010da nikoli ne poteka neposredno med usmerjevalniki \u2013 interakcija poteka na osnovi protokola OMP in mora biti obvezno izvedena preko posebne vrste kontrolerja vSmart, kar omogo\u010da balanciranje, geodokumentacijo in centralizirano upravljanje s signalnim prometom. Druga zna\u010dilnost protokola OMP je njegova znatna odpornost na izgube in neodvisnost od hitrosti komunikacijske povezave s kontrolerji (seveda v razumnem obsegu). To uspe\u0161no omogo\u010da namestitev kontrolerjev SD-WAN v javnih ali zasebnih oblakih z dostopom preko interneta.<\/li>\n<\/ul>\n Politika-plo\u0161\u010da<\/b> \u2013 del re\u0161itve, ki je odgovoren za dolo\u010danje, \u0161irjenje in izvajanje politik upravljanja s prometom v distribuirani mre\u017ei.<\/p>\n\nDMVPN <\/b>\u2013 dejansko omejeno na politike kakovosti storitev (QoS), ki jih nastavljamo individualno na vsakem usmerjevalniku preko CLI ali predlog Prime Infrastructure.<\/li>\nDMVPN\/PfR<\/b> \u2013 politike PfR se oblikujejo na centraliziranem usmerjevalniku Master Controller (MC) preko CLI in se nato avtomatsko \u0161irijo na podru\u017eni\u010dne MC. Uporabljajo se isti na\u010dini prenosa politik kot za podatkovno-plo\u0161\u010do. Ni mo\u017enosti lo\u010devanja izmenjave politik, informacij o usmerjanju in uporabni\u0161kih podatkov. \u0160irjenje politik predpostavlja obvezno prisotnost IP-povezljivosti med Hub in Spoke. Funkcijo MC se lahko po potrebi zdru\u017ei z DMVPN usmerjevalnikom. Uporaba predlog Prime Infrastructure za centralizirano oblikovanje politik je mo\u017ena (ampak ni obvezna). Pomembna zna\u010dilnost je, da se politika oblikuje globalno za celo mre\u017eo enako \u2013 individualne politike za posamezne segmente niso podprte<\/b>.<\/li>\nSD-WAN<\/b> Politike upravljanja prometom i kvalitetom usluge definiraju se centralizirano putem grafi\u010dkog su\u010delja Cisco vManage, dostupnog uklju\u010duju\u0107i i preko interneta (ako je potrebno). Razmjenjuju se putem signalnih kanala direktno ili posredno kroz vSmart kontrolere (ovisno o vrsti politike). Ne ovise o povezanosti data-plane izme\u0111u usmjeriva\u010da, jer koriste sve dostupne putove za prijenos prometa izme\u0111u kontrolera i usmjeriva\u010da.\n Za razli\u010dite segmente mre\u017ee mogu\u0107e je fleksibilno formiranje raznih politika \u2013 podru\u010dje primjene politike definirano je mnogim jedinstvenim identifikatorima koji su predvi\u0111eni u rje\u0161enju \u2013 broj podru\u017enice, tip aplikacije, smjer kretanja prometa itd.\n<\/li>\n<\/ul>\n
Orkestracijska-ravnina<\/b> mehanizmi koji omogu\u0107uju komponentama da se dinami\u010dki otkriju, postave i koordiniraju daljnju interakciju.<\/p>\n\nu DMVPN\/PfR<\/b> uzajamno otkrivanje izme\u0111u usmjeriva\u010da temelji se na stati\u010dkoj konfiguraciji Hub ure\u0111aja i odgovaraju\u0107oj konfiguraciji Spoke ure\u0111aja. Dinami\u010dko otkrivanje doga\u0111a se samo za Spoke, koji obavje\u0161tava Hub ure\u0111aj o svojim parametrima veze, koji je unaprijed unesen u konfiguraciju Spoke. Bez IP povezanosti Spoke-a s barem jednim Hub-om, nije mogu\u0107e formirati niti data-plane, niti control-plane.<\/b><\/li>\nu SD-WAN<\/b> Orkestracija komponenti rje\u0161enja odvija se kori\u0161tenjem kontrolera vBond, s kojim svaki komponent (usmjeriva\u010di i kontroleri vManage\/vSmart) mora unaprijed uspostaviti IP povezanost.\n Isprva, komponente ne znaju o parametrima me\u0111usobnog povezivanja \u2013 za to im je potreban posrednik-orkestrator vBond. Op\u0107i princip je sljede\u0107i \u2013 svaka komponenta u po\u010detnoj fazi saznaje (automatski ili stati\u010dki) samo o parametrima povezivanja s vBond, zatim vBond obavje\u0161tava usmjeriva\u010d o kontrolerima vManage i vSmart (ranije otkrivenim), \u0161to omogu\u0107uje automatsko uspostavljanje svih potrebnih signalnih veza. <\/p>\n
N\u00e1sleduj\u00edc\u00edm krokem se nov\u00fd router dozv\u00ed o ostatn\u00edch routrech v s\u00edti prost\u0159ednictv\u00edm OMP v\u00fdm\u011bny s \u0159\u00edd\u00edc\u00edm syst\u00e9mem vSmart. T\u00edmto zp\u016fsobem je router, kter\u00fd zpo\u010d\u00e1tku nezn\u00e1 parametry s\u00edt\u011b, schopen zcela automaticky zjistit a p\u0159ipojit se k \u0159\u00edd\u00edc\u00edm syst\u00e9m\u016fm a pot\u00e9 tak\u00e9 automaticky zjistit a vytvo\u0159it spojen\u00ed s ostatn\u00edmi routrech. P\u0159i tom jsou parametry p\u0159ipojen\u00ed v\u0161ech komponent\u016f zpo\u010d\u00e1tku nezn\u00e1m\u00e9 a b\u011bhem provozu se mohou m\u011bnit.\n<\/li>\n<\/ul>\n
Pl\u00e1n \u0159\u00edzen\u00ed<\/b> \u2013 \u010d\u00e1st \u0159e\u0161en\u00ed, kter\u00e1 zaji\u0161\u0165uje centralizovan\u00e9 \u0159\u00edzen\u00ed a monitorov\u00e1n\u00ed.<\/p>\n\nDMVPN\/PfR<\/b> \u2013 specializovan\u00e9 \u0159e\u0161en\u00ed pro pl\u00e1n \u0159\u00edzen\u00ed nen\u00ed ur\u010deno. Pro z\u00e1kladn\u00ed automatizaci a monitorov\u00e1n\u00ed je mo\u017en\u00e9 vyu\u017eit\u00ed takov\u00fdch produkt\u016f, jako je Cisco Prime Infrastructure. Ka\u017ed\u00fd router m\u00e1 mo\u017enost \u0159\u00edzen\u00ed prost\u0159ednictv\u00edm p\u0159\u00edkazov\u00e9ho \u0159\u00e1dku CLI. Integrace s extern\u00edmi syst\u00e9my prost\u0159ednictv\u00edm API nen\u00ed ur\u010dena.<\/b><\/li>\nSD-WAN<\/b> \u2013 ve\u0161ker\u00e1 standardn\u00ed interakce a monitorov\u00e1n\u00ed prob\u00edh\u00e1 centr\u00e1ln\u011b prost\u0159ednictv\u00edm grafick\u00e9ho rozhran\u00ed \u0159\u00edd\u00edc\u00edho syst\u00e9mu vManage. V\u0161echny mo\u017enosti \u0159e\u0161en\u00ed bez v\u00fdjimky jsou dostupn\u00e9 pro nastaven\u00ed p\u0159es vManage, stejn\u011b jako prost\u0159ednictv\u00edm pln\u011b zdokumentovan\u00e9 knihovny REST API.\n Ve\u0161ker\u00e1 nastaven\u00ed SD-WAN s\u00edt\u011b ve vManage se z\u00e1sadn\u011b t\u00fdkaj\u00ed dvou z\u00e1kladn\u00edch konstrukc\u00ed \u2013 vytv\u00e1\u0159en\u00ed \u0161ablon za\u0159\u00edzen\u00ed (Device Template) a vytv\u00e1\u0159en\u00ed politiky, kter\u00e1 ur\u010duje logiku fungov\u00e1n\u00ed s\u00edt\u011b a zpracov\u00e1n\u00ed provozu. P\u0159i\u010dem\u017e vManage, p\u0159en\u00e1\u0161ej\u00edc\u00ed politiku vytvo\u0159enou spr\u00e1vcem, automaticky ur\u010duje, kter\u00e9 zm\u011bny a na jak\u00fdch individu\u00e1ln\u00edch za\u0159\u00edzen\u00edch\/\u0159\u00edd\u00edc\u00edch syst\u00e9mech je t\u0159eba prov\u00e9st, co\u017e v\u00fdrazn\u011b zvy\u0161uje efektivitu a \u0161k\u00e1lovatelnost \u0159e\u0161en\u00ed.<\/p>\n
P\u0159es rozhran\u00ed vManage je dostupn\u00e9 nejen nastaven\u00ed \u0159e\u0161en\u00ed Cisco SD-WAN, ale tak\u00e9 plnohodnotn\u00fd monitoring stavu v\u0161ech komponent \u0159e\u0161en\u00ed a\u017e po aktu\u00e1ln\u00ed stav metrik jednotliv\u00fdch tunel\u016f a statistiky pou\u017e\u00edv\u00e1n\u00ed r\u016fzn\u00fdch aplikac\u00ed na z\u00e1klad\u011b DPI anal\u00fdzy.<\/p>\n
Kljub centralizaciji interakcij, imajo vsi komponenti (krmilniki in usmerjevalniki) tudi popolnoma funkcionalno ukazno vrstico CLI, ki je potrebna v fazi implementacije ali v primeru izrednih razmer za lokalno diagnostiko. V obi\u010dajnem na\u010dinu (ob prisotnosti signalnega kanala med komponentami) je ukazna vrstica na usmerjevalnikih na voljo le za diagnostiko in ni dostopna za izvajanje lokalnih sprememb, kar zagotavlja lokalno varnost in edini vir sprememb v tak\u0161ni omre\u017eni strukturi \u2013 vManage.<\/li>\n<\/ul>\n
\nIntegrirana varnost<\/b> \u2013 tukaj je govora ne samo o za\u0161\u010diti uporabni\u0161kih podatkov med prenosom po odprtih kanalih, temve\u010d tudi o splo\u0161ni za\u0161\u010diti WAN omre\u017eja na temelju izbrane tehnologije.<\/p>\n\nu DMVPN\/PfR<\/b> predvidena je mo\u017enost \u0161ifriranja uporabni\u0161kih podatkov in signalnih protokolov. Pri uporabi dolo\u010denih modelov usmerjevalnikov so dodatno na voljo funkcije omre\u017ene za\u0161\u010dite z nadzorom prometa, IPS\/IDS. Vklju\u010dena je tudi mo\u017enost segmentacije podru\u017eni\u010dnih omre\u017eij z uporabo VRF. Mogo\u010da je (enokratna) avtentikacija kontrolnih protokolov.\n Pri tem se oddaljeni usmerjevalnik privzeto \u0161teje za zanesljiv element omre\u017eja \u2013 torej niso predvideni in ne upo\u0161tevajo se primeri fizi\u010dne kompromitacije posameznih naprav ter mo\u017enost nepoobla\u0161\u010denega dostopa do njih, ni dvostopenjske avtentikacije komponent re\u0161itve, kar lahko pri geografsko razpr\u0161enem omre\u017eju prinese resne dodatne tveganja.<\/b> <\/li>\nu SD-WAN<\/b> po vzoru DMVPN je predvidena mo\u017enost \u0161ifriranja uporabni\u0161kih podatkov, vendar z znatno raz\u0161irjenimi funkcijami omre\u017ene varnosti in L3\/VRF segmentacijo (MSE, IPS\/IDS, filtriranje URL, filtriranje DNS, AMP\/TG, SASE, TLS\/SSL proxy itd.). Pri tem se izmenjava \u0161ifrirnih klju\u010dev u\u010dinkoviteje izvaja preko krmilnikov vSmart (namesto neposredno), prek vnaprej dolo\u010denih signalnih kanalov, za\u0161\u010ditenih z DTLS\/TLS \u0161ifriranjem na osnovi varnostnih potrdil. To pa zagotavlja varnost tak\u0161ne izmenjave in omogo\u010da bolj\u0161o raz\u0161irljivost re\u0161itve do deset tiso\u010d naprav v enem omre\u017eju.\n Vse signalne povezave (kontroler-kontroler, kontroler usmerjevalnik) so prav tako za\u0161\u010ditene na osnovi DTLS\/TLS. Usmerjevalniki so opremljeni s certifikati za varnost pri proizvodnji z mo\u017enostjo zamenjave\/podalj\u0161anja. Dvofaktorska avtentikacija se dose\u017ee z obveznim in so\u010dasnim izpolnjevanjem dveh pogojev za delovanje usmerjevalnika\/kontrolerja v SD-WAN omre\u017eju:<\/p>\n
\nVeljavna varnostna potrdila<\/li>\n Izrecno in zavestno dodajanje vsakega komponenta s strani administratorja na 'beli' seznam dovoljenih naprav.<\/li>\n<\/ul>\n\n<\/li>\n<\/ul>\n
Funkcionalne razlike med SD-WAN in DMVPN\/PfR<\/h2>\n \nKo prehajamo k razpravi o funkcionalnih razlikah, je treba omeniti, da mnoge izmed njih izhajajo iz arhitekturnih \u2014 ni skrivnost, da se pri oblikovanju arhitekture re\u0161itev razvijalci opirajo na funkcionalnosti, ki jih \u017eelijo na koncu dose\u010di. Oglejmo si najpomembnej\u0161e razlike med obema tehnologijama.<\/p>\n
AppQ (Kakovost aplikacij) \u2013 funkcije zagotavljanja kakovosti prenosa prometa poslovnih aplikacij<\/h3>\n \nKlju\u010dne funkcije obravnavanih tehnologij so usmerjene v to, da v najve\u010dji mo\u017eni meri izbolj\u0161ajo uporabni\u0161ko izku\u0161njo pri uporabi poslovno kriti\u010dnih aplikacij v razdeljenem omre\u017eju. To je \u0161e posebej pomembno v situacijah, ko del infrastrukture ni pod nadzorom IT ali celo ne zagotavlja uspe\u0161ne prenosa podatkov.<\/p>\n
DMVPN sam po sebi ne ponuja tak\u0161nih mehanizmov. Najbolj\u0161e, kar je mo\u017eno storiti v klasi\u010dnem DMVPN omre\u017eju, je razvr\u0161\u010danje izhodnega prometa po aplikacijah in prioritetizacija pri po\u0161iljanju proti WAN-kanalu. Izbira DMVPN tunela je v tem primeru dolo\u010dena le z njegovo dostopnostjo in rezultati delovanja protokolov usmerjanja. Pri tem se ne upo\u0161teva stanje poti\/tunela in morebitna delna degradacija z vidika klju\u010dnih metrik, ki so pomembne za omre\u017ene aplikacije \u2013 zakasnitev, variacija zakasnitve (jitter) in izgube (%). V zvezi s tem neposredno primerjati klasi\u010dni DMVPN s SD-WAN glede re\u0161evanja nalog AppQ nima pravega smisla \u2013 DMVPN te naloge ne more re\u0161iti. Z dodajanjem tehnologije Cisco Performance Routing (PfR) se situacija spremeni in primerjava s Cisco SD-WAN postane bolj smiselna. <\/p>\n
Preden se lotimo razprave o razlikah, na kratko o podobnostih tehnologij. Torej, obe tehnologiji:<\/p>\n
\nimata mehanizem, ki omogo\u010da dinami\u010dno oceno stanja vsakega vzpostavljenega predora v okviru dolo\u010denih meritev \u2013 najmanj zamudo, variacijo zamude in izgubo paketov (%).<\/li>\n uporabljata dolo\u010den niz orodij za oblikovanje, \u0161irjenje in uporabo pravil (politike) upravljanja prometa ob upo\u0161tevanju rezultatov merjenja stanja klju\u010dnih metrik predorov.<\/li>\n klasificirata promet aplikacij na ravneh L3-L4 (DSCP) modela OSI ali po L7 podpisih aplikacij, ki temeljijo na mehanizmih DPI, vgrajenih v usmerjevalnike.<\/li>\n omogo\u010data, da za pomembne aplikacije dolo\u010dimo dovoljene pragovne vrednosti metrik, privzeta pravila za prenos prometa in pravila za preusmerjanje prometa ob preseganju pragov.<\/li>\n pri enkapsulaciji prometa v GRE\/IPSec uporabljata \u017ee uveljavljen mehanizem prena\u0161anja notranje DSCP oznake v zunanji GRE\/IPSec naslov paketa, kar omogo\u010da uskladitev politik QoS organizacije in telekomunikacijskega operaterja (ob ustreznem SLA).<\/li>\n<\/ul>\n\n
Kako se mehanizmi ocenjevanja celovitih metrik SD-WAN in DMVPN\/PfR razlikujejo?<\/h3>\n \nDMVPN\/PfR <\/b><\/p>\n\nZa oceno standardnih metrik stanja tunela se uporabljajo tako aktivni kot pasivni programski senzorji (Probes). Aktivni \u2013 na osnovi uporabni\u0161kega prometa, pasivni pa simulirajo tak promet (v njegovi odsotnosti). <\/li>\n Natan\u010dna nastavitev \u010dasovnikov in pogojev za odkrivanje degradacije ni na voljo \u2013 algoritem je fiksiran.<\/li>\n Dodatno je na voljo merjenje uporabljene pasovne \u0161irine v izhodnem smeri, kar DMVPN\/PfR dodaja dodatno fleksibilnost pri upravljanju prometa.<\/li>\n Pri tem se nekateri mehanizmi PfR ob preseganju metrik zana\u0161ajo na povratno signalizacijo v obliki posebnih TCA (Threshold Crossing Alert) sporo\u010dil, ki morajo izhajati od prejemnika prometa proti virom, kar pa pomeni, da mora biti stanje merjenih kanalov vsaj dovolj za prenos takih TCA sporo\u010dil. To v ve\u010dini primerov ni problem, vendar o\u010ditno ne more biti garantirano. <\/li>\n<\/ul>\n\nSD-WAN <\/b><\/p>\n\nZa celovito oceno standardnih metrik stanja tunela se uporablja protokol BFD v echo na\u010dinu. Pri tem ni potrebna posebna povratna informacija v obliki TCA ali podobnih sporo\u010dil \u2013 zagotavlja se izolacija domene napak. Prav tako ni potrebno prisotnost uporabni\u0161kega prometa za oceno stanja tunela.<\/li>\n Obstaja mo\u017enost natan\u010dnega prilagajanja BFD \u010dasovnikov za regulacijo hitrosti aktivacije in ob\u010dutljivosti algoritma na degradacije komunikacijskega kanala od nekaj sekund do minut.\n
Ob trenutku pisanja \u010dlanka je v vsakem od tunelov predvidena le ena BFD seja. Potencialno to zmanj\u0161uje granularnost pri analizi stanja tunela. V resnici to lahko predstavlja omejitev le v primeru uporabe WAN povezave, ki temelji na MPLS L2\/L3 VPN s dogovorjenim QoS SLA \u2014 \u010de se DSCP ozna\u010devanje BFD prometa (po inkapsulaciji v IPSec\/GRE) ujema z visokoprioritetno vrsto v omre\u017eju operaterja, lahko to vpliva na natan\u010dnost in hitrost odkrivanja degradacije za nizkoprioritetni promet. Hkrati obstaja mo\u017enost spreminjanja privzete oznake BFD za zmanj\u0161anje tveganja za nastanek tak\u0161nih situacij. V naslednjih razli\u010dicah programske opreme Cisco SD-WAN se pri\u010dakuje pojav natan\u010dnej\u0161ega prilagajanja BFD in mo\u017enost zagonitve ve\u010d BFD sej v okviru enega tunela z individualnimi DSCP vrednostmi (za razli\u010dne aplikacije).<\/li>\n BFD dodatno omogo\u010da oceno najve\u010dje velikosti paketa, ki ga je mogo\u010de prenesti skozi dolo\u010den tunel brez fragmentacije. To omogo\u010da SD-WAN dinami\u010dno prilagajanje takih parametrov, kot so MTU in TCP MSS Adjust, da \u010dim bolj u\u010dinkovito izkoristimo razpolo\u017eljivo pasovno \u0161irino na vsakem kanalu.<\/li>\n V SD-WAN je na voljo tudi mo\u017enost sinhronizacije QoS z operaterji povezav, ne le na osnovi L3 DSCP polja, temve\u010d tudi na osnovi L2 CoS vrednosti, ki jih lahko avtomatsko oblikujejo specializirane naprave v podru\u017eni\u010dnem omre\u017eju \u2014 na primer, IP telefoni.<\/li>\n<\/ul>\n<\/p>\n
Kako se razlikujejo mo\u017enosti, na\u010dini dolo\u010danja in uporabe AppQ politik?<\/h3>\n <\/p>\n
Politike DMVPN\/PfR:<\/h4>\n <\/p>\n
\nDolo\u010dajo se na usmerjevalniku(-ih) centralne podru\u017enice (CP) prek ukazne vrstice CLI ali CLI predlog konfiguracij. Oblikovanje CLI predlog zahteva pripravo in znanje sintakse politik.\n
Dolo\u010dajo se globalno brez mo\u017enosti individualne nastavitve\/premene za zahteve posameznih segmentov omre\u017eja.<\/b><\/li>\nInteraktivno oblikovanje politik v grafi\u010dnem vmesniku ni predvideno.<\/li>\n Spremljanje sprememb, dedovanje, ustvarjanje ve\u010d razli\u010dic politik za hitro preklapljanje ni predvideno.<\/li>\n Samodejno se prena\u0161ajo na usmerjevalnike oddaljenih podru\u017enic. Pri tem se uporabljajo isti komunikacijski kanali kot za prenos uporabni\u0161kih podatkov. Pri pomanjkanju komunikacijskega kanala med centralno in oddaljeno podru\u017enico, prenos\/sprememba politik ni mogo\u010da.<\/li>\n Uporabljajo se na vsakem usmerjevalniku in po potrebi modificirajo rezultate standardnih protokolov usmerjanja, imajo vi\u0161 prioriteto. <\/li>\n Za primere, ko vsi WAN kanali podru\u017enice do\u017eivljajo znatne izgube prometa, mehanizmi kompenzacije niso predvideni<\/b>.<\/li>\n<\/ul>\n <\/p>\n
Politike SD-WAN:<\/h4>\n <\/p>\n
\nDolo\u010dajo se v grafi\u010dnem vmesniku vManage preko interaktivnega \u010darovnika za predloge.<\/li>\n Podpirajo ustvarjanje ve\u010d politik, kopiranje, dedovanje, preklapljanje med politikami v realnem \u010dasu.<\/li>\n Podpirajo individualno nastavitev politik za razli\u010dne segmente (podru\u017enice) omre\u017eja.<\/li>\n Prena\u0161ajo se z uporabo kateregakoli razpolo\u017eljivega signalnega kanala med krmilnikom in usmerjevalnikom in\/ali vSmart - niso neposredno odvisne od povezljivosti podatkovne ravni med usmerjevalniki. Seveda pa je potrebna IP povezljivost med samim usmerjevalnikom in krmilniki.\n
Za primere, ko vsi razpolo\u017eljivi kanali podru\u017enice do\u017eivljajo znatne izgube podatkov, ki presegajo dovoljene pragove za kriti\u010dne aplikacije, je mogo\u010de uporabiti dodatne mehanizme, ki pove\u010dujejo zanesljivost prenosa:\n\nFEC (Forward Error Correction)<\/b> \u2013 uporablja poseben algoritem za odve\u010dno kodiranje. Pri prenosu kriti\u010dnega prometa po kanalih z znatnim odstotkom izgub se lahko FEC samodejno aktivira in omogo\u010di obnavljanje izgubljenih delov podatkov, \u010de je to potrebno. Pri tem se nekoliko pove\u010da uporabljena pasovna \u0161irina, vendar se znatno pove\u010da zanesljivost.\n
Dublikacija podatkovnih tokov<\/b> \u2013 dodatno k FEC politika lahko predvideva samodejno dupliciranje prometa izbranih aplikacij v primeru \u0161e bolj resne ravni izgub, ki jih ni mogo\u010de nadomestiti s FEC. V tem primeru bodo izbrani podatki poslani skozi vse predore proti prejemni enoti z nadaljnjim de-duplication (izmetanje odve\u010dnih kopij paketov). Mehanizem bistveno pove\u010duje izkori\u0161\u010denost kanalov, hkrati pa tudi znatno pove\u010duje zanesljivost prenosa.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n <\/p>\n
Mo\u017enosti Cisco SD-WAN, brez neposrednih analogov v DMVPN\/PfR<\/h3>\n \nArhitektura re\u0161itve Cisco SD-WAN v nekaterih primerih omogo\u010da pridobitev zmo\u017enosti, katerih implementacija v okviru DMVPN\/PfR je ali izjemno te\u017eavna, ali neprimernna zaradi potrebnih delovnih naporov, ali pa preprosto nemogo\u010da. Oglejmo si nekatere izmed njih:<\/p>\n
Upravljanje prometa (TE)<\/h4>\n \nTE vklju\u010duje mehanizme, ki omogo\u010dajo odvajanje prometa od standardne poti, ki jo oblikujejo protokoli usmerjanja. TE se pogosto uporablja za zagotovitev visoke razpolo\u017eljivosti omre\u017enih storitev, zahvaljujo\u010d sposobnosti hitrega in\/ali predhodnega preusmerjanja pomembnega prometa na alternativno (nepre\u010dkanje) pot prenosa, z namenom zagotavljanja bolj\u0161e kakovosti storitve ali hitrosti obnove v primeru okvare glavne poti. <\/p>\n
Te\u017eava pri izvajanju TE je v potrebni predhodni izra\u010dunu in rezervaciji (preverjanju) alternativne poti. V MPLS omre\u017ejih telekomunikacijskih operaterjev to nalogo re\u0161ujejo z uporabo tehnologij, kot sta MPLS Traffic-Engineering z raz\u0161iritvami IGP protokolov in RSVP protokola. V zadnjem \u010dasu pa pridobiva vse ve\u010djo priljubljenost tudi tehnologija Segment Routing, ki je bolj optimizirana za centralizirano nastavitev in orkestracijo. V klasi\u010dnih WAN omre\u017ejih te tehnologije obi\u010dajno niso prisotne ali pa so zmanj\u0161ane na uporabo mehanizmov hop-by-hop, kot je Policy-Based Routing (PBR), ki lahko usmerjajo promet, vendar to izvajajo na vsakem usmerjevalniku posebej \u2013 brez upo\u0161tevanja splo\u0161nega stanja omre\u017eja ali rezultatov PBR na prej\u0161njih ali naslednjih korakih. Rezultat uporabe teh mo\u017enosti TE je razo\u010daranje \u2013 MPLS TE zaradi kompleksnosti nastavitve in obratovanja obi\u010dajno uporabljajo le v najkriti\u010dnej\u0161ih delih omre\u017eja (jedro), medtem ko se PBR uporablja na posameznih usmerjevalnikih brez mo\u017enosti oblikovanja nekak\u0161ne enotne PBR politike v celotnem omre\u017eju. O\u010ditno to velja tudi za omre\u017eja, temelje\u010da na DMVPN.<\/p>\n
Service-chaining (servisne verige) <\/h4>\n \nOblikovanje storitvenih verig je \u0161e bolj delovno intenzivna naloga v klasi\u010dnem usmerjanju kot \u017ee opisani mehanizem Traffic-Engineering. V tem primeru namre\u010d ni dovolj samo oblikovati posebno pot za dolo\u010deno omre\u017eno aplikacijo, temve\u010d je treba tudi omogo\u010diti usmerjanje prometa iz omre\u017eja na dolo\u010denih (ali na vseh) vozli\u0161\u010dih SD-WAN omre\u017eja za obdelavo s posebno aplikacijo ali storitvijo (MSE, uravnote\u017eenje, predpomnjenje, nadzor prometa itd.). Pri tem je pomembno imeti mo\u017enost nadzorovati stanje teh zunanjih storitev, da se izognemo situacijam izgube prometa, prav tako pa so potrebni mehanizmi, ki omogo\u010dajo name\u0161\u010danje tak\u0161nih podobnih zunanjih storitev na razli\u010dnih geo-lokacijah z mo\u017enostjo, da omre\u017eje samodejno izbere najbolj optimalno storitveno vozli\u0161\u010de za obdelavo prometa posameznega podru\u017enice. V primeru Cisco SD-WAN je to dovolj enostavno dose\u010di z ustvarjanjem ustrezne centralizirane politike, ki bo \u00bbspajala\u00ab vse vidike ciljne storitvene verige v enotno celoto in samodejno spremenila logiko podatkovnega in nadzornega plane le tam in takrat, kjer je to potrebno.<\/p>\n
Kaj na koncu?<\/h2>\n \nO\u010ditno je, da DMVPN (v povezavi ali brez Performance Routing) in Cisco SD-WAN na koncu re\u0161ujeta zelo podobne naloge<\/b> v zvezi z razdistributed WAN omre\u017ejem organizacije. Pri tem pa pomembne arhitekturne in funkcionalne razlike tehnologije Cisco SD-WAN postavljajo proces re\u0161evanja teh nalog na drugo kakovostno raven<\/b>. Na kratko lahko izpostavimo naslednje pomembne razlike med tehnologijami SD-WAN in DMVPN\/PfR:<\/p>\n\nDMVPN\/PfR na splo\u0161no uporablja preverjene tehnologije za postavitev prekrivnih VPN omre\u017eij in je po delu data-plane podoben sodobni tehnologiji SD-WAN, vendar ima dolo\u010dene omejitve zaradi obvezne stati\u010dne konfiguracije usmerjevalnikov in je izbira topologij omejena na Hub-n-Spoke. Po drugi strani pa DMVPN\/PfR ponuja nekatere funkcionalnosti, ki trenutno \u0161e niso na voljo v okviru SD-WAN (govorimo o per-application BFD).<\/li>\n Na ravni control-plane se tehnologije bistveno razlikujejo. Glede na centralizirano obdelavo signalnih protokolov SD-WAN omogo\u010da, med drugim, znatno zo\u017eitev domen okvar in 'lo\u010ditev' procesa prenosa uporabni\u0161kega prometa od signalne interakcije \u2013 za\u010dasna nedostopnost kontrolerjev ne vpliva na mo\u017enosti prenosa uporabni\u0161kega prometa. Hkrati pa za\u010dasna nedostopnost katerega koli podru\u017enice (vklju\u010dno s centralno) ne vpliva na mo\u017enosti preostalih podru\u017enic, da medsebojno komunicirajo in se pove\u017eejo s kontrolerji.<\/li>\n Arhitektura oblikovanja in izvajanja politik upravljanja prometa pri SD-WAN tudi bistveno presega DMVPN\/PfR \u2013 geografsko na\u010drtovanje je precej bolje izvedeno, ni vezanosti na Hub, ve\u010d mo\u017enosti za podrobno nastavitev politik, seznam izvedenih scenarijev upravljanja prometa pa je prav tako znatno dalj\u0161i.<\/li>\n Proces orkestracije re\u0161itev se prav tako znatno razlikuje. DMVPN predvideva obstoje\u010de znane parametre, ki jih je treba na nek na\u010din odra\u017eati v konfiguraciji, kar nekoliko omejuje prilagodljivost re\u0161itve in mo\u017enost dinami\u010dnih sprememb. Po drugi strani SD-WAN izhaja iz paradigme, da ob za\u010detnem povezovanju usmerjevalnik 'ne ve ni\u010d' o svojih kontrolerjih, vendar ve 'koga lahko vpra\u0161a' \u2013 to je dovolj ne le za avtomatsko vzpostavljanje povezave s kontrolerji, temve\u010d tudi za avtomatsko oblikovanje popolnoma medsebojno povezanih data-plane topologij, ki jih je nato mogo\u010de fleksibilno prilagoditi\/spremeniti s politikami.<\/li>\n V delu centraliziranega upravljanja, avtomatizacije in nadzora SD-WAN pri\u010dakovano presega zmogljivosti DMVPN\/PfR, ki so rezultat razvoja klasi\u010dnih tehnologij in se v ve\u010dji meri zana\u0161ajo na ukazno vrstico CLI ter uporabo NMS sistemov na osnovi predlog. <\/li>\n V SD-WAN v primerjavi z DMVPN so zahteve za varnost dosegle nov kakovostni nivo. Glavna na\u010dela so ni\u010delno zaupanje, raz\u0161irljivost in dvofaktorska avtentikacija.<\/li>\n<\/ul>\n\nIz teh preprostih zaklju\u010dkov se lahko ustvari napa\u010den vtis, da je ustvarjanje omre\u017eja na osnovi DMVPN\/PfR danes izgubilo vse aktualnosti. To seveda ni povsem res. Na primer, v primerih, ko je v omre\u017eju uporabljena \u0161tevilna zastarela oprema in ni mo\u017enosti za njeno zamenjavo, lahko DMVPN omogo\u010di povezovanje \"starih\" in \"novih\" naprav v enotno geo-razporejeno omre\u017eje z mno\u017eico prej omenjenih prednosti.<\/p>\n
Po drugi strani je treba upo\u0161tevati, da vsi aktualni korporativni usmerjevalniki Cisco na osnovi IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) danes podpirajo katerikoli na\u010din delovanja \u2013 tako klasi\u010dno usmerjanje kot DMVPN in SD-WAN \u2013 izbira pa je dolo\u010dena s trenutnimi potrebami in razumevanjem, da je v vsakem trenutku mogo\u010de na isti opremi preiti na bolj napredno tehnologijo.<\/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