lunedì 21 luglio 2014

LAYER-3 COMMUTAZIONE VXLAN REVISITED

Il mio Trident 2 Chipset e Nexus 9500 post del blog deve aver colpito un nervo scoperto o due - Bruce Davie ha dedicato un intero paragrafo nelle sue reti fisiche in virtualizzato Networking World post sul blog per raccontare a tutti quanto il tutto è un non-problema e come tutto del bene nella terra NSX.
E 'sempre divertente scavare più in dettaglio per capire cosa sta realmente accadendo dietro le quinte; facciamolo.

Quello che ho veramente pretendesse

Ecco cosa ho scritto nel mio post del blog:
Trident 2 chipset non supporta il routing dei pacchetti VXLAN-incapsulati [...] per il momento le cifre chipset fuori è il tunnel di sovrapposizione per il pacchetto in arrivo, ed esegue la ricerca L2 dell'indirizzo MAC di destinazione, è troppo tardi per un altro L3 ricerca.
I passi necessari per ottenere dal mondo fisico a quello virtuale (VLAN-to-VXLAN) sono totalmente diverse rispetto i passi necessari per ottenere dal virtuale al mondo fisico (VXLAN-to-VLAN). Nel primo caso, uno switch di livello 3 (alias router):
  • Riceve un pacchetto Ethernet, potenzialmente con tag 802.1Q;
  • Esegue L2 ricerca per capire l'indirizzo MAC di destinazione appartiene al router (trigger L3 ricerca);
  • Esegue L3 di ricerca per trovare il prossimo hop;
  • Aggiunge salto successivo incapsulamento specifico al pacchetto e invia il pacchetto alla coda interfaccia di uscita.
Finora l'unica differenza tra un interruttore tradizionale L3 e un interruttore L3 VXLAN-capace è la possibilità di aggiungere in testa qualsiasi intestazione davanti del pacchetto Invece di scambiare l'intestazione MAC. Qualsiasi piattaforma con funzionalità di scatter-gather potrebbe fare questo per decenni.
Ricezione di un pacchetto L2 VXLAN-incapsulato e performante L3 ricerca presso l'uscita è una storia completamente diversa. Uno switch di livello 3:
  • Riceve un payload-in-VXLAN-in-IP-in-MAC pacchetto Ethernet;
  • Esegue una ricerca L2, L3 che innesca ricerca;
  • Esegue L3 ricerca e capisce il pacchetto viene inviato al suo indirizzo IP VTEP;
  • Estrae payload originale busta VXLAN;
  • Effettua un'altra ricerca L2, L3 che innesca ricerca;
  • Effettua un'altra ricerca L3 per trovare il prossimo hop;
  • Swap MAC intestazione e invia il pacchetto alla coda interfaccia di uscita.
Le parti segnate in rosso sono quelle che alcune piattaforme non possono fare.
Limitazioni hardware sul tunnel router di uscita non sono una novità - Catalyst 6500 non poteva eseguire hardware decapsulation di MPLS-over-GRE-over-IPsec pacchetti (almeno i Linecards che abbiamo avuto), anche se potrebbe fare le singole operazioni in hardware.

Che cosa ha VMware fare?

Hanno usato la funzionalità di inoltro esistente distribuito L3 di VMware NSX per spostare la ricerca L3 nelle hypervisor. Sulla base della descrizione nel post del blog di Bruce, che utilizzano routing VTEP nella direzione in entrata e ponte sul VTEP nella direzione di uscita, in modo efficace ballando intorno alle limitazioni hardware.

Da fisico a virtuale: Layer-3 lookup seguita da incapsulamento VXLAN

Virtuale a fisico: decapsulation VXLAN seguita da layer-2 ricerca

Ha importanza?

Il design disegno Bruce descritto rimuove la funzionalità confine strato-3 dal VTEP L3 - tutti hypervisor sono collegati direttamente alla VLAN esterno e devono avere tutte le informazioni inoltro L3 che la L3 VTEP ha.
In qualche modo mi ricorda il vecchio trucco abbiamo dovuto usare per collegare le reti MPLS / VPN su Internet - basta usare una route statica con un salto successivo globale .Devo dire di più?

Nessun commento:

Posta un commento

Nota. Solo i membri di questo blog possono postare un commento.