Zal Cisco SD-WAN de tak waarop DMVPN zit afsluiten?

Sinds augustus 2017, toen Cisco Viptela overnam, is de belangrijkste technologie die wordt aangeboden voor het organiseren van gedistribueerde bedrijfsnetwerken geworden Cisco SD-WAN. De afgelopen drie jaar heeft de SD-WAN-technologie veel veranderingen ondergaan, zowel kwalitatief als kwantitatief. Zo is de functionaliteit aanzienlijk uitgebreid en is er ondersteuning verschenen op klassieke routers uit de serie Cisco ISR 1000, ISR 4000, ASR 1000 en Virtuele CSR 1000v. Tegelijkertijd blijven veel klanten en partners van Cisco zich afvragen: wat zijn de verschillen tussen Cisco SD-WAN en reeds bekende benaderingen gebaseerd op technologieën zoals Cisco DMVPN и Cisco prestatieroutering en hoe belangrijk zijn deze verschillen?

Hier moeten we meteen een voorbehoud maken dat DMVPN vóór de komst van SD-WAN in het Cisco-portfolio samen met PfR een sleutelonderdeel vormde in de architectuur Cisco IWAN (intelligent WAN), wat op zijn beurt de voorloper was van volwaardige SD-WAN-technologie. Ondanks de algemene gelijkenis van zowel de taken die worden opgelost als de methoden om ze op te lossen, heeft IWAN nooit het niveau van automatisering, flexibiliteit en schaalbaarheid bereikt dat nodig is voor SD-WAN, en in de loop van de tijd is de ontwikkeling van IWAN aanzienlijk afgenomen. Tegelijkertijd zijn de technologieën waaruit IWAN bestaat niet verdwenen en blijven veel klanten ze met succes gebruiken, ook op moderne apparatuur. Als gevolg hiervan is er een interessante situatie ontstaan: met dezelfde Cisco-apparatuur kunt u de meest geschikte WAN-technologie (klassiek, DMVPN+PfR of SD-WAN) kiezen in overeenstemming met de eisen en verwachtingen van klanten.

Het artikel is niet bedoeld om alle functies van Cisco SD-WAN- en DMVPN-technologieën (met of zonder Performance Routing) in detail te analyseren - hiervoor is een enorme hoeveelheid beschikbare documenten en materialen. De belangrijkste taak is om te proberen de belangrijkste verschillen tussen deze technologieën te evalueren. Maar voordat we verder gaan met het bespreken van deze verschillen, willen we eerst even kort stilstaan ​​bij de technologieën zelf.

Wat is Cisco DMVPN en waarom is het nodig?

Cisco DMVPN lost het probleem op van dynamische (= schaalbare) verbinding van een extern filiaalnetwerk met het netwerk van het hoofdkantoor van een onderneming bij gebruik van willekeurige soorten communicatiekanalen, inclusief internet (= met codering van het communicatiekanaal). Technisch gezien wordt dit gerealiseerd door het creëren van een gevirtualiseerd overlay-netwerk van L3 VPN-klasse in point-to-multipoint-modus met een logische topologie van het “Star”-type (Hub-n-Spoke). Om dit te bereiken gebruikt DMVPN een combinatie van de volgende technologieën:

• IP-routering
• Multipoint GRE-tunnels (mGRE)
• Next Hop-resolutieprotocol (NHRP)
• IPSec Crypto-profielen

Wat zijn de belangrijkste voordelen van Cisco DMVPN vergeleken met klassieke routering met behulp van MPLS VPN-kanalen?

• Om een ​​interfiliaal netwerk te creëren, is het mogelijk om elk communicatiekanaal te gebruiken - alles dat IP-connectiviteit tussen vestigingen kan bieden is geschikt, terwijl het verkeer gecodeerd zal zijn (waar nodig) en gebalanceerd (waar mogelijk).
• Er wordt automatisch een volledig verbonden topologie tussen takken gevormd. Tegelijkertijd zijn er statische tunnels tussen de centrale en afgelegen vestigingen, en dynamische tunnels op aanvraag tussen de afgelegen vestigingen (als er verkeer is)
• De routers van de centrale en externe vestiging hebben dezelfde configuratie tot aan de IP-adressen van de interfaces. Door mGRE te gebruiken is het niet nodig om tientallen, honderden of zelfs duizenden tunnels individueel te configureren. Met als resultaat een behoorlijke schaalbaarheid met het juiste design.

Wat is Cisco Performance Routing en waarom is het nodig?

Bij het gebruik van DMVPN op een interfiliaal netwerk blijft één uiterst belangrijke vraag onopgelost: hoe kunnen we dynamisch de status van elk van de DMVPN-tunnels beoordelen om te voldoen aan de vereisten van verkeer die cruciaal zijn voor onze organisatie en, nogmaals, op basis van een dergelijke beoordeling, dynamisch maken een beslissing over een omleiding? Het feit is dat DMVPN in dit deel weinig verschilt van klassieke routering - het beste dat gedaan kan worden is het configureren van QoS-mechanismen waarmee u verkeer in de uitgaande richting prioriteit kunt geven, maar die op geen enkele manier rekening kunnen houden met de status van het hele pad op een of ander moment.

En wat te doen als het kanaal gedeeltelijk en niet volledig degradeert - hoe kan dit worden gedetecteerd en geëvalueerd? DMVPN zelf kan dit niet. Gezien het feit dat de kanalen die vestigingen verbinden via totaal verschillende telecomoperatoren kunnen lopen, waarbij gebruik wordt gemaakt van totaal verschillende technologieën, wordt deze taak uiterst niet triviaal. En dit is waar de Cisco Performance Routing-technologie te hulp schiet, die tegen die tijd al verschillende ontwikkelingsfasen had doorlopen.

De taak van Cisco Performance Routing (hierna PfR) komt neer op het meten van de toestand van paden (tunnels) van verkeer op basis van belangrijke statistieken die belangrijk zijn voor netwerktoepassingen - latentie, latentievariatie (jitter) en pakketverlies (percentage). Bovendien kan de gebruikte bandbreedte worden gemeten. Deze metingen vinden plaats zo dicht mogelijk bij realtime en terecht, en het resultaat van deze metingen stelt de router die PfR gebruikt in staat om dynamisch beslissingen te nemen over de noodzaak om de routering van dit of dat type verkeer te veranderen.

De taak van de DMVPN/PfR-combinatie kan dus kort als volgt worden beschreven:

• Sta de klant toe om alle communicatiekanalen op het WAN-netwerk te gebruiken
• Zorg voor de hoogst mogelijke kwaliteit van kritische applicaties op deze kanalen

Wat is Cisco SD-WAN?

Cisco SD-WAN is een technologie die de SDN-aanpak gebruikt om het WAN-netwerk van een organisatie te creëren en te exploiteren. Dit betekent met name het gebruik van zogenaamde controllers (software-elementen), die zorgen voor gecentraliseerde orkestratie en geautomatiseerde configuratie van alle oplossingscomponenten. In tegenstelling tot de canonieke SDN (Clean Slate-stijl) gebruikt Cisco SD-WAN verschillende soorten controllers, die elk hun eigen rol vervullen - dit is opzettelijk gedaan om betere schaalbaarheid en geo-redundantie te bieden.

In het geval van SD-WAN blijft de taak van het gebruik van alle soorten kanalen en het waarborgen van de werking van bedrijfsapplicaties hetzelfde, maar tegelijkertijd nemen de eisen voor automatisering, schaalbaarheid, veiligheid en flexibiliteit van een dergelijk netwerk toe.

Bespreking van verschillen

Als we nu de verschillen tussen deze technologieën gaan analyseren, vallen ze in een van de volgende categorieën:

• Architecturale verschillen - hoe zijn functies verdeeld over verschillende componenten van de oplossing, hoe is de interactie tussen dergelijke componenten georganiseerd en welke invloed heeft dit op de mogelijkheden en flexibiliteit van de technologie?
• Functionaliteit – wat kan de ene technologie wel wat de andere niet kan? En is het echt zo belangrijk?

Wat zijn de architectonische verschillen en zijn deze belangrijk?

Elk van deze technologieën heeft veel ‘bewegende delen’ die niet alleen verschillen in hun rol, maar ook in de manier waarop ze met elkaar omgaan. Hoe goed deze principes zijn doordacht en de algemene werking van de oplossing bepalen rechtstreeks de schaalbaarheid, fouttolerantie en algehele efficiëntie.

Laten we de verschillende aspecten van de architectuur in meer detail bekijken:

Datavlak – onderdeel van de oplossing die verantwoordelijk is voor het verzenden van gebruikersverkeer tussen de bron en de ontvanger. DMVPN en SD-WAN worden over het algemeen identiek geïmplementeerd op de routers zelf op basis van Multipoint GRE-tunnels. Het verschil is hoe de noodzakelijke set parameters voor deze tunnels wordt gevormd:

• в DMVPN/PfR is een uitsluitend hiërarchie van knooppunten op twee niveaus met een Star- of Hub-n-Spoke-topologie. Statische configuratie van de hub en statische binding van Spoke aan de hub zijn vereist, evenals interactie via het NHRP-protocol om datavlakconnectiviteit te vormen. Vervolgens, waardoor wijzigingen aan de hub aanzienlijk moeilijker wordenbijvoorbeeld gerelateerd aan het wijzigen/verbinden van nieuwe WAN-kanalen of het wijzigen van de parameters van bestaande WAN-kanalen.
• в SD-WAN is een volledig dynamisch model voor het detecteren van parameters van geïnstalleerde tunnels op basis van control-plane (OMP-protocol) en orkestratie-plane (interactie met de vBond-controller voor controllerdetectie en NAT-traversal-taken). In dit geval kunnen alle op elkaar geplaatste topologieën worden gebruikt, inclusief hiërarchische topologieën. Binnen de gevestigde overlay-tunneltopologie is een flexibele configuratie van de logische topologie in elke individuele VPN (VRF) mogelijk.

Controlevlak – functies voor het uitwisselen, filteren en wijzigen van routering en andere informatie tussen oplossingscomponenten.

• в DMVPN/PfR – alleen uitgevoerd tussen Hub- en Spoke-routers. Directe uitwisseling van route-informatie tussen Spokes is niet mogelijk. Vervolgens, Zonder een functionerende hub kunnen het besturingsvlak en het datavlak niet functioneren, wat aanvullende vereisten voor hoge beschikbaarheid aan de Hub oplegt waaraan niet altijd kan worden voldaan.
• в SD-WAN – control-plane wordt nooit rechtstreeks tussen routers uitgevoerd – interactie vindt plaats op basis van het OMP-protocol en wordt noodzakelijkerwijs uitgevoerd via een afzonderlijk gespecialiseerd type vSmart-controller, die de mogelijkheid biedt tot balancering, geo-reservering en gecentraliseerde controle van de signaal belasting. Een ander kenmerk van het OMP-protocol is de aanzienlijke weerstand tegen verliezen en de onafhankelijkheid van de snelheid van het communicatiekanaal met controllers (uiteraard binnen redelijke grenzen). Hiermee kunt u met evenveel succes SD-WAN-controllers in publieke of private clouds plaatsen met toegang via internet.

Beleidsvlak – onderdeel van de oplossing die verantwoordelijk is voor het definiëren, distribueren en toepassen van verkeersbeheerbeleid op een gedistribueerd netwerk.

• DMVPN – wordt effectief beperkt door Quality of Service (QoS)-beleid dat individueel op elke router is geconfigureerd via de CLI- of Prime Infrastructure-sjablonen.
• DMVPN/PfR – PfR-beleid wordt via de CLI gevormd op de gecentraliseerde Master Controller (MC)-router en vervolgens automatisch gedistribueerd naar filiaal-MC's. In dit geval worden dezelfde beleidsoverdrachtspaden gebruikt als voor het datavlak. Er is geen mogelijkheid om de uitwisseling van polissen, routeringsinformatie en gebruikersgegevens te scheiden. Voor beleidspropagatie is de aanwezigheid van IP-connectiviteit tussen de Hub en Spoke vereist. In dit geval kan de MC-functie indien nodig worden gecombineerd met een DMVPN-router. Het is mogelijk (maar niet verplicht) om Prime Infrastructure-sjablonen te gebruiken voor het gecentraliseerd genereren van beleid. Een belangrijk kenmerk is dat het beleid wereldwijd op dezelfde manier in het hele netwerk wordt gevormd: Individueel beleid voor individuele segmenten wordt niet ondersteund.
• SD-WAN – het verkeersbeheer en het servicekwaliteitsbeleid worden centraal bepaald via de grafische interface van Cisco vManage, die (indien nodig) ook via internet toegankelijk is. Ze worden gedistribueerd via signaalkanalen, direct of indirect via vSmart-controllers (afhankelijk van het type beleid). Ze zijn niet afhankelijk van dataplane-connectiviteit tussen routers, omdat gebruik alle beschikbare verkeerspaden tussen de controller en de router.

  Voor verschillende netwerksegmenten is het mogelijk om flexibel verschillend beleid te formuleren - de reikwijdte van het beleid wordt bepaald door de vele unieke identificatiegegevens die in de oplossing worden verstrekt - filiaalnummer, applicatietype, verkeersrichting, enz.

Orkestratie-vlak – mechanismen waarmee componenten elkaar dynamisch kunnen detecteren, daaropvolgende interacties kunnen configureren en coördineren.

• в DMVPN/PfR Wederzijdse ontdekking tussen routers is gebaseerd op de statische configuratie van Hub-apparaten en de overeenkomstige configuratie van Spoke-apparaten. Dynamische detectie vindt alleen plaats voor Spoke, dat de Hub-verbindingsparameters rapporteert aan het apparaat, dat op zijn beurt vooraf is geconfigureerd met Spoke. Zonder IP-connectiviteit tussen Spoke en ten minste één hub is het onmogelijk om een ​​datavlak of een besturingsvlak te vormen.
• в SD-WAN De orkestratie van oplossingscomponenten vindt plaats met behulp van de vBond-controller, waarmee elk onderdeel (routers en vManage/vSmart-controllers) eerst een IP-connectiviteit tot stand moet brengen.

  In eerste instantie zijn de componenten niet op de hoogte van elkaars verbindingsparameters. Hiervoor hebben ze de vBond intermediaire orkestrator nodig. Het algemene principe is als volgt: elke component in de beginfase leert (automatisch of statisch) alleen over de verbindingsparameters met vBond, waarna vBond de router informeert over de vManage- en vSmart-controllers (eerder ontdekt), waardoor het mogelijk wordt om automatisch een verbinding tot stand te brengen alle benodigde signaalverbindingen.

  De volgende stap is dat de nieuwe router kennis krijgt van de andere routers op het netwerk via OMP-communicatie met de vSmart-controller. Zo kan de router, zonder in eerste instantie ook maar iets te weten over de netwerkparameters, volledig automatisch controllers detecteren en er verbinding mee maken en vervolgens ook automatisch connectiviteit met andere routers detecteren en tot stand brengen. In dit geval zijn de verbindingsparameters van alle componenten aanvankelijk onbekend en kunnen tijdens bedrijf veranderen.

Beheervlak – onderdeel van de oplossing die gecentraliseerd beheer en monitoring biedt.

• DMVPN/PfR – er wordt geen gespecialiseerde managementoplossing geboden. Voor basisautomatisering en monitoring kunnen producten als Cisco Prime Infrastructure worden gebruikt. Elke router kan worden bestuurd via de CLI-opdrachtregel. Integratie met externe systemen via API is niet voorzien.
• SD-WAN – alle reguliere interactie en monitoring wordt centraal uitgevoerd via de grafische interface van de vManage-controller. Alle functies van de oplossing zijn, zonder uitzondering, beschikbaar voor configuratie via vManage, evenals via een volledig gedocumenteerde REST API-bibliotheek.

  Alle SD-WAN-netwerkinstellingen in vManage komen neer op twee hoofdconstructies: de vorming van apparaatsjablonen (Device Template) en de vorming van een beleid dat de logica van netwerkwerking en verkeersverwerking bepaalt. Tegelijkertijd selecteert vManage, dat het door de beheerder gegenereerde beleid uitzendt, automatisch welke wijzigingen en op welke individuele apparaten/controllers moeten worden doorgevoerd, wat de efficiëntie en schaalbaarheid van de oplossing aanzienlijk vergroot.

  Via de vManage-interface is niet alleen de configuratie van de Cisco SD-WAN-oplossing beschikbaar, maar ook volledige monitoring van de status van alle componenten van de oplossing, tot aan de huidige staat van statistieken voor individuele tunnels en statistieken over het gebruik van verschillende applicaties gebaseerd op DPI-analyse.

  Ondanks de centralisatie van de interactie beschikken alle componenten (controllers en routers) ook over een volledig functionele CLI-opdrachtregel, wat nodig is in de implementatiefase of in geval van nood voor lokale diagnostiek. In de normale modus (als er een signaleringskanaal tussen componenten is) op routers is de opdrachtregel alleen beschikbaar voor diagnostiek en niet voor het maken van lokale wijzigingen, wat lokale veiligheid garandeert en de enige bron van wijzigingen in een dergelijk netwerk is vManage.

Geïntegreerde beveiliging – hier moeten we het niet alleen hebben over de bescherming van gebruikersgegevens wanneer deze via open kanalen worden verzonden, maar ook over de algehele beveiliging van het WAN-netwerk op basis van de geselecteerde technologie.

• в DMVPN/PfR Het is mogelijk om gebruikersgegevens en signaleringsprotocollen te coderen. Bij gebruik van bepaalde routermodellen zijn bovendien firewallfuncties met verkeersinspectie en IPS/IDS beschikbaar. Het is mogelijk om vestigingsnetwerken te segmenteren met behulp van VRF. Het is mogelijk om (één-factor) controleprotocollen te authenticeren.

  In dit geval wordt de externe router standaard beschouwd als een vertrouwd onderdeel van het netwerk, d.w.z. gevallen van fysieke inbreuk op individuele apparaten en de mogelijkheid van ongeoorloofde toegang daartoe worden niet aangenomen of in aanmerking genomen; er is geen sprake van tweefactorauthenticatie van oplossingscomponenten, wat in het geval van een geografisch verspreid netwerk wel het geval is. kunnen aanzienlijke extra risico's met zich meebrengen.

• в SD-WAN naar analogie met DMVPN wordt de mogelijkheid geboden om gebruikersgegevens te versleutelen, maar met aanzienlijk uitgebreide netwerkbeveiliging en L3/VRF-segmentatiefuncties (firewall, IPS/IDS, URL-filtering, DNS-filtering, AMP/TG, SASE, TLS/SSL-proxy, enz.) d.). Tegelijkertijd wordt de uitwisseling van encryptiesleutels efficiënter uitgevoerd via vSmart-controllers (in plaats van rechtstreeks), via vooraf vastgestelde signaalkanalen die worden beschermd door DTLS/TLS-encryptie op basis van beveiligingscertificaten. Wat op zijn beurt de veiligheid van dergelijke uitwisselingen garandeert en zorgt voor een betere schaalbaarheid van de oplossing tot tienduizenden apparaten op hetzelfde netwerk.

  Alle signaleringsverbindingen (controller-naar-controller, controller-router) zijn bovendien beveiligd op basis van DTLS/TLS. Routers zijn tijdens de productie voorzien van veiligheidscertificaten met mogelijkheid tot vervanging/uitbreiding. Tweefactorauthenticatie wordt bereikt door de verplichte en gelijktijdige vervulling van twee voorwaarden voor het functioneren van de router/controller in een SD-WAN-netwerk:

  • Geldig beveiligingscertificaat
  • Expliciete en bewuste opname door de beheerder van elk onderdeel in de “witte” lijst met toegestane apparaten.

Functionele verschillen tussen SD-WAN en DMVPN/PfR

Als we verder gaan met het bespreken van functionele verschillen, moet worden opgemerkt dat veel van deze een voortzetting zijn van architecturale verschillen - het is geen geheim dat ontwikkelaars bij het vormen van de architectuur van een oplossing uitgaan van de mogelijkheden die ze uiteindelijk willen krijgen. Laten we eens kijken naar de belangrijkste verschillen tussen de twee technologieën.

AppQ (Application Quality) – functies om de kwaliteit van de overdracht van zakelijk applicatieverkeer te garanderen

De belangrijkste functies van de onderzochte technologieën zijn erop gericht om de gebruikerservaring bij het gebruik van bedrijfskritische applicaties in een gedistribueerd netwerk zoveel mogelijk te verbeteren. Dit is vooral belangrijk in omstandigheden waarin een deel van de infrastructuur niet door IT wordt beheerd of zelfs geen succesvolle gegevensoverdracht garandeert.

DMVPN biedt zelf dergelijke mechanismen niet. Het beste dat in een klassiek DMVPN-netwerk kan worden gedaan, is uitgaand verkeer per toepassing classificeren en er prioriteit aan geven wanneer het naar het WAN-kanaal wordt verzonden. De keuze voor een DMVPN-tunnel wordt in dit geval alleen bepaald door de beschikbaarheid ervan en het resultaat van de werking van routeringsprotocollen. Tegelijkertijd wordt er geen rekening gehouden met de end-to-end-status van het pad/de tunnel en de mogelijke gedeeltelijke verslechtering ervan in termen van belangrijke meetgegevens die van belang zijn voor netwerktoepassingen: vertraging, vertragingsvariatie (jitter) en verliezen (% ). In dit opzicht verliest het rechtstreeks vergelijken van klassieke DMVPN met SD-WAN in termen van het oplossen van AppQ-problemen alle betekenis - DMVPN kan dit probleem niet oplossen. Wanneer je Cisco Performance Routing (PfR)-technologie aan deze context toevoegt, verandert de situatie en wordt de vergelijking met Cisco SD-WAN betekenisvoller.

Voordat we de verschillen bespreken, kijken we eerst hoe de technologieën op elkaar lijken. Dus beide technologieën:

• een mechanisme hebben waarmee u de status van elke bestaande tunnel dynamisch kunt beoordelen in termen van bepaalde statistieken - op zijn minst vertraging, vertragingsvariatie en pakketverlies (%)
• een specifieke set hulpmiddelen gebruiken om verkeersbeheerregels (beleid) te vormen, te verspreiden en toe te passen, rekening houdend met de resultaten van het meten van de status van belangrijke tunnelmetrieken.
• classificeer applicatieverkeer op niveaus L3-L4 (DSCP) van het OSI-model of op basis van L7-applicatiehandtekeningen op basis van DPI-mechanismen die in de router zijn ingebouwd
• Voor belangrijke toepassingen kunt u hiermee aanvaardbare drempelwaarden van statistieken bepalen, regels voor het standaard verzenden van verkeer en regels voor het omleiden van verkeer wanneer drempelwaarden worden overschreden.
• Bij het inkapselen van verkeer in GRE/IPSec gebruiken ze het reeds bestaande industriële mechanisme voor het overbrengen van interne DSCP-markeringen naar de externe GRE/IPSEC-pakketheader, waardoor het QoS-beleid van de organisatie en de telecomoperator kan worden gesynchroniseerd (als er een geschikte SLA is). .

Hoe verschillen de end-to-end-statistieken van SD-WAN en DMVPN/PfR?

DMVPN/PfR

• Zowel actieve als passieve softwaresensoren (Probes) worden gebruikt om standaard tunnelgezondheidsstatistieken te evalueren. Actieve zijn gebaseerd op gebruikersverkeer, passieve emuleren dergelijk verkeer (bij afwezigheid ervan).
• Er is geen fijnafstemming van timers en degradatiedetectieomstandigheden; het algoritme staat vast.
• Bovendien is meting van de gebruikte bandbreedte in uitgaande richting beschikbaar. Dit voegt extra flexibiliteit voor verkeersbeheer toe aan DMVPN/PfR.
• Tegelijkertijd vertrouwen sommige PfR-mechanismen, wanneer meetwaarden worden overschreden, op feedbacksignalering in de vorm van speciale TCA-berichten (Threshold Crossing Alert) die van de ontvanger van het verkeer naar de bron moeten komen, die op zijn beurt ervan uitgaat dat de toestand van de gemeten kanalen moeten op zijn minst voldoende zijn voor de verzending van dergelijke TCA-berichten. Dit is in de meeste gevallen geen probleem, maar kan uiteraard niet worden gegarandeerd.

SD-WAN

• Voor end-to-end evaluatie van standaard tunnelstatusstatistieken wordt het BFD-protocol in de echomodus gebruikt. In dit geval is speciale feedback in de vorm van TCA of soortgelijke berichten niet vereist - de isolatie van foutdomeinen blijft gehandhaafd. Er is ook geen aanwezigheid van gebruikersverkeer vereist om de tunnelstatus te evalueren.
• Het is mogelijk om BFD-timers nauwkeurig af te stemmen om de reactiesnelheid en gevoeligheid van het algoritme voor verslechtering van het communicatiekanaal te regelen van enkele seconden tot minuten.

  

• Op het moment van schrijven is er slechts één BFD-sessie in elke tunnel. Dit zorgt mogelijk voor minder granulariteit bij de analyse van de tunneltoestand. In werkelijkheid kan dit alleen een beperking worden als u een WAN-verbinding gebruikt op basis van MPLS L2/L3 VPN met een overeengekomen QoS SLA - als de DSCP-markering van BFD-verkeer (na inkapseling in IPSec/GRE) overeenkomt met de wachtrij met hoge prioriteit in het netwerk van de telecomoperator, dan kan dit van invloed zijn op de nauwkeurigheid en snelheid van degradatiedetectie voor verkeer met lage prioriteit. Tegelijkertijd is het mogelijk om de standaard BFD-labeling te wijzigen om het risico op dergelijke situaties te verminderen. In toekomstige versies van Cisco SD-WAN-software worden meer verfijnde BFD-instellingen verwacht, evenals de mogelijkheid om meerdere BFD-sessies binnen dezelfde tunnel te starten met individuele DSCP-waarden (voor verschillende toepassingen).
• Met BFD kunt u bovendien de maximale pakketgrootte schatten die zonder fragmentatie door een bepaalde tunnel kan worden verzonden. Hierdoor kan SD-WAN parameters zoals MTU en TCP MSS Adjust dynamisch aanpassen om de beschikbare bandbreedte op elke link optimaal te benutten.
• In SD-WAN is ook de optie van QoS-synchronisatie van telecomoperatoren beschikbaar, niet alleen op basis van L3 DSCP-velden, maar ook op basis van L2 CoS-waarden, die automatisch in het vestigingsnetwerk kunnen worden gegenereerd door gespecialiseerde apparaten - bijvoorbeeld IP telefoons

Hoe verschillen de mogelijkheden en methoden voor het definiëren en toepassen van AppQ-beleid?

DMVPN/PfR-beleid:

• Gedefinieerd op de centrale filiaalrouter(s) via de CLI-opdrachtregel of CLI-configuratiesjablonen. Het genereren van CLI-sjablonen vereist voorbereiding en kennis van de beleidssyntaxis.

  

• Globaal gedefinieerd zonder de mogelijkheid tot individuele configuratie/wijziging van de eisen van individuele netwerksegmenten.
• Interactieve beleidsgeneratie is niet mogelijk in de grafische interface.
• Het bijhouden van wijzigingen, overname en het maken van meerdere versies van beleid voor snel schakelen zijn niet beschikbaar.
• Automatisch gedistribueerd naar routers van externe vestigingen. In dit geval worden dezelfde communicatiekanalen gebruikt als voor het verzenden van gebruikersgegevens. Als er geen communicatiekanaal is tussen de centrale en de externe vestiging, is distributie/wijziging van beleid onmogelijk.
• Ze worden op elke router gebruikt en wijzigen, indien nodig, het resultaat van standaard routeringsprotocollen, met een hogere prioriteit.
• Voor gevallen waarin alle WAN-verbindingen in filialen aanzienlijk verkeersverlies ondervinden, er zijn geen compensatiemechanismen voorzien.

SD-WAN-beleid:

• Gedefinieerd in de vManage GUI via de interactieve sjabloonwizard.
• Ondersteunt het maken van meerdere beleidsregels, het kopiëren, overnemen en schakelen tussen beleidsregels in realtime.
• Ondersteunt individuele beleidsinstellingen voor verschillende netwerksegmenten (filialen)
• Ze worden gedistribueerd via elk beschikbaar signaalkanaal tussen de controller en de router en/of vSmart - zijn niet direct afhankelijk van de datavlakconnectiviteit tussen de routers. Dit vereist uiteraard IP-connectiviteit tussen de router zelf en de controllers.

  

• Voor gevallen waarin alle beschikbare vestigingen van een vestiging aanzienlijke gegevensverliezen ondervinden die de aanvaardbare drempels voor kritieke toepassingen overschrijden, is het mogelijk om aanvullende mechanismen te gebruiken die de transmissiebetrouwbaarheid vergroten:
  • FEC (voorwaartse foutcorrectie) – maakt gebruik van een speciaal redundant coderingsalgoritme. Bij het verzenden van kritisch verkeer via kanalen met een aanzienlijk verliespercentage kan FEC automatisch worden geactiveerd en kan, indien nodig, het verloren deel van de gegevens worden hersteld. Dit vergroot de gebruikte transmissiebandbreedte enigszins, maar verbetert de betrouwbaarheid aanzienlijk.

    

  • Duplicatie van datastromen – Naast FEC kan het beleid voorzien in automatische duplicatie van verkeer van geselecteerde applicaties in het geval van een nog ernstiger niveau van verliezen die niet door FEC kunnen worden gecompenseerd. In dit geval worden de geselecteerde gegevens via alle tunnels naar de ontvangende tak verzonden, met daaropvolgende deduplicatie (waarbij extra kopieën van pakketten worden geplaatst). Het mechanisme verhoogt het kanaalgebruik aanzienlijk, maar verhoogt ook de transmissiebetrouwbaarheid aanzienlijk.

Cisco SD-WAN-mogelijkheden, zonder directe analogen in DMVPN/PfR

De architectuur van de Cisco SD-WAN-oplossing maakt het in sommige gevallen mogelijk om mogelijkheden te verkrijgen die ofwel uiterst moeilijk te implementeren zijn binnen DMVPN/PfR, ofwel onpraktisch zijn vanwege de vereiste arbeidskosten, ofwel volledig onmogelijk zijn. Laten we eens kijken naar de meest interessante van hen:

Verkeerstechniek (TE)

TE omvat mechanismen waarmee verkeer kan afwijken van het standaardpad dat wordt gevormd door routeringsprotocollen. TE wordt vaak gebruikt om een ​​hoge beschikbaarheid van netwerkdiensten te garanderen, door de mogelijkheid om kritisch verkeer snel en/of proactief over te dragen naar een alternatief (disjunct) transmissiepad, om zo een betere kwaliteit van de dienstverlening of snelheid van herstel te garanderen in het geval van een storing op het hoofdpad.

De moeilijkheid bij het implementeren van TE ligt in de noodzaak om vooraf een alternatief traject te berekenen en te reserveren (controleren). In MPLS-netwerken van telecomoperatoren wordt dit probleem opgelost met behulp van technologieën zoals MPLS Traffic-Engineering met uitbreidingen van de IGP-protocollen en het RSVP-protocol. Ook recentelijk is Segment Routing-technologie, die meer geoptimaliseerd is voor gecentraliseerde configuratie en orkestratie, steeds populairder geworden. In klassieke WAN-netwerken zijn deze technologieën meestal niet vertegenwoordigd of zijn ze beperkt tot het gebruik van hop-by-hop-mechanismen zoals Policy-Based Routing (PBR), die in staat zijn verkeer te vertakken, maar dit op elke router afzonderlijk implementeren - zonder rekening houden met de algehele status van het netwerk of het PBR-resultaat in de vorige of volgende stappen. Het resultaat van het gebruik van deze TE-opties is teleurstellend: MPLS TE wordt vanwege de complexiteit van configuratie en bediening in de regel alleen in het meest kritische deel van het netwerk (kern) gebruikt, en PBR wordt gebruikt op individuele routers zonder de mogelijkheid om een ​​uniform PBR-beleid voor het hele netwerk te creëren. Uiteraard geldt dit ook voor DMVPN-gebaseerde netwerken.

SD-WAN biedt in dit opzicht een veel elegantere oplossing die niet alleen eenvoudig te configureren is, maar ook veel beter schaalbaar is. Dit is het resultaat van de gebruikte architecturen op het besturingsvlak en het beleidsvlak. Door een beleidsvlak in SD-WAN te implementeren, kunt u centraal TE-beleid definiëren: welk verkeer is van belang? voor welke VPN's? Via welke knooppunten/tunnels is het noodzakelijk of juist verboden een alternatieve route te vormen? De centralisatie van het controlevlakbeheer op basis van vSmart-controllers stelt u op zijn beurt in staat routeringsresultaten te wijzigen zonder toevlucht te nemen tot de instellingen van individuele apparaten - routers zien al alleen het resultaat van de logica die is gegenereerd in de vManage-interface en voor gebruik is overgedragen naar vSmart.

Serviceketen

Het vormen van serviceketens is bij klassieke routering een nog arbeidsintensievere taak dan het reeds beschreven Traffic-Engineering-mechanisme. In dit geval is het inderdaad niet alleen nodig om een ​​speciale route te creëren voor een specifieke netwerktoepassing, maar ook om de mogelijkheid te garanderen om verkeer van het netwerk op bepaalde (of alle) knooppunten van het SD-WAN-netwerk te verwijderen voor verwerking door een speciale toepassing of dienst (Firewall, Balancing, Caching, Inspectieverkeer, etc.). Tegelijkertijd is het noodzakelijk om de staat van deze externe diensten te kunnen controleren om black-holing-situaties te voorkomen, en zijn er ook mechanismen nodig die het mogelijk maken dat dergelijke externe diensten van hetzelfde type op verschillende geolocaties worden geplaatst. met de mogelijkheid van het netwerk om automatisch het meest optimale serviceknooppunt te selecteren voor het verwerken van het verkeer van een bepaalde vestiging. In het geval van Cisco SD-WAN is dit vrij eenvoudig te bereiken door het creëren van een passend gecentraliseerd beleid dat alle aspecten van de doelserviceketen in één geheel ‘lijmt’ en automatisch de data- en besturingslogica alleen verandert waar dat nodig is. en wanneer nodig.

De mogelijkheid om geogedistribueerde verwerking van verkeer van geselecteerde soorten applicaties in een bepaalde volgorde te creëren op gespecialiseerde (maar niet gerelateerd aan het SD-WAN-netwerk zelf) apparatuur is misschien wel de meest duidelijke demonstratie van de voordelen van Cisco SD-WAN ten opzichte van klassieke technologieën en zelfs enkele alternatieve SD-oplossingen -WAN van andere fabrikanten.

Het resultaat?

Uiteraard zowel DMVPN (met of zonder Performance Routing) als Cisco SD-WAN uiteindelijk vergelijkbare problemen oplossen met betrekking tot het gedistribueerde WAN-netwerk van de organisatie. Tegelijkertijd leiden aanzienlijke architecturale en functionele verschillen in de Cisco SD-WAN-technologie tot het proces van het oplossen van deze problemen naar een ander kwaliteitsniveau. Samenvattend kunnen we de volgende significante verschillen opmerken tussen SD-WAN- en DMVPN/PfR-technologieën:

• DMVPN/PfR maakt over het algemeen gebruik van beproefde technologieën voor het bouwen van overlay-VPN-netwerken en is qua datavlak vergelijkbaar met de modernere SD-WAN-technologie. Er zijn echter een aantal beperkingen in de vorm van een verplichte statische configuratie van routers en de keuze van topologieën is beperkt tot Hub-n-Spoke. Aan de andere kant heeft DMVPN/PfR een aantal functionaliteiten die nog niet beschikbaar zijn binnen SD-WAN (we hebben het over BFD per applicatie).
• Binnen het besturingsvlak verschillen de technologieën fundamenteel. Rekening houdend met de gecentraliseerde verwerking van signaleringsprotocollen, maakt SD-WAN het in het bijzonder mogelijk om storingsdomeinen aanzienlijk te verkleinen en het proces van het verzenden van gebruikersverkeer te ‘ontkoppelen’ van signaleringsinteractie – tijdelijke onbeschikbaarheid van controllers heeft geen invloed op de mogelijkheid om gebruikersverkeer te verzenden . Tegelijkertijd heeft de tijdelijke onbeschikbaarheid van een filiaal (inclusief de centrale) op geen enkele manier invloed op het vermogen van andere filialen om met elkaar en met de verwerkingsverantwoordelijken te communiceren.
• De architectuur voor de vorming en toepassing van verkeersmanagementbeleid in het geval van SD-WAN is ook superieur aan die in DMVPN/PfR - geo-reservering is veel beter geïmplementeerd, er is geen verbinding met de Hub, er zijn meer mogelijkheden voor boetes Door beleid af te stemmen is de lijst met geïmplementeerde verkeersmanagementscenario’s ook veel groter.
• Het oplossingsorkestratieproces is ook aanzienlijk anders. DMVPN gaat uit van de aanwezigheid van eerder bekende parameters die op de een of andere manier in de configuratie moeten worden weerspiegeld, wat de flexibiliteit van de oplossing en de mogelijkheid van dynamische veranderingen enigszins beperkt. SD-WAN is op zijn beurt gebaseerd op het paradigma dat de router op het eerste moment van verbinding “niets weet” van zijn controllers, maar weet “aan wie je het kunt vragen” - dit is niet alleen voldoende om automatisch communicatie tot stand te brengen met de controllers, maar ook om automatisch een volledig verbonden datavlaktopologie te vormen, die vervolgens flexibel kan worden geconfigureerd/gewijzigd met behulp van beleid.
• In termen van gecentraliseerd beheer, automatisering en monitoring wordt verwacht dat SD-WAN de mogelijkheden van DMVPN/PfR zal overtreffen, die zijn voortgekomen uit klassieke technologieën en zwaarder leunen op de CLI-opdrachtregel en het gebruik van op sjablonen gebaseerde NMS-systemen.
• In SD-WAN hebben de beveiligingsvereisten, vergeleken met DMVPN, een ander kwalitatief niveau bereikt. De belangrijkste principes zijn zero trust, schaalbaarheid en tweefactorauthenticatie.

Deze simpele conclusies kunnen de verkeerde indruk wekken dat het creëren van een netwerk gebaseerd op DMVPN/PfR vandaag de dag alle relevantie heeft verloren. Dit is natuurlijk niet helemaal waar. In gevallen waarin het netwerk bijvoorbeeld veel verouderde apparatuur gebruikt en er geen manier is om deze te vervangen, kunt u met DMVPN “oude” en “nieuwe” apparaten combineren in één geogedistribueerd netwerk met veel van de beschreven voordelen. boven.

Aan de andere kant moet eraan worden herinnerd dat alle huidige Cisco-bedrijfsrouters op basis van IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) tegenwoordig elke bedrijfsmodus ondersteunen - zowel klassieke routering als DMVPN en SD-WAN - de keuze wordt bepaald door de huidige behoeften en het besef dat u op elk moment, met behulp van dezelfde apparatuur, de overstap kunt maken naar meer geavanceerde technologie.

Bron: www.habr.com