12
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
Auf den Clients
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:
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:
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
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 -sAuf den Clients
iperf3 -c 192.168.170.11MacBook 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 terminatedEs 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 msBin 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
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: 398711
Url: https://administrator.de/forum/hp-ps1810-8g-switch-stuerzt-bei-iperf3-ab-398711.html
Ausgedruckt am: 23.12.2024 um 18:12 Uhr
12 Kommentare
Neuester Kommentar
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
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
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.
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.
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...
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...
auf dem Server ist ebenfalls Bonding aktiv, siehe Screenshots.
Leider fehlt der Screenshot für den Server 
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 ...
Hallo,
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
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.Und das Problem befindet sich eindeutig auf dem Switch, da ich nach einem Neustart des Switchs ja wieder auf meine GEräte komme.
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
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.
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.
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.
Hallo,
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
Gruß,
Peter
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?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.
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 Die o.g. IP 192.168.170.11 ist also die vom Server.
OKDas 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?
Gruß,
Peter
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.
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
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
Hallo,
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?
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.
Verifiziere das mal NetIO, da müsste dein Switch ja dann auch sich geschlagen geben...
Mal andere Ports anm Switch genommen?
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
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 sagenVerifiziere 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 ControllerKann das an der Schirmung /ATX-Blende liegen?
Nee. Ist ja nur der Schirm (nein, kein Regenschirm Ich musste hinten an dem Anschluss einen Blechpin an der Netzwerkbuchse rausbiegen
!?! Hä? Bild machenweil ich den bei der Montage des Motherboards vergessen hatte.
Noch mehr Fragezeichen und Unverständnishttps://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
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.
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.
as mit dem SysLog des Switches auf einem Server ist mir jetzt zu kompliziert.
Na komm...nicht dein Ernst oder ??- Kostenlosen Syslog Server installieren: https://www.kiwisyslog.com/free-tools/kiwi-free-syslog-server
- Syslog Server IP im Switch einstellen
- Fertisch...
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 
Case closed !
Hallo,
Du hast eine LifetimeWarranty von HPE. Wenn die noch greift, tausche den Switch.
Gruß,
Peter
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.Ganz ehrlich, das mit dem SysLog des Switches auf einem Server ist mir jetzt zu kompliziert.
Der Switch ist sehr teuer gewesen und ein hochwertiges Gerät.
Beides ist eine eher Relative AussageDatei per NFS Share kopiert, keine Probleme.
Nur das dein iPERF3 kein NFS nutztWas 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 sorgenUnd 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?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.
Warum das denn? Dann müssten ja Millionen von Rechnern und Switchen es nicht tunDu hast eine LifetimeWarranty von HPE. Wenn die noch greift, tausche den Switch.
Gruß,
Peter
