8
LAN-Aussetzer bei Dateiabruf von Mac mini-Dateiserver. Herangehensweise zur Fehlerlokalisierung?
Hallo Netzwerkspezialisten.
Ich habe hier ein seltsames Netzwerkverhalten bei einem Dateiserver im Netzwerk.
Ein Mac mini (Ende 2014 mit macOS 10.14.2) ist als ein reiner Dateiserver im LAN für ca. 15-20 Mitarbeiter_innen. Es ist ein Bürogebäude mit strukturierter LAN-Verkabelung (Dosen in der Wand etc.) mit drei Etagen. Zwei Switche hängen nach meiner Info im LAN, einer im Server-Schränkchen. Ggf. sind noch kleine Büro-Switche unter den Tischen, da wo fünf/sechs Clients in einer Tischgruppe zusammenstehen. Bin erst kurz hier tätig, weiß leider noch nicht alles, IT ist auch nicht mein Hauptjob, gibt hier keinen IT-Menschen.
Seit geraumer Zeit gibt es das Problem, dass zwischendurch beim Abruf großer Dateien (ca. 50-100 MB und größer) das Netzwerk "lahmt". Egal von welchem Client.
Habe mal folgendes getestet: Ein Client im LAN ruft von Mac mini-Dateiserver große Dateien ab (waren ca. 800 MB). Zeitgleich hat der Dateiserver im Terminal den Router (Lancom R883+; KEINE Fritzbox) als dritte Gegenstelle angepingt.
Auch "hängt" manchmal das Internet, wo ich derzeit noch nicht sagen kann, ob das miteinander zusammenhängt.
Unten stehen die Ping-Ergebnisse in der Abrufzeit. Da geht die Ping-Zeit hoch auf mehrere Sekunden bzw. fallen sogar aus.
Wie wäre Eure Herangehensweise zur Fehlereingrenzung?
Vielen Dank und beste Grüße
Jörg
Ich habe hier ein seltsames Netzwerkverhalten bei einem Dateiserver im Netzwerk.
Ein Mac mini (Ende 2014 mit macOS 10.14.2) ist als ein reiner Dateiserver im LAN für ca. 15-20 Mitarbeiter_innen. Es ist ein Bürogebäude mit strukturierter LAN-Verkabelung (Dosen in der Wand etc.) mit drei Etagen. Zwei Switche hängen nach meiner Info im LAN, einer im Server-Schränkchen. Ggf. sind noch kleine Büro-Switche unter den Tischen, da wo fünf/sechs Clients in einer Tischgruppe zusammenstehen. Bin erst kurz hier tätig, weiß leider noch nicht alles, IT ist auch nicht mein Hauptjob, gibt hier keinen IT-Menschen.
Seit geraumer Zeit gibt es das Problem, dass zwischendurch beim Abruf großer Dateien (ca. 50-100 MB und größer) das Netzwerk "lahmt". Egal von welchem Client.
Habe mal folgendes getestet: Ein Client im LAN ruft von Mac mini-Dateiserver große Dateien ab (waren ca. 800 MB). Zeitgleich hat der Dateiserver im Terminal den Router (Lancom R883+; KEINE Fritzbox) als dritte Gegenstelle angepingt.
Auch "hängt" manchmal das Internet, wo ich derzeit noch nicht sagen kann, ob das miteinander zusammenhängt.
Unten stehen die Ping-Ergebnisse in der Abrufzeit. Da geht die Ping-Zeit hoch auf mehrere Sekunden bzw. fallen sogar aus.
Wie wäre Eure Herangehensweise zur Fehlereingrenzung?
Vielen Dank und beste Grüße
Jörg
64 bytes from 192.168.178.1: icmp_seq=1512 ttl=60 time=1.018 ms
64 bytes from 192.168.178.1: icmp_seq=1513 ttl=60 time=0.958 ms
64 bytes from 192.168.178.1: icmp_seq=1514 ttl=60 time=1.056 ms
64 bytes from 192.168.178.1: icmp_seq=1515 ttl=60 time=1.022 ms
64 bytes from 192.168.178.1: icmp_seq=1516 ttl=60 time=0.581 ms
64 bytes from 192.168.178.1: icmp_seq=1517 ttl=60 time=0.576 ms
64 bytes from 192.168.178.1: icmp_seq=1518 ttl=60 time=0.910 ms
64 bytes from 192.168.178.1: icmp_seq=1519 ttl=60 time=0.614 ms
64 bytes from 192.168.178.1: icmp_seq=1520 ttl=60 time=1.123 ms
64 bytes from 192.168.178.1: icmp_seq=1521 ttl=60 time=1.208 ms
64 bytes from 192.168.178.1: icmp_seq=1522 ttl=60 time=0.959 ms
64 bytes from 192.168.178.1: icmp_seq=1523 ttl=60 time=1.133 ms
64 bytes from 192.168.178.1: icmp_seq=1524 ttl=60 time=1.113 ms
64 bytes from 192.168.178.1: icmp_seq=1525 ttl=60 time=1.050 ms
64 bytes from 192.168.178.1: icmp_seq=1526 ttl=60 time=4.141 ms
64 bytes from 192.168.178.1: icmp_seq=1527 ttl=60 time=5.049 ms
64 bytes from 192.168.178.1: icmp_seq=1528 ttl=60 time=0.817 ms
64 bytes from 192.168.178.1: icmp_seq=1529 ttl=60 time=1.049 ms
64 bytes from 192.168.178.1: icmp_seq=1530 ttl=60 time=1.121 ms
64 bytes from 192.168.178.1: icmp_seq=1531 ttl=60 time=1.181 ms
64 bytes from 192.168.178.1: icmp_seq=1532 ttl=60 time=1.233 ms
64 bytes from 192.168.178.1: icmp_seq=1533 ttl=60 time=1.109 ms
64 bytes from 192.168.178.1: icmp_seq=1534 ttl=60 time=2.128 ms
64 bytes from 192.168.178.1: icmp_seq=1535 ttl=60 time=0.693 ms
64 bytes from 192.168.178.1: icmp_seq=1536 ttl=60 time=0.991 ms
64 bytes from 192.168.178.1: icmp_seq=1537 ttl=60 time=1.017 ms
64 bytes from 192.168.178.1: icmp_seq=1538 ttl=60 time=1.141 ms
64 bytes from 192.168.178.1: icmp_seq=1539 ttl=60 time=0.984 ms
64 bytes from 192.168.178.1: icmp_seq=1540 ttl=60 time=1.057 ms
64 bytes from 192.168.178.1: icmp_seq=1541 ttl=60 time=1.025 ms
64 bytes from 192.168.178.1: icmp_seq=1542 ttl=60 time=1.151 ms
64 bytes from 192.168.178.1: icmp_seq=1543 ttl=60 time=0.990 ms
64 bytes from 192.168.178.1: icmp_seq=1544 ttl=60 time=5.921 ms
64 bytes from 192.168.178.1: icmp_seq=1545 ttl=60 time=6.422 ms
64 bytes from 192.168.178.1: icmp_seq=1546 ttl=60 time=5.787 ms
Request timeout for icmp_seq 1547
Request timeout for icmp_seq 1548
Request timeout for icmp_seq 1549
Request timeout for icmp_seq 1550
64 bytes from 192.168.178.1: icmp_seq=1551 ttl=60 time=1.782 ms
64 bytes from 192.168.178.1: icmp_seq=1552 ttl=60 time=2.122 ms
64 bytes from 192.168.178.1: icmp_seq=1553 ttl=60 time=1.062 ms
64 bytes from 192.168.178.1: icmp_seq=1554 ttl=60 time=1.035 ms
64 bytes from 192.168.178.1: icmp_seq=1555 ttl=60 time=0.929 ms
64 bytes from 192.168.178.1: icmp_seq=1556 ttl=60 time=4.913 ms
64 bytes from 192.168.178.1: icmp_seq=1557 ttl=60 time=1.015 ms
64 bytes from 192.168.178.1: icmp_seq=1558 ttl=60 time=1.110 ms
64 bytes from 192.168.178.1: icmp_seq=1559 ttl=60 time=6.002 ms
64 bytes from 192.168.178.1: icmp_seq=1560 ttl=60 time=5.817 ms
64 bytes from 192.168.178.1: icmp_seq=1561 ttl=60 time=5.891 ms
64 bytes from 192.168.178.1: icmp_seq=1562 ttl=60 time=5.826 ms
64 bytes from 192.168.178.1: icmp_seq=1563 ttl=60 time=6.032 ms
64 bytes from 192.168.178.1: icmp_seq=1564 ttl=60 time=2.153 ms
64 bytes from 192.168.178.1: icmp_seq=1565 ttl=60 time=6.371 ms
64 bytes from 192.168.178.1: icmp_seq=1566 ttl=60 time=6.466 ms
64 bytes from 192.168.178.1: icmp_seq=1567 ttl=60 time=6.120 ms
64 bytes from 192.168.178.1: icmp_seq=1568 ttl=60 time=1.117 ms
64 bytes from 192.168.178.1: icmp_seq=1569 ttl=60 time=1.035 ms
64 bytes from 192.168.178.1: icmp_seq=1570 ttl=60 time=0.754 ms
64 bytes from 192.168.178.1: icmp_seq=1571 ttl=60 time=1.107 ms
64 bytes from 192.168.178.1: icmp_seq=1572 ttl=60 time=1.012 ms
64 bytes from 192.168.178.1: icmp_seq=1573 ttl=60 time=1.088 ms
64 bytes from 192.168.178.1: icmp_seq=1574 ttl=60 time=2.911 ms
64 bytes from 192.168.178.1: icmp_seq=1575 ttl=60 time=1.161 ms
64 bytes from 192.168.178.1: icmp_seq=1576 ttl=60 time=1.110 ms
64 bytes from 192.168.178.1: icmp_seq=1577 ttl=60 time=1.023 ms
64 bytes from 192.168.178.1: icmp_seq=1578 ttl=60 time=1.030 ms
64 bytes from 192.168.178.1: icmp_seq=1579 ttl=60 time=1.099 ms
64 bytes from 192.168.178.1: icmp_seq=1580 ttl=60 time=1.180 ms
64 bytes from 192.168.178.1: icmp_seq=1581 ttl=60 time=1.020 ms
64 bytes from 192.168.178.1: icmp_seq=1582 ttl=60 time=1.105 ms
64 bytes from 192.168.178.1: icmp_seq=1583 ttl=60 time=1.083 ms
64 bytes from 192.168.178.1: icmp_seq=1584 ttl=60 time=1.122 ms
64 bytes from 192.168.178.1: icmp_seq=1585 ttl=60 time=0.939 ms
64 bytes from 192.168.178.1: icmp_seq=1586 ttl=60 time=1.002 ms
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: 520322
Url: https://administrator.de/contentid/520322
Ausgedruckt am: 04.11.2024 um 18:11 Uhr
8 Kommentare
Neuester Kommentar
Bin erst kurz hier tätig, weiß leider noch nicht alles,
Gerade die genaue Switch Infrastruktur ist aber essentiell wichtig für eine zielführende Fehleranalyse. Das wirst sogar du als Laie wissen. Hier gibt es diverse Fehlerszenarien und Raten oder die Kristallkugel hilft hier sicher keinem.Wenn du in der Autowerkstatt jemanden fragst und ihm sagst...ich weiss nicht aber irgendwie rollt das was kaputt ist und hat 4 Räder wird dir auch dort keiner qualifiziert helfen können, oder ? Das schildert so ziemlich die Situation hier. Fragt sich also was für eine Erwartungshaltung du hast bei solchen Vorgaben ?!
Wie du ja unschwer selber siehst hast du ja zyklische Connectivity Aussetzer die in sauberen Netzen ein NoGo sind. Sowas lässt häufig auf Spanning Tree Probleme schliessen durch falsche oder fehlerhafte STP Konfiguration. Möglich sind aber auch Autonegotiation Probleme am Switchport usw. der Grund. Defelte Kabel und und und...
Da kann man jetzt nur im freien Fall raten ohne detailierte Infos.
Diese zyklischen Aussetzer sind allerdings gravierend und zeigen ja schon das da grundsätlich was im Netzwerk oder seinem Design nicht stimmt und schief läuft.
Hi aqui,
danke Dir für das schnelle Feedback.
Ja, mir ist klar, dass für tiefere Fehleranalyse Details wichtig sind. Liefere ich gern nach.
Mir geht es um den Weg, was kann ich jetzt erst einmal zur Analyse tun. Was sind die ersten Schritte? Gibt es ne (verlinkte) Checkliste? Wonach gucke ich z.B. im system.log des Mac mini oder des Routers? Gibt es Schlüsselbegriffe im Log wie z.B. "disconnected" oder andere?
Eines habe ich grad gefunden:
system.log Mac mini
Router-Syslog zeitgleich:
Heißt: Der Server steht auf DHCP-Adressbezug... ohje.
Muss ich wohl ändern
danke Dir für das schnelle Feedback.
Ja, mir ist klar, dass für tiefere Fehleranalyse Details wichtig sind. Liefere ich gern nach.
Mir geht es um den Weg, was kann ich jetzt erst einmal zur Analyse tun. Was sind die ersten Schritte? Gibt es ne (verlinkte) Checkliste? Wonach gucke ich z.B. im system.log des Mac mini oder des Routers? Gibt es Schlüsselbegriffe im Log wie z.B. "disconnected" oder andere?
Eines habe ich grad gefunden:
system.log Mac mini
Nov 29 10:39:28 Server1 TeamViewer_Service[63697]: NetWatchdog: Completely disconnected. Going offline.
Nov 29 10:39:28 Server1 TeamViewer_Service[63697]: NetWatchdog: Internet is now disconnected
Nov 29 10:39:28 Server1 TeamViewer_Service[63697]: NetWatchdog: LAN is now disconnected
Nov 29 10:39:33 Server1 TeamViewer_Service[63697]: NetWatchdog: Completely disconnected. Going offline.
Nov 29 10:39:33 Server1 TeamViewer_Service[63697]: NetWatchdog: Internet is now disconnected
Nov 29 10:39:33 Server1 TeamViewer_Service[63697]: NetWatchdog: LAN is now disconnected
Nov 29 10:39:46 Server1 TeamViewer_Service[63697]: NetWatchdog: Completely disconnected. Going offline.
Nov 29 10:39:46 Server1 TeamViewer_Service[63697]: NetWatchdog: Internet is now disconnected
Nov 29 10:39:46 Server1 TeamViewer_Service[63697]: NetWatchdog: LAN is now disconnected
Nov 29 10:39:56 Server1 TeamViewer_Service[63697]: NetWatchdog: Completely disconnected. Going offline.
Nov 29 10:39:56 Server1 TeamViewer_Service[63697]: NetWatchdog: Internet is now disconnected
Nov 29 10:39:56 Server1 TeamViewer_Service[63697]: NetWatchdog: LAN is now disconnectedRouter-Syslog zeitgleich:
359 2019-11-29 10:39:52 KERN Hinweis DHCP: IP 192.168.178.xy assigned to MAC: 78:7b:8a:aa:bb:cc for 600 Minutes
360 2019-11-29 10:39:52 LOCAL3 Alarm Dst: 93.bbb.ccc.ddd:12396 {R883+fgh.intern}, Src: 217.f.ggg.hhh:13048 (UDP): connection refused
361 2019-11-29 10:39:40 KERN Hinweis DHCP: IP 192.168.178.xy assigned to MAC: 78:7b:8a:aa:bb:cc for 600 Minutes
362 2019-11-29 10:39:34 KERN Hinweis DHCP: IP 192.168.178.xy assigned to MAC: 78:7b:8a:aa:bb:cc for 600 MinutesHeißt: Der Server steht auf DHCP-Adressbezug... ohje.
Muss ich wohl ändern
Die Endgeräte per se werden sicher nicht das primäre Problem sein.
Du musst mal den gesamten Pfad checken den ein Client auf den Server nimmt. Erstmal die involvierte Hardware, Verkabelung usw.
Das betrifft insbesondere die Logs der beteiligten Switches. Ein Wireshark Trace kann helfen zu sehen ob es Broadcast Stürme oder Loops im Netzwerk gibt. Loops sind bei Knstrukten mit billigen Desktop Switches nie auszuschliessen. Sowas reist dann auch das Netz in den Orkus.
LAN ist now disconnecetd besagt ja auch das da schon physische Anschlussprobleme ans Netz bestehen. Da ist also ganz gehörig was im Argen.
Zur Teamviewer Schnüffelsoftware sagen wir jetzt erstmal nichts, das ist ein anderes Thema.
Du musst mal den gesamten Pfad checken den ein Client auf den Server nimmt. Erstmal die involvierte Hardware, Verkabelung usw.
Das betrifft insbesondere die Logs der beteiligten Switches. Ein Wireshark Trace kann helfen zu sehen ob es Broadcast Stürme oder Loops im Netzwerk gibt. Loops sind bei Knstrukten mit billigen Desktop Switches nie auszuschliessen. Sowas reist dann auch das Netz in den Orkus.
LAN ist now disconnecetd besagt ja auch das da schon physische Anschlussprobleme ans Netz bestehen. Da ist also ganz gehörig was im Argen.
Zur Teamviewer Schnüffelsoftware sagen wir jetzt erstmal nichts, das ist ein anderes Thema.
Zur Teamviewer Schnüffelsoftware sagen wir jetzt erstmal nichts, das ist ein anderes Thema.
...ist nicht mein System - sag ich (erst einmal) auch nix zu Du musst mal den gesamten Pfad checken den ein Client auf den Server nimmt. Erstmal die involvierte Hardware, Verkabelung usw.
Das denke ich, wird Montag früh, bevor die meisten MA's hier starten, tun (Serverschrank/Mac mini/Switche/Router etc.).Das betrifft insbesondere die Logs der beteiligten Switches.
Öhm, das sind, so wie ich es gesehen habe, keine managebaren Switche.Ein Wireshark Trace kann helfen zu sehen ob es Broadcast Stürme oder Loops im Netzwerk gibt. Loops sind bei Knstrukten mit billigen Desktop Switches nie auszuschliessen. Sowas reist dann auch das Netz in den Orkus.
Guter Tipp, muss mein eigenen Lappi mit Wireshark mal hier reinhängen.LAN ist now disconnecetd besagt ja auch das da schon physische Anschlussprobleme ans Netz bestehen. Da ist also ganz gehörig was im Argen.
Tippe auf Kontaktfehler oder defekte Stecker/Buchse. Mal ruckeln am Montag.Öhm, das sind, so wie ich es gesehen habe, keine managebaren Switche.
Das ist sehr schlecht ! 
Ein NoGo in einem Firmennetz normalerweise !! Wer hat sowas verbrochen, der gehört abgemahnt ?!
Dann hast du da schon mal keine Chance was sinnvoll zu testen und kannst das nur mit grobem Austausch machen.
Tippe auf Kontaktfehler oder defekte Stecker/Buchse. Mal ruckeln am Montag.
Dann gehe mit dem Test Lappi erstmal direkt auf den Switch wo auch der Server dran ist und lasse dort einen Dauerping laufen.Hast du immer noch Aussetzer dort ziehe vom Server Switch alle Uplinks zu anderen Switches ab und mache wieder einen Dauerping.
Sind dann die Aussetzer weg steckst du sukzessive die anderen Switches wieder dran und beobachtest dabei das Ping Verhalten und ggf. Wireshark Output.
Bei dem wo die Aussetzer wieder einsetzen ist das Problem.
Klingt doof aber wer so einen Schrott in einem Firmennetzwerk einsetzt der muss halt leiden, sorry.
Das zeigt dir dann auch gleich mal die gravierenden Nachteile solcher Schrotthardware in einer Firmen Infrastruktur.
Danke Dir, aqui.
Am kommenden Samstag wird jetzt ein Netzwerk-Check-Tag, wenn keiner arbeitet.
Vorher wird das hier im laufenden Weihnachtsgeschäft in der Arbeitswoche (ist grad Jahreshochzeit bei uns) nix werden.
Ich hab noch herausgefunden, dass mehrere iMacs sowohl per LAN als auch per WLAN im selben Netzwerk hängen.
Frage: wie wirkt sich das auf Netzwerkverkehr auf, wenn LAN (teilweise nur 100 MBit) als auch WLAN am selben Rechner aktiv sind? Ich sah im Router, dass mehrere Rechner zwei IP-Adressen (aus 192.168.178.x) erhalten haben.
Kannst Du mir dazu noch was sagen, @aqui?
Vorher wird das hier im laufenden Weihnachtsgeschäft in der Arbeitswoche (ist grad Jahreshochzeit bei uns) nix werden.
Ich hab noch herausgefunden, dass mehrere iMacs sowohl per LAN als auch per WLAN im selben Netzwerk hängen.
Frage: wie wirkt sich das auf Netzwerkverkehr auf, wenn LAN (teilweise nur 100 MBit) als auch WLAN am selben Rechner aktiv sind? Ich sah im Router, dass mehrere Rechner zwei IP-Adressen (aus 192.168.178.x) erhalten haben.
Kannst Du mir dazu noch was sagen, @aqui?
Ich hab noch herausgefunden, dass mehrere iMacs sowohl per LAN als auch per WLAN im selben Netzwerk hängen.
Das ist natürlich tödlich !Wenn diese iMacs permanent im LAN arbeiten musst du den WLAN Port natürlich deaktivieren !
Es darf immer nur ein Netzwerk Port aktiv sein ! Logisch, denn wenn beide Adapter im gleichen IP Netz sind ist eine eindeutige Wegefindung damit unmöglich. Kein OS kommt damit klar.
