Funzionalit\u00e0 \u2013 cosa pu\u00f2 fare una tecnologia che l'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 \nOgni tecnologia menzionata presenta numerose 'parti in movimento', le cui funzioni e i principi di interazione differiscono. La scalabilit\u00e0, la resilienza e l'efficienza complessiva della soluzione dipendono direttamente da quanto siano ben progettati questi principi e dalla meccanica generale. <\/p>\n
Esaminiamo pi\u00f9 da vicino diversi aspetti dell'architettura:<\/p>\n
Data-plane<\/b> \u2013 la parte della soluzione responsabile della trasmissione del traffico degli utenti tra fonte e destinatario. In DMVPN e SD-WAN \u00e8 implementata in modo sostanzialmente identico sui router basati su tunnel GRE Multipoint. La differenza sta nel modo in cui vengono formati i parametri necessari per questi tunnel:<\/p>\n\nin DMVPN\/PfR<\/b> \u2013 \u00e8 un'architettura a due livelli di nodi con topologia \"Stella\" o Hub-n-Spoke. \u00c8 necessaria una configurazione statica dell'Hub e un'associazione statica dello Spoke all'Hub, cos\u00ec come l'interazione tramite il protocollo NHRP per la formazione della connettivit\u00e0 del data-plane. Di conseguenza, sono notevolmente complicate le modifiche all'Hub<\/b>, legate, ad esempio, alla modifica\/collegamento di nuovi canali WAN o alla modifica dei parametri esistenti.<\/li>\nin SD-WAN<\/b> \u2013 \u00e8 un modello completamente dinamico per la scoperta dei parametri dei tunnel stabiliti, basato sul control-plane (protocollo OMP) e sull'orchestration-plane (interazione con il controller vBond per compiti di scoperta dei controller e NAT traversal). In questo caso, possono essere applicate topologie qualsiasi, comprese quelle gerarchiche. All'interno della topologia di tunnel stabilita, \u00e8 possibile una configurazione flessibile della topologia logica in ogni singolo VPN (VRF).<\/li>\n<\/ul>\n Control-plane<\/b> \u2013 funzioni di scambio, filtraggio e modifica delle informazioni di routing e altre informazioni 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 funzionante, il funzionamento del control-plane e del data-plane \u00e8 impossibile<\/b>, il che impone all'Hub ulteriori requisiti di alta disponibilit\u00e0 che non sempre possono essere soddisfatti.<\/li>\nin SD-WAN<\/b> \u2013 il control-plane non viene mai gestito direttamente tra i router, l'interazione avviene tramite il protocollo OMP ed \u00e8 obbligatoriamente realizzata attraverso un tipo di controller vSmart specializzato, il che consente il bilanciamento, la geo-ridondanza e la gestione centralizzata del segnale. Un'altra caratteristica del protocollo OMP \u00e8 la sua notevole resilienza alle perdite e l'indipendenza dalla velocit\u00e0 della connessione con i controller (entro limiti ragionevoli, ovviamente). Questo consente efficacemente di ospitare i controller SD-WAN in cloud pubblici o privati con accesso tramite Internet.<\/li>\n<\/ul>\n Policy-plane<\/b> \u2013 la parte della soluzione responsabile della definizione, diffusione 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), configurabili individualmente su ciascun router tramite CLI o modelli di Prime Infrastructure.<\/li>\nDMVPN\/PfR<\/b> \u2013 le politiche PfR vengono formulate su un router centralizzato Master Controller (MC) tramite CLI e successivamente distribuite automaticamente ai MC filiali. Si utilizzano gli stessi percorsi di trasmissione delle politiche previsti per il data-plane. Non \u00e8 possibile separare lo scambio delle politiche, delle informazioni di routing e dei dati degli utenti. La distribuzione delle politiche richiede necessariamente la connessione IP tra il Hub e il Spoke. Inoltre, la funzionalit\u00e0 MC pu\u00f2 essere combinata, se necessario, con un router DMVPN. \u00c8 possibile (ma non obbligatorio) utilizzare modelli Prime Infrastructure per la formazione centralizzata delle politiche. Una caratteristica importante \u00e8 che la politica viene formulata 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 direttamente o indirettamente attraverso i controller vSmart (a seconda del tipo di politica). Non dipendono dalla connettivit\u00e0 della data-plane tra i router, in quanto 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 definito da un insieme di identificatori unici previsti nella soluzione, come il numero della filiale, il tipo di applicazione, la direzione del traffico, ecc.\n<\/li>\n<\/ul>\n
Orchestration-plane<\/b> \u2013 meccanismi che consentono ai componenti di scoprirsi dinamicamente, configurarsi e coordinare le interazioni successive.<\/p>\n\nin DMVPN\/PfR<\/b> La scoperta reciproca dei router si basa sulla configurazione statica dei dispositivi Hub e sulla corretta impostazione dei dispositivi Spoke. La scoperta dinamica avviene solo per lo Spoke che comunica i propri parametri di connessione all'Hub, che \u00e8 stato precedentemente inserito nella configurazione dello Spoke. Senza connettivit\u00e0 IP tra lo Spoke e 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 attraverso un controller vBond, con il quale ogni componente (router e controller vManage\/vSmart) deve stabilire preventivamente la connettivit\u00e0 IP.\n Inizialmente, i componenti non conoscono i parametri di connessione tra loro; per questo, hanno bisogno di un intermediario-orchestratore vBond. Il principio generale \u00e8 il seguente: ogni componente, nella fase iniziale, scopre (automaticamente o staticamente) solo i parametri di connessione al vBond, e successivamente il vBond informa il router sui controller vManage e vSmart (scoperti in precedenza), rendendo possibile l'instaurazione automatica di tutte le necessarie connessioni di segnalazione. <\/p>\n
Il passaggio successivo prevede che il nuovo router apprenda degli altri router nella rete tramite lo scambio OMP con il controller vSmart. In questo modo, il router, pur non conoscendo inizialmente i parametri della rete, \u00e8 in grado di rilevare e connettersi automaticamente ai controller e successivamente rilevare e stabilire la connettivit\u00e0 con gli altri router. I parametri di connessione di tutti i componenti sono inizialmente sconosciuti e possono cambiare nel corso dell'operativit\u00e0.\n<\/li>\n<\/ul>\n
Management-plane<\/b> \u2013 parte della soluzione che offre gestione e monitoraggio centralizzati.<\/p>\n\nDMVPN\/PfR<\/b> \u2013 non \u00e8 previsto un soluzione management-plane specializzata. Per l'automazione di base e il monitoraggio, \u00e8 possibile utilizzare prodotti come Cisco Prime Infrastructure. Ogni router ha la possibilit\u00e0 di essere gestito tramite la riga di comando CLI. Non \u00e8 prevista integrazione con sistemi esterni tramite API.<\/b><\/li>\nSD-WAN<\/b> \u2013 tutta l'interazione e il monitoraggio avvengono centralmente tramite l'interfaccia grafica del controller vManage. Tutte le funzionalit\u00e0 della soluzione, senza eccezione, sono configurabili tramite vManage, oltre a una libreria dell'interfaccia di programmazione REST API completamente documentata.\n Tutte le impostazioni della rete SD-WAN in vManage si riducono a due costrutti principali: la creazione di modelli di dispositivo (Device Template) e la creazione di politiche che definiscono la logica operativa della rete e la gestione del traffico. In questo modo, vManage, trasmettendo la politica definita dall'amministratore, seleziona automaticamente quali modifiche apportare e su quali dispositivi\/controller individuali, aumentando notevolmente l'efficienza e la scalabilit\u00e0 della soluzione.<\/p>\n
Attraverso l'interfaccia di vManage \u00e8 possibile non solo configurare la soluzione Cisco SD-WAN, ma anche monitorare completamente lo 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 su analisi DPI.<\/p>\n
Nonostante la centralizzazione delle interazioni, tutti i componenti (controller e router) dispongono anche di un'interfaccia a riga di comando CLI full-featured, necessaria durante la fase di implementazione o in caso di situazioni anomale per la diagnosi locale. In modalit\u00e0 normale (in presenza di un canale di segnalazione tra i componenti) la riga di comando \u00e8 accessibile solo per la diagnosi e non per apportare modifiche locali, garantendo cos\u00ec sia la sicurezza locale che una fonte unica di modifiche in una rete di questo tipo \u2013 vManage.<\/li>\n<\/ul>\n
\nSicurezza integrata<\/b> \u2013 qui si fa riferimento non solo alla protezione dei dati degli utenti durante la trasmissione su canali aperti, ma anche alla sicurezza complessiva della rete WAN basata sulla tecnologia scelta.<\/p>\n\nin DMVPN\/PfR<\/b> \u00c8 prevista la possibilit\u00e0 di crittografare i dati degli utenti e i protocolli di segnalazione. Utilizzando determinati modelli di router, sono disponibili anche funzionalit\u00e0 di firewall con ispezione del traffico, IPS\/IDS. \u00c8 possibile segmentare le reti filiali utilizzando VRF. \u00c8 prevista l'autenticazione (singolo fattore) dei protocolli di controllo.\n In questo caso, il router remoto \u00e8 considerato un elemento di fiducia della rete per default, cio\u00e8 non si ipotizzano e non si considerano casi di compromissione fisica di singoli dispositivi e la possibilit\u00e0 di accesso non autorizzato a essi; non c'\u00e8 autenticazione a due fattori per i componenti della soluzione, il che, in una rete geograficamente distribuita, pu\u00f2 comportare seri rischi aggiuntivi.<\/b> <\/li>\nin SD-WAN<\/b> Simile a DMVPN, \u00e8 disponibile la possibilit\u00e0 di crittografare i dati degli utenti, ma con funzionalit\u00e0 di sicurezza di rete e segmentazione L3\/VRF notevolmente ampliate (MPLS, IPS\/IDS, filtraggio URL, filtraggio DNS, AMP\/TG, SASE, proxy TLS\/SSL, ecc.). In questo caso, lo scambio delle chiavi di crittografia avviene in modo pi\u00f9 efficiente attraverso i controller vSmart (anzich\u00e9 direttamente), tramite canali di segnalazione predefiniti, protetti dalla crittografia DTLS\/TLS basata su certificati di sicurezza. Ci\u00f2 garantisce la sicurezza di tale scambio e garantisce una migliore scalabilit\u00e0 della soluzione fino a decine di migliaia di dispositivi in una rete.\n Tutte le connessioni di segnalazione (controller-controller, controller-router) sono anch'esse protette sulla base di DTLS\/TLS. I router sono dotati di certificati di sicurezza durante la produzione con la possibilit\u00e0 di sostituzione\/rinnovo. L'autenticazione a due fattori viene raggiunta tramite l'obbligo e l'esecuzione simultanea di due condizioni affinch\u00e9 il router\/controller possa funzionare nella rete SD-WAN:<\/p>\n
\nCertificato di sicurezza valido<\/li>\n Aggiunta esplicita 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 delle differenze funzionali, \u00e8 importante notare che molte di esse sono un'estensione delle considerazioni architettoniche: non \u00e8 un segreto che nella definizione dell'architettura della soluzione gli sviluppatori si basino sulle funzionalit\u00e0 che desiderano ottenere alla fine. Esaminiamo le differenze pi\u00f9 significative tra le due tecnologie.<\/p>\n
AppQ (Application Quality) \u2013 funzioni per garantire la qualit\u00e0 della trasmissione del traffico delle applicazioni aziendali<\/h3>\n \nLe funzionalit\u00e0 chiave delle tecnologie esaminate mirano a migliorare, per quanto possibile, l'esperienza utente nell'uso di applicazioni critiche per il business all'interno di una rete distribuita. Questo \u00e8 particolarmente importante in un contesto in cui parte dell'infrastruttura non \u00e8 sotto il controllo dell'IT o non garantisce nemmeno una trasmissione dati affidabile.<\/p>\n
DMVPN non offre tali meccanismi autonomamente. La miglior cosa che si possa fare in una rete DMVPN classica \u00e8 classificare il traffico in uscita per applicazioni e dargli priorit\u00e0 durante il trasferimento verso la WAN. La scelta del tunnel DMVPN, in questo caso, \u00e8 determinata solo dalla sua disponibilit\u00e0 e dal risultato dei protocolli di routing. Non viene considerato lo stato end-to-end del percorso\/tunnel n\u00e9 la sua possibile degradazione parziale rispetto a metriche chiave significative per le applicazioni di rete, come la latenza, la variazione della latenza (jitter) e le perdite (%). Pertanto, confrontare direttamente DMVPN classico con SD-WAN riguardo alla risoluzione delle problematiche di AppQ perde ogni senso: DMVPN non pu\u00f2 affrontare questa questione. L'introduzione della tecnologia Cisco Performance Routing (PfR) cambia la situazione, rendendo pi\u00f9 appropriato il confronto con Cisco SD-WAN. <\/p>\n
Prima di passare a discutere le differenze, una breve nota sulle somiglianze tra le tecnologie. Quindi, entrambe le tecnologie:<\/p>\n
\ndispongono di un meccanismo che consente di valutare dinamicamente lo stato di ciascun tunnel installato in base a metriche specifiche \u2013 almeno, ritardo, variazione del ritardo e perdita di pacchetti (%)<\/li>\n utilizzano un insieme specifico di strumenti per formare, distribuire e applicare regole (politiche) di gestione del traffico, tenendo conto dei risultati della misurazione delle metriche chiave dei tunnel.<\/li>\n classificano il traffico delle applicazioni ai livelli L3-L4 (DSCP) del modello OSI o secondo le firme L7 delle applicazioni, basandosi sui meccanismi DPI integrati nel router.<\/li>\n permettono di definire valori soglia accettabili per le metriche delle applicazioni significative, regole di trasmissione del traffico predefinite e regole di riinstradamento del traffico in caso di superamento dei valori soglia.<\/li>\n quando si incapsula il traffico in GRE\/IPSec, utilizzano un meccanismo consolidato nell'industria per trasferire i marcatori DSCP interni nell'intestazione esterna del pacchetto GRE\/IPSec, consentendo di sincronizzare le politiche QoS tra l'organizzazione e l'operatore di telecomunicazioni (in presenza di un SLA corrispondente).<\/li>\n<\/ul>\n\n
In che modo i meccanismi di valutazione delle metriche end-to-end SD-WAN differiscono da DMVPN\/PfR?<\/h3>\n \nDMVPN\/PfR <\/b><\/p>\n\nPer la valutazione delle metriche standard dello stato del tunnel vengono utilizzati sensori software sia attivi che passivi (Probes). Gli attivi si basano sul traffico utente, mentre i passivi emulano tale traffico (in assenza di questo). <\/li>\n La regolazione fine dei timer e delle condizioni di rilevamento della degradazione \u00e8 assente \u2013 l'algoritmo \u00e8 fisso.<\/li>\n In aggiunta, \u00e8 disponibile la misurazione della larghezza di banda utilizzata in direzione outbound. Questo aggiunge a DMVPN\/PfR una maggiore flessibilit\u00e0 nella gestione del traffico.<\/li>\n Alcuni meccanismi di PfR si basano invece su feedback di segnale inverso sotto forma di messaggi TCA (Threshold Crossing Alert) speciali, che devono provenire dal ricevente del traffico verso la sorgente, il che implica che gli stati dei canali misurati devono essere almeno sufficienti per trasmettere tali messaggi TCA. Questo nella maggior parte dei casi non \u00e8 un problema, ma 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 risposta speciale sotto forma di TCA o messaggi simili, mantenendo l'isolamento dei domini di guasto. Inoltre, non \u00e8 necessario il traffico utente per valutare lo stato del tunnel.<\/li>\n \u00c8 possibile effettuare una fine regolazione dei timer BFD per controllare la velocit\u00e0 di attivazione e la sensibilit\u00e0 dell'algoritmo rispetto ai degradi del canale di comunicazione, passando da alcuni secondi a diversi minuti.\n
Al momento della scrittura dell'articolo, in ciascun tunnel \u00e8 prevista solo una sessione BFD. Questo potenzialmente crea una minore granularit\u00e0 nell'analisi dello stato del tunnel. In realt\u00e0, questo pu\u00f2 diventare un vincolo 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) corrisponde a una coda ad alta priorit\u00e0 nella rete del fornitore di servizi, ci\u00f2 pu\u00f2 influenzare l'accuratezza e la velocit\u00e0 di rilevamento della degradazione del traffico a bassa priorit\u00e0. \u00c8 possibile modificare la marcatura BFD predefinita per ridurre il rischio di tali situazioni. Nelle prossime versioni del software Cisco SD-WAN \u00e8 prevista l'introduzione di configurazioni pi\u00f9 dettagliate per BFD, nonch\u00e9 la possibilit\u00e0 di avviare pi\u00f9 sessioni BFD all'interno di un singolo tunnel con valori DSCP individuali (per diverse applicazioni).<\/li>\n BFD consente inoltre di valutare la dimensione massima del pacchetto che pu\u00f2 essere trasmesso attraverso un determinato tunnel senza frammentazione. Questo permette a SD-WAN di configurare dinamicamente parametri come MTU e TCP MSS Adjust per utilizzare al meglio la larghezza di banda disponibile su ogni canale.<\/li>\n In SD-WAN \u00e8 anche disponibile un'opzione di sincronizzazione QoS con i fornitori di servizi non solo basata sul campo L3 DSCP, ma anche sui valori L2 CoS, che possono essere automaticamente generati nella rete di filiale da dispositivi specializzati, come i telefoni IP.<\/li>\n<\/ul>\n<\/p>\n
Quali sono le differenze nelle capacit\u00e0, nei metodi di definizione e applicazione delle politiche AppQ?<\/h3>\n <\/p>\n
Politiche DMVPN\/PfR:<\/h4>\n <\/p>\n
\nSono definite sul router(-i) della filiale centrale (CF) tramite la riga di comando CLI o modelli di configurazione CLI. La creazione di modelli CLI richiede preparazione e conoscenza della sintassi delle politiche.\n
Sono definite globalmente senza possibilit\u00e0 di personalizzazione\/modifica secondo le esigenze di singoli segmenti della rete.<\/b><\/li>\nLa creazione interattiva delle politiche nell'interfaccia grafica non \u00e8 prevista.<\/li>\n Il monitoraggio delle modifiche, l'eredit\u00e0 e la creazione di pi\u00f9 versioni delle politiche per un rapido passaggio non sono previsti.<\/li>\n Si propagano automaticamente ai router delle filiali remote. Vengono utilizzati gli stessi canali di comunicazione per la trasmissione dei dati degli utenti. In assenza di un canale di comunicazione tra la sede centrale e la filiale remota, la propagazione o la modifica delle politiche \u00e8 impossibile.<\/li>\n Vengono applicati a ciascun router e, se necessario, modificano il risultato dei protocolli di routing standard, avendo una priorit\u00e0 pi\u00f9 alta. <\/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
\nVengono definite nell'interfaccia grafica di vManage tramite un wizard interattivo per i modelli.<\/li>\n Supportano la creazione di pi\u00f9 politiche, la copia, l'eredit\u00e0 e il cambio tra politiche in tempo reale.<\/li>\n Supportano la personalizzazione delle politiche per diversi segmenti (filiali) della rete.<\/li>\n Si propagano 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. Tuttavia, \u00e8 necessaria la connettivit\u00e0 IP tra il router stesso e i controller.\n
Nei casi in cui tutti i canali disponibili della filiale subiscono perdite significative di dati, che superano i valori soglia accettabili per le applicazioni critiche, \u00e8 possibile utilizzare ulteriori meccanismi per aumentare l'affidabilit\u00e0 della trasmissione:\n\nFEC (Forward Error Correction)<\/b> \u2013 utilizza un algoritmo speciale di codifica ridondante. Durante la trasmissione di traffico critico su canali con una percentuale significativa di perdite, il FEC pu\u00f2 essere attivato automaticamente e consente, se necessario, di recuperare la parte di dati persa. Ci\u00f2 comporta un leggero aumento della banda utilizzata, ma aumenta notevolmente l'affidabilit\u00e0.\n
Duplicazione dei flussi di dati<\/b> \u2013 in aggiunta alla politica FEC, pu\u00f2 essere prevista 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 saranno trasmessi attraverso tutti i tunnel verso la filiale destinataria, con successiva deduplicazione (scartando copie superflue dei pacchetti). Questo meccanismo aumenta notevolmente l'uso dei canali, ma al contempo migliora significativamente l'affidabilit\u00e0 della trasmissione.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n <\/p>\n
Le capacit\u00e0 di Cisco SD-WAN, senza diretti analoghi in DMVPN\/PfR<\/h3>\n \nL'architettura della soluzione Cisco SD-WAN in alcuni casi consente di ottenere capacit\u00e0 la cui implementazione all'interno di DMVPN\/PfR \u00e8 o estremamente difficile, o non conveniente a causa del necessario dispendio di risorse, o addirittura impossibile. Esaminiamo le pi\u00f9 interessanti tra esse:<\/p>\n
Traffic-Engineering (TE)<\/h4>\n \nTE include meccanismi che permettono di deviare il traffico dal percorso standard creato dai protocolli di routing. TE \u00e8 frequentemente utilizzato per garantire un'elevata disponibilit\u00e0 dei servizi di rete, grazie alla capacit\u00e0 di reindirizzare rapidamente e\/o in anticipo il traffico importante su un percorso alternativo (non in sovrapposizione), con l'obiettivo di migliorare la qualit\u00e0 del servizio o la velocit\u00e0 di ripristino in caso di guasto sul 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 telecomunicazioni, questo compito viene svolto utilizzando tecnologie come il MPLS Traffic Engineering con estensioni dei protocolli IGP e il protocollo RSVP. Negli ultimi tempi, sta guadagnando sempre pi\u00f9 popolarit\u00e0 la tecnologia Segment Routing, che \u00e8 pi\u00f9 ottimizzata per la configurazione centralizzata e l'orchestrazione. Nelle classiche reti WAN, queste tecnologie generalmente non sono presenti o sono ridotte all'uso di meccanismi hop-by-hop come il Policy-Based Routing (PBR), che pu\u00f2 deviare il traffico, ma lo fa su ogni router singolarmente, senza considerare lo stato generale della rete o il risultato del PBR nei passaggi precedenti o successivi. Il risultato dell'applicazione di queste varianti di TE \u00e8 deludente: l'MPLS TE, a causa della complessit\u00e0 della configurazione e della manutenzione, 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 unica di PBR su tutta la rete. Questo vale ovviamente anche per le reti basate su DMVPN.<\/p>\n
Service-chaining (Sercizi di servizio) <\/h4>\n \nLa creazione di catene di servizi \u00e8 un compito ancora pi\u00f9 impegnativo nella classica instradamento 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 fuori dalla rete su determinati (o su tutti) nodi della rete SD-WAN per l'elaborazione tramite un'applicazione o un servizio specifico (QoS, Bilanciamento, Caching, Ispezione del traffico, ecc.). Inoltre, \u00e8 fondamentale poter controllare lo stato di questi servizi esterni, per evitare situazioni di black-holing, e sono necessari meccanismi che permettano di posizionare tali servizi esterni simili in diverse geo-localizzazioni con la possibilit\u00e0 che la rete selezioni automaticamente il nodo di servizio pi\u00f9 ottimale per l'elaborazione del traffico di un determinato filiale. Nel caso di Cisco SD-WAN, questo pu\u00f2 essere facilmente raggiunto creando una politica centralizzata appropriata che unisce tutti gli aspetti della catena di servizi target in un'unica entit\u00e0 e modifica automaticamente la logica del data-plane e del control-plane solo dove e quando necessario.<\/p>\n
Quali sono i risultati finali?<\/h2>\n \n\u00c8 evidente che sia DMVPN (insieme o senza Performance Routing) che Cisco SD-WAN affrontano in ultima analisi compiti molto simili<\/b> rispetto alla rete WAN distribuita dell'organizzazione. Tuttavia, le significative differenze architettoniche e funzionali della tecnologia Cisco SD-WAN portano il processo di risoluzione di queste sfide a un livello qualitativo superiore<\/b>. In sintesi, si possono notare le seguenti differenze significative tra le tecnologie SD-WAN e DMVPN\/PfR:<\/p>\n\nDMVPN\/PfR utilizza tecnologie collaudate per la creazione di reti VPN sovrapposte e, per quanto riguarda il data-plane, somiglia alla pi\u00f9 moderna tecnologia SD-WAN; tuttavia, presenta alcune limitazioni, come la necessit\u00e0 di una configurazione statica obbligatoria dei router e una scelta limitata delle topologie, basata sul modello Hub-n-Spoke. D'altra parte, DMVPN\/PfR dispone di alcune funzionalit\u00e0 che non sono ancora disponibili in SD-WAN (riferendosi a per-application BFD).<\/li>\n Nel contesto della tecnologia del control-plane, ci sono differenze fondamentali. Grazie all'elaborazione centralizzata dei protocolli di segnalazione, SD-WAN consente di ridurre notevolmente i domini di guasto e di 'slegare' il processo di trasferimento del traffico utente dall'interazione di segnalazione: la temporanea indisponibilit\u00e0 dei controller non influisce sulla capacit\u00e0 di trasferire il traffico utente. Allo stesso modo, la temporanea indisponibilit\u00e0 di una filiale (inclusa quella centrale) non influisce sulle possibilit\u00e0 di interazione delle altre filiali tra loro e con i controller.<\/li>\n L'architettura per la creazione e l'applicazione delle politiche di gestione del traffico nel caso di SD-WAN supera notevolmente quella di DMVPN\/PfR: il geo-backup \u00e8 implementato in modo significativamente migliore, non \u00e8 legato a un Hub, offre maggiori possibilit\u00e0 di configurazione delle politiche e l'elenco degli scenari di gestione del traffico realizzabili \u00e8 molto pi\u00f9 ampio.<\/li>\n Il processo di orchestrazione della soluzione \u00e8 anch'esso notevolmente diverso. DMVPN richiede parametri noti in anticipo, che devono essere in qualche modo riflessi nella configurazione, limitando cos\u00ec la flessibilit\u00e0 della soluzione e la possibilit\u00e0 di cambiamenti dinamici. Al contrario, SD-WAN parte dal presupposto che all'inizio della connessione il router \"non sappia nulla\" sui propri controller, ma sappia \"chi pu\u00f2 chiedere\" - questo \u00e8 sufficiente non solo per stablire automaticamente una 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, automazione e monitoraggio, SD-WAN supera ampiamente le capacit\u00e0 di DMVPN\/PfR, che sono il risultato dell'evoluzione delle tecnologie classiche e si basano in gran parte su una linea di comando CLI e sull'uso di sistemi NMS basati su template. <\/li>\n In SD-WAN, rispetto a DMVPN, i requisiti di sicurezza sono passati a un livello qualitativo superiore. I principi fondamentali sono: zero trust, scalabilit\u00e0 e autenticazione a due fattori.<\/li>\n<\/ul>\n\nDa queste semplici conclusioni potrebbe nascere una falsa impressione che la creazione di una rete basata su DMVPN\/PfR abbia perso oggi ogni rilevanza. Certamente non \u00e8 cos\u00ec. Ad esempio, nei casi in cui la rete utilizza molte attrezzature obsolete e non \u00e8 possibile sostituirle, DMVPN pu\u00f2 permettere di unire dispositivi \u2018vecchi\u2019 e \u2018nuovi\u2019 in un'unica rete geo-distribuita con un gran numero di vantaggi descritti sopra.<\/p>\n
D'altra parte, \u00e8 importante ricordare che tutti i router aziendali Cisco attuali basati su IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) supportano oggi qualsiasi modalit\u00e0 operativa \u2013 sia la classica routing che DMVPN e SD-WAN \u2013 La scelta \u00e8 determinata dalle esigenze attuali e dalla consapevolezza che in qualsiasi momento sulla stessa attrezzatura si pu\u00f2 iniziare a spostarsi verso tecnologie pi\u00f9 avanzate.<\/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