Kommer Cisco SD-WAN att skära av grenen som DMVPN sitter på?

Sedan augusti 2017, när Cisco förvärvade Viptela, har den huvudsakliga tekniken som erbjuds för att organisera distribuerade företagsnätverk blivit Cisco SD-WAN. Under de senaste 3 åren har SD-WAN-tekniken genomgått många förändringar, både kvalitativa och kvantitativa. Således har funktionaliteten utökats avsevärt och stöd har dykt upp på klassiska routrar i serien Cisco ISR 1000, ISR 4000, ASR 1000 och Virtual CSR 1000v. Samtidigt fortsätter många Cisco-kunder och partners att undra: vad är skillnaderna mellan Cisco SD-WAN och redan bekanta tillvägagångssätt baserade på teknologier som t.ex Cisco DMVPN и Cisco Performance Routing och hur viktiga är dessa skillnader?

Här bör vi omedelbart reservera oss för att innan SD-WAN kom till Ciscos portfölj, utgjorde DMVPN tillsammans med PfR en nyckeldel i arkitekturen Cisco IWAN (Intelligent WAN), som i sin tur var föregångaren till fullfjädrad SD-WAN-teknik. Trots den allmänna likheten mellan både de uppgifter som löses och metoderna för att lösa dem fick IWAN aldrig den nivå av automatisering, flexibilitet och skalbarhet som krävs för SD-WAN, och med tiden har utvecklingen av IWAN minskat avsevärt. Samtidigt har teknikerna som utgör IWAN inte försvunnit, och många kunder fortsätter att använda dem framgångsrikt, inklusive på modern utrustning. Som ett resultat har en intressant situation uppstått - samma Cisco-utrustning låter dig välja den mest lämpliga WAN-tekniken (klassisk, DMVPN+PfR eller SD-WAN) i enlighet med kundernas krav och förväntningar.

Artikeln har inte för avsikt att i detalj analysera alla funktioner i Cisco SD-WAN och DMVPN-teknik (med eller utan Performance Routing) - det finns en enorm mängd tillgängliga dokument och material för detta. Huvuduppgiften är att försöka utvärdera de viktigaste skillnaderna mellan dessa teknologier. Men innan vi går vidare till att diskutera dessa skillnader, låt oss kort komma ihåg själva teknologierna.

Vad är Cisco DMVPN och varför behövs det?

Cisco DMVPN löser problemet med dynamisk (= skalbar) anslutning av ett fjärranslutet filialnätverk till nätverket för ett företags centralkontor när du använder godtyckliga typer av kommunikationskanaler, inklusive Internet (= med kryptering av kommunikationskanalen). Tekniskt sett realiseras detta genom att skapa ett virtualiserat överlagringsnätverk av L3 VPN-klass i punkt-till-multipunkt-läge med en logisk topologi av typen "Star" (Hub-n-Spoke). För att uppnå detta använder DMVPN en kombination av följande teknologier:

• IP routing
• Multipoint GRE-tunnlar (mGRE)
• Next Hop Resolution Protocol (NHRP)
• IPSec Crypto-profiler

Vilka är de främsta fördelarna med Cisco DMVPN jämfört med klassisk routing med MPLS VPN-kanaler?

• För att skapa ett grennät är det möjligt att använda vilka kommunikationskanaler som helst - allt som kan tillhandahålla IP-anslutning mellan grenar är lämpligt, medan trafiken kommer att vara krypterad (där det behövs) och balanserad (där det är möjligt)
• En helt sammankopplad topologi mellan grenar bildas automatiskt. Samtidigt finns det statiska tunnlar mellan de centrala och avlägsna grenarna, och dynamiska tunnlar på begäran mellan de avlägsna grenarna (om det finns trafik)
• Routern för den centrala och fjärranslutna grenen har samma konfiguration upp till IP-adresserna för gränssnitten. Genom att använda mGRE finns det inget behov av att individuellt konfigurera tiotals, hundratals eller ens tusentals tunnlar. Som ett resultat, anständig skalbarhet med rätt design.

Vad är Cisco Performance Routing och varför behövs det?

När du använder DMVPN på ett grennät förblir en extremt viktig fråga olöst - hur man dynamiskt bedömer tillståndet för var och en av DMVPN-tunnlarna för att uppfylla kraven för trafik som är avgörande för vår organisation och, återigen, baserat på en sådan bedömning, dynamiskt göra ett beslut om omläggning? Faktum är att DMVPN i denna del skiljer sig lite från klassisk routing - det bästa som kan göras är att konfigurera QoS-mekanismer som gör att du kan prioritera trafik i utgående riktning, men som inte på något sätt kan ta hänsyn till tillståndet för hela vägen vid ett eller annat tillfälle.

Och vad ska man göra om kanalen försämras delvis och inte helt - hur upptäcker och utvärderar man detta? DMVPN själv kan inte göra detta. Med tanke på att kanalerna som förbinder grenar kan passera genom helt olika telekomoperatörer, med hjälp av helt olika tekniker, blir denna uppgift extremt icke-trivial. Och det är här Cisco Performance Routing-tekniken kommer till undsättning, som vid den tiden redan hade gått igenom flera utvecklingsstadier.

Uppgiften för Cisco Performance Routing (nedan kallat PfR) handlar om att mäta tillståndet för vägar (tunnlar) för trafik baserat på nyckelmått som är viktiga för nätverkstillämpningar - latens, latensvariation (jitter) och paketförlust (procent). Dessutom kan den använda bandbredden mätas. Dessa mätningar sker så nära realtid som möjligt och med rätta, och resultatet av dessa mätningar gör det möjligt för routern som använder PfR att dynamiskt fatta beslut om behovet av att ändra routingen för den eller den typen av trafik.

Sålunda kan uppgiften för DMVPN/PfR-kombinationen kort beskrivas enligt följande:

• Tillåt kunden att använda alla kommunikationskanaler på WAN-nätverket
• Säkerställ högsta möjliga kvalitet på kritiska applikationer på dessa kanaler

Vad är Cisco SD-WAN?

Cisco SD-WAN är en teknik som använder SDN-metoden för att skapa och driva en organisations WAN-nätverk. Detta innebär i synnerhet användningen av så kallade kontroller (mjukvaruelement), som tillhandahåller centraliserad orkestrering och automatiserad konfiguration av alla lösningskomponenter. Till skillnad från den kanoniska SDN (Clean Slate-stilen) använder Cisco SD-WAN flera typer av kontroller, som var och en utför sin egen roll - detta gjordes avsiktligt för att ge bättre skalbarhet och geo-redundans.

När det gäller SD-WAN förblir uppgiften att använda alla typer av kanaler och säkerställa driften av affärsapplikationer densamma, men samtidigt ökar kraven på automatisering, skalbarhet, säkerhet och flexibilitet för ett sådant nätverk.

Diskussion om skillnader

Om vi ​​nu börjar analysera skillnaderna mellan dessa tekniker kommer de att falla in i en av följande kategorier:

• Arkitektoniska skillnader - hur fördelas funktioner över olika komponenter i lösningen, hur är samspelet mellan sådana komponenter organiserat och hur påverkar detta teknikens möjligheter och flexibilitet?
• Funktionalitet – vad kan en teknik göra som en annan inte kan? Och är det verkligen så viktigt?

Vilka är de arkitektoniska skillnaderna och är de viktiga?

Var och en av dessa teknologier har många "rörliga delar" som skiljer sig inte bara i sina roller, utan också i hur de interagerar med varandra. Hur väl dessa principer är genomtänkta och den allmänna mekaniken i lösningen avgör direkt dess skalbarhet, feltolerans och totala effektivitet.

Låt oss titta på de olika aspekterna av arkitekturen mer i detalj:

Dataplan – en del av lösningen som ansvarar för att överföra användartrafik mellan källan och mottagaren. DMVPN och SD-WAN implementeras generellt identiskt på själva routrarna baserat på Multipoint GRE-tunnlar. Skillnaden är hur den nödvändiga uppsättningen parametrar för dessa tunnlar bildas:

• в DMVPN/PfR är en exklusivt två-nivå hierarki av noder med en Star eller Hub-n-Spoke topologi. Statisk konfiguration av hubben och statisk bindning av Spoke till hubben krävs, såväl som interaktion via NHRP-protokollet för att bilda dataplansanslutningar. Följaktligen, gör ändringar i navet betydligt svårarerelaterat till till exempel att byta/ansluta nya WAN-kanaler eller ändra parametrarna för befintliga.
• в SD-WAN är en helt dynamisk modell för att detektera parametrar för installerade tunnlar baserad på kontrollplan (OMP-protokoll) och orkestreringsplan (interaktion med vBond-styrenheten för kontrollerdetektering och NAT-traverseringsuppgifter). I det här fallet kan alla överlagrade topologier användas, inklusive hierarkiska. Inom den etablerade overlay-tunneltopologin är flexibel konfiguration av den logiska topologin i varje enskild VPN(VRF) möjlig.

Kontrollplan – funktioner för utbyte, filtrering och modifiering av routing och annan information mellan lösningskomponenter.

• в DMVPN/PfR – utförs endast mellan Hub- och Spoke-routrar. Direkt utbyte av routinginformation mellan Spokes är inte möjligt. Följaktligen, Utan en fungerande hubb kan kontrollplanet och dataplanet inte fungera, vilket ställer ytterligare höga tillgänglighetskrav på navet som inte alltid kan uppfyllas.
• в SD-WAN – kontrollplan utförs aldrig direkt mellan routrar – interaktion sker på basis av OMP-protokollet och utförs nödvändigtvis genom en separat specialiserad typ av vSmart-styrenhet, som ger möjlighet till balansering, georeservation och centraliserad kontroll av signalbelastning. En annan egenskap hos OMP-protokollet är dess betydande motstånd mot förluster och oberoende av hastigheten på kommunikationskanalen med styrenheter (inom rimliga gränser, förstås). Vilket lika framgångsrikt låter dig placera SD-WAN-kontroller i offentliga eller privata moln med åtkomst via Internet.

Policy-plan – en del av lösningen som ansvarar för att definiera, distribuera och tillämpa trafikhanteringspolicyer på ett distribuerat nätverk.

• DMVPN – begränsas effektivt av kvalitetspolicyer (QoS) som konfigurerats individuellt på varje router via CLI- eller Prime Infrastructure-mallarna.
• DMVPN/PfR – PfR-policyer bildas på den centraliserade Master Controller-routern (MC) via CLI och distribueras sedan automatiskt till filial-MC:er. I detta fall används samma policyöverföringsvägar som för dataplanet. Det finns ingen möjlighet att separera utbyte av policyer, routinginformation och användardata. Policyspridning kräver närvaro av IP-anslutning mellan Hub och Spoke. I detta fall kan MC-funktionen vid behov kombineras med en DMVPN-router. Det är möjligt (men inte nödvändigt) att använda Prime Infrastructure-mallar för centraliserad policygenerering. En viktig egenskap är att policyn utformas globalt i hela nätverket på samma sätt - Individuella policyer för enskilda segment stöds inte.
• SD-WAN – Trafikhantering och servicekvalitetspolicyer bestäms centralt genom Cisco vManage grafiska gränssnitt, tillgängligt även via Internet (om nödvändigt). De distribueras via signaleringskanaler direkt eller indirekt genom vSmart-kontroller (beroende på typen av policy). De är inte beroende av dataplansanslutningar mellan routrar, eftersom använda alla tillgängliga trafikvägar mellan styrenheten och routern.

  För olika nätverkssegment är det möjligt att flexibelt formulera olika policyer - policyns omfattning bestäms av många unika identifierare som tillhandahålls i lösningen - filialnummer, applikationstyp, trafikriktning, etc.

Orchestration-plan – mekanismer som tillåter komponenter att dynamiskt upptäcka varandra, konfigurera och koordinera efterföljande interaktioner.

• в DMVPN/PfR Ömsesidig upptäckt mellan routrar baseras på den statiska konfigurationen av Hub-enheter och motsvarande konfiguration av Spoke-enheter. Dynamisk upptäckt sker endast för Spoke, som rapporterar sina Hub-anslutningsparametrar till enheten, som i sin tur är förkonfigurerad med Spoke. Utan IP-anslutning mellan Spoke och minst en Hub är det omöjligt att bilda vare sig ett dataplan eller ett kontrollplan.
• в SD-WAN orkestrering av lösningskomponenter sker med hjälp av vBond-kontrollern, med vilken varje komponent (routrar och vManage/vSmart-kontroller) först måste upprätta IP-anslutning.

  Till en början känner inte komponenterna till varandras anslutningsparametrar - för detta behöver de vBond-förmedlande orkestrator. Den allmänna principen är som följer - varje komponent i den inledande fasen lär sig (automatiskt eller statiskt) endast om anslutningsparametrarna till vBond, sedan informerar vBond routern om vManage- och vSmart-kontrollerna (upptäckt tidigare), vilket gör det möjligt att automatiskt upprätta alla nödvändiga signalanslutningar.

  Nästa steg är att den nya routern lär sig om de andra routrarna i nätverket genom OMP-kommunikation med vSmart-styrenheten. Således kan routern, utan att först veta något alls om nätverksparametrarna, helt automatiskt upptäcka och ansluta till kontroller och sedan även automatiskt upptäcka och bilda uppkoppling med andra routrar. I detta fall är anslutningsparametrarna för alla komponenter initialt okända och kan ändras under drift.

Management-plan – en del av lösningen som ger centraliserad förvaltning och övervakning.

• DMVPN/PfR – ingen specialiserad hanteringsplanlösning tillhandahålls. För grundläggande automatisering och övervakning kan produkter som Cisco Prime Infrastructure användas. Varje router har möjlighet att styras via CLI-kommandoraden. Integrering med externa system via API tillhandahålls inte.
• SD-WAN – all regelbunden interaktion och övervakning utförs centralt via vManage-styrenhetens grafiska gränssnitt. Alla funktioner i lösningen, utan undantag, är tillgängliga för konfiguration via vManage, såväl som genom ett fullt dokumenterat REST API-bibliotek.

  Alla SD-WAN-nätverksinställningar i vManage kommer ner till två huvudkonstruktioner - bildandet av enhetsmallar (Device Template) och bildandet av en policy som bestämmer logiken för nätverksdrift och trafikbearbetning. Samtidigt väljer vManage, som sänder policyn som genereras av administratören, automatiskt vilka ändringar och på vilka enskilda enheter/kontroller som behöver göras, vilket avsevärt ökar effektiviteten och skalbarheten i lösningen.

  Genom vManage-gränssnittet är inte bara konfigurering av Cisco SD-WAN-lösningen tillgänglig, utan även full övervakning av status för alla komponenter i lösningen, ner till aktuellt tillstånd för mätvärden för enskilda tunnlar och statistik över användningen av olika applikationer baserat på DPI-analys.

  Trots centraliseringen av interaktionen har alla komponenter (kontroller och routrar) också en fullt fungerande CLI-kommandorad, vilket är nödvändigt vid implementeringsstadiet eller i nödfall för lokal diagnostik. I normalt läge (om det finns en signaleringskanal mellan komponenter) på routrar är kommandoraden endast tillgänglig för diagnostik och är inte tillgänglig för att göra lokala ändringar, vilket garanterar lokal säkerhet och den enda källan till ändringar i ett sådant nätverk är vManage.

Integrerad säkerhet – här bör vi prata inte bara om skyddet av användardata när de överförs över öppna kanaler, utan också om den övergripande säkerheten för WAN-nätverket baserat på den valda tekniken.

• в DMVPN/PfR Det är möjligt att kryptera användardata och signaleringsprotokoll. Vid användning av vissa routermodeller finns dessutom brandväggsfunktioner med trafikinspektion, IPS/IDS tillgängliga. Det är möjligt att segmentera filialnät med VRF. Det är möjligt att autentisera (enfaktors) kontrollprotokoll.

  I det här fallet betraktas fjärrroutern som ett pålitligt element i nätverket som standard - dvs. fall av fysisk kompromittering av enskilda enheter och möjligheten till obehörig åtkomst till dem antas eller beaktas inte; det finns ingen tvåfaktorsautentisering av lösningskomponenter, vilket i fallet med ett geografiskt distribuerat nätverk kan medföra betydande ytterligare risker.

• в SD-WAN analogt med DMVPN tillhandahålls möjligheten att kryptera användardata, men med avsevärt utökad nätverkssäkerhet och L3/VRF-segmenteringsfunktioner (brandvägg, IPS/IDS, URL-filtrering, DNS-filtrering, AMP/TG, SASE, TLS/SSL-proxy, etc.) d.). Samtidigt genomförs utbytet av krypteringsnycklar mer effektivt genom vSmart-kontroller (snarare än direkt), genom företablerade signaleringskanaler skyddade av DTLS/TLS-kryptering baserad på säkerhetscertifikat. Vilket i sin tur garanterar säkerheten för sådana utbyten och säkerställer bättre skalbarhet av lösningen upp till tiotusentals enheter i samma nätverk.

  Alla signalanslutningar (styrenhet-till-styrenhet, styrenhet-router) är också skyddade baserat på DTLS/TLS. Routers är utrustade med säkerhetscertifikat under tillverkning med möjlighet till byte/förlängning. Tvåfaktorsautentisering uppnås genom obligatorisk och samtidig uppfyllelse av två villkor för att routern/kontrollern ska fungera i ett SD-WAN-nätverk:

  • Giltigt säkerhetscertifikat
  • Explicit och medveten inkludering av administratören av varje komponent i den "vita" listan över tillåtna enheter.

Funktionsskillnader mellan SD-WAN och DMVPN/PfR

När vi går vidare till att diskutera funktionella skillnader bör det noteras att många av dem är en fortsättning på arkitektoniska - det är ingen hemlighet att utvecklare utgår från de möjligheter som de vill få i slutändan när de formar arkitekturen för en lösning. Låt oss titta på de viktigaste skillnaderna mellan de två teknikerna.

AppQ (Application Quality) – fungerar för att säkerställa kvaliteten på överföringen av affärsapplikationstrafik

Nyckelfunktionerna för de aktuella teknologierna är inriktade på att förbättra användarupplevelsen så mycket som möjligt vid användning av affärskritiska applikationer i ett distribuerat nätverk. Detta är särskilt viktigt under förhållanden där en del av infrastrukturen inte kontrolleras av IT eller inte ens garanterar framgångsrik dataöverföring.

DMVPN tillhandahåller inte i sig sådana mekanismer. Det bästa som kan göras i ett klassiskt DMVPN-nätverk är att klassificera utgående trafik efter applikation och prioritera den när den sänds mot WAN-kanalen. Valet av en DMVPN-tunnel bestäms i detta fall endast av dess tillgänglighet och resultatet av driften av routingprotokoll. Samtidigt tas inte vägens/tunnelns änd-till-ände tillstånd och dess eventuella partiella försämring med i beräkningen när det gäller nyckelmått som är signifikanta för nätverkstillämpningar - fördröjning, fördröjningsvariation (jitter) och förluster (% ). I detta avseende förlorar det all mening att direkt jämföra klassisk DMVPN med SD-WAN när det gäller att lösa AppQ-problem - DMVPN kan inte lösa detta problem. När du lägger till Cisco Performance Routing-teknik (PfR) i detta sammanhang förändras situationen och jämförelsen med Cisco SD-WAN blir mer meningsfull.

Innan vi diskuterar skillnaderna, här är en snabb titt på hur teknikerna liknar varandra. Så båda teknikerna:

• har en mekanism som låter dig dynamiskt bedöma tillståndet för varje etablerad tunnel i termer av vissa mätvärden - som ett minimum, fördröjning, fördröjningsvariation och paketförlust (%)
• använda en specifik uppsättning verktyg för att utforma, distribuera och tillämpa trafikledningsregler (policyer), med beaktande av resultaten av mätning av tillståndet för viktiga tunnelmått.
• klassificera applikationstrafik på nivåerna L3-L4 (DSCP) av OSI-modellen eller med L7 applikationssignaturer baserade på DPI-mekanismer inbyggda i routern
• För betydande applikationer låter de dig bestämma acceptabla tröskelvärden för mätvärden, regler för att överföra trafik som standard och regler för omdirigering av trafik när tröskelvärden överskrids.
• När de kapslar in trafik i GRE/IPSec använder de den redan etablerade industrimekanismen för att överföra interna DSCP-märkningar till den externa GRE/IPSEC-pakethuvudet, vilket möjliggör synkronisering av QoS-policyerna för organisationen och teleoperatören (om det finns en lämplig SLA) .

Hur skiljer sig SD-WAN och DMVPN/PfR end-to-end-mått?

DMVPN/PfR

• Både aktiva och passiva mjukvarusensorer (Probes) används för att utvärdera standardmått för tunnelhälsan. Aktiva är baserade på användartrafik, passiva emulerar sådan trafik (i dess frånvaro).
• Det finns ingen finjustering av timers och detekteringsförhållanden för nedbrytning - algoritmen är fixerad.
• Dessutom är mätning av använd bandbredd i utgående riktning tillgänglig. Vilket ger ytterligare trafikhanteringsflexibilitet till DMVPN/PfR.
• Samtidigt förlitar sig vissa PfR-mekanismer, när mätvärden överskrids, på återkopplingssignalering i form av särskilda TCA-meddelanden (Threshold Crossing Alert) som måste komma från trafikmottagaren mot källan, vilket i sin tur antar att tillståndet för uppmätta kanaler bör åtminstone vara tillräckliga för överföring av sådana TCA-meddelanden. Vilket i de flesta fall inte är ett problem, men uppenbarligen inte kan garanteras.

SD-WAN

• För end-to-end-utvärdering av standardmått för tunneltillstånd, används BFD-protokollet i ekoläge. I detta fall krävs ingen speciell återkoppling i form av TCA eller liknande meddelanden - isolering av feldomäner bibehålls. Det kräver inte heller närvaron av användartrafik för att utvärdera tunneltillståndet.
• Det är möjligt att finjustera BFD-timers för att reglera svarshastigheten och känsligheten hos algoritmen för försämring av kommunikationskanalen från flera sekunder till minuter.

  

• I skrivande stund finns det bara en BFD-session i varje tunnel. Detta skapar potentiellt mindre granularitet i tunneltillståndsanalys. I verkligheten kan detta bara bli en begränsning om du använder en WAN-anslutning baserad på MPLS L2/L3 VPN med en överenskommen QoS SLA - om DSCP-märkningen av BFD-trafik (efter inkapsling i IPSec/GRE) matchar den högprioriterade kön i teleoperatörens nätverk, då kan detta påverka noggrannheten och hastigheten för detektering av degradering för lågprioriterad trafik. Samtidigt är det möjligt att ändra standard BFD-märkning för att minska risken för sådana situationer. I framtida versioner av Cisco SD-WAN-programvaran förväntas mer finjusterade BFD-inställningar, liksom möjligheten att starta flera BFD-sessioner inom samma tunnel med individuella DSCP-värden (för olika applikationer).
• BFD låter dig dessutom uppskatta den maximala paketstorleken som kan överföras genom en viss tunnel utan fragmentering. Detta tillåter SD-WAN att dynamiskt justera parametrar som MTU och TCP MSS Adjust för att få ut det mesta av den tillgängliga bandbredden på varje länk.
• I SD-WAN finns också möjligheten till QoS-synkronisering från teleoperatörer, inte bara baserat på L3 DSCP-fält, utan också baserat på L2 CoS-värden, som automatiskt kan genereras i filialnätet av specialiserade enheter - till exempel IP telefoner

Hur skiljer sig möjligheterna, metoderna för att definiera och tillämpa AppQ-policyer?

DMVPN/PfR-policyer:

• Definieras på den centrala grenroutern via CLI-kommandoraden eller CLI-konfigurationsmallar. Att skapa CLI-mallar kräver förberedelse och kunskap om policysyntax.

  

• Definierat globalt utan möjlighet till individuell konfiguration/ändring av individuella nätsegments krav.
• Generering av interaktiv policy tillhandahålls inte i det grafiska gränssnittet.
• Spårning av ändringar, nedärvning och skapande av flera versioner av policyer för snabbväxling tillhandahålls inte.
• Distribueras automatiskt till routrar för avlägsna filialer. I detta fall används samma kommunikationskanaler som för att överföra användardata. Om det inte finns någon kommunikationskanal mellan den centrala och fjärranslutna grenen är distribution/ändring av policyer omöjlig.
• De används på varje router och modifierar vid behov resultatet av standardroutingprotokoll, med högre prioritet.
• För fall där alla WAN-länkar för filialer upplever betydande trafikförluster, inga kompensationsmekanismer tillhandahålls.

SD-WAN-policyer:

• Definierat i vManage GUI genom den interaktiva mallguiden.
• Stöder att skapa flera policyer, kopiera, ärva, växla mellan policyer i realtid.
• Stöder individuella policyinställningar för olika nätverkssegment (grenar)
• De distribueras med hjälp av valfri tillgänglig signalkanal mellan styrenheten och routern och/eller vSmart - är inte direkt beroende av dataplansanslutningen mellan routrarna. Detta kräver naturligtvis IP-anslutning mellan själva routern och kontrollerna.

  

• I fall då alla tillgängliga grenar av en filial upplever betydande dataförluster som överstiger acceptabla tröskelvärden för kritiska tillämpningar, är det möjligt att använda ytterligare mekanismer som ökar överföringens tillförlitlighet:
  • FEC (Forward Error Correction) – använder en speciell redundant kodningsalgoritm. Vid överföring av kritisk trafik över kanaler med en betydande andel förluster kan FEC aktiveras automatiskt och gör det möjligt att vid behov återställa den förlorade delen av datan. Detta ökar den använda överföringsbandbredden något, men förbättrar tillförlitligheten avsevärt.

    

  • Duplicering av dataströmmar – Utöver FEC kan policyn ge automatisk dubblering av trafik av utvalda applikationer i händelse av en ännu allvarligare nivå av förluster som inte kan kompenseras av FEC. I detta fall kommer den valda datan att sändas genom alla tunnlar mot den mottagande grenen med efterföljande deduplicering (släpper extra kopior av paket). Mekanismen ökar avsevärt kanalutnyttjandet, men ökar också avsevärt överföringssäkerheten.

Cisco SD-WAN-möjligheter, utan direkta analoger i DMVPN/PfR

Arkitekturen för Cisco SD-WAN-lösningen tillåter dig i vissa fall att erhålla funktioner som antingen är extremt svåra att implementera inom DMVPN/PfR, eller är opraktiska på grund av de erforderliga arbetskostnaderna, eller är helt omöjliga. Låt oss titta på de mest intressanta av dem:

Trafikteknik (TE)

TE inkluderar mekanismer som tillåter trafik att förgrena sig från standardvägen som bildas av routingprotokoll. TE används ofta för att säkerställa hög tillgänglighet för nätverkstjänster, genom möjligheten att snabbt och/eller proaktivt överföra kritisk trafik till en alternativ (osammanhängande) överföringsväg, för att säkerställa bättre tjänstekvalitet eller återställningshastighet i händelse av fel på huvudstigen.

Svårigheten med att implementera TE ligger i behovet av att beräkna och reservera (kontrollera) en alternativ väg i förväg. I MPLS-nätverk av telekomoperatörer löses detta problem med hjälp av teknologier som MPLS Traffic-Engineering med förlängningar av IGP-protokollen och RSVP-protokollet. Också nyligen har Segment Routing-tekniken, som är mer optimerad för centraliserad konfiguration och orkestrering, blivit allt mer populär. I klassiska WAN-nätverk är dessa tekniker vanligtvis inte representerade eller reduceras till användningen av hop-by-hop-mekanismer som Policy-Based Routing (PBR), som kan förgrena trafik, men implementera detta på varje router separat - utan att ta ta hänsyn till det övergripande tillståndet för nätverket eller PBR-resultatet i föregående eller efterföljande steg. Resultatet av att använda dessa TE-alternativ är en besvikelse - MPLS TE, på grund av komplexiteten i konfiguration och drift, används som regel endast i den mest kritiska delen av nätverket (kärnan), och PBR används på individuella routrar utan möjligheten att skapa en enhetlig PBR-policy för hela nätverket. Uppenbarligen gäller detta även för DMVPN-baserade nätverk.

SD-WAN erbjuder i detta avseende en mycket mer elegant lösning som inte bara är lätt att konfigurera, utan även skalar mycket bättre. Detta är ett resultat av de styrplans- och policyplansarkitekturer som används. Genom att implementera ett policy-plan i SD-WAN kan du centralt definiera TE-policy - vilken trafik är av intresse? för vilka VPN? Genom vilka noder/tunnlar är det nödvändigt eller omvänt förbjudet att bilda en alternativ väg? I sin tur låter centraliseringen av styrplanshantering baserad på vSmart-styrenheter dig modifiera routingresultat utan att tillgripa inställningarna för enskilda enheter - routrar ser redan bara resultatet av logiken som genererades i vManage-gränssnittet och överfördes för användning till vSmart.

Servicekedja

Att bilda servicekedjor är en ännu mer arbetskrävande uppgift i klassisk routing än den redan beskrivna Traffic-Engineering-mekanismen. I det här fallet är det faktiskt nödvändigt att inte bara skapa en speciell rutt för en specifik nätverksapplikation, utan också att säkerställa möjligheten att ta bort trafik från nätverket på vissa (eller alla) noder i SD-WAN-nätverket för bearbetning av en speciell applikation eller tjänst (brandvägg, balansering, cachelagring, inspektionstrafik, etc.). Samtidigt är det nödvändigt att kunna kontrollera tillståndet för dessa externa tjänster för att förhindra svarta hål-situationer, och det behövs också mekanismer som gör att sådana externa tjänster av samma typ kan placeras på olika geo-platser med nätverkets förmåga att automatiskt välja den mest optimala tjänstenoden för bearbetning av trafiken för en viss gren. I fallet med Cisco SD-WAN är detta ganska enkelt att uppnå genom att skapa en lämplig centraliserad policy som "limmar" alla aspekter av målservicekedjan till en enda helhet och automatiskt ändrar dataplans- och kontrollplanslogiken endast där och när det behövs.

Möjligheten att skapa geo-distribuerad bearbetning av trafik av utvalda typer av applikationer i en viss sekvens på specialiserad (men inte relaterad till själva SD-WAN-nätverket) utrustning är kanske den tydligaste demonstrationen av fördelarna med Cisco SD-WAN jämfört med klassiska teknologier och även några alternativa SD-lösningar -WAN från andra tillverkare.

Resultatet?

Uppenbarligen både DMVPN (med eller utan Performance Routing) och Cisco SD-WAN sluta med att lösa mycket liknande problem i förhållande till organisationens distribuerade WAN-nätverk. Samtidigt leder betydande arkitektoniska och funktionella skillnader i Cisco SD-WAN-tekniken till processen att lösa dessa problem till en annan kvalitetsnivå. För att sammanfatta kan vi notera följande signifikanta skillnader mellan SD-WAN och DMVPN/PfR-teknologier:

• DMVPN/PfR använder i allmänhet beprövade teknologier för att bygga överliggande VPN-nätverk och, vad gäller dataplan, liknar de mer modern SD-WAN-teknik, men det finns ett antal begränsningar i form av en obligatorisk statisk konfiguration av routrar och valet av topologier är begränsat till Hub-n-Spoke. Å andra sidan har DMVPN/PfR en del funktionalitet som ännu inte är tillgänglig inom SD-WAN (vi pratar om BFD per applikation).
• Inom kontrollplanet skiljer sig teknologierna fundamentalt. Med hänsyn till centraliserad bearbetning av signaleringsprotokoll tillåter SD-WAN särskilt att avsevärt begränsa feldomäner och "frikoppla" processen för att överföra användartrafik från signaleringsinteraktion - tillfällig otillgänglighet för styrenheter påverkar inte förmågan att överföra användartrafik . Samtidigt påverkar den tillfälliga otillgängligheten av någon gren (inklusive den centrala) inte på något sätt möjligheten för andra grenar att interagera med varandra och kontroller.
• Arkitekturen för utformning och tillämpning av trafikledningspolicyer i fallet med SD-WAN är också överlägsen den i DMVPN/PfR - georeservation är mycket bättre implementerad, det finns ingen koppling till navet, det finns fler möjligheter för böter -justera policyer, listan över implementerade trafikhanteringsscenarier är också mycket större.
• Processen för orkestrering av lösningen är också väsentligt annorlunda. DMVPN förutsätter närvaron av tidigare kända parametrar som på något sätt måste återspeglas i konfigurationen, vilket något begränsar lösningens flexibilitet och möjligheten till dynamiska förändringar. I sin tur är SD-WAN baserat på paradigmet att routern i det första anslutningsögonblicket "inte vet någonting" om sina kontroller, men vet "vem du kan fråga" - detta räcker inte bara för att automatiskt upprätta kommunikation med styrenheterna, men också för att automatiskt bilda en helt ansluten dataplanstopologi, som sedan kan konfigureras/ändras flexibelt med hjälp av policyer.
• När det gäller centraliserad hantering, automatisering och övervakning förväntas SD-WAN överträffa kapaciteten hos DMVPN/PfR, som har utvecklats från klassiska teknologier och förlitar sig mer på CLI-kommandoraden och användningen av mallbaserade NMS-system.
• I SD-WAN, jämfört med DMVPN, har säkerhetskraven nått en annan kvalitativ nivå. Huvudprinciperna är noll förtroende, skalbarhet och tvåfaktorsautentisering.

Dessa enkla slutsatser kan ge ett felaktigt intryck av att skapa ett nätverk baserat på DMVPN/PfR har tappat all relevans idag. Detta är naturligtvis inte helt sant. Till exempel, i de fall där nätverket använder mycket föråldrad utrustning och det inte finns något sätt att ersätta den, kan DMVPN tillåta dig att kombinera "gamla" och "nya" enheter till ett enda geodistribuerat nätverk med många av de fördelar som beskrivs ovan.

Å andra sidan bör man komma ihåg att alla nuvarande Cisco-företagsroutrar baserade på IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) idag stöder vilket driftläge som helst - både klassisk routing och DMVPN och SD-WAN - valet bestäms av nuvarande behov och förståelsen att du när som helst, med samma utrustning, kan börja gå mot mer avancerad teknik.

Källa: will.com