Kas Cisco SD-WAN lõikab maha oksa, millel DMVPN istub?

Alates augustist 2017, mil Cisco omandas ettevõtte Viptela, on organisatsiooni jaotatud ettevõttevõrkude peamiseks tehnoloogiaks saanud Cisco SD-WAN. Viimase kolme aastaga on SD-WAN tehnoloogia läbi teinud palju muudatusi, nii kvalitatiivseid kui ka kvantitatiivseid. Funktsionaalsed võimalused on oluliselt laienenud ning klassikalistele marsruuteritele on lisandunud tugi seeriatest Cisco ISR 1000, ISR 4000, ASR 1000 ja virtuaalne CSR 1000v. Samal ajal jätkavad paljud Cisco kliendid ja partnerid endalt küsimisega - milles seisnevad Cisco SD-WAN-i erinevused juba tuntud lähenemistest, mis põhinevad sellistel tehnoloogiatel nagu Cisco DMVPN ja Cisco Performance Routing ja kui olulised need erinevused on?

Siin tuleks kohe märkida, et enne SD-WANi ilmumist Cisco portfelli, koosnes DMVPN koos PfR-iga peamisest osast Cisco IWAN (Intelligent WAN), mis omakorda oli täieõigusliku SD-WAN tehnoloogia eelkäija. Üldiselt on sarnasused nii lahendatavate probleemide kui ka nende lahendamise viiside osas olemas, ent IWAN ei saavutanud vajalikku SD-WANi taset automatiseerimises, paindlikkuses ja skaleeritavuses ning IWANi areng on aja jooksul oluliselt vähenenud. Samal ajal ei ole IWANi tehnoloogiad kadunud, ja paljud kliendid kasutavad neid edukalt ka tänapäevases varustuses. Tulemuseks on huvitav olukord - sama Cisco seadmed võimaldavad valida kõige sobivama tehnoloogia WAN-i ehitamiseks (klassikaline, DMVPN+PfR või SD-WAN) vastavalt klientide nõudmistele ja ootustele.

Artikkel ei paku põhjalikku ülevaadet kõigist Cisco SD-WAN ja DMVPN (koos või ilma Performance Routinguta) tehnoloogiate omadustest - selleks on saadaval tohutu hulk dokumente ja materjale. Peamine eesmärk on proovida hinnata nende tehnoloogiate põhilisi erinevusi. Kuid enne kui liigume nende erinevuste arutamisele, tuletame meelde, mis need tehnoloogiad üldse on.

Mis on Cisco DMVPN ja miks see vajalik on?

Cisco DMVPN lahendab kaugfiliaalide võrgu dünaamilise (=skaalautuva) ühendamise probleemi ettevõtte keskkontoriga, kasutades erinevaid kanalitüüpe, sealhulgas Internetti (=kanali krüpteerimisega). Tehniliselt saavutatakse see klassi L3 virtuaalse ülekandevõrgu loomisega. VPN punkt — mitme punkti režiimis (point-to-multipoint) loogilise „Täht“ (Hub-n-Spoke) topoloogiaga. Selleks kasutab DMVPN järgmiste tehnoloogiate kombinatsiooni:

• IP suunamine
• Multipoint GRE tunnelid (mGRE)
• Next Hop Resolution Protocol (NHRP)
• IPSec krüpto profiilid

Millised on peamised Cisco DMVPN eelised klassikalise suunamise ees MPLS VPN kanalite kasutamisel?

• Filiaalidevahelise võrgu loomiseks on võimalik kasutada kõiki sidekanaleid – sobib kõik, mis suudab tagada IP-ühenduse filiaalide vahel; samal ajal on liiklus krüpteeritud (kus vajalik) ja tasakaalustatud (kus võimalik).
• Kaugfiliaalide vahel kujuneb automaatselt täielikult ühendatud topoloogia. Samas on keskkontori ja kaugfiliaalide vahel staatilised tunnelid ning kaugfiliaalide vahel dünaamilised tunnelid nõudmise alusel (liikluse olemasolul).
• Keskkontori ja kaugfiliaali ruuterites on ühtne konfigureerimine, välja arvatud IP-aadresse liidestes. mGRE kasutamine elimineerib vajaduse kümnete, sada või isegi tuhande tunnelite individuaalse seadistamise järele. Selle tulemusena saavutatakse korralik skaleeritavus õige kujunduse juures.

Mis on Cisco Performance Routing ja milleks see vajalik on?

DMVPN-i kasutamisel filiaalidevahelises võrgus jääb lahendamatu üks äärmiselt oluline küsimus – kuidas hinnata dünaamiliselt iga DMVPN tunneli seisukorda, et see vastaks meie organisatsiooni kriitilise tähtsusega liikluse nõuetele ja samuti selle hindamise põhjal dünaamiliselt otsustada ümber suunamise üle? Asi on selles, et DMVPN ei erine selle osas oluliselt klassikalisest suunamisest – parim, mida teha saab, on seadistada QoS mehhanismid, mis võimaldavad andmeside suunda prioriseerida, kuid ei suuda arvestada kogu tee seisukorda mingil kindlal hetkel.

Ja mida teha, kui kanal osaliselt, mitte täielikult, halveneb – kuidas seda tuvastada ja hinnata? DMVPN ei oska seda iseenesest teha. Arvestades, et filiaalide vahelised kanalid võivad kulgeda täielikult erinevate sideoperaatorite kaudu, kasutades täiesti erinevaid tehnoloogiaid, muutub see ülesanne äärmiselt keeruliseks. Siin tuleb appi tehnoloogia Cisco Performance Routing, mis oli sel ajal läbinud mitmeid arenguetappe.

Cisco Performance Routing'i (edaspidi PfR) eesmärk on mõõta liiklusvoogude (tunnelite) seisundit, tuginedes võrgurakenduste jaoks olulistele võtmemõõdikutele – latentsus, latentsuse variatsioon (jitter) ja pakettide kaotus (protsentides). Täiendavalt võib mõõta kasutatud ribalaiust. Need mõõtmised toimuvad võimalikult reaalajas (nii palju kui see on võimalik ja põhjendatud) ning nende mõõtmiste tulemused võimaldavad marsruuteril, mis kasutab PfR-i, dünaamiliselt langetada otsuseid selle kohta, kas on vajalik muuta liiklusmarsruutimist.

Seega saab DMVPN/PfR kombinatsiooni ülesannet lühidalt iseloomustada järgmiselt:

• Lubada kliendil kasutada WAN-võrgus mis tahes sidekanaleid.
• Tagada võimalikult kõrge kvaliteet oluliste rakenduste jaoks nendel kanalitel.

Mis on Cisco SD-WAN?

Cisco SD-WAN on tehnoloogia, mis kasutab SDN lähenemist organisatsiooni WAN-võrgu loomisel ja haldamisel. See tähendab eelkõige hüüdnimede (tarkvarakomponentide) kasutamist, mis tagavad kõigi lahenduse komponentide tsentraliseeritud orkestreerimise ja automatiseeritud seadistamise. Erinevalt kanonilisest SDN-ist (Clean Slate stiilis) kasutab Cisco SD-WAN mitut tüüpi hüüdnime, millest igaühel on oma roll – see on tehtud kavatsusega tagada parem skaleeritavus ja georedundantssus.

SD-WAN-i puhul säilib ülesanne kasutada mis tahes tüüpi kanaleid ja tagada ärierakenduste töötamine, kuid samas laienevad nõuded automatiseerimisele, skaleeritavusele, turvalisusele ja paindlikkusele.

Arutelu erinevuste üle

Kui hakata nüüd analüüsima nende tehnoloogiate erinevusi, siis need langevad ühte järgmise kategooriasse:

• Arhitektuursed erinevused – kuidas on funktsioonid jaotatud erinevate lahenduse komponentide vahel, kuidas on need komponendid omavahel seotud ja kuidas see mõjutab tehnoloogia võimalusi ja paindlikkust?
• Funktsionaalsed võimalused – mida suudab üks tehnoloogia, mida teine ei suuda? Kas see on tõeliselt oluline?

Milles seisnevad arhitektuurilised erinevused ja kas need on tõeliselt olulised?

Igas nimetatud tehnoloogias on palju "liikuvaid osi", millel on erinevad rollid ja omavahelise suhtlemise põhimõtted. Sellest, kui läbimõeldud need põhimõtted on, sõltub lahenduse skalaarmahtus, tõrketaluvus ja üldine efektiivsus.

Vaatame arhitektuuri erinevaid aspekte põhjalikumalt:

Andmepink – lahenduse osa, mis vastutab kasutajate liikluse edastamise eest allikast saajani. DMVPN-i ja SD-WAN-i puhul rakendatakse seda üldiselt sarnasel viisil Multipoint GRE tunnelite põhjal. Erinevus seisneb selles, kuidas moodustatakse vajalike tunneliparametrite kogum:

• ja DMVPN/PfR – see on rangelt kahtasemeline sõlmede hierarhia, millel on "Täht" või Hub-n-Spoke topoloogia. Hubi staatiline seadistamine ja Spoke'i staatiline sidumine Hubiga on kohustuslik, samuti suhtlemine NHRP protokolli kaudu, et luua data-plane ühenduvus. Tagajärje tõttu, on Hubis muudatuste tegemine oluliselt keeruline, näiteks uute WAN-kanalite muutmise või ühendamise või olemasolevate parameetrite muutmisega.
• ja SD-WAN – see on täielikult dünaamiline mudel, mis tuvastab seatud tunnelite parameetrid, toetudes control-plane'ile (OMP protokoll) ja orchestration-plane'ile (koostöö vBond kontrolleriga, et tuvastada kontrollerid ja NAT traverst). Samuti võivad seatud topoloogiad olla mistahes, sealhulgas hierarhilised. Seoses seatud tunnelite katte topoloogiaga on igas eraldi VPN (VRF) võimalik paindlik loogilise topoloogia konfigureerimine.

Control-plane – funktsioonid teabe vahetamiseks, filtreerimiseks ja muutmiseks marsruudi ja muu informatsiooni vahel lahenduse komponentide vahel.

• ja DMVPN/PfR – toimub ainult Hub ja Spoke marsruuterite vahel. Otsene marsruudi teabe vahetamine Spoke vahel ei ole võimalik. Tagajärje tõttu, ilma toimiva Hubita ei saa control-plane ja data-plane töötada., mis see seab Hub'i täiendavad nõudmised kõrge kättesaadavuse osas, mida mitte alati ei ole võimalik täita.
• ja SD-WAN – control-plane'i vahetus ei toimu kunagi otse ruuterite vahel – suhtlemine toimub OMP protokolli alusel ja toimub kindlasti läbi eraldi spetsialiseeritud vSmart kontrolleri tüübi, mis tagab koormuse tasakaalustamise, georedundantsuse ja tsentraliseeritud juhtimise signaalikoormusele. Teine OMP protokolli omadus on selle märkimisväärne vastupidavus kaotustele ja sõltumatuse kontrollereid ühendava kanali kiirusest (mõistlikud piirid, muidugi). See võimaldab SD-WAN kontrollerite majutamist nii avalikes kui ka eraviisilistes pilvedes, mis on juurdepääsetavad Interneti kaudu.

Policy-plane – lahenduse osa, mis vastutab liiklusjuhtimise poliitikate määratlemise, levitamise ja rakendamise eest jaotatud võrgus.

• DMVPN – on tegelikult piiratud kvaliteedi poliitikatega (QoS), mis on kohandatud iga ruuteri jaoks eraldi läbi CLI või Prime Infrastructure'i mallide.
• DMVPN/PfR – PfR poliitikad loomisel toimub keskse ruuteri Master Controller (MC) kaudu CLI abil ja seejärel levitatakse need automaatselt harukontrolleritesse (MC). Sellisel juhul kasutatakse samu poliitikate edastamise teid nagu data-plane'is. Ei ole võimalik eraldada poliitikate, marsruutimise teabe ja kasutajate andmete vahetust. Poliitikate levitamine eeldab, et Hub'i ja Spoke'i vahel on kindlasti IP-ühendus. Samuti võib MC funktsiooni vajaduse korral kombineerida DMVPN ruuteriga. Mallide Prime Infrastructure kasutamine poliitikate tsentraliseeritud loomise jaoks on võimalik (kuid mitte vajalik). Oluline omadus – poliitika luuakse globaalsetelt kogu võrgu lõikes ühtlaselt – erakordsed poliitikad kindlate segmentide jaoks ei ole toetatud..
• SD-WAN – liiklust juhtimise ja teenuse kvaliteedi poliitikad määratakse keskelt läbi Cisco vManage graafilise liidese, mis on kergesti ligipääsetav ka Interneti kaudu, kui vajalik. Need levitatakse signaalikanalite kaudu otse või kaudselt vSmart kontrollerite kaudu (sõltub poliitika liigist). Need ei ole sõltuvad data-plane ühenduvusest marsruuterite vahel, kuna nad kasutavad kõiki olemasolevaid teid liikluse edastamiseks kontrolleri ja marsruuteri vahel.

  Erinevate võrgusegmentide jaoks on võimalik paindlikult vormida erinevaid poliitikaid – poliitika rakendusala määratakse paljude ainulaadsete identifikaatoritega, mis on lahenduses ette nähtud – filiaali number, rakenduse tüüp, liikluse suund jne.

Orkestreerimiskiht – mehhanismid, mis võimaldavad komponentidel dünaamiliselt üksteist avastada, seadistada ja koordineerida edasist koostööd.

• ja DMVPN/PfR marsruuterite vastastikune avastamine põhineb Hub seadmete staatilisel konfigureerimisel ning vastaval Spoke seadmete seadistusel. Dünaamiline avastamine toimub ainult Spoke jaoks, mis teatab oma ühenduse parameetritest Hub seadmele, mis on omakorda eelnevalt Spoke seadme konfiguratsiooni kantud. Ilma IP-ühenduvuseta vähemalt ühe Hubiga ei ole võimalik moodustada ei data-plane'i ega control-plane'i.
• ja SD-WAN lahenduse komponentide orkestreerimine toimub vBond kontrolleri abil, kellega igal komponendil (marsruuteritel ja vManage/vSmart kontrolleritel) on vajalik eelnevalt luua IP-ühendus.

  Alguses ei tea komponendid üksteise ühenduse parameetreid – selleks on neil vajalik vahendaja-orkestreerija vBond. Üksikasjalik põhimõte on järgmine – iga komponent esimeses faasis avastab (automaatselt või staatiliselt) ainult ühenduse parameetrid vBondiga, seejärel teatab vBond marsruuterile vManage ja vSmart kontrolleritest (eelnevalt avastatud), mis muudab kõik vajalikud signaalühendused automaatselt võimalikuks.

  Järgmiseks sammuks saab uus ruuter teada teistest ruuteritest võrgus OMP-vahetuse kaudu vSmart-kontrolleriga. Seega suudab ruuter, olles algselt teadaolevate võrguparametrite osas täielikult automaatselt avastada ja ühenduda kontrolleritega ning seejärel samuti automaatselt avastada ja luua ühenduse teiste ruuteritega. Samal ajal on kõigi komponentide ühenduse parameetrid algselt teadmata ja kasutamise käigus võivad need muutuda.

Halduse tasand – lahuse osa, mis tagab keskse halduse ja jälgimise.

• DMVPN/PfR – spetsialiseeritud halduse tasandi lahendust ei ole ette nähtud. Põhialuste automatiseerimise ja jälgimise jaoks on võimalik kasutada selliseid tooteid nagu Cisco Prime Infrastructure. Igal ruuteril on võimalus haldamiseks käsurea CLI kaudu. Integreerimist väliste süsteemidega API kaudu ei ole ette nähtud.
• SD-WAN – kogu vaikimisi suhtlemine ja jälgimine toimub tsentraliseeritult vManage kontrolleri graafilise liidese kaudu. Kõik lahenduse võimalused ilma eranditeta on saadaval seadistamiseks vManage'i kaudu, samuti täielikult dokumenteeritud REST API liidese kaudu.

  Kõik SD-WAN võrgu seadistused vManage'is koonduvad kahe põhistruktuuri – seadme mallide (Device Template) loomine ja poliitika loomine, mis määratleb võrgu ja traaditöötluse tööloogika. Samal ajal valib vManage, edastades administraatori määratud poliitika, automaatselt, milliseid muudatusi ja millistel individuaalsetel seadmetel/kontrolleritel on vaja teha, mis suurendab lahenduse efektiivsust ja skaleeritavust.

  VManage'i liidese kaudu on saadaval mitte ainult Cisco SD-WAN lahenduse seadistamine, vaid ka kõigi lahenduse komponentide täielik jälgimine, ulatudes isegi individuaalsete tunnelite hetkeoleku ja erinevate rakenduste kasutamise statistika jälgimiseni DPI-analüüsi põhjal.

  Hoolimata suhtlemise tsentraliseerimisest on kõigil komponentidel (kontrollerid ja ruuterid) ka täisfunktsionaalne käsurea liides CLI, mis on vajalik juurutamise etapis või erandolukordade korral kohaliku diagnostika jaoks. Tavalises režiimis (kui komponentide vahel on signaalikanal) on ruuteritel käsurea liides saadaval ainult diagnostikaks ning see ei ole kohalike muudatuste tegemiseks kergesti kättesaadav, mis tagab nii kohaliku turvalisuse kui ka ainus muudatusallika sellises võrgus – vManage.

Integreeritud turvalisus – see ei tähenda mitte ainult kasutajate andmete kaitset avatud kanalite kaudu edastamisel, vaid ka kogu WAN-võrgu üldist turvalisust valitud tehnoloogia alusel.

• ja DMVPN/PfR on ette nähtud kasutajate andmete ja signaaliprotokollide krüpteerimise võimalus. Teatud mudelite ruuterite kasutamisel on saadaval täiendavad tulemüürifunktsioonid koos liiklusinspektsiooniga, IPS/IDS. Filiaalide võrkude segmentimise võimalus VRF-i abil. On võimalik autentimine (ühe teguri) kontrollprotokollide jaoks.

  Sellega seoses peetakse kaugruuteri vaikimisi usaldusväärseks võrgu elemendiks – st ei arvestata füüsilise kompromiteerimise juhtumeid üksikute seadmete suhtes ja nende volitamata juurde pääsemise võimalusi, ei ole lahenduse komponentide jaoks kahefaktorilist autentimist, mis geograafiliselt jaotatud võrgus võib tuua tõsiseid täiendavaid riske.

• ja SD-WAN Nii nagu DMVPN-is, on ette nähtud kasutajate andmete krüpteerimise võimalus, kuid oluliselt laienenud võrgu turvalisuse ja L3/VRF segmentimise funktsioonidega (NAT, IPS/IDS, URL-filtreerimine, DNS-filtreerimine, AMP/TG, SASE, TLS/SSL proxy jne). Samuti toimub krüpteerimisvõtmete vahetus tõhusamalt vSmart kontrollerite kaudu (mitte otse), eelnevalt määratud signaalikanalites, mille on kaitsnud DTLS/TLS krüpteerimine, mis põhineb turbesertifikaatidel. See omakorda tagab sellise vahetuse turvalisuse ja võimaldab paremat lahenduse skaleeritavust isegi kümnete tuhandete seadmete jaoks ühes võrgus.

  Kõik signalisatsiooniseosed (controller-controller, controller-router) on samuti kaitstud DTLS/TLS alusel. Ruuterid on tootmisprotsessis varustatud turv Sertifikaatidega, võimalusega asendamiseks/uuendamiseks. Kahesüsteemne autentimine saavutatakse kahe tingimuse samal ajal ja kohustusliku täitmise kaudu, et ruuter/controller saaks SD-WAN võrgus funktsioneerida:

  • Kehtiv turv Sertifikaat
  • Administratori selge ja teadlik iga komponendi lisamine lubatud seadmete "valgesse nimekirja".

SD-WAN ja DMVPN/PfR funktsionaalsed erinevused

Funktsionaalsete erinevuste arutamisele minnes tuleb märkida, et paljuski on need jätk arhitektuurilistele – ei ole saladus, et lahenduse arhitektuuri loomisel lähtuvad arendajad nendest võimalustest, mida nad soovivad saavutada. Vaatame kaht tehnoloogiat nende kõige olulisemate erinevustega.

AppQ (Rakenduse Kvaliteet) – ärirakenduste liikluse kvaliteedi tagamise funktsioonid

Käsitletud tehnoloogiate võtmefunktsioonid on suunatud sellele, et parandada kasutajakogemust ärikliendiga kriitiliste rakenduste kasutamisel hajutatud võrgus. See on eriti oluline olukordades, kus osa infrastruktuurist ei ole IT kontrolli all või ei garanteeri isegi andmete edastamise sujuvust.

DMVPN ei paku iseseisvalt selliseid mehhanisme. Parim, mida klassikalises DMVPN võrgus teha, on klassifitseerida väljuv liiklus rakenduste järgi ja seada sellele edastamisel prioriteet WAN-kanali suunas. DMVPN tunneli valik sõltub sel juhul ainult selle kättesaadavusest ja marsruutimisprotokollide töötulemustest. Samuti ei arvestata läbipääsu/ tunneli olukorra seisu ja selle võimaliku osalise halvenemise osas, mis on olulised võrgurakenduste jaoks – viivituse, viivituse varieerimise (jitter) ja kaotuste (%). Seetõttu pole mõtet võrrelda klassikalist DMVPN-i SD-WAN-iga AppQ probleemide lahendamisel – DMVPN ei suuda seda ülesannet lahendada. Kui lisada sellesse konteksti tehnoloogia Cisco Performance Routing (PfR), siis olukord muutub ja võrrelemine Cisco SD-WAN-iga muutub mõistlikumaks.

Enne kui liigume eriomaduste arutamise juurde, räägime lühidalt tehnoloogiate sarnasusest. Nii et mõlemad tehnoloogiad:

• omavad mehhanismi, mis võimaldab dünaamiliselt hinnata iga seadistatud tunnelite seisundit määratud mõõdikute raames – minimaalsetena, viivituse, viivituse varieerumise ja pakettide kaotuse (%)
• kasutavad konkreetset tööriistade komplekti reeglite (poliitikate) loomiseks, levitamiseks ja rakendamiseks liikluse juhtimise, arvestades peamiste mõõdikute tunnelite seisundite mõõtmise tulemusi.
• klassifitseerivad rakenduste liiklust OSI mudeli L3-L4 (DSCP) tasemel või L7 rakenduste signatuuride alusel, tuginedes marsruuterisse integreeritud DPI mehhanismidele.
• lubavad märkimisväärsetele rakendustele määrata lubatud mõõdiku läviväärtused, vaikimisi liikluse edastamise reeglid, reeglid liikluse ümbermarsruutimise jaoks läviväärtuste ületamisel.
• tunnelite käguõhuks GRE/IPSec-i kaudu kapseldades kasutavad nad juba tööstuses kehtestatud mehhanismi sisemise DSCP märgistuse edastamiseks välisesse GRE/IPSEC-i paketi pealkirja, mis võimaldab kooskõlastada QoS poliitikaid organisatsiooni ja sideoperaatori vahel (olemasoleva SLAdel).

Kuidas erinevad SD-WAN-i ja DMVPN/PfR-i mehhanismid tunnelite mõõdikute hindamisest?

DMVPN/PfR

• Tunnelite seisundi standardsete mõõdikute hindamiseks kasutatakse nii aktiivseid kui ka passiivseid tarkvara andureid (Probes). Aktivsed - kasutaja liikluse põhjal, passiivsed emuleerivad sellist liiklust (kui seda pole).
• Ajastuse ja degradatsiooni avastamise tingimuste täpset seadistamist ei ole - algoritm on fikseeritud.
• Lisaks on saadaval edasise suuna kasutatava läbilaskevõime mõõtmine. Mis lisab DMVPN/PfR-ile liikluse juhtimisele täiendavat paindlikkust.
• Samas toetuvad mõned PfR mehhanismid metrikate ületamisel tagasiside signaalidele spetsiaalsete TCA (Threshold Crossing Alert) sõnumite kujul, mis peaksid tulema liikluse saajalt allika suunas, mis omakorda eeldab, et mõõdetud kanalite seisund peab olema vähemalt piisav, et edastada selliseid TCA-sõnumeid. See enamikul juhtudel ei ole probleem, kuid seda ei saa ilmtingimata garanteerida.

SD-WAN

• Tunnel'i standardsete mõõdikute pidevaks hindamiseks kasutatakse BFD protokolli echo-režiimis. Sellega ei ole vajalik eriline tagasiside TCA või sarnaste sõnumite näol – häirete domeenide isoleeritust hoitakse. Samuti ei nõuta kasutajaliikluse kohalolekut tunnel'i oleku hindamiseks.
• On võimalik peensusteni seadistada BFD taimerite reguleerimise kiirus ja tundlikkus kohandamisalgoritmile sidekanali degradeerumise osas, alates mõnedest sekunditest kuni minutiteni.

  

• Artikli kirjutamise ajal on iga tunnel'i jaoks ette nähtud ainult üks BFD sessioon. See võib potentsiaalselt tekitada väiksema granulaarsuse tunnel'i oleku analüüsimisel. Praktikas võib see piiranguks kujuneda vaid olukordades, kus kasutatakse MPLS L2/L3 VPN'i WAN-ühendust koos kokkulepitud QoS SLA-ga — kui BFD liikluse DSCP-markering (PDU pärast IPSec/GRE kapseldamist) langeb kokku kõrge prioriteediga järjekorraga operaatori võrgus, võib see mõjutada madala prioriteediga liikluse degradeerumise avastamise täpsust ja kiirus. Samuti on võimalik BFD vaike-markeroid muuta, et vähendada selliste olukordade tekkimise riski. Järgnevates Cisco SD-WAN tarkvara versioonides oodatakse BFD peenhäälestamise võimaluste ja mitme BFD sessiooni käivitamise võimaluste lisamist ühe tunnel'i raames eraldi DSCP-väärtustega (erinevate rakenduste jaoks).
• BFD võimaldab ka hinnata maksimaalset paketimahtu, mis on võimalik edastada ilma fragmenteerimiseta antud tunnel'is. See võimaldab SD-WAN'il dünaamiliselt seadistada selliseid parameetreid nagu MTU ja TCP MSS Adjust, et maksimaalselt efektiivselt kasutada igas kanalis saadaolevat läbilaskevõimet.
• SD-WAN'is on saadaval ka QoS sünkroniseerimise võimalus sideoperaatoritega mitte ainult L3 DSCP välja alusel, vaid ka L2 CoS väärtuste alusel, mis võivad automaatselt moodustuda haru võrgu spetsialiseeritud seadmete, näiteks IP telefonide, toimel.

Kuidas erinevad AppQ poliitikate määratlemise, määramise ja rakendamise võimalused?

DMVPN/PfR poliitikad:

• Määratletakse keskse filiaali ruuteris(ies) CLI käsurea või CLI konfiguratsiooni mallide kaudu. CLI mallide koostamine nõuab ettevalmistust ja poliitikate süntaksi tundmist.

  

• Määratakse globaalsetena ilma võimaluseta individuaalse kohandamise / muutmise jaoks, et vastata üksikute võrgusegmentide nõudmistele.
• Interaktiivne poliitikate loomine graafilises liideses ei ole ette nähtud.
• Muudatuste jälgimine, pärimine, mitme poliitika loomine kiireks vahetamiseks ei ole ette nähtud.
• Levitavad automaatselt kaufiliaalide ruutereid. Sel juhul kasutatakse samu sidekanaleid, mis on mõeldud kasutajate andmete edastamiseks. Kui sidekanalit kesk- ja kaufiliaali vahel ei ole, ei ole poliitikate levitamine / muutmine võimalik.
• Rakendatakse igas ruuteris ja vajadusel muudavad standardsete marsruutimise protokollide tulemusi, omades kõrgemat prioriteeti.
• Juhtudel, kui kõik filiaali WAN-kanalid kannatavad tõsiste liiklustaadete kaotuste all, kompenseerimise mehhanisme ei ole ette nähtud..

SD-WAN poliitikad:

• Määratakse graafilises liideses vManage interaktiivse mallimate abil.
• Toetavad mitme poliitika loomist, kopeerimist, pärimist, poliitikate vahel reaalajas vahetamist.
• Toetavad poliitika individuaalset kohandamist erinevate võrgusegmentide (filiaalide) jaoks.
• Levitavad, kasutades mis tahes saadaval olevat signaalikanalit kontrolleri ja ruuteri ning / või vSmart vahel - ei sõltu otseselt data-plane ühendatavusest ruuterite vahel. Sellega on siiski vajalik IP-ühenduvus ruuteri ja kontrollerite vahel.

  

• Juhtudel, kui kõik filiaali kätelolevad kanalid kannatavad tõsiste andmete kaotuste all, mis ületavad kriitiliste rakenduste näidatud läveväärtusi, võib kasutada täiendavaid mehhanisme, mis tõstavad edastamise usaldusväärsust:
  • FEC (Eeslane Vea Parandus) – kasutab spetsiaalset üleliigse kodeerimise algoritmi. Olulise liikluse edastamisel kanalite kaudu, kus on märkimisväärne kaotuste protsent, võib FEC automaatselt aktiveeruda ja mõnikord lubada kadunud andmete taastamist. Sellega tõuseb pisut kasutatav ribalaius, kuid usaldusväärsus suureneb märkimisväärselt.

    

  • Andmevoogude dubleerimine – lisaks FEC poliitika võib ette näha valitud rakenduste liikluse automaatset dubleerimist juhtudel, kui esinevad tõsisemad kaotused, mida FEC abil ei õnnestu kompenseerida. Sellisel juhul edastatakse valitud andmed kõikide tunnelite kaudu vastuvõtja filiaali, järgneb de-dubleerimine (lisakoopiate eemaldamine). Selline mehhanism suurendab oluliselt kanalite kasutamist, kuid samas märgatavalt tõstab ülekande usaldusväärsust.

Cisco SD-WAN võimalused, millel ei ole otseseid analooge DMVPN\/PfR

Cisco SD-WAN lahenduse arhitektuur võimaldab mõnel juhul saavutada selliseid võimalusi, mille rakendamine DMVPN\/PfR raames on kas äärmiselt keeruline, ebaotstarbekas suure töökoormuse tõttu või isegi võimatu. Vaatame kõige huvitavamaid neist:

Traffic-Engineering (TE)

TE hõlmab mehhanisme, mis võimaldavad suunata liiklust standardsetelt teedelt, mida kujundavad marsruutimise protokollid. TE-d kasutatakse sageli võrguteenuste kõrge kättesaadavuse tagamiseks, võimaldades kiiresti ja\/või eelnevalt suunata olulised liiklus alternatiivsete (mitteülenevate) edastusviiside kaudu, et tagada parema teenuse kvaliteedi või kiirus taastumise korral, kui peamisel teel esinevad tõrked.

TE rakendamise keerukus seisneb vajaduses eelnevalt arvutada ja reserveerida (kontrollida) alternatiivne rada. Telekommunikatsiooni MPLS võrkudes lahendavad operaatorid selle probleemi tehnoloogiate, nagu MPLS Traffic-Engineering koos IGP protokollide ja RSVP protokollide laiendustega. Viimasel ajal on järjest enam populaarsust kogumas tehnoloogia Segment Routing, mis on rohkem optimeeritud tsentraliseeritud seadistamiseks ja orkestreerimiseks. Traditsioonilistes WAN-võrkudes ei ole need tehnoloogiad tavaliselt esindatud või on need viidud minimaalseteks lahendusteks, nagu hop-by-hop mehhanismid nagu Policy-Based Routing (PBR), mis suudavad suunata liiklust, kuid teevad seda igas marsruuteris eraldi – arvestamata võrgu üldist seisundit ega PBR tulemusi eelmistel või järgmistel sammudel. Nende TE variantide rakendamise tulemus on pettumus – MPLS TE keerukuse tõttu seadistamisel ja haldamisel kasutatakse seda tavaliselt ainult võrgu kõige kriitilisemas osas (tuumik), samas kui PBR-i kasutatakse üksikutes marsruuterites ilma võimaluseta luua mingit ühtset PBR poliitikat kogu võrgus. Ilmselgelt puudutab see ka DMVPN-põhiseid võrke.

SD-WAN pakub selles osas palju elegantsimat lahendust, mis on mitte ainult lihtne seadistada, vaid ka märgatavalt paremini skaleeritav. See on tulemus kasutatud control-plane ja policy-plane arhitektuuridest. Policy-plane rakendamine SD-WAN-is võimaldab tsentraliseeritud viisil määrata TE poliitikat – millist liiklust on oluline? milliste VPN-ide jaoks? mille kaudu tuleb moodustada alternatiivne marsuut – või, vastupidi, keelata? Omakorda võimaldab control-plane’i tsentraliseerimine vSmart kontrollerite alusel modifitseerida suunamise tulemusi, ilma et oleks vaja seadistada üksikute seadmete seadistusi – marsruuterid näevad juba ainult selle loogika tulemust, mis on loodud vManage liideses ja edastatud rakendamiseks vSmart-l.

Service-chaining

Teenuste ahelate loomine on klassikalises marsruutimises veelgi töömahukam ülesanne kui juba kirjeldatud Traffic-Engineering mehhanism. Selles osas on vajalik mitte ainult luua spetsiaalne marsruut teatud võrgu rakendusele, vaid ka tagada liiklust juhtimise võimalus SD-WANi võrgu teatud (või kõikides) sõlmedes spetsiaalse rakenduse või teenuse (MCPE, tasakaalustamine, vahemällu salvestamine, liikluse kontrollimine jne) töötlemiseks. Samuti on oluline kontrollida nende välistöötlusteenuste olekut, et vältida black-holing olukordi, ning on vajalikud mehhanismid, mis võimaldavad neid ühetaolisi välistöötlusteenuseid paigutada erinevatesse geograafilistesse asukohtadesse, et võrk saaks automaatselt valida optimaalse teenuse sõlme parajasti liikluse töötlemiseks. Cisco SD-WANi puhul on seda suhteliselt lihtne saavutada, luues vastava tsentraliseeritud poliitika, mis „liidab” kõik sihtteenuste ahela aspektid ühtseks tervikuks ja muudab automaatselt data-plane ja control-plane loogikat ainult seal ja siis, kus see on vajalik.

Võime luua geograafiliselt jaotatud liikluse töötlemise valitud rakenduste tüüpide järjepidevuses spetsialiseeritud (ent mitte SD-WANi võrku kuuluva) varustuse peal – see on ilmselt kõige silmatorkavam näide Cisco SD-WANi eelistest klassikaliste tehnoloogiate ning isegi mõnede teiste tootjate SD-WAN alternatiivsete lahenduste ees.

Kokkuvõttes?

On ilmne, et nii DMVPN (koos või ilma Performance Routinguta) kui Cisco SD-WAN lahendavad lõppkokkuvõttes väga sarnaseid ülesandeid organisatsiooni jaotatud WAN võrgu osas. Siiski viivad Cisco SD-WAN tehnoloogia olulised arhitektuursed ja funktsionaalsed erinevused need ülesannete lahendamise protsessid teisele kvaliteeditasemele. Kokkuvõtteks võib märkida järgmised olulised erinevused SD-WAN ja DMVPN/PfR tehnoloogiate vahel:

• DMVPN/PfR kasutab üldiselt ajaproovitud tehnoloogiaid, mis on suunatud ülekantud VPN-võrkude loomisele ja osaliselt sarnaneb andmepinna osas kaasaegse SD-WAN tehnoloogiaga. Samas on teatud piirangud, sealhulgas kohustuslik staatiline marsruuterite konfiguratsioon ja topoloogiate valik on piiratud Hub-n-Spoke'iga. Teisest küljest on DMVPN/PfR-l mõned funktsionaalsed võimalused, mis pole veel SD-WAN raames saadaval (see puudutab per-application BFD-d).
• Control-plane tehnoloogiad erinevad põhimõtteliselt. Keskse signaaliprotokollide töötlemise tõttu võimaldab SD-WAN oluliselt kitsendada rikke domeene ja 'lahutada' kasutajate liikluse edastamisprotsessi signaalide suhtlemisest – ajutine juurdepääsmatus kontrolleritele ei mõjuta kasutajate liikluse edastamise võimalust. Samas ei mõjuta ajutine juurdepääsmatus mõnele harule (sealhulgas keskusele) teiste harude suhtlemisvõimet omavahel ja kontrolleritega.
• SD-WAN liikluse juhtimise poliitikate koostamise ja rakendamise arhitektuur ületab DMVPN/PfR oma tingimustes – georiseerimise rakendamine on oluliselt paremini teostatud, pole seotud Hubiga, rohkem võimalusi poliitikate peenhäälestamisel ning realiseerimise stsenaariumide loetelu on samuti oluliselt suurem.
• Lahenduse orkestreerimise protsess erineb samuti oluliselt. DMVPN eeldab, et olemas on ette teada omadused, mis peavad mingil moel olema kajastatud konfiguratsioonis, mis piirab lahenduse paindlikkust ja võimalust dünaamiliste muudatuste tegemiseks. SD-WAN lähtestab aga paradigma, et ülesehituse varajases etapis 'ei tea' marsruuter oma kontrolleritest midagi, kuid teab 'kellelt küsida' – seda on piisavalt, et mitte ainult automaatselt luua side kontrolleritega, vaid ka automaatselt luua täielikult seotud andmepinna topoloogiat, mida saab seejärel paindlikult seadistada/muuta poliitikate abil.
• Keskse haldamise, automatiseerimise ja jälgimise osas ületab SD-WAN ootuspäraselt DMVPN/PfR võimalusi, mis on klassikaliste tehnoloogiate arengu tulemus ja tuginevad suuresti CLI käsureale ning mallipõhiste NMS süsteemide kasutamisele.
• SD-WANis on võrreldes DMVPNiga turvanõuded jõudnud teisele kvaliteeditasemele. Peamised põhimõtted on null usaldus, skaleeritavus ja kahefaktoriline autentimine.

Nendest lihtsatest järeldustest võib jääda vale mulje, et DMVPN/PfRi põhjaliku võrgu loomine on täna igasuguse relevantsuse kaotanud. See ei ole kindlasti täiesti tõsi. Näiteks olukordades, kus võrgus kasutatakse palju vananenud seadmeid ja nende asendamine ei ole võimalik, võib DMVPN võimaldada „vanade“ ja „uuside“ seadmete ühendamist ühte geograafiliselt jaotatud võrku, milles on rohkesti eelpoolmainitud eeliseid.

Teisalt tuleb meeles pidada, et kõik aktuaalsed ettevõtte ruuterid Cisco IOS XE baasil (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) toetavad tänapäeval igasugust töörežiimi – nii klassikalist marsruutimist kui DMVPNi ja SD-WANi. Valik sõltub praegustest vajadustest ja arusaamast, et igal ajal saab samal seadmel liikuda edasi keerukamate tehnoloogiate suunas.

Allikas: habr.com