3. VXLAN Problem Statement (Dichiarazione del problema VXLAN)
Questa sezione fornisce ulteriori dettagli sulle aree che VXLAN intende affrontare. L'attenzione è rivolta all'infrastruttura di rete all'interno del data center e ai problemi ad essa correlati.
3.1. Limitations Imposed by Spanning Tree and VLAN Ranges (Limitazioni imposte dallo spanning tree e dagli intervalli VLAN)
Le attuali reti di livello 2 utilizzano il protocollo Spanning Tree IEEE 802.1D (Spanning Tree Protocol, STP) [802.1D] per evitare loop nella rete a causa di percorsi duplicati. STP blocca l'uso di collegamenti per evitare la replica e il loop dei frame. Alcuni operatori di data center vedono questo come un problema con le reti di livello 2 in generale, poiché con STP stanno effettivamente pagando per più porte e collegamenti di quanti possano realmente utilizzare. Inoltre, la resilienza dovuta al multipath non è disponibile con il modello STP. Nuove iniziative, come TRILL [RFC6325] e SPB [802.1aq], sono state proposte per aiutare con il multipath e superare alcuni dei problemi con STP. Le limitazioni STP possono anche essere evitate configurando i server all'interno di un rack per trovarsi sulla stessa rete di livello 3, con lo switching che avviene al livello 3 sia all'interno del rack che tra i rack. Tuttavia, questo è incompatibile con un modello di livello 2 per la comunicazione inter-VM.
Una caratteristica chiave delle reti di data center di livello 2 è il loro uso di reti locali virtuali (VLAN) per fornire l'isolamento broadcast. Un ID VLAN a 12 bit viene utilizzato nei frame di dati Ethernet per dividere la rete di livello 2 più ampia in più domini di broadcast. Questo ha funzionato bene per molti data center che richiedono meno di 4094 VLAN. Con la crescente adozione della virtualizzazione, questo limite superiore sta subendo pressioni. Inoltre, a causa di STP, diversi data center limitano il numero di VLAN che potrebbero essere utilizzate. Inoltre, i requisiti per gli ambienti multi-tenant accelerano la necessità di limiti VLAN più grandi, come discusso nella Sezione 3.2.
3.2. Multi-tenant Environments (Ambienti multi-tenant)
Il cloud computing comporta il provisioning elastico su richiesta di risorse per ambienti multi-tenant. L'esempio più comune di cloud computing è il cloud pubblico, dove un fornitore di servizi cloud offre questi servizi elastici a più clienti/tenant sulla stessa infrastruttura fisica.
L'isolamento del traffico di rete da parte di un tenant può essere effettuato tramite reti di livello 2 o di livello 3. Per le reti di livello 2, le VLAN sono spesso utilizzate per segregare il traffico -- quindi un tenant potrebbe essere identificato dalla propria VLAN, ad esempio. A causa del gran numero di tenant che un fornitore di cloud potrebbe servire, il limite di 4094 VLAN è spesso inadeguato. Inoltre, c'è spesso bisogno di più VLAN per tenant, il che esacerba il problema.
Un caso d'uso correlato è l'espansione cross-pod. Un pod consiste tipicamente in uno o più rack di server con connettività di rete e storage associata. I tenant possono iniziare su un pod e, a causa dell'espansione, richiedere server/VM su altri pod, specialmente nel caso in cui i tenant sugli altri pod non stiano utilizzando completamente tutte le loro risorse. Questo caso d'uso richiede un ambiente di livello 2 "esteso" che collega i singoli server/VM.
Le reti di livello 3 non sono nemmeno una soluzione completa per la multi-tenancy. Due tenant potrebbero utilizzare lo stesso set di indirizzi di livello 3 all'interno delle loro reti, il che richiede al fornitore di cloud di fornire l'isolamento in qualche altra forma. Inoltre, richiedere che tutti i tenant utilizzino IP esclude i clienti che si affidano a protocolli di livello 2 diretti o protocolli di livello 3 non-IP per la comunicazione inter-VM.
3.3. Inadequate Table Sizes at ToR Switch (Dimensioni di tabella inadeguate allo switch ToR)
Gli ambienti virtualizzati di oggi pongono ulteriori richieste sulle tabelle di indirizzi MAC degli switch Top-of-Rack (ToR) che si collegano ai server. Invece di un solo indirizzo MAC per collegamento server, il ToR deve ora apprendere gli indirizzi MAC delle singole VM (che potrebbero variare nelle centinaia per server). Questo è necessario perché il traffico da/verso le VM al resto della rete fisica attraverserà il collegamento tra il server e lo switch. Un tipico switch ToR potrebbe collegarsi a 24 o 48 server a seconda del numero delle sue porte rivolte verso i server. Un data center potrebbe consistere in diversi rack, quindi ogni switch ToR dovrebbe mantenere una tabella di indirizzi per le VM comunicanti attraverso i vari server fisici. Questo pone una richiesta molto più grande sulla capacità della tabella rispetto agli ambienti non virtualizzati.
Se la tabella trabocca, lo switch può smettere di apprendere nuovi indirizzi fino a quando le voci inattive non scadono, portando a un significativo flooding di frame di destinazione sconosciuta successivi.