Ich stehe mit einigen virtuellen Maschinen in meinem vSphere-Setup vor einer sehr seltsamen Situation und kann nicht genau herausfinden, was passiert.
Ursprünglich arbeite ich mit einem 192.168.9.0/24Netzwerk, in dem 192.168.9.254sich der DHCP-Server, 192.168.9.43das Gateway, 192.168.9.82meine Arbeitsstation (sie hat ihre IP vom DHCP-Server erhalten) und 192.168.9.15die meines Kollegen befinden.
Das funktioniert einwandfrei und jede Maschine in diesem Netzwerk kann mit den anderen zusammenarbeiten. Sie alle können sich gegenseitig und über das Gateway auch den Rest der Welt anpingen.
Es wurde ein VSphere 6.5-Cluster mit drei Hosts installiert, die die statischen Adressen , bzw. haben . 192.168.9.1Auf diesen Maschinen läuft ESXi Version 6.0.0, 3380124, und jede hat vier Netzwerkkarten, die mit einem Paar gestapelter Dell N1524-Switches verbunden sind, wobei diese Switches mit dem Netzwerk verbunden sind. Auf diesem Cluster gibt es ein Netzwerk, das mit den Netzwerkkarten aller Hosts verbunden ist, und die VMs erhalten ihre IPs vom DHCP. Das funktioniert auch einwandfrei, aber da die VM-Nutzung zugenommen hat, ist der vom DHCP-Server bediente IP-Bereich jetzt ziemlich überfüllt, so dass einige normale Benutzer keine IP-Adresse erhalten können, wenn sie nachmittags ankommen.192.168.9.2192.168.9.3192.168.9.0/24Production192.168.9.254
Um dies zu vermeiden, habe ich für jeden Host eine neue Portgruppe auf dem vSwitch hinzugefügt und diesen Portgruppen denselben Namen ( VLAN) und denselben VLAN-Wert, nämlich 42, gegeben.
Die physischen Dell-Switches wurden neu konfiguriert, um dieses VLAN zusammen mit dem Standard-VLAN auf den Ports zuzulassen, an denen die Netzwerkkarten der Hosts angeschlossen sind (Trunk-Modus). Ich habe entschieden, dass dieses VLAN ein 10.10.10.0/24Netzwerk sein soll, damit es leicht vom normalen Netzwerk zu unterscheiden ist, und habe dem Switch daher die statische IP auf diesem VLAN gegeben 10.10.10.252.
Dann habe ich eine virtuelle Maschine unter Windows 2012 erstellt, die zwei Schnittstellen hat, eine auf Production(192.168.9.110), eine auf VLAN( 10.10.10.254) und die RRAS-Rolle aktiviert, sodass diese Maschine nun als Gateway zwischen 10.10.10.0/24und dem Rest der Welt fungiert.
Ich habe eine zweite virtuelle Maschine unter Windows 2012 erstellt, die nur eine Schnittstelle hat, auf VLANmit der statischen 10.10.10.253Adresse und habe sie benannt MDC. Ich habe die Rollen Domänencontroller, DHCP und DNS aktiviert. DHCP bedient Leases im Bereich, während DNS einfach vom Netzwerk 10.10.10.50 - 10.10.10.200an den DNS weiterleitet192.168.9.0/24
Anschließend habe ich zwei virtuelle Maschinen erstellt, eine auf dem ersten Host neben MDC und Gateway und eine auf dem dritten Host allein, beide mit dem Netzwerk verbunden . Da die Konnektivität einwandfrei zu funktionieren schien, habe ich beschlossen, vorhandene VMs mit diesem PowerCLI-Befehl aus dem Ordner in das Netzwerk VLANzu verschieben :TemporaryVLAN
Get-Folder Temporary | Get-VMs | Get-networkadapater | set-networkadapter -NetworkName VLAN
Ich habe auch die Gelegenheit genutzt, um sicherzustellen, dass alle Netzwerkadapter vmxnet3mit diesem Befehl
Get-Folder Temporary | Get-VMs | Get-networkadapater | set-networkadapter -Type vmxnet3
Da die Konnektivität noch immer in Ordnung war, habe ich einen weiteren Satz virtueller Maschinen erstellt, die ebenfalls mit dem VLANNetzwerk verbunden und auf allen drei Hosts platziert waren, was die folgende Topologie ergibt:
Gastgeber 1
MDC ( 10.10.10.253)
Gateway ( 10.10.10.254– 192.168.9.110)
Maschine1_H1 ( 10.10.10.64)
Maschine2_H1 ( 10.10.10.57)
Gastgeber 2
Maschine3_H2 ( 10.10.10.65)
Gastgeber 3
Maschine4_H3 ( 10.10.10.50)
Maschine5_H3 ( 10.10.10.51)
Und hier erhalte ich sehr merkwürdige Ergebnisse, wenn es um die Netzwerkkonnektivität geht, sowohl intern VLANals auch bei der Verbindung mit der Außenwelt:
- MDC kann jeden außer dem Switch anpingen (
10.10.10.252) - Gateway kann jeden außer Machine5_H3 anpingen
- Machine1_H1 kann alle anpingen, außer Machine3_H2
- Machine2_H1 kann jeden außer dem Switch anpingen (
10.10.10.252) - Machine3_H2 kann alle außer Host 1 und Machine1_H1 anpingen.
- Machine4_H3 kann alle anpingen
192.168.9.43, außer192.168.9.15undgoogle.fr(Namensauflösung ist OK) - Machine5_H3 kann alle anpingen außer
192.168.9.254,192.168.9.82(meine eigene Workstation) und10.10.10.254 - Mein eigener Computer (
192.168.9.82) kann jeden anpingen, außer Machine5_H3 (10.10.10.51)
Ich habe sichergestellt, dass die Firewalls auf allen Rechnern ausgeschaltet sind, bevor ich diese Tests durchgeführt habe. Außerdem habe ich arp -aMDC ausgeführt, um zu sehen, ob es einen MAC-Adresskonflikt gibt und keine Duplikate vorhanden sind. Die Rechner im TemporaryOrdner wurden vorsichtshalber auch alle ausgeschaltet, aber das hat nichts an den obigen Ergebnissen geändert. Nur um auf Nummer sicher zu gehen, habe ich diesen Codeausschnitt verwendet, um die Generierung einer neuen MAC-Adresse für diese Rechner zu erzwingen:
foreach ($VM in (Get-Folder Temporary | Get-VM))
{
$NetworkAdapter = $VM | Get-NetworkAdapter
$NetworkAdapter | Set-NetworkAdapter -MacAddress 00:50:56:1a:ff:ff -Confirm:$false
$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.deviceChange = New-Object VMware.Vim.VirtualDeviceConfigSpec[] (1)
$spec.deviceChange[0] = New-Object VMware.Vim.VirtualDeviceConfigSpec
$spec.deviceChange[0].operation = "edit"
$spec.deviceChange[0].device = $NetworkAdapter.ExtensionData
$spec.deviceChange[0].device.addressType = "generated"
$spec.deviceChange[0].device.macAddress = $null
$VM.ExtensionData.ReconfigVM_Task($spec)
}
An der Situation hat das nichts geändert.
Ich habe dann Wireshark auf dem Gateway installiert, angefangen, den Datenverkehr zu überwachen 10.10.10.254, und konnte jeden Datenverkehr sehen, in den diese Maschine verwickelt ist. Wenn beispielsweise meine Workstation ( 192.168.9.82) von Machine5_H3 ( 10.10.10.51) angepingt wird, kann ich die PING-Anforderung sehen, dann die PING-Antwort, und dennoch beschwert sich Machine5_H3, dass sie keine Antwort erhalten hat. Wenn ich es umgekehrt mache, kann ich die Anforderung sehen, 192.168.9.82aber das Gateway sieht nie eine Antwort.
Daher glaube ich, dass einige Pakete irgendwo verloren gehen, wobei ich hauptsächlich den Switch ( 10.10.10.252) verdächtige, aber ich bin nicht sicher, was ich tun kann, um diese Theorie zu bestätigen.
Link Aggregation war ursprünglich auf dem DELL-Switch-Stack aktiviert, verursachte aber Verbindungsprobleme von unseren Workstations zu den VMs, die IPs im 192.168.9.0/24Netzwerk haben, also haben wir es deaktiviert.
Das Ändern dieser Einstellung auf dem Switch-Stack änderte jedoch nichts an der obigen Situation.
Ich muss etwas falsch gemacht oder einige Konfigurationsdetails übersehen haben, kann aber nicht herausfinden, was es ist, und würde mich über jeden Vorschlag freuen, der mir bei der Lösung des für mich mysteriösen Problems hilft.
Antwort1
Gemäß dem Kommentar von Zac67 haben wir die NIC-Teaming-Konfiguration auf allen drei Hosts überprüft und dabei festgestellt, dass die ersten beiden den Parameter „Route basierend auf IP-Hash“ verwendeten, während der dritte Host „Route basierend auf dem ursprünglichen virtuellen Port“ verwendete.
Anschließend setzen wir den dritten Host auf den gleichen Wert wie die anderen und lesen die mit der ersten Option verbundene Warnung, die besagt: „Die Link-Aggregation sollte auf dem physischen Switch eingerichtet werden.“
Wir gingen daher zurück zum Switch und aktivierten die Link Aggregation für die entsprechenden Ports erneut, allerdings wurde dadurch die gesamte Konnektivität instabil, Maschinen im 192.168.9.0/24Netzwerk waren teilweise nicht erreichbar, während sich für die Personen im Netzwerk nichts änderte 10.10.10.0/24.
Daher entschieden wir uns für den umgekehrten Weg, deaktivierten die Link Aggregation auf den Switches und verwendeten auf allen drei Hosts die Option „Route basierend auf dem ursprünglichen virtuellen Port“.
Dadurch konnte das normale Verhalten des Netzwerks wiederhergestellt 192.168.9.0/24und die Konnektivität verbessert werden 10.10.10.0/24. Ich sage „besser“, weil einige Maschinen immer noch nicht erreichbar waren, nämlich diejenigen, Host3die den DHCP-Server nicht einmal erreichen konnten, um eine IP abzurufen.
Als wir den Datenverkehr mit Wireshark beobachteten, stellten wir fest, dass ARP-Broadcasts manchmal gefiltert wurden. Dies erklärte, warum einige Maschinen nicht miteinander kommunizieren konnten, gab uns aber noch immer keinen Hinweis auf eine mögliche Lösung.
Nachdem wir einige Wochen lang ohne Hoffnung auf eine Antwort daran festhingen, zogen wir die Berater hinzu, die uns bei der Installation der Infrastruktur geholfen hatten. Sie sagten uns zwei Dinge:
- LACP ist nicht mit VLANs kompatibel
- VLAN 42 wurde auf einem der Switch-Ports verboten
Indem sichergestellt wurde, dass die Konfiguration LACP überhaupt nicht verwendete, und die Einschränkung des Ports entfernt wurde, konnte eine voll funktionsfähige Situation geschaffen werden.
Nun fragen wir uns, wie wir es geschafft haben, VLAN 42 nur auf einem Port des Switches zu verbieten.
Was die LACP- und VLAN-Inkompatibilität betrifft, sind wir nie auf die Idee gekommen, dass dies die Ursache unserer Probleme sein könnte, aber jetzt, wo sie uns davon erzählt haben, scheint es ein bekanntes Problem beim Stapeln von DELL-Switches zu sein, aber ich konnte keine endgültige Antwort zu diesem Thema finden. Aber da es ohne funktioniert, ist für mich alles in Ordnung.