PowerEdge: NPAR-begränsningar för QLogic FastLinQ 45XXX- och 41XXX-adaptrar

Bakgrund

I NPAR-läge (Network Partition) visas en QLogic FastLinQ 45XXX/41XXX-adapter som flera Ethernet-enheter i operativsystemet. Detta är möjligt genom att aktivera flera NIC-partitioner (Network Interface Cards) på en fysisk port, men på bekostnad av att utforma sändningsdomänen* noggrant när källan och målet för unicast*-trafiken finns på samma värd.
För att tillåta kommunikation mellan två partitioner på samma fysiska port tillhandahåller adaptern en funktion som kallas Tx-växling. Målet med den funktionen är att vidarebefordra trafiken internt mellan två logiska partitioner i stället för att förlita sig på routning mellan källa och mål. Tx-växling sker baserat på de MAC-filtreringsregler som konfigurerats på en NIC-partition. Operativsystemet programmerar datasökvägen Layer 2 (Mac till Mac eller BUM-trafik*). I ESXi-miljön hanterar NetworkIoChain trafiken och mer exakt Teaming-motorn "Belastningsbalansering" som skapar en datasökväg till en specifik upplänk baserat på MAC-adresskälla och mål (när trafiken lämnar den virtuella switchen)
Detta beteende gör att paketet tappas eftersom Tx-växling vidarebefordrar paketet till en upplänk i teamet som inte registreras i datasökvägen för NetworkIochain*.

Unicast-trafik* = känd MAC-källa och känd MAC-destination från MAC-adressens synvinkel Tabellen på switchen (virtuell eller fysisk)
Broadcast Domain* = Virtual Switch, Physical Switch, VLAN och Subnet är alla en del av Broadcast Domain (lager 2)
BUM* = Broadcast, Unknown Unicast, Multicast, trafik. Layer 2-trafik som måste lämna den virtuella växeln.
NetworkIOChain* = https://blogs.vmware.com/vsphere/2018/12/understanding-the-esxi-network-iochain.html

1. Kommunikation mellan två virtuella maskiner (VM) på samma värd när partitioner från samma port används (se "Diagram 1")

Som du ser i diagram 1 finns det i den här konfigurationen två virtuella datorer, VM1 (unicast MAC M1) och VM2 (unicast MAC M2). VM1 sitter bakom den virtuella switchen VS1 medan VM2 sitter bakom VS2. VS1 har PF0 som upplänk medan VS2 har PF2 och PF1 som upplänkar. PF0 och PF2 är två partitioner på port 1 på QLogic FastLinQ 41XXX/45XXX-adaptern medan PF1 är en partition från port 2. VS2 PF1 är det aktiva gränssnittet i teamet medan PF2 är ett passivt (standby) gränssnitt. NetworkIOChain skapar en Datapath för MAC M1 på P0 och programmerar en IoChain för M2 på PF1 och PF2. Eftersom trafikflödet betraktas som okänt unicast ur VS1:s och VS2:s perspektiv (VS1 känner bara till MAC-adressen för sin egen virtuella dator och samma sak gäller för VS2) flaggar NetworkIOchain den trafiken som BUM och registrerar en datasökväg för att använda upplänksporten PF0 för VM1 och PF1 för VM2.
VMkernel programmerar ett filter för MAC M1 på P0 och programmerar ett MAC-filter för M2 på PF1 och PF2. NPAR Tx-växlingstrafik kommer från VM1 (käll-MAC M1) och är avsedd för VM2 (mål-MAC M2) loopar alltid tillbaka genom PF2 eftersom VMkernel har programmerat ett MAC-filter för M2 på både PF1 och PF2. Trafiken skickas inte till ledningen på grund av MAC-filtermatchningen på PF2. Men trafiken som kommer till PF2 tas bort av vSwitch eftersom den går till en intern port utan matchande regler för att nå den förväntade virtuella datorns virtuella nätverkskort.

Möjliga lösningar:

I) Använd separata adaptrar: För att kunna utföra sådant konfigurationsarbete måste vi använda portarna från två fysiskt separata nätverkskort i ett team. Vi måste också se till att nätverkssökvägen inte innehåller två PF:er från samma fysiska port. Se "Diagram 2".



II) Inaktivera NPAR Tx-växling tillsammans med extern routing: Problemet som anges ovan kan hanteras genom att inaktivera NPAR Tx-växling. Men att inaktivera NPAR Tx-växling ensam löser inte problemet helt eftersom det finns fall där trafik måste dirigeras tillbaka till en logisk partition på samma port. När NPAR Tx-växling är inaktiverat krävs extern routning. "Diagram 3" utvecklar detta flöde. Se även problem #4 nedan för begränsningar med NPAR Tx-växling inaktiverad.


III) Så här inaktiverar du TX-växlingsparametern:
Om det finns ett behov av att inaktivera NPAR Tx-växling kan detta göras genom att ställa in modulparametern npar_tx_switching till 0.

ESXi-exempel:

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

2. Använda två PF:er från samma fysiska port i ett team

Den här konfigurationen rekommenderas inte eftersom den inte ger återhämtning eller prestanda. När länken på den fysiska porten slutar fungera påverkas båda PF:erna på den porten. Så den här konfigurationen är inte användbar och rekommenderas därför inte.

3. Växla beroende teamindelningslägen som LACP

Växla beroende teamindelningslägen som IEEE 802.3ad Link Aggregation (LACP) fungerar per port och inte vid PCI-funktionen, även kallad fysisk funktion eller granularitet på PF-nivå. Så när NPAR är aktiverat rekommenderar vi inte att du konfigurerar LACP med vissa partitioner (t.ex. PF0 och PF1) och använder återstående partitioner för andra ändamål. LACP-tillståndsdatorn körs på värden och växeln och fastställer tillstånd för aggregeringen. De andra partitionerna som inte ingår i LAG-gruppen är inte medvetna om ändringar i tillståndsmaskineriet och beslut som fattas om LAG-gruppen. Principen för belastningsutjämning som konfigurerats på växeln gäller för alla flöden som överförs från växeln. Eftersom switchen inte känner till NPAR-konfigurationen omfattas trafik som tillhör andra PF som inte ingår i LAG-gruppen av de inställningar som är avsedda för de partitioner som ingår i LAG-gruppen. Detta kan leda till sidoeffekter som att paket vidarebefordras till felaktig PF, oväntad påverkan på trafiken på grund av LACP-tillståndsdatorns beteende och så vidare. Det bör noteras att en del av det beteende som kan uppstå beror på implementeringen av LACP på switchsidan, men i allmänhet kan det finnas oönskade biverkningar.

4. Använda bryggning eller L2VPN som ändrar Layer 2 Ethernet-ramen, QnQ eller vlan till vni och så vidare (NFV-lösning som NSX)

Detta leder in i en loop. Om du planerar att överbrygga trafiken måste du se till att NPAR är inaktiverat, annars går trafiken in i looptillstånd på grund av hur trafikflödet hanteras på NetworkIOChain.