MacMini Server stört lokalen Netzwerkverkehr.

[Turkey1976]

Hi,

unser MacMini Server Late 2012 (mit aktuellem Softwarestand) stört unser Schulnetzwerk. Sobald er nennenswerten Traffic verursacht, bricht das Netzwerk zusammen. Es sind keine Pings mehr möglich (von und zu allen Rechnern), Netzwerklaufwerkverbindungen sind unzuverlässig, der DHCP-dienst des Routers versagt, d.h. neue Clients bekommen keine gültige IP. Ganz unschön. Klemme ich den MacMini vom Netzwerk ab, so dauert es wenige Augenblicke bis alles wieder normal läuft. Auch ein Neustart behebt das Probleme für eine gewisse Zeit. Wir haben eine heterogene Gerätestruktur und einen Lancom 831a Router.
Ein zweites Netzwerk über eine Thunderbird-Ethernetkarte eingebunden wird nicht gestört. Bei mir Zuhause mit popeliger Netzwerkinfrastruktur macht der MacMini keine Probleme.

Wie kann ich Diagnose betreiben?

T

 

[dg2rbf]

hi..
kannst du die Netzwerkeinstellung des MacMini Server mal hier Posten, so ist das nur ein Rätselraten..

 

[Turkey1976]

Bitteschön! Dankeschön!

 

[dg2rbf]

hi..
die Thunderbolt IPv4 Einstellung ist das Problem, kannst du die IP-Adr. auf 192.168.1.xxx einstellen ? würde auch den DNS Server auf ne andere IP-Adr legen .254 is nicht optimal..

 

[Turkey1976]

Das Thunderboldenetzwerk ist physisch vom anderen Netzwerk getrennt. Warum sollte der andere IP Bereich probleme machen? (Hab ja keine Ahnung). Und wo ist das Problem mit dem unüblichen Gateway auf 254? (Hab auch da keine Ahnung)

 

[dg2rbf]

kontroliere mal alle ipadressen im Netzwerk, grundsätzlich ist es besser alle IPAdressen im selben Bereich zu haben, 192.168.1.xxx oder .2.xxx etc, wie so hast du das Thunderbolt Netzwerk auf .2.xxx gelegt ??, so was bringt nix, stelle mal das Gateway auf .1.1, das macht weniger Probleme, is halt etwas Arbeit, würde auch im Router den DHCP Bereich von 192.168.1.50 - 192.168.1.150 einstellen, und die festen IPAdressen in den Klient Rechnern incl Server, auf über .1.150 einstellen, so ist das Ganze System besser strukturiert u übersichtlicher..

 

[Turkey1976]

Netzwerkstruktur:

Netz A: 192.168.1.x --> Netzwerk der Schulverwaltung mit PCs, DSL Zugang, NAS, Kopierern etc.
Netz B: 192.168.2.x --> Netzwerk für unsere Schüler mit PCs, IPads und weiterem mobilen Gedöns unserer Schüler

Der MacMini dient
1. als Fileserver in beiden Netzen,
2. als Wikiserver in beiden Netzen
3. als Printserver in beiden Netzen (insb. für die iPads)
4. als Proxyserver mit Webfilterfunktion und DHCP Server in Netz B. (Dies wird über eine Linux VM erledigt. Das Problem tritt auch auf, wenn die VM abgeschaltet ist.)

Der Mac Mini ist Teil von Netz A und Netz B. Netz A und Netz B sind physisch getrennt. Nur der Mini nimmt an beiden Netzen teil.

Ich will jetzt deine Tipps nicht in den Wind schlagen, aber ich verstehe nicht, warum der IP-Bereich der beiden Netze gleich sein sollte und ich verstehe auch nicht, wieso das Gateway nicht 192.168.1.254 haben sollte - mal davon abgesehen, dass man es überlicherweise auf 1 vermutet. Aber die nötigen Informationen für die Clients liefert doch der DHCP, bei dem die 254 als Standardgateway eingetragen ist. ... ich will ja nur was dazulernen.

 

[dg2rbf]

hi..
es ist Problematisch wenn in einem Netzwerk .1.xxx u .2.xxx vergeben werden, das können nur die wenigsten Router vernünftig handeln..

 

[Wuchtbrumme]

hi..
es ist Problematisch wenn in einem Netzwerk .1.xxx u .2.xxx vergeben werden, das können nur die wenigsten Router vernünftig handeln..

Quark. Andersherum: Die wenigsten Geräte, die das nicht können, werden noch als Router bezeichnet

@TE: Läuft der Softwareupdatedienst auf dem Server? Insgesamt fehlen noch so etliche Infos für ein stimmiges Bild.

 

[Insulaner]

Ich stimme Wuchtbrumme zu.

Wenn Du auf dem MacMini zwei Netze konfiguriert hast, dann stellt sich immer
die Frage, wie das auf der Protokoll-Ebene geregelt ist. Ich hab aktuell keinen
schimmer, wie das funktionieren kann.
Hast Du einen Netzplan, in dem Du die entscheidenende Infos mal dargestellt hast?

Infos:
- Interfaces mit IP-Adressen und default Gateways
- Kabelverbindungen
- Aktive Komponenten (Switches (Layer-2) und Router (Layer-3)
- Wo sind die Gateways für die beiden Netze konfiguriert

Du kannst ein Gateway (in der Regel) immer nur über das gleiche IP-Netz erreichen.
Will sagen: Du kannst das Gateway 192.168.1.x nicht über das INterface 192.168.2.y erreichen.

 

[Turkey1976]

Sorry für die Wartezeit. Ich habe einen Netzplan erstellt.


Ich glaube allerdings nicht, dass es an der grundsätzlichen Verkabelung liegt, denn diese Architektur besteht schon seit mehreren Jahren. Früher werkelte allerdings eine Linuxkiste an der Position des MacMini.
Die Geräte im 192.168.2.x Netzwerk können und sollen das Gateway und die Clients in 192.168.1.x NICHT erreichen. Die greifen auf eine virtuelle Maschine (IPFIRE) auf dem Mini zu, die auf 192.168.2.1 eine Gateway, DHCP, DNS, Squidproxy und DansGuardian bereitstellt. Die VM hat über über NAT Zugriff auf das Internet und leitet es hinüber ins 192.168.2.x. Die Netzwerkprobleme, treten aber auch dann auf, wenn die VM abgeschaltet ist und der MacMini Traffic verursacht, z.b. beim Download von Updates o.Ä.

 

[Insulaner]

Ja, die Linux-Kiste werkelte als Router zwischen den Netzen.
Ich nehme mal an, dass dies beim MacMini nicht der Fall ist.
Wie man die Routing-Funktionalität auf dem Teil aktiviert, weiß ich leider nicht.

Auf dem Interface des 192.168.2.0/24er Netzes darf kein Default Gateway angegeben sein.
Denn das Default Gateway ist ja die 192.167.1.254

 

[Turkey1976]

Das Problem tritt nur im 192.168.1.x Netz auf. Auch dann, wenn ich den Thunderboldethernetadapter (zuständig für das andere Netz) rausziehe. Auch dann wenn die VM aus ist. Das Routing zwischen den Netzen funktioniert perfekt; dies erledigt das virtuelle Linux. Ein Ping von 1.x nach 2.x und umgekehrt ist nicht erwünscht.

 

[Wuchtbrumme]

Das Problem tritt nur im 192.168.1.x Netz auf. Auch dann, wenn ich den Thunderboldethernetadapter (zuständig für das andere Netz) rausziehe. Auch dann wenn die VM aus ist. Das Routing zwischen den Netzen funktioniert perfekt; dies erledigt das virtuelle Linux. Ein Ping von 1.x nach 2.x und umgekehrt ist nicht erwünscht.

der DHCP-Server vom Mini ist nur an den Thunderbolt-Adapter gebunden? Ich würde den VM-Linux-Router auch DHCP machen lassen, wenn sie nicht läuft ist eh nichts mit Internet für das zweite Netz.

 

[Turkey1976]

der DHCP-Server vom Mini ist nur an den Thunderbolt-Adapter gebunden? Ich würde den VM-Linux-Router auch DHCP machen lassen, wenn sie nicht läuft ist eh nichts mit Internet für das zweite Netz.

(Wie ich am Anfang des Threads schrieb,) die Netzwerkdienste in 2.x kommen ohnehin alle von der VM und haben auch gar nicht die Möglichkeit das 1.x zu beeinträchtigen.

 

[drlecter]

Kannst du auf dem Mac mal Wireshark laufen lassen (falls dies erlaubt ist) und schauen ob er vielleicht was ungewöhnlich erscheint (Masse an Broadcasts, hohe Anzahl von Verbindungen usw.).

 

[Wuchtbrumme]

(Wie ich am Anfang des Threads schrieb,) die Netzwerkdienste in 2.x kommen ohnehin alle von der VM und haben auch gar nicht die Möglichkeit das 1.x zu beeinträchtigen.

dann schau noch mal in das Netzwerkdiagramm - aus der Darstellung geht das nicht so klar hervor. Aber nachdem Du gesagt hast, dass die VM routet, kann Deine Aussage "haben auch gar nicht die Möglichkeit das 1.x zu beeinträchtigen" so auch nicht stehen bleiben. Dann ist halt die Frage, ob der DHCP der VM vernünftig auf ein 2.x-Interface gebunden ist.

Ich würde jetzt auch mal an einigen Stellen tcpdumps erstellen und gucken, was ich finde.

 

[Turkey1976]

dann schau noch mal in das Netzwerkdiagramm - aus der Darstellung geht das nicht so klar hervor. Aber nachdem Du gesagt hast, dass die VM routet, kann Deine Aussage "haben auch gar nicht die Möglichkeit das 1.x zu beeinträchtigen" so auch nicht stehen bleiben. Dann ist halt die Frage, ob der DHCP der VM vernünftig auf ein 2.x-Interface gebunden ist.

Ich lasse mich zu der Vermutung hinreißen, weil das Problem auch dann auftritt, wenn die VM nicht in Betrieb ist...

Ich würde jetzt auch mal an einigen Stellen tcpdumps erstellen und gucken, was ich finde.

Das scheint die Art von Diagnose zu sein, die ich mir vorgestellt habe: den Traffic auf unterster Ebene zu untersuchen. Wie geht das mit tcpdumps? Wireshark?
I

 

[drlecter]

Wie oben schon erwähnt kannst du mit Wireshark anfangen. http://www.wireshark.org/download.html
Du kannst auch gern tcpdump (im Terminal) benutzen, das in ein pcap schreiben und dir das in Wireshark anschauen.
Bei tcpdump muss du halt nur das Interface angeben das mitgelogt werden soll und gut.
Wireshark selber ist "recht einfach" zu bedienen. Du kannst das mithören einmal anstellen und schauen was alles auf der Netzwerkschnittstelle passiert. Wenn du eine Vermutung hast (z.B. sehr viel Broadcastfloods, komischer http Trafic) kann man mit den Filtern arbeiten.
Ich tendiere normalerweise dazu, mittels tcpdump alles in eine Datei zuschreiben und dann mit Wireshark nur noch anzuschauen. (-i Interface -s 0 -w datei als Option für tcpdump müsste klappen).

 

[Wuchtbrumme]

(-i Interface -s 0 -w datei als Option für tcpdump müsste klappen).

bitte -s 1500, sonst fehlen mglws. wichtige Informationen