Functionele mogelijkheden \u2013 wat kan de ene technologie dat de andere niet kan? En is dat echt zo belangrijk?<\/li>\n<\/ul>\n<\/p>\n
Waarin bestaan de architecturale verschillen en zijn ze zo belangrijk?<\/h3>\n \nElke van de genoemde technologie\u00ebn heeft vele 'bewegende delen', die niet alleen verschillen in rol, maar ook in de principes van interactie met elkaar. De schaalbaarheid, fouttolerantie en algehele effici\u00ebntie van de oplossing hangen rechtstreeks af van hoe doordacht deze principes zijn. <\/p>\n
Laten we de verschillende aspecten van de architectuur nader bekijken:<\/p>\n
Data-plane<\/b> \u2013 het deel van de oplossing dat verantwoordelijk is voor de overdracht van het gebruikersverkeer tussen bron en ontvanger. In DMVPN en SD-WAN wordt dit in wezen op dezelfde manier gerealiseerd op de routers die zijn gebaseerd op Multipoint GRE-tunnels. Het verschil zit in hoe de noodzakelijke set parameters voor deze tunnels wordt vastgesteld:<\/p>\n\nin DMVPN\/PfR<\/b> \u2013 dit is een strikt tweelaagse hi\u00ebrarchie van knooppunten met een stertopologie of Hub-n-Spoke. Een statische configuratie van de Hub en een statische koppeling van de Spoke aan de Hub zijn verplicht, evenals communicatie via het NHRP-protocol voor het vormen van data-plane connectiviteit. Als gevolg hiervan, worden wijzigingen aan de Hub aanzienlijk bemoeilijkt,<\/b>bijvoorbeeld met betrekking tot het wijzigen\/aansluiten van nieuwe WAN-k connectors of het wijzigen van parameters van bestaande.<\/li>\nin SD-WAN<\/b> \u2013 dit is een volledig dynamisch model voor het ontdekken van parameters van opgelegde tunnels, steunt op de control-plane (protocol OMP) en orchestration-plane (interactie met de vBond-controller voor het ontdekken van controllers en NAT-traversal). De opgelegde topologie\u00ebn kunnen hierbij vari\u00ebren, inclusief hi\u00ebrarchische. Binnen de vastgestelde opgelegde topologie van tunnels is flexibele configuratie van de logische topologie in elke afzonderlijke VPN (VRF) mogelijk.<\/li>\n<\/ul>\n Control-plane<\/b> \u2013 functies voor uitwisseling, filtering en wijziging van routerings- en andere informatie tussen de componenten van de oplossing. <\/p>\n\nin DMVPN\/PfR<\/b> \u2013 dit gebeurt alleen tussen de Hub- en Spoke-routers. Directe uitwisseling van routeringsinformatie tussen Spoke is niet mogelijk. Als gevolg hiervan, kan de control-plane en data-plane niet functioneren zonder een actieve Hub.<\/b>, wat extra eisen voor hoge beschikbaarheid aan Hub oplegt, die niet altijd kunnen worden nagekomen.<\/li>\nin SD-WAN<\/b> \u2013 de control-plane wordt nooit direct tussen routers uitgevoerd \u2013 de interactie vindt plaats op basis van het OMP-protocol en moet worden uitgevoerd via een aparte gespecialiseerde type controller vSmart, wat de mogelijkheid van load balancing, geo-redundantie en gecentraliseerd beheer van signaalbelasting waarborgt. Een andere eigenschap van het OMP-protocol is de significante weerstand tegen verlies en onafhankelijkheid van de snelheid van de communicatieverbinding met de controllers (binnen redelijke grenzen, uiteraard). Dit maakt het mogelijk om SD-WAN-controllers zowel in publieke als priv\u00e9-clouds te plaatsen met toegang via het internet.<\/li>\n<\/ul>\n Policy-plane<\/b> \u2013 het onderdeel van de oplossing dat verantwoordelijk is voor het defini\u00ebren, verspreiden en toepassen van verkeersbeheerbeleid op het gedistribueerde netwerk.<\/p>\n\nDMVPN <\/b>\u2013 is in feite beperkt door de kwaliteitsservice (QoS) beleid, die individueel op elke router kan worden ingesteld via CLI of Prime Infrastructure-sjablonen.<\/li>\nDMVPN\/PfR<\/b> \u2013 PfR-beleid wordt gevormd op de gecentraliseerde router Master Controller (MC) via CLI en vervolgens automatisch verspreid naar de filialen MC. Hierbij worden dezelfde paden voor de verspreiding van beleid gebruikt als voor de data-plane. Er is geen mogelijkheid om het uitwisselen van beleid, routeringsinformatie en gebruikersgegevens uit elkaar te halen. Verspreiding van beleid vereist obligatoir IP-connectiviteit tussen Hub en Spoke. Hierbij kan de functie van MC indien nodig worden gecombineerd met de DMVPN-router. Het gebruik van Prime Infrastructure-sjablonen voor de centrale vorming van beleid is mogelijk (maar niet verplicht). Een belangrijk kenmerk is dat beleid globaal op het hele netwerk op dezelfde manier wordt gevormd \u2013 individuele beleidsregels voor aparte segmenten worden niet ondersteund.<\/b>.<\/li>\nSD-WAN<\/b> \u2013 het beheer van dataverkeer en de kwaliteitsservice wordt centraal bepaald via de grafische interface van Cisco vManage, die ook via het internet toegankelijk is (indien nodig). Ze worden verspreid via signaalroutes, rechtstreeks of indirect via vSmart-controllers (afhankelijk van het type beleid). Ze zijn niet afhankelijk van de datavliegtuigsconnectiviteit tussen routers, aangezien ze alle beschikbare paden voor dataverkeer tussen de controller en de router gebruiken.\n Voor verschillende netwerksegmenten is het mogelijk om flexibele beleidsvorming te realiseren \u2013 het toepassingsgebied van het beleid wordt bepaald door een verscheidenheid aan unieke identificatoren die in de oplossing zijn voorzien \u2013 vestigingsnummer, type applicatie, verkeersrichting, enzovoort.\n<\/li>\n<\/ul>\n
Orkestratievlak<\/b> \u2013 mechanismen die componenten in staat stellen om elkaar dynamisch te detecteren, configureren en hun volgende interactie te co\u00f6rdineren.<\/p>\n\nin DMVPN\/PfR<\/b> De wederzijdse ontdekking door routers is gebaseerd op de statische configuratie van Hub-apparaten en de bijbehorende instelling van Spoke-apparaten. Dynamische ontdekking vindt alleen plaats voor Spoke, dat zijn verbindingsparameters doorgeeft aan het Hub-apparaat, dat op zijn beurt van tevoren in de configuratie van de Spoke is opgenomen. Zonder IP-connectiviteit van de Spoke met minstens \u00e9\u00e9n Hub is het onmogelijk om een datavliegtuig of controle-vliegtuig te vormen.<\/b><\/li>\nin SD-WAN<\/b> De orkestratie van de componenten van de oplossing vindt plaats met behulp van de vBond-controller, waarmee elk component (routers en vManage\/vSmart-controllers) vooraf IP-connectiviteit moet hebben vastgesteld.\n Aanvankelijk weten de componenten niet van de verbindingsparameters van elkaar \u2013 hiervoor hebben ze een tussenpersoon-orkestrator vBond nodig. Het algemene principe is het volgende: elke component ontdekt in de initi\u00eble fase (automatisch of statisch) alleen de verbindingsparameters met vBond, waarna vBond de router informeert over de vManage- en vSmart-controllers (eerder ontdekt), wat het mogelijk maakt om alle noodzakelijke signaleringsverbindingen automatisch tot stand te brengen. <\/p>\n
In de volgende stap zal de nieuwe router via OMP-uitwisseling met de vSmart-controller informatie verkrijgen over de andere routers in het netwerk. Op deze manier kan de router, die aanvankelijk niets weet over de netwerkparameters, volledig automatisch de controllers ontdekken en zich verbinden en vervolgens automatisch de connectiviteit met andere routers opzetten. De verbindingsparameters van alle componenten zijn in eerste instantie onbekend en kunnen tijdens de werking veranderen.\n<\/li>\n<\/ul>\n
Beheerlaag<\/b> \u2013 het deel van de oplossing dat centraal beheer en monitoring biedt.<\/p>\n\nDMVPN\/PfR<\/b> \u2013 er is geen gespecialiseerd management-plane opgelost. Voor basisautomatisering en monitoring is het gebruik van producten zoals Cisco Prime Infrastructure mogelijk. Elke router kan worden beheerd via de commandoregel CLI. Integraties met externe systemen via API zijn niet voorzien.<\/b><\/li>\nSD-WAN<\/b> \u2013 alle standaardinteracties en monitoring worden centraal uitgevoerd via de grafische interface van de vManage-controller. Alle mogelijkheden van de oplossing zijn zonder uitzondering configureerbaar via vManage, evenals via een volledig gedocumenteerde bibliotheek van de REST API.\n Alle instellingen van het SD-WAN-netwerk in vManage zijn gereduceerd tot twee hoofdelementen \u2013 het cre\u00ebren van apparaatsjablonen (Device Template) en het opstellen van beleid dat de logica van het netwerk en de verwerking van verkeer definieert. Hierbij kiest vManage, terwijl het beleid dat door de beheerder is opgesteld uitzendt, automatisch welke wijzigingen op welke individuele apparaten\/controllers moeten worden aangebracht, wat de effectiviteit en schaalbaarheid van de oplossing aanzienlijk verhoogt.<\/p>\n
Via de vManage-interface is niet alleen de configuratie van de Cisco SD-WAN-oplossing beschikbaar, maar ook een volledige monitoring van de status van alle componenten van de oplossing tot de huidige status van de metrics van afzonderlijke tunnels en het gebruik van verschillende applicaties op basis van DPI-analyse.<\/p>\n
Ondanks de centralisatie van interactie beschikken alle componenten (controllers en routers) ook over een volledig functionele CLI (command line interface), die nodig is tijdens de implementatiefase of in geval van een noodsituatie voor lokale diagnose. In de normale modus (met een signaalverbinding tussen de componenten) is de commandoregel op routers alleen beschikbaar voor diagnostiek en niet toegankelijk voor het aanbrengen van lokale wijzigingen, wat zorgt voor lokale veiligheid en een enkele bron van wijzigingen in zo'n netwerk \u2013 vManage.<\/li>\n<\/ul>\n
\nGe\u00efntegreerde beveiliging<\/b> \u2013 hierbij gaat het niet alleen om de bescherming van gebruikersgegevens tijdens overdracht via open kanalen, maar ook om de algehele beveiliging van het WAN-netwerk op basis van de gekozen technologie.<\/p>\n\nin DMVPN\/PfR<\/b> er is een mogelijkheid tot versleuteling van gebruikersgegevens en signaalprotocollen. Bij gebruik van bepaalde modellen routers zijn aanvullend functies van firewalls met verkeersinspectie, IPS\/IDS beschikbaar. Er is een mogelijkheid voor segmentatie van filialen met behulp van VRF. Er is ook een mogelijkheid voor (\u00e9\u00e9n-factorauthenticatie) van controleprotocollen.\n Hierbij wordt de externe router standaard beschouwd als een vertrouwd netwerkcomponent \u2013 d.w.z. gevallen van fysieke compromittering van afzonderlijke apparaten worden niet verondersteld en niet in aanmerking genomen, er is geen twee-factorauthenticatie van de componenten van de oplossing, wat in het geval van een geografisch verspreid netwerk ernstige aanvullende risico's kan met zich meebrengen.<\/b> <\/li>\nin SD-WAN<\/b> In navolging van DMVPN is er een mogelijkheid tot versleuteling van gebruikersgegevens, maar met aanzienlijk uitgebreidere netwerksbeveiligingsfuncties en L3\/VRF-segmentatie (MSE, IPS\/IDS, URL-filtering, DNS-filtering, AMP\/TG, SASE, TLS\/SSL-proxy, enz.). Daarbij wordt de uitwisseling van versleutelingssleutels effici\u00ebnter uitgevoerd via vSmart-controllers (in plaats van rechtstreeks), via vooraf ingestelde signaalverbindingen, beveiligd met DTLS\/TLS-versleuteling op basis van beveiligingscertificaten. Dit garandeert op zijn beurt de veiligheid van deze uitwisseling en zorgt voor een betere schaalbaarheid van de oplossing tot tientallen duizenden apparaten in \u00e9\u00e9n netwerk.\n Alle signaalverbindingen (controller-controller, controller-router) zijn ook beveiligd op basis van DTLS\/TLS. Routers worden bij de productie voorzien van beveiligingscertificaten die vervangingen\/verlengingen mogelijk maken. Tweefactorauthenticatie wordt bereikt door het gelijktijdig voldoen aan twee voorwaarden voor de werking van de router\/controller in een SD-WAN-netwerk:<\/p>\n
\nActief beveiligingscertificaat<\/li>\n Duidelijke en bewuste toevoeging door de beheerder van elk component aan de 'witte' lijst van toegestane apparaten.<\/li>\n<\/ul>\n\n<\/li>\n<\/ul>\n
Functionele verschillen tussen SD-WAN en DMVPN\/PfR<\/h2>\n \nAls we over de functionele verschillen spreken, moeten we opmerken dat veel van deze verschillen voortvloeien uit architecturale \u2013 het is geen geheim dat ontwikkelaars bij het opstellen van de architectuur van een oplossing uitgaan van de mogelijkheden die ze uiteindelijk willen verkrijgen. Laten we de meest significante verschillen tussen de twee technologie\u00ebn bekijken.<\/p>\n
AppQ (Application Quality) \u2013 functies voor het waarborgen van de kwaliteit van het verkeer van zakelijke applicaties<\/h3>\n \nDe belangrijkste functies van de besproken technologie\u00ebn zijn gericht op het verbeteren van de gebruikerservaring bij het gebruik van zakelijke kritische applicaties in een gedistribueerd netwerk. Dit is vooral belangrijk in situaties waarin een deel van de infrastructuur niet wordt beheerd door IT of zelfs niet de succesvolle overdracht van gegevens garandeert.<\/p>\n
DMVPN biedt zelf geen dergelijke mechanismen. Het beste wat mogelijk is in een klassieke DMVPN-netwerk, is het classificeren van uitgaand verkeer op basis van applicaties en dit prioriteren bij de overdracht naar de WAN-kanaal. De keuze van de DMVPN-tunnel is in dit geval alleen afhankelijk van de beschikbaarheid en het resultaat van de routingprotocollen. Hierbij wordt geen rekening gehouden met de end-to-end status van de route\/tunnel en de mogelijke gedeeltelijke degradatie vanuit het perspectief van belangrijke metrics die relevant zijn voor netwerkapplicaties - vertraging, variatie in vertraging (jitter) en verlies (%). Daarom heeft het weinig zin om klassieke DMVPN rechtstreeks te vergelijken met SD-WAN met betrekking tot het oplossen van AppQ-taken \u2013 DMVPN kan deze taak niet uitvoeren. Wanneer we Cisco Performance Routing (PfR) in deze context toevoegen, verandert de situatie en wordt de vergelijking met Cisco SD-WAN relevanter. <\/p>\n
Voordat we de verschillen bespreken, kort over de overeenkomsten tussen de technologie\u00ebn. Dus, beide technologie\u00ebn:<\/p>\n
\nbeschikken over een mechanisme dat het mogelijk maakt om de status van elke opgezette tunnel dynamisch te evalueren op basis van bepaalde metrics \u2013 in ieder geval latentie, variabiliteit van de latentie en pakketverlies (%).<\/li>\n gebruiken een specifieke set tools voor het vormen, verspreiden en toepassen van regels (beleid) voor dataverkeerbeheer, rekening houdend met de resultaten van de metingen van de status van de belangrijkste metrics van de tunnels.<\/li>\n classificeren applicatietraffic op de niveaus L3-L4 (DSCP) van het OSI-model of op L7-applicatiesignaturen op basis van de ingebouwde DPI-mechanismen in de router.<\/li>\n stellen voor significante applicaties toegestane drempelwaarden voor metrics vast, standaardregels voor verkeersoverdracht en regels voor het herrouteren van verkeer bij het overschrijden van drempelwaarden.<\/li>\n gebruik bij het encapsuleren van verkeer in GRE\/IPSec het al gevestigde mechanisme in de industrie voor het verplaatsen van interne DSCP-markeringen naar de externe GRE\/IPSec-pakketheader, waardoor de QoS-beleidslijnen van de organisatie en de telecomoperator (bij overeenkomend SLA) kunnen worden gesynchroniseerd.<\/li>\n<\/ul>\n\n
Hoe verschillen de mechanismen voor het evalueren van end-to-end metrics van SD-WAN en DMVPN\/PfR?<\/h3>\n \nDMVPN\/PfR <\/b><\/p>\n\nVoor het evalueren van standaard metrics van de tunnelstatus worden zowel actieve als passieve software-sensoren (Probes) gebruikt. Actieve sensoren zijn gebaseerd op gebruikersverkeer, passieve simuleren dergelijk verkeer (bij afwezigheid). <\/li>\n Fijnafstemming van timers en detectievoorwaarden voor degradatie is afwezig \u2013 het algoritme staat vast.<\/li>\n Vervolgens is het ook mogelijk om de gebruikte bandbreedte in de uitgaande richting te meten. Dit voegt extra flexibiliteit toe aan het verkeersbeheer van DMVPN\/PfR.<\/li>\n Sommige mechanismen van PfR vertrouwen bij het overschrijden van metrics op feedback in de vorm van speciale TCA (Threshold Crossing Alert) berichten, die van de ontvanger van het verkeer naar de bron moeten komen, wat impliceert dat de status van de gemeten kanalen op zijn minst voldoende moet zijn om dergelijke TCA-berichten te verzenden. Dit is in de meeste gevallen geen probleem, maar kan uiteraard niet gegarandeerd worden. <\/li>\n<\/ul>\n\nSD-WAN <\/b><\/p>\n\nVoor de algehele evaluatie van standaardmetriek van de tunnelstatus wordt het BFD-protocol in echo-modus gebruikt. Hiervoor is geen speciale feedback in de vorm van TCA of soortgelijke berichten nodig \u2013 de isolatie van de falen domeinen wordt gewaarborgd. Het is ook niet nodig dat gebruikersverkeer aanwezig is om de status van de tunnel te evalueren.<\/li>\n Er is een mogelijkheid voor verfijnde instelling van BFD-timers om de reactietijd en gevoeligheid van het algoritme voor degradaties van de communicatielijn van enkele seconden tot minuten te regelen.\n
Op het moment van schrijven van dit artikel is er in elke tunnel slechts \u00e9\u00e9n BFD-sessie voorzien. Dit cre\u00ebert potentieel een lagere granulariteit bij de analyse van de status van de tunnel. In de praktijk kan dit een beperking vormen, maar alleen bij gebruik van een WAN-verbinding op basis van MPLS L2\/L3 VPN met een overeengekomen QoS SLA \u2013 als de DSCP-markering van het BFD-verkeer (na encapsulatie in IPSec\/GRE) overeenkomt met de hoogprioritaire wachtrij in het netwerk van de provider, kan dit de nauwkeurigheid en snelheid van het detecteren van degradaties voor laagprioritair verkeer be\u00efnvloeden. Er is echter een mogelijkheid om de standaardmarkering van BFD aan te passen om het risico van dergelijke situaties te verminderen. In toekomstige versies van Cisco SD-WAN wordt meer verfijnde BFD-instelling verwacht, evenals de mogelijkheid om meerdere BFD-sessies binnen \u00e9\u00e9n tunnel met afzonderlijke DSCP-waarden (voor verschillende toepassingen) te starten.<\/li>\n BFD maakt het bovendien mogelijk om de maximale pakketgrootte te beoordelen die mogelijk is om over een bepaalde tunnel te verzenden zonder fragmentatie. Dit stelt SD-WAN in staat om parameters zoals MTU en TCP MSS Adjust dynamisch in te stellen om de beschikbare bandbreedte op elke kanaal zo effectief mogelijk te benutten.<\/li>\n In SD-WAN is ook de optie beschikbaar om QoS-synchronisatie met providers niet alleen op basis van L3 DSCP-velden, maar ook op basis van L2 CoS-waarden, die automatisch kunnen worden gegenereerd in het filiaalnetwerk door gespecialiseerde apparaten - bijvoorbeeld IP-telefoons.<\/li>\n<\/ul>\n<\/p>\n
Hoe verschillen de mogelijkheden, methoden voor bepaling en toepassing van AppQ-beleid?<\/h3>\n <\/p>\n
DMVPN\/PfR-beleidsregels:<\/h4>\n <\/p>\n
\nWorden gedefinieerd op de router(s) van het centrale filiaal (CF) via de CLI of CLI-configuratiesjablonen. Het opstellen van CLI-sjablonen vereist voorbereiding en kennis van de beleidsyntax.\n
Wordt wereldwijd gedefinieerd zonder mogelijkheid voor individuele aanpassing\/wijzigingen volgens de vereisten van specifieke netwerksegmenten.<\/b><\/li>\nInteractieve beleidsvorming in de grafische interface is niet beschikbaar.<\/li>\n Wijzigingen volgen, erven, en het maken van meerdere versies van beleidsregels voor snelle schakeling zijn niet voorzien.<\/li>\n Worden automatisch verspreid naar routers van externe filialen. Hiervoor worden dezelfde communicatiemiddelen gebruikt als voor de overdracht van gebruikersgegevens. Bij afwezigheid van een communicatiekanaal tussen het centrale en externe filiaal is verspreiding\/wijziging van beleidsregels niet mogelijk.<\/li>\n Worden toegepast op elke router en modificeren indien nodig het resultaat van standaard routeringsprotocollen, met een hogere prioriteit. <\/li>\n In gevallen waarin alle WAN-kanalen van het filiaal aanzienlijke dataverliezen ondervinden, zijn compensatiemechanismen niet voorzien.<\/b>.<\/li>\n<\/ul>\n <\/p>\n
SD-WAN-beleidsregels:<\/h4>\n <\/p>\n
\nWorden gedefinieerd in de grafische interface vManage via een interactieve sjablonenwizard.<\/li>\n Ondersteunt het maken van meerdere beleidsregels, kopi\u00ebren, erven en schakelen tussen beleidsregels in real-time.<\/li>\n Ondersteunt individuele aanpassing van beleid voor verschillende segmenten (filialen) van het netwerk.<\/li>\n Worden verspreid via elk beschikbaar signaal kanaal tussen de controller en de router en\/of vSmart - zijn niet direct afhankelijk van de data-plane connectiviteit tussen de routers. IP-connectiviteit tussen de router en de controllers is echter vereist.\n
In gevallen waarin alle beschikbare kanalen van het filiaal aanzienlijke dataverliezen ondervinden die de toegestane drempelwaarden voor kritische toepassingen overschrijden, kunnen aanvullende mechanismen worden gebruikt om de betrouwbaarheid van de overdracht te verhogen:\n\nFEC (Forward Error Correction)<\/b> maakt gebruik van een speciaal algoritme voor redundante codering. Bij de overdracht van kritische data over kanalen met een aanzienlijk percentage verlies, kan FEC automatisch worden geactiveerd en het stelt in staat om verloren gegevens indien nodig te herstellen. Dit verhoogt de gebruikte bandbreedte lichtjes, maar verhoogt de betrouwbaarheid aanzienlijk.\n
Duplicatie van datastromen<\/b> Naast FEC kan het beleid ook automatische duplicatie van het verkeer van geselecteerde toepassingen omvatten in het geval van een nog ernstiger verliesniveau, dat niet kan worden gecompenseerd door middel van FEC. In dit geval worden de geselecteerde gegevens over alle tunnels naar de ontvangende vestiging verzonden, gevolgd door deduplicatie (het weggooien van overbodige kopie\u00ebn van gegevenspakketten). Dit mechanisme verhoogt de benutting van de kanalen aanzienlijk, maar verhoogt eveneens de betrouwbaarheid van de overdracht aanzienlijk.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n <\/p>\n
De mogelijkheden van Cisco SD-WAN, zonder directe tegenhangers in DMVPN\/PfR<\/h3>\n \nDe architectuur van de Cisco SD-WAN-oplossing biedt in sommige gevallen mogelijkheden waarvan de implementatie binnen DMVPN\/PfR ofwel uiterst moeilijk is, ofwel economisch niet verantwoord is vanwege de benodigde arbeidsinspanningen, ofwel zelfs helemaal niet mogelijk is. Laten we de meest interessante hiervan bekijken:<\/p>\n
Traffic-Engineering (TE)<\/h4>\n \nTE omvat mechanismen die het mogelijk maken om verkeer af te leiden van de standaardroute die door de routeringsprotocollen is gevormd. TE wordt vaak gebruikt om hoge beschikbaarheid van netwerkdiensten te garanderen, door het vermogen om snel en\/of vooraf belangrijk verkeer naar een alternatieve (niet-overlappende) overdrachtsroute om te leiden, met als doel een betere kwaliteit van service of een snellere herstel in geval van een storing op de primaire route. <\/p>\n
De complexiteit van het implementeren van TE ligt in de noodzaak om van tevoren een alternatieve route te berekenen en te reserveren (te controleren). In MPLS-netwerken van telecomoperators wordt deze taak opgelost met technologie\u00ebn zoals MPLS Traffic Engineering met extensies van IGP-protocollen en de RSVP-protocol. Ook in recentere tijd wint Segment Routing aan populariteit, wat beter geoptimaliseerd is voor gecentraliseerde configuratie en orkestratie. In klassieke WAN-netwerken zijn deze technologie\u00ebn vaak niet aanwezig of gereduceerd tot het gebruik van hop-by-hop mechanismen zoals Policy-Based Routing (PBR), die in staat zijn om verkeer af te splitten, maar dit afzonderlijk op elke router realiseren \u2013 zonder rekening te houden met de algehele netwerkinfrastructuur of de resultaten van PBR in eerdere of latere stappen. Het resultaat van het toepassen van deze TE-opties is teleurstellend \u2013 MPLS TE wordt vanwege de complexiteit van de configuratie en het onderhoud doorgaans alleen in het meest kritische deel van het netwerk (de kern) gebruikt, terwijl PBR op afzonderlijke routers wordt toegepast zonder de mogelijkheid om een uniform PBR-beleid voor het hele netwerk te vormen. Dit geldt uiteraard ook voor netwerken op basis van DMVPN.<\/p>\n
Service-chaining <\/h4>\n \nHet vormen van serviceketens is een nog arbeidsintensievere taak in de klassieke routering dan het al beschreven Traffic Engineering-mechanisme. In dit geval is het namelijk niet alleen nodig om een speciaal pad voor een bepaalde netwerktoepassing te cre\u00ebren, maar ook om het mogelijk te maken om verkeer uit het netwerk op bepaalde (of op alle) knooppunten van het SD-WAN-netwerk te leiden voor verwerking door een speciale toepassing of dienst (zoals MSE, Balancering, Caching, Verkeersinspectie, enz.). Daarbij is het noodzakelijk om de status van deze externe diensten te controleren, om black-holing situaties te voorkomen, en bovendien moeten er mechanismen zijn die het mogelijk maken om dergelijke uniforme externe diensten op verschillende geo-locaties te plaatsen, zodat het netwerk automatisch de meest optimale serviceknoop voor de verwerking van verkeer van een bepaalde tak kan kiezen. In het geval van Cisco SD-WAN is dit vrij gemakkelijk te bereiken door een bijbehorende gecentraliseerde beleidsmaatregel te cre\u00ebren die alle aspecten van de doelserviceketen in \u00e9\u00e9n geheel 'plakt' en automatisch de logica van data-plane en control-plane alleen daar en wanneer dat nodig is, aanpast.<\/p>\n
Wat is het resultaat?<\/h2>\n \nHet is duidelijk dat zowel DMVPN (samen met of zonder Performance Routing) als Cisco SD-WAN uiteindelijk zeer vergelijkbare taken oplossen<\/b> ten opzichte van het gedistribueerde WAN-netwerk van de organisatie. Daarbij brengen de aanzienlijke architectonische en functionele verschillen van de technologie Cisco SD-WAN het proces van het oplossen van deze taken naar een ander kwalitatief niveau<\/b>. Samenvattend kunnen de volgende belangrijke verschillen tussen de technologie\u00ebn SD-WAN en DMVPN\/PfR worden opgemerkt:<\/p>\n\nDMVPN\/PfR maakt gebruik van door de tijd bewezen technologie\u00ebn voor het opzetten van overlays van VPN-netwerken en vertoont gelijkenissen met de modernere SD-WAN-technologie wat betreft de data-plane, hoewel er enkele beperkingen zijn in de vorm van verplichte statische configuraties van routers en een beperkte keuze in topologie\u00ebn, namelijk Hub-n-Spoke. Aan de andere kant heeft DMVPN\/PfR enkele functionele mogelijkheden die momenteel niet beschikbaar zijn binnen het kader van SD-WAN (zoals per-application BFD).<\/li>\n Binnen de control-plane technologie\u00ebn zijn ze fundamenteel verschillend. Met gecentraliseerde verwerking van signaalprotocollen stelt SD-WAN in het bijzonder in staat om de uitvaldomeinen aanzienlijk te verkleinen en het proces van het verzenden van gebruikersverkeer los te koppelen van de signaalinteractie \u2013 tijdelijke ontoegankelijkheid van controllers heeft geen invloed op de mogelijkheid om gebruikersverkeer te verzenden. Tegelijkertijd heeft de tijdelijke ontoegankelijkheid van een bepaald filiaal (inclusief het centrale) geen invloed op de mogelijkheid van andere filialen om met elkaar en met de controllers te communiceren.<\/li>\n De architectuur voor het opstellen en toepassen van verkeersbeheersingsbeleid in het geval van SD-WAN gaat ook verder dan die van DMVPN\/PfR \u2013 geo-reservering is aanzienlijk beter gerealiseerd, er is geen binding aan een Hub, er zijn meer mogelijkheden voor gedetailleerde aanpassing van beleid en de lijst van uitvoerbare verkeersbeheersingsscenario's is ook aanzienlijk groter.<\/li>\n Het proces van orkestratie van de oplossing verschilt ook aanzienlijk. DMVPN veronderstelt dat er vooraf bekende parameters zijn die op de een of andere manier in de configuratie moeten worden weerspiegeld, wat de flexibiliteit van de oplossing en de mogelijkheid van dynamische wijzigingen enigszins beperkt. Aan de andere kant gaat SD-WAN uit van de paradigma dat de router op het moment van verbinding 'niets weet' over zijn controllers, maar wel 'waar hij vragen kan stellen' \u2013 dit is voldoende voor niet alleen de automatische verbinding met de controllers, maar ook voor de automatische opstelling van een volledig verbonden data-plane topologie, die vervolgens flexibel kan worden ingesteld\/wijzigd met behulp van beleidsregels.<\/li>\n Op het gebied van gecentraliseerd beheer, automatisering en monitoring overtreft SD-WAN naar verwachting de mogelijkheden van DMVPN\/PfR, die zijn ontstaan uit de evolutie van traditionele technologie\u00ebn en in hoge mate afhankelijk zijn van de commandoregel CLI en het gebruik van NMS-systemen op basis van sjablonen. <\/li>\n Bij SD-WAN zijn de beveiligingseisen in vergelijking met DMVPN naar een ander kwaliteitsniveau gestegen. De belangrijkste principes zijn \u2013 zero trust, schaalbaarheid en tweefactorauthenticatie.<\/li>\n<\/ul>\n\nUit deze eenvoudige conclusies kan een onjuist beeld ontstaan dat het cre\u00ebren van een netwerk op basis van DMVPN\/PfR vandaag de dag helemaal niet meer relevant is. Dat is natuurlijk niet helemaal waar. Bijvoorbeeld, in situaties waar in het netwerk veel verouderde apparatuur wordt gebruikt en er geen mogelijkheid is om deze te vervangen, kan DMVPN het mogelijk maken om 'oude' en 'nieuwe' apparaten te combineren in \u00e9\u00e9n geo-gedeeld netwerk met veel van de hierboven beschreven voordelen.<\/p>\n
Aan de andere kant moet worden onthouden dat alle actuele Cisco bedrijfsrouters op basis van IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) vandaag de dag elke werksituatie ondersteunen \u2013 zowel klassieke routering als DMVPN en SD-WAN \u2013 de keuze wordt bepaald door de huidige behoeften en het begrip dat op elk moment met dezelfde apparatuur kan worden overgestapt naar een meer geavanceerde technologie.<\/b>habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0421 \u0430\u0432\u0433\u0443\u0441\u0442\u0430 2017 \u0433\u043e\u0434\u0430, \u043a\u043e\u0433\u0434\u0430 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f Cisco \u043f\u0440\u0438\u043e\u0431\u0440\u0435\u043b\u0430 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044e Viptela, \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u0439 \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u0435\u043c\u043e\u0439 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0435\u0439 \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u0438 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0445 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0442\u0438\u0432\u043d\u044b\u0445 \u0441\u0435\u0442\u0435\u0439 \u0441\u0442\u0430\u043b\u0430 Cisco SD-WAN. \u0417\u0430 \u043f\u0440\u043e\u0448\u0435\u0434\u0448\u0438\u0435 3 \u0433\u043e\u0434\u0430 SD-WAN \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u044f \u043f\u0440\u043e\u0448\u043b\u0430 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0439, \u043a\u0430\u043a \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0433\u043e, \u0442\u0430\u043a \u0438 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0433\u043e \u0445\u0430\u0440\u0430\u043a\u0442\u0435\u0440\u0430. \u0422\u0430\u043a \u0437\u043d\u0430\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u0440\u0430\u0441\u0448\u0438\u0440\u0438\u043b\u0438\u0441\u044c \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u0435 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u0438 \u043f\u043e\u044f\u0432\u0438\u043b\u0430\u0441\u044c \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0430 \u043d\u0430 \u043a\u043b\u0430\u0441\u0441\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0442\u043e\u0440\u0430\u0445 \u0441\u0435\u0440\u0438\u0439 Cisco ISR 1000, ISR 4000, ASR 1000 \u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91349,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91348","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t