4. VXLAN
VXLAN (rete locale virtuale eXtensibile, Virtual eXtensible Local Area Network) affronta i requisiti sopra indicati dell'infrastruttura di rete del data center di livello 2 e di livello 3 in presenza di VM in un ambiente multi-tenant. Funziona sull'infrastruttura di rete esistente e fornisce un mezzo per "estendere" una rete di livello 2. In breve, VXLAN è uno schema di overlay di livello 2 su una rete di livello 3. Ogni overlay è chiamato segmento VXLAN (VXLAN Segment). Solo le VM all'interno dello stesso segmento VXLAN possono comunicare tra loro. Ogni segmento VXLAN è identificato attraverso un ID di segmento a 24 bit, denominato "identificatore di rete VXLAN (VXLAN Network Identifier, VNI)". Questo consente fino a 16 M segmenti VXLAN di coesistere all'interno dello stesso dominio amministrativo.
Il VNI identifica l'ambito del frame MAC interno originato dalla singola VM. Pertanto, si potrebbero avere indirizzi MAC sovrapposti tra i segmenti ma non avere mai traffico che "si incrocia" poiché il traffico è isolato utilizzando il VNI. Il VNI si trova in un'intestazione esterna che incapsula il frame MAC interno originato dalla VM. Nelle sezioni seguenti, il termine "segmento VXLAN" viene utilizzato in modo intercambiabile con il termine "rete overlay VXLAN".
A causa di questa incapsulamento, VXLAN potrebbe anche essere chiamato uno schema di tunneling per sovrapporre reti di livello 2 su reti di livello 3. I tunnel sono senza stato, quindi ogni frame viene incapsulato secondo un insieme di regole. Il punto terminale del tunnel (punto terminale del tunnel VXLAN, VXLAN Tunnel End Point o VTEP) discusso nelle sezioni seguenti si trova all'interno dell'hypervisor sul server che ospita la VM. Pertanto, il VNI e l'incapsulamento del tunnel/intestazione esterna correlato a VXLAN sono noti solo al VTEP -- la VM non lo vede mai (vedere Figura 1). Si noti che è possibile che i VTEP possano anche trovarsi su uno switch fisico o server fisico e potrebbero essere implementati in software o hardware. Un caso d'uso in cui il VTEP è uno switch fisico è discusso nella Sezione 6 sugli scenari di distribuzione VXLAN.
Le sezioni seguenti discutono scenari tipici di flusso di traffico in un ambiente VXLAN utilizzando un tipo di schema di controllo -- apprendimento del piano dati (Data Plane Learning). Qui, l'associazione del MAC della VM all'indirizzo IP del VTEP viene scoperta tramite l'apprendimento dell'indirizzo sorgente. Il multicast viene utilizzato per trasportare frame di destinazione sconosciuta, broadcast e multicast.
Oltre a un piano di controllo basato sull'apprendimento, esistono altri schemi possibili per la distribuzione delle informazioni di mappatura IP VTEP a MAC VM. Le opzioni potrebbero includere una ricerca basata su autorità centrale/directory da parte dei singoli VTEP, distribuzione di queste informazioni di mappatura ai VTEP da parte dell'autorità centrale e così via. Questi sono talvolta caratterizzati come modelli push e pull, rispettivamente. Questo documento si concentrerà sullo schema di apprendimento del piano dati come piano di controllo per VXLAN.
4.1. Unicast VM-to-VM Communication (Comunicazione unicast da VM a VM)
Consideriamo una VM all'interno di una rete overlay VXLAN. Questa VM non è a conoscenza di VXLAN. Per comunicare con una VM su un host diverso, invia un frame MAC destinato al target come di consueto. Il VTEP sull'host fisico cerca il VNI a cui questa VM è associata. Quindi determina se il MAC di destinazione è sullo stesso segmento e se esiste una mappatura dell'indirizzo MAC di destinazione al VTEP remoto. Se così, un'intestazione esterna comprendente un MAC esterno, un'intestazione IP esterna e un'intestazione VXLAN (vedere Figura 1 nella Sezione 5 per il formato del frame) vengono anteposti al frame MAC originale. Il pacchetto incapsulato viene inoltrato verso il VTEP remoto. Al ricevimento, il VTEP remoto verifica la validità del VNI e se esiste una VM su quel VNI utilizzando un indirizzo MAC che corrisponde all'indirizzo MAC di destinazione interno. Se così, il pacchetto viene spogliato delle sue intestazioni di incapsulamento e passato alla VM di destinazione. La VM di destinazione non conosce mai il VNI o che il frame è stato trasportato con un incapsulamento VXLAN.
Oltre a inoltrare il pacchetto alla VM di destinazione, il VTEP remoto apprende la mappatura dal MAC sorgente interno all'indirizzo IP sorgente esterno. Memorizza questa mappatura in una tabella in modo che quando la VM di destinazione invia un pacchetto di risposta, non sia necessario un flooding di "destinazione sconosciuta" del pacchetto di risposta.
La determinazione dell'indirizzo MAC della VM di destinazione prima della trasmissione da parte della VM sorgente viene eseguita come con gli ambienti non-VXLAN tranne come descritto nella Sezione 4.2. I frame broadcast vengono utilizzati ma sono incapsulati all'interno di un pacchetto multicast, come dettagliato nella Sezione 4.2.
4.2. Broadcast Communication and Mapping to Multicast (Comunicazione broadcast e mappatura a multicast)
Consideriamo la VM sull'host sorgente che tenta di comunicare con la VM di destinazione utilizzando IP. Supponendo che entrambe siano sulla stessa sottorete, la VM invia un frame broadcast ARP (Address Resolution Protocol). Nell'ambiente non-VXLAN, questo frame verrebbe inviato utilizzando broadcast MAC attraverso tutti gli switch che trasportano quella VLAN.
Con VXLAN, un'intestazione incluso il VNI VXLAN viene inserita all'inizio del pacchetto insieme all'intestazione IP e all'intestazione UDP. Tuttavia, questo pacchetto broadcast viene inviato al gruppo multicast IP su cui quella rete overlay VXLAN è realizzata.
Per effettuare questo, dobbiamo avere una mappatura tra il VNI VXLAN e il gruppo multicast IP che utilizzerà. Questa mappatura viene effettuata a livello di gestione e fornita ai singoli VTEP attraverso un canale di gestione. Utilizzando questa mappatura, il VTEP può fornire rapporti di appartenenza IGMP allo switch/router upstream per unirsi/lasciare i gruppi multicast IP correlati a VXLAN secondo necessità. Questo abiliterà la potatura dei nodi foglia per indirizzi di traffico multicast specifici in base alla disponibilità di un membro su questo host utilizzando l'indirizzo multicast specifico (vedere [RFC4541]). Inoltre, l'uso di protocolli di routing multicast come Protocol Independent Multicast - Sparse Mode (PIM-SM vedere [RFC4601]) fornirà alberi multicast efficienti all'interno della rete di livello 3.
Il VTEP utilizzerà join (*,G). Questo è necessario poiché l'insieme delle sorgenti di tunnel VXLAN è sconosciuto e può cambiare spesso, poiché le VM si attivano/disattivano su host diversi. Una nota a margine qui è che poiché ogni VTEP può agire sia come sorgente che come destinazione per i pacchetti multicast, un protocollo come PIM bidirezionale (BIDIR-PIM -- vedere [RFC5015]) sarebbe più efficiente.
La VM di destinazione invia una risposta ARP standard utilizzando unicast IP. Questo frame verrà incapsulato al VTEP che collega la VM originante utilizzando incapsulamento VXLAN unicast IP. Questo è possibile poiché la mappatura del MAC di destinazione della risposta ARP all'IP del punto terminale del tunnel VXLAN è stata appresa in precedenza attraverso la richiesta ARP.
Si noti che i frame multicast e i frame "destinazione MAC sconosciuta" vengono anche inviati utilizzando l'albero multicast, similmente ai frame broadcast.
4.3. Physical Infrastructure Requirements (Requisiti dell'infrastruttura fisica)
Quando il multicast IP viene utilizzato all'interno dell'infrastruttura di rete, un protocollo di routing multicast come PIM-SM può essere utilizzato dai singoli router/switch IP di livello 3 all'interno della rete. Questo viene utilizzato per costruire alberi di inoltro multicast efficienti in modo che i frame multicast vengano inviati solo a quegli host che hanno richiesto di riceverli.
Allo stesso modo, non vi è alcun requisito che la rete effettiva che collega la VM sorgente e la VM di destinazione debba essere una rete di livello 3: VXLAN può anche funzionare su reti di livello 2. In entrambi i casi, una replica multicast efficiente all'interno della rete di livello 2 può essere ottenuta utilizzando IGMP snooping.
I VTEP non devono (MUST NOT) frammentare i pacchetti VXLAN. I router intermedi possono frammentare i pacchetti VXLAN incapsulati a causa della dimensione del frame più grande. Il VTEP di destinazione può (MAY) scartare silenziosamente tali frammenti VXLAN. Per garantire la consegna del traffico end-to-end senza frammentazione, si raccomanda (RECOMMENDED) che le MTU (Maximum Transmission Unit) attraverso l'infrastruttura di rete fisica siano impostate su un valore che accomoda la dimensione del frame più grande dovuta all'incapsulamento. Altre tecniche come Path MTU discovery (vedere [RFC1191] e [RFC1981]) possono (MAY) essere utilizzate per soddisfare anche questo requisito.