Mun Cisco SD-WAN skera af greininni sem DMVPN situr á?

Síðan í ágúst 2017, þegar Cisco keypti Viptela, hefur helsta tæknin sem boðið er upp á til að skipuleggja dreifð fyrirtækjanet orðið Cisco SD-WAN. Undanfarin 3 ár hefur SD-WAN tæknin gengið í gegnum margar breytingar, bæði eigindlegar og megindlegar. Þannig hefur virknin aukist verulega og stuðningur hefur birst á klassískum beinum í seríunni Cisco ISR 1000, ISR 4000, ASR 1000 og Virtual CSR 1000v. Á sama tíma halda margir Cisco viðskiptavinir og samstarfsaðilar áfram að velta fyrir sér: hver er munurinn á Cisco SD-WAN og þegar kunnuglegum aðferðum byggðar á tækni eins og Cisco DMVPN и Cisco Performance Routing og hversu mikilvægur er þessi munur?

Hér ættum við strax að gera fyrirvara um að áður en SD-WAN kom til sögunnar í Cisco eignasafninu, myndaði DMVPN ásamt PfR lykilhluta í arkitektúrnum Cisco IWAN (Intelligent WAN), sem aftur var forveri fullgildrar SD-WAN tækni. Þrátt fyrir almenna líkindi bæði verkefna sem verið er að leysa og aðferða við að leysa þau fékk IWAN aldrei það stig sjálfvirkni, sveigjanleika og sveigjanleika sem nauðsynleg er fyrir SD-WAN og með tímanum hefur þróun IWAN minnkað verulega. Á sama tíma hefur tæknin sem mynda IWAN ekki horfið og margir viðskiptavinir halda áfram að nota hana með góðum árangri, þar á meðal á nútíma búnaði. Fyrir vikið hefur áhugaverð staða skapast - sami Cisco búnaður gerir þér kleift að velja heppilegustu WAN tæknina (klassíska, DMVPN+PfR eða SD-WAN) í samræmi við kröfur og væntingar viðskiptavina.

Greinin ætlar ekki að greina í smáatriðum alla eiginleika Cisco SD-WAN og DMVPN tækni (með eða án árangursleiðar) - það er mikið magn af tiltækum skjölum og efni fyrir þetta. Meginverkefnið er að reyna að meta lykilmuninn á þessari tækni. En áður en farið er að ræða þennan mun skulum við rifja upp tæknina sjálfa í stuttu máli.

Hvað er Cisco DMVPN og hvers vegna er þörf á því?

Cisco DMVPN leysir vandamálið við kraftmikla (= stigstærð) tengingu ytra útibúanets við net aðalskrifstofu fyrirtækis þegar notaðar eru handahófskenndar tegundir samskiptaleiða, þar á meðal internetið (= með dulkóðun á samskiptarásinni). Tæknilega er þetta gert að veruleika með því að búa til sýndarvædd yfirborðsnet af L3 VPN flokki í punkt-til-margpunkta ham með rökréttri staðfræði af „Star“ gerð (Hub-n-Spoke). Til að ná þessu notar DMVPN blöndu af eftirfarandi tækni:

• IP leiðsögn
• Multipoint GRE göng (mGRE)
• Next Hop Resolution Protocol (NHRP)
• IPSec Crypto snið

Hverjir eru helstu kostir Cisco DMVPN samanborið við klassíska leið með MPLS VPN rásum?

• Til að búa til milligreinanet er hægt að nota hvaða samskiptaleiðir sem er - allt sem getur veitt IP-tengingu milli útibúa hentar, en umferðin verður dulkóðuð (þar sem nauðsyn krefur) og jafnvægi (þar sem hægt er)
• Fulltengd staðfræði milli útibúa myndast sjálfkrafa. Á sama tíma eru kyrrstæð göng á milli miðlægu og fjarlægu útibúanna og kraftmikil göng á milli ytri útibúa (ef það er umferð)
• Beinar í miðlægum og fjarlægum útibúum eru með sömu uppsetningu upp að IP tölum viðmótanna. Með því að nota mGRE er engin þörf á að stilla tugi, hundruð eða jafnvel þúsundir jarðganga fyrir sig. Fyrir vikið ágætis stigstærð með réttri hönnun.

Hvað er Cisco Performance Routing og hvers vegna er þörf á henni?

Þegar DMVPN er notað á milliútibúaneti er ein afar mikilvæg spurning óleyst - hvernig á að meta ástand hvers og eins DMVPN ganganna á virkum hætti til að uppfylla kröfur um umferð sem eru mikilvægar fyrir fyrirtæki okkar og, aftur, byggt á slíku mati, gera á virkan hátt. ákvörðun um endurskipulagningu? Staðreyndin er sú að DMVPN í þessum hluta er lítið frábrugðinn klassískri leið - það besta sem hægt er að gera er að stilla QoS kerfi sem gerir þér kleift að forgangsraða umferð í útleið, en eru á engan hátt fær um að taka tillit til stöðu alla leiðina á einum tíma eða öðrum.

Og hvað á að gera ef rásin rýrnar að hluta og ekki alveg - hvernig á að greina og meta þetta? DMVPN sjálft getur ekki gert þetta. Með hliðsjón af því að rásirnar sem tengja útibú geta farið í gegnum gjörólík fjarskiptafyrirtæki, með því að nota allt aðra tækni, verður þetta verkefni afar léttvægt. Og þetta er þar sem Cisco Performance Routing tæknin kemur til bjargar, sem á þeim tíma hafði þegar farið í gegnum nokkur stig þróunar.

Verkefni Cisco Performance Routing (hér eftir PfR) snýst um að mæla stöðu slóða (göng) umferðar út frá lykilmælingum sem eru mikilvægar fyrir netforrit - leynd, breyting á leynd (jitter) og pakkatap (prósenta). Að auki er hægt að mæla notaða bandbreidd. Þessar mælingar eiga sér stað eins nálægt rauntíma og mögulegt er og á réttan hátt, og niðurstaða þessara mælinga gerir leiðinni sem notar PfR kleift að taka ákvarðanir á kraftmikinn hátt um nauðsyn þess að breyta leið á þessari eða hinni tegund umferðar.

Þannig er hægt að lýsa verkefni DMVPN/PfR samsetningar í stuttu máli sem hér segir:

• Leyfa viðskiptavinum að nota hvaða samskiptaleiðir sem er á WAN netinu
• Tryggja sem mest gæði mikilvægra forrita á þessum rásum

Hvað er Cisco SD-WAN?

Cisco SD-WAN er tækni sem notar SDN nálgunina til að búa til og reka WAN net stofnunarinnar. Þetta þýðir einkum notkun svokallaðra stýringa (hugbúnaðarþátta), sem veita miðlæga skipulagningu og sjálfvirka uppsetningu allra lausnarhluta. Ólíkt kanónískum SDN (Clean Slate stíl), notar Cisco SD-WAN nokkrar gerðir stýringa, sem hver um sig sinnir sínu hlutverki - þetta var vísvitandi gert til að veita betri sveigjanleika og landfræðilega offramboð.

Þegar um SD-WAN er að ræða er verkefnið að nota hvers kyns rásir og tryggja rekstur viðskiptaforrita það sama, en á sama tíma stækka kröfur um sjálfvirkni, sveigjanleika, öryggi og sveigjanleika slíks nets.

Umræða um ágreining

Ef við byrjum núna að greina muninn á þessari tækni, þá falla þær í einn af eftirfarandi flokkum:

• Byggingarfræðilegur munur - hvernig er aðgerðum dreift yfir ýmsa hluti lausnarinnar, hvernig er samspili slíkra íhluta skipulagt og hvernig hefur það áhrif á getu og sveigjanleika tækninnar?
• Virkni - hvað getur ein tækni gert sem önnur getur ekki? Og er það virkilega svona mikilvægt?

Hver er byggingarfræðilegur munur og er hann mikilvægur?

Hver þessara tækni hefur marga „hreyfanlega hluta“ sem eru ekki aðeins mismunandi í hlutverkum sínum, heldur einnig hvernig þeir hafa samskipti sín á milli. Hversu vel þessar meginreglur eru hugsaðar og almenn vélfræði lausnarinnar ákvarðar beinlínis sveigjanleika hennar, bilanaþol og heildarhagkvæmni.

Við skulum skoða hina ýmsu þætti arkitektúrsins nánar:

Gagna-plan – hluti af lausninni sem ber ábyrgð á að senda notendaumferð milli upprunans og viðtakandans. DMVPN og SD-WAN eru útfærð almennt eins á beinunum sjálfum byggt á Multipoint GRE göngum. Munurinn er hvernig nauðsynlegt sett af færibreytum fyrir þessi göng er myndað:

• в DMVPN/PfR er eingöngu tveggja stiga stigveldi hnúta með stjörnu eða Hub-n-Spoke svæðisfræði. Nauðsynlegt er að stilla upp kyrrstöðu miðstöðvarinnar og kyrrstöðubindingu Spoke við miðstöðina, auk samskipta í gegnum NHRP samskiptareglur til að mynda gagnaplanstengingu. Þar af leiðandi, gera breytingar á miðstöðinni verulega erfiðaritengist td breytingu/tengingu nýrra WAN rása eða breyta breytum þeirra sem fyrir eru.
• в SD WAN er fullkomlega kraftmikið líkan til að greina færibreytur uppsettra jarðganga byggt á stjórnplani (OMP samskiptareglum) og hljómsveitarplani (samskipti við vBond stjórnandi fyrir uppgötvun stjórnanda og NAT-flutningsverkefni). Í þessu tilviki er hægt að nota hvaða staðfræði sem er sett ofan á, þar með talið stigveldi. Innan viðurkenndra yfirlagsgönga svæðisfræði er sveigjanleg uppsetning á rökréttu svæðisfræði í hverju VPN(VRF) fyrir sig möguleg.

Stjórnarflugvél – skipti, síun og breytingu á leiðarlýsingu og öðrum upplýsingum milli lausnarhluta.

• в DMVPN/PfR – eingöngu framkvæmt á milli Hub og Spoke beina. Bein skipti á leiðarupplýsingum milli talsmanna er ekki möguleg. Þar af leiðandi, Án virkra miðstöðvar geta stjórnplanið og gagnaplanið ekki virkað, sem setur háar kröfur um aðgengi að miðstöðinni sem ekki er alltaf hægt að uppfylla.
• в SD WAN – stýriplan er aldrei framkvæmt beint á milli beina – samspil á sér stað á grundvelli OMP samskiptareglunnar og er endilega framkvæmt í gegnum sérstaka sérhæfða gerð vSmart stjórnanda, sem gefur möguleika á jafnvægi, landverndar og miðlægri stjórn á merki álag. Annar eiginleiki OMP samskiptareglunnar er veruleg viðnám hennar gegn tapi og óháð hraða samskiptarásarinnar við stýringar (innan skynsamlegra marka, auðvitað). Sem gerir þér kleift að staðsetja SD-WAN stýringar í opinberum eða einkaskýjum með aðgangi í gegnum internetið.

Stefna-plan – hluti af lausninni sem ber ábyrgð á að skilgreina, dreifa og beita umferðarstjórnunarstefnu á dreifðu neti.

• DMVPN – er í raun takmörkuð af gæðaþjónustu (QoS) reglum sem eru stilltar fyrir sig á hverri leið í gegnum CLI eða Prime Infrastructure sniðmát.
• DMVPN/PfR – PfR stefnur myndast á miðlægum Master Controller (MC) beini í gegnum CLI og síðan dreift sjálfkrafa til útibús MCs. Í þessu tilviki eru sömu stefnuflutningsleiðir notaðar og fyrir gagnaplanið. Enginn möguleiki er á að aðgreina skipti á stefnum, leiðarupplýsingum og notendagögnum. Útbreiðsla stefnu krefst tilvistar IP-tengingar á milli Hub og Spoke. Í þessu tilviki er hægt að sameina MC aðgerðina, ef nauðsyn krefur, við DMVPN bein. Það er mögulegt (en ekki krafist) að nota Prime Infrastructure sniðmát fyrir miðlæga stefnugerð. Mikilvægur eiginleiki er að stefnan er mótuð á heimsvísu um allt netið á sama hátt - Einstakar reglur fyrir einstaka hluta eru ekki studdar.
• SD WAN – umferðarstjórnun og gæðaþjónustustefnur eru ákvarðaðar miðlægt í gegnum grafíska viðmótið Cisco vManage, einnig aðgengilegt í gegnum internetið (ef nauðsyn krefur). Þeim er dreift í gegnum merkjarásir beint eða óbeint í gegnum vSmart stýringar (fer eftir tegund stefnu). Þeir eru ekki háðir gagnaflugstengingu milli beina, vegna þess að nota allar tiltækar umferðarleiðir á milli stjórnandans og beinisins.

  Fyrir mismunandi nethluta er hægt að móta mismunandi stefnur á sveigjanlegan hátt - umfang stefnunnar ræðst af mörgum einstökum auðkennum sem gefin eru upp í lausninni - útibúsnúmer, tegund umsóknar, umferðarstefnu osfrv.

Hljómsveitarflugvél - kerfi sem gerir íhlutum kleift að greina hver annan á virkan hátt, stilla og samræma síðari samskipti.

• в DMVPN/PfR Gagnkvæm uppgötvun milli beina byggist á kyrrstöðustillingu Hub-tækja og samsvarandi uppsetningu Spoke-tækja. Kvik uppgötvun á sér stað aðeins fyrir Spoke, sem tilkynnir Hub-tengingarfæribreytur sínar til tækisins, sem aftur er forstillt með Spoke. Án IP-tengingar milli Spoke og að minnsta kosti einnar Hub er ómögulegt að mynda annað hvort gagnaplan eða stjórnplan.
• в SD WAN skipulagning á íhlutum lausnar á sér stað með því að nota vBond stjórnandi, sem hver íhluti (beini og vManage/vSmart stýringar) verður fyrst að koma á IP tengingu við.

  Upphaflega vita íhlutirnir ekki um tengibreytur hvers annars - til þess þurfa þeir vBond milliliðasveitarmanninn. Almenna meginreglan er sem hér segir - hver hluti í byrjunarfasa lærir (sjálfvirkt eða kyrrstætt) aðeins um tengingarfæribreytur við vBond, síðan upplýsir vBond beini um vManage og vSmart stýringar (uppgötvuð fyrr), sem gerir það mögulegt að koma sjálfkrafa á fót allar nauðsynlegar merkjatengingar.

  Næsta skref er að nýi beininn læri um aðra beina á netinu í gegnum OMP samskipti við vSmart stjórnandann. Þannig getur beininn, án þess að vita neitt um netbreytur í upphafi, að fullu sjálfkrafa greint og tengt við stýringar og þá einnig sjálfkrafa greint og myndað tengingu við aðra beina. Í þessu tilviki eru tengibreytur allra íhluta óþekktar í upphafi og geta breyst meðan á notkun stendur.

Stjórnunarflugvél – hluti af lausninni sem veitir miðlæga stjórnun og eftirlit.

• DMVPN/PfR – Engin sérhæfð stjórnunarflugslausn er til staðar. Fyrir grunn sjálfvirkni og eftirlit er hægt að nota vörur eins og Cisco Prime Infrastructure. Hver leið hefur getu til að vera stjórnað í gegnum CLI skipanalínuna. Samþætting við ytri kerfi í gegnum API er ekki veitt.
• SD WAN – öll regluleg samskipti og eftirlit fer fram miðlægt í gegnum grafíska viðmót vManage stjórnandans. Allir eiginleikar lausnarinnar, án undantekninga, eru fáanlegir fyrir stillingar í gegnum vManage, sem og í gegnum fullkomlega skjalfest REST API bókasafn.

  Allar SD-WAN netstillingar í vManage koma niður á tveimur meginbyggingum - myndun tækjasniðmáta (Device Template) og myndun stefnu sem ákvarðar rökfræði netreksturs og umferðarvinnslu. Á sama tíma velur vManage, sem útvarpar stefnunni sem kerfisstjórinn býr til, sjálfkrafa hvaða breytingar og á hvaða einstökum tækjum/stýringum þarf að gera, sem eykur verulega skilvirkni og sveigjanleika lausnarinnar.

  Í gegnum vManage viðmótið er ekki aðeins uppsetning á Cisco SD-WAN lausninni í boði heldur einnig fullt eftirlit með stöðu allra íhluta lausnarinnar, allt að núverandi stöðu mæligilda fyrir einstök jarðgöng og tölfræði um notkun ýmissa forrita. byggt á DPI greiningu.

  Þrátt fyrir miðstýringu samskipta eru allir íhlutir (stýringar og beinar) einnig með fullvirka CLI skipanalínu, sem er nauðsynleg á innleiðingarstigi eða í neyðartilvikum fyrir staðbundna greiningu. Í venjulegri stillingu (ef það er merkjarás á milli íhluta) á beinum er skipanalínan aðeins tiltæk fyrir greiningu og er ekki tiltæk til að gera staðbundnar breytingar, sem tryggir staðbundið öryggi og eina uppspretta breytinga á slíku neti er vManage.

Innbyggt öryggi – hér erum við ekki aðeins að tala um vernd notendagagna þegar þau eru send um opnar rásir, heldur einnig um heildaröryggi WAN netsins sem byggir á völdum tækni.

• в DMVPN/PfR Það er hægt að dulkóða notendagögn og merkjasamskiptareglur. Þegar notaðar eru ákveðnar gerðir beina eru eldveggsaðgerðir með umferðarskoðun, IPS/IDS einnig fáanlegar. Það er hægt að skipta útibúaneti með VRF. Það er hægt að sannvotta (eins þátta) stjórnunarsamskiptareglur.

  Í þessu tilviki er ytri beininn sjálfgefið talinn traustur þáttur netsins - þ.e. Ekki er gert ráð fyrir eða tekið tillit til tilvika um líkamlega málamiðlun einstakra tækja og möguleika á óviðkomandi aðgangi að þeim; það er engin tvíþætt auðkenning á lausnarhlutum, sem þegar um er að ræða landfræðilega dreift netkerfi getur haft í för með sér verulega viðbótaráhættu.

• в SD WAN á hliðstæðan hátt við DMVPN er getu til að dulkóða notendagögn veitt, en með verulega auknu netöryggi og L3/VRF skiptingaraðgerðum (eldvegg, IPS/IDS, URL síun, DNS síun, AMP/TG, SASE, TLS/SSL proxy, o.s.frv.) d.). Á sama tíma er skipt á dulkóðunarlykla framkvæmt á skilvirkari hátt í gegnum vSmart stýringar (frekar en beint), í gegnum fyrirfram staðfestar merkjarásir sem verndaðar eru með DTLS/TLS dulkóðun byggðar á öryggisvottorðum. Sem aftur tryggir öryggi slíkra skipta og tryggir betri sveigjanleika lausnarinnar upp í tugþúsundir tækja á sama neti.

  Allar merkjatengingar (stýribúnaður-í-stýribúnaður, stjórnandi-beini) eru einnig verndaðar á grundvelli DTLS/TLS. Beinar eru búnir öryggisvottorðum við framleiðslu með möguleika á að skipta út/framlengja. Tveggja þátta auðkenning er náð með því að skyldu og samtímis uppfylla tvö skilyrði fyrir bein/stýringu til að virka í SD-WAN neti:

  • Gilt öryggisvottorð
  • Skýr og meðvituð skráning stjórnanda hvers íhluta á „hvíta“ listann yfir leyfð tæki.

Virkur munur á SD-WAN og DMVPN/PfR

Þegar farið er að ræða um hagnýtan mun, skal tekið fram að margir þeirra eru framhald af byggingarlistum - það er ekkert leyndarmál að þegar þeir mynda arkitektúr lausnar byrja verktaki frá þeim getu sem þeir vilja fá á endanum. Við skulum skoða mikilvægasta muninn á tækninni tveimur.

AppQ (Application Quality) – virkar til að tryggja gæði sendingar viðskiptaumferðar

Lykilhlutverk þeirrar tækni sem hér er til skoðunar miða að því að bæta notendaupplifun eins mikið og mögulegt er þegar viðskiptaþörf forrit eru notuð í dreifðu neti. Þetta er sérstaklega mikilvægt við aðstæður þar sem hluti innviðanna er ekki stjórnað af upplýsingatækni eða tryggir ekki einu sinni árangursríkan gagnaflutning.

DMVPN býður ekki sjálft upp á slíkar aðferðir. Það besta sem hægt er að gera í klassísku DMVPN neti er að flokka útleið eftir forriti og forgangsraða henni þegar hún er send í átt að WAN rásinni. Val á DMVPN göngum ræðst í þessu tilviki eingöngu af framboði þess og niðurstöðu af rekstri leiðarsamskiptareglur. Á sama tíma er ekki tekið tillit til enda-til-enda ástands slóðarinnar/ganganna og hugsanlegrar niðurbrots þess að hluta hvað varðar lykilmælikvarða sem skipta máli fyrir netforrit - seinkun, seinkun breytileika (jitter) og tap (% ). Í þessu sambandi missir það alla merkingu að bera saman klassískt DMVPN við SD-WAN hvað varðar lausn AppQ vandamála - DMVPN getur ekki leyst þetta vandamál. Þegar þú bætir Cisco Performance Routing (PfR) tækni inn í þetta samhengi breytist ástandið og samanburðurinn við Cisco SD-WAN verður þýðingarmeiri.

Áður en við ræðum muninn er hér stutt yfirlit yfir hvernig tæknin er svipuð. Svo, bæði tækni:

• hafa vélbúnað sem gerir þér kleift að meta ástand hvers stofnaðs jarðganga á virkan hátt með tilliti til ákveðinna mælikvarða - að minnsta kosti seinkun, seinkun og pakkatap (%)
• nota tiltekið sett af verkfærum til að móta, dreifa og beita umferðarstjórnunarreglum (stefnu), að teknu tilliti til niðurstaðna mælinga á stöðu lykilmælinga í jarðgöngum.
• flokka forritaumferð á stigum L3-L4 (DSCP) af OSI líkaninu eða með L7 forritaundirskriftum sem byggjast á DPI vélbúnaði sem er innbyggður í beininn
• Fyrir mikilvæg forrit leyfa þeir þér að ákvarða ásættanleg þröskuldsgildi mæligilda, reglur um að senda umferð sjálfgefið og reglur um að endurleiða umferð þegar farið er yfir þröskuldsgildi.
• Þegar þeir hjúpa umferð í GRE/IPSec nota þeir þegar komið er fyrir iðnaðarkerfi til að flytja innri DSCP merkingar yfir á ytri GRE/IPSEC pakkahausinn, sem gerir kleift að samstilla QoS stefnu fyrirtækisins og fjarskiptafyrirtækisins (ef það er viðeigandi SLA) .

Hvernig eru SD-WAN og DMVPN/PfR mæligildi frá enda til enda mismunandi?

DMVPN/PfR

• Bæði virkir og óvirkir hugbúnaðarskynjarar (Probes) eru notaðir til að meta staðlaðar göngheilsumælingar. Virkar eru byggðar á umferð notenda, óvirkar líkja eftir slíkri umferð (í fjarveru hennar).
• Það er engin fínstilling á tímamælum og niðurbrotsskynjunarskilyrðum - reikniritið er fast.
• Að auki er hægt að mæla notaða bandbreidd í útleið. Sem bætir auka sveigjanleika í umferðarstjórnun við DMVPN/PfR.
• Á sama tíma treysta sumir PfR kerfi, þegar farið er yfir mæligildi, á endurgjöf merkja í formi sérstakra TCA (Threshold Crossing Alert) skilaboða sem verða að koma frá viðtakanda umferðar í átt að upprunanum, sem aftur gerir ráð fyrir að ástand mældar rásir ættu að minnsta kosti að duga til að senda slík TCA skilaboð. Sem í flestum tilfellum er ekki vandamál, en augljóslega ekki hægt að tryggja.

SD WAN

• Fyrir end-til-enda mat á stöðluðum jarðgöngumælingum er BFD samskiptareglan notuð í bergmálsham. Í þessu tilviki er ekki krafist sérstakrar endurgjöf í formi TCA eða svipuð skilaboð - einangrun bilunarléna er viðhaldið. Það þarf heldur ekki tilvist notendaumferðar til að meta ástand ganganna.
• Það er hægt að fínstilla BFD tímamæla til að stjórna viðbragðshraða og næmni reikniritsins fyrir niðurbroti samskiptarásarinnar frá nokkrum sekúndum í mínútur.

  

• Þegar þetta er skrifað er aðeins ein BFD fundur í hverjum göngum. Þetta skapar hugsanlega minni nákvæmni í greiningu jarðganga. Í raun og veru getur þetta aðeins orðið takmörkun ef þú notar WAN tengingu sem byggir á MPLS L2/L3 VPN með samþykktu QoS SLA - ef DSCP merking BFD umferðar (eftir hjúpun í IPSec/GRE) passar við forgangsröðina í net fjarskiptafyrirtækisins, þá getur þetta haft áhrif á nákvæmni og hraða niðurbrotsgreiningar fyrir umferð með lágan forgang. Á sama tíma er hægt að breyta sjálfgefnum BFD merkingum til að draga úr hættu á slíkum aðstæðum. Í framtíðarútgáfum af Cisco SD-WAN hugbúnaði er gert ráð fyrir fínstilltum BFD stillingum, sem og getu til að ræsa margar BFD lotur í sömu göngunum með einstökum DSCP gildum (fyrir mismunandi forrit).
• BFD gerir þér að auki kleift að áætla hámarks pakkastærð sem hægt er að senda í gegnum tiltekin göng án sundrunar. Þetta gerir SD-WAN kleift að stilla breytur eins og MTU og TCP MSS Adjust á virkan hátt til að nýta tiltæka bandbreidd á hverjum hlekk.
• Í SD-WAN er möguleiki á QoS samstillingu frá fjarskiptafyrirtækjum einnig í boði, ekki aðeins byggt á L3 DSCP sviðum, heldur einnig byggt á L2 CoS gildum, sem hægt er að búa til sjálfkrafa í útibúaneti með sérhæfðum tækjum - td IP síma

Hvernig eru hæfileikar, aðferðir við að skilgreina og beita AppQ stefnum mismunandi?

DMVPN/PfR reglur:

• Skilgreint á miðlægum útibúbeini í gegnum CLI skipanalínuna eða CLI stillingarsniðmát. Að búa til CLI sniðmát krefst undirbúnings og þekkingar á setningafræði stefnu.

  

• Skilgreind á heimsvísu án möguleika á einstakri uppsetningu/breytingu á kröfum einstakra nethluta.
• Gagnvirk stefnugerð er ekki veitt í myndræna viðmótinu.
• Ekki er hægt að rekja breytingar, arfleifð og búa til margar útgáfur af reglum til að skipta fljótt.
• Dreift sjálfkrafa til beina fjarlægra útibúa. Í þessu tilviki eru sömu samskiptaleiðir notaðar og til að senda notendagögn. Ef engin samskiptarás er á milli miðlægs og fjarlægs útibús er dreifing/breyting á stefnu ómöguleg.
• Þær eru notaðar á hvern bein og, ef nauðsyn krefur, breyta niðurstöðum staðlaðra leiðarferla, með hærri forgang.
• Fyrir tilvik þar sem allir WAN-tenglar útibúa verða fyrir verulegu umferðartapi, engin bótakerfi veitt.

SD-WAN reglur:

• Skilgreint í vManage GUI í gegnum gagnvirka sniðmátshjálpina.
• Styður að búa til margar stefnur, afrita, erfa, skipta á milli reglna í rauntíma.
• Styður einstakar stefnustillingar fyrir mismunandi nethluta (útibú)
• Þeim er dreift með hvaða tiltæku merkjarás sem er á milli stjórnandans og beinisins og/eða vSmart - er ekki beint háð gagnaflugstengingunni milli beina. Þetta krefst auðvitað IP-tengingar á milli beinisins sjálfs og stjórnendanna.

  

• Fyrir tilvik þar sem allar tiltækar útibú útibús verða fyrir verulegu gagnatapi sem fer yfir viðunandi viðmiðunarmörk fyrir mikilvæg forrit, er hægt að nota viðbótaraðferðir sem auka flutningsáreiðanleika:
  • FEC (Forward Error Correction) - notar sérstakt óþarfa kóðaalgrím. Þegar mikilvæg umferð er send yfir rásir með verulegu hlutfalli af tapi er hægt að virkja FEC sjálfkrafa og gerir, ef nauðsyn krefur, kleift að endurheimta týnda hluta gagnanna. Þetta eykur aðeins notaða flutningsbandbreidd, en bætir verulega áreiðanleika.

    

  • Fjölföldun gagnastrauma – Auk FEC getur stefnan kveðið á um sjálfvirka fjölföldun á umferð valinna forrita ef um er að ræða enn alvarlegra tap sem FEC getur ekki bætt. Í þessu tilviki verða völdu gögnin send í gegnum öll göng í átt að móttökuútibúinu með síðari af-afritun (sleppa aukaafritum af pökkum). Vélbúnaðurinn eykur verulega nýtingu rása, en eykur einnig flutningsáreiðanleika verulega.

Cisco SD-WAN getu, án beinna hliðstæða í DMVPN/PfR

Arkitektúr Cisco SD-WAN lausnarinnar gerir þér í sumum tilfellum kleift að fá getu sem annað hvort er mjög erfitt í framkvæmd innan DMVPN/PfR, eða er óframkvæmanlegt vegna tilskilins launakostnaðar, eða er algjörlega ómögulegt. Við skulum líta á áhugaverðustu þeirra:

Umferðarverkfræði (TE)

TE inniheldur kerfi sem gerir umferð kleift að kvísla frá stöðluðu leiðinni sem myndast af leiðarsamskiptareglum. TE er oft notað til að tryggja mikið framboð á netþjónustu, með því að hægt sé að flytja mikilvæga umferð fljótt og/eða með fyrirbyggjandi hætti yfir á aðra (ósamstæða) flutningsleið, til að tryggja betri þjónustugæði eða hraða endurheimts ef bilun kemur upp. á aðalstígnum.

Erfiðleikarnir við að innleiða TE liggja í nauðsyn þess að reikna út og panta (athugaðu) aðra leið fyrirfram. Í MPLS netum fjarskiptafyrirtækja er þetta vandamál leyst með tækni eins og MPLS Traffic-Engineering með framlengingu á IGP samskiptareglum og RSVP samskiptareglum. Einnig nýlega hefur Segment Routing tækni, sem er fínstilltari fyrir miðlæga uppsetningu og hljómsveit, orðið sífellt vinsælli. Í klassískum WAN netkerfum er þessi tækni venjulega ekki sýnd eða hún minnkar við notkun hopp-fyrir-hopp aðferða eins og Policy-Based Routing (PBR), sem eru fær um að dreifa umferð, en innleiða þetta á hvern bein fyrir sig - án þess að taka tekið tillit til heildarástands netkerfisins eða PBR niðurstöðu í fyrri eða síðari skrefum. Niðurstaðan af því að nota þessa TE valkosti veldur vonbrigðum - MPLS TE, vegna flókinnar uppsetningar og notkunar, er að jafnaði aðeins notað í mikilvægasta hluta netkerfisins (kjarna) og PBR er notað á einstökum beinum án getu til að búa til sameinaða PBR stefnu fyrir allt netið. Augljóslega á þetta einnig við um DMVPN-undirstaða net.

SD-WAN í þessu sambandi býður upp á miklu glæsilegri lausn sem er ekki aðeins auðvelt að stilla, heldur mælir hún mun betur. Þetta er afleiðing af stjórnplaninu og stefnuplaninu sem notað er. Innleiðing stefnuplans í SD-WAN gerir þér kleift að skilgreina TE stefnu miðlægt - hvaða umferð er áhugaverð? fyrir hvaða VPN? Um hvaða hnúta/göng er nauðsynlegt eða öfugt bannað að mynda aðra leið? Aftur á móti gerir miðstýring stjórnunarflugvélar sem byggir á vSmart stýringar þér kleift að breyta leiðarniðurstöðum án þess að grípa til stillinga einstakra tækja - beinar sjá nú þegar aðeins niðurstöður rökfræðinnar sem var mynduð í vManage viðmótinu og flutt til notkunar til vSmart.

Þjónustukeðja

Að mynda þjónustukeðjur er enn vinnufrekara verkefni í klassískri leiðaráætlun en þegar lýst er um umferðarverkfræði. Reyndar, í þessu tilfelli, er ekki aðeins nauðsynlegt að búa til sérstaka leið fyrir tiltekið netforrit, heldur einnig til að tryggja getu til að fjarlægja umferð frá netinu á ákveðnum (eða öllum) hnútum SD-WAN netsins til vinnslu með sérstakt forrit eða þjónusta (eldveggur, jafnvægi, skyndiminni, skoðunarumferð osfrv.). Jafnframt er nauðsynlegt að geta stjórnað stöðu þessarar ytri þjónustu til að koma í veg fyrir svarthol, og einnig þarf aðgerðir sem gera kleift að setja slíka ytri þjónustu af sömu gerð á mismunandi landfræðilegum stöðum. með getu netkerfisins til að velja sjálfkrafa besta þjónustuhnútinn til að vinna úr umferð tiltekins útibús. Þegar um er að ræða Cisco SD-WAN er þetta frekar auðvelt að ná fram með því að búa til viðeigandi miðstýrða stefnu sem „límir“ alla þætti markþjónustukeðjunnar í eina heild og breytir sjálfkrafa rökfræði gagnaplans og stjórnplans aðeins þar sem og þegar þörf krefur.

Hæfni til að búa til landdreifða vinnslu umferðar valinna tegunda forrita í ákveðinni röð á sérhæfðum (en ekki tengdum SD-WAN netkerfinu sjálfu) búnaði er kannski skýrasta sýningin á kostum Cisco SD-WAN yfir klassískum tækni og jafnvel nokkrar aðrar SD lausnir -WAN frá öðrum framleiðendum.

Niðurstaðan?

Augljóslega, bæði DMVPN (með eða án árangursleiðar) og Cisco SD-WAN endar með því að leysa mjög svipuð vandamál í tengslum við dreift WAN net stofnunarinnar. Á sama tíma leiðir verulegur byggingar- og hagnýtur munur á Cisco SD-WAN tækni til þess að leysa þessi vandamál upp á annað gæðastig. Til að draga saman getum við tekið eftir eftirfarandi marktækum mun á SD-WAN og DMVPN/PfR tækni:

• DMVPN/PfR notar almennt tímaprófaða tækni til að byggja upp VPN netkerfi og, hvað varðar gagnaplan, eru þær svipaðar nútímalegri SD-WAN tækni, þó eru ýmsar takmarkanir í formi skyldubundinnar kyrrstöðustillingar af beinum og val á staðfræði er takmarkað við Hub-n-Spoke. Aftur á móti hefur DMVPN/PfR einhverja virkni sem er ekki enn fáanleg innan SD-WAN (við erum að tala um BFD fyrir hverja umsókn).
• Innan stjórnunarplansins er tæknin í grundvallaratriðum mismunandi. Að teknu tilliti til miðstýrðrar vinnslu merkjasamskiptareglna, gerir SD-WAN einkum kleift að þrengja verulega bilunarlén og „aftengja“ ferlið við að senda notendaumferð frá merkjasamskiptum - tímabundið skort á stjórnendum hefur ekki áhrif á getu til að senda notendaumferð . Á sama tíma hefur tímabundið óaðgengi hvers útibús (þar á meðal miðlægrar) ekki á nokkurn hátt áhrif á getu annarra útibúa til að hafa samskipti sín á milli og stjórnendur.
• Arkitektúrinn fyrir myndun og beitingu umferðarstjórnunarstefnu þegar um SD-WAN er að ræða er líka betri en í DMVPN/PfR - landfræðileg pöntun er miklu betur útfærð, það er engin tenging við miðstöðina, það eru fleiri tækifæri fyrir fínn -stillingarstefnur, listinn yfir innleiddar umferðarstjórnunarsviðsmyndir er líka miklu stærri.
• Skipulagningarferlið lausna er líka verulega frábrugðið. DMVPN gerir ráð fyrir að áður þekktar breytur séu til staðar sem verða að endurspeglast á einhvern hátt í uppsetningunni, sem takmarkar nokkuð sveigjanleika lausnarinnar og möguleika á kraftmiklum breytingum. Aftur á móti er SD-WAN byggt á þeirri hugmyndafræði að á fyrstu augnabliki tengingar „veiti beini ekkert“ um stýringar sínar, en veit „hvern þú getur spurt“ - þetta er nóg ekki aðeins til að koma á sjálfkrafa samskiptum við stýringarnar, en einnig til að mynda sjálfkrafa fulltengda gagnaplana svæðisfræði, sem síðan er hægt að stilla/breyta á sveigjanlegan hátt með því að nota stefnur.
• Hvað varðar miðlæga stjórnun, sjálfvirkni og eftirlit, er búist við að SD-WAN fari fram úr getu DMVPN/PfR, sem hafa þróast frá klassískri tækni og treysta meira á CLI skipanalínuna og notkun sniðmátsbundinna NMS kerfa.
• Í SD-WAN, samanborið við DMVPN, hafa öryggiskröfur náð öðru eigindlegu stigi. Meginreglurnar eru núlltraust, sveigjanleiki og tvíþætt auðkenning.

Þessar einföldu ályktanir geta gefið rangt til kynna að það að búa til net byggt á DMVPN/PfR hafi misst allt gildi í dag. Þetta er auðvitað ekki alveg satt. Til dæmis, í þeim tilvikum þar sem netið notar mikið af gamaldags búnaði og engin leið er að skipta um hann, getur DMVPN leyft þér að sameina „gömul“ og „ný“ tæki í eitt landdreift net með mörgum af þeim kostum sem lýst er. hér að ofan.

Á hinn bóginn skal hafa í huga að allir núverandi Cisco fyrirtækjabeinar sem byggjast á IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) styðja í dag hvaða rekstrarham sem er - bæði klassíska leið og DMVPN og SD-WAN - valið ræðst af núverandi þörfum og skilningi á því að hvenær sem er, með því að nota sama búnað, geturðu byrjað að stefna í átt að fullkomnari tækni.

Heimild: www.habr.com