PowerEdge: NPAR-Einschränkungen der QLogic FastLinQ 45XXX- und 41XXX-Adapter

Hintergrund

Im NPAR-Modus (Network Partition) wird ein QLogic FastLinQ 45XXX/41XXX-Adapter als mehrere Ethernet-Geräte für das Betriebssystem dargestellt. Dies wird durch die Aktivierung mehrerer NIC-Partitionen (Network Interface Card) auf einem physischen Port ermöglicht, allerdings auf Kosten einer sorgfältigen Gestaltung der Broadcast-Domain*, wenn sich Quelle und Ziel des Unicast*-Datenverkehrs auf demselben Host befinden.
Um die Kommunikation zwischen zwei Partitionen auf demselben physischen Port zu ermöglichen, bietet der Adapter eine Funktion namens Tx-Switching. Das Ziel dieser Funktion ist es, den Datenverkehr intern zwischen zwei logischen Partitionen weiterzuleiten, anstatt sich auf das Routing zwischen Quelle und Ziel zu verlassen. Das TX-Switching erfolgt basierend auf den MAC-Filterregeln, die auf einer NIC-Partition konfiguriert sind. Das Betriebssystem programmiert den Layer-2-Datenpfad (Mac-zu-Mac- oder BUM-Datenverkehr*). In der ESXi-Umgebung verwaltet NetworkIoChain den Datenverkehr und genauer gesagt die "Load Balancing"-Teaming-Engine, die einen Datenpfad zu einem bestimmten Uplink basierend auf Quelle und Ziel der MAC-Adresse erstellt (wenn der Datenverkehr den virtuellen Switch verlässt)Dieses
Verhalten führt dazu, dass das Paket verworfen wird, wenn das Tx-Switching das Paket an einen Uplink im Team weiterleitet, der nicht im Datenpfad der NetworkIochain* aufgezeichnet ist.

Unicast-Datenverkehr* = bekannte MAC-Quelle und bekanntes MAC-Ziel aus Sicht der MAC-Adresse Tabelle auf dem Switch (virtuell oder physisch)
Broadcast-Domain* = Virtueller Switch, physischer Switch, VLAN und Subnetz sind alle Teil der Broadcast-Domain (Layer 2)
BUM* = Broadcast, unbekanntes Unicast, Multicast, Datenverkehr. Layer 2-Datenverkehr, der den virtuellen Switch verlassen muss.
NetworkIOChain* =https://blogs.vmware.com/vsphere/2018/12/understanding-the-esxi-network-iochain.html 

1. Kommunikation zwischen zwei virtuellen Maschinen (VMs) auf demselben Host unter Verwendung von Partitionen über denselben Port (siehe "Diagramm 1")

Wie in Diagramm 1 dargestellt, gibt es in dieser Konfiguration zwei VMs: VM1 (Unicast-MAC M1) und VM2 (Unicast-MAC M2). VM1 befindet sich hinter dem virtuellen Switch VS1, während VM2 hinter VS2 sitzt. VS1 hat PF0 als Uplink, VS2 hat PF2 und PF1 als Uplinks. PF0 und PF2 sind zwei Partitionen auf Port 1 des QLogic FastLinQ 41XXX/45XXX-Adapters, während PF1 eine Partition von Port 2 ist. VS2 PF1 ist die aktive Schnittstelle im Team, während PF2 eine passive Schnittstelle (Stand-by) ist. NetworkIOChain erstellt einen Datenpfad für MAC M1 auf P0 und programmiert eine IoChain für M2 auf PF1 und PF2. Da der Datenverkehrsfluss aus der Perspektive von VS1 und VS2 als unbekanntes Unicast betrachtet wird (VS1 kennt nur die MAC-Adresse seiner eigenen VM und das Gleiche gilt für VS2), kennzeichnet die NetworkIO-Kette diesen Datenverkehr als BUM und zeichnet einen Datenpfad auf, um den Uplink-Port PF0 für VM1 und PF1 für VM2 zu verwenden.
VMkernel programmiert einen Filter für MAC M1 auf P0 und programmiert einen MAC-Filter für M2 auf PF1 und PF2. NPAR Tx-Switching-Datenverkehr, der von VM1 (Quell-MAC M1) stammt und VM2 (Ziel-MAC M2) zugeordnet ist, wird immer über PF2 zurückgeleitet, da VMkernel einen MAC-Filter für M2 sowohl auf PF1 als auch auf PF2 programmiert hat. Der Datenverkehr wird aufgrund der MAC-Filterübereinstimmung auf PF2 nicht an das Netzwerk gesendet. Der Datenverkehr, der auf PF2 eingeht, wird jedoch vom vSwitch gelöscht, da er an einen internen Port ohne übereinstimmende Regeln geleitet wird, um die virtuelle NIC der erwarteten VM zu erreichen.

Mögliche Lösungen:

I) Verwenden Sie separate Adapter: Um solche Konfigurationsarbeiten durchzuführen, müssen wir die Ports von zwei physisch getrennten Netzwerkadaptern in einem Team verwenden. Außerdem muss sichergestellt werden, dass der Netzwerkpfad keine zwei PFs vom selben physischen Port enthält. Siehe "Diagramm 2".



II) Deaktivieren Sie das NPAR Tx-Switching zusammen mit externem Routing: Das oben genannte Problem kann durch Deaktivieren der NPAR Tx-Umschaltung behoben werden. Das Deaktivieren des NPAR Tx-Switching allein löst das Problem jedoch nicht vollständig, da es Fälle gibt, in denen der Datenverkehr auf eine logische Partition auf demselben Port zurückgeleitet werden muss. Wenn NPAR Tx-Switching deaktiviert ist, ist externes Routing erforderlich. "Diagramm 3" erläutert diesen Ablauf. Siehe auch Problem #4 unten für Einschränkungen bei deaktivierter NPAR Tx-Umschaltung.


III) So deaktivieren Sie den TX-Switching-Parameter:
Wenn es notwendig ist, den NPAR Tx-Switch zu deaktivieren, kann dies durch Einstellen des Modulparameters erfolgen npar_tx_switching auf 0.

ESXi-Beispiel:

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

2. Verwenden von zwei PFs vom selben physischen Port in einem Team

Von dieser Konfiguration wird abgeraten, da sie weder Ausfallsicherheit noch Performance bietet. Wenn die Verbindung auf dem physischen Port ausfällt, sind beide PFs auf diesem Port betroffen. Daher ist diese Konfiguration nicht sinnvoll und wird daher nicht empfohlen.

3. Switchabhängige Teaming-Modi wie LACP

Switch-abhängige Teaming-Modi wie IEEE 802.3ad Link Aggregation (LACP) funktionieren pro Port und nicht mit PCI-Funktion, auch bekannt als physikalische Funktion oder PF-Granularität. Wenn NPAR aktiviert ist, wird daher nicht empfohlen, LACP mit einigen Partitionen (z. B. PF0 und PF1) zu konfigurieren und die verbleibenden Partitionen für andere Zwecke zu verwenden. Der LACP-Zustandsautomat wird auf dem Host und dem Switch ausgeführt und bestimmt die Zustände des Aggregats. Die anderen Partitionen, die nicht Teil der LAG sind, sind sich der Zustandsautomatenänderungen und der Entscheidungen, die über die LAG getroffen werden, nicht bewusst. Die auf dem Switch konfigurierte Lastenausgleichs-Policy gilt für alle Flows, die vom Switch übertragen werden. Da der Switch die NPAR-Konfiguration nicht kennt, unterliegt der Datenverkehr, der zu anderen PFs gehört, die nicht Teil der LAG sind, den Einstellungen, die für die Partitionen vorgesehen sind, die Teil der LAG sind. Dies kann zu Nebeneffekten führen, z. B. zu Paketen, die an einen falschen PF weitergeleitet werden, zu unerwarteten Auswirkungen auf den Datenverkehr aufgrund des LACP-Zustandsautomatenverhaltens usw. Es sollte beachtet werden, dass ein Teil des Verhaltens, das auftreten kann, von der Implementierung von LACP auf der Switchseite abhängt, aber im Allgemeinen kann es unerwünschte Nebeneffekte geben.

4. Verwenden von Bridging oder L2VPN, das den Layer-2-Ethernet-Frame QnQ oder VLAN in VNI ändert usw. (NFV-Lösung wie NSX)

Dies führt zu einer Schleife. Wenn Sie planen, Ihren Datenverkehr zu überbrücken, stellen Sie sicher, dass NPAR deaktiviert ist, andernfalls wechselt der Datenverkehr aufgrund der Art und Weise, wie der Datenverkehrsfluss auf dem gehandhabt wird, in Schleifenzustand. NetworkIOChain.