Funktsionaalsed v\u00f5imalused \u2013 mida suudab \u00fcks tehnoloogia, mida teine ei suuda? Kas see on t\u00f5eliselt oluline?<\/li>\n<\/ul>\n<\/p>\n
Milles seisnevad arhitektuurilised erinevused ja kas need on t\u00f5eliselt olulised?<\/h3>\n \nIgas nimetatud tehnoloogias on palju \"liikuvaid osi\", millel on erinevad rollid ja omavahelise suhtlemise p\u00f5him\u00f5tted. Sellest, kui l\u00e4bim\u00f5eldud need p\u00f5him\u00f5tted on, s\u00f5ltub lahenduse skalaarmahtus, t\u00f5rketaluvus ja \u00fcldine efektiivsus. <\/p>\n
Vaatame arhitektuuri erinevaid aspekte p\u00f5hjalikumalt:<\/p>\n
Andmepink<\/b> \u2013 lahenduse osa, mis vastutab kasutajate liikluse edastamise eest allikast saajani. DMVPN-i ja SD-WAN-i puhul rakendatakse seda \u00fcldiselt sarnasel viisil Multipoint GRE tunnelite p\u00f5hjal. Erinevus seisneb selles, kuidas moodustatakse vajalike tunneliparametrite kogum:<\/p>\n\nja DMVPN\/PfR<\/b> \u2013 see on rangelt kahtasemeline s\u00f5lmede hierarhia, millel on \"T\u00e4ht\" v\u00f5i Hub-n-Spoke topoloogia. Hubi staatiline seadistamine ja Spoke'i staatiline sidumine Hubiga on kohustuslik, samuti suhtlemine NHRP protokolli kaudu, et luua data-plane \u00fchenduvus. Tagaj\u00e4rje t\u00f5ttu, on Hubis muudatuste tegemine oluliselt keeruline<\/b>, n\u00e4iteks uute WAN-kanalite muutmise v\u00f5i \u00fchendamise v\u00f5i olemasolevate parameetrite muutmisega.<\/li>\nja SD-WAN<\/b> \u2013 see on t\u00e4ielikult d\u00fcnaamiline mudel, mis tuvastab seatud tunnelite parameetrid, toetudes control-plane'ile (OMP protokoll) ja orchestration-plane'ile (koost\u00f6\u00f6 vBond kontrolleriga, et tuvastada kontrollerid ja NAT traverst). Samuti v\u00f5ivad seatud topoloogiad olla mistahes, sealhulgas hierarhilised. Seoses seatud tunnelite katte topoloogiaga on igas eraldi VPN (VRF) v\u00f5imalik paindlik loogilise topoloogia konfigureerimine.<\/li>\n<\/ul>\n Control-plane<\/b> \u2013 funktsioonid teabe vahetamiseks, filtreerimiseks ja muutmiseks marsruudi ja muu informatsiooni vahel lahenduse komponentide vahel. <\/p>\n\nja DMVPN\/PfR<\/b> \u2013 toimub ainult Hub ja Spoke marsruuterite vahel. Otsene marsruudi teabe vahetamine Spoke vahel ei ole v\u00f5imalik. Tagaj\u00e4rje t\u00f5ttu, ilma toimiva Hubita ei saa control-plane ja data-plane t\u00f6\u00f6tada.<\/b>, mis see seab Hub'i t\u00e4iendavad n\u00f5udmised k\u00f5rge k\u00e4ttesaadavuse osas, mida mitte alati ei ole v\u00f5imalik t\u00e4ita.<\/li>\nja SD-WAN<\/b> \u2013 control-plane'i vahetus ei toimu kunagi otse ruuterite vahel \u2013 suhtlemine toimub OMP protokolli alusel ja toimub kindlasti l\u00e4bi eraldi spetsialiseeritud vSmart kontrolleri t\u00fc\u00fcbi, mis tagab koormuse tasakaalustamise, georedundantsuse ja tsentraliseeritud juhtimise signaalikoormusele. Teine OMP protokolli omadus on selle m\u00e4rkimisv\u00e4\u00e4rne vastupidavus kaotustele ja s\u00f5ltumatuse kontrollereid \u00fchendava kanali kiirusest (m\u00f5istlikud piirid, muidugi). See v\u00f5imaldab SD-WAN kontrollerite majutamist nii avalikes kui ka eraviisilistes pilvedes, mis on juurdep\u00e4\u00e4setavad Interneti kaudu.<\/li>\n<\/ul>\n Policy-plane<\/b> \u2013 lahenduse osa, mis vastutab liiklusjuhtimise poliitikate m\u00e4\u00e4ratlemise, levitamise ja rakendamise eest jaotatud v\u00f5rgus.<\/p>\n\nDMVPN <\/b>\u2013 on tegelikult piiratud kvaliteedi poliitikatega (QoS), mis on kohandatud iga ruuteri jaoks eraldi l\u00e4bi CLI v\u00f5i Prime Infrastructure'i mallide.<\/li>\nDMVPN\/PfR<\/b> \u2013 PfR poliitikad loomisel toimub keskse ruuteri Master Controller (MC) kaudu CLI abil ja seej\u00e4rel levitatakse need automaatselt harukontrolleritesse (MC). Sellisel juhul kasutatakse samu poliitikate edastamise teid nagu data-plane'is. Ei ole v\u00f5imalik eraldada poliitikate, marsruutimise teabe ja kasutajate andmete vahetust. Poliitikate levitamine eeldab, et Hub'i ja Spoke'i vahel on kindlasti IP-\u00fchendus. Samuti v\u00f5ib MC funktsiooni vajaduse korral kombineerida DMVPN ruuteriga. Mallide Prime Infrastructure kasutamine poliitikate tsentraliseeritud loomise jaoks on v\u00f5imalik (kuid mitte vajalik). Oluline omadus \u2013 poliitika luuakse globaalsetelt kogu v\u00f5rgu l\u00f5ikes \u00fchtlaselt \u2013 erakordsed poliitikad kindlate segmentide jaoks ei ole toetatud.<\/b>.<\/li>\nSD-WAN<\/b> \u2013 liiklust juhtimise ja teenuse kvaliteedi poliitikad m\u00e4\u00e4ratakse keskelt l\u00e4bi Cisco vManage graafilise liidese, mis on kergesti ligip\u00e4\u00e4setav ka Interneti kaudu, kui vajalik. Need levitatakse signaalikanalite kaudu otse v\u00f5i kaudselt vSmart kontrollerite kaudu (s\u00f5ltub poliitika liigist). Need ei ole s\u00f5ltuvad data-plane \u00fchenduvusest marsruuterite vahel, kuna nad kasutavad k\u00f5iki olemasolevaid teid liikluse edastamiseks kontrolleri ja marsruuteri vahel.\n Erinevate v\u00f5rgusegmentide jaoks on v\u00f5imalik paindlikult vormida erinevaid poliitikaid \u2013 poliitika rakendusala m\u00e4\u00e4ratakse paljude ainulaadsete identifikaatoritega, mis on lahenduses ette n\u00e4htud \u2013 filiaali number, rakenduse t\u00fc\u00fcp, liikluse suund jne.\n<\/li>\n<\/ul>\n
Orkestreerimiskiht<\/b> \u2013 mehhanismid, mis v\u00f5imaldavad komponentidel d\u00fcnaamiliselt \u00fcksteist avastada, seadistada ja koordineerida edasist koost\u00f6\u00f6d.<\/p>\n\nja DMVPN\/PfR<\/b> marsruuterite vastastikune avastamine p\u00f5hineb Hub seadmete staatilisel konfigureerimisel ning vastaval Spoke seadmete seadistusel. D\u00fcnaamiline avastamine toimub ainult Spoke jaoks, mis teatab oma \u00fchenduse parameetritest Hub seadmele, mis on omakorda eelnevalt Spoke seadme konfiguratsiooni kantud. Ilma IP-\u00fchenduvuseta v\u00e4hemalt \u00fche Hubiga ei ole v\u00f5imalik moodustada ei data-plane'i ega control-plane'i.<\/b><\/li>\nja SD-WAN<\/b> lahenduse komponentide orkestreerimine toimub vBond kontrolleri abil, kellega igal komponendil (marsruuteritel ja vManage\/vSmart kontrolleritel) on vajalik eelnevalt luua IP-\u00fchendus.\n Alguses ei tea komponendid \u00fcksteise \u00fchenduse parameetreid \u2013 selleks on neil vajalik vahendaja-orkestreerija vBond. \u00dcksikasjalik p\u00f5him\u00f5te on j\u00e4rgmine \u2013 iga komponent esimeses faasis avastab (automaatselt v\u00f5i staatiliselt) ainult \u00fchenduse parameetrid vBondiga, seej\u00e4rel teatab vBond marsruuterile vManage ja vSmart kontrolleritest (eelnevalt avastatud), mis muudab k\u00f5ik vajalikud signaal\u00fchendused automaatselt v\u00f5imalikuks. <\/p>\n
J\u00e4rgmiseks sammuks saab uus ruuter teada teistest ruuteritest v\u00f5rgus OMP-vahetuse kaudu vSmart-kontrolleriga. Seega suudab ruuter, olles algselt teadaolevate v\u00f5rguparametrite osas t\u00e4ielikult automaatselt avastada ja \u00fchenduda kontrolleritega ning seej\u00e4rel samuti automaatselt avastada ja luua \u00fchenduse teiste ruuteritega. Samal ajal on k\u00f5igi komponentide \u00fchenduse parameetrid algselt teadmata ja kasutamise k\u00e4igus v\u00f5ivad need muutuda.\n<\/li>\n<\/ul>\n
Halduse tasand<\/b> \u2013 lahuse osa, mis tagab keskse halduse ja j\u00e4lgimise.<\/p>\n\nDMVPN\/PfR<\/b> \u2013 spetsialiseeritud halduse tasandi lahendust ei ole ette n\u00e4htud. P\u00f5hialuste automatiseerimise ja j\u00e4lgimise jaoks on v\u00f5imalik kasutada selliseid tooteid nagu Cisco Prime Infrastructure. Igal ruuteril on v\u00f5imalus haldamiseks k\u00e4surea CLI kaudu. Integreerimist v\u00e4liste s\u00fcsteemidega API kaudu ei ole ette n\u00e4htud.<\/b><\/li>\nSD-WAN<\/b> \u2013 kogu vaikimisi suhtlemine ja j\u00e4lgimine toimub tsentraliseeritult vManage kontrolleri graafilise liidese kaudu. K\u00f5ik lahenduse v\u00f5imalused ilma eranditeta on saadaval seadistamiseks vManage'i kaudu, samuti t\u00e4ielikult dokumenteeritud REST API liidese kaudu.\n K\u00f5ik SD-WAN v\u00f5rgu seadistused vManage'is koonduvad kahe p\u00f5histruktuuri \u2013 seadme mallide (Device Template) loomine ja poliitika loomine, mis m\u00e4\u00e4ratleb v\u00f5rgu ja traadit\u00f6\u00f6tluse t\u00f6\u00f6loogika. Samal ajal valib vManage, edastades administraatori m\u00e4\u00e4ratud poliitika, automaatselt, milliseid muudatusi ja millistel individuaalsetel seadmetel\/kontrolleritel on vaja teha, mis suurendab lahenduse efektiivsust ja skaleeritavust.<\/p>\n
VManage'i liidese kaudu on saadaval mitte ainult Cisco SD-WAN lahenduse seadistamine, vaid ka k\u00f5igi lahenduse komponentide t\u00e4ielik j\u00e4lgimine, ulatudes isegi individuaalsete tunnelite hetkeoleku ja erinevate rakenduste kasutamise statistika j\u00e4lgimiseni DPI-anal\u00fc\u00fcsi p\u00f5hjal.<\/p>\n
Hoolimata suhtlemise tsentraliseerimisest on k\u00f5igil komponentidel (kontrollerid ja ruuterid) ka t\u00e4isfunktsionaalne k\u00e4surea liides CLI, mis on vajalik juurutamise etapis v\u00f5i erandolukordade korral kohaliku diagnostika jaoks. Tavalises re\u017eiimis (kui komponentide vahel on signaalikanal) on ruuteritel k\u00e4surea liides saadaval ainult diagnostikaks ning see ei ole kohalike muudatuste tegemiseks kergesti k\u00e4ttesaadav, mis tagab nii kohaliku turvalisuse kui ka ainus muudatusallika sellises v\u00f5rgus \u2013 vManage.<\/li>\n<\/ul>\n
\nIntegreeritud turvalisus<\/b> \u2013 see ei t\u00e4henda mitte ainult kasutajate andmete kaitset avatud kanalite kaudu edastamisel, vaid ka kogu WAN-v\u00f5rgu \u00fcldist turvalisust valitud tehnoloogia alusel.<\/p>\n\nja DMVPN\/PfR<\/b> on ette n\u00e4htud kasutajate andmete ja signaaliprotokollide kr\u00fcpteerimise v\u00f5imalus. Teatud mudelite ruuterite kasutamisel on saadaval t\u00e4iendavad tulem\u00fc\u00fcrifunktsioonid koos liiklusinspektsiooniga, IPS\/IDS. Filiaalide v\u00f5rkude segmentimise v\u00f5imalus VRF-i abil. On v\u00f5imalik autentimine (\u00fche teguri) kontrollprotokollide jaoks.\n Sellega seoses peetakse kaugruuteri vaikimisi usaldusv\u00e4\u00e4rseks v\u00f5rgu elemendiks \u2013 st ei arvestata f\u00fc\u00fcsilise kompromiteerimise juhtumeid \u00fcksikute seadmete suhtes ja nende volitamata juurde p\u00e4\u00e4semise v\u00f5imalusi, ei ole lahenduse komponentide jaoks kahefaktorilist autentimist, mis geograafiliselt jaotatud v\u00f5rgus v\u00f5ib tuua t\u00f5siseid t\u00e4iendavaid riske.<\/b> <\/li>\nja SD-WAN<\/b> Nii nagu DMVPN-is, on ette n\u00e4htud kasutajate andmete kr\u00fcpteerimise v\u00f5imalus, kuid oluliselt laienenud v\u00f5rgu turvalisuse ja L3\/VRF segmentimise funktsioonidega (NAT, IPS\/IDS, URL-filtreerimine, DNS-filtreerimine, AMP\/TG, SASE, TLS\/SSL proxy jne). Samuti toimub kr\u00fcpteerimisv\u00f5tmete vahetus t\u00f5husamalt vSmart kontrollerite kaudu (mitte otse), eelnevalt m\u00e4\u00e4ratud signaalikanalites, mille on kaitsnud DTLS\/TLS kr\u00fcpteerimine, mis p\u00f5hineb turbesertifikaatidel. See omakorda tagab sellise vahetuse turvalisuse ja v\u00f5imaldab paremat lahenduse skaleeritavust isegi k\u00fcmnete tuhandete seadmete jaoks \u00fches v\u00f5rgus.\n K\u00f5ik signalisatsiooniseosed (controller-controller, controller-router) on samuti kaitstud DTLS\/TLS alusel. Ruuterid on tootmisprotsessis varustatud turv Sertifikaatidega, v\u00f5imalusega asendamiseks\/uuendamiseks. Kahes\u00fcsteemne autentimine saavutatakse kahe tingimuse samal ajal ja kohustusliku t\u00e4itmise kaudu, et ruuter\/controller saaks SD-WAN v\u00f5rgus funktsioneerida:<\/p>\n
\nKehtiv turv Sertifikaat<\/li>\n Administratori selge ja teadlik iga komponendi lisamine lubatud seadmete \"valgesse nimekirja\".<\/li>\n<\/ul>\n\n<\/li>\n<\/ul>\n
SD-WAN ja DMVPN\/PfR funktsionaalsed erinevused<\/h2>\n \nFunktsionaalsete erinevuste arutamisele minnes tuleb m\u00e4rkida, et paljuski on need j\u00e4tk arhitektuurilistele \u2013 ei ole saladus, et lahenduse arhitektuuri loomisel l\u00e4htuvad arendajad nendest v\u00f5imalustest, mida nad soovivad saavutada. Vaatame kaht tehnoloogiat nende k\u00f5ige olulisemate erinevustega.<\/p>\n
AppQ (Rakenduse Kvaliteet) \u2013 \u00e4rirakenduste liikluse kvaliteedi tagamise funktsioonid<\/h3>\n \nK\u00e4sitletud tehnoloogiate v\u00f5tmefunktsioonid on suunatud sellele, et parandada kasutajakogemust \u00e4rikliendiga kriitiliste rakenduste kasutamisel hajutatud v\u00f5rgus. See on eriti oluline olukordades, kus osa infrastruktuurist ei ole IT kontrolli all v\u00f5i ei garanteeri isegi andmete edastamise sujuvust.<\/p>\n
DMVPN ei paku iseseisvalt selliseid mehhanisme. Parim, mida klassikalises DMVPN v\u00f5rgus teha, on klassifitseerida v\u00e4ljuv liiklus rakenduste j\u00e4rgi ja seada sellele edastamisel prioriteet WAN-kanali suunas. DMVPN tunneli valik s\u00f5ltub sel juhul ainult selle k\u00e4ttesaadavusest ja marsruutimisprotokollide t\u00f6\u00f6tulemustest. Samuti ei arvestata l\u00e4bip\u00e4\u00e4su\/ tunneli olukorra seisu ja selle v\u00f5imaliku osalise halvenemise osas, mis on olulised v\u00f5rgurakenduste jaoks \u2013 viivituse, viivituse varieerimise (jitter) ja kaotuste (%). Seet\u00f5ttu pole m\u00f5tet v\u00f5rrelda klassikalist DMVPN-i SD-WAN-iga AppQ probleemide lahendamisel \u2013 DMVPN ei suuda seda \u00fclesannet lahendada. Kui lisada sellesse konteksti tehnoloogia Cisco Performance Routing (PfR), siis olukord muutub ja v\u00f5rrelemine Cisco SD-WAN-iga muutub m\u00f5istlikumaks. <\/p>\n
Enne kui liigume eriomaduste arutamise juurde, r\u00e4\u00e4gime l\u00fchidalt tehnoloogiate sarnasusest. Nii et m\u00f5lemad tehnoloogiad:<\/p>\n
\nomavad mehhanismi, mis v\u00f5imaldab d\u00fcnaamiliselt hinnata iga seadistatud tunnelite seisundit m\u00e4\u00e4ratud m\u00f5\u00f5dikute raames \u2013 minimaalsetena, viivituse, viivituse varieerumise ja pakettide kaotuse (%)<\/li>\n kasutavad konkreetset t\u00f6\u00f6riistade komplekti reeglite (poliitikate) loomiseks, levitamiseks ja rakendamiseks liikluse juhtimise, arvestades peamiste m\u00f5\u00f5dikute tunnelite seisundite m\u00f5\u00f5tmise tulemusi.<\/li>\n klassifitseerivad rakenduste liiklust OSI mudeli L3-L4 (DSCP) tasemel v\u00f5i L7 rakenduste signatuuride alusel, tuginedes marsruuterisse integreeritud DPI mehhanismidele.<\/li>\n lubavad m\u00e4rkimisv\u00e4\u00e4rsetele rakendustele m\u00e4\u00e4rata lubatud m\u00f5\u00f5diku l\u00e4viv\u00e4\u00e4rtused, vaikimisi liikluse edastamise reeglid, reeglid liikluse \u00fcmbermarsruutimise jaoks l\u00e4viv\u00e4\u00e4rtuste \u00fcletamisel.<\/li>\n tunnelite k\u00e4gu\u00f5huks GRE\/IPSec-i kaudu kapseldades kasutavad nad juba t\u00f6\u00f6stuses kehtestatud mehhanismi sisemise DSCP m\u00e4rgistuse edastamiseks v\u00e4lisesse GRE\/IPSEC-i paketi pealkirja, mis v\u00f5imaldab koosk\u00f5lastada QoS poliitikaid organisatsiooni ja sideoperaatori vahel (olemasoleva SLAdel).<\/li>\n<\/ul>\n\n
Kuidas erinevad SD-WAN-i ja DMVPN\/PfR-i mehhanismid tunnelite m\u00f5\u00f5dikute hindamisest?<\/h3>\n \nDMVPN\/PfR <\/b><\/p>\n\nTunnelite seisundi standardsete m\u00f5\u00f5dikute hindamiseks kasutatakse nii aktiivseid kui ka passiivseid tarkvara andureid (Probes). Aktivsed - kasutaja liikluse p\u00f5hjal, passiivsed emuleerivad sellist liiklust (kui seda pole). <\/li>\n Ajastuse ja degradatsiooni avastamise tingimuste t\u00e4pset seadistamist ei ole - algoritm on fikseeritud.<\/li>\n Lisaks on saadaval edasise suuna kasutatava l\u00e4bilaskev\u00f5ime m\u00f5\u00f5tmine. Mis lisab DMVPN\/PfR-ile liikluse juhtimisele t\u00e4iendavat paindlikkust.<\/li>\n Samas toetuvad m\u00f5ned PfR mehhanismid metrikate \u00fcletamisel tagasiside signaalidele spetsiaalsete TCA (Threshold Crossing Alert) s\u00f5numite kujul, mis peaksid tulema liikluse saajalt allika suunas, mis omakorda eeldab, et m\u00f5\u00f5detud kanalite seisund peab olema v\u00e4hemalt piisav, et edastada selliseid TCA-s\u00f5numeid. See enamikul juhtudel ei ole probleem, kuid seda ei saa ilmtingimata garanteerida. <\/li>\n<\/ul>\n\nSD-WAN <\/b><\/p>\n\nTunnel'i standardsete m\u00f5\u00f5dikute pidevaks hindamiseks kasutatakse BFD protokolli echo-re\u017eiimis. Sellega ei ole vajalik eriline tagasiside TCA v\u00f5i sarnaste s\u00f5numite n\u00e4ol \u2013 h\u00e4irete domeenide isoleeritust hoitakse. Samuti ei n\u00f5uta kasutajaliikluse kohalolekut tunnel'i oleku hindamiseks.<\/li>\n On v\u00f5imalik peensusteni seadistada BFD taimerite reguleerimise kiirus ja tundlikkus kohandamisalgoritmile sidekanali degradeerumise osas, alates m\u00f5nedest sekunditest kuni minutiteni.\n
Artikli kirjutamise ajal on iga tunnel'i jaoks ette n\u00e4htud ainult \u00fcks BFD sessioon. See v\u00f5ib potentsiaalselt tekitada v\u00e4iksema granulaarsuse tunnel'i oleku anal\u00fc\u00fcsimisel. Praktikas v\u00f5ib see piiranguks kujuneda vaid olukordades, kus kasutatakse MPLS L2\/L3 VPN'i WAN-\u00fchendust koos kokkulepitud QoS SLA-ga \u2014 kui BFD liikluse DSCP-markering (PDU p\u00e4rast IPSec\/GRE kapseldamist) langeb kokku k\u00f5rge prioriteediga j\u00e4rjekorraga operaatori v\u00f5rgus, v\u00f5ib see m\u00f5jutada madala prioriteediga liikluse degradeerumise avastamise t\u00e4psust ja kiirus. Samuti on v\u00f5imalik BFD vaike-markeroid muuta, et v\u00e4hendada selliste olukordade tekkimise riski. J\u00e4rgnevates Cisco SD-WAN tarkvara versioonides oodatakse BFD peenh\u00e4\u00e4lestamise v\u00f5imaluste ja mitme BFD sessiooni k\u00e4ivitamise v\u00f5imaluste lisamist \u00fche tunnel'i raames eraldi DSCP-v\u00e4\u00e4rtustega (erinevate rakenduste jaoks).<\/li>\n BFD v\u00f5imaldab ka hinnata maksimaalset paketimahtu, mis on v\u00f5imalik edastada ilma fragmenteerimiseta antud tunnel'is. See v\u00f5imaldab SD-WAN'il d\u00fcnaamiliselt seadistada selliseid parameetreid nagu MTU ja TCP MSS Adjust, et maksimaalselt efektiivselt kasutada igas kanalis saadaolevat l\u00e4bilaskev\u00f5imet.<\/li>\n SD-WAN'is on saadaval ka QoS s\u00fcnkroniseerimise v\u00f5imalus sideoperaatoritega mitte ainult L3 DSCP v\u00e4lja alusel, vaid ka L2 CoS v\u00e4\u00e4rtuste alusel, mis v\u00f5ivad automaatselt moodustuda haru v\u00f5rgu spetsialiseeritud seadmete, n\u00e4iteks IP telefonide, toimel.<\/li>\n<\/ul>\n<\/p>\n
Kuidas erinevad AppQ poliitikate m\u00e4\u00e4ratlemise, m\u00e4\u00e4ramise ja rakendamise v\u00f5imalused?<\/h3>\n <\/p>\n
DMVPN\/PfR poliitikad:<\/h4>\n <\/p>\n
\nM\u00e4\u00e4ratletakse keskse filiaali ruuteris(ies) CLI k\u00e4surea v\u00f5i CLI konfiguratsiooni mallide kaudu. CLI mallide koostamine n\u00f5uab ettevalmistust ja poliitikate s\u00fcntaksi tundmist.\n
M\u00e4\u00e4ratakse globaalsetena ilma v\u00f5imaluseta individuaalse kohandamise \/ muutmise jaoks, et vastata \u00fcksikute v\u00f5rgusegmentide n\u00f5udmistele.<\/b><\/li>\nInteraktiivne poliitikate loomine graafilises liideses ei ole ette n\u00e4htud.<\/li>\n Muudatuste j\u00e4lgimine, p\u00e4rimine, mitme poliitika loomine kiireks vahetamiseks ei ole ette n\u00e4htud.<\/li>\n Levitavad automaatselt kaufiliaalide ruutereid. Sel juhul kasutatakse samu sidekanaleid, mis on m\u00f5eldud kasutajate andmete edastamiseks. Kui sidekanalit kesk- ja kaufiliaali vahel ei ole, ei ole poliitikate levitamine \/ muutmine v\u00f5imalik.<\/li>\n Rakendatakse igas ruuteris ja vajadusel muudavad standardsete marsruutimise protokollide tulemusi, omades k\u00f5rgemat prioriteeti. <\/li>\n Juhtudel, kui k\u00f5ik filiaali WAN-kanalid kannatavad t\u00f5siste liiklustaadete kaotuste all, kompenseerimise mehhanisme ei ole ette n\u00e4htud.<\/b>.<\/li>\n<\/ul>\n <\/p>\n
SD-WAN poliitikad:<\/h4>\n <\/p>\n
\nM\u00e4\u00e4ratakse graafilises liideses vManage interaktiivse mallimate abil.<\/li>\n Toetavad mitme poliitika loomist, kopeerimist, p\u00e4rimist, poliitikate vahel reaalajas vahetamist.<\/li>\n Toetavad poliitika individuaalset kohandamist erinevate v\u00f5rgusegmentide (filiaalide) jaoks.<\/li>\n Levitavad, kasutades mis tahes saadaval olevat signaalikanalit kontrolleri ja ruuteri ning \/ v\u00f5i vSmart vahel - ei s\u00f5ltu otseselt data-plane \u00fchendatavusest ruuterite vahel. Sellega on siiski vajalik IP-\u00fchenduvus ruuteri ja kontrollerite vahel.\n
Juhtudel, kui k\u00f5ik filiaali k\u00e4telolevad kanalid kannatavad t\u00f5siste andmete kaotuste all, mis \u00fcletavad kriitiliste rakenduste n\u00e4idatud l\u00e4vev\u00e4\u00e4rtusi, v\u00f5ib kasutada t\u00e4iendavaid mehhanisme, mis t\u00f5stavad edastamise usaldusv\u00e4\u00e4rsust:\n\nFEC (Eeslane Vea Parandus)<\/b> \u2013 kasutab spetsiaalset \u00fcleliigse kodeerimise algoritmi. Olulise liikluse edastamisel kanalite kaudu, kus on m\u00e4rkimisv\u00e4\u00e4rne kaotuste protsent, v\u00f5ib FEC automaatselt aktiveeruda ja m\u00f5nikord lubada kadunud andmete taastamist. Sellega t\u00f5useb pisut kasutatav ribalaius, kuid usaldusv\u00e4\u00e4rsus suureneb m\u00e4rkimisv\u00e4\u00e4rselt.\n
Andmevoogude dubleerimine<\/b> \u2013 lisaks FEC poliitika v\u00f5ib ette n\u00e4ha valitud rakenduste liikluse automaatset dubleerimist juhtudel, kui esinevad t\u00f5sisemad kaotused, mida FEC abil ei \u00f5nnestu kompenseerida. Sellisel juhul edastatakse valitud andmed k\u00f5ikide tunnelite kaudu vastuv\u00f5tja filiaali, j\u00e4rgneb de-dubleerimine (lisakoopiate eemaldamine). Selline mehhanism suurendab oluliselt kanalite kasutamist, kuid samas m\u00e4rgatavalt t\u00f5stab \u00fclekande usaldusv\u00e4\u00e4rsust.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n <\/p>\n
Cisco SD-WAN v\u00f5imalused, millel ei ole otseseid analooge DMVPN\\\/PfR<\/h3>\n \nCisco SD-WAN lahenduse arhitektuur v\u00f5imaldab m\u00f5nel juhul saavutada selliseid v\u00f5imalusi, mille rakendamine DMVPN\\\/PfR raames on kas \u00e4\u00e4rmiselt keeruline, ebaotstarbekas suure t\u00f6\u00f6koormuse t\u00f5ttu v\u00f5i isegi v\u00f5imatu. Vaatame k\u00f5ige huvitavamaid neist:<\/p>\n
Traffic-Engineering (TE)<\/h4>\n \nTE h\u00f5lmab mehhanisme, mis v\u00f5imaldavad suunata liiklust standardsetelt teedelt, mida kujundavad marsruutimise protokollid. TE-d kasutatakse sageli v\u00f5rguteenuste k\u00f5rge k\u00e4ttesaadavuse tagamiseks, v\u00f5imaldades kiiresti ja\\\/v\u00f5i eelnevalt suunata olulised liiklus alternatiivsete (mitte\u00fclenevate) edastusviiside kaudu, et tagada parema teenuse kvaliteedi v\u00f5i kiirus taastumise korral, kui peamisel teel esinevad t\u00f5rked. <\/p>\n
TE rakendamise keerukus seisneb vajaduses eelnevalt arvutada ja reserveerida (kontrollida) alternatiivne rada. Telekommunikatsiooni MPLS v\u00f5rkudes lahendavad operaatorid selle probleemi tehnoloogiate, nagu MPLS Traffic-Engineering koos IGP protokollide ja RSVP protokollide laiendustega. Viimasel ajal on j\u00e4rjest enam populaarsust kogumas tehnoloogia Segment Routing, mis on rohkem optimeeritud tsentraliseeritud seadistamiseks ja orkestreerimiseks. Traditsioonilistes WAN-v\u00f5rkudes ei ole need tehnoloogiad tavaliselt esindatud v\u00f5i on need viidud minimaalseteks lahendusteks, nagu hop-by-hop mehhanismid nagu Policy-Based Routing (PBR), mis suudavad suunata liiklust, kuid teevad seda igas marsruuteris eraldi \u2013 arvestamata v\u00f5rgu \u00fcldist seisundit ega PBR tulemusi eelmistel v\u00f5i j\u00e4rgmistel sammudel. Nende TE variantide rakendamise tulemus on pettumus \u2013 MPLS TE keerukuse t\u00f5ttu seadistamisel ja haldamisel kasutatakse seda tavaliselt ainult v\u00f5rgu k\u00f5ige kriitilisemas osas (tuumik), samas kui PBR-i kasutatakse \u00fcksikutes marsruuterites ilma v\u00f5imaluseta luua mingit \u00fchtset PBR poliitikat kogu v\u00f5rgus. Ilmselgelt puudutab see ka DMVPN-p\u00f5hiseid v\u00f5rke.<\/p>\n
Service-chaining <\/h4>\n \nTeenuste ahelate loomine on klassikalises marsruutimises veelgi t\u00f6\u00f6mahukam \u00fclesanne kui juba kirjeldatud Traffic-Engineering mehhanism. Selles osas on vajalik mitte ainult luua spetsiaalne marsruut teatud v\u00f5rgu rakendusele, vaid ka tagada liiklust juhtimise v\u00f5imalus SD-WANi v\u00f5rgu teatud (v\u00f5i k\u00f5ikides) s\u00f5lmedes spetsiaalse rakenduse v\u00f5i teenuse (MCPE, tasakaalustamine, vahem\u00e4llu salvestamine, liikluse kontrollimine jne) t\u00f6\u00f6tlemiseks. Samuti on oluline kontrollida nende v\u00e4list\u00f6\u00f6tlusteenuste olekut, et v\u00e4ltida black-holing olukordi, ning on vajalikud mehhanismid, mis v\u00f5imaldavad neid \u00fchetaolisi v\u00e4list\u00f6\u00f6tlusteenuseid paigutada erinevatesse geograafilistesse asukohtadesse, et v\u00f5rk saaks automaatselt valida optimaalse teenuse s\u00f5lme parajasti liikluse t\u00f6\u00f6tlemiseks. Cisco SD-WANi puhul on seda suhteliselt lihtne saavutada, luues vastava tsentraliseeritud poliitika, mis \u201eliidab\u201d k\u00f5ik sihtteenuste ahela aspektid \u00fchtseks tervikuks ja muudab automaatselt data-plane ja control-plane loogikat ainult seal ja siis, kus see on vajalik.<\/p>\n
Kokkuv\u00f5ttes?<\/h2>\n \nOn ilmne, et nii DMVPN (koos v\u00f5i ilma Performance Routinguta) kui Cisco SD-WAN lahendavad l\u00f5ppkokkuv\u00f5ttes v\u00e4ga sarnaseid \u00fclesandeid<\/b> organisatsiooni jaotatud WAN v\u00f5rgu osas. Siiski viivad Cisco SD-WAN tehnoloogia olulised arhitektuursed ja funktsionaalsed erinevused need \u00fclesannete lahendamise protsessid teisele kvaliteeditasemele<\/b>. Kokkuv\u00f5tteks v\u00f5ib m\u00e4rkida j\u00e4rgmised olulised erinevused SD-WAN ja DMVPN\/PfR tehnoloogiate vahel:<\/p>\n\nDMVPN\/PfR kasutab \u00fcldiselt ajaproovitud tehnoloogiaid, mis on suunatud \u00fclekantud VPN-v\u00f5rkude loomisele ja osaliselt sarnaneb andmepinna osas kaasaegse SD-WAN tehnoloogiaga. Samas on teatud piirangud, sealhulgas kohustuslik staatiline marsruuterite konfiguratsioon ja topoloogiate valik on piiratud Hub-n-Spoke'iga. Teisest k\u00fcljest on DMVPN\/PfR-l m\u00f5ned funktsionaalsed v\u00f5imalused, mis pole veel SD-WAN raames saadaval (see puudutab per-application BFD-d).<\/li>\n Control-plane tehnoloogiad erinevad p\u00f5him\u00f5tteliselt. Keskse signaaliprotokollide t\u00f6\u00f6tlemise t\u00f5ttu v\u00f5imaldab SD-WAN oluliselt kitsendada rikke domeene ja 'lahutada' kasutajate liikluse edastamisprotsessi signaalide suhtlemisest \u2013 ajutine juurdep\u00e4\u00e4smatus kontrolleritele ei m\u00f5juta kasutajate liikluse edastamise v\u00f5imalust. Samas ei m\u00f5juta ajutine juurdep\u00e4\u00e4smatus m\u00f5nele harule (sealhulgas keskusele) teiste harude suhtlemisv\u00f5imet omavahel ja kontrolleritega.<\/li>\n SD-WAN liikluse juhtimise poliitikate koostamise ja rakendamise arhitektuur \u00fcletab DMVPN\/PfR oma tingimustes \u2013 georiseerimise rakendamine on oluliselt paremini teostatud, pole seotud Hubiga, rohkem v\u00f5imalusi poliitikate peenh\u00e4\u00e4lestamisel ning realiseerimise stsenaariumide loetelu on samuti oluliselt suurem.<\/li>\n Lahenduse orkestreerimise protsess erineb samuti oluliselt. DMVPN eeldab, et olemas on ette teada omadused, mis peavad mingil moel olema kajastatud konfiguratsioonis, mis piirab lahenduse paindlikkust ja v\u00f5imalust d\u00fcnaamiliste muudatuste tegemiseks. SD-WAN l\u00e4htestab aga paradigma, et \u00fclesehituse varajases etapis 'ei tea' marsruuter oma kontrolleritest midagi, kuid teab 'kellelt k\u00fcsida' \u2013 seda on piisavalt, et mitte ainult automaatselt luua side kontrolleritega, vaid ka automaatselt luua t\u00e4ielikult seotud andmepinna topoloogiat, mida saab seej\u00e4rel paindlikult seadistada\/muuta poliitikate abil.<\/li>\n Keskse haldamise, automatiseerimise ja j\u00e4lgimise osas \u00fcletab SD-WAN ootusp\u00e4raselt DMVPN\/PfR v\u00f5imalusi, mis on klassikaliste tehnoloogiate arengu tulemus ja tuginevad suuresti CLI k\u00e4sureale ning mallip\u00f5histe NMS s\u00fcsteemide kasutamisele. <\/li>\n SD-WANis on v\u00f5rreldes DMVPNiga turvan\u00f5uded j\u00f5udnud teisele kvaliteeditasemele. Peamised p\u00f5him\u00f5tted on null usaldus, skaleeritavus ja kahefaktoriline autentimine.<\/li>\n<\/ul>\n\nNendest lihtsatest j\u00e4reldustest v\u00f5ib j\u00e4\u00e4da vale mulje, et DMVPN\/PfRi p\u00f5hjaliku v\u00f5rgu loomine on t\u00e4na igasuguse relevantsuse kaotanud. See ei ole kindlasti t\u00e4iesti t\u00f5si. N\u00e4iteks olukordades, kus v\u00f5rgus kasutatakse palju vananenud seadmeid ja nende asendamine ei ole v\u00f5imalik, v\u00f5ib DMVPN v\u00f5imaldada \u201evanade\u201c ja \u201euuside\u201c seadmete \u00fchendamist \u00fchte geograafiliselt jaotatud v\u00f5rku, milles on rohkesti eelpoolmainitud eeliseid.<\/p>\n
Teisalt tuleb meeles pidada, et k\u00f5ik aktuaalsed ettev\u00f5tte ruuterid Cisco IOS XE baasil (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) toetavad t\u00e4nap\u00e4eval igasugust t\u00f6\u00f6re\u017eiimi \u2013 nii klassikalist marsruutimist kui DMVPNi ja SD-WANi. Valik s\u00f5ltub praegustest vajadustest ja arusaamast, et igal ajal saab samal seadmel liikuda edasi keerukamate tehnoloogiate suunas.<\/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