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