9
IP Adresskonflikt nach Reboot Windows Server 2003 R2
Ich habe eine VMware Maschine mit Windows Server 2003 R2 SP2. Diese habe ich neugestartet. Nach dem Reboot meldete mir Windows einen IP Adresskonflikt. Lt. Ereignisanzeige soll es sich um einen Adapter von Watchguard halten (anhand der MAC Adresse) Die Mac Adresse, die dort angezeigt wird, ist auch die MAC des internen Interfaces unserer Watchguard.
Dieses Interface hat aber nicht die IP die der Server hat. Also ist die Meldung in meinen Augen Quatsch.
Stelle ich die IP des Server auf eine sonstige freie IP, funktioniert alles. Stelle ich wieder zurück, bekomme ich wieder die Konflikt Meldung.
Ich hab mal prophylaktisch DNS Cache und ARP Cache gelöscht, ohne Erfolg. In der Arp Tabelle sind die MACs auch richtig. Also Die IPs passen auch zu den MACs.
Was kann denn noch den Konflikt auslösen? [verzweifeltumhilferuf]
Danke im Voraus
Gruß
Michael
Dieses Interface hat aber nicht die IP die der Server hat. Also ist die Meldung in meinen Augen Quatsch.
Stelle ich die IP des Server auf eine sonstige freie IP, funktioniert alles. Stelle ich wieder zurück, bekomme ich wieder die Konflikt Meldung.
Ich hab mal prophylaktisch DNS Cache und ARP Cache gelöscht, ohne Erfolg. In der Arp Tabelle sind die MACs auch richtig. Also Die IPs passen auch zu den MACs.
Was kann denn noch den Konflikt auslösen? [verzweifeltumhilferuf]
Danke im Voraus
Gruß
Michael
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 152861
Url: https://administrator.de/contentid/152861
Printed on: April 18, 2024 at 03:04 o'clock
9 Comments
Latest comment
Salü,
was ist das denn für eine Maschine?
Du mußt schon genau sein, wenn du eine genaue Antwort haben möchtest.
Gruß
was ist das denn für eine Maschine?
- selbstgezimmert?
- p2v?
Stelle ich wieder zurück, bekomme ich wieder die Konflikt Meldung.
Auf was denn?Du mußt schon genau sein, wenn du eine genaue Antwort haben möchtest.
Gruß
Hallo,
also eine Watchguard Edge hat als Default-Network auf dem Trustet Interface die 192.168.111.0
Und die VMware (zumindest meine Workstation die ich hier habe) benutzt auf dem NAT-Interface ebenfalls die 192.168.111.0.
Es ist also gut möglich, dass du dort einen Konfilkt hast.
Vielleicht solltest du im Network Editor der VMWARE das Nat-Interface auf eine andere Netzwerk-ID mal legen.
Gruß
Torsten
also eine Watchguard Edge hat als Default-Network auf dem Trustet Interface die 192.168.111.0
Und die VMware (zumindest meine Workstation die ich hier habe) benutzt auf dem NAT-Interface ebenfalls die 192.168.111.0.
Es ist also gut möglich, dass du dort einen Konfilkt hast.
Vielleicht solltest du im Network Editor der VMWARE das Nat-Interface auf eine andere Netzwerk-ID mal legen.
Gruß
Torsten
Erstmal vielen Dank für die Antwort.
Die VM ist selbstgebastelt und läuft auch schon seit bestimmt 3 -43 Monaten ohne jegliche Probleme. Die wurde seither auch schon mehrmals neu gestartet (z.B. nach Patchday)
Nochmals zur Erklärung:
Die Maschine hat die IP 192.168.100.40. Ich habe testweise auf 192.168.100.41 umgestellt. Damit funktioniert es ohne Konflikt. Danach wieder zurückgestellt auf 192.168.100.40. Da taucht der Konflikt wieder auf und lt. Ereignisanzeige mit dem internen Interface der Firewall, was aber nicht sein kann, denn dieses hat die IP 192.168.100.22
Dass ist leider nicht immer so einfach. Da ich keine Idee mehr habe woran es noch liegen könnte, weiß ich auch nicht welche Details noch wichtig sein könnten. Ich hab mich schon bemühr so detailiert wie möglich mein Problem zu beschreiben.
P.S.: ein "netsh int ip reset" hab ich auch schon durchgeführt um Probleme mit dem IP Stack auszuschließen.
P.S.: es handelt sich um einen VWare ESXi 4.1 Server
P.S.: wenn ich die IP auf 192.168.100.41 umstelle und von einem anderen Rechner aus die 40 anpinge kommt kein response...
Gruß
Michael
Die VM ist selbstgebastelt und läuft auch schon seit bestimmt 3 -43 Monaten ohne jegliche Probleme. Die wurde seither auch schon mehrmals neu gestartet (z.B. nach Patchday)
Nochmals zur Erklärung:
Die Maschine hat die IP 192.168.100.40. Ich habe testweise auf 192.168.100.41 umgestellt. Damit funktioniert es ohne Konflikt. Danach wieder zurückgestellt auf 192.168.100.40. Da taucht der Konflikt wieder auf und lt. Ereignisanzeige mit dem internen Interface der Firewall, was aber nicht sein kann, denn dieses hat die IP 192.168.100.22
Du mußt schon genau sein, wenn du eine genaue Antwort haben möchtest.
Dass ist leider nicht immer so einfach. Da ich keine Idee mehr habe woran es noch liegen könnte, weiß ich auch nicht welche Details noch wichtig sein könnten. Ich hab mich schon bemühr so detailiert wie möglich mein Problem zu beschreiben.
P.S.: ein "netsh int ip reset" hab ich auch schon durchgeführt um Probleme mit dem IP Stack auszuschließen.
P.S.: es handelt sich um einen VWare ESXi 4.1 Server
P.S.: wenn ich die IP auf 192.168.100.41 umstelle und von einem anderen Rechner aus die 40 anpinge kommt kein response...
Gruß
Michael
Hier mal noch zwei Screenshots. Der Eine vom Watchguard Interface, der andere von der Ereignisanzeige des Servers:
http://andreabeck.org/bilder/Watchguard.jpg
http://andreabeck.org/bilder/Win2003.jpg
http://andreabeck.org/bilder/Watchguard.jpg
http://andreabeck.org/bilder/Win2003.jpg
Hallo,
liegt da evtl. noch ein Switch zwischen?
Wir hatten einmal ein ähnliches Problem, bei dem das Problem behoben wurde, indem ich ein Switch neu gestartet habe.
Bei dem Switch wird bei einem Neustart der Cache gellert und komplett neu aufgebaut.
Nur mal so als Anregung...
Gruß
Mike
liegt da evtl. noch ein Switch zwischen?
Wir hatten einmal ein ähnliches Problem, bei dem das Problem behoben wurde, indem ich ein Switch neu gestartet habe.
Bei dem Switch wird bei einem Neustart der Cache gellert und komplett neu aufgebaut.
Nur mal so als Anregung...
Gruß
Mike
Ja, die Idee hatte ich auch schon. Der VMWare Server hängt allerdings an einem 48 Port vollbelegten Switch. Mal sehen, wann ich den mal abschalten kann.
Danke aber trotzdem für die Anregung!
Seltsam finde ich aber, dass es erst nach dem Reboot des Servers auftrat. Es fand ja bis dahin kein IP Adress Austausch oder der gleichen statt!? Der Server hatte also vor dem Reboot die 40 und nach dem Reboot meldet er mir den Konflikt.
Gruß
Michael
Danke aber trotzdem für die Anregung!
Seltsam finde ich aber, dass es erst nach dem Reboot des Servers auftrat. Es fand ja bis dahin kein IP Adress Austausch oder der gleichen statt!? Der Server hatte also vor dem Reboot die 40 und nach dem Reboot meldet er mir den Konflikt.
Gruß
Michael
Tagchen,
hmm...
also grundlegend würde ich mal darauf schließen, dass ein ping auf deine 40 (wenn dein Server die 41 hat) nicht unbedingt etwas zu sagen hat...
Eine fehlende Antwort auf einen Ping kann ja auch bedeuten, dass das Endgerät Ping-Anfragen ignoriert ;)
versuch doch mal via HTTP / HTTPS auf die 40 zu gehen.
In der Vergangenheit hatte ich hier ähnliche Probleme: IP-Telefon antwortete nicht, aber die Weboberfläche ging ;)
gruß
meistro
hmm...
also grundlegend würde ich mal darauf schließen, dass ein ping auf deine 40 (wenn dein Server die 41 hat) nicht unbedingt etwas zu sagen hat...
Eine fehlende Antwort auf einen Ping kann ja auch bedeuten, dass das Endgerät Ping-Anfragen ignoriert ;)
versuch doch mal via HTTP / HTTPS auf die 40 zu gehen.
In der Vergangenheit hatte ich hier ähnliche Probleme: IP-Telefon antwortete nicht, aber die Weboberfläche ging ;)
gruß
meistro
Danke auch für diesen Rat. Wenn die IP tatsächlich die Watchguard haben soll, könnte ich sie auch anpingen. Also das interne Interface ist temporär zumindest erreichbar. Trotzdem hab ich mal deinen Rat befolgt und http bzw https geprüft Leider ohne Ergebnis, weder auf Port 80 noch auf sonstigen "Sonderports" die für gewöhnlich für Webinterface genutzt werden (8080, 8000 etc)
Sch*
Gruß
Michael
Edit: Ich hab jetzt mal einen anderen Client die 40 gegeben und der bekommt auch einen Konflikt gemeldet. OK, einen Schritt weiter. Es liegt nicht an dem Server. Warum es allerdings erst nach dem Reboot auftrat entschließt sich mir noch völlig. Da müsste ja zumindest irgendein anderes Gerät vorher schon gemeckert haben!?
Sch*
Gruß
Michael
Edit: Ich hab jetzt mal einen anderen Client die 40 gegeben und der bekommt auch einen Konflikt gemeldet. OK, einen Schritt weiter. Es liegt nicht an dem Server. Warum es allerdings erst nach dem Reboot auftrat entschließt sich mir noch völlig. Da müsste ja zumindest irgendein anderes Gerät vorher schon gemeckert haben!?
So, gelöst. Ich habe jetzt einfach mal Kraft meiner Wassersuppe die Firewall neugestartet. Und siehe da, ich kann die 40 wieder vergeben ohne Konflikt. So wirklich verstanden habe ich das immernoch nicht.
btw: Erstaunlich wieviele Leute die Firewall nutzen. Schließlich dauert der Reboot nur wenige Minuten. Und da kamen schon drei Anrufe, dass einer der drei BOVPN nicht mehr funktioniert
Herrlich, ein bisschen das Gefühl des BOfH zu haben
DANKE nochmals an Alle!!!!
Gruß
Michael
btw: Erstaunlich wieviele Leute die Firewall nutzen. Schließlich dauert der Reboot nur wenige Minuten. Und da kamen schon drei Anrufe, dass einer der drei BOVPN nicht mehr funktioniert
Herrlich, ein bisschen das Gefühl des BOfH zu haben
DANKE nochmals an Alle!!!!
Gruß
Michael
