Netzwerkprobleme Windows XP hoher Paketverlust
Hallo,
ich habe ein Problem mit einer Windows XP VM.
Die Netzwerkverbindung wird als Verbunden angezeigt, aber wenn ich einen anderen PC anpinge, werden ca. 50% der pings nicht zugestellt. Umgekehrt ist auch kein stabiler Zugriff auf die VM möglich. Bei allen andren VMs auf dem ESXi5 Server funktioniert das netzwerk einwandfrei.
An der WIndows XP VM wurde soweit feststellbar auch nichts verändert, was das Problem ausgelöst haben könnte. Das Xp ist aktuellem Patch-Level. Es ist nicht großartig installiert außer McAffe, MS Office 2007 und einer Software für unsere Stechuhr.
Bisher habe ich folgendes versucht:
- Ping 127.0.0.1 -> 100% OK!
- Ping 192.168.100.32 (eigene IP) -> 100% OK!
- Ping 192.168.100.234 (Switch Mnt. IP) -> min. 50% keine antwort
- Ping 192.168.100.5 (Server) -> -> min. 50% keine antwort
- Ping 192.168.100.124 (Andere VM auf gleichem ESXi) -> min. 50% keine antwort
- Netzwerkverbindung repariert
- VM-Ware Tools neu installiert
- Virtuelle Netzwerkkarte entfern und wieder hinzugefügt
- ARP Cache gelöscht
- McAffe Virenscanner deinstalliert -> keine Veränderung -> neuste Version installiert -> komplettscan -> keine entdeckungen.
- netsh interface ip delete arpcache
- Systemwiederherstellung auf ein Datum vor 10 Tagen, wo die Kiste definitiv noch einwandfrei funktionierte.
Alles kein Erfolg...
Irgendwelche Vorschläge / Ideen?
gruß!
ich habe ein Problem mit einer Windows XP VM.
Die Netzwerkverbindung wird als Verbunden angezeigt, aber wenn ich einen anderen PC anpinge, werden ca. 50% der pings nicht zugestellt. Umgekehrt ist auch kein stabiler Zugriff auf die VM möglich. Bei allen andren VMs auf dem ESXi5 Server funktioniert das netzwerk einwandfrei.
An der WIndows XP VM wurde soweit feststellbar auch nichts verändert, was das Problem ausgelöst haben könnte. Das Xp ist aktuellem Patch-Level. Es ist nicht großartig installiert außer McAffe, MS Office 2007 und einer Software für unsere Stechuhr.
Bisher habe ich folgendes versucht:
- Ping 127.0.0.1 -> 100% OK!
- Ping 192.168.100.32 (eigene IP) -> 100% OK!
- Ping 192.168.100.234 (Switch Mnt. IP) -> min. 50% keine antwort
- Ping 192.168.100.5 (Server) -> -> min. 50% keine antwort
- Ping 192.168.100.124 (Andere VM auf gleichem ESXi) -> min. 50% keine antwort
- Netzwerkverbindung repariert
- VM-Ware Tools neu installiert
- Virtuelle Netzwerkkarte entfern und wieder hinzugefügt
- ARP Cache gelöscht
- McAffe Virenscanner deinstalliert -> keine Veränderung -> neuste Version installiert -> komplettscan -> keine entdeckungen.
- netsh interface ip delete arpcache
- Systemwiederherstellung auf ein Datum vor 10 Tagen, wo die Kiste definitiv noch einwandfrei funktionierte.
Alles kein Erfolg...
Irgendwelche Vorschläge / Ideen?
gruß!
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 187078
Url: https://administrator.de/forum/netzwerkprobleme-windows-xp-hoher-paketverlust-187078.html
Ausgedruckt am: 15.05.2025 um 22:05 Uhr
8 Kommentare
Neuester Kommentar
Moin,
hm, ist die IP evtl. doppel vergeben?
Evtl. hillfts auch die vNIC aus der VM zu löschen eine neue (vorzugsweise VMXNET3) vNIC hinzuzufügen.
lg,
Slainte
hm, ist die IP evtl. doppel vergeben?
Evtl. hillfts auch die vNIC aus der VM zu löschen eine neue (vorzugsweise VMXNET3) vNIC hinzuzufügen.
lg,
Slainte
Danke für die schnelle Antowrt schon mal.
- IP Doppelt vergeben:
Wenn ich die VM herunterfahre, kann ich die IP gar nicht mehr anpingen. Also sollte sie nciht anderweitig in verwendung sein. Abgesehen davon tritt das Problem auch auf, wenn ich der VM eine andere IP gebe.
- vNIC gelöscht und eine neue mit VMXNET3 erstellt.
Per DHCP IP (192.168.100.145) bekommen. Wieder das gleiche Problem:
auf der VM:
U:\>ping 192.168.100.5
Ping wird ausgeführt für 192.168.100.5 mit 32 Bytes Daten:
Antwort von 192.168.100.5: Bytes=32 Zeit<1ms TTL=128
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Ping-Statistik für 192.168.100.5:
Pakete: Gesendet = 4, Empfangen = 1, Verloren = 3 (75% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms
auf 192.168.100.5:
U:\>ping 192.168.100.145 -t
Ping wird ausgeführt für 192.168.100.145 mit 32 Bytes Daten:
Antwort von 192.168.100.145: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.100.145: Bytes=32 Zeit<1ms TTL=128
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 192.168.100.145: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.100.145: Bytes=32 Zeit<1ms TTL=128
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
.
.
.
Zeitüberschreitung der Anforderung.
Ping-Statistik für 192.168.100.145:
Pakete: Gesendet = 22, Empfangen = 4, Verloren = 18 (81% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms
- IP Doppelt vergeben:
Wenn ich die VM herunterfahre, kann ich die IP gar nicht mehr anpingen. Also sollte sie nciht anderweitig in verwendung sein. Abgesehen davon tritt das Problem auch auf, wenn ich der VM eine andere IP gebe.
- vNIC gelöscht und eine neue mit VMXNET3 erstellt.
Per DHCP IP (192.168.100.145) bekommen. Wieder das gleiche Problem:
auf der VM:
U:\>ping 192.168.100.5
Ping wird ausgeführt für 192.168.100.5 mit 32 Bytes Daten:
Antwort von 192.168.100.5: Bytes=32 Zeit<1ms TTL=128
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Ping-Statistik für 192.168.100.5:
Pakete: Gesendet = 4, Empfangen = 1, Verloren = 3 (75% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms
auf 192.168.100.5:
U:\>ping 192.168.100.145 -t
Ping wird ausgeführt für 192.168.100.145 mit 32 Bytes Daten:
Antwort von 192.168.100.145: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.100.145: Bytes=32 Zeit<1ms TTL=128
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 192.168.100.145: Bytes=32 Zeit<1ms TTL=128
Antwort von 192.168.100.145: Bytes=32 Zeit<1ms TTL=128
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
.
.
.
Zeitüberschreitung der Anforderung.
Ping-Statistik für 192.168.100.145:
Pakete: Gesendet = 22, Empfangen = 4, Verloren = 18 (81% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms
Was mich stutzig macht ist der Ping an den Switch, die sollten alle sauber zurückkommen.
Ggf. mal rebooten (Switch) oder einen anderen Switch anhängen.
Try this!
greetz
ravers
P.S.: Wie sieht der Ping von einer VM zur XP-VM aus?
Ggf. mal rebooten (Switch) oder einen anderen Switch anhängen.
Try this!
greetz
ravers
P.S.: Wie sieht der Ping von einer VM zur XP-VM aus?
@Ravers
Danke für die schnelle antwort.
- Switch reboot ist gerade schlecht, weil dort noch viel mehr dran hängt. Allerdings kann ich von anderen VMs auf dem gleichen ESXI den Switch sauber anpingen.
- Ping von und zu anderer VM:
Gut das ichs nochmal versucht habe.
- Ping von .32 (XP-VM) zu .50 (Win7-VM) klappt zu 100%
- Ping von .50 (Win7-VM) zu .32 (XP-VM) klappt zu 100%
jetzt versteh ichs ehrlich gesagt noch weniger wie vorher..
Und: Wenn ich von der XP-Vm auf ein Netzwlaufwer auf meinem Server (.100.5) zugreife klappt das. und während ich da etwas tue, also browsen oder Dateien kopieren, geht auch der Ping durch. sobald ich damit aufhöre geht auch der Ping nicht mehr......
Danke für die schnelle antwort.
- Switch reboot ist gerade schlecht, weil dort noch viel mehr dran hängt. Allerdings kann ich von anderen VMs auf dem gleichen ESXI den Switch sauber anpingen.
- Ping von und zu anderer VM:
Gut das ichs nochmal versucht habe.
- Ping von .32 (XP-VM) zu .50 (Win7-VM) klappt zu 100%
- Ping von .50 (Win7-VM) zu .32 (XP-VM) klappt zu 100%
jetzt versteh ichs ehrlich gesagt noch weniger wie vorher..
Und: Wenn ich von der XP-Vm auf ein Netzwlaufwer auf meinem Server (.100.5) zugreife klappt das. und während ich da etwas tue, also browsen oder Dateien kopieren, geht auch der Ping durch. sobald ich damit aufhöre geht auch der Ping nicht mehr......
Wie sieht den deine Netzwerk-konfig auf dem ESXi aus? Haengen alle VMs auf dem gleichen vSwitch?
Mach doch mal auf einem Host, der sich nicht/schlecht pingen lässt ein
Mach doch mal auf einem Host, der sich nicht/schlecht pingen lässt ein
arp -a 192.168.100.145
Hi,
schau dir mal die Netzwerkkabel an, hier vielleicht mal im Schrank eingeklemmt o.ä. ?
Die Netzwerkkabel von der ESX mal auf einen anderen Switch klemmen und schaun, obs hilft.
Ansonsten fällt so`n kleiner Switch-Huster (reboot) auch nicht wirklich ins Gewicht.
Telefon 2 Minuten aus, Stecker raus, rein, fertig. Die Benutzer merken schon nach kurzer Zeit das alles wieder geht und rufen dich dann nicht mehr an.
Ansonsten halt nach Feierabend
Wie du merkst denke ich, das das Problem am Switch buw. Kabellage hängt.
Kannst du vielleicht auf dem Switch etwas ungewöhliches erkennen??
greetz
ravers
schau dir mal die Netzwerkkabel an, hier vielleicht mal im Schrank eingeklemmt o.ä. ?
Die Netzwerkkabel von der ESX mal auf einen anderen Switch klemmen und schaun, obs hilft.
Ansonsten fällt so`n kleiner Switch-Huster (reboot) auch nicht wirklich ins Gewicht.
Telefon 2 Minuten aus, Stecker raus, rein, fertig. Die Benutzer merken schon nach kurzer Zeit das alles wieder geht und rufen dich dann nicht mehr an.
Ansonsten halt nach Feierabend
Wie du merkst denke ich, das das Problem am Switch buw. Kabellage hängt.
Kannst du vielleicht auf dem Switch etwas ungewöhliches erkennen??
greetz
ravers
hm. es läuft jezt wieder.
ich habe die VM mit dem Converter von dem ESXi auf den gleichen ESXi konvertiert. IP wieder eingestellt und siehe da geht einwandfre.
Aber was das jetzt wirklich war - kein ahnung..
ich habe die VM mit dem Converter von dem ESXi auf den gleichen ESXi konvertiert. IP wieder eingestellt und siehe da geht einwandfre.
Aber was das jetzt wirklich war - kein ahnung..
Hallo!
Hast Du die vMAC doppelt vergeben?
Schau doch mal in den ARP-Tables von den Switchen nach, ob die MAC "wandert"...
Phil
Hast Du die vMAC doppelt vergeben?
Schau doch mal in den ARP-Tables von den Switchen nach, ob die MAC "wandert"...
Phil
