Sal Cisco SD-WAN die tak waarop DMVPN sit afsny?

Sedert Augustus 2017, toe Cisco Viptela verkry het, is die belangrikste tegnologie wat aangebied word vir die organisering van verspreide ondernemingsnetwerke Cisco SD-WAN. Oor die afgelope 3 jaar het SD-WAN-tegnologie deur baie veranderinge gegaan, beide kwalitatief en kwantitatief. Die funksionaliteit het dus aansienlik uitgebrei en ondersteuning het op klassieke routers van die reeks verskyn Cisco ISR 1000, ISR 4000, ASR 1000 en Virtual CSR 1000v. Terselfdertyd bly baie Cisco-kliënte en vennote wonder: wat is die verskille tussen Cisco SD-WAN en reeds bekende benaderings gebaseer op tegnologieë soos Cisco DMVPN и Cisco Performance Routing en hoe belangrik is hierdie verskille?

Hier moet ons dadelik 'n voorbehoud maak dat voor die koms van SD-WAN in die Cisco-portefeulje, DMVPN saam met PfR 'n sleuteldeel in die argitektuur gevorm het Cisco IWAN (Intelligente WAN), wat op sy beurt die voorganger was van volwaardige SD-WAN-tegnologie. Ten spyte van die algemene ooreenkoms van beide die take wat opgelos word en die metodes om dit op te los, het IWAN nooit die vlak van outomatisering, buigsaamheid en skaalbaarheid ontvang wat nodig is vir SD-WAN nie, en met verloop van tyd het die ontwikkeling van IWAN aansienlik afgeneem. Terselfdertyd het die tegnologieë waaruit IWAN bestaan, nie verdwyn nie, en baie kliënte gaan voort om dit suksesvol te gebruik, insluitend op moderne toerusting. As gevolg hiervan het 'n interessante situasie ontstaan ​​- dieselfde Cisco-toerusting laat jou toe om die mees geskikte WAN-tegnologie (klassiek, DMVPN+PfR of SD-WAN) te kies in ooreenstemming met die vereistes en verwagtinge van kliënte.

Die artikel is nie van plan om al die kenmerke van Cisco SD-WAN- en DMVPN-tegnologie (met of sonder Performance Routing) in detail te ontleed nie - daar is 'n groot hoeveelheid beskikbare dokumente en materiaal hiervoor. Die hooftaak is om die sleutelverskille tussen hierdie tegnologieë te probeer evalueer. Maar voordat ons verder gaan om hierdie verskille te bespreek, laat ons kortliks die tegnologieë self onthou.

Wat is Cisco DMVPN en hoekom is dit nodig?

Cisco DMVPN los die probleem op van dinamiese (= skaalbare) verbinding van 'n afgeleë taknetwerk aan die netwerk van die sentrale kantoor van 'n onderneming wanneer arbitrêre tipes kommunikasiekanale gebruik word, insluitend die internet (= met enkripsie van die kommunikasiekanaal). Tegnies word dit gerealiseer deur 'n gevirtualiseerde oorlegnetwerk van L3 VPN-klas te skep in punt-tot-multipunt-modus met 'n logiese topologie van die "Star"-tipe (Hub-n-Spoke). Om dit te bereik, gebruik DMVPN 'n kombinasie van die volgende tegnologieë:

• IP-roetering
• Multipoint GRE tonnels (mGRE)
• Next Hop Resolution Protocol (NHRP)
• IPSec Crypto profiele

Wat is die belangrikste voordele van Cisco DMVPN in vergelyking met klassieke roetering met behulp van MPLS VPN-kanale?

• Om 'n intertaknetwerk te skep, is dit moontlik om enige kommunikasiekanale te gebruik - enigiets wat IP-verbinding tussen takke kan verskaf, is geskik, terwyl die verkeer geïnkripteer (waar nodig) en gebalanseerd (waar moontlik) sal wees.
• 'n Ten volle gekoppelde topologie tussen takke word outomaties gevorm. Terselfdertyd is daar statiese tonnels tussen die sentrale en afgeleë takke, en dinamiese tonnels op aanvraag tussen die afgeleë takke (as daar verkeer is)
• Die routers van die sentrale en afgeleë tak het dieselfde konfigurasie tot by die IP-adresse van die koppelvlakke. Deur mGRE te gebruik, is dit nie nodig om tiene, honderde of selfs duisende tonnels individueel op te stel nie. As gevolg hiervan, ordentlike skaalbaarheid met die regte ontwerp.

Wat is Cisco Performance Routing en hoekom is dit nodig?

Wanneer DMVPN op 'n intertaknetwerk gebruik word, bly een uiters belangrike vraag onopgelos - hoe om die toestand van elk van die DMVPN-tonnels dinamies te assesseer vir voldoening aan die vereistes van verkeer wat krities is vir ons organisasie en, weereens, gebaseer op so 'n assessering, dinamies te maak 'n besluit oor herroetering? Die feit is dat DMVPN in hierdie deel min verskil van klassieke roetering - die beste wat gedoen kan word is om QoS-meganismes op te stel wat jou sal toelaat om verkeer in die uitgaande rigting te prioritiseer, maar op geen manier in staat is om die toestand van die hele pad een of ander tyd.

En wat om te doen as die kanaal gedeeltelik en nie heeltemal degradeer nie - hoe om dit op te spoor en te evalueer? DMVPN self kan dit nie doen nie. As in ag geneem word dat die kanale wat takke verbind deur heeltemal verskillende telekommunikasie-operateurs kan gaan, met heeltemal verskillende tegnologieë, word hierdie taak uiters nie-triviaal. En dit is waar Cisco Performance Routing-tegnologie tot die redding kom, wat teen daardie tyd reeds deur verskeie stadiums van ontwikkeling gegaan het.

Die taak van Cisco Performance Routing (hierna PfR) kom daarop neer om die toestand van paaie (tonnels) van verkeer te meet gebaseer op sleutelmaatstawwe wat belangrik is vir netwerktoepassings - latency, latency-variasie (jitter) en pakkieverlies (persentasie). Daarbenewens kan die gebruikte bandwydte gemeet word. Hierdie metings vind so na as moontlik aan intydse tyd en regverdig plaas, en die resultaat van hierdie metings stel die roeteerder wat PfR gebruik in staat om dinamies besluite te neem oor die behoefte om die roetering van hierdie of daardie tipe verkeer te verander.

Die taak van die DMVPN/PfR-kombinasie kan dus kortliks soos volg beskryf word:

• Laat die kliënt toe om enige kommunikasiekanale op die WAN-netwerk te gebruik
• Verseker die hoogste moontlike gehalte van kritieke toepassings op hierdie kanale

Wat is Cisco SD-WAN?

Cisco SD-WAN is 'n tegnologie wat die SDN-benadering gebruik om 'n organisasie se WAN-netwerk te skep en te bedryf. Dit beteken veral die gebruik van sogenaamde beheerders (sagteware-elemente), wat gesentraliseerde orkestrasie en outomatiese konfigurasie van alle oplossingkomponente verskaf. Anders as die kanonieke SDN (Clean Slate-styl), gebruik Cisco SD-WAN verskeie tipes beheerders, wat elkeen sy eie rol vervul – dit is doelbewus gedoen om beter skaalbaarheid en geo-oortolligheid te bied.

In die geval van SD-WAN bly die taak om enige tipe kanale te gebruik en die werking van besigheidstoepassings te verseker dieselfde, maar terselfdertyd brei die vereistes vir outomatisering, skaalbaarheid, sekuriteit en buigsaamheid van so 'n netwerk uit.

Bespreking van verskille

As ons nou begin om die verskille tussen hierdie tegnologieë te ontleed, sal hulle in een van die volgende kategorieë val:

• Argitektoniese verskille - hoe word funksies oor verskeie komponente van die oplossing versprei, hoe word die interaksie van sulke komponente georganiseer, en hoe beïnvloed dit die vermoëns en buigsaamheid van die tegnologie?
• Funksionaliteit – wat kan een tegnologie doen wat 'n ander nie kan nie? En is dit regtig so belangrik?

Wat is die argitektoniese verskille en is dit belangrik?

Elkeen van hierdie tegnologieë het baie "bewegende dele" wat nie net in hul rolle verskil nie, maar ook in hoe hulle met mekaar omgaan. Hoe goed hierdie beginsels uitgedink word en die algemene meganika van die oplossing bepaal direk die skaalbaarheid, fouttoleransie en algehele doeltreffendheid daarvan.

Kom ons kyk in meer besonderhede na die verskillende aspekte van die argitektuur:

Data-vlak – deel van die oplossing wat verantwoordelik is vir die oordrag van gebruikersverkeer tussen die bron en die ontvanger. DMVPN en SD-WAN word oor die algemeen identies op die routers self geïmplementeer, gebaseer op Multipoint GRE-tonnels. Die verskil is hoe die nodige stel parameters vir hierdie tonnels gevorm word:

• в DMVPN/PfR is 'n uitsluitlik twee-vlak hiërargie van nodusse met 'n Ster of Hub-n-Spoke topologie. Statiese konfigurasie van die Hub en statiese binding van Spoke aan die Hub word vereis, sowel as interaksie via die NHRP-protokol om data-vlak-verbinding te vorm. Gevolglik, maak veranderinge aan die Hub aansienlik moeilikerwat byvoorbeeld verband hou met die verandering/verbinding van nuwe WAN-kanale of die verandering van die parameters van bestaande kanale.
• в SD-WAN is 'n ten volle dinamiese model vir die opsporing van parameters van geïnstalleerde tonnels gebaseer op beheervlak (OMP-protokol) en orkestrasievlak (interaksie met die vBond-beheerder vir kontroleerderopsporing en NAT-deurkruistake). In hierdie geval kan enige gesuperponeerde topologieë gebruik word, insluitend hiërargiese. Binne die gevestigde oorlegtonneltopologie is buigsame konfigurasie van die logiese topologie in elke individuele VPN(VRF) moontlik.

Beheer-vlak – funksies van uitruil, filter en wysiging van roetering en ander inligting tussen oplossingkomponente.

• в DMVPN/PfR – slegs tussen Hub- en Spoke-routers uitgevoer. Direkte uitruil van roete-inligting tussen Spokes is nie moontlik nie. Gevolglik, Sonder 'n funksionerende Hub kan die beheervlak en datavlak nie funksioneer nie, wat bykomende hoë beskikbaarheidsvereistes op die Hub stel wat nie altyd nagekom kan word nie.
• в SD-WAN – beheervlak word nooit direk tussen routers uitgevoer nie – interaksie vind plaas op die basis van die OMP-protokol en word noodwendig uitgevoer deur 'n aparte gespesialiseerde tipe vSmart-beheerder, wat die moontlikheid bied van balansering, geo-reservering en gesentraliseerde beheer van die sein vrag. Nog 'n kenmerk van die OMP-protokol is sy aansienlike weerstand teen verliese en onafhanklikheid van die spoed van die kommunikasiekanaal met beheerders (natuurlik binne redelike perke). Wat jou ewe suksesvol toelaat om SD-WAN-beheerders in publieke of private wolke te plaas met toegang via die internet.

Beleidsvlak – deel van die oplossing wat verantwoordelik is vir die definisie, verspreiding en toepassing van verkeersbestuurbeleide op 'n verspreide netwerk.

• DMVPN – word effektief beperk deur kwaliteit van diens (QoS)-beleide wat individueel op elke roeteerder opgestel is via die CLI- of Prime Infrastructure-sjablone.
• DMVPN/PfR – PfR-beleide word op die gesentraliseerde Meesterbeheerder (MC)-roeteerder via die CLI gevorm en dan outomaties na tak-MC'e versprei. In hierdie geval word dieselfde beleidoordragpaaie gebruik as vir die datavlak. Daar is geen moontlikheid om die uitruil van beleide, roete-inligting en gebruikersdata te skei nie. Beleidpropagasie vereis die teenwoordigheid van IP-verbinding tussen die Hub en Spoke. In hierdie geval kan die MC-funksie, indien nodig, gekombineer word met 'n DMVPN-roeteerder. Dit is moontlik (maar nie nodig nie) om Prime Infrastructure-sjablone te gebruik vir gesentraliseerde beleidgenerering. 'n Belangrike kenmerk is dat die beleid wêreldwyd regdeur die netwerk op dieselfde manier gevorm word - Individuele beleide vir individuele segmente word nie gesteun nie.
• SD-WAN – verkeersbestuur en kwaliteit van diensbeleide word sentraal bepaal deur die Cisco vManage grafiese koppelvlak, toeganklik ook via die internet (indien nodig). Hulle word direk of indirek deur seinkanale deur vSmart-beheerders versprei (na gelang van die tipe beleid). Hulle is nie afhanklik van data-vliegtuig konneksie tussen routers, want gebruik alle beskikbare verkeerspaaie tussen die beheerder en die router.

  Vir verskillende netwerksegmente is dit moontlik om verskillende beleide buigsaam te formuleer - die omvang van die beleid word bepaal deur baie unieke identifiseerders wat in die oplossing verskaf word - taknommer, toepassingstipe, verkeersrigting, ens.

Orkestrasie-vliegtuig – meganismes wat komponente toelaat om mekaar dinamies op te spoor, daaropvolgende interaksies te konfigureer en te koördineer.

• в DMVPN/PfR Wedersydse ontdekking tussen roeteerders is gebaseer op die statiese konfigurasie van Hub-toestelle en die ooreenstemmende opstelling van Spoke-toestelle. Dinamiese ontdekking vind slegs plaas vir Spoke, wat sy Hub-verbindingsparameters aan die toestel rapporteer, wat op sy beurt vooraf met Spoke gekonfigureer is. Sonder IP-konneksie tussen Spoke en ten minste een Hub, is dit onmoontlik om óf 'n datavlak óf 'n beheervlak te vorm.
• в SD-WAN orkestrasie van oplossingkomponente vind plaas met behulp van die vBond-beheerder, waarmee elke komponent (routers en vManage/vSmart-beheerders) eers IP-konneksie moet vestig.

  Aanvanklik weet die komponente nie van mekaar se verbindingsparameters nie - hiervoor benodig hulle die vBond-tussenganger-orkeseerder. Die algemene beginsel is soos volg - elke komponent in die beginfase leer (outomaties of staties) slegs oor die verbindingsparameters na vBond, dan lig vBond die router in oor die vManage- en vSmart-beheerders (vroeër ontdek), wat dit moontlik maak om outomaties vas te stel al die nodige seinverbindings.

  Die volgende stap is dat die nuwe roeteerder meer oor die ander roeteerders op die netwerk leer deur OMP-kommunikasie met die vSmart-beheerder. Sodoende is die router, sonder om aanvanklik enigsins iets van die netwerkparameters te weet, in staat om ten volle outomaties op te spoor en aan beheerders te koppel en dan ook outomaties op te spoor en verbinding met ander routers te vorm. In hierdie geval is die verbindingsparameters van alle komponente aanvanklik onbekend en kan dit tydens werking verander.

Bestuur-vliegtuig – deel van die oplossing wat gesentraliseerde bestuur en monitering verskaf.

• DMVPN/PfR – geen gespesialiseerde bestuursvlakoplossing word verskaf nie. Vir basiese outomatisering en monitering kan produkte soos Cisco Prime Infrastructure gebruik word. Elke router het die vermoë om beheer te word via die CLI-opdragreël. Integrasie met eksterne stelsels via API word nie verskaf nie.
• SD-WAN – alle gereelde interaksie en monitering word sentraal uitgevoer deur die grafiese koppelvlak van die vManage-beheerder. Alle kenmerke van die oplossing, sonder uitsondering, is beskikbaar vir konfigurasie deur vManage, sowel as deur 'n volledig gedokumenteerde REST API-biblioteek.

  Alle SD-WAN-netwerkinstellings in vManage kom neer op twee hoofkonstrukte - die vorming van toestelsjablone (Device Template) en die vorming van 'n beleid wat die logika van netwerkwerking en verkeersverwerking bepaal. Terselfdertyd, vManage, wat die beleid wat deur die administrateur gegenereer word, uitsaai, kies outomaties watter veranderinge en op watter individuele toestelle/beheerders gemaak moet word, wat die doeltreffendheid en skaalbaarheid van die oplossing aansienlik verhoog.

  Deur die vManage-koppelvlak is nie net konfigurasie van die Cisco SD-WAN-oplossing beskikbaar nie, maar ook volledige monitering van die status van alle komponente van die oplossing, tot by die huidige stand van metrieke vir individuele tonnels en statistieke oor die gebruik van verskeie toepassings gebaseer op DPI-analise.

  Ten spyte van die sentralisering van interaksie, het alle komponente (beheerders en routers) ook 'n ten volle funksionele CLI-opdragreël, wat nodig is in die implementeringstadium of in geval van 'n noodgeval vir plaaslike diagnostiek. In normale modus (as daar 'n seinkanaal tussen komponente is) op routers, is die opdragreël slegs beskikbaar vir diagnostiek en is nie beskikbaar vir die maak van plaaslike veranderinge nie, wat plaaslike sekuriteit waarborg en die enigste bron van veranderinge in so 'n netwerk is vManage.

Geïntegreerde sekuriteit – hier moet ons nie net praat oor die beskerming van gebruikersdata wanneer dit oor oop kanale versend word nie, maar ook oor die algehele sekuriteit van die WAN-netwerk gebaseer op die geselekteerde tegnologie.

• в DMVPN/PfR Dit is moontlik om gebruikersdata en seinprotokolle te enkripteer. Wanneer sekere routermodelle gebruik word, is brandmuurfunksies met verkeersinspeksie, IPS/IDS addisioneel beskikbaar. Dit is moontlik om taknetwerke met behulp van VRF te segmenteer. Dit is moontlik om (een-faktor) beheerprotokolle te verifieer.

  In hierdie geval word die afgeleë router as 'n betroubare element van die netwerk by verstek beskou - d.w.s. gevalle van fisiese kompromie van individuele toestelle en die moontlikheid van ongemagtigde toegang daartoe word nie aanvaar of in ag geneem nie; daar is geen twee-faktor-verifikasie van oplossingskomponente nie, wat in die geval van 'n geografies verspreide netwerk kan aansienlike bykomende risiko's inhou.

• в SD-WAN na analogie van DMVPN word die vermoë verskaf om gebruikersdata te enkripteer, maar met aansienlik uitgebreide netwerksekuriteit en L3/VRF-segmenteringsfunksies (firewall, IPS/IDS, URL-filtrering, DNS-filtrering, AMP/TG, SASE, TLS/SSL-instaanbediener, ens.) d.). Terselfdertyd word die uitruil van enkripsiesleutels meer doeltreffend uitgevoer deur vSmart-beheerders (eerder as direk), deur voorafgevestigde seinkanale wat beskerm word deur DTLS/TLS-enkripsie gebaseer op sekuriteitsertifikate. Wat op sy beurt die sekuriteit van sulke uitruilings waarborg en beter skaalbaarheid van die oplossing tot tienduisende toestelle op dieselfde netwerk verseker.

  Alle seinverbindings (beheerder-na-beheerder, beheerder-roeteerder) word ook beskerm op grond van DTLS/TLS. Roeteerders is toegerus met veiligheidssertifikate tydens produksie met die moontlikheid van vervanging/verlenging. Twee-faktor-verifikasie word bereik deur die verpligte en gelyktydige vervulling van twee voorwaardes vir die roeteerder/beheerder om in 'n SD-WAN-netwerk te funksioneer:

  • Geldige sekuriteitsertifikaat
  • Eksplisiete en bewuste insluiting deur die administrateur van elke komponent in die "wit" lys van toegelate toestelle.

Funksionele verskille tussen SD-WAN en DMVPN/PfR

As ons verder gaan met die bespreking van funksionele verskille, moet daarop gelet word dat baie van hulle 'n voortsetting van argitektoniese verskille is - dit is geen geheim dat wanneer hulle die argitektuur van 'n oplossing vorm, ontwikkelaars begin met die vermoëns wat hulle op die ou end wil kry. Kom ons kyk na die belangrikste verskille tussen die twee tegnologieë.

AppQ (Application Quality) – funksioneer om die kwaliteit van die oordrag van besigheidstoepassingsverkeer te verseker

Die sleutelfunksies van die tegnologieë wat oorweeg word, is daarop gemik om die gebruikerservaring soveel as moontlik te verbeter wanneer besigheidskritiese toepassings in 'n verspreide netwerk gebruik word. Dit is veral belangrik in toestande waar 'n deel van die infrastruktuur nie deur IT beheer word nie of nie eers suksesvolle data-oordrag waarborg nie.

DMVPN verskaf nie self sulke meganismes nie. Die beste wat in 'n klassieke DMVPN-netwerk gedoen kan word, is om uitgaande verkeer volgens toepassing te klassifiseer en dit te prioritiseer wanneer dit na die WAN-kanaal gestuur word. Die keuse van 'n DMVPN-tonnel word in hierdie geval slegs bepaal deur die beskikbaarheid daarvan en die resultaat van die werking van roeteprotokolle. Terselfdertyd word die end-tot-end toestand van die pad/tonnel en die moontlike gedeeltelike agteruitgang daarvan nie in ag geneem in terme van sleutelmaatstawwe wat betekenisvol is vir netwerktoepassings nie - vertraging, vertragingsvariasie (jitter) en verliese (% ). In hierdie verband verloor die direkte vergelyking van klassieke DMVPN met SD-WAN in terme van die oplossing van AppQ-probleme alle betekenis - DMVPN kan nie hierdie probleem oplos nie. Wanneer jy Cisco Performance Routing (PfR)-tegnologie by hierdie konteks voeg, verander die situasie en word die vergelyking met Cisco SD-WAN meer betekenisvol.

Voordat ons die verskille bespreek, hier is 'n vinnige blik op hoe die tegnologieë soortgelyk is. Dus, beide tegnologieë:

• 'n meganisme hê wat jou toelaat om die toestand van elke gevestigde tonnel dinamies te assesseer in terme van sekere maatstawwe - op 'n minimum, vertraging, vertragingsvariasie en pakkieverlies (%)
• gebruik 'n spesifieke stel gereedskap om verkeersbestuurreëls (beleide) te vorm, te versprei en toe te pas, met inagneming van die resultate van die meting van die stand van sleuteltonnelmetrieke.
• klassifiseer toepassingsverkeer op vlakke L3-L4 (DSCP) van die OSI-model of deur L7 toepassingshandtekeninge gebaseer op DPI-meganismes wat in die roeteerder ingebou is
• Vir beduidende toepassings laat hulle jou toe om aanvaarbare drempelwaardes van statistieke, reëls vir die oordrag van verkeer by verstek te bepaal, en reëls vir die herleiding van verkeer wanneer drempelwaardes oorskry word.
• Wanneer hulle verkeer in GRE/IPSec inkapsuleer, gebruik hulle die reeds gevestigde industriemeganisme om interne DSCP-merke na die eksterne GRE/IPSEC-pakkiekop oor te dra, wat die sinchronisering van die QoS-beleide van die organisasie en die telekommunikasie-operateur moontlik maak (indien daar 'n toepaslike SLA is) .

Hoe verskil SD-WAN en DMVPN/PfR end-tot-end-metrieke?

DMVPN/PfR

• Beide aktiewe en passiewe sagtewaresensors (Probes) word gebruik om standaard tonnelgesondheidsmetrieke te evalueer. Aktiewe is gebaseer op gebruikersverkeer, passiewes boots sulke verkeer na (in die afwesigheid daarvan).
• Daar is geen fyninstelling van tydtellers en toestande vir degradasiebespeuring nie - die algoritme is vasgestel.
• Daarbenewens is meting van gebruikte bandwydte in die uitgaande rigting beskikbaar. Wat bykomende verkeersbestuur buigsaamheid by DMVPN/PfR voeg.
• Terselfdertyd maak sommige PfR-meganismes, wanneer metrieke oorskry word, staatmaak op terugvoersein in die vorm van spesiale TCA (Threshold Crossing Alert) boodskappe wat van die verkeersontvanger na die bron moet kom, wat op sy beurt aanneem dat die toestand van die gemete kanale moet ten minste voldoende wees vir die oordrag van sulke TCA-boodskappe. Wat in die meeste gevalle nie 'n probleem is nie, maar natuurlik nie gewaarborg kan word nie.

SD-WAN

• Vir end-tot-end-evaluering van standaard tonneltoestandmetrieke, word die BFD-protokol in eggomodus gebruik. In hierdie geval is spesiale terugvoer in die vorm van TCA of soortgelyke boodskappe nie nodig nie - isolasie van mislukkingsdomeine word gehandhaaf. Dit vereis ook nie die teenwoordigheid van gebruikersverkeer om die tonneltoestand te evalueer nie.
• Dit is moontlik om BFD-tydtellers te verfyn om die reaksiespoed en sensitiwiteit van die algoritme vir die agteruitgang van die kommunikasiekanaal van etlike sekondes tot minute te reguleer.

  

• Met die skryf hiervan is daar slegs een BFD-sessie in elke tonnel. Dit skep moontlik minder korreligheid in tonneltoestandontleding. In werklikheid kan dit slegs 'n beperking word as u 'n WAN-verbinding gebruik gebaseer op MPLS L2/L3 VPN met 'n ooreengekome QoS SLA - as die DSCP-merk van BFD-verkeer (na inkapseling in IPSec/GRE) ooreenstem met die hoë-prioriteit-tou in die telekommunikasie-operateur se netwerk, dan kan dit die akkuraatheid en spoed van degradasie-opsporing vir lae-prioriteit verkeer beïnvloed. Terselfdertyd is dit moontlik om die standaard BFD-etikettering te verander om die risiko van sulke situasies te verminder. In toekomstige weergawes van Cisco SD-WAN-sagteware word meer verfynde BFD-instellings verwag, sowel as die vermoë om verskeie BFD-sessies binne dieselfde tonnel te begin met individuele DSCP-waardes (vir verskillende toepassings).
• BFD laat jou ook toe om die maksimum pakkiegrootte te skat wat sonder fragmentasie deur 'n spesifieke tonnel versend kan word. Dit laat SD-WAN toe om parameters soos MTU en TCP MSS Adjust dinamies aan te pas om die beste van die beskikbare bandwydte op elke skakel te maak.
• In SD-WAN is die opsie van QoS-sinchronisasie van telekommunikasie-operateurs ook beskikbaar, nie net gebaseer op L3 DSCP-velde nie, maar ook gebaseer op L2 CoS-waardes, wat outomaties in die taknetwerk gegenereer kan word deur gespesialiseerde toestelle - byvoorbeeld IP fone

Hoe verskil die vermoëns, metodes om AppQ-beleide te definieer en toe te pas?

DMVPN/PfR-beleide:

• Gedefinieer op die sentrale takroeteerder(s) via die CLI-opdragreël of CLI-konfigurasiesjablone. Die generering van CLI-sjablone vereis voorbereiding en kennis van beleidsintaksis.

  

• Globaal gedefinieer sonder die moontlikheid van individuele konfigurasie/verandering aan die vereistes van individuele netwerksegmente.
• Interaktiewe beleidgenerering word nie in die grafiese koppelvlak verskaf nie.
• Nasporing van veranderinge, oorerwing en die skep van veelvuldige weergawes van beleide vir vinnige oorskakeling word nie verskaf nie.
• Word outomaties versprei na routers van afgeleë takke. In hierdie geval word dieselfde kommunikasiekanale gebruik as vir die oordrag van gebruikersdata. As daar geen kommunikasiekanaal tussen die sentrale en afgeleë tak is nie, is verspreiding/verandering van beleide onmoontlik.
• Hulle word op elke roeteerder gebruik en, indien nodig, verander die resultaat van standaard roeteringsprotokolle, met 'n hoër prioriteit.
• Vir gevalle waar alle tak WAN-skakels aansienlike verkeersverlies ervaar, geen vergoedingsmeganismes verskaf nie.

SD-WAN-beleide:

• Gedefinieer in die vManage GUI deur die interaktiewe sjabloon towenaar.
• Ondersteun die skep van veelvuldige beleide, kopieer, erf, skakel tussen beleide intyds.
• Ondersteun individuele beleidinstellings vir verskillende netwerksegmente (takke)
• Hulle word versprei deur gebruik te maak van enige beskikbare seinkanaal tussen die beheerder en die roeteerder en/of vSmart - is nie direk afhanklik van die datavlakverbinding tussen die roeteerders nie. Dit vereis natuurlik IP-konneksie tussen die router self en die beheerders.

  

• Vir gevalle waar alle beskikbare takke van 'n tak aansienlike dataverliese ervaar wat aanvaarbare drempels vir kritieke toepassings oorskry, is dit moontlik om bykomende meganismes te gebruik wat transmissiebetroubaarheid verhoog:
  • FEC (Forward Error Correction) - gebruik 'n spesiale oortollige koderingsalgoritme. Wanneer kritieke verkeer oor kanale met 'n beduidende persentasie verliese versend word, kan FEC outomaties geaktiveer word en laat, indien nodig, toe om die verlore deel van die data te herstel. Dit verhoog die gebruikte transmissiebandwydte effens, maar verbeter betroubaarheid aansienlik.

    

  • Duplisering van datastrome – Benewens FEC, kan die beleid voorsiening maak vir outomatiese duplisering van verkeer van geselekteerde toepassings in die geval van 'n selfs ernstiger vlak van verliese wat nie deur FEC vergoed kan word nie. In hierdie geval sal die geselekteerde data deur alle tonnels na die ontvangende tak versend word met daaropvolgende de-duplisering (verwerping van ekstra kopieë van pakkies). Die meganisme verhoog kanaalbenutting aansienlik, maar verhoog ook transmissiebetroubaarheid aansienlik.

Cisco SD-WAN-vermoëns, sonder direkte analoë in DMVPN/PfR

Die argitektuur van die Cisco SD-WAN-oplossing laat jou in sommige gevalle toe om vermoëns te verkry wat óf uiters moeilik is om binne DMVPN/PfR te implementeer, óf onprakties is as gevolg van die vereiste arbeidskoste, óf heeltemal onmoontlik is. Kom ons kyk na die interessantste van hulle:

Verkeersingenieurswese (TE)

TE sluit meganismes in wat verkeer toelaat om die standaardpad wat deur roeteringsprotokolle gevorm word, te vertak. TE word dikwels gebruik om hoë beskikbaarheid van netwerkdienste te verseker, deur die vermoë om kritieke verkeer vinnig en/of proaktief na 'n alternatiewe (onsamehangende) transmissiepad oor te dra, ten einde beter kwaliteit diens of spoed van herstel in die geval van mislukking te verseker op die hoofpad.

Die moeilikheid om TE te implementeer lê in die behoefte om vooraf 'n alternatiewe pad te bereken en te reserveer (kontroleer). In MPLS-netwerke van telekommunikasie-operateurs word hierdie probleem opgelos met behulp van tegnologieë soos MPLS Traffic-Engineering met uitbreidings van die IGP-protokolle en RSVP-protokol. Ook onlangs het Segment Routing-tegnologie, wat meer geoptimaliseer is vir gesentraliseerde konfigurasie en orkestrasie, toenemend gewild geword. In klassieke WAN-netwerke word hierdie tegnologieë gewoonlik nie verteenwoordig nie of is dit gereduseer tot die gebruik van hop-vir-hop-meganismes soos beleidsgebaseerde roetering (PBR), wat in staat is om verkeer te vertak, maar implementeer dit op elke roeteerder afsonderlik - sonder om die algehele toestand van die netwerk of PBR-resultaat in die vorige of daaropvolgende stappe in ag te neem. Die resultaat van die gebruik van hierdie TE-opsies is teleurstellend - MPLS TE, as gevolg van die kompleksiteit van konfigurasie en werking, word as 'n reël slegs in die mees kritieke deel van die netwerk (kern) gebruik, en PBR word op individuele routers gebruik sonder die vermoë om 'n verenigde PBR-beleid vir die hele netwerk te skep. Dit geld natuurlik ook vir DMVPN-gebaseerde netwerke.

SD-WAN bied in hierdie verband 'n baie meer elegante oplossing wat nie net maklik is om te konfigureer nie, maar ook baie beter skaal. Dit is 'n gevolg van die beheervlak- en beleidvlakargitekture wat gebruik is. Die implementering van 'n beleidsvlak in SD-WAN stel jou in staat om TE-beleid sentraal te definieer - watter verkeer is van belang? vir watter VPN’s? Deur watter nodusse/tonnels is dit nodig of, omgekeerd, verbode om 'n alternatiewe roete te vorm? Op sy beurt laat die sentralisering van beheervlakbestuur gebaseer op vSmart-beheerders jou toe om roeteresultate te verander sonder om na die instellings van individuele toestelle toe te vlug - routers sien reeds net die resultaat van die logika wat in die vManage-koppelvlak gegenereer is en oorgedra is vir gebruik na vSlim.

Diens-ketting

Die vorming van dienskettings is 'n selfs meer arbeidsintensiewe taak in klassieke roetering as die reeds beskryfde Verkeersingenieurswese-meganisme. Inderdaad, in hierdie geval is dit nodig om nie net 'n spesiale roete vir 'n spesifieke netwerktoepassing te skep nie, maar ook om die vermoë te verseker om verkeer van die netwerk op sekere (of alle) nodusse van die SD-WAN-netwerk te verwyder vir verwerking deur 'n spesiale toepassing of diens (brandmuur, balansering, kas, inspeksieverkeer, ens.). Terselfdertyd is dit nodig om die toestand van hierdie eksterne dienste te kan beheer ten einde swartgat situasies te voorkom, en meganismes is ook nodig wat toelaat dat sulke eksterne dienste van dieselfde tipe in verskillende geo-liggings geplaas word met die vermoë van die netwerk om outomaties die mees optimale diensnodus te kies vir die verwerking van die verkeer van 'n bepaalde tak. In die geval van Cisco SD-WAN is dit redelik maklik om te bereik deur 'n toepaslike gesentraliseerde beleid te skep wat alle aspekte van die teikendiensketting in 'n enkele geheel "gom" en outomaties die datavlak- en beheervlaklogika verander slegs waar en wanneer nodig.

Die vermoë om geo-verspreide verwerking van verkeer van geselekteerde soorte toepassings in 'n sekere volgorde te skep op gespesialiseerde (maar nie verwant aan die SD-WAN-netwerk self nie) toerusting is miskien die duidelikste demonstrasie van die voordele van Cisco SD-WAN bo klassieke tegnologieë en selfs 'n paar alternatiewe SD-oplossings -WAN van ander vervaardigers.

Die resultaat?

Dit is duidelik dat beide DMVPN (met of sonder prestasieroetering) en Cisco SD-WAN los baie soortgelyke probleme op met betrekking tot die verspreide WAN-netwerk van die organisasie. Terselfdertyd lei beduidende argitektoniese en funksionele verskille in Cisco SD-WAN-tegnologie tot die proses om hierdie probleme op te los na 'n ander kwaliteitsvlak. Om op te som, kan ons let op die volgende beduidende verskille tussen SD-WAN en DMVPN/PfR tegnologieë:

• DMVPN/PfR gebruik oor die algemeen beproefde tegnologieë vir die bou van oorleg-VPN-netwerke en, in terme van datavlak, is soortgelyk aan meer moderne SD-WAN-tegnologie, maar daar is 'n aantal beperkings in die vorm van 'n verpligte statiese konfigurasie van routers en die keuse van topologieë is beperk tot Hub-n-Spoke. Aan die ander kant het DMVPN/PfR 'n paar funksies wat nog nie binne SD-WAN beskikbaar is nie (ons praat van BFD per toepassing).
• Binne die beheervlak verskil tegnologieë fundamenteel. Met inagneming van die gesentraliseerde verwerking van seinprotokolle, laat SD-WAN veral toe om mislukkingsdomeine aansienlik te vernou en die proses van die oordrag van gebruikersverkeer van seininteraksie te "ontkoppel" - tydelike onbeskikbaarheid van beheerders beïnvloed nie die vermoë om gebruikersverkeer oor te dra nie. . Terselfdertyd beïnvloed die tydelike onbeskikbaarheid van enige tak (insluitend die sentrale een) geensins die vermoë van ander takke om met mekaar en beheerders te kommunikeer nie.
• Die argitektuur vir die vorming en toepassing van verkeersbestuurbeleide in die geval van SD-WAN is ook beter as dié in DMVPN/PfR - geo-reservering is baie beter geïmplementeer, daar is geen verbinding met die Hub nie, daar is meer geleenthede vir boete -instellingsbeleide, die lys van geïmplementeerde verkeersbestuurscenario's is ook baie groter.
• Die oplossing orkestrasie proses is ook aansienlik anders. DMVPN veronderstel die teenwoordigheid van voorheen bekende parameters wat op een of ander manier in die konfigurasie weerspieël moet word, wat die buigsaamheid van die oplossing en die moontlikheid van dinamiese veranderinge ietwat beperk. Op sy beurt is SD-WAN gebaseer op die paradigma dat die router op die aanvanklike oomblik van verbinding "niks weet nie" oor sy beheerders, maar weet "wie jy kan vra" - dit is genoeg om nie net outomaties kommunikasie met die beheerders, maar ook om outomaties 'n volledig gekoppelde datavlak-topologie te vorm, wat dan buigsaam gekonfigureer/verander kan word met behulp van beleide.
• In terme van gesentraliseerde bestuur, outomatisering en monitering, word verwag dat SD-WAN die vermoëns van DMVPN/PfR sal oortref, wat uit klassieke tegnologieë ontwikkel het en meer staatmaak op die CLI-opdragreël en die gebruik van sjabloongebaseerde NMS-stelsels.
• In SD-WAN, in vergelyking met DMVPN, het sekuriteitsvereistes 'n ander kwalitatiewe vlak bereik. Die hoofbeginsels is nul vertroue, skaalbaarheid en twee-faktor-verifikasie.

Hierdie eenvoudige gevolgtrekkings kan die verkeerde indruk wek dat die skep van 'n netwerk gebaseer op DMVPN/PfR vandag alle relevansie verloor het. Dit is natuurlik nie heeltemal waar nie. Byvoorbeeld, in gevalle waar die netwerk baie verouderde toerusting gebruik en daar geen manier is om dit te vervang nie, kan DMVPN jou toelaat om "ou" en "nuwe" toestelle te kombineer in 'n enkele geo-verspreide netwerk met baie van die voordele wat beskryf word. hierbo.

Aan die ander kant moet onthou word dat alle huidige Cisco korporatiewe routers gebaseer op IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) vandag enige bedryfsmodus ondersteun - beide klassieke roetering en DMVPN en SD-WAN - die keuse word bepaal deur huidige behoeftes en die begrip dat jy enige oomblik, met dieselfde toerusting, kan begin beweeg na meer gevorderde tegnologie.

Bron: will.com