Funzionalit\u00e0: cosa pu\u00f2 fare una tecnologia che un'altra non pu\u00f2? E quanto \u00e8 importante?<\/li>\n<\/ul>\n<\/p>\n
Quali sono le differenze architettoniche e quanto sono importanti?<\/h3>\n \nIn ciascuna delle tecnologie indicate ci sono molte \"parti in movimento\", che non solo differiscono per ruolo, ma anche per i principi di interazione l'una con l'altra. La scalabilit\u00e0, la tolleranza ai guasti e l'efficienza complessiva della soluzione dipendono direttamente da quanto siano ben pensati questi principi e dalla meccanica generale della soluzione. <\/p>\n
Esaminiamo pi\u00f9 in dettaglio i vari aspetti dell'architettura:<\/p>\n
Data-plane<\/b> \u2013 la parte della soluzione responsabile della trasmissione del traffico utente tra sorgente e destinatario. In DMVPN e SD-WAN \u00e8 implementato sostanzialmente allo stesso modo sui router basati su tunnel GRE multipoint. La differenza sta nel modo in cui viene formata la necessaria serie di parametri per questi tunnel:<\/p>\n\nin DMVPN\/PfR<\/b> \u2013 \u00e8 esclusivamente una gerarchia a due livelli di nodi con topologia a \"Stella\" o Hub-n-Spoke. \u00c8 necessaria una configurazione statica dell'Hub e un'associazione statica dello Spoke all'Hub, nonch\u00e9 l'interazione tramite il protocollo NHRP per formare la connettivit\u00e0 del data-plane. Di conseguenza, \u00e8 notevolmente complicato effettuare modifiche sull'Hub<\/b>, ad esempio, relative alla modifica\/connessione di nuovi canali WAN o cambiamenti nei parametri esistenti.<\/li>\nin SD-WAN<\/b> \u2013 \u00e8 un modello di scoperta dei parametri dei tunnel completamente dinamico, basato sul control-plane (protocollo OMP) e sull'orchestration-plane (interazione con il controller vBond per le attivit\u00e0 di scoperta dei controller e NAT traversal). In questo caso, le topologie sovrapposte possono essere qualsiasi, comprese quelle gerarchiche. All'interno della topologia sovrapposta stabilita dei tunnel, \u00e8 possibile una configurazione flessibile della topologia logica in ciascun VPN (VRF).<\/li>\n<\/ul>\n Control-plane<\/b> \u2013 funzioni di scambio, filtraggio e modifica delle informazioni di routing e di altro tipo tra i componenti della soluzione. <\/p>\n\nin DMVPN\/PfR<\/b> \u2013 avviene solo tra i router Hub e Spoke. Lo scambio diretto di informazioni di routing tra gli Spoke non \u00e8 possibile. Di conseguenza, senza un Hub attivo, il funzionamento del control-plane e del data-plane non \u00e8 possibile.<\/b>, che pone ulteriori requisiti di alta disponibilit\u00e0 su Hub, che non sempre possono essere soddisfatti.<\/li>\nin SD-WAN<\/b> \u2013 il control-plane non \u00e8 mai realizzato direttamente tra i router \u2013 l'interazione avviene sulla base del protocollo OMP ed \u00e8 sempre effettuata tramite un tipo di controller vSmart specializzato, il che consente bilanciamento, geo-riserva e gestione centralizzata del carico di segnalazione. Un'altra caratteristica del protocollo OMP \u00e8 la sua notevole resilienza alle perdite e indipendenza dalla velocit\u00e0 della connessione con i controller (nei limiti ragionevoli, naturalmente). Ci\u00f2 consente di posizionare i controller SD-WAN sia in cloud pubblici che privati con accesso tramite Internet.<\/li>\n<\/ul>\n Policy-plane<\/b> \u2013 la parte della soluzione responsabile della definizione, distribuzione e applicazione delle politiche di gestione del traffico su una rete distribuita.<\/p>\n\nDMVPN <\/b>\u2013 \u00e8 di fatto limitato alle politiche di qualit\u00e0 del servizio (QoS), configurate individualmente su ciascun router tramite CLI o modelli Prime Infrastructure.<\/li>\nDMVPN\/PfR<\/b> \u2013 le politiche PfR vengono generate su un router centralizzato Master Controller (MC) tramite CLI e successivamente distribuite automaticamente ai MC remoti. In questo processo vengono utilizzati gli stessi canali di trasmissione delle politiche di data-plane. Non esiste la possibilit\u00e0 di separare lo scambio di politiche, informazioni di routing e dati utente. La distribuzione delle politiche richiede la presenza obbligatoria di connettivit\u00e0 IP tra Hub e Spoke. In questo caso, la funzione MC pu\u00f2 essere combinata se necessario con il router DMVPN. \u00c8 possibile (ma non necessario) utilizzare modelli Prime Infrastructure per la creazione centralizzata di politiche. Una caratteristica importante \u00e8 che le politiche vengono generate globalmente in tutta la rete in modo uniforme \u2013 le politiche individuali per singoli segmenti non sono supportate.<\/b>.<\/li>\nSD-WAN<\/b> \u2013 Le politiche di gestione del traffico e della qualit\u00e0 del servizio sono definite centralmente tramite l'interfaccia grafica Cisco vManage accessibile anche tramite Internet (se necessario). Vengono diffuse tramite canali di segnale in modo diretto o indiretto attraverso i controller vSmart (a seconda del tipo di politica). Non dipendono dalla connettivit\u00e0 del data-plane tra i router, poich\u00e9 utilizzano tutti i percorsi disponibili per il trasferimento del traffico tra il controller e il router.\n Per diversi segmenti di rete \u00e8 possibile creare politiche flessibili \u2013 l'ambito di applicazione della politica \u00e8 determinato da molteplici identificatori unici previsti nella soluzione \u2013 numero della filiale, tipo di applicazione, direzione del traffico, ecc.\n<\/li>\n<\/ul>\n
Piano di orchestrazione<\/b> \u2013 meccanismi che consentono ai componenti di scoprire dinamicamente l'uno l'altro, configurarsi e coordinare le interazioni successive.<\/p>\n\nin DMVPN\/PfR<\/b> La scoperta reciproca tra i router si basa sulla configurazione statica dei dispositivi Hub e sulla corrispondente configurazione dei dispositivi Spoke. La scoperta dinamica avviene solo per Spoke, che comunica i propri parametri di connessione al dispositivo Hub, che a sua volta \u00e8 stato precedentemente inserito nella configurazione dello Spoke. Senza connettivit\u00e0 IP dello Spoke con almeno un Hub, non \u00e8 possibile formare n\u00e9 il data-plane n\u00e9 il control-plane.<\/b><\/li>\nin SD-WAN<\/b> L'orchestrazione dei componenti della soluzione avviene utilizzando il controller vBond, con il quale ciascun componente (router e controller vManage\/vSmart) deve prima stabilire la connettivit\u00e0 IP.\n Inizialmente, i componenti non sono a conoscenza dei parametri di connessione reciproci \u2013 a tal fine hanno bisogno di un intermediario orchestratore vBond. Il principio generale \u00e8 il seguente: ogni componente nella fase iniziale apprende (automaticamente o staticamente) solo i parametri di connessione al vBond, quindi vBond informa il router sui controller vManage e vSmart (precedentemente scoperti), il che consente di stabilire automaticamente tutte le connessioni di segnalazione necessarie. <\/p>\n
Il passaggio successivo riguarda il nuovo router che apprende sugli altri router della rete attraverso lo scambio OMP con il controller vSmart. In questo modo, il router, pur non conoscendo inizialmente i parametri di rete, \u00e8 in grado di rilevare e connettersi completamente in modo automatico ai controller e, successivamente, di scoprire e formare automaticamente la connettivit\u00e0 con gli altri router. I parametri di connessione di tutti i componenti sono inizialmente sconosciuti e possono variare durante il processo di utilizzo.\n<\/li>\n<\/ul>\n
Management-plane<\/b> \u2013 parte della soluzione che garantisce gestione centralizzata e monitoraggio.<\/p>\n\nDMVPN\/PfR<\/b> \u2013 non \u00e8 prevista una soluzione management-plane specializzata. Per l'automazione e il monitoraggio di base, \u00e8 possibile utilizzare prodotti come Cisco Prime Infrastructure. Ogni router ha la possibilit\u00e0 di gestione tramite interfaccia a riga di comando (CLI). Non \u00e8 prevista integrazione con sistemi esterni tramite API.<\/b><\/li>\nSD-WAN<\/b> \u2013 tutte le interazioni e il monitoraggio vengono gestiti centralmente tramite l'interfaccia grafica del controller vManage. Tutte le funzionalit\u00e0 della soluzione, senza eccezioni, sono disponibili per la configurazione tramite vManage, nonch\u00e9 tramite un'API REST completamente documentata.\n Tutte le impostazioni della rete SD-WAN in vManage si concentrano su due principali costrutti: la creazione di template per dispositivi (Device Template) e la creazione di politiche che definiscono la logica operativa della rete e la gestione del traffico. A tal fine, vManage, trasmettendo la politica creata dall'amministratore, seleziona automaticamente quali cambiamenti e su quali dispositivi\/controller individuali devono essere effettuati, aumentando notevolmente l'efficacia e la scalabilit\u00e0 della soluzione.<\/p>\n
Attraverso l'interfaccia vManage \u00e8 disponibile non solo la configurazione della soluzione Cisco SD-WAN, ma anche un monitoraggio completo dello stato di tutti i componenti della soluzione, fino allo stato attuale delle metriche dei singoli tunnel e alle statistiche di utilizzo delle diverse applicazioni basate sull'analisi DPI.<\/p>\n
Nonostante la centralizzazione dell'interazione, tutti i componenti (controller e router) dispongono di una riga di comando CLI completamente funzionale, necessaria nella fase di implementazione o in caso di situazioni di emergenza per la diagnostica locale. In modalit\u00e0 operativa (con un canale di segnale disponibile tra i componenti), la riga di comando \u00e8 accessibile solo per diagnosi e non \u00e8 disponibile per apportare modifiche locali, garantendo cos\u00ec sia la sicurezza locale che una fonte unica di modifiche in tale rete: vManage.<\/li>\n<\/ul>\n
\nSicurezza integrata<\/b> \u2013 qui si parla non solo di protezione dei dati degli utenti durante il trasferimento su canali aperti, ma anche della sicurezza generale della rete WAN basata sulla tecnologia scelta.<\/p>\n\nin DMVPN\/PfR<\/b> \u00e8 prevista la possibilit\u00e0 di crittografia dei dati degli utenti e dei protocolli di segnale. Utilizzando determinati modelli di router, sono inoltre disponibili funzioni di firewall con ispezione del traffico, IPS\/IDS. C'\u00e8 la possibilit\u00e0 di segmentazione delle reti filiali utilizzando VRF. \u00c8 possibile l'autenticazione (monofattoriale) dei protocolli di controllo.\n In questo caso, il router remoto \u00e8 considerato un elemento fidato della rete per impostazione predefinita \u2013 cio\u00e8 non si presuppongono e non si considerano situazioni di compromissione fisica di singoli dispositivi e la possibilit\u00e0 di accesso non autorizzato a questi, non esiste autenticazione a due fattori per i componenti della soluzione, il che in caso di rete geograficamente distribuita pu\u00f2 comportare rischi aggiuntivi significativi.<\/b> <\/li>\nin SD-WAN<\/b> Analogamente a DMVPN, \u00e8 prevista la crittografia dei dati degli utenti, ma con funzioni di sicurezza di rete e segmentazione L3\/VRF significativamente ampliate (MSE, IPS\/IDS, filtrazione URL, filtrazione DNS, AMP\/TG, SASE, proxy TLS\/SSL, ecc.). In questo caso, lo scambio delle chiavi di crittografia avviene in modo pi\u00f9 efficiente tramite controller vSmart (e non direttamente), attraverso canali di segnale predefiniti, protetti da crittografia DTLS\/TLS basata su certificati di sicurezza. Questo garantisce a sua volta la sicurezza di tale scambio e assicura una migliore scalabilit\u00e0 della soluzione fino a decine di migliaia di dispositivi in una rete.\n Tutte le connessioni del segnale (controllore-controllore, controllore-router) sono anch'esse protette sulla base di DTLS\/TLS. I router vengono forniti di certificati di sicurezza al momento della produzione e possono essere sostituiti\/rinnovati. L'autenticazione a due fattori \u00e8 raggiunta attraverso l'esecuzione obbligatoria e simultanea di due condizioni per il funzionamento del router\/controllore nella rete SD-WAN:<\/p>\n
\nCertificato di sicurezza valido<\/li>\n Inserimento esplicito e consapevole da parte dell'amministratore di ciascun componente nella lista 'bianca' dei dispositivi autorizzati.<\/li>\n<\/ul>\n\n<\/li>\n<\/ul>\n
Differenze funzionali tra SD-WAN e DMVPN\/PfR<\/h2>\n \nPassando a discutere le differenze funzionali, \u00e8 importante notare che molte di esse sono una continuazione delle differenze architettoniche; non \u00e8 un segreto che nella formazione dell'architettura della soluzione, gli sviluppatori si basino sulle possibilit\u00e0 che vogliono ottenere alla fine. Esaminiamo le differenze pi\u00f9 significative tra le due tecnologie.<\/p>\n
AppQ (Qualit\u00e0 dell'Applicazione) \u2013 funzioni che garantiscono la qualit\u00e0 del traffico per le applicazioni aziendali<\/h3>\n \nLe funzioni chiave delle tecnologie trattate mirano a migliorare l'esperienza dell'utente, per quanto possibile, durante l'utilizzo di applicazioni critiche per il business in una rete distribuita. Questo \u00e8 particolarmente importante in situazioni in cui parte dell'infrastruttura non \u00e8 controllata dall'IT o non garantisce neanche il successo nella trasmissione dei dati.<\/p>\n
DMVPN non fornisce tali meccanismi autonomamente. Il meglio che si pu\u00f2 fare in una rete DMVPN classica \u00e8 classificare il traffico in uscita per applicazioni e dare priorit\u00e0 durante la trasmissione verso il canale WAN. La scelta del tunnel DMVPN \u00e8 in questo caso determinata solo dalla sua disponibilit\u00e0 e dai risultati ottenuti dai protocolli di instradamento. Non viene quindi considerato lo stato end-to-end del percorso\/tunnel e la sua possibile parziale degradazione rispetto a metriche chiave rilevanti per le applicazioni di rete \u2013 latenza, variazione della latenza (jitter) e perdite (%). Di conseguenza, confrontare direttamente il DMVPN classico con l'SD-WAN in termini di risoluzione delle problematiche AppQ perde di significato: il DMVPN non pu\u00f2 risolvere questa questione. Con l'aggiunta della tecnologia Cisco Performance Routing (PfR) in questo contesto, la situazione cambia e il confronto con Cisco SD-WAN diventa pi\u00f9 sensato. <\/p>\n
Prima di passare alla discussione delle differenze, ecco brevemente in cosa le tecnologie sono simili. Quindi, entrambe le tecnologie:<\/p>\n
\ndispongono di un meccanismo che consente di valutare dinamicamente lo stato di ciascun tunnel installato in base a determinate metriche \u2013 almeno, ritardo, variazione del ritardo e perdita di pacchetti (%)<\/li>\n utilizzano un insieme specifico di strumenti per la formazione, diffusione e applicazione delle regole (politiche) di gestione del traffico, tenendo conto del risultato della misurazione dello stato delle metriche chiave dei tunnel.<\/li>\n classificano il traffico delle applicazioni ai livelli L3-L4 (DSCP) del modello OSI o sulle firme L7 delle applicazioni, basandosi sui meccanismi DPI integrati nel router<\/li>\n consentono di definire valori soglia accettabili delle metriche per applicazioni significative, le regole di trasmissione del traffico predefinite, le regole di rimappatura del traffico in caso di superamento dei valori soglia.<\/li>\n nella incapsulazione del traffico in GRE\/IPSec utilizzano un meccanismo ampiamente consolidato nell'industria per il trasferimento dell'etichettatura DSCP interna nel pacchetto GRE\/IPSec esterno, il che consente di sincronizzare le politiche QoS tra l'organizzazione e l'operatore di telecomunicazioni (se \u00e8 presente il relativo SLA).<\/li>\n<\/ul>\n\n
Quali sono le differenze nei meccanismi di valutazione delle metriche end-to-end tra SD-WAN e DMVPN\/PfR?<\/h3>\n \nDMVPN\/PfR <\/b><\/p>\n\nPer misurare le metriche standard dello stato del tunnel si utilizzano sensori software (Probes) sia attivi che passivi. Gli attivi si basano sul traffico degli utenti, i passivi simulano tale traffico (in assenza di esso). <\/li>\n La regolazione fine dei timer e delle condizioni di rilevamento della degradazione \u00e8 assente \u2013 l'algoritmo \u00e8 fisso.<\/li>\n \u00c8 disponibile anche la misurazione della larghezza di banda utilizzata nella direzione uscente. Questo conferisce a DMVPN\/PfR ulteriore flessibilit\u00e0 nella gestione del traffico.<\/li>\n Alcuni meccanismi di PfR, in caso di superamento delle metriche, si basano su feedback di segnalazione inversa tramite messaggi speciali TCA (Threshold Crossing Alert), che devono provenire dal destinatario del traffico verso la sorgente, il che implica che le condizioni dei canali misurati devono essere almeno sufficienti per inviare tali messaggi TCA. Questo, nella maggior parte dei casi, non rappresenta un problema, ma chiaramente non pu\u00f2 essere garantito. <\/li>\n<\/ul>\n\nSD-WAN <\/b><\/p>\n\nPer la valutazione continua delle metriche standard dello stato del tunnel viene utilizzato il protocollo BFD in modalit\u00e0 echo. In questo caso, non \u00e8 necessaria alcuna retroazione speciale come TCA o messaggi simili: si rispetta l'isolamento dei domini di guasto. Non \u00e8 richiesto nemmeno il traffico degli utenti per valutare lo stato del tunnel.<\/li>\n C'\u00e8 la possibilit\u00e0 di una fine regolazione dei timer BFD per controllare la velocit\u00e0 di attivazione e la sensibilit\u00e0 dell'algoritmo rispetto alle degradazioni del canale di comunicazione, da pochi secondi a minuti.\n
Al momento della stesura dell'articolo, in ciascun tunnel \u00e8 prevista solo una sessione BFD. Potenzialmente, questo crea una granularit\u00e0 ridotta nell'analisi dello stato del tunnel. In realt\u00e0, ci\u00f2 pu\u00f2 diventare una limitazione solo in caso di utilizzo di una connessione WAN basata su MPLS L2\/L3 VPN con SLA QoS concordato: se la marcatura DSCP del traffico BFD (dopo l'incapsulamento in IPSec\/GRE) coincide con la coda ad alta priorit\u00e0 nella rete dell'operatore di telecomunicazioni, ci\u00f2 potrebbe influenzare la precisione e la velocit\u00e0 di rilevamento delle degradazioni per il traffico a bassa priorit\u00e0. In questo caso, \u00e8 possibile modificare la marcatura BFD predefinita per ridurre il rischio di situazioni simili. Nelle prossime versioni del software Cisco SD-WAN \u00e8 prevista l'introduzione di regolazioni pi\u00f9 dettagliate per il BFD, cos\u00ec come la possibilit\u00e0 di avviare pi\u00f9 sessioni BFD all'interno di un singolo tunnel con valori DSCP individuali (per diverse applicazioni).<\/li>\n Il BFD consente inoltre di valutare la massima dimensione del pacchetto che pu\u00f2 essere trasmessa attraverso un determinato tunnel senza frammentazione. Questo consente a SD-WAN di configurare dinamicamente parametri come MTU e TCP MSS Adjust, per utilizzare in modo ottimale la larghezza di banda disponibile su ciascun canale.<\/li>\n In SD-WAN \u00e8 disponibile anche l'opzione di sincronizzazione della QoS con gli operatori di telecomunicazioni non solo sulla base del campo L3 DSCP, ma anche sulla base dei valori L2 CoS, che possono essere automaticamente generati nella rete filiale da dispositivi specializzati, come i telefoni IP.<\/li>\n<\/ul>\n<\/p>\n
Quali sono le differenze nelle capacit\u00e0, nei metodi di determinazione e nell'applicazione delle politiche AppQ?<\/h3>\n <\/p>\n
Politiche DMVPN\/PfR:<\/h4>\n <\/p>\n
\nSono definite sui router del filiale centrale (CF) tramite la riga di comando CLI o tramite modelli di configurazione CLI. La creazione di modelli CLI richiede preparazione e conoscenza della sintassi delle politiche.\n
Definiti globalmente senza possibilit\u00e0 di personalizzazione\/modifica in base alle esigenze dei singoli segmenti della rete.<\/b><\/li>\nNon \u00e8 previsto un formato interattivo delle politiche nell'interfaccia grafica.<\/li>\n Non \u00e8 previsto il tracciamento delle modifiche, l'eredit\u00e0 o la creazione di pi\u00f9 versioni delle politiche per un rapido switching.<\/li>\n Vengono automaticamente distribuite ai router delle filiali remote, utilizzando gli stessi canali di comunicazione impiegati per il trasferimento dei dati degli utenti. In assenza di un canale di comunicazione tra la centrale e la filiale remota, la distribuzione\/modifica delle politiche non \u00e8 possibile.<\/li>\n Si applicano a ciascun router e, se necessario, modificano il risultato dei protocolli di routing standard, avendo una priorit\u00e0 pi\u00f9 elevata. <\/li>\n Per i casi in cui tutti i canali WAN della filiale subiscono perdite significative di traffico, non sono previsti meccanismi di compensazione<\/b>.<\/li>\n<\/ul>\n <\/p>\n
Politiche SD-WAN:<\/h4>\n <\/p>\n
\nDefinite nell'interfaccia grafica di vManage tramite un wizard interattivo di template.<\/li>\n Supportano la creazione di pi\u00f9 politiche, la copia, l'eredit\u00e0 e il switching tra politiche in tempo reale.<\/li>\n Supportano la personalizzazione delle politiche per diversi segmenti (filiali) della rete.<\/li>\n Vengono distribuite utilizzando qualsiasi canale di segnale disponibile tra il controller e il router e\/o vSmart \u2013 non dipendono direttamente dalla connettivit\u00e0 del data-plane tra i router. \u00c8 comunque necessaria la connettivit\u00e0 IP tra il router stesso e i controller.\n
Per i casi in cui tutti i canali disponibili della filiale subiscono perdite significative di dati, superiori ai limiti tollerabili per le applicazioni critiche, \u00e8 possibile utilizzare meccanismi aggiuntivi che aumentano l'affidabilit\u00e0 della trasmissione:\n\nFEC (Forward Error Correction)<\/b> \u2013 utilizza un algoritmo speciale di codifica ridondante. Durante il trasferimento di traffico critico su canali con un'alta percentuale di perdite, FEC pu\u00f2 essere attivato automaticamente e consente, se necessario, di recuperare la parte di dati persa. Questo comporta un leggero aumento della larghezza di banda utilizzata, ma un significativo aumento dell'affidabilit\u00e0.\n
Duplicazione dei flussi di dati<\/b> \u2013 oltre alla FEC, la politica pu\u00f2 prevedere la duplicazione automatica del traffico delle applicazioni selezionate in caso di perdite ancora pi\u00f9 gravi che non possono essere compensate tramite FEC. In questo caso, i dati selezionati verranno trasmessi attraverso tutti i tunnel verso la filiale ricevente con successiva deduplicazione (scartando le copie extra dei pacchetti). Questo meccanismo aumenta notevolmente l'utilizzo dei canali, ma aumenta anche significativamente l'affidabilit\u00e0 della trasmissione.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n <\/p>\n
Le funzionalit\u00e0 di Cisco SD-WAN, senza veri analoghi in DMVPN\/PfR<\/h3>\n \nL'architettura della soluzione Cisco SD-WAN permette in alcuni casi di ottenere funzionalit\u00e0 la cui implementazione nel contesto di DMVPN\/PfR \u00e8 estremamente complessa, impraticabile a causa delle necessarie spese operative oppure del tutto impossibile. Analizziamo le pi\u00f9 interessanti tra queste:<\/p>\n
Traffic-Engineering (TE)<\/h4>\n \nTE include meccanismi che consentono di deviare il traffico dal percorso standard stabilito dai protocolli di instradamento. TE \u00e8 spesso utilizzato per garantire un'alta disponibilit\u00e0 dei servizi di rete, grazie alla capacit\u00e0 di spostare rapidamente e\/o previamente il traffico importante su un percorso alternativo (non sovrapposto), al fine di garantire una migliore qualit\u00e0 del servizio o una maggiore velocit\u00e0 di recupero in caso di guasto del percorso principale. <\/p>\n
La complessit\u00e0 dell'implementazione del TE risiede nella necessit\u00e0 di calcolare e riservare in anticipo (verificare) un percorso alternativo. Nelle reti MPLS degli operatori di telecomunicazione, questo compito viene svolto utilizzando tecnologie come il MPLS Traffic Engineering con estensioni dei protocolli IGP e del protocollo RSVP. Inoltre, ultimamente sta guadagnando popolarit\u00e0 la tecnologia Segment Routing, che \u00e8 pi\u00f9 ottimizzata per la configurazione e l'orchestrazione centralizzate. Nelle reti WAN classiche, queste tecnologie non sono generalmente disponibili o sono ridotte all'uso di meccanismi hop-by-hop come il Policy-Based Routing (PBR), che \u00e8 in grado di deviare il traffico, ma lo fa su ciascun router separatamente, senza considerare lo stato complessivo della rete o il risultato del PBR nei passaggi precedenti o successivi. Il risultato dell'applicazione di queste opzioni di TE \u00e8 deludente: il MPLS TE, a causa della complessit\u00e0 di configurazione e gestione, viene generalmente utilizzato solo nella parte pi\u00f9 critica della rete (il nucleo), mentre il PBR viene utilizzato su singoli router senza la possibilit\u00e0 di formare una politica PBR unitaria su tutta la rete. Questo \u00e8 chiaramente applicabile anche alle reti basate su DMVPN.<\/p>\n
Service-chaining (Sviluppo di servizi) <\/h4>\n \nLa formazione di catene di servizi \u00e8 un compito ancora pi\u00f9 laborioso nella classica instradazione rispetto al gi\u00e0 descritto meccanismo di Traffic Engineering. Infatti, in questo caso, \u00e8 necessario non solo creare un percorso speciale per una determinata applicazione di rete, ma anche garantire la possibilit\u00e0 di instradare il traffico dalla rete verso nodi specifici (o verso tutti) della rete SD-WAN per l'elaborazione da parte di un'applicazione o servizio specializzato (MPLS, Bilanciamento, Cache, Ispezione del traffico, ecc.). Inoltre, \u00e8 necessario avere la possibilit\u00e0 di controllare lo stato di questi servizi esterni per evitare situazioni di black-holing, oltre a meccanismi che consentono di distribuire servizi esterni omogenei in diverse geo-localizzazioni, con la possibilit\u00e0 che la rete scelga automaticamente il nodo di servizio pi\u00f9 ottimale per elaborare il traffico di una filiale specifica. Nel caso di Cisco SD-WAN, \u00e8 piuttosto facile raggiungere questo obiettivo creando una politica centralizzata appropriata che<\/p>\n
Qual \u00e8 il risultato finale?<\/h2>\n \n\u00c8 evidente che sia DMVPN (insieme o senza Performance Routing) che Cisco SD-WAN affrontano in fin dei conti compiti molto simili<\/b> rispetto alla rete WAN distribuita dell'organizzazione. In questo caso, le sostanziali differenze architettoniche e funzionali della tecnologia Cisco SD-WAN elevano il processo di risoluzione di questi compiti a un altro livello qualitativo<\/b>. Riassumendo, si possono notare le seguenti differenze significative tra le tecnologie SD-WAN e DMVPN\/PfR:<\/p>\n\nDMVPN\/PfR utilizzano in generale tecnologie collaudate nel tempo per costruire reti VPN sovrapposte e, per quanto riguarda data-plane, sono simili alla pi\u00f9 moderna tecnologia SD-WAN; tuttavia, ci sono alcune limitazioni come la necessaria configurazione statica dei router e la scelta delle topologie \u00e8 limitata a Hub-n-Spoke. D'altra parte, DMVPN\/PfR ha alcune funzionalit\u00e0 che al momento non sono disponibili nel contesto di SD-WAN (riferito a BFD per applicazione).<\/li>\n Nell'ambito della tecnologia control-plane, ci sono differenze sostanziali. Considerando l'elaborazione centralizzata dei protocolli di segnalazione, SD-WAN consente, in particolare, di ridurre significativamente i domini di guasto e di \"slegare\" il processo di trasferimento del traffico degli utenti dall'interazione di segnalazione: la temporanea indisponibilit\u00e0 dei controller non influisce sulla possibilit\u00e0 di trasferire il traffico degli utenti. Allo stesso tempo, la temporanea indisponibilit\u00e0 di una filiale (inclusa quella centrale) non influisce sulla capacit\u00e0 delle altre filiali di interagire tra loro e con i controller.<\/li>\n L'architettura per la formazione e l'applicazione delle politiche di gestione del traffico nel caso di SD-WAN supera anche quella di DMVPN\/PfR: il geo-riserva \u00e8 realizzato in modo significativamente migliore, non c'\u00e8 vincolo a Hub, ci sono maggiori possibilit\u00e0 di fine tuning delle politiche e l'elenco degli scenari di gestione del traffico realizzabili \u00e8 notevolmente pi\u00f9 ampio.<\/li>\n Il processo di orchestrazione della soluzione differisce anche in modo significativo. DMVPN presuppone la presenza di parametri precedentemente noti che devono essere in qualche modo riflessi nella configurazione, il che limita un po' la flessibilit\u00e0 della soluzione e la possibilit\u00e0 di modifiche dinamiche. Al contrario, SD-WAN parte dal paradigma che all'inizio della connessione il router \"non sa nulla\" sui propri controller, ma sa \"da chi chiedere\"; questo \u00e8 sufficiente non solo per stabilire automaticamente la connessione con i controller, ma anche per formare automaticamente una topologia data-plane completamente connessa, che pu\u00f2 poi essere configurata\/modificata in modo flessibile tramite politiche.<\/li>\n Nel campo della gestione centralizzata, dell'automazione e del monitoraggio, SD-WAN supera chiaramente le capacit\u00e0 di DMVPN\/PfR, che sono il risultato dell'evoluzione delle tecnologie classiche e si basano maggiormente sulla riga di comando CLI e sull'uso di sistemi NMS basati su modelli. <\/li>\n Nel SD-WAN rispetto a DMVPN, i requisiti di sicurezza hanno raggiunto un altro livello qualitativo. I principi chiave sono: zero fiducia, scalabilit\u00e0 e autenticazione a due fattori.<\/li>\n<\/ul>\n\nDa queste conclusioni semplici pu\u00f2 nascere l'impressione errata che la creazione di una rete basata su DMVPN\/PfR abbia perso oggi ogni rilevanza. Questo non \u00e8 del tutto vero. Ad esempio, nei casi in cui la rete utilizza molte apparecchiature obsolete e non \u00e8 possibile sostituirle, DMVPN pu\u00f2 consentire di collegare dispositivi 'vecchi' e 'nuovi' in una rete geo-distribuita unica con un gran numero di vantaggi sopra descritti.<\/p>\n
D'altra parte, \u00e8 importante ricordare che tutti i router aziendali Cisco attualmente attuali basati su IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) supportano oggi qualsiasi modalit\u00e0 operativa \u2013 sia la classica instradamento che DMVPN e SD-WAN \u2013 la scelta \u00e8 determinata dalle esigenze attuali e dalla comprensione che in qualsiasi momento \u00e8 possibile iniziare a muoversi verso una tecnologia pi\u00f9 avanzata utilizzando lo stesso hardware.<\/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