Uno dei commenti che ho di solito ottengono circa OpenFlow è "suona alla grande e io sono positivo di Yahoo! e Google alla fine ne fanno uso, ma non vedo nessun caso l'uso aziendale." (Si veda anche questo post del blog ). Ovviamente nessuno sarebbe andato per una vera e propria implementazione nativa OpenFlow e probabilmente vedrete ibrido (navi-in-the-notte) approccio più spesso nei laboratori di ricerca che in reti aziendali, ma c'è sempre la modalità integrata che consente di aggiungere OpenFlow funzionalità basate su infrastruttura di rete esistente.
Lasciando da parte le rivendicazioni pretenzioso come OpenFlow risolverà i problemi duri come il bilanciamento del carico globale , ci sono quattro funzioni si possono facilmente implementare con OpenFlow (Tony Bourke ha scritto su di loro in maniera più dettagliata):
- filtri di pacchetti - classificatore flusso seguito da una caduta o normale azione;
- politiche di routing basato - classificatore flusso seguito da interfaccia di uscita e / o spingere VLAN tag;
- route statiche - classificatori flusso utilizzando solo prefisso IP di destinazione e
- NAT - alcuni switch OpenFlow potrebbe supportare sorgente / destinazione indirizzo IP / porta riscrive.
Combinano con la natura effimera di OpenFlow (qualunque scarica di controllo nel dispositivo di rete non influisce in esecuzione / configurazione di avvio e scompare quando non è più necessario), e la possibilità di utilizzare lo stesso protocollo con le famiglie di prodotto, sia da uno o più fornitori, e si dispone di un combo piuttosto interessante.
In realtà, non mi interessa se il meccanismo di modificare le tabelle di inoltro dispositivi di rete 'è OpenFlow o qualcosa di completamente diverso, a condizione che sia programmabile , multi-vendor e integrato con le tecnologie di networking esistenti . Come ho scritto un certo numero di volte, OpenFlow è solo un TCAM / FIB / pacchetto strumento di download classificatore .
Ricordo che uno dei casi OpenFlow di uso primario: "aggiungere funzionalità in cui venditore è che manca" (vedi presentazione Igor Gashinsky da OpenFlow Simposio per una buona copertura di questo argomento).
Ora sosta per un minuto e ricordare quante volte male bisogno di qualche funzionalità in linea con le quattro funzioni che ho citato sopra (filtri di pacchetti, PBR, route statiche, NAT) che non si poteva attuare, a tutti, o che ha richiesto un miscuglio si aspettano di script (o XML / richieste Netconf se siete fan di automazione Junos) che è necessario modificare ogni volta che si distribuisce un diverso tipo dispositivo o una release software differenti.
Qui ci sono alcune idee mi sono nei primi 30 secondi (se si ottiene altre idee, si prega di scrivere un commento):
- L'autenticazione degli utenti per i dispositivi che non supportano 802.1X;
- Per utente access control (NAC credo è la parola d'ordine popolari) che funziona in modo identico su dial-up, VPN, wireless e dispositivi di accesso cablati;
- Spingere utente in una specifica VLAN in base a quello che sta facendo (o si basano su autenticazione utente personalizzata);
- Fornire agli utenti l'accesso controllato a una singola applicazione in un altro VLAN (che si combinano con NAT per risolvere i problemi percorso di ritorno);
- Layer-2 inserimento di servizio, sia esso firewall, IDS / IPS, WAAS o alcuni ancora sconosciuto dispositivo;
Guardando il mio breve elenco, sembra coppa @ aveva ragione: la sicurezza potrebbe essere solo la killer application per OpenFlow / SDN - OpenFlow potrebbero essere utilizzati sia per implementare alcune funzioni di sicurezza (filtri di pacchetti e di direzione del traffico), per contribuire a integrare le funzioni di sicurezza tradizionali con il resto della rete, o per implementare servizi di sicurezza dinamico inserimento in qualsiasi punto della rete - qualcosa che abbiamo fortemente bisogno, ma quasi mai ottenere.
Nessun commento:
Posta un commento
Nota. Solo i membri di questo blog possono postare un commento.