Vai Cisco SD-WAN nogriezīs zaru, uz kura atrodas DMVPN?

KopÅ” 2017. gada augusta, kad Cisco iegādājās Viptela, galvenā piedāvātā tehnoloÄ£ija izplatÄ«to uzņēmumu tÄ«klu organizÄ“Å”anai ir kļuvusi Cisco SD-WAN. Pēdējo 3 gadu laikā SD-WAN tehnoloÄ£ija ir piedzÄ«vojusi daudzas izmaiņas gan kvalitatÄ«vi, gan kvantitatÄ«vi. Tādējādi funkcionalitāte ir ievērojami paplaÅ”inājusies un ir parādÄ«jies atbalsts sērijas klasiskajiem marÅ”rutētājiem Cisco ISR 1000, ISR 4000, ASR 1000 un Virtual CSR 1000v. Tajā paŔā laikā daudzi Cisco klienti un partneri turpina brÄ«nÄ«ties: kādas ir atŔķirÄ«bas starp Cisco SD-WAN un jau pazÄ«stamajām pieejām, kuru pamatā ir tādas tehnoloÄ£ijas kā Cisco DMVPN Šø Cisco veiktspējas marÅ”rutÄ“Å”ana un cik svarÄ«gas ir Ŕīs atŔķirÄ«bas?

Å eit mums nekavējoties jāizdara atruna, ka pirms SD-WAN parādÄ«Å”anās Cisco portfelÄ« DMVPN kopā ar PfR veidoja galveno arhitektÅ«ras daļu. Cisco IWAN (inteliÄ£entais WAN), kas savukārt bija pilnvērtÄ«gas SD-WAN tehnoloÄ£ijas priekÅ”tecis. Neskatoties uz risināmo uzdevumu un to risināŔanas metožu vispārējo lÄ«dzÄ«bu, IWAN nekad nav saņēmis SD-WAN nepiecieÅ”amo automatizācijas, elastÄ«bas un mērogojamÄ«bas lÄ«meni, un laika gaitā IWAN attÄ«stÄ«ba ir ievērojami samazinājusies. Tajā paŔā laikā tehnoloÄ£ijas, kas veido IWAN, nav pazuduÅ”as, un daudzi klienti turpina tās veiksmÄ«gi izmantot, tostarp modernās iekārtās. Rezultātā ir izveidojusies interesanta situācija - viena un tā pati Cisco iekārta ļauj izvēlēties piemērotāko WAN tehnoloÄ£iju (classic, DMVPN+PfR vai SD-WAN) atbilstoÅ”i klientu prasÄ«bām un vēlmēm.

Rakstā nav paredzēts detalizēti analizēt visas Cisco SD-WAN un DMVPN tehnoloÄ£iju funkcijas (ar vai bez veiktspējas marÅ”rutÄ“Å”anas) - Å”im nolÅ«kam ir pieejams milzÄ«gs daudzums dokumentu un materiālu. Galvenais uzdevums ir mēģināt novērtēt galvenās atŔķirÄ«bas starp Ŕīm tehnoloÄ£ijām. Bet pirms pāriet uz Å”o atŔķirÄ«bu apsprieÅ”anu, Ä«si atcerēsimies paÅ”as tehnoloÄ£ijas.

Kas ir Cisco DMVPN un kāpēc tas ir vajadzīgs?

Cisco DMVPN atrisina attālā filiāļu tÄ«kla dinamiska (= mērogojama) savienojuma ar uzņēmuma centrālā biroja tÄ«klu problēmu, izmantojot patvaļīgus sakaru kanālu veidus, tostarp internetu (= ar sakaru kanāla Å”ifrÄ“Å”anu). Tehniski tas tiek realizēts, izveidojot virtualizētu L3 VPN klases pārklājuma tÄ«klu point-to-multipoint režīmā ar loÄ£isku ā€œStarā€ tipa topoloÄ£iju (Hub-n-Spoke). Lai to panāktu, DMVPN izmanto Ŕādu tehnoloÄ£iju kombināciju:

  • IP marÅ”rutÄ“Å”ana
  • Daudzpunktu GRE tuneļi (mGRE)
  • Next Hop Resolution Protocol (NHRP)
  • IPSec Crypto profili

Vai Cisco SD-WAN nogriezīs zaru, uz kura atrodas DMVPN?

Kādas ir galvenās Cisco DMVPN priekÅ”rocÄ«bas salÄ«dzinājumā ar klasisko marÅ”rutÄ“Å”anu, izmantojot MPLS VPN kanālus?

  • Lai izveidotu starpnozaru tÄ«klu, ir iespējams izmantot jebkurus sakaru kanālus - ir piemērots jebkas, kas var nodroÅ”ināt IP savienojamÄ«bu starp filiālēm, savukārt trafiks tiks Å”ifrēts (kur nepiecieÅ”ams) un lÄ«dzsvarots (kur iespējams)
  • Automātiski tiek izveidota pilnÄ«bā savienota topoloÄ£ija starp zariem. Tajā paŔā laikā starp centrālajiem un attālajiem atzariem ir statiski tuneļi, bet starp attālajiem atzariem pēc pieprasÄ«juma ir dinamiski tuneļi (ja ir satiksme).
  • Centrālās un attālās filiāles marÅ”rutētājiem ir vienāda konfigurācija lÄ«dz interfeisu IP adresēm. Izmantojot mGRE, nav nepiecieÅ”ams individuāli konfigurēt desmitiem, simtiem vai pat tÅ«kstoÅ”iem tuneļu. Rezultātā pienācÄ«ga mērogojamÄ«ba ar pareizo dizainu.

Kas ir Cisco veiktspējas marÅ”rutÄ“Å”ana un kāpēc tas ir vajadzÄ«gs?

Izmantojot DMVPN starpnozaru tÄ«klā, neatrisināts paliek viens ārkārtÄ«gi bÅ«tisks jautājums - kā dinamiski novērtēt katra DMVPN tuneļa stāvokli, lai tas atbilstu mÅ«su organizācijai kritiskajām satiksmes prasÄ«bām un atkal, pamatojoties uz Ŕādu novērtējumu, dinamiski veikt. lēmums par marÅ”ruta maiņu? Fakts ir tāds, ka DMVPN Å”ajā daļā maz atŔķiras no klasiskās marÅ”rutÄ“Å”anas - labākais, ko var izdarÄ«t, ir konfigurēt QoS mehānismus, kas ļaus noteikt prioritāti trafikam izejoŔā virzienā, bet nekādā gadÄ«jumā nevar ņemt vērā visu ceļu vienā vai otrā reizē.

Un ko darÄ«t, ja kanāls degradējas daļēji, nevis pilnÄ«bā - kā to atklāt un novērtēt? DMVPN pats to nevar izdarÄ«t. Ņemot vērā, ka kanāli, kas savieno filiāles, var iziet cauri pilnÄ«gi dažādiem telekomunikāciju operatoriem, izmantojot pilnÄ«gi atŔķirÄ«gas tehnoloÄ£ijas, Å”is uzdevums kļūst ārkārtÄ«gi nenozÄ«mÄ«gs. Un Å”eit palÄ«gā nāk Cisco Performance Routing tehnoloÄ£ija, kas lÄ«dz tam laikam jau bija izgājusi vairākus attÄ«stÄ«bas posmus.

Vai Cisco SD-WAN nogriezīs zaru, uz kura atrodas DMVPN?

Cisco Performance Routing (turpmāk PfR) uzdevums ir izmērÄ«t trafika ceļu (tuneļu) stāvokli, pamatojoties uz galvenajiem tÄ«kla lietojumprogrammām svarÄ«giem rādÄ«tājiem. latentums, latentuma izmaiņas (trÄ«ce) un pakeÅ”u zudumi (procentos). Turklāt var izmērÄ«t izmantoto joslas platumu. Å ie mērÄ«jumi notiek pēc iespējas tuvāk reālajam laikam un pamatoti, un Å”o mērÄ«jumu rezultāts ļauj marÅ”rutētājam, kas izmanto PfR, dinamiski pieņemt lēmumus par nepiecieÅ”amÄ«bu mainÄ«t tā vai cita veida trafika marÅ”rutÄ“Å”anu.

Tādējādi DMVPN / PfR kombinācijas uzdevumu var Ä«si aprakstÄ«t Ŕādi:

  • Ä»aujiet klientam izmantot jebkurus sakaru kanālus WAN tÄ«klā
  • NodroÅ”iniet augstāko iespējamo kritisko lietojumprogrammu kvalitāti Å”ajos kanālos

Kas ir Cisco SD-WAN?

Cisco SD-WAN ir tehnoloÄ£ija, kas izmanto SDN pieeju, lai izveidotu un darbinātu organizācijas WAN tÄ«klu. Tas jo Ä«paÅ”i nozÄ«mē tā saukto kontrolieru (programmatÅ«ras elementu) izmantoÅ”anu, kas nodroÅ”ina visu risinājuma komponentu centralizētu orÄ·estrÄ“Å”anu un automatizētu konfigurāciju. AtŔķirÄ«bā no kanoniskā SDN (Clean Slate style), Cisco SD-WAN izmanto vairāku veidu kontrolierus, no kuriem katrs veic savu lomu - tas tika darÄ«ts ar nolÅ«ku, lai nodroÅ”inātu labāku mērogojamÄ«bu un Ä£eogrāfisko atlaiÅ”anu.

Vai Cisco SD-WAN nogriezīs zaru, uz kura atrodas DMVPN?

SD-WAN gadÄ«jumā uzdevums izmantot jebkāda veida kanālus un nodroÅ”ināt biznesa aplikāciju darbÄ«bu paliek nemainÄ«gs, taču tajā paŔā laikā paplaÅ”inās prasÄ«bas Ŕāda tÄ«kla automatizācijai, mērogojamÄ«bai, droŔībai un elastÄ«bai.

AtŔķirību diskusija

Ja mēs tagad sāksim analizēt atŔķirÄ«bas starp Ŕīm tehnoloÄ£ijām, tās iedalÄ«sies kādā no Ŕīm kategorijām:

  • ArhitektÅ«ras atŔķirÄ«bas ā€“ kā funkcijas tiek sadalÄ«tas pa dažādiem risinājuma komponentiem, kā tiek organizēta Ŕādu komponentu mijiedarbÄ«ba un kā tas ietekmē tehnoloÄ£ijas iespējas un elastÄ«bu?
  • Funkcionalitāte ā€“ ko viena tehnoloÄ£ija var darÄ«t, ko cita nespēj? Un vai tas tieŔām ir tik svarÄ«gi?

Kādas ir arhitektūras atŔķirības un vai tās ir svarīgas?

Katrai no Ŕīm tehnoloÄ£ijām ir daudz ā€œkustÄ«go daļuā€, kas atŔķiras ne tikai ar savām lomām, bet arÄ« to, kā tās mijiedarbojas savā starpā. Cik labi Å”ie principi ir pārdomāti un risinājuma vispārējā mehānika tieÅ”i nosaka tā mērogojamÄ«bu, kļūdu toleranci un kopējo efektivitāti.

Apskatīsim dažādus arhitektūras aspektus sīkāk:

Datu plakne ā€“ daļa no risinājuma, kas atbild par lietotāja trafika pārsÅ«tÄ«Å”anu starp avotu un saņēmēju. DMVPN un SD-WAN parasti tiek ieviesti identiski paÅ”os marÅ”rutētājos, pamatojoties uz daudzpunktu GRE tuneļiem. AtŔķirÄ«ba ir tā, kā tiek veidots nepiecieÅ”amais parametru kopums Å”iem tuneļiem:

  • Š² DMVPN/PfR ir tikai divu lÄ«meņu mezglu hierarhija ar Star vai Hub-n-Spoke topoloÄ£iju. NepiecieÅ”ama statiskā centrmezgla konfigurācija un statiskā Spoke saistÄ«Å”ana ar centrmezglu, kā arÄ« mijiedarbÄ«ba, izmantojot NHRP protokolu, lai izveidotu datu plaknes savienojumu. SekojoÅ”i, ievērojami apgrÅ«tinot izmaiņas centrmezglākas saistÄ«ti, piemēram, ar jaunu WAN kanālu maiņu/pieslēgÅ”anu vai esoÅ”o parametru maiņu.
  • Š² SD WAN ir pilnÄ«bā dinamisks modelis uzstādÄ«to tuneļu parametru noteikÅ”anai, pamatojoties uz vadÄ«bas plakni (OMP protokols) un orÄ·estrÄ“Å”anas plakni (mijiedarbÄ«ba ar vBond kontrolleri kontroliera noteikÅ”anai un NAT ŔķērsoÅ”anas uzdevumiem). Å ajā gadÄ«jumā var izmantot jebkuras virskārtas topoloÄ£ijas, ieskaitot hierarhiskas. Izveidotās pārklājuma tuneļa topoloÄ£ijas ietvaros ir iespējama elastÄ«ga loÄ£iskās topoloÄ£ijas konfigurācija katrā atseviŔķā VPN (VRF).

Vai Cisco SD-WAN nogriezīs zaru, uz kura atrodas DMVPN?

VadÄ«bas plakne ā€“ marÅ”rutÄ“Å”anas un citas informācijas apmaiņas, filtrÄ“Å”anas un modifikācijas funkcijas starp risinājuma komponentiem.

  • Š² DMVPN/PfR ā€“ tiek veikta tikai starp Hub un Spoke marÅ”rutētājiem. TieÅ”a marÅ”rutÄ“Å”anas informācijas apmaiņa starp spieÄ·iem nav iespējama. SekojoÅ”i, Bez funkcionējoÅ”a centrmezgla vadÄ«bas plakne un datu plakne nevar darboties, kas centrmezglam uzliek papildu augstas pieejamÄ«bas prasÄ«bas, kuras ne vienmēr var izpildÄ«t.
  • Š² SD WAN - vadÄ«bas plakne nekad netiek veikta tieÅ”i starp marÅ”rutētājiem - mijiedarbÄ«ba notiek, pamatojoties uz OMP protokolu un obligāti tiek veikta, izmantojot atseviŔķu specializētu vSmart kontrollera veidu, kas nodroÅ”ina iespēju lÄ«dzsvarot, Ä£eogrāfiski rezervēt un centralizēti kontrolēt signāla slodze. Vēl viena OMP protokola iezÄ«me ir tā ievērojamā izturÄ«ba pret zaudējumiem un neatkarÄ«ba no sakaru kanāla ātruma ar kontrolieriem (protams, saprātÄ«gās robežās). Kas vienlÄ«dz veiksmÄ«gi ļauj izvietot SD-WAN kontrolierus publiskos vai privātos mākoņos ar piekļuvi caur internetu.

Vai Cisco SD-WAN nogriezīs zaru, uz kura atrodas DMVPN?

Politikas plāns ā€“ daļa no risinājuma, kas atbild par trafika pārvaldÄ«bas politiku definÄ“Å”anu, izplatÄ«Å”anu un piemēroÅ”anu izplatÄ«tajā tÄ«klā.

  • DMVPN ā€“ to efektÄ«vi ierobežo pakalpojuma kvalitātes (QoS) politikas, kas katrā marÅ”rutētājā konfigurētas atseviŔķi, izmantojot CLI vai Prime Infrastructure veidnes.
  • DMVPN/PfR ā€“ PfR politikas tiek veidotas centralizētajā galvenā kontrollera (MC) marÅ”rutētājā, izmantojot CLI, un pēc tam automātiski izplatÄ«tas filiāles MC. Å ajā gadÄ«jumā tiek izmantoti tie paÅ”i politikas pārsÅ«tÄ«Å”anas ceļi kā datu plaknei. Nav iespējas nodalÄ«t politiku, marÅ”rutÄ“Å”anas informācijas un lietotāja datu apmaiņu. Politikas izplatÄ«Å”anai ir nepiecieÅ”ams IP savienojuma klātbÅ«tne starp centrmezglu un spoku. Å ajā gadÄ«jumā MC funkciju vajadzÄ«bas gadÄ«jumā var apvienot ar DMVPN marÅ”rutētāju. Ir iespējams (bet nav obligāti) izmantot Prime Infrastructure veidnes centralizētai politikas Ä£enerÄ“Å”anai. SvarÄ«ga iezÄ«me ir tāda, ka politika visā tÄ«klā tiek veidota globāli vienādi - AtseviŔķas politikas atseviŔķiem segmentiem netiek atbalstÄ«tas.
  • SD WAN ā€“ trafika pārvaldÄ«ba un pakalpojumu kvalitātes politikas tiek noteiktas centralizēti caur Cisco vManage grafisko interfeisu, kas pieejams arÄ« caur internetu (ja nepiecieÅ”ams). Tie tiek izplatÄ«ti pa signalizācijas kanāliem tieÅ”i vai netieÅ”i, izmantojot vSmart kontrollerus (atkarÄ«bā no politikas veida). Tie nav atkarÄ«gi no datu plaknes savienojamÄ«bas starp marÅ”rutētājiem, jo izmantojiet visus pieejamos satiksmes ceļus starp kontrolieri un marÅ”rutētāju.

    Dažādiem tīkla segmentiem iespējams elastīgi formulēt dažādas politikas - politikas apjomu nosaka daudzi unikāli risinājumā sniegtie identifikatori - filiāles numurs, aplikācijas veids, satiksmes virziens u.c.

Vai Cisco SD-WAN nogriezīs zaru, uz kura atrodas DMVPN?

OrÄ·estrācija-plakne ā€“ mehānismi, kas ļauj komponentiem dinamiski atklāt vienam otru, konfigurēt un koordinēt turpmākās mijiedarbÄ«bas.

  • Š² DMVPN/PfR MarÅ”rutētāju savstarpējās atklāŔanas pamatā ir centrmezgla ierīču statiskā konfigurācija un atbilstoŔā Spoke ierīču konfigurācija. Dinamiskā atklāŔana notiek tikai Spoke, kas ziņo par saviem centrmezgla savienojuma parametriem ierÄ«cei, kas savukārt ir iepriekÅ” konfigurēta ar Spoke. Bez IP savienojuma starp Spoke un vismaz vienu centrmezglu nav iespējams izveidot ne datu plakni, ne vadÄ«bas plakni.
  • Š² SD WAN risinājuma komponentu orÄ·estrÄ“Å”ana notiek, izmantojot vBond kontrolleri, ar kuru katram komponentam (marÅ”rutētāji un vManage/vSmart kontrolleri) vispirms ir jāizveido IP savienojums.

    Sākotnēji komponenti nezina viens par otra savienojuma parametriem - Å”im nolÅ«kam viņiem ir nepiecieÅ”ams vBond starpnieksorÄ·estris. Vispārējais princips ir Ŕāds - katrs komponents sākuma fāzē apgÅ«st (automātiski vai statiski) tikai par savienojuma parametriem vBond, pēc tam vBond informē marÅ”rutētāju par vManage un vSmart kontrolleriem (atklāti iepriekÅ”), kas ļauj automātiski izveidot visi nepiecieÅ”amie signalizācijas savienojumi.

    Nākamais solis ir jaunajam marÅ”rutētājam uzzināt par citiem marÅ”rutētājiem tÄ«klā, izmantojot OMP saziņu ar vSmart kontrolleri. Tādējādi marÅ”rutētājs, sākotnēji vispār neko nezinot par tÄ«kla parametriem, spēj pilnÄ«bā automātiski noteikt un izveidot savienojumu ar kontrolieriem un pēc tam arÄ« automātiski noteikt un veidot savienojumu ar citiem marÅ”rutētājiem. Å ajā gadÄ«jumā visu komponentu savienojuma parametri sākotnēji nav zināmi un darbÄ«bas laikā var mainÄ«ties.

Vai Cisco SD-WAN nogriezīs zaru, uz kura atrodas DMVPN?

VadÄ«bas plakne ā€“ daļa no risinājuma, kas nodroÅ”ina centralizētu pārvaldÄ«bu un uzraudzÄ«bu.

  • DMVPN/PfR ā€“ netiek nodroÅ”ināts specializēts vadÄ«bas plaknes risinājums. Pamata automatizācijai un uzraudzÄ«bai var izmantot tādus produktus kā Cisco Prime Infrastructure. Katru marÅ”rutētāju var vadÄ«t, izmantojot CLI komandrindu. Integrācija ar ārējām sistēmām, izmantojot API, netiek nodroÅ”ināta.
  • SD WAN ā€“ visa regulārā mijiedarbÄ«ba un uzraudzÄ«ba tiek veikta centralizēti, izmantojot vManage kontrollera grafisko interfeisu. Visas risinājuma funkcijas bez izņēmuma ir pieejamas konfigurÄ“Å”anai, izmantojot vManage, kā arÄ« pilnÄ«bā dokumentētu REST API bibliotēku.

    Visi SD-WAN tÄ«kla iestatÄ«jumi vManage ir saistÄ«ti ar divām galvenajām konstrukcijām - ierīču veidņu (Device Template) veidoÅ”anu un politikas veidoÅ”anu, kas nosaka tÄ«kla darbÄ«bas un trafika apstrādes loÄ£iku. Tajā paŔā laikā vManage, pārraidot administratora Ä£enerēto politiku, automātiski atlasa, kuras izmaiņas un kurās atseviŔķās ierÄ«cēs/kontrolleros jāveic, kas bÅ«tiski palielina risinājuma efektivitāti un mērogojamÄ«bu.

    Izmantojot vManage interfeisu, ir pieejama ne tikai Cisco SD-WAN risinājuma konfigurācija, bet arÄ« pilnÄ«ga visu risinājuma komponentu statusa uzraudzÄ«ba lÄ«dz pat atseviŔķu tuneļu metrikas paÅ”reizējam stāvoklim un dažādu lietojumprogrammu izmantoÅ”anas statistikai. pamatojoties uz DPI analÄ«zi.

    Neskatoties uz mijiedarbÄ«bas centralizāciju, visiem komponentiem (kontrolleriem un marÅ”rutētājiem) ir arÄ« pilnÄ«bā funkcionējoÅ”a CLI komandrinda, kas nepiecieÅ”ama ievieÅ”anas stadijā vai avārijas gadÄ«jumā vietējai diagnostikai. Normālā režīmā (ja starp komponentiem ir signalizācijas kanāls) marÅ”rutētājos komandrinda ir pieejama tikai diagnostikai un nav pieejama lokālu izmaiņu veikÅ”anai, kas garantē lokālo droŔību un vienÄ«gais izmaiņu avots Ŕādā tÄ«klā ir vManage.

Integrētā droŔība ā€“ Å”eit jārunā ne tikai par lietotāja datu aizsardzÄ«bu, kad tie tiek pārraidÄ«ti pa atvērtiem kanāliem, bet arÄ« par kopējo WAN tÄ«kla droŔību, pamatojoties uz izvēlēto tehnoloÄ£iju.

  • Š² DMVPN/PfR Ir iespējams Å”ifrēt lietotāja datus un signalizācijas protokolus. Lietojot noteiktus marÅ”rutētāju modeļus, papildus ir pieejamas ugunsmÅ«ra funkcijas ar satiksmes pārbaudi, IPS/IDS. Ir iespējams segmentēt filiāļu tÄ«klus, izmantojot VRF. Ir iespējams autentificēt (vienfaktora) kontroles protokolus.

    Å ajā gadÄ«jumā attālais marÅ”rutētājs pēc noklusējuma tiek uzskatÄ«ts par uzticamu tÄ«kla elementu ā€“ t.i. netiek pieņemti vai ņemti vērā atseviŔķu ierīču fiziska kompromitÄ“Å”anas gadÄ«jumi un nesankcionētas piekļuves iespēja tām, nav risinājuma komponentu divu faktoru autentifikācijas, kas Ä£eogrāfiski izkliedēta tÄ«kla gadÄ«jumā var radÄ«t ievērojamus papildu riskus.

  • Š² SD WAN pēc analoÄ£ijas ar DMVPN tiek nodroÅ”ināta iespēja Å”ifrēt lietotāja datus, bet ar ievērojami paplaÅ”inātām tÄ«kla droŔības un L3/VRF segmentācijas funkcijām (ugunsmÅ«ris, IPS/IDS, URL filtrÄ“Å”ana, DNS filtrÄ“Å”ana, AMP/TG, SASE, TLS/SSL starpniekserveris, utt.) d.). Tajā paŔā laikā Å”ifrÄ“Å”anas atslēgu apmaiņa tiek veikta efektÄ«vāk, izmantojot vSmart kontrolierus (nevis tieÅ”i), izmantojot iepriekÅ” izveidotus signalizācijas kanālus, kas aizsargāti ar DTLS/TLS Å”ifrÄ“Å”anu, pamatojoties uz droŔības sertifikātiem. Kas savukārt garantē Ŕādu apmaiņu droŔību un nodroÅ”ina labāku risinājuma mērogojamÄ«bu lÄ«dz pat desmitiem tÅ«kstoÅ”u ierīču vienā tÄ«klā.

    Visi signalizācijas savienojumi (kontrolleris-kontrolleris, kontrolleris-marÅ”rutētājs) arÄ« ir aizsargāti, pamatojoties uz DTLS/TLS. MarÅ”rutētāji ražoÅ”anas laikā ir aprÄ«koti ar droŔības sertifikātiem ar iespēju nomainÄ«t/pagarināt. Divu faktoru autentifikācija tiek panākta, obligāti un vienlaikus izpildot divus nosacÄ«jumus, lai marÅ”rutētājs/kontrolleris darbotos SD-WAN tÄ«klā:

    • DerÄ«gs droŔības sertifikāts
    • Administrators skaidri un apzināti iekļauj katra komponenta ā€œbaltajāā€ atļauto ierīču sarakstā.

Vai Cisco SD-WAN nogriezīs zaru, uz kura atrodas DMVPN?

Funkcionālās atŔķirības starp SD-WAN un DMVPN/PfR

Pārejot pie funkcionālo atŔķirÄ«bu iztirzāŔanas, jāatzÄ«mē, ka daudzas no tām ir arhitektonisko turpinājums - nav noslēpums, ka, veidojot risinājuma arhitektÅ«ru, izstrādātāji iziet no iespējām, kuras galu galā vēlas iegÅ«t. ApskatÄ«sim bÅ«tiskākās atŔķirÄ«bas starp abām tehnoloÄ£ijām.

AppQ (Application Quality) ā€“ funkcijas, lai nodroÅ”inātu biznesa lietojumprogrammu trafika pārraides kvalitāti

AplÅ«kojamo tehnoloÄ£iju galvenās funkcijas ir vērstas uz to, lai pēc iespējas vairāk uzlabotu lietotāja pieredzi, izmantojot biznesam svarÄ«gas lietojumprogrammas izplatÄ«tajā tÄ«klā. ÄŖpaÅ”i svarÄ«gi tas ir apstākļos, kad daļu infrastruktÅ«ras nekontrolē IT vai pat negarantē veiksmÄ«gu datu pārraidi.

DMVPN pats nenodroÅ”ina Ŕādus mehānismus. Labākais, ko var izdarÄ«t klasiskajā DMVPN tÄ«klā, ir klasificēt izejoÅ”o trafiku pēc lietojumprogrammas un noteikt to prioritāti, kad tā tiek pārraidÄ«ta uz WAN kanālu. DMVPN tuneļa izvēli Å”ajā gadÄ«jumā nosaka tikai tā pieejamÄ«ba un marÅ”rutÄ“Å”anas protokolu darbÄ«bas rezultāts. Tajā paŔā laikā ceļa/tuneļa stāvoklis no gala lÄ«dz galam un tā iespējamā daļēja degradācija netiek ņemta vērā attiecÄ«bā uz galvenajiem rādÄ«tājiem, kas ir nozÄ«mÄ«gi tÄ«kla lietojumprogrammām - aizkave, aizkaves izmaiņas (trÄ«ce) un zudumi (% ). Å ajā sakarā, tieÅ”i salÄ«dzinot klasisko DMVPN ar SD-WAN AppQ problēmu risināŔanas ziņā, tiek zaudēta visa nozÄ«me - DMVPN nevar atrisināt Å”o problēmu. Ja Å”im kontekstam pievienojat Cisco Performance Routing (PfR) tehnoloÄ£iju, situācija mainās un salÄ«dzināŔana ar Cisco SD-WAN kļūst nozÄ«mÄ«gāka.

Pirms mēs apspriežam atŔķirÄ«bas, Å”eit ir Ä«ss ieskats tehnoloÄ£iju lÄ«dzÄ«bās. Tātad, abas tehnoloÄ£ijas:

  • ir mehānisms, kas ļauj dinamiski novērtēt katra izveidotā tuneļa stāvokli, ņemot vērā noteiktus rādÄ«tājus - pēc minimuma, aizkaves, aizkaves variācijas un pakeÅ”u zuduma (%)
  • izmantot Ä«paÅ”u rÄ«ku komplektu, lai veidotu, izplatÄ«tu un piemērotu satiksmes pārvaldÄ«bas noteikumus (politiku), ņemot vērā galveno tuneļa rādÄ«tāju stāvokļa mērÄ«Å”anas rezultātus.
  • klasificēt lietojumprogrammu trafiku OSI modeļa L3-L4 (DSCP) lÄ«menÄ« vai pēc L7 lietojumprogrammu parakstiem, pamatojoties uz marÅ”rutētājā iebÅ«vētiem DPI mehānismiem
  • NozÄ«mÄ«gām lietojumprogrammām tie ļauj noteikt pieļaujamās metrikas sliekŔņa vērtÄ«bas, noteikumus trafika pārsÅ«tÄ«Å”anai pēc noklusējuma un noteikumus trafika marÅ”rutÄ“Å”anai, ja sliekŔņa vērtÄ«bas tiek pārsniegtas.
  • Iekapsulējot trafiku GRE/IPSec, viņi izmanto jau izveidoto nozares mehānismu iekŔējo DSCP marķējumu pārsÅ«tÄ«Å”anai uz ārējo GRE/IPSEC pakeÅ”u galveni, kas ļauj sinhronizēt organizācijas un telekomunikāciju operatora QoS politikas (ja ir atbilstoÅ”s SLA) .

Vai Cisco SD-WAN nogriezīs zaru, uz kura atrodas DMVPN?

Kā atŔķiras SD-WAN un DMVPN/PfR metrika no gala līdz galam?

DMVPN/PfR

  • Lai novērtētu standarta tuneļa veselÄ«bas rādÄ«tājus, tiek izmantoti gan aktÄ«vie, gan pasÄ«vie programmatÅ«ras sensori (zondes). AktÄ«vās ir balstÄ«tas uz lietotāju trafiku, pasÄ«vās atdarina Ŕādu trafiku (ja tās nav).
  • Taimeru un degradācijas noteikÅ”anas apstākļu precÄ«za regulÄ“Å”ana nav veikta - algoritms ir fiksēts.
  • Turklāt ir pieejams izmantotā joslas platuma mērÄ«jums izejoŔā virzienā. Kas pievieno papildu trafika pārvaldÄ«bas elastÄ«bu DMVPN/PfR.
  • Tajā paŔā laikā daži PfR mehānismi, ja tiek pārsniegti rādÄ«tāji, paļaujas uz atgriezeniskās saites signālu Ä«paÅ”u TCA (Threshold Crossing Alert) ziņojumu veidā, kam jānāk no satiksmes saņēmēja virzienā uz avotu, kas savukārt pieņem, ka izmērÄ«tajiem kanāliem jābÅ«t vismaz pietiekamiem Ŕādu TCA ziņojumu pārraidÄ«Å”anai. Kas vairumā gadÄ«jumu nav problēma, bet acÄ«mredzami to nevar garantēt.

SD WAN

  • Standarta tuneļa stāvokļa metrikas pilnÄ«gai novērtÄ“Å”anai BFD protokols tiek izmantots atbalss režīmā. Å ajā gadÄ«jumā Ä«paÅ”a atgriezeniskā saite TCA vai lÄ«dzÄ«gu ziņojumu veidā nav nepiecieÅ”ama - tiek saglabāta kļūmju domēnu izolācija. Lai novērtētu tuneļa stāvokli, nav nepiecieÅ”ama arÄ« lietotāju trafika klātbÅ«tne.
  • Ir iespējams precÄ«zi noregulēt BFD taimerus, lai regulētu reakcijas ātrumu un algoritma jutÄ«gumu pret sakaru kanāla degradāciju no vairākām sekundēm lÄ«dz minÅ«tēm.

    Vai Cisco SD-WAN nogriezīs zaru, uz kura atrodas DMVPN?

  • RakstÄ«Å”anas laikā katrā tunelÄ« ir tikai viena BFD sesija. Tas potenciāli rada mazāku tuneļa stāvokļa analÄ«zi. PatiesÄ«bā tas var kļūt par ierobežojumu tikai tad, ja izmantojat WAN savienojumu, kura pamatā ir MPLS L2/L3 VPN ar saskaņotu QoS SLA ā€” ja BFD trafika DSCP marķējums (pēc iekapsulÄ“Å”anas IPSec/GRE) atbilst augstas prioritātes rindai telekomunikāciju operatora tÄ«klā, tas var ietekmēt zemas prioritātes trafika degradācijas noteikÅ”anas precizitāti un ātrumu. Tajā paŔā laikā ir iespējams mainÄ«t noklusējuma BFD marķējumu, lai samazinātu Ŕādu situāciju risku. Turpmākajās Cisco SD-WAN programmatÅ«ras versijās ir sagaidāmi precÄ«zāki BFD iestatÄ«jumi, kā arÄ« iespēja palaist vairākas BFD sesijas vienā tunelÄ« ar atseviŔķām DSCP vērtÄ«bām (dažādām lietojumprogrammām).
  • BFD papildus ļauj novērtēt maksimālo pakeÅ”u lielumu, ko var pārsÅ«tÄ«t pa noteiktu tuneli bez sadrumstalotÄ«bas. Tas ļauj SD-WAN dinamiski pielāgot tādus parametrus kā MTU un TCP MSS Adjust, lai maksimāli izmantotu pieejamo joslas platumu katrā saitē.
  • SD-WAN ir pieejama arÄ« QoS sinhronizācijas iespēja no telekomunikāciju operatoriem, ne tikai pamatojoties uz L3 DSCP laukiem, bet arÄ« pamatojoties uz L2 CoS vērtÄ«bām, kuras var automātiski Ä£enerēt filiāļu tÄ«klā ar specializētām ierÄ«cēm - piemēram, IP. tālruņi

Kā atŔķiras AppQ politiku definÄ“Å”anas un piemēroÅ”anas iespējas, metodes?

DMVPN/PfR politikas:

  • Definēts centrālajā(-s) filiāles marÅ”rutētājā(-os), izmantojot CLI komandrindu vai CLI konfigurācijas veidnes. CLI veidņu Ä£enerÄ“Å”anai ir nepiecieÅ”ama sagatavoÅ”anās un zināŔanas par politikas sintakse.

    Vai Cisco SD-WAN nogriezīs zaru, uz kura atrodas DMVPN?

  • Definēts globāli bez individuālas konfigurācijas/izmaiņas iespējas atseviŔķu tÄ«kla segmentu prasÄ«bām.
  • Grafiskajā saskarnē nav nodroÅ”ināta interaktÄ«va politikas Ä£enerÄ“Å”ana.
  • Izmaiņu izsekoÅ”ana, mantoÅ”ana un vairāku politiku versiju izveide ātrai pārslēgÅ”anai netiek nodroÅ”ināta.
  • Automātiski tiek izplatÄ«ts attālo filiāļu marÅ”rutētājiem. Å ajā gadÄ«jumā tiek izmantoti tie paÅ”i sakaru kanāli, kas tiek izmantoti lietotāja datu pārsÅ«tÄ«Å”anai. Ja nav sakaru kanāla starp centrālo un attālo filiāli, politiku izplatÄ«Å”ana/maiņa nav iespējama.
  • Tie tiek izmantoti katrā marÅ”rutētājā un, ja nepiecieÅ”ams, modificē standarta marÅ”rutÄ“Å”anas protokolu rezultātu ar augstāku prioritāti.
  • GadÄ«jumos, kad visas filiāles WAN saites piedzÄ«vo ievērojamus trafika zudumus, nav paredzēti kompensācijas mehānismi.

SD-WAN politikas:

  • Definēts vManage GUI, izmantojot interaktÄ«vo veidņu vedni.
  • Atbalsta vairāku politiku izveidi, kopÄ“Å”anu, mantoÅ”anu, pārslēgÅ”anos starp politikām reāllaikā.
  • Atbalsta atseviŔķus politikas iestatÄ«jumus dažādiem tÄ«kla segmentiem (filiālēm)
  • Tie tiek izplatÄ«ti, izmantojot jebkuru pieejamo signāla kanālu starp kontrolieri un marÅ”rutētāju un/vai vSmart ā€” tie nav tieÅ”i atkarÄ«gi no datu plaknes savienojamÄ«bas starp marÅ”rutētājiem. Tas, protams, prasa IP savienojumu starp paÅ”u marÅ”rutētāju un kontrolieriem.

    Vai Cisco SD-WAN nogriezīs zaru, uz kura atrodas DMVPN?

  • GadÄ«jumos, kad visas pieejamās filiāles filiāles piedzÄ«vo ievērojamus datu zudumus, kas pārsniedz kritisko lietojumprogrammu pieļaujamos sliekŔņus, ir iespējams izmantot papildu mehānismus, kas palielina pārraides uzticamÄ«bu:
    • FEC (forward Error Correction) ā€“ izmanto Ä«paÅ”u lieku kodÄ“Å”anas algoritmu. Pārraidot kritisko trafiku pa kanāliem ar ievērojamu zaudējumu procentu, FEC var tikt automātiski aktivizēts un vajadzÄ«bas gadÄ«jumā ļauj atjaunot zaudēto datu daļu. Tas nedaudz palielina izmantoto pārraides joslas platumu, bet ievērojami uzlabo uzticamÄ«bu.

      Vai Cisco SD-WAN nogriezīs zaru, uz kura atrodas DMVPN?

    • Datu straumju dublÄ“Å”anās ā€“ Papildus FEC polise var paredzēt automātisku atlasÄ«to aplikāciju trafika dublÄ“Å”anu, ja rodas vēl nopietnāks zaudējumu lÄ«menis, ko FEC nevar kompensēt. Å ajā gadÄ«jumā atlasÄ«tie dati tiks pārsÅ«tÄ«ti pa visiem tuneļiem uz saņēmēju filiāli ar sekojoÅ”u dublÄ“Å”anas atcelÅ”anu (pakeÅ”u papildu kopiju nomeÅ”ana). Mehānisms ievērojami palielina kanālu izmantoÅ”anu, bet arÄ« ievērojami palielina pārraides uzticamÄ«bu.

Cisco SD-WAN iespējas bez tieÅ”iem analogiem DMVPN/PfR

Cisco SD-WAN risinājuma arhitektÅ«ra dažos gadÄ«jumos ļauj iegÅ«t iespējas, kuras ir vai nu ārkārtÄ«gi grÅ«ti ieviest DMVPN/PfR ietvaros, vai arÄ« ir nepraktiskas nepiecieÅ”amo darbaspēka izmaksu dēļ, vai arÄ« ir pilnÄ«gi neiespējamas. ApskatÄ«sim interesantākos no tiem:

Satiksmes inženierija (TE)

TE ietver mehānismus, kas ļauj satiksmei atzaroties pa standarta ceļu, ko veido marÅ”rutÄ“Å”anas protokoli. TE bieži izmanto, lai nodroÅ”inātu augstu tÄ«kla pakalpojumu pieejamÄ«bu, spēju ātri un/vai proaktÄ«vi pārsÅ«tÄ«t kritisko trafiku uz alternatÄ«vu (atdalÄ«tu) pārraides ceļu, lai nodroÅ”inātu labāku pakalpojuma kvalitāti vai atkopÅ”anas ātrumu kļūmes gadÄ«jumā. uz galvenā ceļa.

TE ievieÅ”anas grÅ«tÄ«bas ir saistÄ«tas ar nepiecieÅ”amÄ«bu iepriekÅ” aprēķināt un rezervēt (pārbaudÄ«t) alternatÄ«vu ceļu. Telekomunikāciju operatoru MPLS tÄ«klos Ŕī problēma tiek atrisināta, izmantojot tādas tehnoloÄ£ijas kā MPLS Traffic-Engineering ar IGP protokolu un RSVP protokola paplaÅ”inājumiem. Pēdējā laikā arvien populārāka ir kļuvusi arÄ« Segment Routing tehnoloÄ£ija, kas ir vairāk optimizēta centralizētai konfigurācijai un orÄ·estrÄ“Å”anai. Klasiskajos WAN tÄ«klos Ŕīs tehnoloÄ£ijas parasti nav pārstāvētas vai tiek reducētas lÄ«dz lēcienveida mehānismu izmantoÅ”anai, piemēram, uz politiku balstÄ«ta marÅ”rutÄ“Å”ana (PBR), kas spēj sazarot trafiku, bet ievieÅ” to katrā marÅ”rutētājā atseviŔķi, neizmantojot ņem vērā kopējo tÄ«kla stāvokli vai PBR rezultātu iepriekŔējās vai turpmākajās darbÄ«bās. Å o TE opciju izmantoÅ”anas rezultāts ir neapmierinoÅ”s - MPLS TE konfigurācijas un darbÄ«bas sarežģītÄ«bas dēļ parasti tiek izmantots tikai vissvarÄ«gākajā tÄ«kla daļā (kodolā), un PBR tiek izmantots atseviŔķiem marÅ”rutētājiem bez iespēja izveidot vienotu PBR politiku visam tÄ«klam. AcÄ«mredzot tas attiecas arÄ« uz tÄ«kliem, kuru pamatā ir DMVPN.

Vai Cisco SD-WAN nogriezīs zaru, uz kura atrodas DMVPN?

SD-WAN Å”ajā ziņā piedāvā daudz elegantāku risinājumu, kas ir ne tikai viegli konfigurējams, bet arÄ« daudz labāk mērogojams. Tas ir izmantotās vadÄ«bas plaknes un politikas plaknes arhitektÅ«ras rezultāts. Politikas plaknes ievieÅ”ana SD-WAN ļauj centralizēti definēt TE politiku ā€” kāda satiksme interesē? kuriem VPN? Caur kuriem mezgliem/tuneļiem ir nepiecieÅ”ams vai, tieÅ”i otrādi, aizliegts veidot alternatÄ«vu marÅ”rutu? Savukārt vadÄ«bas plaknes vadÄ«bas centralizācija, kuras pamatā ir vSmart kontrolleri, ļauj modificēt marÅ”rutÄ“Å”anas rezultātus, neizmantojot atseviŔķu ierīču iestatÄ«jumus ā€“ marÅ”rutētāji jau redz tikai tās loÄ£ikas rezultātu, kas tika Ä£enerēta vManage saskarnē un nodota lietoÅ”anai vSmart.

Pakalpojumu ķēde

Pakalpojumu ķēžu veidoÅ”ana klasiskajā marÅ”rutÄ“Å”anā ir vēl darbietilpÄ«gāks uzdevums nekā jau aprakstÄ«tais Satiksmes inženierijas mehānisms. PatieŔām, Å”ajā gadÄ«jumā ir nepiecieÅ”ams ne tikai izveidot Ä«paÅ”u marÅ”rutu konkrētai tÄ«kla lietojumprogrammai, bet arÄ« nodroÅ”ināt iespēju noņemt trafiku no tÄ«kla noteiktos (vai visos) SD-WAN tÄ«kla mezglos, lai to apstrādātu. Ä«paÅ”a lietojumprogramma vai pakalpojums (ugunsmÅ«ris, balansÄ“Å”ana, keÅ”atmiņa, pārbaudes trafiks utt.). Tajā paŔā laikā ir jāspēj kontrolēt Å”o ārējo pakalpojumu stāvokli, lai novērstu melnā holinga situācijas, kā arÄ« ir nepiecieÅ”ami mehānismi, kas ļauj izvietot Ŕādus viena veida ārējos pakalpojumus dažādās Ä£eogrāfiskās vietās. ar tÄ«kla iespēju automātiski izvēlēties optimālāko servisa mezglu konkrētas filiāles trafika apstrādei. Cisco SD-WAN gadÄ«jumā to ir diezgan viegli panākt, izveidojot atbilstoÅ”u centralizētu politiku, kas ā€œsalÄ«mēā€ visus mērÄ·a pakalpojumu ķēdes aspektus vienā veselumā un automātiski maina datu plaknes un vadÄ«bas plaknes loÄ£iku tikai tad, ja un kad nepiecieÅ”ams.

Vai Cisco SD-WAN nogriezīs zaru, uz kura atrodas DMVPN?

Iespēja izveidot Ä£eogrāfiski sadalÄ«tu atlasÄ«to lietojumprogrammu veidu trafika apstrādi noteiktā secÄ«bā specializētā (bet ne ar paÅ”u SD-WAN tÄ«klu saistÄ«tā) iekārtā, iespējams, ir visskaidrākais Cisco SD-WAN priekÅ”rocÄ«bu demonstrējums salÄ«dzinājumā ar klasisko. tehnoloÄ£ijas un pat daži alternatÄ«vi SD risinājumi -WAN no citiem ražotājiem.

Rezultāts?

AcÄ«mredzot gan DMVPN (ar vai bez veiktspējas marÅ”rutÄ“Å”anas), gan Cisco SD-WAN galu galā atrisina ļoti lÄ«dzÄ«gas problēmas saistÄ«bā ar organizācijas izplatÄ«to WAN tÄ«klu. Tajā paŔā laikā ievērojamas arhitektÅ«ras un funkcionālās atŔķirÄ«bas Cisco SD-WAN tehnoloÄ£ijā noved pie Å”o problēmu risināŔanas procesa. uz citu kvalitātes lÄ«meni. Rezumējot, mēs varam atzÄ«mēt Ŕādas bÅ«tiskas atŔķirÄ«bas starp SD-WAN un DMVPN/PfR tehnoloÄ£ijām:

  • DMVPN/PfR parasti izmanto laika pārbaudÄ«tas tehnoloÄ£ijas pārklājuma VPN tÄ«klu veidoÅ”anai un datu plaknes ziņā ir lÄ«dzÄ«gas modernākai SD-WAN tehnoloÄ£ijai, tomēr ir vairāki ierobežojumi obligātās statiskās konfigurācijas veidā. marÅ”rutētāju un topoloÄ£iju izvēle ir ierobežota ar Hub-n-Spoke. No otras puses, DMVPN/PfR ir dažas funkcijas, kas vēl nav pieejamas SD-WAN (mēs runājam par BFD katrai lietojumprogrammai).
  • VadÄ«bas plaknē tehnoloÄ£ijas bÅ«tiski atŔķiras. Ņemot vērā signalizācijas protokolu centralizēto apstrādi, SD-WAN jo Ä«paÅ”i ļauj ievērojami saÅ”aurināt kļūmju domēnus un ā€œatsaistÄ«tā€ lietotāja trafika pārsÅ«tÄ«Å”anas procesu no signalizācijas mijiedarbÄ«bas - kontrolieru Ä«slaicÄ«ga nepieejamÄ«ba neietekmē spēju pārraidÄ«t lietotāja trafiku. . Tajā paŔā laikā jebkuras filiāles (arÄ« centrālās) Ä«slaicÄ«ga nepieejamÄ«ba nekādā veidā neietekmē citu filiāļu spēju mijiedarboties savā starpā un kontrolieriem.
  • ArÄ« trafika pārvaldÄ«bas politiku veidoÅ”anas un piemēroÅ”anas arhitektÅ«ra SD-WAN gadÄ«jumā ir pārāka par DMVPN/PfR - Ä£eogrāfiskā rezervācija ir daudz labāk ieviesta, nav savienojuma ar centrmezglu, ir lielākas naudas soda iespējas -skaņoÅ”anas politikas, arÄ« ieviesto satiksmes pārvaldÄ«bas scenāriju saraksts ir daudz lielāks.
  • ArÄ« risinājuma orÄ·estrÄ“Å”anas process bÅ«tiski atŔķiras. DMVPN pieņem iepriekÅ” zināmu parametru klātbÅ«tni, kas kaut kādā veidā jāatspoguļo konfigurācijā, kas nedaudz ierobežo risinājuma elastÄ«bu un dinamisku izmaiņu iespēju. Savukārt SD-WAN pamatā ir paradigma, ka sākotnējā savienojuma brÄ«dÄ« marÅ”rutētājs ā€œneko nezinaā€ par saviem kontrolieriem, bet zina, ā€œkam var jautātā€ ā€“ ar to pietiek ne tikai, lai automātiski izveidotu saziņu ar kontrolieriem, bet arÄ« automātiski veidot pilnÄ«bā savienotu datu plaknes topoloÄ£iju, ko pēc tam var elastÄ«gi konfigurēt/mainÄ«t, izmantojot politikas.
  • Paredzams, ka centralizētās pārvaldÄ«bas, automatizācijas un uzraudzÄ«bas ziņā SD-WAN pārspēs DMVPN/PfR iespējas, kas ir attÄ«stÄ«juŔās no klasiskajām tehnoloÄ£ijām un vairāk paļaujas uz CLI komandrindu un uz veidnēm balstÄ«tu NMS sistēmu izmantoÅ”anu.
  • SD-WAN, salÄ«dzinot ar DMVPN, droŔības prasÄ«bas ir sasnieguÅ”as citu kvalitatÄ«vu lÄ«meni. Galvenie principi ir nulles uzticamÄ«ba, mērogojamÄ«ba un divu faktoru autentifikācija.

Å ie vienkārÅ”ie secinājumi var radÄ«t nepareizu iespaidu, ka tÄ«kla izveide, pamatojoties uz DMVPN/PfR, mÅ«sdienās ir zaudējusi savu nozÄ«mi. Tas, protams, nav pilnÄ«gi taisnÄ«ba. Piemēram, gadÄ«jumos, kad tÄ«klā tiek izmantots daudz novecojuÅ”u iekārtu un nav iespējas to nomainÄ«t, DMVPN var ļaut apvienot ā€œvecāsā€ un ā€œjaunāsā€ ierÄ«ces vienā Ä£eogrāfiski sadalÄ«tā tÄ«klā ar daudzām no aprakstÄ«tajām priekÅ”rocÄ«bām. virs.

No otras puses, jāatceras, ka visi paÅ”reizējie Cisco korporatÄ«vie marÅ”rutētāji, kuru pamatā ir IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v), Å”odien atbalsta jebkuru darbÄ«bas režīmu - gan klasisko marÅ”rutÄ“Å”anu, gan DMVPN un SD-WAN - izvēli nosaka aktuālās vajadzÄ«bas un izpratne, ka jebkurā brÄ«dÄ«, izmantojot vienu un to paÅ”u aprÄ«kojumu, var sākt virzÄ«ties uz progresÄ«vākām tehnoloÄ£ijām.

Avots: www.habr.com

Pievieno komentāru