PowerEdge: Limitazioni NPAR delle schede QLogic FastLinQ 45XXX e 41XXX

Informazioni preliminari

In modalità NPAR (Network Partition), una scheda QLogic FastLinQ 45XXX/41XXX viene presentata al sistema operativo come più dispositivi Ethernet. Ciò è possibile abilitando più partizioni di schede di interfaccia di rete (NIC) su una porta fisica, ma al costo di progettare attentamente il dominio di trasmissione* quando l'origine e la destinazione del traffico unicast* risiedono sullo stesso host.
Per consentire la comunicazione tra due partizioni sulla stessa porta fisica, l'adattatore fornisce una funzione denominata Tx switching. L'obiettivo di questa funzionalità è quello di inoltrare il traffico internamente tra due partizioni logiche invece di basarsi sul routing tra l'origine e la destinazione. Lo switching Tx avviene in base alle regole di filtraggio MAC configurate su una partizione della scheda di rete. Il sistema operativo programma il percorso dati Layer 2 (da Mac a Mac o traffico BUM*). Nell'ambiente ESXi, NetworkIoChain gestisce il traffico e più precisamente il Teaming Engine "Load Balancing" che crea un percorso dati per un uplink specifico in base all'origine e alla destinazione dell'indirizzo MAC (quando il traffico lascia lo switch virtuale).
Questo comportamento fa sì che il pacchetto venga scartato poiché lo switching Tx sta inoltrando il pacchetto a un uplink nel team che non è registrato nel percorso dati di NetworkIochain*.

Traffico unicast* = origine e destinazione MAC note dal punto di vista dell'indirizzo MAC Tabella sullo switch (virtuale o fisico)
Broadcast Domain* = switch virtuale, switch fisico, VLAN e subnet fanno tutti parte del dominio di trasmissione (livello 2)
BUM* = Broadcast, Unicast sconosciuto, Multicast, traffico. Traffico di livello 2 che deve uscire dallo switch virtuale.
NetworkIOChain* =https://blogs.vmware.com/vsphere/2018/12/understanding-the-esxi-network-iochain.html 

1. Comunicazione tra due macchine virtuali (VM) sullo stesso host durante l'utilizzo di partizioni dalla stessa porta (vedere "Diagramma 1")

Come illustrato nel diagramma 1, in questa configurazione sono presenti due VM, VM1 (MAC M1 unicast) e VM2 (MAC M2 unicast). VM1 si trova dietro lo switch virtuale VS1, mentre VM2 si trova dietro VS2. VS1 ha PF0 come uplink, mentre VS2 ha PF2 e PF1 come uplink. PF0 e PF2 sono due partizioni sulla porta 1 della scheda QLogic FastLinQ 41XXX/45XXX, mentre PF1 è una partizione della porta 2. VS2 PF1 è l'interfaccia attiva nel team, mentre PF2 è un'interfaccia passiva (standby). NetworkIOChain crea un Datapath per MAC M1 su P0 e programma un IoChain per M2 su PF1 e PF2. Poiché il flusso di traffico è considerato unicast sconosciuto dal punto di vista di VS1 e VS2 (VS1 conosce solo l'indirizzo MAC della propria VM e lo stesso vale per VS2), NetworkIOchain contrassegna tale traffico come BUM e registra un percorso dati per utilizzare la porta di uplink PF0 per VM1 e PF1 per VM2.
VMkernel programma un filtro per MAC M1 su P0 e programma un filtro MAC per M2 su PF1 e PF2. Il traffico di switching NPAR Tx ha origine da VM1 (MAC M1 di origine) e destinato a VM2 (MAC M2 di destinazione) e torna sempre indietro attraverso PF2 poiché VMkernel ha programmato un filtro MAC per M2 sia su PF1 che su PF2. Il traffico non viene inviato alla rete a causa della corrispondenza del filtro MAC su PF2. Tuttavia, il traffico in arrivo su PF2 viene scartato da vSwitch in quanto si sta dirigendo verso una porta interna senza regole corrispondenti per raggiungere la scheda di rete virtuale della VM prevista.

Possibili soluzioni:

I) Utilizzare adattatori separati: Per eseguire questo lavoro di configurazione, è necessario utilizzare le porte di due schede di rete fisicamente separate in un team. È inoltre necessario assicurarsi che il percorso di rete non includa due PF dalla stessa porta fisica. Vedere "Diagramma 2".



II) Disabilitare lo switching NPAR Tx insieme al routing esterno: Il problema sopra indicato può essere risolto disabilitando lo switching NPAR Tx. Tuttavia, la sola disabilitazione dello switching NPAR Tx non risolve completamente il problema, in quanto vi sono casi in cui il traffico deve essere reindirizzato a una partizione logica sulla stessa porta. Quando lo switching NPAR Tx è disabilitato, è necessario il routing esterno. Il "Diagramma 3" approfondisce questo flusso. Vedere anche il problema #4 di seguito per le limitazioni con lo switching NPAR Tx disabilitato.


III) Come disabilitare il parametro di commutazione TX: Se è necessario disabilitare la commutazione NPAR Tx,
è possibile farlo impostando il parametro del modulo npar_tx_switching fino a 0.

Esempio di ESXi:

[root@esxi03:~] esxcfg-module -s 'npar_tx_switching=0' qedentv

2. Utilizzo di due PF dalla stessa porta fisica in un team

Questa configurazione è sconsigliata in quanto non fornisce resilienza né prestazioni. Quando il link sulla porta fisica si interrompe, sono interessati entrambi i PF su tale porta. Pertanto, questa configurazione non è utile e pertanto non è consigliata.

3. Modalità di teaming dipendenti dallo switch come LACP

Le modalità di teaming dipendenti dallo switch, come IEEE 802.3ad Link Aggregation (LACP), funzionano in base alla porta e non alla funzione PCI, ovvero alla funzione fisica o alla granularità a livello di PF. Pertanto, quando NPAR è abilitato, non è consigliabile configurare LACP con alcune partizioni (ad esempio PF0 e PF1) e utilizzare le partizioni rimanenti per altri scopi. La macchina a stati LACP viene eseguita sull host e sullo switch e determina gli stati dell'aggregazione. Le altre partizioni che non fanno parte del LAG non sono a conoscenza delle modifiche alla macchina degli stati e delle decisioni prese sul LAG. La policy di bilanciamento del carico configurata sullo switch si applica a tutti i flussi trasmessi dallo switch. Poiché lo switch non riconosce la configurazione NPAR, il traffico appartenente ad altri PF che non fanno parte del LAG è soggetto alle impostazioni previste per le partizioni che fanno parte del LAG. Ciò potrebbe causare effetti collaterali come l'inoltro di pacchetti a PF errato, un impatto imprevisto sul traffico dovuto al comportamento della macchina a stati LACP e così via. Si noti che alcuni dei comportamenti che possono verificarsi dipendono dall'implementazione di LACP sul lato switch, ma in generale possono esserci effetti collaterali indesiderati.

4. Utilizzo di Bridging o L2VPN che modificano il frame Ethernet Layer 2 QnQ o vlan in vni e così via (soluzione NFV come NSX)

Questo porta a un loop. Se si prevede di collegare il traffico, assicurarsi che NPAR sia disabilitato, altrimenti il traffico entra in condizione di loop a causa del modo in cui il flusso del traffico viene gestito su NetworkIOChain.