Dropped Packets auf vMotion NIC

[stahly]

Hallo allerseits!

Auf 2 Hosts haben wir Dropped Packets (empfangen) auf dem vMotion NIC (10G)
Selbst dann, wenn sich der Host im Wartungsmodus befindet und keine VM auf dem Host ist.

Startet man einen vMotion-Vorgang, wird die VM mit der "üblichen 10G-Geschwindigkeit" verschoben. Also eigentlich alles gut. Dabei gehen die verloren gegangenen Pakete aber nochmals drastisch nach oben.

Die Jungs aus der Netzwerkabteilung sagen, dass alles I.O. ist...

Hat jemand eine Idee, woran das liegen könnte?

Bedankt & viele Grüße, der stahly

[irix]

Die Jungs aus der Netzwerkabteilung sagen, dass alles I.O. ist...

Bei denen steht ja auch schon im Anstellungsvertrag das sie Luegen duerfen ohne Rot zu werden. Gleiches gilt fuer die Securityjungs

Zum Thema,
eigenes VLAN und nicht geroutet oder? Gibts dropped Packages auf fuer anderen Art von Verkehr?

Gruss
Joerg

[stahly]

Bei denen steht ja auch schon im Anstellungsvertrag das sie Luegen duerfen ohne Rot zu werden. Gleiches gilt fuer die Securityjungs
...

...
eigenes VLAN und nicht geroutet oder? Gibts dropped Packages auf fuer anderen Art von Verkehr?
...

Ja, ist ein eigenes VLAN. Die dropped Packages sind auch nur auf der Eingangsseite (also empfangene Pakete (gleichbeleibend ca. 60000 im Leistungsdiagramm / Netzwerk / 20sec))

Der 10G Anschluss für das Produktivnetz hat einen Durchnschittswert von 200 bei den empf. Paketen (habe gerade gesehen, das dort auch ein paar wenige vermisst werden )

[bla!zilla]

Dropped Packets auf einem Port, wo eigentlich kein Verkehr sein dürfte (Hosts im Wartungsmodus) ist ein relativ sicherer Indikator für Flooding, wie es z.B. von einigen dummen Loadbalancern gemacht wird. Wird ein Paket auf einem Port empfangen, was dort nicht hingehört, dann wird es gedroppt und damit erhöht sich der Counter.

Häng mal einen Sniffer in das VLAN.

[PeterDA]

Moin,
hatte ähnliches Verhalten auch vor kurzem. Lag daran, dass eine Leitung nicht sauber war...

Wie ist die 10G Verbindung aufgebaut?
a) LWL
b) DAC
-> Wenn DAC Kabel sind die SFP+ Module auf den DAC Kabel im Server und der Switch Supportet?

Gruß Peter

[stahly]

Es sind LWL Kabel. Und da es bei 2 Hosts auftritt, ist die Wahrscheinlichkeit hoch, dass die SFPs i.O. sind. (Ich gucke aber nochmal... )
Alle SFPs sind vom selben Typ - auch die, bei denen es funktioniert.

Tja, den Sniffer müssen dann wohl doch die Netzwerkjungs installieren. Habe da wenig Erfahrung mit.

[bla!zilla]

Hast du die dropped Packets auf allen Switchports in dem VLAN?

Defekte an Kabeln oder SFPs gehen einher mit Frame Checksum Fehlern etc. Wenn es nur dropped Packets sind, dann ist es kein Kabel oder SFP.

[stahly]

Hast du die dropped Packets auf allen Switchports in dem VLAN?
...

Nein, nur an 2 Hosts von 8.
Jeweils 4 in RZ1 und 4 in RZ2.
Die Hosts in RZ2 alle mit 10G und Hosts in RZ1 alle mit 1G (natürlich alle im selben VLAN).

[stahly]

...
Häng mal einen Sniffer in das VLAN.

Kann das auch ne VM sein? Wenn ja, gibt es sogar ein fertige Appliance dafür?

[bla!zilla]

Kann auch eine VM sein. Eine fertige Appliance fällt mir nicht ein. Aber eine Windows VM mit Wireshark dürfte es tun.

[rprengel]

Kann auch eine VM sein. Eine fertige Appliance fällt mir nicht ein. Aber eine Windows VM mit Wireshark dürfte es tun.

Kali ehemals backtrack gibt es als Vm inc. whireshark
Und obendrauf jede Menge andere nette Tools.

Gruss

[blue_focus]

Also ich habe das vor einer Weile (ca. vor einem Jahr) bei uns auch beobachtet und sicher eine Woche nach einem Gespenst hinterher gejagt. Über vCenter lassen sich in den Performancecharts bei jeder vMotion bei den korrespondierenden Hosts bis zu ein paar wenige Tausend Packet Drops feststellen. (Ich glaube jeweils der empfangende Hosts war der "Verwerfer")
Auf den Coreswitches war jedoch nichts zu finden. Die ErrorCounters veränderten sich nicht.
Sniffen wollte ich mir nicht an tun. Da brauchts erst mal ne Maschine die nen 10Gbit - Stream Echtzeit verarbeiten und analysieren kann. Vom manuelle Auswerten der Datenflut ganz abgesehen - Naja mit ner minikleinen VM mit ganz wenig vRAM und keiner Last drauf wärs vielleicht noch gegangen...

Ein guter Freund von mir - auch ein RZ-Betrieb hatte dasselbe Thema und hat nen Case bei VMWare geöffnet. Der Outcome war seitens vmware -> Es sei ein Schönheitsfehler (Darstellungsfehler) der wohl mit der nächsten Release behoben sein sollte. Irgendwo hatte ich dazu auch was in der offiziellen vmware-community stehen. Kanns jedoch ums verrecken nicht mehr finden

Müsste glatt mal probieren, ob ich das mit meinen 5.5er Hosts auch noch reproduzieren kann.



EDIT: Hab den Thread doch nochmal gefunden ->https://communities.vmware.com/message/2239357#2239357

[stahly]

...
und sicher eine Woche nach einem Gespenst hinterher gejagt.
...

Das kenn ich

...
Der Outcome war seitens vmware -> Es sei ein Schönheitsfehler (Darstellungsfehler) der wohl mit der nächsten Release behoben sein sollte.
...

Das wäre schön! Da ich mitten in der Umstelllung von 5.0/5.1 auf 5.5 bin, warte ich mal ab. Vielleicht hat sich das Problem dann von alleine gelöst.

...
Hab den Thread doch nochmal gefunden ->https://communities.vmware.com/message/2239357#2239357

Muss ich mir in einer ruhigen Minute mal durchlesen. DANKE!

[kastlr]

Hallo zusammen,

falls es sich um BladeCenter Server handelt könnte das Problem auch innerhalb des BladeCenters liegen.

Wir hatten mal ein ähnliches Problem im 8GBit FC Umfeld und konnten unter Verwendung eines FC Analyzers nachweisen, das die Packete aus unserem SAN fehlerfrei an die BladeCenter SAN Ports geliefert worden sind.
Trotzdem meldeten ESX Server immer mal wieder Probleme beim Zugriff auf Ihre SAN Datastores.
Die Errorcounter an den SAN Switchen waren auch sauber, inklusive der Counter der SAN Switche in den BladeCentern.

Nachdem der Kunde die Best Pratices des Blade Herstellers für 8GBit FC umgesetzt hat, trat das Problem bei einer BC Modelreihe nicht mehr auf.
Bei der anderen vom Kunden eingesetzte BC Modelreihe hat der Hersteller dann auch noch Komponenten getauscht.

Im Rahmen der Fehlereingrenzung wurden auch mal die Positionen der Blades verändert, je nach verwendeter Slot Position trat das Problem häufiger auf oder verschwand ganz.
Allerdings wanderte es nie mit dem Blade mit.

Alles in allem war die ganze Sache extrem aufwändig, da am Anfang nur die externen Komponenten als Verursacher betrachtet worden sind.

Gruß,
Ralf

[blue_focus]

Ja sowas hatten wir bei unseren HP-Blades auch schon. Wir mussten dann nach HP BestPractice die Fillword Einstellungen an den SAN-Switchports ändern und... hat auch nix gebracht

Unser Problem war, dass neue Blades keinen FC-Login zusammengebracht hatten -> Status: "Not Logged In"

Schlussendlich hat es geholfen die FC Module vom Enclosure nach der Reihe zu resetten. Das hätte beim vorangegangenen FW-Upgrade gemacht werde sollen, wurde dann aber wohl vergessen.

----

Aber in dem oben genannten Problem geht es um keine SAN sondern LAN Probleme. Wir dachten damals auch es läge an der Bladeinfrastruktur (Stichwort Virtual Connect). Konnten dann das Problem aber auch bei den nicht Blade ESXn feststellen.
Wie in meinem Link beschrieben stand vor ca. 1 Jahr der Fix mit 5.1 U2 am Plan von VMWare.