Funktsionaalsed v\u00f5imalused \u2013 mida suudab \u00fcks tehnoloogia, mida teine ei suuda? Kas see on t\u00f5eliselt oluline?<\/li>\n<\/ul>\n<\/p>\n
Millistes arhitektuurilistes erinevustes see seisneb ja kas need on t\u00f5eliselt olulised?<\/h3>\n \nIgas nimetatud tehnoloogias on palju \u201eliikuvad osi\u201d, millel on erinevad rollid ja koost\u00f6\u00f6 p\u00f5him\u00f5tted. Kuidas need p\u00f5him\u00f5tted on l\u00e4bi m\u00f5eldud, m\u00f5jutab lahenduse skaleeritavust, talitlush\u00e4irete taluvust ja \u00fcldist efektiivsust. <\/p>\n
Vaatame arhitektuuri erinevaid aspekte l\u00e4hemalt:<\/p>\n
Andmeplaan<\/b> \u2013 lahenduse osa, mis vastutab kasutaja liikluse edastamise eest allika ja sihtkoha vahel. DMVPN ja SD-WAN rakendatakse p\u00f5him\u00f5tteliselt samamoodi mitme punktiga GRE tunnelite baasil marsruutijatel. Erinevus seisneb selles, kui palju aruandeparameetreid nende tunnelite jaoks luuakse:<\/p>\n\n\u00fches DMVPN\/PfR<\/b> \u2014 see on rang, kus on kaks taset node'ide hierarhiast, mille topoloogia on t\u00fc\u00fcpi \u201eT\u00e4ht\u201d v\u00f5i Hub-n-Spoke. Hub'i staatiline seadistus ja Spoke'i staatiline sidumine Hub'iga on kohustuslikud, samuti interaktsioon NHRP protokolli kaudu, et luua data-plane'i seos. Selle tulemusena on Hub'i muudatused oluliselt keerulisemad<\/b>, mis on seotud n\u00e4iteks uute WAN-kanalite muutmise v\u00f5i \u00fchendamisega v\u00f5i olemasolevate parameetrite muutmisega.<\/li>\n\u00fches SD-WAN<\/b> on t\u00e4ielikult d\u00fcnaamiline mudel installeeritud tunnelite parameetrite avastamiseks, tuginedes control-plane'ile (OMP protokoll) ja orchestration-plane'ile (interaktsioon vBond kontrolleriga kontrollerite avastamise ja NAT l\u00e4bimise \u00fclesannete jaoks). Samal ajal v\u00f5ivad seostatavad topoloogiad olla erinevad, sealhulgas hierarhiilised. Seoses seatud tunnelite seostatava topoloogiaga on igas eraldi VPN (VRF) paindlik seadistus v\u00f5imalike loogiliste topoloogiate jaoks.<\/li>\n<\/ul>\n Control-plane<\/b> on vahetuse, filtreerimise ja marsruudi ning muude andmete modifitseerimise funktsioonide komplekt, mis toimub lahenduse komponentide vahel. <\/p>\n\n\u00fches DMVPN\/PfR<\/b> toimub ainult Hub ja Spoke ruuteri vahel. Otsene marsruudiinfo vahetamine Spoke'ide vahel on v\u00f5imatu. Selle tulemusena, ilma toimivat Hub'i, control-plane ja data-plane ei saa toimida<\/b>, mis seab Hub'ile t\u00e4iendavad k\u00f5rge k\u00e4ttesaadavuse n\u00f5udmised, mida mitte alati on v\u00f5imalik t\u00e4ita.<\/li>\n\u00fches SD-WAN<\/b> \u2013 control-plane ei toimu kunagi otse ruutite vahel \u2013 suhtlemine toimub OMP protokolli alusel ja peab toimuma l\u00e4bi eraldi spetsialiseeritud vSmart kontrolleri, mis tagab koormuse tasakaalustamise, georeserveerimise ja tsentraliseeritud signaalikoormuse haldamise. OMP protokoli teine omadus on selle m\u00e4rkimisv\u00e4\u00e4rne vastupidavus kaotustele ja s\u00f5ltumatus kontrolleritega sidekanali kiirusest (m\u00f5istlikes piirides, muidugi). See v\u00f5imaldab edukalt paigutada SD-WAN kontrollerid avalikesse v\u00f5i erakliimadesse 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 kvaliteedikindluse (QoS) poliitikate poolt, mis seadistatakse individuaalselt igas ruuteris l\u00e4bi CLI v\u00f5i Prime Infrastructure'i mallide.<\/li>\nDMVPN\/PfR<\/b> \u2013 PfR poliitikaid hallatakse kesksete Master Controller (MC) ruuterite kaudu CLI kaudu ning levitatakse automaatselt harukontoritesse. Selleks kasutatakse samu poliitikate edastuskaid nagu data-plane'i jaoks. Pole v\u00f5imalik eraldada poliitikate, marsruudiinfot ja kasutajate andmeid. Poliitikate levitamine eeldab IP-\u00fchenduse olemasolu Hub'i ja Spoke'i vahel. Samuti saab MC funktsiooni vajadusel kombineerida DMVPN ruuteriga. Prime Infrastructure mallide kasutamine poliitikate keskseks loomiseks on v\u00f5imalik (aga mitte kohustuslik). T\u00e4htis omadus on see, et poliitika luuakse globaalselt \u00fchtlaselt kogu v\u00f5rgus \u2013 erakliendipoliitikaid individuaalsete segmentide jaoks ei toetata.<\/b>.<\/li>\nSD-WAN<\/b> \u2013 liiklus- ja teenuse kvaliteedi haldustavad poliitikad m\u00e4\u00e4ratakse tsentraalselt Cisco vManage graafilise kasutajaliidese kaudu, mis on saadaval ka interneti kaudu (vajadusel). Need edastatakse signaalikanalite kaudu otse v\u00f5i kaudselt vSmart kontrollerite kaudu (s\u00f5ltuvalt poliitika t\u00fc\u00fcbist). Need ei s\u00f5ltu andmeplaadi \u00fchenduvusest marsruuterite vahel, kuna nad kasutavad k\u00f5iki saadaolevaid teid liikluse edastamiseks kontrolleri ja marsruuteri vahel.\n Erinevates v\u00f5rgusegmentides on v\u00f5imalik paindlikult moodustada erinevaid poliitikaid \u2013 poliitika rakendamise sf\u00e4\u00e4r m\u00e4\u00e4ratakse paljude unikaalsete identifikaatoritega, mis on ette n\u00e4htud lahenduses \u2013 filiaali number, rakenduse t\u00fc\u00fcp, liikluse liikumise suund jne.\n<\/li>\n<\/ul>\n
Orkestreerimisplatvorm<\/b> \u2013 mehhanismid, mis v\u00f5imaldavad komponentidel \u00fcksteist d\u00fcnaamiliselt avastada, seadistada ja koordineerida j\u00e4rgnevat suhtlemist.<\/p>\n\n\u00fches DMVPN\/PfR<\/b> Routeerite omavaheline tuvastamine p\u00f5hineb Hub-seadmete staatilisel konfiguratsioonil ja vastaval Spoke-seadmete seadistusel. D\u00fcnaamiline tuvastamine toimub ainult Spoke'i puhul, mis edastab oma \u00fchenduse parameetrid Hub-seadmestikule, mis on omakorda eelnevalt Spoke'i konfiguratsiooni lisatud. Ilma IP-\u00fchenduse olemasoluta Spoke'i ja v\u00e4hemalt \u00fche Hub'i vahel ei ole v\u00f5imalik moodustada ei andme- ega juhtimisplaani.<\/b><\/li>\n\u00fches SD-WAN<\/b> Lahenduse komponentide orkestreerimine toimub vBond kontrolleri abil, millega on igal komponendil (maruuterid ja vManage\/vSmart kontrollerid) eelnevalt IP-\u00fchendus loodud.\n Alguses ei tea komponendid \u00fcksteise \u00fchendusparameetritest - selleks on vajalik vahendajana toimiv orkestreerija vBond. \u00dcldine p\u00f5him\u00f5te on j\u00e4rgmine: iga komponent algfaasis kuulab (automaatsete v\u00f5i staatiliste meetoditega) ainult vBond'i \u00fchendusparameetreid, seej\u00e4rel edastab vBond maruuterile vManage ja vSmart kontrollerite (enne avastatud) teavet, mis v\u00f5imaldab automaatset signaalide seadistamist. <\/p>\n
J\u00e4rgmise sammuna saad uue ruuteri teavet \u00fclej\u00e4\u00e4nud v\u00f5rgu ruuterite kohta vSmarti kontrolleriga OMP-vahetuse kaudu. Nii saab ruuter, olles algselt teadmata v\u00f5rgu parameetreid, t\u00e4ieliku automaatse avastamise ja \u00fchendamise kontrolleritega ning seej\u00e4rel ka automaatse avastamise ja \u00fchenduse loomise \u00fclej\u00e4\u00e4nud ruuteritega. Samuti on k\u00f5igi komponentide \u00fchendamise parameetrid alguses teadmata ja v\u00f5ivad kasutamise k\u00e4igus muutuda.\n<\/li>\n<\/ul>\n
Halduse tasand<\/b> \u2013 lahuse osa, mis tagab tsentraliseeritud juhtimise ja j\u00e4lgimise.<\/p>\n\nDMVPN\/PfR<\/b> \u2013 spetsiaalset halduse tasandi lahendust ei ole ette n\u00e4htud. P\u00f5hitehnoloogiate automatiseerimiseks ja j\u00e4lgimiseks saab kasutada selliseid tooteid nagu Cisco Prime Infrastructure. Igal ruuteril on CLI k\u00e4surea kaudu haldamise v\u00f5imalus. Integreerimist v\u00e4liste s\u00fcsteemidega l\u00e4bi API ei ole ette n\u00e4htud.<\/b><\/li>\nSD-WAN<\/b> \u2013 kogu tavap\u00e4rane suhtlemine ja j\u00e4lgimine toimub keskustatud kaudu vManage kontrolleri graafilise liidese kaudu. K\u00f5ik lahenduse v\u00f5imalused, v\u00e4lja arvatud erandid, on seadistamiseks saadaval vManage'is, samuti t\u00e4ielikult dokumenteeritud REST API teegi kaudu.\n K\u00f5ik SD-WAN v\u00f5rgu seadistused vManage'is p\u00f5hinevad kahel peamiselt konstruktsioonil \u2013 seadmete mallide (Device Template) loomine ja poliitikate loomine, mis m\u00e4\u00e4ratleb v\u00f5rgu t\u00f6\u00f6loogika ja liiklusprotsessimise. Samuti valib vManage, edastades administraatori koostatud poliitika, automaatselt, milliseid muudatusi ja millistel individuaalsetel seadmetel\/kontrolleritel tuleb teha, mis suurendab m\u00e4rkimisv\u00e4\u00e4rselt lahenduse t\u00f5husust ja skaleeritavust.<\/p>\n
vManage'i liidese kaudu on saadaval mitte ainult Cisco SD-WAN lahenduse seadistamine, vaid ka k\u00f5ikide lahenduse komponentide p\u00f5hjalik j\u00e4lgimine, sealhulgas eraldi tunnelite hetkeseisud ja erinevate rakenduste kasutamise statistika DPI anal\u00fc\u00fcsi p\u00f5hjal.<\/p>\n
Keskendudes suhtluse tsentraliseerimisele, on k\u00f5igil komponentidel (kontrollerid ja ruuterid) ka t\u00e4ielikult funktsionaalne CLI (kommando rea liides), mis on vajalik rakendusetapis v\u00f5i h\u00e4daolukordades kohaliku diagnostika jaoks. Tavalistes oludes (kui komponentide vahel on signaalikanal) on ruuterites k\u00e4surea liides saadaval vaid diagnostikaks ja ei ole kergesti muudetav, mis tagab nii kohaliku turvalisuse kui ka ainulaadse muudatuste allika sellises v\u00f5rgus \u2013 vManage.<\/li>\n<\/ul>\n
\nIntegreeritud turvalisus<\/b> \u2013 see ei t\u00e4henda ainult kasutajaandmete kaitset avatud kanalite kaudu, vaid ka kogu WAN-v\u00f5rgu \u00fcldist turvalisust valitud tehnoloogia alusel.<\/p>\n\n\u00fches DMVPN\/PfR<\/b> on ette n\u00e4htud kasutaja andmete ja signaalprotokollide kr\u00fcptimise v\u00f5imalus. Teatud marsruuterimudelite kasutamisel on saadaval ka tulem\u00fc\u00fcrifunktsioonid koos liiklusinspektsiooniga, IPS\/IDS. On v\u00f5imalik haruv\u00f5rkude segmenteerimine VRF-i kasutamisega. Kontrollprotokollide (\u00fche teguri) autentimine on v\u00f5imalik.\n Sel juhul loetakse eemalolev marsruuter vaikimisi v\u00f5rgu usaldusv\u00e4\u00e4rseks elemendiks \u2013 st ei eelda ega arvesta individuaalsete seadmete f\u00fc\u00fcsilise kompromiteerimise juhtumeid ega v\u00f5imalust nendele volitamata juurdep\u00e4\u00e4suks, ei ole kahte tegurit autentimise komponente lahenduses, mis geograafiliselt jaotatud v\u00f5rgus v\u00f5ib kanda t\u00f5siseid t\u00e4iendavaid riske.<\/b> <\/li>\n\u00fches SD-WAN<\/b> DMVPN-i sarnasel on kasutusv\u00f5imalus kasutajate andmete kr\u00fcptimiseks, kuid oluliselt laiendatud v\u00f5rgu turvafunktsioonide ja L3\/VRF segmentatsiooniga (MSE, IPS\/IDS, URL-filterimine, DNS-filterimine, AMP\/TG, SASE, TLS\/SSL proksid jne). Kr\u00fcpteerimise v\u00f5tmete vahetus toimub t\u00f5husamalt vSmart kontrollere kaudu (mitte otseselt), eelnevalt m\u00e4\u00e4ratud signalisikanalite kaudu, mis on kaitstud DTLS\/TLS kr\u00fcptimisega, mis p\u00f5hineb turv Sertifikaatidel. See omakorda tagab sellise vahetuse turvalisuse ja tagab lahenduse parema skaleeritavuse isegi kuni k\u00fcmnete tuhandete seadmeteni \u00fches v\u00f5rgus.\n K\u00f5ik signalisikanalid (kontroller-kontroller, kontroller-ruuter) on samuti kaitstud p\u00f5hinedes DTLS\/TLS-le. Ruuteritel on tootmisel kehtivad turv \u0441\u0435\u0440\u0442\u0438\u0444\u0438\u043aatid, millel on v\u00f5imalus asendada\/uuendada. Kahefaktoriline autentimine saavutatakse kahes tingimuses, mis peavad olema t\u00e4idetud, et ruuter\/kontroller saaks SD-WAN-v\u00f5rgus toimida:<\/p>\n
\nKehtiv turv sertifikaat<\/li>\n Iga seadme komponent, mille administraator lisab, on selgelt ja teadlikult lubatud seadmete mustas nimekirjas.<\/li>\n<\/ul>\n\n<\/li>\n<\/ul>\n
SD-WAN ja DMVPN\/PfR funktsionaalsed erinevused<\/h2>\n \nR\u00e4\u00e4kides funktsionaalsetest erinevustest, tasub m\u00e4rkida, et paljuski p\u00f5hinevad need arhitektuurilistel \u2013 ei ole saladus, et lahenduse arhitektuuri kujundamisel l\u00e4htuvad arendajad eeldatavatest v\u00f5imalustest, mida nad soovivad saada. Vaatame kahe tehnoloogia olulisemaid erinevusi.<\/p>\n
AppQ (Rakenduste Kvaliteet) \u2013 \u00e4rirakenduste liikluse kvaliteedi tagamise funktsioonid<\/h3>\n \nArutatavate tehnoloogiate peamine fookus on kasutajakogemuse v\u00f5imalikult suure parendamise suunal \u00e4ritootete rakendustes hajutatud v\u00f5rgus. See on eriti oluline olukordades, kus osa infrastruktuurist ei ole IT juhtimise all v\u00f5i ei taga isegi andmete edastamise edukust.<\/p>\n
DMVPN ei paku selliseid mehhanisme. Parim, mida klassikalises DMVPN-v\u00f5rgus teha saab, on v\u00e4ljuva liikluse klassifitseerimine rakenduste j\u00e4rgi ja selle prioriseerimine WAN-kanali suunas edastamisel. DMVPN tunnel valitakse sellisel juhul ainult selle k\u00e4ttesaadavuse ja marsruutimisprotokollide t\u00f6\u00f6 tulemuste p\u00f5hjal. Samuti ei arvestata teed\/tunnelit ja selle v\u00f5imalikku osalist degradeerumist olulisemate m\u00f5\u00f5dikute \u2013 viivituse, viivitusvariatsiooni (jitter) ja kaotuste (%) \u2013 osas, mis on v\u00f5rgurakenduste jaoks olulised. Seet\u00f5ttu pole m\u00f5tet otse v\u00f5rrelda klassikalist DMVPN SD-WAN-iga AppQ probleemide lahendamisel \u2013 DMVPN ei saa seda \u00fclesannet lahendada. Kui konteksti lisandub tehnoloogia Cisco Performance Routing (PfR), muutub olukord ja v\u00f5rrelda Cisco SD-WAN-iga on m\u00f5istlikum. <\/p>\n
Enne kui liigume erinevuste arutamise juurde, r\u00e4\u00e4gime l\u00fchidalt, milles tehnoloogiad sarnanevad. Nii et m\u00f5lemad tehnoloogiad:<\/p>\n
\nomavad mehhanismi, mis v\u00f5imaldab d\u00fcnaamiliselt hinnata iga paigaldatud tunnelit teatud meetrikate l\u00f5ikes \u2013 v\u00e4hemalt viivitust, viivituse variatsiooni ja paketikaotust (%)<\/li>\n kasutavad kindlat t\u00f6\u00f6riistade komplekti reeglite (poliitikate) loomiseks, levitamiseks ja rakendamiseks, arvestades oluliste m\u00f5\u00f5tmismeetrite tulemusi tunnelite seisukorrast.<\/li>\n klassifitseerivad rakenduste liiklust OSI mudeli L3-L4 (DSCP) tasemel v\u00f5i L7 rakenduste allkirjade p\u00f5hjal, kasutades ruuteri sisseehitatud DPI mehhanisme.<\/li>\n v\u00f5imaldavad oluliste rakenduste jaoks m\u00e4\u00e4rata lubatavad meetrikate piirm\u00e4\u00e4rad, vaike liiklus\u00fclekande reeglid ja liikluse \u00fcmbersuunamise reeglid piirm\u00e4\u00e4rade \u00fcletamisel.<\/li>\n GRE\/IPSec liikluse kapseldamisel kasutatakse juba t\u00f6\u00f6stuses kehtestatud mehhanismi sisemise DSCP m\u00e4rgistuse edastamiseks v\u00e4ljapoole GRE\/IPSec paketi pealkirja, mis v\u00f5imaldab s\u00fcnkroniseerida QoS poliitikaid organisatsiooni ja sideteenuse osutaja vahel (olemasoleva SLA korral).<\/li>\n<\/ul>\n\n
Kuidas erinevad SD-WAN ja DMVPN\/PfR vahemeetodi hindamise mehhanismid?<\/h3>\n \nDMVPN\/PfR <\/b><\/p>\n\nTunnel'i seisundi standardsete m\u00f5\u00f5dikute hindamiseks kasutatakse nii aktiivseid kui ka passiivseid tarkvarasensoreid (Probes). Aktiivsed p\u00f5hinevad kasutaja liikluses, passiivsed emuleerivad sellist liiklust (kui see puudub). <\/li>\n Ajastite ja degradeerumisavastuse tingimuste peenh\u00e4\u00e4lestamine puudub \u2013 algoritm on fikseeritud.<\/li>\n Lisaks on saadaval l\u00e4bilaskev\u00f5ime m\u00f5\u00f5tmine v\u00e4ljuvas suunas. See lisab DMVPNi\/PfR-i liikluse haldamisse t\u00e4iendavat paindlikkust.<\/li>\n Samas tuginevad m\u00f5ned PfR mehhanismid, kui m\u00f5\u00f5dikud \u00fcletatakse, tagasisidep\u00f5hisele teabele, kasutades spetsiaalseid TCA (Threshold Crossing Alert) s\u00f5numeid, mis peavad olema saadetud liikluse vastuv\u00f5tjalt allika suunas, mis omakorda eeldab, et m\u00f5\u00f5detud kanalite seisund peab olema v\u00e4hemalt piisav, et edastada selliseid TCA-s\u00f5numeid. See ei ole enamasti probleem, kuid seda ei saa ilmselgelt garanteerida. <\/li>\n<\/ul>\n\nSD-WAN <\/b><\/p>\n\nTunnel'i olekute standardsete m\u00f5\u00f5dikute hindamiseks kasutatakse BFD protokolli echo-re\u017eiimis. Sel juhul ei ole vaja erilist tagasisidet nagu TCA v\u00f5i sarnased teated \u2013 rike domeenide isoleeritus on s\u00e4ilinud. Tunnel'i oleku hindamiseks ei ole samuti vajalik kasutajate liiklus.<\/li>\n On v\u00f5imalik BFD ajastajate t\u00e4pset seadistamist, et reguleerida reageerimise kiirus ja algoritmi tundlikkust sidekanali halvenemisele paarist sekundist kuni minutiteni.\n
Artikli kirjutamise hetkel on igas tunnelis ette n\u00e4htud ainult \u00fcks BFD seanss. Potentsiaalselt loob see anal\u00fc\u00fcsi seisundi tunneli kohta madalama granulaarsuse. Tegelikult v\u00f5ib see muutuda piiranguks ainult MPLS L2\/L3 VPN-i WAN-\u00fchenduse kasutamisel, millel on koosk\u00f5lastatud QoS SLA \u2014 kui BFD liiklus (p\u00e4rast IPSec\/GRE kapseldamist) DSCP-m\u00e4rgistamine vastab operaatori k\u00f5rge prioriteedi j\u00e4rjekorrale, v\u00f5ib see m\u00f5jutada madala prioriteediga liikluse delegeerimise t\u00e4psust ja kiirus. Samuti on v\u00f5imalus muuta vaikimisi BFD m\u00e4rgistust, et v\u00e4hendada sarnaste olukordade tekkimise ohtu. J\u00e4rgmistes Cisco SD-WAN tarkvaraversioonides oodatakse BFD t\u00e4iendavat kohandamist, samuti mitme BFD seansi k\u00e4ivitamise v\u00f5imalust \u00fches tunnelis, kus on individuaalsed DSCP-v\u00e4\u00e4rtused (erinevate rakenduste jaoks).<\/li>\n BFD v\u00f5imaldab lisaks hinnata maksimaalse paketi suurust, mida on v\u00f5imalik edastada erinevate tunnelite kaudu ilma fragmenteerimiseta. See v\u00f5imaldab SD-WAN-il d\u00fcnaamiliselt kohandada selliseid parameetreid nagu MTU ja TCP MSS Adjust, et maksimaalselt efektiivselt kasutada iga kanali saadaval olevat ribalaiust.<\/li>\n SD-WAN-is on saadaval ka QoS-i s\u00fcnkroniseerimise valik sideoperaatoritega mitte ainult L3 DSCP v\u00e4lja p\u00f5hjal, vaid ka L2 CoS v\u00e4\u00e4rtuste p\u00f5hjal, mis v\u00f5ivad automaatselt moodustuda filiaalis spetsialiseeritud seadmete \u2014 n\u00e4iteks IP-telefonide \u2014 abil.<\/li>\n<\/ul>\n<\/p>\n
Kuidas erinevad AppQ poliitikate m\u00e4\u00e4ratlemise ja rakendamise v\u00f5imalused?<\/h3>\n <\/p>\n
DMVPN\/PfR poliitikad:<\/h4>\n <\/p>\n
\nM\u00e4\u00e4ratakse keskfiliaali (\u0426\u0424) marsruuteris(te) CLI k\u00e4surea v\u00f5i CLI konfiguratsioonimallide kaudu. CLI mallide koostamine n\u00f5uab ettevalmistust ja poliitikate s\u00fcntaksiga tutvumist.\n
M\u00e4\u00e4ratakse globaalselt ilma v\u00f5imaluseta individuaalselt kohandada\/muuta vastavalt teatud v\u00f5rgu segmentide n\u00f5udmistele.<\/b><\/li>\nInteraktiivne poliitikate loomine graafilises liideses ei ole ette n\u00e4htud.<\/li>\n Muudatuste j\u00e4lgimine, p\u00e4randamine, mitme poliitika versiooni loomine kiireks vahetuseks ei ole toetatud.<\/li>\n Levitatakse automaatselt eemalolevate filiaalide ruuteritele. Kasutatakse samu sidekanaleid, mis on m\u00f5eldud kasutajate andmete edastamiseks. Kui keskmise ja eemaloleva filiaali vahel pole sidekanalit, ei ole poliitikate levitamine\/muutmine v\u00f5imalik.<\/li>\n Rakendatakse igas ruuteris ja vajadusel kohandavad nad standardsete marsruutimisprotokollide tulemusi, omades k\u00f5rgemat prioriteeti. <\/li>\n Juhtudel, kui k\u00f5ik filiaali WAN-kanalid kogevad m\u00e4rkimisv\u00e4\u00e4rseid andmekadu, kompensatsioonimehhanisme ei ole ette n\u00e4htud.<\/b>.<\/li>\n<\/ul>\n <\/p>\n
SD-WAN poliitikad:<\/h4>\n <\/p>\n
\nM\u00e4\u00e4ratakse vManage'i graafilises liideses interaktiivse mallimeisteri kaudu.<\/li>\n Toetavad mitme poliitika loomist, kopeerimist, p\u00e4randamist ja reaalajas poliitikate vahel vahetamist.<\/li>\n Toetavad poliitikate kohandamist erinevate v\u00f5rgu segmentide (filiaalide) jaoks.<\/li>\n Levitavad, kasutades \u00fchtegi olemasolevat signaalikanalit juhendi ja ruuteri ja\/v\u00f5i vSmart vahel \u2013 ei s\u00f5ltu otseselt data-plane \u00fchenduvusest ruuterite vahel. Samas n\u00f5utakse loomulikult IP-\u00fchenduvust ruuteri ja juhendite vahel.\n
Kui k\u00f5ik saadaval olevad harukaubad kogevad m\u00e4rkimisv\u00e4\u00e4rseid andmekadusid, mis \u00fcletavad lubatud l\u00e4vendid kriitiliste rakenduste jaoks, v\u00f5ib kasutada t\u00e4iendavaid mehhanisme, mis suurendavad edastamise usaldusv\u00e4\u00e4rsust:\n\nFEC (Eesliitevea Parandamine)<\/b> kasutab erilist \u00fclem\u00e4\u00e4rase koodimise algoritmi. Kui kriitilise liikluse edastamisel kogevad kanalid m\u00e4rkimisv\u00e4\u00e4rset kadusid, v\u00f5ib FEC automaatselt aktiveerida ja v\u00f5imaldab vajadusel kadunud andmete osa taastada. Sellega suureneb veidi kasutatav ribalaius, kuid usaldusv\u00e4\u00e4rsus t\u00f5useb m\u00e4rgatavalt.\n
Andmevoogude dubleerimine<\/b> \u2013 lisaks FEC poliitikale v\u00f5ib automaatne valikute jagamine rakenduste liikluse koopia loomiseks olla etten\u00e4htud veelgi t\u00f5sisema kadumise taseme korral, mida FEC-i abil ei suudeta tasakaalustada. Sellisel juhul edastatakse valitud andmed k\u00f5iki tunnelite kaudu filiaali saajani koos edasise de-duplication'iga (\u00fclej\u00e4\u00e4nud koopia pakettide eemaldamine). Mehanism suurendab oluliselt kanalite kasutamise efektiivsust, kuid t\u00f5stab ka edastamise usaldusv\u00e4\u00e4rsust.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n <\/p>\n
Cisco SD-WAN v\u00f5imed, ilma vahetute analoogideta DMVPN\/PfR<\/h3>\n \nCisco SD-WAN lahenduse arhitektuur v\u00f5imaldab m\u00f5nel juhul saavutada funktsioone, mille rakendamine DMVPN\/PfR raames on kas \u00e4\u00e4rmiselt keeruline, v\u00f5i ebaotstarbekas vajalike t\u00f6\u00f6j\u00f5ukulude t\u00f5ttu, v\u00f5i on isegi t\u00e4iesti v\u00f5imatu. Vaadakem nende k\u00f5ige huvitavamaid aspekte:<\/p>\n
Traffic-Engineering (TE)<\/h4>\n \nTE h\u00f5lmab mehhanisme, mis v\u00f5imaldavad suunata liiklust standardsetelt marsruutimise protokollidelt k\u00f5rvale. TE-d kasutatakse sageli, et tagada k\u00f5rgem v\u00f5rguteenuste k\u00e4ttesaadavus, v\u00f5imaldades kiiresti ja\/v\u00f5i ette teada oluline liiklus suunata alternatiivsele (mitte\u00fchtivale) edastusteele, et tagada parema teenuse kvaliteedi v\u00f5i taastumise kiirus peamise marsruudi t\u00f5rke korral. <\/p>\n
TE rakendamise keerukus seisneb vajaduses eelnevalt v\u00e4lja arvutada ja reserveerida (kontrollida) alternatiivne tee. MPLS v\u00f5rkudes, mida haldavad teenusepakkujad, lahendatakse see probleem selliste tehnoloogiate abil nagu MPLS Traffic Engineering koos IGP protokollide ja RSVP protokollide laiendustega. Viimasel ajal on \u00fcha suuremat populaarsust kogumas ka Segment Routing tehnoloogia, mis on paremini optimeeritud tsentraliseeritud seadistamiseks ja orkestreerimiseks. Klassikalistes WAN-v\u00e4rkudes ei ole neid tehnoloogiaid tavaliselt esindatud v\u00f5i on need v\u00e4hendatud hop-by-hop mehhanismide nagu Policy-Based Routing (PBR) kasutamiseni, mis suudavad suunata liiklust, kuid rakendavad seda eraldi igas marsruutoris - ilma \u00fcldise v\u00f5rgu oleku v\u00f5i PBR-i tulemuste arvestamiseta eelnevatel v\u00f5i j\u00e4rgnevatel sammudel. Nende TE variantide rakendamise l\u00f5pptulemus on pettumustvalmistav - MPLS TE keerukuse t\u00f5ttu seadistamises ja haldamises, kasutatakse tavaliselt ainult k\u00f5ige kriitilisemas v\u00f5rguosas (tuum), samas kui PBR-i rakendatakse eraldiseisvates marsruutorites, ilma v\u00f5imaluseta kujundada mingit \u00fchte PBR poliitikat kogu v\u00f5rgu ulatuses. Ilmselgelt kehtib see ka DMVPN-p\u00f5histe v\u00f5rkude kohta.<\/p>\n
Service-chaining (Teenuse ahelad) <\/h4>\n \nTeenitud teenuseahelate vormimine on klassikalises marsruutimises veelgi t\u00f6\u00f6mahukam \u00fclesanne kui juba kirjeldatud Traffic-Engineering'i mehhanism. Selles olukorras on vajalik mitte ainult luua spetsiaalne marsruut teatud v\u00f5rgu rakenduse jaoks, vaid ka tagada, et liiklus saaks v\u00e4ljuda v\u00f5rgust teatud (v\u00f5i k\u00f5ikidel) SD-WAN node'idel, et mingit erirakendust v\u00f5i teenust nagu MSE, laadimine, vahem\u00e4lu, liikluse kontrollimist jne. t\u00f6\u00f6delda. Samuti peab olema v\u00f5imalik j\u00e4lgida nende v\u00e4list teenuste seisukorda, et v\u00e4ltida black-holing olukordi ning on vajalikud mehhanismid, mis v\u00f5imaldavad selliseid \u00fchesuguseid v\u00e4list teenuseid paigutada erinevatesse geograafilistesse asukohtadesse, et v\u00f5rk saaks automaatselt valida k\u00f5ige optimaalne teenuse node liikluse t\u00f6\u00f6tlemiseks antud filiaali jaoks. Cisco SD-WAN-i puhul on see piisavalt lihtne saavutada, luues vastava keskse poliitika, mis \u201eliibub\u201d k\u00f5ik sihtrikka teenuseahela aspektid \u00fchtseks ja muudab automaatselt data-plane ja control-plane loogikat ainult seal ja siis, kus see on vajalik.<\/p>\n
Mis on l\u00f5pptulemus?<\/h2>\n \nOn ilmne, et nii DMVPN (koos v\u00f5i ilma Performance Routinguta) kui ka Cisco SD-WAN lahendavad l\u00f5puks v\u00e4ga sarnaseid \u00fclesandeid<\/b> jaotatud WAN-v\u00f5rgu suhtes organisatsioonis. Oluline on, et Cisco SD-WAN tehnoloogia arhitektuuri ja funktsionaalsete erinevuste t\u00f5ttu viiakse nende \u00fclesannete lahendamine teisele kvaliteeditasemele.<\/b>Kokkuv\u00f5ttes v\u00f5ib m\u00e4rkida j\u00e4rgmisi olulisi erinevusi SD-WAN ja DMVPN\/PfR tehnoloogiate vahel:<\/p>\n\nDMVPN\/PfR kasutab tuntud tehnoloogiaid kihiliste VPN-v\u00f5rkude loomiseks ning andmeplaani osas sarnaneb see kaasaegse SD-WAN tehnoloogiaga, kuid sellega on seotud mitmed piirangud, nagu kohustuslik staatiline marsruuterite konfigureerimine ning topoloogiate valik on piiratud Hub-n-Spoke s\u00fcsteemiga. Kuid DMVPN\/PfR-l on m\u00f5ned funktsionaalsed v\u00f5imalused, mis ei ole veel SD-WAN-is saadaval (r\u00e4\u00e4kides per-application BFD-st).<\/li>\n Control-plane tehnoloogiate osas on need p\u00f5him\u00f5tteliselt erinevad. SD-WAN v\u00f5imaldab keskse signaaliprotsessimise abil oluliselt v\u00e4hendada t\u00f5rketsoone ja \u201elahutada\u201d kasutajate liikluse edastamise signaalidest \u2013 ajutine kontrollerite k\u00e4ttesaamatus ei m\u00f5juta kasutajate liikluse edastamise v\u00f5imalust. Samal ajal ei m\u00f5juta m\u00f5ne haru (sealhulgas keskse) ajutine k\u00e4ttesaamatus teiste harude omavahelist suhtlust ega kontrolleritega suhtlemist.<\/li>\n SD-WAN-i liiklusjuhtimise poliitikate kujundamise ja rakendamise arhitektuur \u00fcletab DMVPN\/PfR-i oma mitmekesisuses \u2013 geo-reserveerimine on paremini rakendatud, pole keskjaamaga seotust, poliitikate peenh\u00e4\u00e4lestamiseks on rohkem v\u00f5imalusi ning rakendatavate liiklusjuhtimise stsenaariumite nimekiri on samuti palju ulatuslikum.<\/li>\n Lahenduse orkestreerimisprotsess on samuti oluliselt erinev. DMVPN eeldab, et konfigureeritud peavad olema eelnevalt teadaolevad parameetrid, mis piirab lahenduse paindlikkust ja d\u00fcnaamiliste muudatuste v\u00f5imalusi. SD-WAN l\u00e4htub aga paradigmaatilisest seisukohast, et \u00fchenduse algusmomendil \u201eei tea\u201d ruuter oma kontrollereid, kuid \u201eteab, kelle k\u00fcsida\u201d \u2013 seda piisab mitte ainult automaatseks \u00fchenduse loomiseks kontrollereid, vaid ka t\u00e4ielikult \u00fchendatud andmeplaani topoloogia automaatseks moodustamiseks, mida saab hiljem poliitikate abil paindlikult kohandada\/muudatada.<\/li>\n TSentraliseeritud halduse, automatiseerimise ja j\u00e4lgimise osas \u00fcletab SD-WAN ootusp\u00e4raselt DMVPN\/PfR v\u00f5imalusi, mis on klassikaliste tehnoloogiate arengutulemused ja toetuvad enamasti CLI k\u00e4sureale ning mallidel p\u00f5hinevatele NMS s\u00fcsteemidele. <\/li>\n SD-WAN-is on v\u00f5rreldes DMVPN-iga ohutusn\u00f5uded t\u00f5usnud uuele kvaliteeditasemele. Peamised p\u00f5him\u00f5tted on null usaldus, skaleeritavus ja kahefaktoriline autentimine.<\/li>\n<\/ul>\n\nNendest lihtsatest j\u00e4reldustest v\u00f5ib luua vale mulje, et DMVPN\/PfR-l p\u00f5hineva v\u00f5rgu loomine on t\u00e4na igasuguse aktuaalsuse kaotanud. See ei ole kindlasti t\u00e4iesti t\u00f5si. N\u00e4iteks olukordades, kus v\u00f5rgus kasutatakse palju vananenud seadmeid ja ei ole v\u00f5imalust neid asendada, v\u00f5ib DMVPN v\u00f5imaldada \"vanade\" ja \"uute\" seadmete \u00fchendamist \u00fchte geo-jaotatud v\u00f5rku koos paljude eelpool kirjeldatud eelistega.<\/p>\n
Teisest k\u00fcljest tuleb meeles pidada, et k\u00f5ik praegused Cisco ettev\u00f5tte ruuterid, mis p\u00f5hinevad IOS XE-l (ISR 1000, ISR 4000, ASR 1000, CSR 1000v), toetavad t\u00e4na mis tahes t\u00f6\u00f6re\u017eiimi \u2013 nii klassikalist suunamist, DMVPN-d kui ka SD-WAN-i. valik s\u00f5ltub praegustest vajadustest ja arusaamast, et samal riistvaral on v\u00f5imalik 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