bierkistenschlepper
Goto Top

HP PS1810-8G Switch stürzt bei iperf3 ab

Hallo,

ich habe folgendes Setup:

VDSL -> FritzBox (DHCP) -> HP PS1810-8G Switch => Bonding mit 2 Leitungen => Server (iperf3)
|------ unmanaged Netgear-Switch -> alle Clients, beim PC nochmal ein unmanaged Switch. .

Es hängen also alle Geräte an dem HP Switch. Besonderheit ist, dass ich hier einen Trunk konfiguriert habe, d.h. die Ports 6 und 7 (Server) haben Trunk aktiviert und auf dem Server ist ebenfalls Bonding aktiv, siehe Screenshots. Sicherheitsfeatures am Switch (Auto D0S und Storm Control) habe ich deaktiviert.. Alle Ports sind fest auf Gigabit Ethernet Full Duplex, weil ich mit Auto Negotiation schonmal Probleme hatte. Alle anderen besonderen Features (LLDP, Spanning Tree, ...) sind deaktivert.

Auf dem Server
iperf3 -s

Auf den Clients
iperf3 -c 192.168.170.11

MacBook Pro an allen Netzwerkbuchsen getestet. Läuft 1A, 940 Mbit/s auch per WLAN keine Probleme.

Bei meinem Linux Mint PC ist die Onboard Netzwerkkarte ziemlich langsam, 740 Mbit/s. Nun habe ich hier eine vorhandene und eine nagelneue 1 Gbit PCIe KArte eingebaut. Beide verursachen folgenden Fehler:

cornelius@vincent ~ $ iperf3 -c 192.168.170.11
Connecting to host 192.168.170.11, port 5201
[  4] local 192.168.170.31 port 34002 connected to 192.168.170.11 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   112 MBytes   940 Mbits/sec    0    139 KBytes       
[  4]   1.00-2.00   sec   587 KBytes  4.80 Mbits/sec    2   1.41 KBytes       
[  4]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes       
[  4]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes       
[  4]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes       
[  4]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes       
[  4]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes       
[  4]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes       
[  4]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes       
^C[  4]  10.00-35.01  sec  0.00 Bytes  0.00 bits/sec    2   1.41 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-35.01  sec   113 MBytes  27.0 Mbits/sec    7             sender
[  4]   0.00-35.01  sec  0.00 Bytes  0.00 bits/sec                  receiver
iperf3: interrupt - the client has terminated
Manchmal läuft es fast durch, manchmal bricht er sofort ab, aber das Ergebnis ist immer gleich von diesem PC. Ich muss iperf3 dann abschießen.
Es bricht das gesamte Netz zusammen, kann nichts mehr pingen etc.
Der PC meldet "Verbindung wird aufgebaut", er bekommt aber keine IP, auch wenn ich ihn neustarte.

Was hilft ist ein Neustart des HP Switchs (Strom raus). Danach geht es wieder - bis ich wieder iperf3 auf dem PC laufen lasse.

An der Netzwerkkarte kann es nicht liegen, denn dass zwei Karten defekt sind, kann man wohl ausschließen.

Würde es am Bonding liegen, müsste es auch mit dem MacBook Pro abbrechen? Die Link Aggreggation habe ich testweise auch schon deaktiviert - keine Verbesserung.
Paketverlust habe ich keinen mit Ping:

--- 192.168.170.11 ping statistics ---
168 packets transmitted, 168 received, 0% packet loss, time 171009ms
rtt min/avg/max/mdev = 0.355/0.442/0.511/0.025 ms

Bin mit meinem Latein am Ende. Hat jemand noch eine Idee oder einen Verdacht, welche Einstellung am Switch derartig harte Crashs verursachen könnte? Oder liegt es am Linux?

Gruß,
BKS
auswahl_016
auswahl_017

Content-Key: 398711

Url: https://administrator.de/contentid/398711

Ausgedruckt am: 19.03.2024 um 02:03 Uhr

Mitglied: em-pie
em-pie 18.01.2019 um 22:22:49 Uhr
Goto Top
Moin,

Eine konkrete Idee habe ich nicht, aber welche FW rennt derzeit auf dem Switch? Evtl. mal updaten?

Und evtl. könnte es sein, dass trotz TechSpecs und den 16GBit Throughput der iperf Traffic erst dein Notebook „überforfert“ und der dann in dem Zuge den Switch überlastet.

Hast du mal parallel via WireShark geschaut, was kurz vor dem Switch-Ausstieg an Paketen transportiert wird?

Gruß
em-pie
Mitglied: Bierkistenschlepper
Bierkistenschlepper 18.01.2019 aktualisiert um 23:10:10 Uhr
Goto Top
Auf dem Switch läuft überhaupt keine Firewall. Und auf dem Server läuft UFW / Iperf. Aber da ist der gesamte IP-Bereich freigegeben.

Und das Problem befindet sich eindeutig auf dem Switch, da ich nach einem Neustart des Switchs ja wieder auf meine GEräte komme.

https://www.file-upload.net/download-13474744/Switch_Absturz.pcapng.tar. ...
Ich habe hier mal ein Wireshark Capture gemacht. Kann damit jemand etwas anfangen?

Das Problem beginnt ganz unten, da wo die schwarzen Pakete auftauchen. Gefiltert habe ich nach Port 5201

Im Anhang noch ein Screenshot mit dem letzten Paket vor Abbruch.
switch_absturz.pcapng_018
Mitglied: em-pie
em-pie 19.01.2019 um 07:55:58 Uhr
Goto Top
Moin,

FW= Firmware, mein Fehler...

Zum Capture kann ich (noch) nichts sagen (habe es nicht nicht geladen). Auf 5201 zu filtern könnte aber Suboptimal gewesen sein, denn dann bekommst du ja nicht alles mit, was an Paketen vorbeikommt...
Mitglied: aqui
aqui 19.01.2019 aktualisiert um 13:12:00 Uhr
Goto Top
auf dem Server ist ebenfalls Bonding aktiv, siehe Screenshots.
Leider fehlt der Screenshot für den Server face-sad
Hier wird sehr oft der Fehler gemacht das eben KEIN LAG nach 802.3ad Standard mit LACP Server seitig verwendet wird sondern irgendwelche anderen Verfahren.
Aber glauben wir dir mal blind das du das richtig gemacht hast ?!
da wo die schwarzen Pakete auftauchen
Du nutzt TCP Encapsulation bei iPerf3.
Checke mal ob dieser Fehler auch auftaucht wenn du UDP Encapsulation nutzt (-u Parameter)

Desweiteren wäre noch interessant ob die HP Gurke auch wirklich beide Links im LAG nutzt ?
Gut deren Featureset ist sehr mickrig wie leider ja üblich bei HP und als einziges Hashing benutzt das Teil leider nur die Mac Adressen.
Du hast also sehr wenig Entropie im Link Sharing durch das schwache Hashing des HP. Dennoch wäre es interessant wie die Verteilung wirklich aussieht.
Kann das Teil SNMP ??
Wenn ja aktiviere das mal und siehe dir mit einem kleinen SNMP Tool (STG) mal die Last auf dem Link 6 und 7 an.
RX Dropped Pkts Problem
und poste das Ergebnis mal hier.

Es steht aber zu befürchten das das ein Firmware Bug ist. Hast du die HP Gurke auf die aktuellste Firmware geflasht ??
Aktuell ist PL2.10
https://h10145.www1.hpe.com/downloads/SoftwareReleases.aspx?ProductNumbe ...
Mitglied: Pjordorf
Pjordorf 19.01.2019 um 13:17:00 Uhr
Goto Top
Hallo,

Zitat von @Bierkistenschlepper:
Und das Problem befindet sich eindeutig auf dem Switch, da ich nach einem Neustart des Switchs ja wieder auf meine GEräte komme.
Deswegen muss aber der Switch nicht das Problem verursachen welches dazu führt das dieser seine Ports lahmlegt.

Ich habe hier mal ein Wireshark Capture gemacht. Kann damit jemand etwas anfangen?
Ich will mich aber weder dort registrieren noch anmelden nch eine Tar aus dem 7zip holen und dann noch das TAR selbst entpacken.

Das Problem beginnt ganz unten, da wo die schwarzen Pakete auftauchen. Gefiltert habe ich nach Port 5201
Oder ist das endlich das ende davon? Mal geschaut ob dieses Retransmission auftritt wenn der Port dichgemacht hat (Auch in Wireshark kann man ein aktuelles Datum/Uhrzeit einstellen. Ausserdem warum nur Port 5201? Und wer ist was mit den IPs bzw. MACs?

Wenn es über dein Netzwerk kommen sollte, müsste ja dann irgendwo in den Datenpaketen, und nicht zwingend nur auf Port 5201, und nicht nur auf diesen beiden IPs bzw. MACs beschränkt, etwas zu sehen sein welches deinen Switch veranlasst seine Ports dichtzumachen. Das direkt danach Retransmissions uftreten ist doch eine folge davon. Was sagt das LOG des Switches aus, was der Switch im Augenblick des Fehlers aus? Mit einen anderen PC/Client (mit manueller IP , kein DHCP) ist der Switch weiterhin anpingbar? Die Console sagt was, oder ist die dann auch Stumm, Blind und Taub? Wenn letzteres, Switch mal auf Werkseinstellung, dann dein iPerf nochmals testen lassen und erst bei Erfolg dein Switch langsam auf den jetzige Stand bringen, dazu zählen auch deine Trunks und Bonds usw. Oder du schaust in dein Museum ob du noch einen HP PS1810-XXG ausgestellt hast und setzt den mal ein.

Wenn du allerdings diese genaue beschaltung und Konfiguration schon erfolgreich und längere Zeit am laufen hattest...

Gruß,
Peter
Mitglied: Bierkistenschlepper
Bierkistenschlepper 20.01.2019 um 10:38:43 Uhr
Goto Top
Ich habe den Switch J9833A, das verlinkte Update war für eine andere Revision. Es gibt aber auch für meine Version die V2.10.

Das Firmwareupdate hat leider nichts geholfen. Problem besteht also weiterhin. Auffällig war, dass das Firmware-Update vom betroffenen PC den Switch ebenfalls zum Absturz brachte. Vom MacBook ging es dagegen anstandslos.

Vom MacBook Pro läuft iperf3 auch mit dem exakt gleichen Kabel wie am PC.

Mit UDP gibt es keine Probleme, allerdings kriege ich mit UDP auch nur besch** Datenraten.

cornelius@vincent ~ $ iperf3 -u -c 192.168.170.11
Connecting to host 192.168.170.11, port 5201
[  4] local 192.168.170.31 port 41961 connected to 192.168.170.11 port 5201
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  4]   0.00-1.00   sec   128 KBytes  1.05 Mbits/sec  16  
[  4]   1.00-2.00   sec   128 KBytes  1.05 Mbits/sec  16  
[  4]   2.00-3.00   sec   128 KBytes  1.05 Mbits/sec  16  
[  4]   3.00-4.00   sec   128 KBytes  1.05 Mbits/sec  16  
[  4]   4.00-5.00   sec   128 KBytes  1.05 Mbits/sec  16  
[  4]   5.00-6.00   sec   128 KBytes  1.05 Mbits/sec  16  
[  4]   6.00-7.00   sec   128 KBytes  1.05 Mbits/sec  16  
[  4]   7.00-8.00   sec   128 KBytes  1.05 Mbits/sec  16  
[  4]   8.00-9.00   sec   128 KBytes  1.05 Mbits/sec  16  
[  4]   9.00-10.00  sec   128 KBytes  1.05 Mbits/sec  16  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  1.25 MBytes  1.05 Mbits/sec  0.045 ms  1/159 (0.63%)  
[  4] Sent 159 datagrams

iperf Done.

Die o.g. IP 192.168.170.11 ist also die vom Server.

Das Log vom Switch kann ich nicht auslesen, da in dem Moment mein komplettes Netzwerk zusammenbricht. Ich komme nicht mehr auf den Switch. Und nach dem Reboot ist das Log gelöscht.

Ich werde jetzt als nächstes mal probieren, eine andere Linux-Version zu testen, vielleicht hat der Kernel 4.15 einen Bug?

Einen zweiten solchen Switch habe ich leider nicht parat.

Ich hatte es ja auch schon mal ohne Trunk bzw. Bonding probiert - gleiches Problem. Aber wenns daran liegen würde, dann müsste das Problem auch beim MBP auftreten.
Mitglied: Pjordorf
Pjordorf 20.01.2019 um 20:47:32 Uhr
Goto Top
Hallo,

Zitat von @Bierkistenschlepper:
Problem besteht also weiterhin. Auffällig war, dass das Firmware-Update vom betroffenen PC den Switch ebenfalls zum Absturz brachte. Vom MacBook ging es dagegen anstandslos.
Deutet also auf die dort verwendete NIC hin. Die mal ausgetasucht oder eine andere dort im PC verwendet?

Vom MacBook Pro läuft iperf3 auch mit dem exakt gleichen Kabel wie am PC.
Das Kabel geht oder geht nicht, das kennt keinen Unterschiede ov TCP oder UDP usw. Und es hat einen Fehler oder es hat keinen Fehler. Das ein Fehler dort nur bei/durch bestimmte Daten oder Protokolle auftritt ist doch mehr als ungewöhnlich face-smile

Die o.g. IP 192.168.170.11 ist also die vom Server.
OK

Das Log vom Switch kann ich nicht auslesen, da in dem Moment mein komplettes Netzwerk zusammenbricht.
Da das ja bekannt ist das dein Nezuerk bei diesem Fehler komplett zusammenbricht, wäre es doch sicherlich klug gewesen das log vom Schwitch schon vorher (im Funktionsfähigen zustand) angezapft zu haben oder das Log auf einen LogServer ausgeben zu lassen damit du mal schauen was denn vorher passiert usw. Das muss halt alles vorher vorbereitet sein und bracht halt mehrere Messpunkte (Rechner und Software). Im nachhinein wenn alles steht ist es zu Spät. Sind dann alle Ports dicht? Was ist mit den Consolen Port oder hat es keinen? Und wenn ja, ist der Port dann auch Putt wenn der vorher noch funktionierte?

Ich komme nicht mehr auf den Switch.
Deshalb muss ja auch schon vorher alles aufgebaut und funktionsfähig sein...

Und nach dem Reboot ist das Log gelöscht.
Das haben manche Komponenten in ein Netzwerk so an sich.
https://community.hpe.com/t5/Web-and-Unmanaged/HP-ProCurve-1810G-24-SNMP ...
https://community.hpe.com/t5/Aruba-ProVision-based/Syslog-configuration/ ...
https://www.manualslib.com/manual/791725/Hp-Procurve-1810g.html?page=64
ftp://ftp.hp.com/pub/networking/software/59906028_ap-A.pdf
https://support.hpe.com/hpsc/doc/public/display?docId=mmr_kc-0125066

Ich werde jetzt als nächstes mal probieren, eine andere Linux-Version zu testen, vielleicht hat der Kernel 4.15 einen Bug?
face-smile

Gruß,
Peter
Mitglied: Bierkistenschlepper
Bierkistenschlepper 24.01.2019 aktualisiert um 18:57:39 Uhr
Goto Top
Hallo,

ich habe inzwischen eher den Netzwerkchip im Verdacht. Zwar habe ich zwei PCIe Karten probiert, diese haben aber beide einen Realtek Chip. Mit dem Chip der neu gekauften Karte, dem Realtek 8168E gab es früher mal massive Probleme mit dem Linux Kernel. Die Karten wurden überhaupt nicht erkannt. Erkannt werden sie inzwischen, aber ich vermute bei voller Auslastung durch iperf3 läuft irgendwas schief. Dies passiert dann auch, wenn man z.B. das Update auf den Switch hochlädt.

Ich benutze nun also wieder den Onboard NIC meines Asus Z170A Pro. Dieser liefert halt keine volle Gigabit-Geschwindigkeit, aber dafür bricht das Netz nicht mehr zusammen.

cornelius@vincent ~ $ iperf3 -c 192.168.170.11
Connecting to host 192.168.170.11, port 5201
[  4] local 192.168.170.20 port 56022 connected to 192.168.170.11 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  93.5 MBytes   784 Mbits/sec    0    373 KBytes       
[  4]   1.00-2.00   sec  90.5 MBytes   759 Mbits/sec    0    373 KBytes       
[  4]   2.00-3.00   sec  91.3 MBytes   766 Mbits/sec    0    373 KBytes       
[  4]   3.00-4.00   sec  91.6 MBytes   768 Mbits/sec    0    373 KBytes       
[  4]   4.00-5.00   sec  91.8 MBytes   770 Mbits/sec    0    373 KBytes       
[  4]   5.00-6.00   sec  91.7 MBytes   769 Mbits/sec    0    392 KBytes       
[  4]   6.00-7.00   sec  91.6 MBytes   768 Mbits/sec    0    392 KBytes       
[  4]   7.00-8.00   sec  90.5 MBytes   759 Mbits/sec    0    392 KBytes       
[  4]   8.00-9.00   sec  91.7 MBytes   769 Mbits/sec    0    392 KBytes       
[  4]   9.00-10.00  sec  92.5 MBytes   776 Mbits/sec    0    530 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec   917 MBytes   769 Mbits/sec    0             sender
[  4]   0.00-10.00  sec   914 MBytes   766 Mbits/sec                  receiver

iperf Done.

Kann das an der Schirmung /ATX-Blende liegen? Ich musste hinten an dem Anschluss einen Blechpin an der Netzwerkbuchse rausbiegen, weil ich den bei der Montage des Motherboards vergessen hatte. Ich frage mal lieber vorher, da mir dann eventuell ein Ausbau des Motherboards erspart bleibt face-smile
Mitglied: Pjordorf
Pjordorf 24.01.2019 aktualisiert um 19:57:59 Uhr
Goto Top
Hallo,

Zitat von @Bierkistenschlepper:
ich habe inzwischen eher den Netzwerkchip im Verdacht.
Nur im Verdacht oder doch etwas konkretes? Sollte man im Switch Log dann auch sehen wenn der Port wo dein Verdacht dran hängt fehlerhafte Pakete oder sonst was empfängt und sich anschliessend dein Switch aufhängt. Was steht also da drin?

Zwar habe ich zwei PCIe Karten probiert, diese haben aber beide einen Realtek Chip.
Und beide haben den Switch zum Stillstand gebracht?
Und wie ist es mit einer Intel Gigabit CT Desktop Adapter (Kostet nicht viel)?
Und beide Karten haben den selben Fehler oder verhalten sich identisch grade was das Fehlerbild betrifft? Unwahrscheinlich, ausser dein PC hat eine Macke.

Erkannt werden sie inzwischen, aber ich vermute
Nicht Vermuten.

bei voller Auslastung durch iperf3 läuft irgendwas schief.
Auch das kann dir ein Wireshark mitschnitt sagen
Verifiziere das mal NetIO, da müsste dein Switch ja dann auch sich geschlagen geben...
Mal andere Ports anm Switch genommen?

Ich benutze nun also wieder den Onboard NIC meines Asus Z170A Pro.
Und das ist auch ein REALTEK Chipsatz? Nee, Asus sagt es ist eine Intel, und zwar eine Intel® I219V, 1 x Gigabit LAN Controller

Kann das an der Schirmung /ATX-Blende liegen?
Nee. Ist ja nur der Schirm (nein, kein Regenschirm face-smile

Ich musste hinten an dem Anschluss einen Blechpin an der Netzwerkbuchse rausbiegen
!?! Hä? Bild machen

weil ich den bei der Montage des Motherboards vergessen hatte.
Noch mehr Fragezeichen und Unverständnis

https://www.ebay.de/p/HP-Gigabit-8-port-Managed-Switch-Ps1810-8g-j9833a/ ...

Und das Fehlerbild tritt nur auf wenn dein PC mit iPerf3 sich beschäftigt, mit anderen PCs oder Ports passiert es nicht? Auch ein Switch kann mal einen Fehler haben bzw. defekt werden.

Gruß,
Peter
Mitglied: Bierkistenschlepper
Bierkistenschlepper 26.01.2019 um 09:18:45 Uhr
Goto Top
Ganz ehrlich, das mit dem SysLog des Switches auf einem Server ist mir jetzt zu kompliziert. _Ich bin Heimadmin und keine Firma.

Der Switch ist sehr teuer gewesen und ein hochwertiges Gerät. Er funktioniert mit sämtlichen Netzwerkgeräten einwandfrei, bis auf diesen PC hier auf Basis des Z170A Pro. Mit dem alten Motherboard habe ich auch volle Geschwindigkeit erreicht. Und ja beide Realtek NICs (unterschiedliche Chips, die eine ist ja schon 5 Jahre alt) legen den Switch reproduzierbar lahm.

Die Realtek NICs werden halt (zusammen mit Kernel-Bugs und iperf3) irgendwelche kaputten Pakete schicken. Ich habe gerade mal eine 2 GB große Datei per NFS Share kopiert, keine Probleme. Auch sonst habe ich nie Probleme, solange ich eben kein iperf benutze.

Was ich mit dem Onboard Netzwerk Blech meinte, sieht man im Bild. Kann das eurer Meinung nach für die schwache Leistung verantwortlich sein? Ich denke eher nicht. Und um das richtig zu machen müsste ich das Mainboard eben ausbauen.

Für mich ist das Problem gegessen. Hab da schon viel zu viel Zeit reingesteckt und wenn ich mir mal nen neuen Rechner hinstelle, wird vermutlich alles funzen. Das sind eben Probleme, die man mit OpenSource Betriebssystemen und selbst zusammengebauten Rechnern hat.
img_20190126_084903
Mitglied: aqui
aqui 26.01.2019 um 19:12:30 Uhr
Goto Top
as mit dem SysLog des Switches auf einem Server ist mir jetzt zu kompliziert.
Na komm...nicht dein Ernst oder ??
Maximal 3 Minuten. Das kann sogar der Hund vom Nachbarn wenn er ein Frolic dafür bekommt.
Der Switch ist sehr teuer gewesen und ein hochwertiges Gerät.
Ha ha ha...netter Witz. Das ist ein billiger Web Smart Switch unterster Kategorie. Hochwertig ist was anderes.
User mit Cisco Catalysten können da nur gequält lachen wenn jemand bei solchen HP Billiggurken von hochwertig reden... Das der bei einem klein bischen TCP Last ins Nirwana segelt wundert einen also nicht wirklich groß. Du solltest da also mal die Kirche im Dorf lassen. Aber egal...andere Baustelle.
Die Realtek NICs werden halt irgendwelche kaputten Pakete schicken
Das wäre theoretisch möglich. Realtek Chips sind berühmt berüchtigt dafür. Das liegt daran das sie ein Großteil des Paket Handlings der rechner CPU aufbürden, da sie als Billigchipsatz diese Resourcen nicht haben wie z.B. Intel und Broadcom Chipsätze. Entsprechend schelcht ist auch ihre Performance und generell eine vollkommen falsche Wahl wenn es um Storage Protokolle im Netzwerk geht !!
Wenn, dann solltest du die immer nur mit den original Treibern betreiben:
https://www.realtek.com/en/component/zoo/advanced-search/72?Itemid=276
Eigentlich kann man das aber ausschliessen, da gute Switches kaputte Frames einfach droppen. Ebenso das Bleck im Rechner (Foto) das ist dafür ganz sicher nicht verantwortlich.
Testweise kannst du ja mal einen unmanaged Billigswitch nehmen und sehen was der so schaufeln kann:
https://www.reichelt.de/switch-8-port-fast-ethernet-zyxel-es-108av3-p232 ...
https://www.reichelt.de/switch-5-port-gigabit-ethernet-d-link-go-sw-5g-p ...
Für mich ist das Problem gegessen. Hab da schon viel zu viel Zeit reingesteckt
OK, dann ist ja eh gut face-wink
Case closed !
Mitglied: Pjordorf
Lösung Pjordorf 26.01.2019 aktualisiert um 20:12:06 Uhr
Goto Top
Hallo,

Zitat von @Bierkistenschlepper:
Ganz ehrlich, das mit dem SysLog des Switches auf einem Server ist mir jetzt zu kompliziert.
Nimmst du hiervon was du brauchst und nutzt nur den SysLog teil, Konfigurieren und dein Kaffe ist noch nicht fertig gekocht.

Der Switch ist sehr teuer gewesen und ein hochwertiges Gerät.
Beides ist eine eher Relative Aussage

Datei per NFS Share kopiert, keine Probleme.
Nur das dein iPERF3 kein NFS nutzt

Was ich mit dem Onboard Netzwerk Blech meinte, sieht man im Bild.
Wie hat man das denn geschafft, Hat da jemand versucht den Nippel durch die Lasche zu ziehen?

Kann das eurer Meinung nach für die schwache Leistung verantwortlich sein?
Ne. Das beeinflusst nicht die Leistung, es kann höchsten für eine nicht Funktion deiner NIC sorgen

Und um das richtig zu machen müsste ich das Mainboard eben ausbauen.
Und was hindert den Heimadmin?

Für mich ist das Problem gegessen. Hab da schon viel zu viel Zeit reingesteckt
und wenn ich mir mal nen neuen Rechner hinstelle, wird vermutlich alles funzen.
Sicher das dann deine Probleme verschwunden sind?

Das sind eben Probleme, die man mit OpenSource Betriebssystemen und selbst zusammengebauten Rechnern hat.
Warum das denn? Dann müssten ja Millionen von Rechnern und Switchen es nicht tun
Du hast eine LifetimeWarranty von HPE. Wenn die noch greift, tausche den Switch.

Gruß,
Peter