Přeruší Cisco SD-WAN větev, na které sedí DMVPN?

Od srpna 2017, kdy společnost Cisco získala společnost Viptela, se hlavní nabízenou technologií pro organizaci distribuovaných podnikových sítí stala Cisco SD-WAN. Za poslední 3 roky prošla technologie SD-WAN mnoha změnami, jak kvalitativními, tak kvantitativními. Funkčnost se tedy výrazně rozšířila a podpora se objevila na klasických routerech řady Cisco ISR 1000, ISR 4000, ASR 1000 a Virtual CSR 1000v. Zároveň se mnoho zákazníků a partnerů Cisco stále ptá: jaké jsou rozdíly mezi Cisco SD-WAN a již známými přístupy založenými na technologiích jako např Cisco DMVPN и Cisco Performance Routing a jak důležité jsou tyto rozdíly?

Zde bychom měli okamžitě učinit výhradu, že před příchodem SD-WAN v portfoliu Cisco tvořil DMVPN spolu s PfR klíčovou součást architektury Cisco IWAN (inteligentní WAN), což byl zase předchůdce plnohodnotné technologie SD-WAN. Navzdory obecné podobnosti jak řešených úloh, tak metod jejich řešení, IWAN nikdy nezískal úroveň automatizace, flexibility a škálovatelnosti nezbytnou pro SD-WAN a postupem času se vývoj IWAN výrazně snížil. Technologie, které tvoří IWAN, přitom nezmizely a mnoho zákazníků je nadále úspěšně používá, a to i na moderních zařízeních. V důsledku toho nastala zajímavá situace - stejné vybavení Cisco umožňuje zvolit nejvhodnější technologii WAN (klasická, DMVPN+PfR nebo SD-WAN) v souladu s požadavky a očekáváními zákazníků.

Článek nemá v úmyslu podrobně rozebírat všechny vlastnosti technologií Cisco SD-WAN a DMVPN (s nebo bez Performance Routing) - k tomu existuje obrovské množství dostupných dokumentů a materiálů. Hlavním úkolem je pokusit se vyhodnotit klíčové rozdíly mezi těmito technologiemi. Než však přejdeme k diskusi o těchto rozdílech, připomeňme si krátce samotné technologie.

Co je Cisco DMVPN a proč je potřeba?

Cisco DMVPN řeší problém dynamického (= škálovatelného) připojení vzdálené pobočkové sítě do sítě centrály podniku při použití libovolných typů komunikačních kanálů včetně Internetu (= s šifrováním komunikačního kanálu). Technicky je to realizováno vytvořením virtualizované překryvné sítě třídy L3 VPN v režimu point-to-multipoint s logickou topologií typu „Star“ (Hub-n-Spoke). K dosažení tohoto cíle používá DMVPN kombinaci následujících technologií:

• IP směrování
• Vícebodové GRE tunely (mGRE)
• Next Hop Resolution Protocol (NHRP)
• IPSec Crypto profily

Jaké jsou hlavní výhody Cisco DMVPN ve srovnání s klasickým směrováním pomocí MPLS VPN kanálů?

• Pro vytvoření mezioborové sítě je možné použít libovolné komunikační kanály - vhodné je cokoliv, co dokáže zajistit IP konektivitu mezi pobočkami, přičemž provoz bude šifrovaný (tam, kde je to nutné) a vyvážený (tam, kde je to možné)
• Automaticky se vytvoří plně propojená topologie mezi větvemi. Současně existují statické tunely mezi centrální a vzdálenou větví a dynamické tunely na vyžádání mezi vzdálenými větvemi (pokud je provoz)
• Směrovače centrální a vzdálené pobočky mají stejnou konfiguraci až do IP adres rozhraní. Při použití mGRE není potřeba individuálně konfigurovat desítky, stovky nebo dokonce tisíce tunelů. Výsledkem je slušná škálovatelnost se správným designem.

Co je Cisco Performance Routing a proč je potřeba?

Při použití DMVPN na mezioborové síti zůstává nevyřešena jedna nesmírně důležitá otázka – jak dynamicky hodnotit stav každého z tunelů DMVPN z hlediska splnění požadavků na provoz kritický pro naši organizaci a opět na základě takového posouzení dynamicky provádět rozhodnutí o přesměrování? Faktem je, že DMVPN se v této části liší od klasického směrování jen málo - nejlepší, co lze udělat, je nakonfigurovat mechanismy QoS, které vám umožní upřednostňovat provoz v odchozím směru, ale v žádném případě nejsou schopny zohlednit stav celou cestu v té či oné době.

A co dělat, když kanál degraduje částečně a ne úplně - jak to zjistit a vyhodnotit? DMVPN sám to neumí. Vzhledem k tomu, že kanály propojující pobočky mohou procházet úplně jinými telekomunikačními operátory za použití zcela jiných technologií, stává se tento úkol extrémně netriviální. A právě zde přichází na pomoc technologie Cisco Performance Routing, která v té době již prošla několika fázemi vývoje.

Úkol Cisco Performance Routing (dále PfR) spočívá v měření stavu cest (tunelů) provozu na základě klíčových metrik důležitých pro síťové aplikace - latence, variace latence (jitter) a ztráta paketů (procenta). Navíc lze měřit použitou šířku pásma. Tato měření probíhají co nejblíže reálnému času a oprávněně a výsledek těchto měření umožňuje routeru využívajícímu PfR dynamicky rozhodovat o nutnosti změnit směrování toho či onoho typu provozu.

Úkol kombinace DMVPN/PfR lze tedy stručně popsat takto:

• Umožněte zákazníkovi používat jakékoli komunikační kanály v síti WAN
• Zajistěte nejvyšší možnou kvalitu kritických aplikací na těchto kanálech

Co je Cisco SD-WAN?

Cisco SD-WAN je technologie, která využívá přístup SDN k vytvoření a provozování WAN sítě organizace. Jedná se zejména o použití tzv. kontrolérů (softwarových prvků), které zajišťují centralizovanou orchestraci a automatizovanou konfiguraci všech komponent řešení. Na rozdíl od kanonického SDN (styl Clean Slate) používá Cisco SD-WAN několik typů řadičů, z nichž každý plní svou vlastní roli – to bylo provedeno záměrně, aby byla zajištěna lepší škálovatelnost a geografická redundance.

V případě SD-WAN zůstává úkol využívat libovolné typy kanálů a zajišťovat provoz podnikových aplikací stejný, ale zároveň se rozšiřují požadavky na automatizaci, škálovatelnost, bezpečnost a flexibilitu takové sítě.

Diskuse o rozdílech

Pokud nyní začneme analyzovat rozdíly mezi těmito technologiemi, budou spadat do jedné z následujících kategorií:

• Architektonické rozdíly – jak jsou funkce rozděleny mezi různé komponenty řešení, jak je organizována interakce takových komponent a jak to ovlivňuje schopnosti a flexibilitu technologie?
• Funkčnost – co dokáže jedna technologie, co jiná neumí? A je to opravdu tak důležité?

Jaké jsou architektonické rozdíly a jsou důležité?

Každá z těchto technologií má mnoho „pohyblivých částí“, které se liší nejen svými rolemi, ale také tím, jak na sebe vzájemně působí. Jak dobře jsou tyto principy promyšlené a obecná mechanika řešení přímo určuje jeho škálovatelnost, odolnost proti chybám a celkovou efektivitu.

Podívejme se na různé aspekty architektury podrobněji:

Datová rovina – část řešení zodpovědná za přenos uživatelského provozu mezi zdrojem a příjemcem. DMVPN a SD-WAN jsou implementovány obecně identicky na samotných směrovačích na základě tunelů Multipoint GRE. Rozdíl je v tom, jak se tvoří nezbytná sada parametrů pro tyto tunely:

• в DMVPN/PfR je výhradně dvouúrovňová hierarchie uzlů s topologií Star nebo Hub-n-Spoke. Je vyžadována statická konfigurace Hubu a statické navázání Spoke na Hub, stejně jako interakce prostřednictvím protokolu NHRP za účelem vytvoření konektivity datové roviny. Tudíž, podstatně ztížit změny v Hubusouvisející například se změnou/připojováním nových WAN kanálů nebo změnou parametrů stávajících.
• в SD WAN je plně dynamický model pro detekci parametrů instalovaných tunelů na bázi control-plane (OMP protokol) a orchestration-plane (interakce s řadičem vBond pro detekci kontroléru a úlohy NAT traversal). V tomto případě lze použít libovolné superponované topologie, včetně hierarchických. V rámci zavedené topologie překryvného tunelu je možná flexibilní konfigurace logické topologie v každé jednotlivé VPN (VRF).

Řídící rovina – funkce výměny, filtrování a úpravy směrování a dalších informací mezi komponenty řešení.

• в DMVPN/PfR – provádí se pouze mezi směrovači Hub a Spoke. Přímá výměna směrovacích informací mezi Spokes není možná. Tudíž, Bez fungujícího rozbočovače nemůže řídicí rovina a datová rovina fungovat, který klade na Hub další požadavky na vysokou dostupnost, které nelze vždy splnit.
• в SD WAN – control-plane se nikdy neprovádí přímo mezi routery – interakce probíhá na základě protokolu OMP a je nutně prováděna prostřednictvím samostatného specializovaného typu vSmart kontroleru, který poskytuje možnost vyvažování, georezervace a centralizovaného ovládání zatížení signálu. Další vlastností protokolu OMP je jeho značná odolnost proti ztrátám a nezávislost na rychlosti komunikačního kanálu s kontroléry (samozřejmě v rozumných mezích). Což stejně úspěšně umožňuje umístit řadiče SD-WAN do veřejných nebo privátních cloudů s přístupem přes internet.

Politická rovina – část řešení zodpovědná za definování, distribuci a aplikaci politik řízení provozu v distribuované síti.

• DMVPN – je účinně omezena zásadami kvality služeb (QoS) nakonfigurovanými individuálně na každém routeru prostřednictvím šablon CLI nebo Prime Infrastructure.
• DMVPN/PfR – Zásady PfR se vytvářejí na centralizovaném směrovači Master Controller (MC) prostřednictvím CLI a poté se automaticky distribuují do pobočkových MC. V tomto případě se použijí stejné cesty přenosu zásad jako pro datovou rovinu. Neexistuje žádná možnost oddělit výměnu politik, informace o směrování a uživatelská data. Šíření zásad vyžaduje přítomnost IP konektivity mezi Hub a Spoke. V tomto případě lze funkci MC v případě potřeby kombinovat s routerem DMVPN. Je možné (ale není to nutné) používat šablony Prime Infrastructure pro centralizované generování zásad. Důležitým rysem je, že politika se tvoří globálně v celé síti stejným způsobem – Jednotlivé zásady pro jednotlivé segmenty nejsou podporovány.
• SD WAN – řízení provozu a zásady kvality služeb jsou určovány centrálně prostřednictvím grafického rozhraní Cisco vManage, dostupném i přes internet (v případě potřeby). Jsou distribuovány prostřednictvím signálních kanálů přímo nebo nepřímo prostřednictvím ovladačů vSmart (v závislosti na typu politiky). Nejsou závislé na konektivitě datové roviny mezi routery, protože použít všechny dostupné dopravní cesty mezi řadičem a routerem.

  Pro různé segmenty sítě je možné flexibilně formulovat různé politiky – rozsah politiky je určen mnoha jedinečnými identifikátory poskytnutými v řešení – číslo pobočky, typ aplikace, směr provozu atd.

Orchestrační letadlo – mechanismy, které umožňují komponentám dynamicky se navzájem detekovat, konfigurovat a koordinovat následné interakce.

• в DMVPN/PfR Vzájemné zjišťování mezi routery je založeno na statické konfiguraci zařízení Hub a odpovídající konfiguraci zařízení Spoke. Dynamické zjišťování probíhá pouze pro Spoke, který hlásí své parametry připojení Hub do zařízení, které je zase předem nakonfigurováno pomocí Spoke. Bez IP konektivity mezi Spoke a alespoň jedním Hubem není možné vytvořit datovou rovinu ani řídicí rovinu.
• в SD WAN k orchestraci komponent řešení dochází pomocí řadiče vBond, se kterým musí každá komponenta (směrovače a řadiče vManage/vSmart) nejprve navázat IP konektivitu.

  Zpočátku komponenty navzájem nevědí o parametrech připojení - k tomu potřebují zprostředkující orchestrátor vBond. Obecný princip je následující - každá komponenta se v počáteční fázi dozví (automaticky nebo staticky) pouze o parametrech připojení k vBond, poté vBond informuje router o dříve objevených řadičích vManage a vSmart, což umožňuje automaticky navázat všechna potřebná signalizační spojení.

  Dalším krokem je, aby se nový směrovač dozvěděl o ostatních směrovačích v síti prostřednictvím komunikace OMP s řadičem vSmart. Router tak, aniž by zpočátku věděl vůbec cokoli o parametrech sítě, je schopen plně automaticky detekovat a připojit se k řadičům a následně také automaticky detekovat a vytvářet konektivitu s jinými routery. V tomto případě jsou parametry připojení všech komponent zpočátku neznámé a mohou se během provozu změnit.

Management-rovina – část řešení, která poskytuje centralizovanou správu a monitorování.

• DMVPN/PfR – není poskytováno žádné specializované řešení roviny řízení. Pro základní automatizaci a monitorování lze použít produkty jako Cisco Prime Infrastructure. Každý router má možnost ovládat pomocí příkazového řádku CLI. Integrace s externími systémy přes API není poskytována.
• SD WAN – veškerá pravidelná interakce a monitorování probíhá centrálně prostřednictvím grafického rozhraní ovladače vManage. Všechny funkce řešení bez výjimky jsou dostupné pro konfiguraci prostřednictvím vManage a také prostřednictvím plně zdokumentované knihovny REST API.

  Všechna nastavení sítě SD-WAN ve vManage se skládají ze dvou hlavních konstrukcí – vytvoření šablon zařízení (Device Template) a vytvoření zásady, která určuje logiku síťového provozu a zpracování provozu. Zároveň vManage vysílající politiku generovanou administrátorem automaticky vybírá, které změny a na kterých jednotlivých zařízeních/řadičích je potřeba provést, což výrazně zvyšuje efektivitu a škálovatelnost řešení.

  Prostřednictvím rozhraní vManage je dostupná nejen konfigurace řešení Cisco SD-WAN, ale také plné sledování stavu všech komponent řešení, až po aktuální stav metrik pro jednotlivé tunely a statistiky využití různých aplikací. na základě analýzy DPI.

  I přes centralizaci interakce mají všechny komponenty (řadiče a routery) také plně funkční příkazový řádek CLI, který je nezbytný ve fázi implementace nebo v případě nouze pro lokální diagnostiku. V normálním režimu (pokud je mezi komponentami signální kanál) na routerech je příkazový řádek dostupný pouze pro diagnostiku a není dostupný pro provádění lokálních změn, což zaručuje lokální bezpečnost a jediným zdrojem změn v takové síti je vManage.

Integrovaná bezpečnost – zde bychom měli hovořit nejen o ochraně uživatelských dat při přenosu otevřenými kanály, ale také o celkové bezpečnosti sítě WAN na základě zvolené technologie.

• в DMVPN/PfR Je možné šifrovat uživatelská data a signalizační protokoly. Při použití určitých modelů routerů jsou navíc k dispozici funkce brány firewall s kontrolou provozu, IPS/IDS. Pomocí VRF je možné segmentovat pobočkové sítě. Je možné autentizovat (jednofaktorové) řídicí protokoly.

  Vzdálený router je v tomto případě standardně považován za důvěryhodný prvek sítě – tzn. nepředpokládá se ani se nepočítá s případy fyzické kompromitace jednotlivých zařízení a možnosti neoprávněného přístupu k nim, nedochází k dvoufaktorové autentizaci komponent řešení, která v případě geograficky distribuované sítě může nést významná další rizika.

• в SD WAN analogicky s DMVPN je zajištěna možnost šifrování uživatelských dat, ale s výrazně rozšířeným zabezpečením sítě a funkcemi segmentace L3/VRF (firewall, IPS/IDS, filtrování URL, filtrování DNS, AMP/TG, SASE, TLS/SSL proxy, atd.) d.). Zároveň je výměna šifrovacích klíčů prováděna efektivněji prostřednictvím ovladačů vSmart (spíše než přímo), prostřednictvím předem vytvořených signálních kanálů chráněných šifrováním DTLS/TLS na základě bezpečnostních certifikátů. Což zase zaručuje bezpečnost takovýchto výměn a zajišťuje lepší škálovatelnost řešení až pro desítky tisíc zařízení ve stejné síti.

  Všechna signalizační spojení (kontrolér-kontrolér, kontrolér-router) jsou rovněž chráněna na základě DTLS/TLS. Routery jsou při výrobě vybaveny bezpečnostními atesty s možností výměny/prodloužení. Dvoufaktorové autentizace je dosaženo povinným a současným splněním dvou podmínek pro fungování routeru/řadiče v síti SD-WAN:

  • Platný bezpečnostní certifikát
  • Explicitní a vědomé zařazení administrátorem každé součásti do „bílého“ seznamu povolených zařízení.

Funkční rozdíly mezi SD-WAN a DMVPN/PfR

Když přejdeme k diskusi o funkčních rozdílech, je třeba poznamenat, že mnohé z nich jsou pokračováním architektonických - není žádným tajemstvím, že při vytváření architektury řešení vycházejí vývojáři z možností, které chtějí nakonec získat. Podívejme se na nejvýraznější rozdíly mezi oběma technologiemi.

AppQ (Application Quality) – funkce zajišťující kvalitu přenosu provozu obchodních aplikací

Klíčové funkce uvažovaných technologií jsou zaměřeny na maximální zlepšení uživatelské zkušenosti při používání kritických obchodních aplikací v distribuované síti. To je důležité zejména v podmínkách, kdy část infrastruktury není řízena IT nebo dokonce nezaručuje úspěšný přenos dat.

DMVPN sama takové mechanismy neposkytuje. Nejlepší, co lze v klasické síti DMVPN udělat, je klasifikovat odchozí provoz podle aplikace a upřednostnit jej při přenosu do kanálu WAN. Volba tunelu DMVPN je v tomto případě určena pouze jeho dostupností a výsledkem činnosti směrovacích protokolů. Zároveň není zohledněn end-to-end stav cesty/tunelu a jeho možná částečná degradace z hlediska klíčových metrik, které jsou významné pro síťové aplikace – zpoždění, kolísání zpoždění (jitter) a ztráty (% ). V tomto ohledu ztrácí přímé srovnávání klasického DMVPN s SD-WAN z hlediska řešení problémů AppQ veškerý význam – DMVPN tento problém vyřešit nedokáže. Když do tohoto kontextu přidáte technologii Cisco Performance Routing (PfR), situace se změní a srovnání s Cisco SD-WAN bude smysluplnější.

Než probereme rozdíly, zde je rychlý pohled na to, jak jsou si technologie podobné. Takže obě technologie:

• mají mechanismus, který vám umožňuje dynamicky hodnotit stav každého vytvořeného tunelu z hlediska určitých metrik – minimálně zpoždění, variace zpoždění a ztráta paketů (%)
• používat specifickou sadu nástrojů k vytváření, distribuci a aplikaci pravidel (politik) řízení provozu s přihlédnutím k výsledkům měření stavu klíčových metrik tunelů.
• klasifikovat provoz aplikací na úrovních L3-L4 (DSCP) modelu OSI nebo podle podpisů aplikací L7 na základě mechanismů DPI zabudovaných do routeru
• U významných aplikací umožňují určit přijatelné prahové hodnoty metrik, standardně pravidla pro přenos provozu a pravidla pro přesměrování provozu při překročení prahových hodnot.
• Při zapouzdření provozu v GRE/IPSec používají již zavedený průmyslový mechanismus pro přenos interních značek DSCP do externí hlavičky paketů GRE/IPSEC, což umožňuje synchronizaci zásad QoS organizace a telekomunikačního operátora (pokud existuje odpovídající SLA) .

Jak se liší end-to-end metriky SD-WAN a DMVPN/PfR?

DMVPN/PfR

• K vyhodnocení standardních ukazatelů stavu tunelu se používají aktivní i pasivní softwarové senzory (Probes). Aktivní jsou založeny na uživatelském provozu, pasivní takový provoz emulují (v jeho nepřítomnosti).
• Neexistuje žádné jemné doladění časovačů a podmínek detekce degradace - algoritmus je pevně daný.
• Navíc je k dispozici měření použité šířky pásma v odchozím směru. Což přidává další flexibilitu řízení provozu k DMVPN/PfR.
• Některé mechanismy PfR přitom při překročení metrik spoléhají na signalizaci zpětné vazby ve formě speciálních zpráv TCA (Threshold Crossing Alert), které musí přijít od příjemce provozu směrem ke zdroji, což zase předpokládá, že stav měřené kanály by měly být alespoň dostatečné pro přenos takových zpráv TCA. Což ve většině případů není problém, ale samozřejmě to nelze zaručit.

SD WAN

• Pro end-to-end vyhodnocení standardních metrik stavu tunelu se používá protokol BFD v režimu echo. V tomto případě není vyžadována speciální zpětná vazba ve formě TCA nebo podobných zpráv - je zachována izolace domén selhání. K vyhodnocení stavu tunelu také nevyžaduje přítomnost uživatelského provozu.
• BFD časovače je možné doladit pro regulaci rychlosti odezvy a citlivosti algoritmu na degradaci komunikačního kanálu z několika sekund na minuty.

  

• V době psaní tohoto článku je v každém tunelu pouze jedna relace BFD. To potenciálně vytváří menší granularitu analýzy stavu tunelu. Ve skutečnosti se to může stát omezením pouze v případě, že používáte připojení WAN založené na MPLS L2/L3 VPN s dohodnutou QoS SLA – pokud označení DSCP provozu BFD (po zapouzdření v IPSec/GRE) odpovídá frontě s vysokou prioritou v sítě telekomunikačního operátora, pak to může ovlivnit přesnost a rychlost detekce degradace u provozu s nízkou prioritou. Zároveň je možné změnit výchozí označení BFD pro snížení rizika takových situací. V budoucích verzích softwaru Cisco SD-WAN se očekávají vyladěnější nastavení BFD a také možnost spouštět více relací BFD v rámci stejného tunelu s individuálními hodnotami DSCP (pro různé aplikace).
• BFD navíc umožňuje odhadnout maximální velikost paketů, které lze přenést konkrétním tunelem bez fragmentace. To umožňuje SD-WAN dynamicky upravovat parametry, jako je MTU a TCP MSS Adjust, aby bylo možné co nejlépe využít dostupnou šířku pásma na každém spoji.
• V SD-WAN je k dispozici také možnost synchronizace QoS od telekomunikačních operátorů, a to nejen na základě polí L3 DSCP, ale také na základě hodnot L2 CoS, které mohou být automaticky generovány v pobočkové síti specializovanými zařízeními - například IP telefony

Jak se liší možnosti, metody definování a aplikace zásad AppQ?

Zásady DMVPN/PfR:

• Definuje se na směrovačích centrální pobočky prostřednictvím příkazového řádku CLI nebo konfiguračních šablon CLI. Generování šablon CLI vyžaduje přípravu a znalost syntaxe zásad.

  

• Definováno globálně bez možnosti individuální konfigurace/změny na požadavky jednotlivých segmentů sítě.
• V grafickém rozhraní není k dispozici interaktivní generování zásad.
• Sledování změn, dědičnost a vytváření více verzí zásad pro rychlé přepínání nejsou poskytovány.
• Distribuováno automaticky na routery vzdálených poboček. V tomto případě se používají stejné komunikační kanály jako pro přenos uživatelských dat. Pokud mezi centrální a vzdálenou pobočkou neexistuje komunikační kanál, distribuce/změna politik není možná.
• Používají se na každém routeru a v případě potřeby upravují výsledek standardních směrovacích protokolů s vyšší prioritou.
• V případech, kdy všechna propojení WAN poboček zaznamenají významnou ztrátu provozu, nejsou poskytovány žádné kompenzační mechanismy.

Zásady SD-WAN:

• Definováno v grafickém uživatelském rozhraní vManage prostřednictvím průvodce interaktivní šablonou.
• Podporuje vytváření více politik, kopírování, dědění, přepínání mezi politikami v reálném čase.
• Podporuje individuální nastavení zásad pro různé segmenty sítě (větve)
• Jsou distribuovány pomocí jakéhokoli dostupného signálového kanálu mezi řadičem a routerem a/nebo vSmart – nezávisí přímo na konektivitě datové roviny mezi routery. To samozřejmě vyžaduje IP konektivitu mezi samotným routerem a ovladači.

  

• Pro případy, kdy všechny dostupné větve větve zažívají významné ztráty dat překračující přijatelné prahové hodnoty pro kritické aplikace, je možné použít další mechanismy, které zvyšují spolehlivost přenosu:
  • FEC (Forward Error Correction) – používá speciální redundantní kódovací algoritmus. Při přenosu kritického provozu přes kanály s významným procentem ztrát lze FEC automaticky aktivovat a v případě potřeby umožňuje obnovit ztracenou část dat. To mírně zvyšuje použitou přenosovou šířku pásma, ale výrazně zlepšuje spolehlivost.

    

  • Duplikace datových toků – Kromě FEC může politika zajistit automatickou duplikaci provozu vybraných aplikací v případě ještě vážnější úrovně ztrát, které nemůže FEC kompenzovat. V tomto případě budou vybraná data přenášena všemi tunely směrem k přijímací pobočce s následnou deduplikací (zahazováním nadbytečných kopií paketů). Mechanismus výrazně zvyšuje využití kanálu, ale také výrazně zvyšuje spolehlivost přenosu.

Možnosti Cisco SD-WAN, bez přímých analogů v DMVPN/PfR

Architektura řešení Cisco SD-WAN v některých případech umožňuje získat schopnosti, které jsou buď extrémně obtížně implementovatelné v rámci DMVPN/PfR, nebo jsou nepraktické kvůli požadovaným mzdovým nákladům, nebo jsou zcela nemožné. Pojďme se podívat na ty nejzajímavější z nich:

Dopravní inženýrství (TE)

TE zahrnuje mechanismy, které umožňují provozu odbočit ze standardní cesty tvořené směrovacími protokoly. TE se často používá k zajištění vysoké dostupnosti síťových služeb prostřednictvím schopnosti rychle a/nebo proaktivně přenést kritický provoz na alternativní (nesouvisející) přenosovou cestu, aby byla zajištěna lepší kvalita služeb nebo rychlost obnovy v případě selhání. na hlavní cestě.

Obtížnost implementace TE spočívá v nutnosti předem vypočítat a rezervovat (prověřit) alternativní cestu. V MPLS sítích telekomunikačních operátorů je tento problém řešen pomocí technologií jako MPLS Traffic-Engineering s rozšířeními o protokoly IGP a protokol RSVP. V poslední době je také stále populárnější technologie Segment Routing, která je více optimalizována pro centralizovanou konfiguraci a orchestraci. V klasických sítích WAN tyto technologie obvykle nejsou zastoupeny nebo jsou omezeny na použití mechanismů hop-by-hop, jako je Policy-Based Routing (PBR), které jsou schopné větvit provoz, ale implementují to na každém routeru samostatně – bez nutnosti zohlednit celkový stav sítě nebo výsledek PBR v předchozích nebo následujících krocích. Výsledek použití těchto možností TE je zklamáním - MPLS TE se vzhledem ke složitosti konfigurace a provozu používá zpravidla pouze v nejkritičtější části sítě (jádru) a PBR se používá na jednotlivých routerech bez možnost vytvořit jednotnou politiku PBR pro celou síť. Je zřejmé, že to platí také pro sítě založené na DMVPN.

SD-WAN v tomto ohledu nabízí mnohem elegantnější řešení, které se nejen snadno konfiguruje, ale také mnohem lépe škáluje. To je výsledkem použitých architektur řídicí roviny a politické roviny. Implementace politické roviny v SD-WAN vám umožní centrálně definovat politiku TE – jaký provoz je zajímavý? pro jaké VPN? Přes které uzly/tunely je nutné nebo naopak zakázáno vytvořit alternativní trasu? Na druhé straně centralizace správy řídicí roviny založená na ovladačích vSmart vám umožňuje upravovat výsledky směrování, aniž byste se museli uchylovat k nastavení jednotlivých zařízení – směrovače již vidí pouze výsledek logiky, která byla vygenerována v rozhraní vManage a přenesena k použití do vSmart.

Řetězení služeb

Vytvoření servisních řetězců je v klasickém směrování ještě pracnější úkol než již popsaný mechanismus Traffic-Engineering. V tomto případě je skutečně nutné nejen vytvořit speciální trasu pro konkrétní síťovou aplikaci, ale také zajistit schopnost odstranit provoz ze sítě na určitých (nebo všech) uzlech sítě SD-WAN pro zpracování speciální aplikace nebo služba (Firewall, Balancing, Caching, Inspection traffic atd.). Zároveň je nutné mít možnost kontrolovat stav těchto externích služeb, aby nedocházelo k black-holing situacím, a také jsou zapotřebí mechanismy, které umožní takové externí služby stejného typu umístit do různých geografických lokalit. se schopností sítě automaticky vybrat nejoptimálnější obslužný uzel pro zpracování provozu konkrétní pobočky. V případě Cisco SD-WAN je toho docela snadné dosáhnout vytvořením vhodné centralizované politiky, která „slepí“ všechny aspekty cílového servisního řetězce do jednoho celku a automaticky změní datovou rovinu a logiku řídicí roviny pouze tam, kde a když je to nutné.

Schopnost vytvářet geodistribuované zpracování provozu vybraných typů aplikací v určité posloupnosti na specializovaných (avšak nesouvisejících se samotnou sítí SD-WAN) zařízení je snad nejnázornější ukázkou výhod Cisco SD-WAN oproti klasickým technologie a dokonce i některá alternativní SD řešení -WAN od jiných výrobců.

Výsledek?

Je zřejmé, že jak DMVPN (s nebo bez Performance Routing), tak Cisco SD-WAN vyřešit velmi podobné problémy ve vztahu k distribuované síti WAN organizace. Přitom výrazné architektonické a funkční rozdíly v technologii Cisco SD-WAN vedou k procesu řešení těchto problémů na jinou kvalitativní úroveň. Abychom to shrnuli, můžeme si všimnout následujících významných rozdílů mezi technologiemi SD-WAN a DMVPN/PfR:

• DMVPN/PfR obecně využívají léty prověřené technologie pro budování overlay VPN sítí a z hlediska datové roviny jsou podobné modernější technologii SD-WAN, existuje však řada omezení v podobě povinné statické konfigurace. routerů a výběr topologií je omezen na Hub-n-Spoke. Na druhou stranu má DMVPN/PfR některé funkce, které v rámci SD-WAN zatím nejsou dostupné (mluvíme o BFD pro jednotlivé aplikace).
• V rámci řídicí roviny se technologie zásadně liší. S přihlédnutím k centralizovanému zpracování signalizačních protokolů umožňuje SD-WAN zejména výrazně zúžit domény selhání a „oddělit“ proces přenosu uživatelského provozu od signalizační interakce – dočasná nedostupnost řadičů nemá vliv na schopnost přenášet uživatelský provoz . Dočasná nedostupnost kterékoli pobočky (včetně té centrální) přitom nijak neovlivňuje schopnost ostatních poboček vzájemné interakce a controllerů.
• Architektura pro tvorbu a aplikaci politik řízení provozu v případě SD-WAN je také lepší než v DMVPN/PfR - mnohem lépe je implementována georezervace, chybí připojení k Hubu, existuje více příležitostí pro jemné -tuning politik, seznam implementovaných scénářů řízení provozu je také mnohem větší.
• Proces orchestrace řešení je také výrazně odlišný. DMVPN předpokládá přítomnost dříve známých parametrů, které se musí nějak promítnout do konfigurace, což poněkud omezuje flexibilitu řešení a možnost dynamických změn. SD-WAN je zase založen na paradigmatu, že v počátečním okamžiku připojení router „neví nic“ o svých řadičích, ale ví „koho se můžete zeptat“ – to stačí nejen k automatickému navázání komunikace s řadičů, ale také k automatickému vytvoření plně propojené topologie datové roviny, kterou lze následně flexibilně konfigurovat/měnit pomocí politik.
• Pokud jde o centralizovanou správu, automatizaci a monitorování, očekává se, že SD-WAN překoná možnosti DMVPN/PfR, které se vyvinuly z klasických technologií a více se spoléhají na příkazový řádek CLI a použití systémů NMS založených na šablonách.
• V SD-WAN ve srovnání s DMVPN dosáhly požadavky na zabezpečení jiné kvalitativní úrovně. Hlavními principy jsou nulová důvěra, škálovatelnost a dvoufaktorová autentizace.

Tyto jednoduché závěry mohou vyvolat mylný dojem, že vytvoření sítě založené na DMVPN/PfR dnes ztratilo veškerý význam. To samozřejmě není úplně pravda. Například v případech, kdy síť používá mnoho zastaralých zařízení a neexistuje způsob, jak je nahradit, DMVPN vám umožní kombinovat „stará“ a „nová“ zařízení do jediné geograficky distribuované sítě s mnoha popsanými výhodami. výše.

Na druhou stranu je třeba připomenout, že všechny současné podnikové routery Cisco založené na IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) dnes podporují jakýkoli provozní režim – jak klasické směrování, tak DMVPN a SD-WAN – výběr je dán aktuálními potřebami a pochopením, že s použitím stejného vybavení můžete kdykoli začít směřovat k pokročilejším technologiím.

Zdroj: www.habr.com