Ořeže Cisco SD-WAN větev, na které sedí DMVPN?

Od srpna 2017, kdy společnost Cisco získala společnost Viptela, se hlavní technologií pro budování distribuovaných podnikových sítí stala Cisco SD-WAN. V uplynulých třech letech technologie SD-WAN prošla mnoha změnami, jak kvalitativními, tak kvantitativními. Výrazně se rozšířily funkční možnosti a byla zavedena podpora pro klasické směrovače sérií Cisco ISR 1000, ISR 4000, ASR 1000 a virtuální CSR 1000v. Zatímco mnoho zákazníků a partnerů Cisco se i nadále ptá – v čem se Cisco SD-WAN liší od již známých přístupů založených na technologiích jako je Cisco DMVPN a Cisco Performance Routing a jak důležité tyto rozdíly jsou?

Je třeba ihned poznamenat, že před příchodem SD-WAN do portfolia Cisco, DMVPN společně s PfR tvořily klíčovou část architektury Cisco IWAN (Intelligent WAN), která byla svým způsobem předchůdcem plnohodnotné technologie SD-WAN. Přestože existují podobnosti jak v řešených úlohách, tak ve způsobech jejich řešení, IWAN nedosáhl potřebné úrovně automatizace, flexibility a škálovatelnosti pro SD-WAN, a vývoj IWAN se v průběhu času výrazně zpomalil. Přesto samotné technologie, které tvoří IWAN, nikam nezmizely a mnoho zákazníků je stále úspěšně používá, včetně na moderním vybavení. Vznikla tak zajímavá situace – stejné vybavení Cisco umožňuje vybrat tu nejvhodnější technologii pro budování WAN (tradiční, DMVPN+PfR nebo SD-WAN) v souladu s požadavky a očekáváními zákazníků.

Tento článek nemá v úmyslu podrobně rozebírat všechny charakteristiky technologií Cisco SD-WAN a DMVPN (společně nebo bez Performance Routing) – pro to je k dispozici obrovské množství dokumentů a materiálů. Hlavním cílem je pokusit se zhodnotit klíčové rozdíly těchto technologií. Než však přejdeme k diskusi o těchto rozdílech, připomeňme si stručně samotné technologie.

Co je Cisco DMVPN a k čemu slouží?

Cisco DMVPN řeší problém dynamického (= škálovatelného) připojení sítě vzdálené pobočky k síti centrálního kanceláře firmy při použití libovolných typů komunikačních kanálů, včetně Internetu (= s šifrováním kanálu). Technicky je to realizováno vytvořením virtualizované překryvné sítě třídy L3. VPN v režimu bod — víc bodů (point-to-multipoint) s logickou topologií typu „Hvězda“ (Hub-n-Spoke). K tomu DMVPN využívá kombinaci následujících technologií:

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

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

• Pro vytvoření mezi pobočkového sítě je možné využít jakékoli komunikační kanály – vyhovuje vše, co je schopno zajistit IP konektivitu mezi pobočkami, přičemž provoz bude šifrován (kde je to nutné) a vyvažován (kde je to možné).
• Automaticky se vytváří plně propojená topologie mezi pobočkami. Přičemž mezi centrální a vzdálenou pobočkou – statické tunely, a mezi vzdálenými pobočkami – dynamické tunely na vyžádání (při přítomnosti provozu).
• Na směrovačích centrální a vzdálené pobočky se používá jednotná konfigurace s přesností na IP adress rozhraní. Díky použití mGRE není potřeba individuální konfigurace desítek, stovek nebo dokonce tisíců tunelů. To vede k dobré škálovatelnosti při správném designu.

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

Při použití DMVPN na mezi pobočkové síti zůstává nevyřešená jedna nesmírně důležitá otázka – jak dynamicky vyhodnotit stav každého z DMVPN tunelů z hlediska splnění požadavků pro kritický provoz naší organizace a opět na základě takového hodnocení dynamicky rozhodnout o přesměrování? Skutečnost je taková, že DMVPN se v této části od klasického směrování příliš neliší – nejlepší, co lze udělat, je nastavit mechanismy QoS, které umožní prioritizovat provoz v odchozím směru, ale jakýmkoli způsobem nezohledňují stav celé cesty v daném okamžiku.

A co dělat, pokud kanál degraduje částečně, a ne úplně – jak to odhalit a zhodnotit? DMVPN to samo o sobě neumí. Vzhledem k tomu, že kanály spojující pobočky mohou procházet přes zcela různé poskytovatele služeb a používat zcela různé technologie, stává se tento úkol velmi netradičním. A tady přichází na pomoc technologie Cisco Performance Routing, která v té době již prošla několika fázemi vývoje.

Úkolem Cisco Performance Routing (dále PfR) je měření stavu cest (tunelů) procházení provozu na základě klíčových metrik důležitých pro síťové aplikace – zpoždění, variabilita zpoždění (jitter) a ztráty paketů (v procentech). Dále může být měřena používaná šířka pásma. Tato měření probíhají co nejblíže skutečnému času (pokud to je možné a opodstatněné) a výsledky těchto měření umožňují směrovači využívajícímu PfR dynamicky přijímat rozhodnutí o nutnosti změny směrování určitého typu provozu.

Tímto způsobem lze úkol kombinace DMVPN/PfR stručně charakterizovat následujícím způsobem:

• Umožnit zákazníkovi využívat v WAN sítích jakékoli komunikační kanály
• Zajistit co nejlepší kvalitu důležitých aplikací na těchto kanálech

Co je to Cisco SD-WAN?

Cisco SD-WAN je technologie, která využívá přístup SDN k vytváření a provozu WAN sítě organizace. To mimo jiné znamená využití takzvaných kontrolerů (softwarových prvků), které zajišťují centralizovanou orchestraci a automatizovanou konfiguraci všech komponentů řešení. Na rozdíl od klasického SDN (ve stylu Clean Slate) se v Cisco SD-WAN používá více typů kontrolerů, přičemž každý z nich má svou roli – to bylo záměrně uděláno s cílem zajistit lepší škálovatelnost a geo-rezervaci.

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

Diskuse o rozdílech

Pokud nyní začneme analyzovat rozdíly mezi těmito technologiemi, budou patřit do jedné z kategorií:

• Architektonické rozdíly – jak jsou funkce rozděleny mezi různé komponenty řešení, jak je organizována interakce těchto komponent a jak to ovlivňuje možnosti a flexibilitu technologie?
• Funkční možnosti – co může jedna technologie, co druhá nemůže? A je to skutečně tak důležité?

V čem se skrývají architektonické rozdíly a jsou skutečně důležité?

V každé z uvedených technologií existuje řada "hybných částí", které mají odlišnou roli i principy vzájemné interakce. Od toho, jak dobře jsou tyto principy promyšleny, závisí přímo škálovatelnost, odolnost vůči výpadkům a celková efektivita řešení.

Pojďme se podívat na různé aspekty architektury podrobněji:

Data-plane – část řešení zodpovědná za přenos uživatelského provozu mezi zdrojem a příjemcem. V DMVPN a SD-WAN je realizována téměř shodně na samotných směrovačích na základě Multipoint GRE tunelů. Rozdíl spočívá v tom, jakým způsobem se formuje potřebná sada parametrů těchto tunelů:

• v DMVPN/PfR – to je výhradně dvoustupňová hierarchie uzlů s topologií typu "Hvězda" nebo Hub-n-Spoke. Je nutná statická konfigurace Hubu a statické propojení Spoke s Hubem, stejně jako interakce protokolu NHRP pro vytvoření data-plane konektivity. V důsledku toho jsou změny na Hubu, spojené například se změnou/připojením nových WAN kanálů nebo změny parametrů stávajících, výrazně ztíženy.
• v SD-WAN – to je zcela dynamický model detekce parametrů vytvářených tunelů s oporou na control-plane (protokol OMP) a orchestration-plane (interakce s kontrolérem vBond pro úkoly detekce kontrolérů a NAT traversal). Přitom mohou být použity jakékoli překryvné topologie, včetně hierarchických. V rámci nastavené překryvné topologie tunelů je možná flexibilní konfigurace logické topologie v každém jednotlivém VPN (VRF).

Control-plane – funkce výměny, filtrování a modifikace směrovací a jiné informace mezi komponentami řešení.

• v DMVPN/PfR – probíhá pouze mezi směrovači Hub a Spoke. Přímá výměna směrovacích informací mezi Spoke není možná. V důsledku toho bez funkčního Hubu není možné fungování control-plane a data-plane., což klade na Hub dodatečné požadavky na vysokou dostupnost, které nejsou vždy splnitelné.
• v SD-WAN – control-plane není nikdy realizováno přímo mezi směrovači – interakce probíhá na základě protokolu OMP a nutně je realizována prostřednictvím specifického typu řídicího prvku vSmart, což zajišťuje možnost vyvážení, geo-rezervace a centralizovaného řízení signální zátěže. Další zvláštností protokolu OMP je jeho značná odolnost vůči ztrátám a nezávislost na rychlosti spojení s řídicími prvky (v rozumných mezích, samozřejmě). To stejně úspěšně umožňuje umístit řídicí prvky SD-WAN do veřejných nebo soukromých cloudů s přístupem přes Internet.

Policy-plane – část řešení odpovídající za definování, šíření a aplikaci politik řízení provozu v distribuované síti.

• DMVPN – je fakticky omezeno politikami kvality služeb (QoS), které jsou nastavovány individuálně na každém směrovači prostřednictvím CLI nebo šablon Prime Infrastructure.
• DMVPN/PfR – politiky PfR jsou utvářeny na centralizovaném směrovači Master Controller (MC) prostřednictvím CLI a následně jsou automaticky distribuovány do pobočkových MC. Přitom se používají stejné cesty pro přenos politik, jaké jsou pro data-plane. Není možné oddělit výměnu politik, směrovacích informací a uživatelských dat. Distribuce politik zahrnuje povinnou IP konektivitu mezi Hub a Spoke. Přičemž funkce MC může být v případě potřeby spojena se směrovačem DMVPN. Je možné (ale ne nutné) používat šablony Prime Infrastructure pro centralizované utváření politik. Důležitou zvláštností je, že politika je utvářena globálně pro celou síť stejně – individuální politiky pro jednotlivé segmenty nejsou podporovány..
• SD-WAN – Politiky správy provozu a kvality služeb jsou centralizovaně řízeny prostřednictvím grafického rozhraní Cisco vManage, které je dostupné také přes Internet (pokud je to potřeba). Rozšiřují se po signálních kanálech přímo nebo zprostředkovaně prostřednictvím řadičů vSmart (závisí na typu politiky). Nezávisí na datové konektivitě mezi směrovači, protože využívají všechny dostupné cesty přenosu provozu mezi řadičem a směrovačem.

  Pro různé segmenty sítě je možné flexibilně vytvářet různé politiky – rozsah použití politiky je definován mnoha jedinečnými identifikátory, které jsou v řešení předpokládány – číslo pobočky, typ aplikace, směr pohybu provozu atd.

Orchestration-plane – Mechanismy, které umožňují komponentům dynamicky se navzájem objevit, nakonfigurovat a koordinovat následnou interakci.

• v DMVPN/PfR Vzájemné objevování směrovači je založeno na statické konfiguraci Hub zařízení a odpovídající konfiguraci Spoke zařízení. Dynamické objevování probíhá pouze pro Spoke, který hlásí své spojovací parametry Hub zařízení, které je předtím vloženo do konfigurace Spoke. Bez IP konektivity Spoke s alespoň jedním Hubem není možné vytvořit ani datovou, ani řídicí rovinu.
• v SD-WAN Orkestrace komponent řešení probíhá s využitím řadiče vBond, se kterým musí mít každý komponent (směrovače a řadiče vManage/vSmart) předem nastavenou IP konektivitu.

  Zpočátku komponenty nevědí o parametrech připojení k sobě navzájem – pro to potřebují zprostředkovatele-orkestrátora vBond. Obecný princip je následující – každý komponent v počáteční fázi zjistí (automaticky nebo staticky) pouze parametry připojení k vBond, poté vBond informuje směrovač o řadičích vManage a vSmart (dříve objevených), což umožňuje automatické vytvoření všech potřebných signálních spojení.

  Dalším krokem je, že nový směrovač zjistí informace o ostatních směrovačích v síti prostřednictvím OMP výměny s řídicím systémem vSmart. Takto směrovač, který ze začátku neví nic o parametrech sítě, dokáže automaticky objevit a připojit se k řídicím systémům a poté také automaticky zjistit a vytvořit konektivitu s ostatními směrovači. Přitom parametry připojení všech komponentů jsou na začátku neznámé a mohou se měnit během provozu.

Správní vrstva – část řešení, která zajišťuje centralizované řízení a monitoring.

• DMVPN/PfR – specializované řešení pro správní vrstvu není určeno. Pro základní automatizaci a monitoring je možné použít produkty, jako je Cisco Prime Infrastructure. Každý směrovač má možnost správy prostřednictvím příkazového řádku CLI. Integrace s externími systémy přes API není plánována.
• SD-WAN – veškerá standardní interakce a monitoring se provádí centralizovaně přes grafické rozhraní řídicího systému vManage. Všechny funkce řešení, bez výjimky, jsou dostupné k nastavení prostřednictvím vManage, jakož i prostřednictvím plně zdokumentované knihovny rozhraní REST API.

  Veškerá nastavení sítě SD-WAN ve vManage se soustředí na dvě hlavní konstrukce – tvorbu šablon zařízení (Device Template) a tvorbu politiky, která určuje logiku fungování sítě a zpracování provozu. Přitom vManage, přenášející politiky formulované administrátorem, automaticky vybírá, jaké změny a na jakých jednotlivých zařízeních/řídicích systémech je třeba provést, což výrazně zvyšuje efektivitu a škálovatelnost řešení.

  Přes rozhraní vManage je dostupné nejen nastavení řešení Cisco SD-WAN, ale také plnohodnotný monitoring stavu všech komponentů řešení, až po aktuální stav metrik jednotlivých tunelů a statistiku využití různých aplikací na základě analýzy DPI.

  I když je interakce centralizována, všechny komponenty (kontroléry a směrovače) mají také plně funkční příkazovou řádku CLI, která je nezbytná v průběhu implementace nebo v případě nouzových situací pro místní diagnostiku. V běžném režimu (při dostupnosti signálního kanálu mezi komponenty) je příkazová řádka na směrovačích dostupná pouze pro diagnostiku a není přístupná pro provádění místních změn, což zaručuje místní bezpečnost a jediný zdroj změn v takové síti – vManage.

Integrovaná bezpečnost – toto by mělo zahrnovat nejen ochranu uživatelských dat při přenosu přes veřejné kanály, ale také celkovou bezpečnost WAN sítě postavené na vybrané technologii.

• v DMVPN/PfR je stanovena možnost šifrování uživatelských dat a signálních protokolů. Při používání určitých modelů směrovačů jsou navíc k dispozici funkce firewallu s inspekcí provozu, IPS/IDS. Existuje možnost segmentace pobočkových sítí s využitím VRF. Je k dispozici autentizace (jednofaktorová) kontrolních protokolů.

  Přitom je vzdálený směrovač standardně považován za důvěryhodný prvek sítě – t.j. nepředpokládají se a nezohledňují se případy fyzické kompromitace jednotlivých zařízení a možnost neoprávněného přístupu k nim, neexistuje dvoufaktorová autentizace komponent řešení, což v případě geograficky rozptýlené sítě může představovat vážná dodatečná rizika.

• v SD-WAN podobně jako u DMVPN je stanovena možnost šifrování uživatelských dat, ale s výrazně rozšířenými funkcemi síťové bezpečnosti a L3/VRF segmentace (MAC, IPS/IDS, filtrování URL, filtrování DNS, AMP/TG, SASE, TLS/SSL proxy atd.). Při tom je výměna šifrovacích klíčů prováděna efektivněji prostřednictvím vSmart kontrolérů (a ne přímo), po předem stanovených signálních kanálech zabezpečených DTLS/TLS šifrováním na základě bezpečnostních certifikátů. Což na oplátku zaručuje bezpečnost takové výměny a zajišťuje lepší škálovatelnost řešení až do desítek tisíc zařízení v jedné síti.

  Všechna signální spojení (řadič-řadič, řadič-router) jsou také zabezpečena na základě DTLS/TLS. Routery jsou vybaveny bezpečnostními certifikáty při výrobě s možností výměny/prodloužení. Dvoufaktorová autentizace je dosažena splněním dvou podmínek současně pro možnost fungování routeru/řadiče v síti SD-WAN:

  • Platný bezpečnostní certifikát
  • Výslovné a uvědomělé zařazení každého komponentu administrátorem do "bílého" seznamu povolených zařízení.

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

Při přechodu k diskuzi o funkčních rozdílech je třeba poznamenat, že mnohé z nich vyplývají z architektonických — není tajemstvím, že při vytváření architektury řešení se vývojáři odvíjejí od těch možností, které chtějí na konci získat. Pojďme se podívat na nejvýznamnější rozdíly dvou technologií.

AppQ (Kvalita aplikace) – funkce zajištění kvality přenosu dat obchodních aplikací

Klíčové funkce zvažovaných technologií jsou zaměřeny na to, aby co nejvíce zlepšily uživatelský zážitek při používání obchodně kritických aplikací v distribuované síti. To je zvlášť důležité v podmínkách, kdy část infrastruktury není pod kontrolou IT nebo dokonce nezaručuje úspěšný přenos dat.

DMVPN sama o sobě neposkytuje takové mechanismy. Nejlepší, co lze udělat v klasické DMVPN síti, je klasifikovat odchozí provoz podle aplikací a upřednostnit ho při přenosu směrem k WAN kanálu. Výběr DMVPN tunelu je v tomto případě určen pouze jeho dostupností a výsledkem fungování směrovacích protokolů. Přitom se nijak nezohledňuje průchozí stav cesty/tunelu a jeho možná částečná degradace z hlediska klíčových metrik důležitých pro síťové aplikace – latence, variace latence (jitter) a ztráty (%). V této souvislosti ztrácí přímé srovnání klasického DMVPN se SD-WAN v oblasti řešení úloh AppQ jakýkoliv smysl – DMVPN tuto úlohu nemůže vyřešit. Přidáním technologie Cisco Performance Routing (PfR) do této souvislosti se situace mění a srovnání s Cisco SD-WAN se stává smysluplnějším.

Než přejdeme k diskusi o rozdílech, krátce o tom, v čem si technologie jsou podobné. Takže obě technologie:

• mají mechanismus, který umožňuje dynamicky posoudit stav každého nainstalovaného tunelu na základě určitých metrik – minimálně zpoždění, variabilita zpoždění a ztráty paketů (%)
• používají určitý soubor nástrojů na vytváření, distribuci a aplikaci pravidel (politik) správy provozu s ohledem na výsledky měření stavu klíčových metrik tunelů.
• k lasifikují aplikací provoz na úrovních L3-L4 (DSCP) modelu OSI nebo podle L7 signatur aplikací na základě mechanismů DPI integrovaných v routeru.
• umožňují pro významné aplikace definovat přípustné prahové hodnoty metrik, výchozí pravidla pro přenos dat a pravidla pro přesměrování dat při překročení prahových hodnot.
• při enkapsulaci provozu v GRE/IPSec využívají již zavedený průmyslový mechanismus přenosu interního DSCP označení do externího GRE/IPSec hlavičky paketů, což umožňuje synchronizaci politik QoS organizace a telekomunikačního operátora (za předpokladu odpovídající SLA).

Jak se liší mechanismy hodnocení průchodných metrik SD-WAN a DMVPN/PfR?

DMVPN/PfR

• Pro hodnocení standardních metrik stavu tunelů se používají jak aktivní, tak pasivní softwarové senzory (Probes). Aktivní – na základě uživatelského provozu, pasivní emulují takový provoz (při jeho nepřítomnosti).
• Jemné nastavení časovačů a podmínek detekce degradace není k dispozici – algoritmus je pevně stanoven.
• Dále je k dispozici měření využité šířky pásma v odchozím směru. Co dodává DMVPN/PfR dodatečnou flexibilitu pro řízení provozu.
• Přitom některé mechanismy PfR se při překročení metrik spoléhají na zpětnou signální vazbu ve formě speciálních TCA (Threshold Crossing Alert) zpráv, které musí vycházet od příjemce dat směrem k zdroji, což na druhou stranu předpokládá, že stavy měřených kanálů musí být alespoň dostatečné k přenosu takových TCA zpráv. Což ve většině případů není problém, ale zjevně to nelze zaručit.

SD-WAN

• Pro průběžné hodnocení 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 – dochází k udržení izolace domén selhání. Také není třeba přítomnost uživatelského provozu pro hodnocení stavu tunelu.
• Existuje možnost podrobného nastavení časovačů BFD pro regulaci rychlosti akce a citlivosti algoritmu na degradaci komunikačního kanálu od několika sekund po minuty.

  

• K datu psaní článku je v každém z tunelů navržena pouze jedna BFD relace. To potenciálně vytváří menší granularitu při analýze stavu tunelu. Ve skutečnosti se to může stát omezením pouze v případě použití WAN připojení na bázi MPLS L2/L3 VPN se sjednaným QoS SLA — pokud bude DSCP označení BFD provozu (po zapouzdření v IPSec/GRE) shodovat s vysoce prioritní frontou v síti provozovatele telekomunikací, může to ovlivnit přesnost a rychlost detekce degradace pro nízkoprioritní provoz. Současně existuje možnost změny výchozího označení BFD pro snížení rizika vzniku takových situací. V následujících verzích softwaru Cisco SD-WAN se očekává zavedení podrobnějšího nastavení BFD a také možnost spuštění několika BFD relací v rámci jednoho tunelu s individuálními DSCP hodnotami (pro různé aplikace).
• BFD rovněž umožňuje posoudit maximální velikost paketu, který je možné přenášet daným tunelem bez fragmentace. To umožňuje SD-WAN dynamicky nastavovat takové parametry, jako je MTU a TCP MSS Adjust, aby co nejefektivněji využívalo dostupnou šířku pásma na každém kanálu.
• V SD-WAN je také k dispozici možnost synchronizace QoS s operátory telekomunikací nejen na základě pole L3 DSCP, ale také na základě hodnot L2 CoS, které mohou být automaticky vytvářeny ve firemní síti specializovanými zařízeními — například IP telefony.

Jak se liší možnosti, způsoby určení a aplikace politik AppQ?

Politiky DMVPN/PfR:

• Jsou určovány na routeru(-ech) centrální pobočky (CP) prostřednictvím příkazového řádku CLI nebo konfigurací na bázi CLI šablon. Tvorba CLI šablon vyžaduje přípravu a znalost syntaxe politik.

  

• Určují se globálně bez možnosti individuálního nastavení / změny podle požadavků jednotlivých segmentů sítě.
• Interaktivní vytváření politik v grafickém rozhraní není zajištěno.
• Sledování změn, dědění, vytváření více verzí politik pro rychlé přepínání není zajištěno.
• Rozšiřují se automaticky na routery vzdálených poboček. Přitom se používají ty samé komunikační kanály, které slouží k přenosu uživatelských dat. V případě absence komunikačního kanálu mezi centrální a vzdálenou pobočkou není možné rozšíření / změna politik.
• Používají se na každém routeru a v případě potřeby modifikují výsledek standardních směrovacích protokolů, přičemž mají vyšší prioritu.
• Pro případy, kdy všechny WAN kanály pobočky trpí výraznými ztrátami provozu, mechanismy kompenzace nejsou zajištěny..

Politiky SD-WAN:

• Definují se v grafickém rozhraní vManage prostřednictvím interaktivního šablonového průvodce.
• Podporují vytváření více politik, kopírování, dědění, přepínání mezi politikami v reálném čase.
• Podporují individuální nastavení politiky pro různé segmenty (pobočky) sítě.
• Distribuují se pomocí jakéhokoli dostupného signálního kanálu mezi kontrolérem a routerem a/nebo vSmart – nejsou přímo závislé na datové konektivitě mezi routery. Je však samozřejmě vyžadována IP konektivita mezi samotnými routery a kontroléry.

  

• Pro případy, kdy všechny dostupné kanály pobočky zažívají výrazné ztráty dat, které překračují povolené prahové hodnoty pro kritické aplikace, je možné použít další mechanismy zvyšující spolehlivost přenosu:
  • FEC (Forward Error Correction) – používá speciální algoritmus redundatního kódování. Při přenosu kritického provozu po kanálech se značným procentem ztrát může být FEC automaticky aktivován a umožňuje v případě potřeby obnovit ztracenou část dat. Přitom se mírně zvyšuje použité pásmo, ale výrazně se zvyšuje spolehlivost.

    

  • Duplikace datových toků – navíc k politice FEC může existovat automatické duplikování provozu vybraných aplikací v případě ještě závažnějších ztrát, které nelze kompenzovat pomocí FEC. V tomto případě budou vybraná data odesílána ve všech tunelech směrem k pobočné straně příjemce s následnou de-duplicitou (odstranění nadbytečných kopií paketů). Tento mechanismus výrazně zvyšuje využití kanálů, 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 možnosti, jejichž realizace v rámci DMVPN/PfR je buď extrémně složitá, nebo neefektivní kvůli nezbytným nákladům na práci, nebo dokonce zcela nemožná. Podívejme se na nejzajímavější z nich:

Traffic-Engineering (TE)

TE zahrnuje mechanismy, které umožňují odklonit provoz od standardní cesty, kterou vytvářejí směrovací protokoly. TE se často používá k zajištění vysoké dostupnosti sítových služeb, díky schopnosti rychle a/nebo předem přesměrovat důležitý provoz na alternativní (neprolínající) cestu přenosu, za účelem zajištění lepší kvality služby nebo rychlosti její obnovy v případě selhání hlavní cesty.

Složitost implementace TE spočívá v nutnosti předem vypočítat a rezervovat (zkontrolovat) alternativní cestu. V MPLS sítích telekomunikačních operátorů se tento úkol řeší pomocí technologií, jako je MPLS Traffic-Engineering s rozšířeními IGP protokolů a RSVP protokolu. V poslední době také získává na popularitě technologie Segment Routing, která je lépe optimalizována pro centralizované nastavení a orchestrace. V klasických WAN sítích tyto technologie obvykle nejsou přítomny nebo jsou omezeny na použití mechanismů hop-by-hop, jako je Policy-Based Routing (PBR), které dokážou odklonit provoz, ale realizují to na každém routeru zvlášť – bez ohledu na celkový stav sítě nebo výsledky PBR na předchozích či následujících krocích. Výsledek použití těchto variant TE je neuspokojivý – MPLS TE vzhledem k složitosti nastavení a provozu se obvykle používá pouze v nejkritičtější části sítě (jádro), zatímco PBR se využívá na jednotlivých routerech bez možnosti vytvořit nějakou jednotnou PBR politiku v celé síti. To se samozřejmě týká i sítí založených na DMVPN.

SD-WAN v tomto ohledu nabízí mnohem elegantnější řešení, které není jen snadno nastavitelné, ale také výrazně lépe škálovatelné. To je výsledkem použitých architektur control-plane a policy-plane. Implementace policy-plane v SD-WAN umožňuje centralizovaně definovat politiku TE – který provoz je zajímavý? pro jaké VPN? přes které uzly/tunely je nutné nebo naopak zakázáno vytvářet alternativní trasu? Zároveň centralizace řízení control-plane na bázi vSmart kontrolérů umožňuje modifikovat výsledky routingu, aniž by bylo nutné měnit nastavení jednotlivých zařízení – routery již vidí pouze výsledek té logiky, která byla vytvořena v rozhraní vManage a předána k použití na vSmart.

Služební řetězení

Vytváření servisních řetězců je ještě náročnější úkol v klasické routingu než již popsaný mechanismus Traffic-Engineering. V tomto případě je totiž třeba nejen vytvořit specifickou trasu pro určitou síťovou aplikaci, ale také zajistit možnost výstupu provozu ze sítě na určitých (nebo na všech) uzlech SD-WAN sítě pro zpracování specializovanou aplikací nebo službou (MPLS, vyvažování zátěže, cachování, inspekce provozu atd.). Je také nutné mít možnost kontrolovat stav těchto externích služeb, aby se předešlo situacím black-holing, a rovněž potřebné mechanismy pro umístění těchto homogenních externích služeb na různé geografické lokace s možností, aby síť automaticky vybírala nejoptimálnější servisní uzel pro zpracování provozu dané pobočky. V případě Cisco SD-WAN lze tohoto cíle snadno dosáhnout vytvořením odpovídající centralizované politiky, která „sespojuje“ všechny aspekty cíleného servisního řetězce do jednoho celku a automaticky mění logiku data-plane a control-plane pouze tam a tehdy, kde je to nezbytné.

Schopnost vytvořit geo-distribuované zpracování provozu vybraných typů aplikací v určité sekvenci na specializovaném (ale nesouvisejícím se samotnou sítí SD-WAN) vybavení – to je pravděpodobně nejvýstižnější ukázka výhod Cisco SD-WAN oproti klasickým technologiím a dokonce některým alternativním řešením SD-WAN od jiných výrobců.

Jaký je výsledek?

Je zřejmé, že DMVPN (samostatně nebo v kombinaci se Performance Routing) a Cisco SD-WAN řeší nakonec velmi podobné úkoly ve vztahu k distribuované WAN síti organizace. Zároveň však zásadní architektonické a funkční rozdíly technologie Cisco SD-WAN posouvají proces řešení těchto úkolů na jinou kvalitativní úroveň. Shrnutí ukazuje následující významné rozdíly mezi technologiemi SD-WAN a DMVPN/PfR:

• DMVPN/PfR v zásadě využívají osvědčené technologie pro budování překryvných VPN sítí a co se týče data-plane, jsou podobné modernější technologii SD-WAN. Nicméně existuje řada omezení, jako je povinná statická konfigurace směrovačů a výběr topologií je omezen na Hub-n-Spoke. Na druhé straně DMVPN/PfR nabízí některé funkční možnosti, které zatím nejsou v rámci SD-WAN dostupné (myšleno per-application BFD).
• V rámci control-plane technologie se zásadně liší. Díky centralizovanému zpracování signálních protokolů SD-WAN umožňuje výrazně zúžit domény selhání a "odpojit" proces přenosu uživatelského provozu od signální komunikace – dočasná nedostupnost kontrolérů nemá vliv na schopnost přenášet uživatelský provoz. Zároveň dočasná nedostupnost některé pobočky (včetně centrály) nijak neovlivňuje možnost ostatních poboček spolupracovat mezi sebou a s kontroléry.
• Architektura vytváření a uplatňování politik pro řízení provozu v případě SD-WAN také překonává tu v DMVPN/PfR – geo-redundance je realizována výrazně lépe, není vázána na Hub, je tu více možností pro jemné doladění politik a seznam realizovaných scénářů řízení provozu je také výrazně rozsáhlejší.
• Proces orchestrace řešení se také výrazně liší. DMVPN předpokládá existenci předem známých parametrů, které musí být nějakým způsobem odraženy v konfiguraci, což poněkud omezuje flexibilitu řešení a možnost dynamických změn. Naopak SD-WAN vychází z předpokladu, že v počátečním okamžiku připojení směrovač "neví nic" o svých kontrolérech, ale ví "kde se zeptat" – to je dostatečné nejen pro automatické navázání spojení s kontroléry, ale i pro automatické vytvoření plně propojené data-plane topologie, kterou lze následně flexibilně nastavit/změnit pomocí politik.
• V oblasti centralizovaného řízení, automatizace a monitorování SD-WAN očekávaně převyšuje možnosti DMVPN/PfR, které jsou výsledkem vývoje klasických technologií a do značné míry spoléhají na příkazový řádek CLI a používání systémů NMS založených na šablonách.
• V SD-WAN v porovnání s DMVPN se požadavky na bezpečnost dostaly na jinou kvalitativní úroveň. Hlavními principy jsou nulová důvěra, škálovatelnost a dvoufaktorová autentizace.

Z těchto jednoduchých závěrů může vzniknout mylný dojem, že vytvoření sítě na bázi DMVPN/PfR dnes ztratilo jakýkoli význam. To samozřejmě není úplně pravda. Například v případech, kdy se v síti používá mnoho zastaralého zařízení a není možné je nahradit, může DMVPN umožnit spojení „starých“ a „nových“ zařízení do jedné geograficky distribované sítě s mnoha výše uvedenými výhodami.

Na druhé straně je třeba mít na paměti, že všechny aktuální podnikové směrovače Cisco na bázi IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) dnes podporují jakýkoli pracovní režim – tedy jak klasické směrování, tak DMVPN i SD-WAN. Výběr je určen aktuálními potřebami a chápáním, že kdykoli na tomtéž zařízení lze začít směřovat k pokročilejší technologii.

Zdroj: habr.com