Protocolli legacy OpenFlow IN BASE DI RETI

Questo post è probabilmente un po 'prematuro, ma io sono positivo il CIO riceverà la visita di un fornitore che offre clean-slate OpenFlow / SDN a base di tessuti di data center in futuro non così lontano. In quel momento, una delle prime domande che si dovrebbe chiedere è " In che misura il nuovo paese delle meraviglie integrarsi con la rete già esistente? "o più specificamente" i protocolli di L2 e L3 sono supportati? "

Almeno uno dei produttori e con i controller che gestiscono OpenFlow switch fisici ha una risposta semplice: utilizzare LAG statico per collegare la vostra attrezzatura esistente con il nostro OpenFlow rete basata su (perché il nostro controller non supporta LACP), utilizzare route statiche (perché don 't eseguire tutti i protocolli di routing) e non creano alcun loop L2 in rete (perché anche noi non abbiamo STP). Se vi chiedete come affidabile che è, ovviamente non hanno attuato una rete ridondante con route statiche prima.

Tuttavia, per essere un po 'più ottimista, la necessità di un supporto per il protocollo legacy dipende soprattutto da come la nuova soluzione si integra con la rete.

Soluzioni Overlay (come NVP Nicira di) non interagiscono con la rete esistente a tutti .Un hypervisor open switch virtuale in esecuzione e l'utilizzo di STT o GRE appare come un host IP alla rete, e utilizza i meccanismi di Linux (compreso NIC bonding e LACP) per risolvere i problemi di connettività L2.

OpenFlow soluzioni ibride che solo modificano il comportamento dell'utente rivolto periferia della rete (esempio: per ogni utente il controllo di accesso) sono OK. Si consiglia di ispezionare attentamente cosa fa il prodotto ed assicurarsi che non modifica il comportamento del dispositivo di rete di fare affidamento su in rete, ma in linea di principio si dovrebbe andare bene. Ad esempio, il controller switch virtuale XenServermodifica solo il VM-rivestimento comportamento, ma non il comportamento configurato sulle porte di uplink.

Tessuti di rete Rip-and-replace OpenFlow base sono il problema veramente interessante. Dovrete connettere gli host esistenti per loro, così si sarebbe probabilmente desidera avere il supporto LACP ( a meno che non sei un negozio di VMware-only ), e dovrà integrarsi con il resto della rete, così si dovrebbe chiedere almeno:

• LACP, se si prevede di collegare nulla, ma padroni di casa vSphere al tessuto ... e avrete probabilmente bisogno di un dispositivo per collegare OpenFlow basata su parte della rete con il mondo esterno;
• LLDP o CDP. Se non altro, semplificano la risoluzione dei problemi, e che siano realizzate su quasi tutto compresi switch virtuale vSphere.
• STP meno che il controller OpenFlow implementa split horizon ponte come quello di vSphere switch virtuale , ma anche allora abbiamo bisogno di cose basilari come BPDU guardia .
• Un protocollo di routing se il OpenFlow basata su soluzione supporta L3 (OSPF viene in mente).

Chiama me un vecchio brontolone , ma non vorrei toccare un controller OpenFlow che non supporta i suddetti protocolli. Caso peggiore, se sarei stato costretto a implementare una rete utilizzando un controller, vorrei fare in modo che è totalmente isolata dal resto della mia rete. Anche allora un singolo punto di fallimento non avrebbe molto senso, quindi avrei bisogno di due firewall o router e il routing statico in scenari ridondanti si rompe prima o poi. Si ottiene l'immagine.

Per riassumere: lo stato del collegamento dinamico e protocolli di routing sono stati creati per un motivo. Non permettere sfarzosi new-age soluzioni per stordire te, o semplicemente potrebbe verificare una delle grandi preoccupazioni in fondo alla strada.

Corso Cisco - Corsi Cisco - Corso CCNA

 Corso Security - CCNA Security - Certificazione Cisco

POTREBBE MPLS-OVER-IP SOSTITUIRE VXLAN O NVGRE?

Un sacco di ingegneri si occupano di quello che sembra essere la creazione di formati di incapsulamento frivola nuove a sostegno di reti virtuali. Mentre STT ha un senso tecnico(che consente agli switch morbide da usare esistente NIC funzionalità offload TCP), è più difficile capire i vantaggi di VXLAN e NVGRE. Scott Lowe ha scritto un grande post blog di recente dove ha fatto una domanda molto valida: " ? Non potremmo utilizzare MPLS su IP o GRE "Potremmo, ma non ci guadagnerebbe nulla per farlo.

RFC 4023 specifica due metodi di MPLS-in-IP incapsulamento: label MPLS sulla parte superiore dello stack del protocollo IP (utilizzando il protocollo IP 137) e lo stack di label MPLS sulla parte superiore del GRE (usando MPLS tipo di protocollo in intestazione GRE).Potremmo usare uno di questi e di utilizzare la semantica tradizionali MPLS o uso improprio delle etichette MPLS come identificativo di rete virtuale (VNI). Analizziamo entrambe le opzioni.

Uso scorretto di label MPLS come VNI

In teoria, si potrebbe utilizzare MPLS-over-IP e MPLS-over-GRE, invece di VXLAN (o NVGRE) e utilizzare la prima etichetta MPLS come VNI. Anche se questo potrebbe funzionare (dopo tutto, NVGRE riutilizza GRE chiave come VNI), non ci guadagna niente.L'apparecchiatura esistente non riconoscere questo uso "creativo" di etichette MPLS, e ancora non avrebbe il piano di controllo e avrebbe dovuto contare su multicast IP virtuale per emulare inondazioni rete L2.

La label MPLS = VNI approccio sarebbe totalmente incompatibile con gli attuali pile MPLS e sarebbe quindi bisogno di un nuovo software in virtual-to-gateway fisici . Sarebbe anche andare contro il senso di MPLS - etichette devono avere un significato locale (mentre VNI ha significato a livello di rete) e dovrebbero essere assegnate indipendentemente dai singoli nodi MPLS (PE-egress router MPLS / VPN caso).

E 'anche lecito chiedersi se l'hardware esistente sarebbe in grado di elaborare pacchetti MAC-in-MPLS-in-GRE-in-IP, che sarebbe l'unico vantaggio potenziale di questo approccio.So che alcuni (costoso) Linecard interattive in Catalyst 6500 in grado di elaborare IP-in-MPLS-in-pacchetti GRE (come fanno alcuni interruttori da Juniper e HP), ma può elaborare MAC-in-MPLS-in-GRE? Chi lo sa.

Infine, come NVGRE, MPLS-over-GRE o MPLS-over-IP inquadratura con l'etichetta MPLS utilizzato come VNI manca di entropia che potrebbe essere utilizzato a fini di bilanciamento del carico , i commutatori esistenti non sarebbero in grado di bilanciare il traffico tra due host hypervisor a meno che ogni hypervisor padroni di casa si utilizzano indirizzi IP multipli.

Riutilizzo esistente MPLS stack di protocollo

Riutilizzo label MPLS come VNI ci compra niente, siamo quindi meglio usare STT o VXLAN (almeno uguale costo di bilanciamento del carico funziona decentemente bene). Che ne dite di usare MPLS-over-GRE il modo in cui è stato concepito per essere utilizzato - come parte dello stack del protocollo MPLS? Qui stiamo imbattersi in diversi posti di blocco principali:

• No hypervisor venditore è disposto a smettere di sostenere L2 reti virtuali , perché solo potrebbe essere richiesto per " mission-critical " craplications in esecuzione su Bilanciamento Microsoft Network Load , quindi non possiamo usare L3 MPLS VPN.
• Non c'è utilizzabile Ethernet-over-MPLS di serie . VPLS è una kludge (mesh = pieno di pseudowires) e si alternano approcci ( draft-raggarwa-mac-vpn e draft-ietf-L2VPN-evpn ) sono ancora sul tavolo da disegno.
• MPLS VPN basate richiedono piano decente di controllo , compreso il controllo-piano protocolli come BGP, e che richiederebbe un lavoro reale su hypervisor interruttori morbide. Implementazione di una soluzione ad hoc come VXLAN basata sul fare-more-with-less approccio (= cerchiamo di spingere il problema nel giro di qualcun altro e richiedono multicast IP in rete core) è meno costoso e più veloce.

Riassunto

Utilizzando MPLS-over-IP/GRE per implementare reti virtuali senso marginale, non risolve i problemi di bilanciamento del carico NVGRE sta affrontando, e richiede un investimento significativo nella hypervisor lato piano di controllo se si vuole farlo bene. Non mi aspetto di vederlo implementato in qualunque momento presto (anche se Nicira potuto farlo molto velocemente dovrebbero trovare un cliente che sarebbe disposto a pagare per questo).

Corso Cisco - Corsi Cisco - Corso CCNA

 Corso Security - CCNA Security - Certificazione Cisco

ABBIAMO BISOGNO SIA OPENFLOW E NETCONF

Ogni volta che scrivo su un caso di semplice utilizzo che potrebbero beneficiare di OpenFlow, ho sempre avere un commento sulla falsariga di " si può fare con netconf ".Ripetuta abbastanza spesso, tali osservazioni potrebbe fare un osservatore esterno credere che tu non hai bisogno di OpenFlow per Software Defined Networking (SDN) , che non è vero. Qui ci sono almeno tre ragioni fondamentali per cui questo è il caso.

Controllo / Data piano di separazione

Se avete bisogno di OpenFlow per SDN dipende ovviamente da come si definisce SDN. I componenti di rete sono state definite dal loro software nel momento in cui è diventato più intelligente di cavi di collegamento singoli host (nel periodo 3705 IBM ha lanciato negli anni Settanta, se non prima), quindi sicuramente non c'è bisogno OpenFlow per implementare rete definita da software.

Tuttavia, lame scherzi a parte, la definizione di SDN come promosso dalla Fondazione Networking aperto presuppone la separazione di controllo e piani di dati, e semplicemente non è possibile farlo con netconf. Semmai, ForCES sarebbe lo strumento giusto per il lavoro, ma non hai sentito parlare molto ForCES dal vostro fornitore preferito, avete ... anche se il suo sviluppo è stata lenta progressione (o meno, a seconda dei punti di vista) per nell'ultimo decennio.

Implementazione di nuove funzionalità

Netconf è un protocollo che consente di modificare la configurazione del dispositivo di rete. OpenFlow è un protocollo che consente di modificare la propria tabella di inoltro. Se è necessario riconfigurare un dispositivo, netconf è la strada da percorrere. Se si desidera implementare nuove funzionalità (qualunque esso sia) che non è facilmente configurabile all'interno del software del dispositivo di rete è in esecuzione, è meglio essere in grado di modificare il piano di inoltro direttamente.

Ci possono essere cose interessanti che si potrebbe fare attraverso la configurazione di rete del dispositivo con netconf (l'installazione di mappe delle rotte con policy-based routing, liste di accesso o MPLS statico in / out Etichetta mappature, per esempio), ma installando le stesse voci tramite OpenFlow sarebbe modo più facile , semplice e (soprattutto) dispositivo e indipendente dal vendor.

Ad esempio, netconf non ha alcun meccanismo standard si può usare oggi per creare e applicare una ACL a un'interfaccia . È possibile creare un ACL su un Cisco IOS / XR / NX-OS o uno switch o router con Junos netconf, ma il contenuto effettivo del messaggio netconf sarebbe vendor-specific. Per supportare i dispositivi realizzati da diversi fornitori, che avrebbe dovuto attuare vendor funzionalità specifiche nel controller netconf. Al contrario, è possibile installare le voci di inoltro stessi (con l'azione DROP) attraverso OpenFlow in qualsiasi OpenFlow-enabled switch (la questione "solo" essere se queste voci saranno eseguiti in hardware o la CPU centrale).

Stato effimero

Protocollo netconf modifica la configurazione del dispositivo. Qualunque cosa configurare con netconf appare nella configurazione del dispositivo e può essere salvato l'esecuzione configurazione permanente (o avvio) uno quando si decide di salvare le modifiche.Potrebbe non vogliamo che ciò accada se tutto quello che vogliamo fare è applicare una temporanea ACL su un'interfaccia o creare un MPLS-TP-like tunnel ingegneria del traffico (calcolato esternamente, non è segnalato tramite RSVP).

OpenFlow voci create nella tabella di inoltro sono per definizione temporanee. Essi non appaiono nella configurazione del dispositivo (e sono probabilmente divertente per risolvere i problemi, perché appaiono solo nella tabella di inoltro) e sono perso su reload dispositivo o la perdita di link.

Possiamo fare a meno netconf?

Considerato tutto quanto sopra, possiamo implementare reti SDN senza netconf?Naturalmente siamo in grado di assumere il scendiamo OpenFlow-unica via, ma gli utenti non molti considerando OpenFlow o venditori sono disposti a farlo ( Google di essere una delle eccezioni ), la maggior parte di loro vorrebbe mantenere le testate sul campo della loro intelligenza dispositivi di rete e aumentare la loro funzionalità aggiuntive configurato attraverso OpenFlow. In un vero network, ci sarà quindi bisogno di entrambi netconf configurare il software esistente in esecuzione in dispositivi di rete (si spera attraverso messaggi standardizzati in un futuro non troppo lontano), e potenzialmente OpenFlow per aggiungere nuove funzionalità quando necessario.

Corso Cisco - Corsi Cisco - Corso CCNA

 Corso Security - CCNA Security - Certificazione Cisco

NETCONF = ASPETTATEVI ON STEROIDS

Dopo l'esplosione iniziale di OpenFlow / SDN campagna pubblicitaria , un certo numero di persone hanno fatto affermazioni che OpenFlow non è lo strumento si può usare per rendere il lavoro SDN, e netconf è comunemente citato come alternativa (e non sorprende, considerando che il sostegno sia IOS Cisco e Junos esso). Purtroppo, considerando lo stato attuale di netconf, nulla può essere più lontano dalla verità.

Che cosa è netconf?

Netconf ( RFC 6,421 mila ) è un protocollo basato su XML utilizzato per gestire la configurazione di apparecchiature di rete. Permette la console di gestione ("manager") per impartire comandi e modificare la configurazione dei dispositivi di rete ("agenti netconf"). A questo proposito, è un po 'simile a SNMP, ma dato che usa XML, fornisce un insieme molto più ricco di funzionalità rispetto alle semplici coppie chiave / valore di SNMP.

Per ulteriori dettagli, vorrei vivamente di ascoltare il netconf Pusher Packet podcast.

Cosa c'è di sbagliato netconf?

Greg Ferro ha una grande analogia nella suddetta podcast: netconf è come SNMPv2/v3 (il protocollo di trasporto) e Yang (il linguaggio usato per descrivere messaggi netconf validi) è come ASN.1 (la sintassi descrivere variabili SNMP). Tuttavia, c'è un terzo componente nel quadro SNMP: un ampio insieme di standard MIB che vengono attuate da quasi tutti i fornitori di rete.

E 'quindi possibile scrivere un'applicazione per la gestione di rete utilizzando un MIB standard che avrebbe funzionato con attrezzature da tutti i venditori che hanno deciso di attuare tale MIB. Per esempio, se gli sviluppatori Hadoop decidere di utilizzare LLDP di auto-scoperta della topologia dei cluster Hadoop , che poteva contare su LLDP MIB essere disponibile negli switch da molti produttori di data center networking.

A parte pochi aspetti fondamentali della gestione della sessione, nessuna di tali struttura standardizzata dei dati esiste nel mondo netconf. Per esempio, non esiste un comando standard (specificata in un RFC) che si potrebbe usare per ottenere l'elenco di interfacce, spegnere un'interfaccia o configurare un indirizzo IP su un'interfaccia. Le bozze sono state scritte dal gruppo NETMOD di lavoro , ma ci vorrà un po 'prima che lo rendono allo stato RFC e vengono attuate dai fornitori principali.

Ogni singolo fornitore, che ci ha graziati con una implementazione netconf utilizza quindi il suo formato proprietario all'interno della busta XML di netconf. Nella maggior parte dei casi, il fornitore parte specifica delle mappe dei messaggi direttamente in comandi CLI esistenti (nel caso in cui Junos, i comandi sono in formato XML, perché Junos XML utilizza internamente). Posso dunque scrivere un'applicazione netconf che avrebbe lavorato con Cisco IOS e Junos? Certo che potevo ... se avessi implementare un fornitore modulo specifico per ogni famiglia di dispositivi ho intenzione di sostenere nella mia applicazione.

Perché utilizzare netconf?

Prendiamo in considerazione le alternative: decenni fa abbiamo configurato dispositivi di rete sulla sessioni Telnet utilizzando aspettano script - script di automazione semplici che specificano ciò che si deve inviare al dispositivo, e quale risposta ci si dovrebbe aspettare. Si potrebbe implementare gli script con l'originale si aspettano strumento, o con un linguaggio di scripting come Perl o Tcl.

Utilizzando un protocollo standard che fornisce una chiara definizione del messaggio ( si aspettano gli script sono stati principalmente congetture e potrebbe rompersi ad ogni aggiornamento software fatto su i dispositivi di rete) e la segnalazione degli errori (un'altra parte le congetture del aspettano script) è evidentemente una soluzione molto più robusta, ma è ancora troppo poco e troppo lentamente consegnato. Quello che ci serve è un meccanismo standard di configurazione di un ambiente multi-vendor, non è un wrapper migliore intorno CLI esistente (anche se l'involucro non meglio tornare utile).

Corso Cisco - Corsi Cisco - Corso CCNA

 Corso Security - CCNA Security - Certificazione Cisco