16
Keine Kommunikation auf allen TCP IP Verbindungen
Hallo Leute,
Ich bin neu hier und möchte Euch gleich mit einem Problem behelligen, dass mich schon seit geraumer Zeit plagt
Ich habe seit längerer Zeit ein Problem auf W2K3 Servern (HP DL380 G4) mit folgender Konfiguration.
W2K3 SP1 + aktuelle Patches
WinCC 6.0 SP4
Simatic SNMP OPC Server 6.4
Office 2003
2 x Onboard NIC 1Gbit
Server Mitglied einer Domäne (damit wird nur der Corporate Security Rechnung getragen)
Benutzer Anmeldung erfolgt nur mit lokaler Kontierung (aus kompatibilitätsgründen mit WinCC).
Problem:
Die Server laufen ca. 1,5 Monate anstandslos bis auf einmal keine TCP IP Verbindung mehr möglich ist.
Die Maschine ist weder von aussen erreichbar, noch kann die Maschine einen Ping auf ihre eigenen Adressen ausführen.
Ein Hardware Problem ist komplett auszuschliessen, da dass Problem zeitgleich auf beiden Adaptern auftritt und nach einem
Reboot alles wieder in Ordnung ist. Kennt jemand einen Grund der zu solch einem Verhalten führen kann?
Das Ereignisprotokoll ist lediglich voll mit Meldungen, die ein Resultat dieses Ausfalls sind. Es deutet allerdings nichts auf die Ursache hin.
Ich vermute das WinSOCK aus irgendeinem Grund keine freien Ressourcen mehr hat ? Wenn ja wie ließe sich das zweifelsfrei diagnostizieren?
Vielen Dank schon mal Vorraus
DAU-JONES
Ich bin neu hier und möchte Euch gleich mit einem Problem behelligen, dass mich schon seit geraumer Zeit plagt
Ich habe seit längerer Zeit ein Problem auf W2K3 Servern (HP DL380 G4) mit folgender Konfiguration.
W2K3 SP1 + aktuelle Patches
WinCC 6.0 SP4
Simatic SNMP OPC Server 6.4
Office 2003
2 x Onboard NIC 1Gbit
Server Mitglied einer Domäne (damit wird nur der Corporate Security Rechnung getragen)
Benutzer Anmeldung erfolgt nur mit lokaler Kontierung (aus kompatibilitätsgründen mit WinCC).
Problem:
Die Server laufen ca. 1,5 Monate anstandslos bis auf einmal keine TCP IP Verbindung mehr möglich ist.
Die Maschine ist weder von aussen erreichbar, noch kann die Maschine einen Ping auf ihre eigenen Adressen ausführen.
Ein Hardware Problem ist komplett auszuschliessen, da dass Problem zeitgleich auf beiden Adaptern auftritt und nach einem
Reboot alles wieder in Ordnung ist. Kennt jemand einen Grund der zu solch einem Verhalten führen kann?
Das Ereignisprotokoll ist lediglich voll mit Meldungen, die ein Resultat dieses Ausfalls sind. Es deutet allerdings nichts auf die Ursache hin.
Ich vermute das WinSOCK aus irgendeinem Grund keine freien Ressourcen mehr hat ? Wenn ja wie ließe sich das zweifelsfrei diagnostizieren?
Vielen Dank schon mal Vorraus
DAU-JONES
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 131649
Url: https://administrator.de/contentid/131649
Ausgedruckt am: 22.11.2024 um 14:11 Uhr
16 Kommentare
Neuester Kommentar
Hallo Dau-Jones,
hast Du es schon mal mit "netstat -a" auf der DOS-Eingabeaufforderung probiert?
Es zeigt Dir den Status der Netzwerkverbindungen an...
Gruß Roger
hast Du es schon mal mit "netstat -a" auf der DOS-Eingabeaufforderung probiert?
Es zeigt Dir den Status der Netzwerkverbindungen an...
Gruß Roger
Neustes Treiber direkt vom Chipsatzhersteller der verwendeten Netzwerkchips hast du installiert ??
Was sagt HP dazu (Hotline Support) ??
Was sagt HP dazu (Hotline Support) ??
Moin,
schon mal mit net config server geschaut, ob autodisconnect zu niederig eingestellt ist? Habe irgendwo gelesen, dass es einen Wert für autodisconnect = niemals gibt.
Ansonsten habe ich mal Netzwerkkarten erlebt, denen es erlaubt war, sich abzuschalten, um Strom zu sparen.
Gruß
Hügel
schon mal mit net config server geschaut, ob autodisconnect zu niederig eingestellt ist? Habe irgendwo gelesen, dass es einen Wert für autodisconnect = niemals gibt.
Ansonsten habe ich mal Netzwerkkarten erlebt, denen es erlaubt war, sich abzuschalten, um Strom zu sparen.
Gruß
Hügel
hast Du es schon mal mit "netstat -a" auf der DOS-Eingabeaufforderung probiert?
Es zeigt Dir den Status der Netzwerkverbindungen an...
Es zeigt Dir den Status der Netzwerkverbindungen an...
netstat -a = sieht alles normal aus (nur listenings)
netstat -a -n -b = nichts ungewöhnliches (nur listenings)
netsh diag gui = alles ok bis auf die Ping Anforderungen (ist ja auch logisch bei dem Problem)
route print = liefert auch nichts ungewöhnliches
TCPView = alles ok
msinfo32 \ komponenten \ netzwerk = nichts ungewöhnliches
Prüfung ob alle Protokolle korrekt installiert sind = ok
Gerätemanager = alles ok
Dienste = alles ok
HP Insight Diagnosis = alles OK (aus diesem Grund habe ich auch bis jetzt noch nicht den HP Support kontaktiert ).
Netzwerkkarteneinstellungen = NIC Powersafe deaktiviert
Firewall ausgeschaltet
Ich vergaß zu erwähnen, dass die beiden Netzwerkadapter onboard sind. INTEL 1000 Pro
Somit mag ich ein Treiber Problem nicht gänzlich ausschließen wollen. Ein Treiber update ist leider keine Option, da die installierte Software (WinCC von Siemens) eben nur mit diesem Treiber getestet und freigegeben wurde.
ping auf ip NIC1 = zielhost nicht erreichbar
ping auf ip NIC2 = zielhost nicht erreichbar
ping auf Loopback = zielhost nicht erreichbar !!!
Was mir allerdings auffiel ist die Tatsache, dass ich mir über die Symbole der Netzwerkarten im Tray zwar die aktuelle Konfiguration anzeigen lassen kann, jedoch ist es nicht möglich einen Adapter zu deaktivieren und danach wieder zu aktivieren.
Ich hoffe das sind genug Infos
Gruß Roger
Die Karten dürfen kein Powermanagement betreiben. Sind auch so konfiguriert.
autodisconnect ist mir jetzt neu muss ich mal testen. Aber lass mich raten. Die Einstellung erfordert einen Reboot oder? D.h. dass ich das Ergebnis erst in 1 - 2 Monaten sehe wenn das Problem wieder auftritt oder eben ausbleibt.
Das will ich vermeiden. Die Server arbeiten Im Redundanzbetrieb (WinCC) wodurch ich derzeit den Ausfall des einen verschmerzen kann. Deshalb möchte ich den aktuellen Status so lange wie möglich konservieren um das Problem soweit wie möglich einzukreisen.
Gruß
DAU-JONES
autodisconnect ist mir jetzt neu muss ich mal testen. Aber lass mich raten. Die Einstellung erfordert einen Reboot oder? D.h. dass ich das Ergebnis erst in 1 - 2 Monaten sehe wenn das Problem wieder auftritt oder eben ausbleibt.
Das will ich vermeiden. Die Server arbeiten Im Redundanzbetrieb (WinCC) wodurch ich derzeit den Ausfall des einen verschmerzen kann. Deshalb möchte ich den aktuellen Status so lange wie möglich konservieren um das Problem soweit wie möglich einzukreisen.
Gruß
DAU-JONES
Hi DAU :-}
Nee, net config erfordert keinen Neustart.
Nee, net config erfordert keinen Neustart.
Hallo Huegel
Ich werde es mal versuchen, jedoch macht mir der Technet Artikel http://support.microsoft.com/kb/138365/de
weniger Mut. Autodisconnect greift ja nur bei bei idle connections. Das auf dem Server auch nur eine Verbindung weniger als 1 mal in einer Minute benutzt wird halte ich für unwahrscheinlich. Ich werde den Wert morgen mal auslesen und ggf anpassen.
regards
DAU-JONES
Ich werde es mal versuchen, jedoch macht mir der Technet Artikel http://support.microsoft.com/kb/138365/de
weniger Mut. Autodisconnect greift ja nur bei bei idle connections. Das auf dem Server auch nur eine Verbindung weniger als 1 mal in einer Minute benutzt wird halte ich für unwahrscheinlich. Ich werde den Wert morgen mal auslesen und ggf anpassen.
regards
DAU-JONES
Hallo Dau-Jones,
Ein,zwei Punkte finde ich schon "komisch"...
netstat und keine "127.0.0.1-Verbindungen hergestellt" Hmmm...
Zur Fehlersuche gehe ich normalerweise erst mal hin und pinge auf 127.0.0.1, dann auf die eigene IP, IP des Gateway, IP des DNS, Ping auf den eigenen Namen...
Du hast oben geschrieben "...auf Servern..." Mehrzahl, passiert das auf allen Maschinen? Dann ist mir aufgefallen, daß es wohl am Anfang funktioniert und erst mit der Zeit plötzlich "steht"...
Der Umstand, daß Du Dir zwar die Konfiguration anzeigen lassen kannst, aber nichts dran ändern, kenne ich nur wenn Dir die Rechte daran fehlen, was zu ändern.
Hypothetisch, Du würdest den Rechner neu starten und Du würdest die Standard-Ping-Tests machen, würde dann alles funktionieren?
Das führt mich zu der Vermutung, daß die IP und die Protokolle und die Netzwerkadapter korrekt aneinander gebunden werden. Da fällt mir dann eine neue Frage ein... Woher bekommt er seine IP? DHCP? Vielleicht läuft da der DHCP-LEASE ab, und die Karten machen keinen Release um einen neuen zu bekommen. Das würde passen, die Karten denken sie hätten noch die IP, zeigen dies auch an, aber die Gegenstelle nimmt nichts an, weil die IP offiziell nicht vergeben ist?!
Das wäre zumindest mal einen Versuch wert, nachzusehen...
Gruß Roger
netstat -a = sieht alles normal aus (nur listenings)
netstat -a -n -b = nichts ungewöhnliches (nur listenings)
route print = liefert auch nichts ungewöhnliches
ping auf ip NIC1 = zielhost nicht erreichbar
ping auf ip NIC2 = zielhost nicht erreichbar
ping auf Loopback = zielhost nicht erreichbar !!!
Was mir allerdings auffiel ist die Tatsache, dass ich mir über die Symbole der Netzwerkarten im Tray zwar die aktuelle
Konfiguration anzeigen lassen kann, jedoch ist es nicht möglich einen Adapter zu deaktivieren und danach wieder zu
aktivieren.
netstat -a -n -b = nichts ungewöhnliches (nur listenings)
route print = liefert auch nichts ungewöhnliches
ping auf ip NIC1 = zielhost nicht erreichbar
ping auf ip NIC2 = zielhost nicht erreichbar
ping auf Loopback = zielhost nicht erreichbar !!!
Was mir allerdings auffiel ist die Tatsache, dass ich mir über die Symbole der Netzwerkarten im Tray zwar die aktuelle
Konfiguration anzeigen lassen kann, jedoch ist es nicht möglich einen Adapter zu deaktivieren und danach wieder zu
aktivieren.
Ein,zwei Punkte finde ich schon "komisch"...
netstat und keine "127.0.0.1-Verbindungen hergestellt" Hmmm...
Zur Fehlersuche gehe ich normalerweise erst mal hin und pinge auf 127.0.0.1, dann auf die eigene IP, IP des Gateway, IP des DNS, Ping auf den eigenen Namen...
Du hast oben geschrieben "...auf Servern..." Mehrzahl, passiert das auf allen Maschinen? Dann ist mir aufgefallen, daß es wohl am Anfang funktioniert und erst mit der Zeit plötzlich "steht"...
Der Umstand, daß Du Dir zwar die Konfiguration anzeigen lassen kannst, aber nichts dran ändern, kenne ich nur wenn Dir die Rechte daran fehlen, was zu ändern.
Hypothetisch, Du würdest den Rechner neu starten und Du würdest die Standard-Ping-Tests machen, würde dann alles funktionieren?
Das führt mich zu der Vermutung, daß die IP und die Protokolle und die Netzwerkadapter korrekt aneinander gebunden werden. Da fällt mir dann eine neue Frage ein... Woher bekommt er seine IP? DHCP? Vielleicht läuft da der DHCP-LEASE ab, und die Karten machen keinen Release um einen neuen zu bekommen. Das würde passen, die Karten denken sie hätten noch die IP, zeigen dies auch an, aber die Gegenstelle nimmt nichts an, weil die IP offiziell nicht vergeben ist?!
Das wäre zumindest mal einen Versuch wert, nachzusehen...
Gruß Roger
Ein,zwei Punkte finde ich schon "komisch"...
netstat und keine "127.0.0.1-Verbindungen hergestellt" Hmmm...
Zur Fehlersuche gehe ich normalerweise erst mal hin und pinge auf 127.0.0.1, dann auf die eigene IP, IP des Gateway, IP des DNS,
Ping auf den eigenen Namen...
netstat und keine "127.0.0.1-Verbindungen hergestellt" Hmmm...
Zur Fehlersuche gehe ich normalerweise erst mal hin und pinge auf 127.0.0.1, dann auf die eigene IP, IP des Gateway, IP des DNS,
Ping auf den eigenen Namen...
Jeder Ping läuft ins Leere
Du hast oben geschrieben "...auf Servern..." Mehrzahl, passiert das auf allen Maschinen? >Dann ist mir aufgefallen,
daß es wohl am Anfang funktioniert und erst mit der Zeit plötzlich "steht"...
daß es wohl am Anfang funktioniert und erst mit der Zeit plötzlich "steht"...
Korrekt, nach einem Neustart einer Maschine ist dort wieder alles in Ordnung, bis eben nach ca 1 bis 2 Monaten wieder die ganze Kommunikation steht. Manchmal, je nachdem wie schnell das Problem auffällt (die Maschinen laufen ja als Redundanzpaar) gibt es zu dem geschilderten Problem noch ein weiteres. Die Prozessliste im Taskmanager hat keine Benutzer mehr für die Prozesse zugewiesen. In diesem Fall kann die Kiste nur noch hart ausgeschaltet werden, da ich dann keine Berechtigungen mehr zum herunterfahren habe.
Der Umstand, daß Du Dir zwar die Konfiguration anzeigen lassen kannst, aber nichts dran > > ändern, kenne ich nur wenn Dir
die Rechte daran fehlen, was zu ändern.
Hypothetisch, Du würdest den Rechner neu starten und Du würdest die Standard-Ping-Tests > machen, würde dann alles
funktionieren?
die Rechte daran fehlen, was zu ändern.
Hypothetisch, Du würdest den Rechner neu starten und Du würdest die Standard-Ping-Tests > machen, würde dann alles
funktionieren?
Ja, aber das ist ja das blöde, nach einem Reboot beraube ich mich der Möglichkeit das Problem tiefer zu analysieren.
Das führt mich zu der Vermutung, daß die IP und die Protokolle und die Netzwerkadapter > > > korrekt aneinander gebunden
werden. Da fällt mir dann eine neue Frage ein... Woher bekommt er seine IP? DHCP? >
Vielleicht läuft da der DHCP-LEASE ab,
und die Karten machen keinen Release um einen neuen zu bekommen. Das würde passen, > die Karten denken sie hätten noch die
IP, zeigen dies auch an, aber die Gegenstelle nimmt nichts an, weil die IP offiziell nicht
vergeben ist?!
Das wäre zumindest mal einen Versuch wert, nachzusehen...
werden. Da fällt mir dann eine neue Frage ein... Woher bekommt er seine IP? DHCP? >
Vielleicht läuft da der DHCP-LEASE ab,
und die Karten machen keinen Release um einen neuen zu bekommen. Das würde passen, > die Karten denken sie hätten noch die
IP, zeigen dies auch an, aber die Gegenstelle nimmt nichts an, weil die IP offiziell nicht
vergeben ist?!
Das wäre zumindest mal einen Versuch wert, nachzusehen...
Alles statisch, DHCP ist in diesem Umfeld (WinCC Server) auch gar nicht gestattet. DNS ist richtig eingetragen Gateway auch.
Bzgl Sicherheit, kann ich nur sagen dass ich hier gemäß den Vorgaben der Corporate Security arbeite und somit den aktuellsten Virenscanner inklusive Definitionen habe. Ein Full Scan fördert auch nichts zu Tage.
Gruß
DAU-JONES
Wert stand auf 15, habe es jetzt mit -1 deaktiviert
Gruß DAU-JONES
Gruß DAU-JONES
Hallo Dau-Jones,
Da sieht es mit den Ideen jetzt schon schlecht aus.
Wie würde ich weiterweitermachen. Ich würde versuchen, eine kleine Batch zu schreiben, die alle X-Minuten einen Rechner pingt und falls das nicht klappt, irgendwas macht, damit ich das sofort merke bzw. ich es an einem Datum/Uhrzeit festmachen kann (Fester Wert oder variabel). Vielleicht sogar in eine Datei Konfig-Infos (ipconfig /all; route print) mit reinschieben um zu sehen was sich ändert.
Mit netsh lassen sich doch die Adapter-Konfigs ändern, läßt er das mit sich machen..?
Gruß Roger
Jeder Ping läuft ins Leere
Also 4 Pakets send -4 Pakets lostJa, aber das ist ja das blöde, nach einem Reboot beraube ich mich der Möglichkeit das Problem tiefer zu analysieren.
Normal sollten im Ereignislog keine roten Punkte auftauchen, was gibt er denn da was brauchbares von sich?> Das führt mich zu der Vermutung, daß die IP und die Protokolle und die Netzwerkadapter korrekt aneinander gebunden
> werden....
Und die Verbindung verliert er, selbst auf dem Loopback. Und die Prozesse haben keine Benutzerkennung mehr...> werden....
Alles statisch, DHCP ist in diesem Umfeld (WinCC Server) auch gar nicht gestattet.
Also fällt das mit dem DHCP-Lease auch aus... Hmmm...Da sieht es mit den Ideen jetzt schon schlecht aus.
Wie würde ich weiterweitermachen. Ich würde versuchen, eine kleine Batch zu schreiben, die alle X-Minuten einen Rechner pingt und falls das nicht klappt, irgendwas macht, damit ich das sofort merke bzw. ich es an einem Datum/Uhrzeit festmachen kann (Fester Wert oder variabel). Vielleicht sogar in eine Datei Konfig-Infos (ipconfig /all; route print) mit reinschieben um zu sehen was sich ändert.
Mit netsh lassen sich doch die Adapter-Konfigs ändern, läßt er das mit sich machen..?
Gruß Roger
Normal sollten im Ereignislog keine roten Punkte auftauchen, was gibt er denn da was brauchbares
von sich?
Also fällt das mit dem DHCP-Lease auch aus... Hmmm...
Da sieht es mit den Ideen jetzt schon schlecht aus.
Wie würde ich weiterweitermachen. Ich würde versuchen, eine kleine Batch zu schreiben, die alle X-Minuten einen Rechner
pingt und falls das nicht klappt, irgendwas macht, damit ich das sofort merke bzw. ich es an einem Datum/Uhrzeit festmachen kann
(Fester Wert oder variabel). Vielleicht sogar in eine Datei Konfig-Infos (ipconfig /all; route print) mit reinschieben um zu sehen
was sich ändert.
Mit netsh lassen sich doch die Adapter-Konfigs ändern, läßt er das mit sich machen..?
von sich?
Also fällt das mit dem DHCP-Lease auch aus... Hmmm...
Da sieht es mit den Ideen jetzt schon schlecht aus.
Wie würde ich weiterweitermachen. Ich würde versuchen, eine kleine Batch zu schreiben, die alle X-Minuten einen Rechner
pingt und falls das nicht klappt, irgendwas macht, damit ich das sofort merke bzw. ich es an einem Datum/Uhrzeit festmachen kann
(Fester Wert oder variabel). Vielleicht sogar in eine Datei Konfig-Infos (ipconfig /all; route print) mit reinschieben um zu sehen
was sich ändert.
Mit netsh lassen sich doch die Adapter-Konfigs ändern, läßt er das mit sich machen..?
Natürlich habe ich Fehlereinträge. Z.B USERENV mit der Meldung dass der Domänencontroller nicht erreichbar ist. DCOM mit mit der Meldung kein Zugriff auf.... . Aber all diese Einträge sind logische Konsequenzen meines Problems. Ich habe auf den Servern in den WinCC Projekten eine Menge zyklischer Scripte laufen, die via WMI Prozesse , handles , threads und allen möglichen Quatsch den ich zur analyse als sinnvoll erachtet habe, mitloggen und in eine Datenbank schreiben.
Zudem habe ich einen SNMP OPC konfiguriert um alle Maschinen mit denen ich kommuniziere (ca. 30) im 5 Sekunden Zyklus überwache. Diese Werte laufen auch in eine Datenbank zur Analyse.
Ich kann also bis auf 5 Sekunden genau sagen, wann das Problem auftrat. Aber es gibt keinen einzigen Eintrag vor dem Problem, der ein wenig Licht ins Dunkel bringen könnte. Alle Einträge die ich finden kann sind ein Resultat meines Problems.
Jetzt könnte ich natürlich hingehen und die Maschinen einfach neustarten sobald ich bemerke, das etwas nicht stimmt. Dies ist allerdings keine Lösung und somit extrem unbefriedigend. Zum Zweiten verhält es sich mit WinCC Redundanzserven etwas anders. Diese Maschinen stellen Die Schnittstelle Zwischen Produktionsanlage und Mensch dar. Die kann man nicht mal ebenso rebooten ohne Gefahr zu laufen den Produktionablauf empfindlich zu stören.
Gruß
DAU-JONES
Hallo Dau-Jones,
Bis auf 5 Sek genau, das hört sich brauchbar an, mein Gedanke war dabei, rauszufinden ob es ein Wert (Timeout, x-Verbindungen,...) auf der Maschine selbst ist, der es auslöst, oder ob es von außen bewirkt wird. Wenn es ein fester zyklich wiederkehrender Vorfall ist, dann vielleicht mit Wireshark die Netzwerk-Pakete überwachen, und/oder RegMon die Zugriffe auf die Registry mitloggen. Nur fallen da enorme Datenmengen an, sodaß man wenige Minuten bevor das passiert die Programme startet. Wenn man das also an einem Wert festmachen könnte, könnte man die Registry danach durchsuchen.
Das sehe ich 100% genauso!
Verstehe...
Deswegen auch die Redundanz, aber wenn die eine Maschine eh nicht mehr geht mußt Du sie ja doch neu booten dachte ich.
Auf jeden Fall denke ich weiter drüber nach...
Gruß Roger
Bis auf 5 Sek genau, das hört sich brauchbar an, mein Gedanke war dabei, rauszufinden ob es ein Wert (Timeout, x-Verbindungen,...) auf der Maschine selbst ist, der es auslöst, oder ob es von außen bewirkt wird. Wenn es ein fester zyklich wiederkehrender Vorfall ist, dann vielleicht mit Wireshark die Netzwerk-Pakete überwachen, und/oder RegMon die Zugriffe auf die Registry mitloggen. Nur fallen da enorme Datenmengen an, sodaß man wenige Minuten bevor das passiert die Programme startet. Wenn man das also an einem Wert festmachen könnte, könnte man die Registry danach durchsuchen.
Jetzt könnte ich natürlich hingehen und die Maschinen einfach neustarten sobald ich bemerke, das etwas nicht stimmt.
Dies ist allerdings keine Lösung und somit extrem unbefriedigend.
Dies ist allerdings keine Lösung und somit extrem unbefriedigend.
Das sehe ich 100% genauso!
Zum Zweiten verhält es sich mit WinCC Redundanzserven
etwas anders. Diese Maschinen stellen Die Schnittstelle Zwischen Produktionsanlage und Mensch dar. Die kann man nicht mal eben > so rebooten ohne Gefahr zu laufen den Produktionablauf empfindlich zu stören.
etwas anders. Diese Maschinen stellen Die Schnittstelle Zwischen Produktionsanlage und Mensch dar. Die kann man nicht mal eben > so rebooten ohne Gefahr zu laufen den Produktionablauf empfindlich zu stören.
Verstehe...
Deswegen auch die Redundanz, aber wenn die eine Maschine eh nicht mehr geht mußt Du sie ja doch neu booten dachte ich.
Auf jeden Fall denke ich weiter drüber nach...
Gruß Roger
zyklich wiederkehrender Vorfall ist, dann vielleicht mit Wireshark die Netzwerk-Pakete überwachen, und/oder RegMon die
Zugriffe auf die Registry mitloggen. Nur fallen da enorme Datenmengen an, sodaß man wenige Minuten bevor das passiert die
Programme startet. Wenn man das also an einem Wert festmachen könnte, könnte man die Registry danach durchsuchen.
Zugriffe auf die Registry mitloggen. Nur fallen da enorme Datenmengen an, sodaß man wenige Minuten bevor das passiert die
Programme startet. Wenn man das also an einem Wert festmachen könnte, könnte man die Registry danach durchsuchen.
Das Problem dabei ist, dass selbst aus meinem tracing heraus nichts Auffälliges zu finden ist, dass auf dieses Problem hindeutet. Ich habe schon Tage mit Analysen verbracht und letztendlich zu der Erkenntnis gelangt, dass ich in keiner Weise die möglichkeit habe präventive Maßnahmen zu ergreifen.
Deswegen hatte ich mich dann auch hier angemeldet, da ich die Hoffnung hatte, dass sich irgendwo auf dieser Welt schon einmal jemand mit diesem Sch..ss rumärgern durfte und vielleicht eine Lösung fand.
Deswegen auch die Redundanz, aber wenn die eine Maschine eh nicht mehr geht mußt Du sie ja doch neu booten dachte ich.
Logo ein Reboot Steht in jedem Fall an. Das habe ich heute auch erledigt und alles läuft wieder, bis zum nächsten mal.
Automatisiert könnte man dies nur mit dem Loopback (127.0.0.1) machen, indem man diesen zyklisch per WMI (ist schneller und einfacher) pingt. sobald mehr als 10 Mal nichts kommt -> Shutdown und mach neu
Ich hab mal bei unseren Programmierern nachgefragt und einer hat wie aus der Pistole geschoßen gesagt, Host-Datei und Routing-Tabelle wäre da seine ersten Ansatzpunkte..
Ich bleib aber weiter dran...
Gruß Roger
Ich bleib aber weiter dran...
Gruß Roger
Wie versprochen, ich bin aus meiner Bibliothek zurück. Ich hab mich nochmal durch die Informationen zum OSI-Referenzmodell gelesen. Ein zwei Frage hätte ich jetzt dazu. Man vergißt es ja schnell, aber eigentlich werden die Paket nicht von IP zu IP übertragen, sondern von MAC zu MAC. Was passiert wenn Du einen Namen Pings, nun, es wird eine DNS-Auflösung gemacht. Was passiert wenn Du eine IP-Adresse Pings? Wenn Du mal mit Wireshark gearbeitet hast, siehst Du daß auch häufig ARP-Requests mit im Datenstrom sind. Die Maschine fragt (solange die Adresse nicht im ARP-Cache drin ist) "Wer hat die IP x.x.x.x und die Maschine die sie hat, sollte antworten! Offensichtlich tut das Deine Maschine nicht.
Ich hätte einen Test. Solange die Maschine läuft, schreib Dir mal die MAC-Adresse des Servers auf. Wenn die Maschine von außen nicht zu erreichen ist, sieh Dir die ARP-Tabelle Deines Clients an. Da dürfte sie jetzt nicht mehr drin sein. Wenn Du dann die Maschine anpingst, löst Du einen ARP-Request aus, den die Maschine aber nicht beantwortet, also der "Zielhost ist nicht erreichbar". Du kannst aber der ARP-Tabelle einen statischen Eintrag verpassen. Was passiert, wenn Du das nur auf dem Client machst und dann die Maschine anpingst? Kannst Du auf der Konsole des Servers die ARP-Tabelle ebenfalls mit dem statischen Eintrag versehen und dann nochmal versuchen zu pingen?
Sieh Dir auch bei Wiki (http://de.wikipedia.org/wiki/Address_Resolution_Protocol) unten den Teil bei Probleme an, nicht das Du in Deinem Netz einen "ARP-Vergifter" hast..
LG und Frohe Weihnachten
Roger
Ich hätte einen Test. Solange die Maschine läuft, schreib Dir mal die MAC-Adresse des Servers auf. Wenn die Maschine von außen nicht zu erreichen ist, sieh Dir die ARP-Tabelle Deines Clients an. Da dürfte sie jetzt nicht mehr drin sein. Wenn Du dann die Maschine anpingst, löst Du einen ARP-Request aus, den die Maschine aber nicht beantwortet, also der "Zielhost ist nicht erreichbar". Du kannst aber der ARP-Tabelle einen statischen Eintrag verpassen. Was passiert, wenn Du das nur auf dem Client machst und dann die Maschine anpingst? Kannst Du auf der Konsole des Servers die ARP-Tabelle ebenfalls mit dem statischen Eintrag versehen und dann nochmal versuchen zu pingen?
Sieh Dir auch bei Wiki (http://de.wikipedia.org/wiki/Address_Resolution_Protocol) unten den Teil bei Probleme an, nicht das Du in Deinem Netz einen "ARP-Vergifter" hast..
LG und Frohe Weihnachten
Roger
