Capabilit\u0103\u021bile func\u021bionale \u2013 ce poate face o tehnologie ceea ce nu poate face alta? \u0218i c\u00e2t de important este acest lucru?<\/li>\n<\/ul>\n<\/p>\n
Care sunt diferen\u021bele arhitecturale \u0219i c\u00e2t de importante sunt ele?<\/h3>\n \nFiecare dintre tehnologiile men\u021bionate con\u021bine o mul\u021bime de \u201ep\u0103r\u021bi mobile\u201d, ale c\u0103ror roluri \u0219i principii de interac\u021biune difer\u0103. De la c\u00e2t de bine sunt concepute aceste principii depind scalabilitatea, rezilien\u021ba la erori \u0219i eficien\u021ba general\u0103 a solu\u021biei. <\/p>\n
S\u0103 analiz\u0103m diferitele aspecte ale arhitecturii mai \u00een detaliu:<\/p>\n
Data-plane<\/b> \u2013 partea solu\u021biei responsabil\u0103 pentru transmiterea traficului utilizatorilor \u00eentre surs\u0103 \u0219i destinatar. \u00cen DMVPN \u0219i SD-WAN, aceasta este implementat\u0103 \u00een ansamblu la fel pe routerele bazate pe tuneluri Multipoint GRE. Diferen\u021ba const\u0103 \u00een modul \u00een care se formeaz\u0103 setul necesar de parametri pentru aceste tuneluri:<\/p>\n\n\u00een DMVPN\/PfR<\/b> \u2013 este o ierarhie a nodurilor cu dou\u0103 niveluri, cu o topologie de tip \u201eStea\u201d sau Hub-n-Spoke. Configurarea static\u0103 a Hub-ului \u0219i legarea static\u0103 a Spoke-ului de Hub sunt obligatorii, precum \u0219i interac\u021biunea prin protocolul NHRP pentru a forma conectivitatea data-plane. Ca urmare, modific\u0103rile pe Hub sunt semnificativ dificile,<\/b>, legate, de exemplu, de schimbarea\/conectarea unor noi canale WAN sau de modificarea parametrilor celor existente.<\/li>\n\u00een SD-WAN<\/b> \u2013 este un model complet dinamic de detectare a parametrilor tunelurilor stabilite, bazat pe control-plane (protocolul OMP) \u0219i orchestration-plane (interac\u021biunea cu controller-ul vBond pentru sarcini de descoperire a controller-elor \u0219i traversarea NAT). \u00cen acest context, topologiile impuse pot fi diverse, inclusiv ierarhice. \u00cen cadrul topologiei impuse stabilite a tunelurilor, este posibil\u0103 configurarea flexibil\u0103 a topologiei logice \u00een fiecare VPN (VRF) individual.<\/li>\n<\/ul>\n Control-plane<\/b> \u2013 func\u021biile de schimb, filtrare \u0219i modificare a informa\u021biilor rutiere \u0219i altor informa\u021bii \u00eentre componentele solu\u021biei. <\/p>\n\n\u00een DMVPN\/PfR<\/b> \u2013 se realizeaz\u0103 doar \u00eentre routerele Hub \u0219i Spoke. Schimbul direct de informa\u021bii rutiere \u00eentre Spoke-uri este imposibil. Ca urmare, f\u0103r\u0103 un Hub func\u021bional, func\u021bionarea control-plane \u0219i data-plane nu este posibil\u0103.<\/b>, ceea ce impune Hub-ului cerin\u021be suplimentare de disponibilitate ridicat\u0103, care nu pot fi \u00eentotdeauna \u00eendeplinite.<\/li>\n\u00een SD-WAN<\/b> \u2013 control-plane-ul nu este realizat direct \u00eentre routere \u2013 interac\u021biunea se desf\u0103\u0219oar\u0103 pe baza protocolului OMP \u0219i se efectueaz\u0103 obligatoriu printr-un tip specializat de controler vSmart, ceea ce permite echilibrarea, rezervarea geo \u0219i gestionarea centralizat\u0103 a sarcinii semnalului. O alt\u0103 caracteristic\u0103 a protocolului OMP este rezisten\u021ba sa semnificativ\u0103 la pierderi \u0219i independen\u021ba fa\u021b\u0103 de viteza canalului de comunica\u021bie cu controlerele (\u00een limite rezonabile, desigur). Acest lucru permite, de asemenea, plasarea controlerelor SD-WAN \u00een cloud-uri publice sau private cu acces prin Internet.<\/li>\n<\/ul>\n Policy-plane<\/b> \u2013 partea solu\u021biei responsabil\u0103 pentru definirea, r\u0103sp\u00e2ndirea \u0219i aplicarea politicilor de gestionare a traficului \u00een re\u021beaua distribuit\u0103.<\/p>\n\nDMVPN <\/b>\u2013 este de fapt limitat\u0103 de politicile de calitate a serviciilor (QoS), configurabile individual pe fiecare router prin CLI sau \u0219abloane Prime Infrastructure.<\/li>\nDMVPN\/PfR<\/b> \u2013 politicile PfR sunt generate pe routerul centralizat Master Controller (MC) prin CLI \u0219i apoi r\u0103sp\u00e2ndite automat \u00een MC-urile sucursalelor. Se utilizeaz\u0103 acelea\u0219i c\u0103i pentru transmiterea politicilor ca \u0219i pentru data-plane. Nu exist\u0103 posibilitatea de a separa schimbul de politici, informa\u021bii de rutare \u0219i date ale utilizatorilor. R\u0103sp\u00e2ndirea politicilor presupune o conectivitate IP obligatorie \u00eentre Hub \u0219i Spoke. Func\u021bia MC poate fi, dac\u0103 este necesar, combinat\u0103 cu routerul DMVPN. Este posibil (dar nu obligatoriu) s\u0103 se utilizeze \u0219abloane Prime Infrastructure pentru generarea centralizat\u0103 a politicilor. O caracteristic\u0103 important\u0103 este c\u0103 politica este generat\u0103 global pe \u00eentreaga re\u021bea \u00een mod uniform \u2013 politicile individuale pentru segmente separate nu sunt suportate.<\/b>.<\/li>\nSD-WAN<\/b> Politicile de gestionare a traficului \u0219i a calit\u0103\u021bii serviciului sunt definite centralizat prin intermediul interfe\u021bei grafice Cisco vManage, disponibil\u0103 inclusiv prin Internet (dac\u0103 este necesar). Acestea sunt distribuite prin canale de semnalizare direct sau indirect prin intermediul controlerelor vSmart (\u00een func\u021bie de tipul politicii). Nu depind de conectivitatea data-plane \u00eentre routere, deoarece folosesc toate c\u0103ile disponibile pentru transmiterea traficului \u00eentre controler \u0219i router.\n Pentru diferite segmente de re\u021bea, este posibil\u0103 formarea flexibil\u0103 a diferitelor politici \u2013 domeniul de aplicare al unei politici este definit de o mul\u021bime de identificatori unici prev\u0103zu\u021bi \u00een solu\u021bie \u2013 num\u0103rul sucursalei, tipul aplica\u021biei, direc\u021bia de mi\u0219care a traficului etc.\n<\/li>\n<\/ul>\n
Orchestration-plane<\/b> \u2013 mecanisme care permit componentelor s\u0103 se descopere dinamic, s\u0103 se configureze \u0219i s\u0103 coordoneze interac\u021biunile ulterioare.<\/p>\n\n\u00een DMVPN\/PfR<\/b> Descoperirea reciproc\u0103 \u00eentre routere se bazeaz\u0103 pe configurarea static\u0103 a dispozitivelor Hub \u0219i set\u0103rile corespunz\u0103toare pentru dispozitivele Spoke. Descoperirea dinamic\u0103 se produce doar pentru Spoke, care comunic\u0103 parametrii s\u0103i de conectare dispozitivului Hub, care a fost anterior inclus \u00een configurarea Spoke. F\u0103r\u0103 conectivitate IP a Spoke cu cel pu\u021bin un Hub nu este posibil s\u0103 se formeze nici data-plane, nici control-plane.<\/b><\/li>\n\u00een SD-WAN<\/b> Orchestrarea componentelor solu\u021biei se face folosind controlerul vBond, cu care fiecare component\u0103 (routere \u0219i controlere vManage\/vSmart) trebuie s\u0103 stabileasc\u0103 anterior conectivitate IP.\n Ini\u021bial, componentele nu \u0219tiu despre parametrii de conectare ale celorlalte \u2013 pentru aceasta au nevoie de un intermediar-orchestrator, vBond. Principiul general este urm\u0103torul \u2013 cada component\u0103, \u00een faza ini\u021bial\u0103, afl\u0103 (automat sau static) doar despre parametrii de conectare la vBond, iar mai departe, vBond informeaz\u0103 routerul despre controlerele vManage \u0219i vSmart (descoperite anterior), ceea ce face posibil\u0103 stabilirea automat\u0103 a tuturor conexiunilor de semnalizare necesare. <\/p>\n
Urm\u0103torul pas, noul router va afla despre celelalte routere din re\u021bea prin intermediul schimbului OMP cu controlerul vSmart. Astfel, routerul, f\u0103r\u0103 a avea cuno\u0219tin\u021b\u0103 ini\u021bial\u0103 despre parametrii re\u021bei, este capabil s\u0103 descopere \u0219i s\u0103 se conecteze complet automat la controlere \u0219i, de asemenea, s\u0103 descopere \u0219i s\u0103 formeze conexiuni cu celelalte routere. \u00cen acest proces, parametrii de conectare ai tuturor componentelor sunt ini\u021bial necunoscu\u021bi \u0219i pot varia pe parcursul exploat\u0103rii.\n<\/li>\n<\/ul>\n
Management-plane<\/b> \u2013 partea solu\u021biei care asigur\u0103 management \u0219i monitorizare centralizat\u0103.<\/p>\n\nDMVPN\/PfR<\/b> \u2013 nu este prev\u0103zut\u0103 o solu\u021bie specializat\u0103 pentru management-plane. Pentru automatizarea de baz\u0103 \u0219i monitorizarea, se pot folosi produse precum Cisco Prime Infrastructure. Fiecare router are capacitatea de a fi gestionat prin linia de comand\u0103 CLI. Integr\u0103rile cu sistemele externe prin API nu sunt prev\u0103zute.<\/b><\/li>\nSD-WAN<\/b> \u2013 toat\u0103 interac\u021biunea \u0219i monitorizarea se realizeaz\u0103 centralizat prin intermediul interfe\u021bei grafice a controlerului vManage. Toate func\u021bionalit\u0103\u021bile solu\u021biei sunt complet disponibile pentru configurare prin vManage, precum \u0219i prin intermediul unei biblioteci complet documentate de API REST.\n Toate configur\u0103rile re\u021belei SD-WAN \u00een vManage se reduc la dou\u0103 concepte de baz\u0103 \u2013 crearea \u0219abloanelor de dispozitive (Device Template) \u0219i crearea politicii care define\u0219te logica opera\u021biunilor re\u021belei \u0219i gestionarea traficului. \u00cen acest proces, vManage, transmi\u021b\u00e2nd politica formulat\u0103 de administrator, selecteaz\u0103 automat ce modific\u0103ri \u0219i pe ce dispozitive individuale\/controlere trebuie efectuate, ceea ce cre\u0219te semnificativ eficien\u021ba \u0219i scalabilitatea solu\u021biei.<\/p>\n
Prin intermediul interfe\u021bei vManage, este disponibil nu doar managementul solu\u021biei Cisco SD-WAN, ci \u0219i o monitorizare complet\u0103 a st\u0103rii tuturor componentelor solu\u021biei, inclusiv starea curent\u0103 a metrilor pentru tuneluri individuale \u0219i statistica utiliz\u0103rii diferitelor aplica\u021bii pe baza analizei DPI.<\/p>\n
\u00cen ciuda centraliz\u0103rii interac\u021biunii, toate componentele (controlerele \u0219i routerele) dispun de un terminal CLI complet func\u021bional, necesar \u00een etapa de implementare sau \u00een caz de situa\u021bii neprev\u0103zute pentru diagnosticarea local\u0103. \u00cen mod normal (c\u00e2nd exist\u0103 un canal de semnal \u00eentre componente), terminalul de comenzi pe routere este disponibil doar pentru diagnosticare \u0219i nu poate fi utilizat pentru modific\u0103ri locale, ceea ce garanteaz\u0103 at\u00e2t securitatea local\u0103, c\u00e2t \u0219i un singur punct de modificare \u00eentr-o astfel de re\u021bea \u2013 vManage.<\/li>\n<\/ul>\n
\nSecuritate integrat\u0103<\/b> \u2013 aici este vorba nu doar despre protejarea datelor utilizatorilor \u00een timpul transmiterii prin canale deschise, ci \u0219i despre securitatea general\u0103 a re\u021belei WAN pe baza tehnologiei alese.<\/p>\n\n\u00een DMVPN\/PfR<\/b> se preconizeaz\u0103 criptarea datelor utilizatorilor \u0219i a protocoalelor de semnalizare. Utiliz\u00e2nd anumite modele de routere, sunt disponibile suplimentar func\u021bii de firewall cu inspec\u021bie de trafic, IPS\/IDS. Exist\u0103 posibilitatea segment\u0103rii re\u021belelor de sucursale utiliz\u00e2nd VRF. Exist\u0103, de asemenea, op\u021biunea de autentificare (unifactorial\u0103) a protocoalelor de control.\n Prin urmare, routerul la distan\u021b\u0103 este considerat implicit un element de \u00eencredere \u00een re\u021bea \u2013 adic\u0103 nu se presupun \u0219i nu sunt luate \u00een considerare cazuri de compromitere fizic\u0103 a unor dispozitive individuale \u0219i posibilitatea accesului neautorizat la acestea, nu exist\u0103 autentificare \u00een doi pa\u0219i pentru componentele solu\u021biei, ceea ce, \u00een cazul unei re\u021bele distribuite geografic, poate prezenta riscuri suplimentare serioase.<\/b> <\/li>\n\u00een SD-WAN<\/b> \u00een analogie cu DMVPN, este preconizat\u0103 criptarea datelor utilizatorilor, dar cu func\u021bii de securitate a re\u021belei \u0219i segmentare L3\/VRF semnificativ extinse (MSS, IPS\/IDS, filtrare URL, filtrare DNS, AMP\/TG, SASE, proxy TLS\/SSL etc.). \u00cen acest caz, schimbul de chei de criptare se realizeaz\u0103 mai eficient prin intermediul controlerelor vSmart (nu direct), prin canale de semnalizare predefinite, protejate prin criptare DTLS\/TLS pe baza certificatelor de securitate. Acest lucru garanteaz\u0103 securitatea unui astfel de schimb \u0219i asigur\u0103 o scalabilitate mai bun\u0103 a solu\u021biei, p\u00e2n\u0103 la zeci de mii de dispozitive \u00eentr-o singur\u0103 re\u021bea.\n Toate conexiunile de semnal (controler-controler, controler-router) sunt, de asemenea, protejate pe baza DTLS\/TLS. Ruterii sunt echipa\u021bi cu certificate de securitate la fabrica\u021bie, av\u00e2nd posibilitatea de \u00eenlocuire\/extindere. Autentificarea cu dou\u0103 factori se realizeaz\u0103 prin \u00eendeplinirea obligatorie \u0219i simultan\u0103 a dou\u0103 condi\u021bii pentru a permite func\u021bionarea routerului\/controlerului \u00een re\u021beaua SD-WAN:<\/p>\n
\nCertificat de securitate activ<\/li>\n Includerea explicit\u0103 \u0219i con\u0219tient\u0103 de c\u0103tre administrator a fiec\u0103rui component \u00een lista \u201ealb\u0103\u201d de dispozitive autorizate.<\/li>\n<\/ul>\n\n<\/li>\n<\/ul>\n
Diferen\u021bele func\u021bionale \u00eentre SD-WAN \u0219i DMVPN\/PfR<\/h2>\n \nTrec\u00e2nd la discutarea diferen\u021belor func\u021bionale, trebuie men\u021bionat c\u0103 multe dintre acestea sunt o continuare a aspectelor arhitecturale \u2013 nu este un secret c\u0103, \u00een formarea arhitecturii solu\u021biei, dezvoltatorii pornesc de la acele capacit\u0103\u021bi pe care doresc s\u0103 le ob\u021bin\u0103 \u00een final. S\u0103 analiz\u0103m cele mai semnificative diferen\u021be \u00eentre cele dou\u0103 tehnologii.<\/p>\n
AppQ (Calitatea Aplica\u021biei) \u2013 func\u021bii care asigur\u0103 calitatea transmisiei de trafic pentru aplica\u021biile de afaceri<\/h3>\n \nFunc\u021biile cheie ale tehnologiilor discutate sunt orientate spre \u00eembun\u0103t\u0103\u021birea experien\u021bei utilizatorului atunci c\u00e2nd utilizeaz\u0103 aplica\u021bii critice pentru afaceri \u00eentr-o re\u021bea distribuit\u0103. Acest lucru este deosebit de important \u00een condi\u021biile \u00een care o parte din infrastructur\u0103 nu este controlat\u0103 de IT sau chiar nu garanteaz\u0103 o transmitere de date de succes.<\/p>\n
DMVPN nu ofer\u0103 de la sine astfel de mecanisme. Cel mai bun lucru care se poate realiza \u00eentr-o re\u021bea DMVPN clasic\u0103 este clasificarea traficului de ie\u0219ire pe aplica\u021bii \u0219i prioritizarea acestuia \u00een momentul transmiterii c\u0103tre canalul WAN. Alegerea tunelului DMVPN este \u00een acest caz determinat\u0103 doar de disponibilitatea sa \u0219i de rezultatul func\u021bion\u0103rii protocoalelor de rutare. \u00cen aceast\u0103 situa\u021bie, nu se ia \u00een considerare starea global\u0103 a c\u0103ii\/tunelului \u0219i posibila sa degradare par\u021bial\u0103 din perspectiva metricilor cheie, relevante pentru aplica\u021biile de re\u021bea \u2013 \u00eent\u00e2rziere, varia\u021bia \u00eent\u00e2rzierei (jitter) \u0219i pierderi (%). Din acest motiv, compara\u021bia direct\u0103 \u00eentre DMVPN clasic \u0219i SD-WAN \u00een ceea ce prive\u0219te solu\u021bionarea problemelor AppQ \u00ee\u0219i pierde orice sens \u2013 DMVPN nu poate rezolva aceast\u0103 problem\u0103. C\u00e2nd ad\u0103ug\u0103m \u00een acest context tehnologia Cisco Performance Routing (PfR), situa\u021bia se schimb\u0103 \u0219i compara\u021bia cu Cisco SD-WAN devine mai justificat\u0103. <\/p>\n
\u00cenainte de a discuta diferen\u021bele, s\u0103 prezent\u0103m pe scurt asem\u0103n\u0103rile tehnologice. Astfel, ambele tehnologii:<\/p>\n
\nau un mecanism care permite evaluarea dinamic\u0103 a st\u0103rii fiec\u0103rui tunel instalat pe baza unor metrici specifice \u2013 cel pu\u021bin, \u00eent\u00e2rziere, varia\u021bia \u00eent\u00e2rzierii \u0219i pierderile de pachete (%)<\/li>\n folosesc un set specific de instrumente pentru a crea, distribui \u0219i aplica reguli (politici) de management al traficului pe baza rezultatelor m\u0103sur\u0103rii st\u0103rii principalelor metrici ale tunelurilor.<\/li>\n clasific\u0103 traficul aplica\u021biilor la nivelurile L3-L4 (DSCP) din modelul OSI sau \u00een func\u021bie de semn\u0103turile L7 ale aplica\u021biilor, baz\u00e2ndu-se pe mecanismele DPI integrate \u00een router.<\/li>\n permit pentru aplica\u021biile semnificative s\u0103 defineasc\u0103 valori de prag acceptabile pentru metrici, reguli de transmitere a traficului prestabilite \u0219i reguli de rerouting al traficului la dep\u0103\u0219irea valorilor prag.<\/li>\n c\u00e2nd se \u00eencastreaz\u0103 traficul \u00een GRE\/IPSec, folosesc un mecanism deja consacrat \u00een industrie pentru a transporta marcajul intern DSCP \u00een antetul extern al pachetului GRE\/IPSec, ceea ce permite sincronizarea politicilor QoS ale organiza\u021biei \u0219i operatorului de telecomunica\u021bii (\u00een cazul unui SLA corespunz\u0103tor).<\/li>\n<\/ul>\n\n
Cum difer\u0103 mecanismele de evaluare a metricilor end-to-end SD-WAN \u0219i DMVPN\/PfR?<\/h3>\n \nDMVPN\/PfR <\/b><\/p>\n\nPentru evaluarea metricilor standard ale st\u0103rii tunelului, se folosesc at\u00e2t senzori activi, c\u00e2t \u0219i pasivi (Probes). Senzorii activi se bazeaz\u0103 pe traficul utilizatorilor, iar cei pasivi simulaz\u0103 un astfel de trafic (\u00een absen\u021ba acestuia). <\/li>\n Ajust\u0103rile fine ale temporizatoarelor \u0219i condi\u021biilor de depistare a degrad\u0103rii sunt absente \u2013 algoritmul este fix.<\/li>\n De asemenea, este disponibil\u0103 m\u0103surarea l\u0103\u021bimii de band\u0103 utilizate \u00een direc\u021bia de ie\u0219ire. Aceasta confer\u0103 DMVPN\/PfR o flexibilitate suplimentar\u0103 \u00een gestionarea traficului.<\/li>\n \u00cen acest context, unele mecanisme PfR, la dep\u0103\u0219irea metricilor, se bazeaz\u0103 pe feedback-ul invers sub form\u0103 de mesaje speciale TCA (Threshold Crossing Alert), care trebuie s\u0103 provin\u0103 de la destinatarul traficului c\u0103tre surs\u0103, ceea ce presupune c\u0103 st\u0103rile canalelor m\u0103surate trebuie s\u0103 fie cel pu\u021bin suficiente pentru a transmite astfel de mesaje TCA. Aceasta, \u00een majoritatea cazurilor, nu reprezint\u0103 o problem\u0103, dar evident nu poate fi garantat\u0103. <\/li>\n<\/ul>\n\nSD-WAN <\/b><\/p>\n\nPentru evaluarea standard a metricilor de stare a tunelului se folose\u0219te protocolul BFD \u00een modul echo. Astfel, nu este necesar\u0103 o retroac\u021biune special\u0103 sub forma mesajelor TCA sau similare \u2013 se respect\u0103 izola\u021bia domeniilor de e\u0219ec. De asemenea, nu este necesar\u0103 prezen\u021ba traficului utilizatorului pentru evaluarea st\u0103rii tunelului.<\/li>\n Exist\u0103 posibilitatea de a ajusta fin temporizatoarele BFD pentru a regla viteza de activare \u0219i sensibilitatea algoritmului la degrad\u0103rile canalului de comunica\u021bie de la c\u00e2teva secunde la minute.\n
\u00cen momentul redact\u0103rii articolului, fiecare tunel prevede doar o singur\u0103 sesiune BFD. Acest lucru creeaz\u0103 poten\u021bial o granularitate mai mic\u0103 la analiza st\u0103rii tunelului. \u00cen realitate, aceasta poate deveni o limitare doar \u00een cazul utiliz\u0103rii unei conexiuni WAN bazate pe MPLS L2\/L3 VPN cu un SLA QoS convenit \u2014 dac\u0103 marcajul DSCP al traficului BFD (dup\u0103 encapsularea \u00een IPSec\/GRE) coincide cu coada de \u00eenalt\u0103 prioritate din re\u021beaua operatorului de telecomunica\u021bii, atunci aceasta poate afecta acurate\u021bea \u0219i viteza de detectare a degrad\u0103rii pentru traficul de prioritate sc\u0103zut\u0103. Exist\u0103 totu\u0219i op\u021biunea de a modifica marcajul BFD implicit pentru a reduce riscul apari\u021biei unor astfel de situa\u021bii. \u00cen versiunile viitoare ale software-ului Cisco SD-WAN se a\u0219teapt\u0103 apari\u021bia unor ajust\u0103ri mai fine ale BFD, precum \u0219i posibilitatea de a lansa mai multe sesiuni BFD \u00een cadrul unui singur tunel cu valori DSCP individuale (pentru aplica\u021bii diferite).<\/li>\n BFD permite, de asemenea, evaluarea dimensiunii maxime a pachetului care poate fi transmis printr-un anumit tunel f\u0103r\u0103 fragmentare. Aceasta permite SD-WAN s\u0103 ajusteze dinamic astfel de parametrii precum MTU \u0219i TCP MSS Adjust, pentru a utiliza c\u00e2t mai eficient l\u0103\u021bimea de band\u0103 disponibil\u0103 pe fiecare canal.<\/li>\n \u00cen SD-WAN este disponibil\u0103 \u0219i op\u021biunea de sincronizare QoS cu operatorii de telecomunica\u021bii nu doar pe baza c\u00e2mpului L3 DSCP, ci \u0219i pe baza valorilor L2 CoS, care pot fi formate automat \u00een re\u021beaua filialei de c\u0103tre dispozitive specializate \u2014 de exemplu, telefoane IP.<\/li>\n<\/ul>\n<\/p>\n
Cum difer\u0103 capacit\u0103\u021bile, metodele de determinare \u0219i aplicarea politicilor AppQ?<\/h3>\n <\/p>\n
Politici DMVPN\/PfR:<\/h4>\n <\/p>\n
\nSunt definite pe routerele(-le) centrale ale filialei prin intermediul interfe\u021bei de linie de comand\u0103 CLI sau a \u0219abloanelor de configurare CLI. Crearea \u0219abloanelor CLI necesit\u0103 preg\u0103tire \u0219i cuno\u0219tin\u021be despre sintaxa politicilor.\n
Definite globalmente f\u0103r\u0103 posibilitatea de personalizare sau modificare, \u00een func\u021bie de cerin\u021bele diferitelor segmente de re\u021bea.<\/b><\/li>\nGenerarea interactiv\u0103 de politici \u00een interfa\u021ba grafic\u0103 nu este prev\u0103zut\u0103.<\/li>\n Urm\u0103rirea modific\u0103rilor, mo\u0219tenirea, crearea mai multor versiuni ale politicilor pentru comutarea rapid\u0103 nu sunt prev\u0103zute.<\/li>\n Se aplic\u0103 automat pe routerele filialelor \u00eendep\u0103rtate. \u00cen acest proces, se folosesc acelea\u0219i canale de comunica\u021bie ca pentru transferul datelor utilizatorilor. \u00cen absen\u021ba unui canal de comunica\u021bie \u00eentre filiala central\u0103 \u0219i cea \u00eendep\u0103rtat\u0103, distribuirea\/modificarea politicilor nu este posibil\u0103.<\/li>\n Se aplic\u0103 pe fiecare router \u0219i, c\u00e2nd este necesar, modific\u0103 rezultatul protocoalelor de rutare standard, av\u00e2nd o prioritate mai mare. <\/li>\n Pentru cazurile \u00een care toate canalele WAN ale filialei sufer\u0103 pierderi semnificative de trafic, mecanismele de compensare nu sunt prev\u0103zute.<\/b>.<\/li>\n<\/ul>\n <\/p>\n
Politici SD-WAN:<\/h4>\n <\/p>\n
\nSe definesc \u00een interfa\u021ba grafic\u0103 vManage prin asistentul interactiv de \u0219abloane.<\/li>\n Suport\u0103 crearea mai multor politici, copiere, mo\u0219tenire, comutare \u00eentre politici \u00een timp real.<\/li>\n Suport\u0103 personalizarea individual\u0103 a politicilor pentru diferite segmente (filiale) ale re\u021belei.<\/li>\n Se distribuie, folosind orice canal de semnal disponibil \u00eentre controler \u0219i router \u0219i\/sau vSmart \u2013 nu depind \u00een mod direct de conectivitatea data-plane \u00eentre routere. Totu\u0219i, este necesar\u0103 conectivitatea IP \u00eentre router \u0219i controlere.\n
Pentru cazurile \u00een care toate canalele disponibile ale filialei sufer\u0103 pierderi semnificative de date, dep\u0103\u0219ind pragurile admisibile pentru aplica\u021biile critice, se poate utiliza mecanisme suplimentare care cresc fiabilitatea transmiterii:\n\nFEC (Corectarea erorilor \u00een avans)<\/b> \u2013 folose\u0219te un algoritm special de codare redundant\u0103. Atunci c\u00e2nd se transmite trafic critic prin canale cu un procent semnificativ de pierderi, FEC poate fi activat automat \u0219i permite, dac\u0103 este necesar, recuperarea p\u0103r\u021bii de date pierdute. \u00cen acest proces, se cre\u0219te u\u0219or l\u0103\u021bimea de band\u0103 utilizat\u0103, dar se \u00eembun\u0103t\u0103\u021be\u0219te semnificativ fiabilitatea.\n
Duplicarea fluxurilor de date.<\/b> \u2013 \u00een plus fa\u021b\u0103 de FEC, politica poate prevedea duplicarea automat\u0103 a traficului pentru aplica\u021biile selectate \u00een cazul unor pierderi \u0219i mai grave, care nu pot fi compensate prin FEC. \u00cen acest caz, datele selectate vor fi transmise prin toate tunelurile c\u0103tre filiala destinatar\u0103 cu ulterior deduplicarea (eliminarea copiilor inutile ale pachetelor). Mecanismul cre\u0219te semnificativ utilizarea canalelor, dar de asemenea \u00eembun\u0103t\u0103\u021be\u0219te considerabil fiabilitatea transmitere.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n <\/p>\n
Func\u021bionalit\u0103\u021bile Cisco SD-WAN, f\u0103r\u0103 echivalente directe \u00een DMVPN\/PfR<\/h3>\n \nArhitectura solu\u021biei Cisco SD-WAN permite \u00een anumite cazuri ob\u021binerea unor func\u021bionalit\u0103\u021bi, implementarea c\u0103rora \u00een cadrul DMVPN\/PfR este fie extrem de dificultoas\u0103, fie ineficient\u0103 din cauza eforturilor necesare, fie complet imposibil\u0103. S\u0103 analiz\u0103m cele mai interesante dintre ele:<\/p>\n
Ingineria traficului (TE)<\/h4>\n \nTE include mecanisme care permit devierea traficului de la calea standard, format\u0103 de protocoalele de rutare. TE este adesea utilizat\u0103 pentru a asigura disponibilitatea ridicat\u0103 a serviciilor de re\u021bea, datorit\u0103 capacit\u0103\u021bii de a muta rapid \u0219i\/sau \u00een prealabil traficul important pe un drum alternativ (neintersectant), cu scopul de a asigura o calitate mai bun\u0103 a serviciului sau o vitez\u0103 de recuperare mai rapid\u0103 \u00een cazul unei defec\u021biuni pe drumul principal. <\/p>\n
Dificultatea implement\u0103rii TE const\u0103 \u00een necesitatea de a calcula \u0219i rezerva (verifica) mai devreme o alternativ\u0103 de rutare. \u00cen re\u021belele MPLS ale operatorilor de telecomunica\u021bii, aceast\u0103 problem\u0103 este rezolvat\u0103 prin utilizarea unor tehnologii precum MPLS Traffic Engineering, \u00eempreun\u0103 cu extensiile protocolului IGP \u0219i protocolul RSVP. De asemenea, tehnologia Segment Routing c\u00e2\u0219tig\u0103 din ce \u00een ce mai mult\u0103 popularitate \u00een ultima vreme, fiind mai optimizat\u0103 pentru configurarea \u0219i orchestri\u021bia centralizat\u0103. \u00cen re\u021belele WAN clasice, aceste tehnologii sunt, de regul\u0103, absente sau reduse la utilizarea mecanismelor hop-by-hop, cum ar fi Policy-Based Routing (PBR), care pot devia traficul, dar o fac pe fiecare router \u00een parte \u2014 f\u0103r\u0103 a lua \u00een considerare starea general\u0103 a re\u021belei sau rezultatul PBR \u00een pa\u0219ii anteriori sau ulteriori. Rezultatul aplic\u0103rii acestor variante TE este dezam\u0103gitor \u2014 MPLS TE, din cauza complexit\u0103\u021bii sale de configurare \u0219i operare, este folosit, de regul\u0103, doar \u00een cele mai critice p\u0103r\u021bi ale re\u021belei (nucleu), iar PBR este utilizat pe routere individuale, f\u0103r\u0103 posibilitatea de a forma o politic\u0103 PBR unic\u0103 pe \u00eentreaga re\u021bea. Este evident c\u0103 aceasta se aplic\u0103 \u0219i re\u021belelor bazate pe DMVPN.<\/p>\n
Service-chaining (Catenarea de servicii) <\/h4>\n \nFormarea lan\u021burilor de servicii este o sarcin\u0103 \u0219i mai laborioas\u0103 \u00een rutarea clasic\u0103 dec\u00e2t mecanismul deja descris de Traffic Engineering. \u00cen acest caz, este necesar nu doar s\u0103 fie creat un anumit traseu special pentru o aplica\u021bie de re\u021bea specific\u0103, ci \u0219i s\u0103 se asigure posibilitatea de extragere a traficului din re\u021bea pe anumite (sau pe toate) noduri ale re\u021belei SD-WAN pentru a fi procesat de o aplica\u021bie sau serviciu special (MPLS, Balansare, Cache, Inspec\u021bia traficului etc.). Este necesar, de asemenea, s\u0103 existe posibilitatea de a controla starea acestor servicii externe, pentru a evita situa\u021bii de black-holing, precum \u0219i mecanisme care s\u0103 permit\u0103 plasarea acestor servicii externe similare \u00een diverse loca\u021bii geo-geografice, av\u00e2nd capacitatea re\u021belei de a alege automat nodul de serviciu cel mai optim pentru procesarea traficului dintr-un anumit filiar. \u00cen cazul Cisco SD-WAN, acest lucru este relativ simplu de realizat, cre\u00e2nd o politic\u0103 centralizat\u0103 corespunz\u0103toare, care s\u0103 \u201elipiasc\u0103\u201d toate aspectele lan\u021bului de servicii \u021bint\u0103 \u00eentr-un \u00eentreg unitar \u0219i s\u0103 schimbe automat logica data-plane \u0219i control-plane doar acolo \u0219i atunci unde este necesar.<\/p>\n
Ce \u00eenseamn\u0103 \u00een final?<\/h2>\n \nEste evident c\u0103 at\u00e2t DMVPN (\u00eempreun\u0103 sau f\u0103r\u0103 Performance Routing), c\u00e2t \u0219i Cisco SD-WAN abordaz\u0103, \u00een final, sarcini foarte asem\u0103n\u0103toare<\/b> \u00een raport cu re\u021beaua WAN distribuit\u0103 a organiza\u021biei. Totu\u0219i, diferen\u021bele arhitecturale \u0219i func\u021bionale semnificative ale tehnologiei Cisco SD-WAN ridic\u0103 procesul de rezolvare a acestor sarcini la un nou nivel calitativ<\/b>. Pentru a rezuma, putem sublinia urm\u0103toarele diferen\u021be semnificative \u00eentre tehnologiile SD-WAN \u0219i DMVPN\/PfR:<\/p>\n\nDMVPN\/PfR utilize tried-and-true technologies for building overlay VPN networks and share similarities with the more modern SD-WAN technology in the data plane, although there are some limitations, such as the necessity of static router configurations and a restricted choice of Hub-n-Spoke topologies. On the other hand, DMVPN\/PfR offers certain functionalities that are not yet available within the framework of SD-WAN (specifically, per-application BFD).<\/li>\n In terms of control-plane technology, they differ fundamentally. Given the centralized processing of signaling protocols, SD-WAN allows, among other things, to significantly narrow down failure domains and 'untie' the process of user traffic transmission from signaling interactions\u2014temporary unavailability of controllers does not affect the ability to transmit user traffic. At the same time, temporary unavailability of any branch (including the central one) does not impact the ability of other branches to interact with each other and with controllers.<\/li>\n The architecture for forming and applying traffic management policies in the case of SD-WAN also surpasses that in DMVPN\/PfR\u2014geo-redundancy is implemented far more effectively, there is no dependence on the Hub, and there are more capabilities for fine-tuning policies. The list of implemented traffic management scenarios is also considerably larger.<\/li>\n The orchestration process of the solution is also significantly different. DMVPN assumes the existence of predefined parameters that must be reflected in the configuration in some way, which somewhat limits the solution's flexibility and the possibility of dynamic changes. In contrast, SD-WAN operates under the paradigm that at the initial moment of connection, the router 'knows nothing' about its controllers but knows 'who to ask'\u2014this is sufficient not only for automatically establishing communication with the controllers but also for automatically forming a fully connected data-plane topology, which can then be flexibly configured\/modified using policies.<\/li>\n \u00cen ceea ce prive\u0219te gestionarea centralizat\u0103, automatizarea \u0219i monitorizarea, SD-WAN dep\u0103\u0219e\u0219te a\u0219tept\u0103rile fa\u021b\u0103 de DMVPN\/PfR, care sunt rezultatul evolu\u021biei tehnologiilor clasice \u0219i se bazeaz\u0103 \u00een mare m\u0103sur\u0103 pe linia de comand\u0103 CLI \u0219i aplica\u021biile NMS bazate pe \u0219abloane. <\/li>\n \u00cen SD-WAN, comparativ cu DMVPN, cerin\u021bele de securitate au atins un nou nivel calitativ. Principiile de baz\u0103 sunt - zero \u00eencredere, scalabilitate \u0219i autentificare \u00een doi pa\u0219i.<\/li>\n<\/ul>\n\nAceste concluzii simple pot crea o impresie gre\u0219it\u0103 c\u0103 crearea unei re\u021bele bazate pe DMVPN\/PfR a pierdut ast\u0103zi din relevan\u021b\u0103. Aceasta nu este complet adev\u0103rat. De exemplu, \u00een cazurile \u00een care re\u021beaua utilizeaz\u0103 echipamente \u00eenvechite \u0219i nu exist\u0103 posibilitatea de a le \u00eenlocui, DMVPN poate permite integrarea echipamentelor \u201evechi\u201d \u0219i \u201enoi\u201d \u00eentr-o re\u021bea geo-distribuit\u0103 unificat\u0103, cu numeroase beneficii men\u021bionate mai sus.<\/p>\n
Pe de alt\u0103 parte, trebuie s\u0103 ne amintim c\u0103 toate routerele Cisco actuale pentru mediul enterprise bazate pe IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) suport\u0103 ast\u0103zi orice mod de operare \u2013 at\u00e2t rutare clasic\u0103, c\u00e2t \u0219i DMVPN \u0219i SD-WAN \u2013 alegerea fiind determinat\u0103 de nevoile curente \u0219i \u00een\u021belegerea faptului c\u0103, \u00een orice moment, pe acela\u0219i echipament se poate \u00eencepe tranzi\u021bia c\u0103tre o tehnologie mai avansat\u0103.<\/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