Anpingen selbst zeigt Dir nur ob zum Zeitpunkt des Pingbefehls der jeweilige rechner Verfügbar
ist.

mmn lässt sich somit keinerlei fundierte aussage über den zustand oder die funktion eures netzwerks
machen.

ich würde zb auf tools wie wireshark oder einen analyzer für packetloss setzen.

das zb ein switch nicht mehr gescheit arbeitet soll ja auch mal vorkommen

Irgenwoher kenn ich das Problem...

Als bei mir im Betrieb eine ERP-Software angeschafft wurde kam da jemand zu einer Demonastration vorbei der eine Art Demoversion installiert und 2-3 Leute instruiert hat, das ganze hat dann auch die ganzen 30 Tage funktioniert, allderdings wurde dann eine andere Software angeschafft die wir selbst installiert haben und die wochenlang nicht lief, entweder wurde der SQL-Server nicht gefunden, oder es "fehlten" Schreibrechte, zig verschiedene Fehler die auf den ersten Blick nichts miteinander zu tun hatten.
Letzendlich stellte sich dann heraus das der Komiker der die Demoversion installiert hat etwas am DNS-Server verpfuscht hatte und das niemandem gesagt oder irgendwo vermerkt hat.


Ich würde mal von allen Rechner aus Fehler provozieren und die Art des Fehlers und die Zeit notieren, dann alles was irgendwo an Logs vorhanden ist (Lokale Ereignisanzeige, Serverlogs, Firewall, Sicherheitssoftware) zu den notierten Zeiten durchschauen. Wenn da irgendwo was auffälliges auftaucht kannst du die Konfiguration entsprechend anpassen.
Wenn du nichts findest gibts keine andere Möglichkeit als den Service-Techniker zu bestellen, der soll dann aber jeden Handgriff dokumentieren und genau erklären wo der Fehler lag. (ist ja evtl. doch ein Problem das der Support bisher verschlampt hat)

Eine Software die das Netzwerk automatisch überprüft gibt es nicht (zu komplex und ein enormes Sicherheitsrisiko), entweder bietet der Server die Möglichkeit seine Dienste und deren Konfiguration zu überprüfen (Server2008 macht das ganz gut) oder eine Software die das Netzwerk nutzt bietet die Möglichkeit die Verbindungen zu diagnostizieren.

Wenn die das eingerichtet haben und alle weiteren Arbeiten über Teamviewer oder nach Anweisung ausgeführt wurden können die sich die Rechnung für den Techniker an den Hut streichen.

Irgendwer hat gepfuscht und das noch ziemlich grob. Wenn du so vorgehst wie ich dir das beschrieben habe findest du evtl. den Fehler und kannst ihn selbst beheben, der Techniker wird dir eh sonstwas erzählen... Uns wurde bei der Fehlersuche sogar empfohlen die Domäne neu zu installieren um den Fehler zu beheben, bloss um den Pfusch eines "Technikers" zu verdecken

Normalerweise treten Fehler in einer bestimmten Regelmässigkeit auf, z.B. wenn du versuchst eine bestimmte Aktion mit der Software auszuführen. Den Fehler provozierst du dann damit indem du (wer hätte das gedacht ... ) die Aktion ausführst die zum Fehler führt.

Der Sinn dahinter ist es einen Anhaltspunkt zu haben wo du suchen musst. Wenn du nicht weisst wann und unter welchen Bedingungen ein Fehler auftritt hast du sehr kleine Chance rauszufinden was nicht stimmt. Wenn du eine genaue Zeitangabe hast musst du nur noch wenige Datensätze in den Logfiles durchsuchen und die gesammelten Infos (Was hast du gemacht als der Fehler auftrat, welcher Fehler trat auf (Nr, bzw genauer Text der Meldung), was steht in welchen Logfiles) müsste es dann auch dem grottigsten Support möglich sein eine Aussage zu formulieren die dir weiterhilft.

Citation de "Thybald"

Neuerding schieben sie die ganzen Probleme auch unser netzwerk

Diese Vorgehensweise (schuld sind immer die Anderen) kenne ich doch irgendwoher.

Citation

... und würden und für 900€ jemand schicken.

Ich frag' mich nur, was dieser Mensch machen möchte.
Falls der Dir für 900 Euro ein komplettes Prüfprotokoll (Layer 1 und 2) erstellt, würde ich das sofort in Anspruch nehmen.

Citation

Kann ich irgendwie selbst das Netzwerk testen und hib und stichfest wiederlegen, das da alles in ordnung ist?

Für kleines Geld... Nein.

Aber das ist auch garnicht notwendig.
TCP/IP ist ausgesprochen robust und die aktuellen Auto-Negotiates zaubern auch noch auf einem alten Klingeldraht eine Verbindung herbei (solange der 4 Adern hat und nicht allzu lang ist).
Das zeigt auch Dein bestehendes Netzwerk, in dem - wie Du schreibst - alles funktioniert und offensichtlich auch keine TimeOuts zu beobachten sind.

BTW: Mit "Ping" (das wurde schon erwähnt) kann man garnix prüfen. Wenn Ping nicht geht, geht der Rest auch nicht - diese Regel ist nicht umkehrbar.

Wenn diese Software auf vorhandene Stacks aufsetzt, müsste sie also ebenfalls klaglos funktionieren.
Das sieht natürlich ganz anders aus, wenn hier irgendwelche Kommunikations-Module aus der Computersteinzeit herumwerkeln - Derlei Unbill ist im industriellen und messtechnischen Umfeld leider häufiger anzutreffen. Warum nur geht mir jetzt gerade "IEEE-488 over NetBIOS" nicht aus dem Kopf?

BOT: Weißt Du denn (anhand der Dokumentation), welche Protokolle hier verwendet werden? Bei Netzwerk-Software ist diese Dokumentation übrigens zwingend erforderlich.
Falls die Dokumentation das nicht hergibt, steht zu vermuten, daß der Hersteller das selbst nicht weiß - in diesem Fall würde ich die Zusammenarbeit nochmal genauer überdenken.

Ad hoc hab' ich noch drei Ideen:
1. Mach' mal einen Lasttest - einfach eine größere Datei von einem Rechner auf einen anderen kopieren.
2. Falls Du gemanagte Switche hast: Überprüfe mal die BroadCast-Einstellungen und guck' Dir auch die SysLogs an - mit besonderem Blick auf LACP-Meldungen.
3. In einem Netz mit "alten Geräten" solltest Du dringend einen dezidierten WINS-Server betreiben und alle Namen auf ihre LM2-Konformität prüfen. Hier sollte der DHCP dann auch diesen bekanntgeben und die Knoten auf Typ-H setzen.

mfg, Tom

Citation de "Tom_H"

Ad hoc hab' ich noch drei Ideen:
1. Mach' mal einen Lasttest - einfach eine größere Datei von einem Rechner auf einen anderen kopieren.
2. Falls Du gemanagte Switche hast: Überprüfe mal die BroadCast-Einstellungen und guck' Dir auch die SysLogs an - mit besonderem Blick auf LACP-Meldungen.
3. In einem Netz mit "alten Geräten" solltest Du dringend einen dezidierten WINS-Server betreiben und alle Namen auf ihre LM2-Konformität prüfen. Hier sollte der DHCP dann auch diesen bekanntgeben und die Knoten auf Typ-H setzen.

mfg, Tom

Damit wäre ich heillos überfordert.