PowerEdge: Omezení NPAR adaptérů QLogic FastLinQ 45XXX a 41XXX

Pozadí

V režimu NPAR (Network Partition) je adaptér QLogic FastLinQ 45XXX/41XXX prezentován jako více ethernetových zařízení v operačním systému. To je možné povolením více oddílů síťových karet (NIC) na fyzickém portu, ale za cenu pečlivého návrhu domény všesměrového vysílání*, pokud je zdroj a cíl jednosměrového* provozu umístěn ve stejném hostiteli.
Aby byla umožněna komunikace mezi dvěma oddíly na stejném fyzickém portu, je adaptér vybaven funkcí zvanou Tx switching. Cílem této funkce je interně přesměrovat provoz mezi dvěma logickými oddíly a nespoléhat se na směrování mezi zdrojem a cílem. Přepínání Tx probíhá na základě pravidel filtrování adres MAC nakonfigurovaných v oddílu NIC. Operační systém programuje datovou cestu vrstvy 2 (provoz Mac na Mac nebo NUM*). V prostředí ESXi spravuje provoz NetworkIoChain, přesněji modul seskupování "Load Balancing", který vytváří datovou cestu ke konkrétnímu uplinku na základě zdroje a cíle adresy MAC (když provoz opustí virtuální přepínač)
Toto chování způsobí, že paket bude zahozen, protože přepínání Tx přesměruje paket do uplinku v týmu, který není zaznamenán v datové cestě NetworkIochain*.

Jednosměrový provoz* = známý zdroj MAC a známý cíl MAC z hlediska adresy MAC Tabulka na přepínači (virtuální nebo fyzická)
Doména všesměrového vysílání* = Virtuální přepínač, Fyzický přepínač, VLAN a Podsíť jsou součástí domény všesměrového vysílání (vrstva 2)
BUM* = Všesměrové vysílání, Neznámé jednosměrové vysílání, vícesměrové vysílání, provoz. Provoz vrstvy 2, který musí opustit virtuální přepínač.
NetworkIOChain* = https://blogs.vmware.com/vsphere/2018/12/understanding-the-esxi-network-iochain.html

1. Komunikace mezi dvěma virtuálními počítači (VM) na stejném hostiteli při použití oddílů ze stejného portu (viz "Diagram 1")

Jak je znázorněno na obrázku 1, v této konfiguraci jsou dva virtuální počítače, VM1 (jednosměrové vysílání MAC M1) a VM2 (jednosměrové vysílání MAC M2). VM1 se nachází za virtuálním přepínačem VS1, zatímco VM2 je umístěn za VS2. VS1 má PF0 jako uplink, zatímco VS2 má PF2 a PF1 jako uplink. PF0 a PF2 jsou dva oddíly na portu 1 adaptéru QLogic FastLinQ 41XXX/45XXX, zatímco PF1 je oddíl z portu 2. VS2 PF1 je aktivní rozhraní v týmu, zatímco PF2 je pasivní (pohotovostní) rozhraní. NetworkIOChain vytvoří datovou cestu pro MAC M1 na P0 a naprogramuje IoChain pro M2 na PF1 a PF2. Vzhledem k tomu, že tok dat je z pohledu VS1 a VS2 považován za neznámý jednosměrový (VS1 zná pouze adresu MAC svého vlastního virtuálního počítače a totéž platí pro VS2), NetworkIOchain označí tento provoz jako BUM a zaznamená datovou cestu pro použití portu uplinku PF0 pro VM1 a PF1 pro VM2.
VMkernel naprogramuje filtr pro MAC M1 na P0 a naprogramuje MAC filtr pro M2 na PF1 a PF2. Přepínací provoz NPAR Tx pochází z VM1 (zdrojová adresa MAC M1) a směřuje do VM2 (cílová adresa MAC M2) se vždy vrací zpět přes PF2, protože VMkernel naprogramoval filtr MAC pro M2 na PF1 i PF2. Provoz není odesílán do drátu kvůli shodě filtru MAC na PF2. Provoz přicházející na PF2 je ale přepínačem vSwitch zahozen, protože směřuje na interní port bez odpovídajících pravidel, aby se dostal k očekávané virtuální síťové kartě virtuálního počítače.

Možné řešení:

I) Používejte samostatné adaptéry: Aby bylo možné provést takovou konfiguraci, musíme použít porty ze dvou fyzicky oddělených síťových adaptérů v týmu. Musíme také zajistit, aby síťová cesta neobsahovala dva PF ze stejného fyzického portu. Viz "Obrázek 2".



II) Zakažte přepínání NPAR Tx spolu s externím směrováním: Výše uvedený problém lze vyřešit zakázáním přepínání NPAR Tx. Samotné vypnutí přepínání NPAR Tx však problém zcela nevyřeší, protože existují případy, kdy je nutné provoz směrovat zpět do logického oddílu na stejném portu. Když je přepínání NPAR Tx zakázáno, je vyžadováno externí směrování. "Diagram 3" tento tok rozvádí. Viz také problém #4 níže, kde jsou uvedena omezení s vypnutým přepínáním NPAR Tx.


III) Jak deaktivovat přepínací parametr TX: Pokud je potřeba zakázat přepínání NPAR Tx,
lze to provést nastavením parametru modulu npar_tx_switching až 0.

Příklad systému ESXi:

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

2. Použití dvou PF ze stejného fyzického portu v týmu

Tato konfigurace se nedoporučuje, protože neposkytuje odolnost ani výkon. Když selže linka na fyzickém portu, budou ovlivněny oba PF na tomto portu. Tato konfigurace tedy není užitečná, a proto se nedoporučuje.

3. Přepínání režimů seskupování závislých na systému, jako je LACP

Režimy seskupování závislé na přepínačích, jako je IEEE 802.3ad Link Aggregation (LACP), fungují na základě jednotlivých portů, nikoli na úrovni funkce PCI, neboli fyzické funkce nebo členitosti PF. Pokud je tedy NPAR povolen, konfigurace LACP s některými oddíly (například PF0 a PF1) a použití zbývajících oddílů pro jiné účely se nedoporučuje. Stavový automat LACP běží na hostiteli a přepínači a určuje stavy agregace. Ostatní oddíly, které nejsou součástí LAG, nevědí o změnách stavového počítače a rozhodnutích o LAG. Zásady vyrovnávání zatížení nakonfigurované na přepínači platí pro všechny toky přenášené z přepínače. Vzhledem k tomu, že přepínač nezná konfiguraci NPAR, provoz náležející do jiných PF, které nejsou součástí LAG, podléhá nastavením určeným pro oddíly, které jsou součástí LAG. To může vést k vedlejším účinkům, jako je předávání paketů na nesprávný PF, neočekávaný dopad na provoz v důsledku chování stavového počítače LACP atd. Je třeba poznamenat, že některé chování, ke kterému může dojít, závisí na implementaci LACP na straně přepínače, ale obecně se mohou vyskytnout nežádoucí vedlejší účinky.

4. Použití přemostění nebo L2VPN, které upravují ethernetový rámec vrstvy 2, QnQ nebo vlan na vni atd. (řešení NFV, jako je NSX)

To vede do smyčky. Pokud plánujete přemostit provoz, ujistěte se, že je NPAR zakázán, jinak provoz přejde do stavu smyčky kvůli způsobu, jakým je tok provozu zpracováván na NetworkIOChain.