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