NIC-Teaming mit Broadcom unter HyperV 2008 R2

Ich habe einen HyperV-Cluster, der aus 3 Hosts besteht. Jeder Host ist mit meinen beiden Nexus 5548-Switches verbunden, die in einem Etherchannel ausgeführt werden. LACP auf dem Switch und NIC-Teaming mit Broadcom 802.3ad auf der Serverseite. Dies gibt mir 2 GB Bandbreite und bietet auch Fehlertoleranz.

Das Problem tritt auf, wenn ich eine Live-Migration durchführe. Vor der Live-Migration zeigen beide Nexus-Switches den MAC der VM in der ARP-Tabelle an. Nach der Migration zeigt ein Switch den MAC der VM und der andere den MAC des HyperV-Hosts, auf den er verschoben wurde.

Ich führte eine Paketerfassung durch und sah, dass der HyperV-Host einen kostenlosen ARP mit der IP der VM und dem MAC des Hosts anstelle des MAC der VM sendete. In diesem Fall verliere ich die Layer 3-Konnektivität. Ich muss den ARP-Eintrag manuell vom Switch löschen oder ca. 7 Minuten warten, bis er sich selbst korrigiert.

Ich habe mich umgesehen und die Leute haben ähnliche Probleme beim Umgang mit NIC-Teaming mit Broadcom. Hat das jemand gesehen? Irgendein Rat?

-------- Bearbeiten unten hinzugefügt

Ich habe dieses Problem nur beim Teaming mit Link Aggregation 802.3ad. Die Broadcom-Teaming-Optionen sind ...

• Link Aggregation (802.3ad)
  
• Smart Load Balancing (TM) und Failover
  
• SLB (Auto-Fallback Disable)
  
• Generisches Trunking (FEC / GEC) / 802.3ad-Draft Static

Ich habe auf Smart Load Balancing umgestellt und VM Live migriert, ohne die Netzwerkverbindung zu verlieren. Die ARP-Tabellen auf den Nexus-Switches sind zwar synchron, zeigen jedoch die MAC-Adresse des Hosts und nicht der VM an. Dies ist das Gegenteil von dem, was ich mir vorgestellt hatte. Sollten die ARP-Tabellen der Switches nicht den MAC der VM anzeigen? Wenn nicht und sie sollen den MAC des Hosts anzeigen, warum?

Okay. Nach 3 Wochen intensiven Kampfes habe ich endlich alles herausgefunden.

Ich habe einen Fall mit Broadcom-Support eröffnet und nachdem ich einige Tage hin und her gegangen bin, ist hier die Antwort, die ich von einem Broadcom-Softwareentwickler erhalten habe.

Das Anzeigen eines (vm_ipv4, host_mac_addr) oder (vm_ipv6, host_mac_addr) Paares auf einer Remote-Station oder einem Switch ist für viele Netzwerke in Ordnung. Basp übernimmt das Muxen der Adressen und stellt sicher, dass die VMs die richtigen Pakete erhalten.

Bei einigen Netzwerkkonfigurationen muss die IP-Adresse jedoch der vm_mac_addr zugeordnet werden. Wenn Sie vm_mac_addr anstelle von host_mac_addr verwenden möchten, müssen Sie den unten aufgeführten HyperVMode-Registrierungsschlüssel hinzufügen.

Wenn Sie die Mac-Adresse des VM nicht muxen möchten, dh nicht durch eine Mac-Adresse eines Nic ersetzen möchten, müssen Sie den folgenden Registrierungseintrag auf dem Host festlegen, auf dem der VM ausgeführt wird, und das System neu starten, damit er verwendet werden kann bewirken. Das Festlegen dieses Registrierungseintrags führt zu einem weniger effizienten Vorgang durch basp, ist jedoch in bestimmten Setups erforderlich, z. B. wenn ein DHCP-Server vorhanden ist, für den die Mac-Adresse des VM verwendet werden muss, um eine IP-Adresse zuzuweisen. Wenn Sie diesen Registrierungseintrag festlegen, sollte auch die Mac-Adresse des tatsächlichen VM in der Arp-Tabelle aller Remote-Stationen angezeigt werden, mit denen der VM verbunden ist.

Dieser Registrierungseintrag kann hinzugefügt werden, nachdem ein Team erstellt wurde, aber bevor der virtuelle Hyper-V-Adapter, der das Team verwendet, erstellt wurde. Der Wert 1 konfiguriert basp so, dass die Mac-Adresse eines VM anstelle der Mac-Adresse eines Nic in einem SlB-Team verwendet wird, wenn der Lastausgleich erfolgt. Der Wert 0 oder nicht vorhanden konfiguriert basp so, dass die Mac-Adresse des VM mit einer Mac-Adresse eines der Nics im Team mux / demux wird.

Setzen Sie die "1" im Registrierungspfad auf die richtige Teamnummer, auf die dieser Modus angewendet werden soll, und starten Sie das System neu. Beachten Sie, dass dieser Registrierungseintrag gelöscht wird, wenn das Team gelöscht wird, und jedes Mal neu erstellt werden muss, wenn das Team erstellt wird. Zukünftige Versionen von BACS verfügen über ein Kontrollkästchen, mit dem dieser Registrierungseintrag festgelegt wird und verhindert wird, dass er hinzugefügt werden muss, wenn ein Team erstellt wird und das System neu gestartet werden muss. Dieser Registrierungseintrag ist nur unter> = basp6-1.5.1 verfügbar.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Blfp \ Parameters \ 1] "HyperVMode" = dword: 00000001

PS. Abgesehen davon, dass dieser Registrierungseintrag nur für> = basp6-1.5.1 verfügbar ist, gilt er nur für slb-Teamtypen und nicht für lacp- oder gec-Teams.

Nachdem dies gesagt war, habe ich es versucht. Zuerst habe ich den Registrierungsschlüssel erstellt. Dann habe ich den virtuellen Switch in den Netzwerkmodus für private virtuelle Maschinen geändert. Ich habe den Server schnell neu gestartet. Als der Server wieder online ging, konfigurierte ich den virtuellen Switch wieder in den externen Modus und wählte den virtuellen BASP-Adapter. Ich habe Live Migrations getestet und alles hat perfekt funktioniert und die ARP-Tabellen im Nexus zeigten VM_IP und VM-MAC. JA !!!!

Hier ist die Einstellung innerhalb von SCVMM. Ich hatte Probleme wie Sie, bis ich den Trunk-Modus für den Host aktiviert habe. Wenn Sie mit der rechten Maustaste auf den Host in SCVMM -> Eigenschaften -> Registerkarte Netzwerk klicken