Netzwerk lahmt, keine Idee woran es liegen könnte

[dfarin]

Hallo zusammen,
ich nutze aktuell ein Debian Squeeze Server in meinem Heimnetzwerk als "Fileserver".
Während ich vorher Daten mit rund 60/70 MB/s verschoben habe ist der Speed seit einigen Tagen komplett zusammen gebrochen (600/700 KB/s) und ich habe keine Idee woran es liegen könnte.
Hier mal ein paar Daten, sagt mir bitte wenn ihr noch etwas anderes braucht.

hdparm:

Code: Alles auswählen

giant:/home# hdparm -t /dev/sda1
/dev/sda1:
 Timing buffered disk reads: 314 MB in  3.01 seconds = 104.48 MB/sec

giant:/home# hdparm -t /dev/sdb1
/dev/sdb1:
 Timing buffered disk reads: 618 MB in  3.01 seconds = 205.58 MB/sec

ethtool

Code: Alles auswählen

giant:/home# ethtool eth0
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: umbg
        Wake-on: g
        Current message level: 0x00000007 (7)
        Link detected: yes

giant:/home# ethtool eth3
Settings for eth3:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Half 1000baseT/Full
        Link partner advertised pause frame use: No
        Link partner advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000033 (51)
        Link detected: yes

ifconfig -a

Code: Alles auswählen

giant:/home# ifconfig -a
eth0      Link encap:Ethernet  Hardware Adresse 00:0e:0c:c4:17:1a
          inet Adresse:192.168.2.3  Bcast:192.168.2.255  Maske:255.255.255.0
          inet6-Adresse: fe80::20e:cff:fec4:171a/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:6370521 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8635370 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:7353215408 (6.8 GiB)  TX bytes:8825020545 (8.2 GiB)

eth3      Link encap:Ethernet  Hardware Adresse 00:1a:92:92:79:59
          inet Adresse:192.168.2.4  Bcast:192.168.2.255  Maske:255.255.255.0
          inet6-Adresse: fe80::21a:92ff:fe92:7959/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:80388 errors:0 dropped:0 overruns:0 frame:0
          TX packets:116 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:25414293 (24.2 MiB)  TX bytes:13241 (12.9 KiB)
          Interrupt:27 Basisadresse:0xa000

lo        Link encap:Lokale Schleife
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:16436  Metrik:1
          RX packets:119024 errors:0 dropped:0 overruns:0 frame:0
          TX packets:119024 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX bytes:324713889 (309.6 MiB)  TX bytes:324713889 (309.6 MiB)

pan0      Link encap:Ethernet  Hardware Adresse 5e:ea:62:60:36:b5
          BROADCAST MULTICAST  MTU:1500  Metrik:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

netio

Code: Alles auswählen

giant:/home/netio132/bin# ./linux-x86_64 -t 192.168.2.83

NETIO - Network Throughput Benchmark, Version 1.31
(C) 1997-2010 Kai Uwe Rommel

TCP connection established.
Packet size  1k bytes:  3119.45 KByte/s Tx,  1750.59 KByte/s Rx.
Packet size  2k bytes:  2779.33 KByte/s Tx,  1502.39 KByte/s Rx.
Packet size  4k bytes:  2694.67 KByte/s Tx,  2442.68 KByte/s Rx.
Packet size  8k bytes:  2844.00 KByte/s Tx,  2454.83 KByte/s Rx.
Packet size 16k bytes:  2637.45 KByte/s Tx,  2367.34 KByte/s Rx.
Packet size 32k bytes:  2677.25 KByte/s Tx,  2421.33 KByte/s Rx.
Done.

wget

Code: Alles auswählen

giant:/home# wget http://speedtest.netcologne.de/test_1gb.bin
--2015-07-13 10:44:25--  http://speedtest.netcologne.de/test_1gb.bin
Auflösen des Hostnamen speedtest.netcologne.de... 194.8.194.20
Verbindungsaufbau zu speedtest.netcologne.de|194.8.194.20|:80... verbunden.
HTTP-Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 1073741824 (1,0G) [application/octet-stream]
In »test_1gb.bin.1« speichern.

100%[=====================================================================================================>] 1.073.741.824 15,5M/s   in 78s

2015-07-13 10:45:44 (13,0 MB/s) - »test_1gb.bin.1« gespeichert [1073741824/1073741824]

[uname]

Mir ist aufgefallen, dass dein Fileserver zwei Netzwerkkarten im selben Netzwerk hat. Muss das so? Auch könntest du IPv6 deaktivieren falls nicht wirklich benötigt.

[dfarin]

Naja, ich habs halt mal vor urzeiten so eingerichtet.
Normalerweise ist eth3 jedoch nicht im Netz, lediglich aktuell wieder angestöpselt weil ich auf der Suche nach dem Problem bin und testen wollte ob die Netzwerkkarte eventuell einen wech hat.
IPV6 hat bisher nicht wirklich ein Problem verursacht, daher ungerne, aber wenn es dir bei der Fehlersuche hilft teste ich das selbstverständlich für dich.
Daher die Frage, wie würde es dir helfen wenn ich IPv6 deaktiviere, denn wirklich brauchen tu ich das natürlich nicht.

[uname]

Also zwei Netzwerkkarten für dasselbe Netzwerk zu konfigurieren ist keine gute Idee. Schau dir vorher und nachher am besten noch die Routing-Tabelle an.

Code: Alles auswählen

route -n

[Six]

Wenn das "seit einigen Tagen" so ist, dann denke scharf darüber nach, was du damals an deinem Netzwerk geändert hast. Bis es dir einfällt, nimmst du eines der beiden Interfaces aus 192.168.2.0/24 raus. GNU/Linux ist ein sogn. weak end system und verträgt eine solche Konfiguration nicht.

[Six]

Als weitere Diagnoseschritte:

1) führe ping gegen Namen und IP durch. Wie lange sind die Antwortzeiten? Gibt es Paketverluste?
2) führe traceroute durch. Gibt es auffällige Hops? (in einem LAN sollte es gar keine Hops geben).
3) lass tcpdump mitlaufen und gucke, ob ACKs oder SYNs ausbleiben oder sonstige Auffälligkeiten zu sehen sind.

[catdog2]

Auch könntest du IPv6 deaktivieren falls nicht wirklich benötigt.

Was soll immer dieser Mist den Leuten das ohne Indikation irgendeines Problems Vorzuschlagen? Macht das Spass?

edit://
Vielleicht mal eine Direktverbindung zu einem anderen Rechner ausprobieren um dem Switch aus dem Spiel zu nehmen.

NU/Linux ist ein sogn. weak end system und verträgt eine solche Konfiguration nicht.

Natürlich verträgt es das ist nur nicht sonderlich sinnvoll.

[dfarin]

Also zwei Netzwerkkarten für dasselbe Netzwerk zu konfigurieren ist keine gute Idee. Schau dir vorher und nachher am besten noch die Routing-Tabelle an.

Code: Alles auswählen

route -n

Kabel ist wieder raus, wie gesagt, eth3 ist normalerweise nicht in Benutzung sondern dient idR nur als Möglichkeit mal was zu testen wenn zB so wie jetzt, irgendetwas seltsames passiert.

Wenn das "seit einigen Tagen" so ist, dann denke scharf darüber nach, was du damals an deinem Netzwerk geändert hast. Bis es dir einfällt, nimmst du eines der beiden Interfaces aus 192.168.2.0/24 raus. GNU/Linux ist ein sogn. weak end system und verträgt eine solche Konfiguration nicht.

Ich weiß, hört man immer wieder, aber NICHTS. Der Server wird idR nichtmal neu gestartet, warum auch, lief ja nun fast 6 Monate ohne Probleme. Die anfallenden Neutstarts haben sich auch auf HDD Austausch für den Raid beschränkt. Wenn das System sauber läuft gibt´s nicht mal ein update.
Ich vermutete erst einen Windows Patch als Ursache, das konnte ich aber ausschließen da ich andere Clients getestet habe die diesen Patch noch nicht haben.

Als weitere Diagnoseschritte:

1) führe ping gegen Namen und IP durch. Wie lange sind die Antwortzeiten? Gibt es Paketverluste?
2) führe traceroute durch. Gibt es auffällige Hops? (in einem LAN sollte es gar keine Hops geben).
3) lass tcpdump mitlaufen und gucke, ob ACKs oder SYNs ausbleiben oder sonstige Auffälligkeiten zu sehen sind.

1. Ping

PING 192.168.2.83 (192.168.2.83) 56(84) bytes of data.
64 bytes from 192.168.2.83: icmp_req=1 ttl=128 time=2.57 ms
64 bytes from 192.168.2.83: icmp_req=2 ttl=128 time=2.80 ms
64 bytes from 192.168.2.83: icmp_req=3 ttl=128 time=1.34 ms
64 bytes from 192.168.2.83: icmp_req=4 ttl=128 time=1.44 ms

PING dfmain (192.168.2.83) 56(84) bytes of data.
64 bytes from dfmain.fritz.box (192.168.2.83): icmp_req=1 ttl=128 time=3.04 ms
64 bytes from dfmain.fritz.box (192.168.2.83): icmp_req=2 ttl=128 time=2.97 ms
64 bytes from dfmain.fritz.box (192.168.2.83): icmp_req=3 ttl=128 time=2.81 ms
64 bytes from dfmain.fritz.box (192.168.2.83): icmp_req=4 ttl=128 time=2.02 ms

C:\WINDOWS\system32>ping 192.168.2.1

Ping wird ausgeführt für 192.168.2.1 mit 32 Bytes D
Antwort von 192.168.2.1: Bytes=32 Zeit=2ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=2ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=3ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=1ms TTL=64

Ping-Statistik für 192.168.2.1:
Pakete: Gesendet = 4, Empfangen = 4, Verloren =
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 1ms, Maximum = 3ms, Mittelwert = 2ms

C:\WINDOWS\system32>ping 192.168.2.1

Ping wird ausgeführt für 192.168.2.1 mit 32 Bytes D
Antwort von 192.168.2.1: Bytes=32 Zeit=2ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=2ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=3ms TTL=64
Antwort von 192.168.2.1: Bytes=32 Zeit=1ms TTL=64

Ping-Statistik für 192.168.2.1:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 1ms, Maximum = 3ms, Mittelwert = 2ms

2. traceroute

giant:/home# traceroute 192.168.2.83
traceroute to 192.168.2.83 (192.168.2.83), 30 hops max, 60 byte packets
1 dfmain.fritz.box (192.168.2.83) 10.731 ms * *

C:\WINDOWS\system32>tracert 192.168.2.3
Routenverfolgung zu giant2.fritz.box [192.168.2.3]
über maximal 30 Hops:
1 3 ms 1 ms <1 ms giant2.fritz.box [192.168.2.3]

Ablaufverfolgung beendet.

3. tcpdump
Wie kann ich dir da eine Logdatei erstellen ?

[Six]

Code: Alles auswählen

tcpdump -i eth0 -w tcpdump.txt

[dfarin]

Ich danke euch für die ganze angebotene Hilfe.
Bis jetzt weiß ich nicht woran es lag, ich hab nun aber einfach mal den kompletten Haushalt für 10min Stromlos gemacht und siehe da, nun zeigt netio folgendes und ich bin wieder happy:

giant:/home/netio132/bin# ./linux-x86_64 -t 192.168.2.83

NETIO - Network Throughput Benchmark, Version 1.31
(C) 1997-2010 Kai Uwe Rommel

TCP connection established.
Packet size 1k bytes: 99.10 MByte/s Tx, 89.14 MByte/s Rx.
Packet size 2k bytes: 99.60 MByte/s Tx, 78.60 MByte/s Rx.
Packet size 4k bytes: 98.94 MByte/s Tx, 88.77 MByte/s Rx.
Packet size 8k bytes: 99.59 MByte/s Tx, 98.16 MByte/s Rx.
Packet size 16k bytes: 99.56 MByte/s Tx, 85.87 MByte/s Rx.
Packet size 32k bytes: 99.56 MByte/s Tx, 94.65 MByte/s Rx.
Done.

[dfarin]

Wirklich kurios, 2 Stunden später:

Code: Alles auswählen

giant:/home/netio132/bin# ./linux-x86_64 -t 192.168.2.83

NETIO - Network Throughput Benchmark, Version 1.31
(C) 1997-2010 Kai Uwe Rommel

TCP connection established.
Packet size  1k bytes:  32.26 MByte/s Tx,  27.89 MByte/s Rx.
Packet size  2k bytes:  24.28 MByte/s Tx,  8843.14 KByte/s Rx.
Packet size  4k bytes:  23.70 MByte/s Tx,  24.23 MByte/s Rx.
Packet size  8k bytes:  23.47 MByte/s Tx,  5013.98 KByte/s Rx.
Packet size 16k bytes:  22.03 MByte/s Tx,  1903.15 KByte/s Rx.
Packet size 32k bytes:  22.92 MByte/s Tx,  2002.79 KByte/s Rx.
Done.

Ich werde jetzt noch etwas abwarten und auf jeden Fall noch die Direktverbindung testen.

[eggy]

poste mal den output von "route -n"

[dfarin]

Klaro doch, wobei nach diversen Kilometern nun wohl recht offensichtlich ist das mein 24p Switch einen wech hat.
Da ich mehrer Switches nutze um auch in jedem Raum eine ordentliche Kabelverbindung zu haben musste ich halt viel hin- und herstecken um das schadhafte Gerät zu finden

Aber gerne noch route -n

Code: Alles auswählen

giant:~# route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 eth3
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 eth3
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 eth0

[eggy]

Versuch mal ob "ungenutztes Interface deaktivieren" (ifconfig eth3 down) nicht doch was bringt.
Dein Routing sieht jedenfalls etwas schizophren aus. Pakete über nen Interface rausschicken an dem kein Kabel ist, könnte ein guter Grund für nen langsames Netz sein.

[dfarin]

Versuch mal ob "ungenutztes Interface deaktivieren" (ifconfig eth3 down) nicht doch was bringt.
Dein Routing sieht jedenfalls etwas schizophren aus. Pakete über nen Interface rausschicken an dem kein Kabel ist, könnte ein guter Grund für nen langsames Netz sein.

Ich würde dir SOFORT recht geben, wirklich SOFORT, aber es hat seit .. ufz ka seit wann gibt es squeeze?.... NIE Probleme gemacht. Warum also urplötzlich nach etlichen Monaten Dauerbetrieb ohne Änderung oder update ?
Und Performance, jau, mag sein, möchte ich gar nicht abstreiten das mein System alles andere als optimal ist, allerdings ist es ausreichend für mehrere, zeitgleiche HD-Streams + 2x großes Backup von laufenden Clients. Was will ich denn mehr?

Ok, das ich alle 2-3 Monate mal ne HDD tauschen muss nervt noch arg, aber das ist mir die Datensicherheit zumindest noch wert.

Das nun nach 1,5 Jahren auf einmal der Switch teils abraucht, pfff, ok auf die Idee wäre ich nicht so schnell gekommen. Der letzte hat locker 8 Jahre gehalten ohne Mucken.

[dfarin]

Versuch mal ob "ungenutztes Interface deaktivieren" (ifconfig eth3 down) nicht doch was bringt.
Dein Routing sieht jedenfalls etwas schizophren aus. Pakete über nen Interface rausschicken an dem kein Kabel ist, könnte ein guter Grund für nen langsames Netz sein.

btw. habs aber gern mal getestet weil es das system eh nicht beschädigt, bzw keine Probleme macht.

Bringen tuts aber nichts, wie auch wenn der switch hinüber ist

[eggy]

Die Praxis zeigt "komische IP Konfigurationen" sind in den meisten Fällen doof. Und komisches Routing gehört da auch mit rein. Wie löst der Rechner (oder besser noch andere Kisten) seinen Namen auf, an welches Interface sollen die Antwort-Pakete gehen? Kiste A redet mit B, Routen zu A sagen aber A wird auf C angesprochen, Interface A (bzw die Dienste die dort lauschen/stateful firewall) weis nix mit den Paketen anzufangen, weil "hab ich nicht bestellt" ... Verwirrung pur ... und einige Dienste mögen sowas garnicht. Alles jetzt zwar grad nicht Dein Problem, aber sowas kann halt zu komischen Effekten führen.

Falls Du Dich doch noch dazu entschließt, dass es doch nicht am Switch liegt, würd ich mal schauen, ob übermässig viele ARP Anfragen im Netz unterwegs sind.

Und "mehrere Switches" ist unter Umständen auch ne gute Quelle für "langsam" (Signalqualität fällt sporadisch unter nen brauchbares Niveau, was bei TCP zwar nicht weiter wild ist, fehlendes Zeug wird einfach nochmal verschickt aber dabei geht eben auch die Übertragungsgeschwindigkeit runter)

[dfarin]

Naja, aber eth3 ist doch nicht angeklemmt, also, nicht im Netzwerk vorhanden.
Wiso sollten da Probleme Auftreten?

Und, ich habe es ja doch extra für dich probiert, gebracht hat es jedoch nichts.