Ausgehende TCP-Pakete extrem klein

[xray]

Hallo Community,

nach 3 Wochen google, probieren und experimitieren bin ich mit meinem Latein am Ende und hoffe auf eure Hilfe hier im Forum.

Ich kämpfe mit folgendem Problem ... Netzwerktraffic (1GB-LAN), der auf den Server ankommt geht hoch bis 80MB/s alles was den Server "verlässt" schwankt zwischen 1-3MB/s.

Es ist egal ob FTP, Samba, IPERF, etc immer das gleiche phänomen.

Ich bin soweit gekommen, das ich glaube, dass das Problem bei TCP liegt ...

Incomming:

Code: Alles auswählen

19:49:25.310482 IP (tos 0x0, ttl 128, id 30110, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.1.10.49288 > 192.168.1.2.20: . 3189329:3190777(1448) ack 1 win 260 <nop,nop,timestamp 148338 327060>
19:49:25.310490 IP (tos 0x0, ttl 128, id 30111, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.1.10.49288 > 192.168.1.2.20: . 3190777:3192225(1448) ack 1 win 260 <nop,nop,timestamp 148338 327060>
19:49:25.310643 IP (tos 0x0, ttl 128, id 30115, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.1.10.49288 > 192.168.1.2.20: . 3195121:3196569(1448) ack 1 win 260 <nop,nop,timestamp 148338 327060>
19:49:25.310657 IP (tos 0x0, ttl 128, id 30116, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.1.10.49288 > 192.168.1.2.20: . 3196569:3198017(1448) ack 1 win 260 <nop,nop,timestamp 148338 327060>
19:49:25.310668 IP (tos 0x0, ttl 128, id 30117, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.1.10.49288 > 192.168.1.2.20: . 3198017:3199465(1448) ack 1 win 260 <nop,nop,timestamp 148338 327060>
19:49:25.310821 IP (tos 0x0, ttl 128, id 30122, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.1.10.49288 > 192.168.1.2.20: . 3205257:3206705(1448) ack 1 win 260 <nop,nop,timestamp 148338 327060>
19:49:25.310830 IP (tos 0x0, ttl 128, id 30123, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.1.10.49288 > 192.168.1.2.20: . 3206705:3208153(1448) ack 1 win 260 <nop,nop,timestamp 148338 327060>
19:49:25.310837 IP (tos 0x0, ttl 128, id 30124, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.1.10.49288 > 192.168.1.2.20: . 3208153:3209601(1448) ack 1 win 260 <nop,nop,timestamp 148338 327060>
19:49:25.310949 IP (tos 0x0, ttl 128, id 30128, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.1.10.49288 > 192.168.1.2.20: . 3213945:3215393(1448) ack 1 win 260 <nop,nop,timestamp 148338 327060>
19:49:25.310964 IP (tos 0x0, ttl 128, id 30129, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.1.10.49288 > 192.168.1.2.20: . 3215393:3216841(1448) ack 1 win 260 <nop,nop,timestamp 148338 327060>
19:49:25.310974 IP (tos 0x0, ttl 128, id 30130, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.1.10.49288 > 192.168.1.2.20: . 3216841:3218289(1448) ack 1 win 260 <nop,nop,timestamp 148338 327060>
19:49:25.311082 IP (tos 0x0, ttl 128, id 30133, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.1.10.49288 > 192.168.1.2.20: . 3221185:3222633(1448) ack 1 win 260 <nop,nop,timestamp 148338 327060>
19:49:25.318967 IP (tos 0x0, ttl 128, id 30532, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.1.10.49288 > 192.168.1.2.20: . 3795737:3797185(1448) ack 1 win 260 <nop,nop,timestamp 148338 327062>
19:49:25.320334 IP (tos 0x0, ttl 128, id 30536, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.1.10.49288 > 192.168.1.2.20: . 3801529:3802977(1448) ack 1 win 260 <nop,nop,timestamp 148339 327062>
19:49:25.320345 IP (tos 0x0, ttl 128, id 30537, offset 0, flags [DF], proto TCP (6), length 1500) 192.168.1.10.49288 > 192.168.1.2.20: . 3802977:3804425(1448) ack 1 win 260 <nop,nop,timestamp 148339 327062>

Outgoing:

Code: Alles auswählen

19:35:27.643407 IP (tos 0x0, ttl 128, id 26076, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.10.49201 > 192.168.1.2.20: ., cksum 0x6311 (correct), 1:1(0) ack 6576817 win 260 <nop,nop,timestamp 64570 117643>
19:35:27.643553 IP (tos 0x0, ttl 128, id 26077, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.10.49201 > 192.168.1.2.20: ., cksum 0x57c1 (correct), 1:1(0) ack 6579713 win 260 <nop,nop,timestamp 64570 117643>
19:35:27.643706 IP (tos 0x0, ttl 128, id 26079, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.10.49201 > 192.168.1.2.20: ., cksum 0x4c71 (correct), 1:1(0) ack 6582609 win 260 <nop,nop,timestamp 64570 117643>
19:35:27.643862 IP (tos 0x0, ttl 128, id 26081, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.10.49201 > 192.168.1.2.20: ., cksum 0x4121 (correct), 1:1(0) ack 6585505 win 260 <nop,nop,timestamp 64570 117643>
19:35:27.644019 IP (tos 0x0, ttl 128, id 26083, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.10.49201 > 192.168.1.2.20: ., cksum 0x35d1 (correct), 1:1(0) ack 6588401 win 260 <nop,nop,timestamp 64570 117643>
19:35:27.644161 IP (tos 0x0, ttl 128, id 26084, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.10.49201 > 192.168.1.2.20: ., cksum 0x2a80 (correct), 1:1(0) ack 6591297 win 260 <nop,nop,timestamp 64570 117644>
19:35:27.644322 IP (tos 0x0, ttl 128, id 26086, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.10.49201 > 192.168.1.2.20: ., cksum 0x1f30 (correct), 1:1(0) ack 6594193 win 260 <nop,nop,timestamp 64570 117644>
19:35:27.644461 IP (tos 0x0, ttl 128, id 26087, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.10.49201 > 192.168.1.2.20: ., cksum 0x13e0 (correct), 1:1(0) ack 6597089 win 260 <nop,nop,timestamp 64570 117644>
19:35:27.644617 IP (tos 0x0, ttl 128, id 26089, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.10.49201 > 192.168.1.2.20: ., cksum 0x0890 (correct), 1:1(0) ack 6599985 win 260 <nop,nop,timestamp 64570 117644>
19:35:27.644758 IP (tos 0x0, ttl 128, id 26090, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.10.49201 > 192.168.1.2.20: ., cksum 0xfd3f (correct), 1:1(0) ack 6602881 win 260 <nop,nop,timestamp 64570 117644>
19:35:27.644917 IP (tos 0x0, ttl 128, id 26092, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.10.49201 > 192.168.1.2.20: ., cksum 0xf1ef (correct), 1:1(0) ack 6605777 win 260 <nop,nop,timestamp 64570 117644>
19:35:27.645059 IP (tos 0x0, ttl 128, id 26093, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.10.49201 > 192.168.1.2.20: ., cksum 0xe69f (correct), 1:1(0) ack 6608673 win 260 <nop,nop,timestamp 64570 117644>
19:35:27.645205 IP (tos 0x0, ttl 128, id 26094, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.10.49201 > 192.168.1.2.20: ., cksum 0xdb4f (correct), 1:1(0) ack 6611569 win 260 <nop,nop,timestamp 64570 117644>
19:35:27.645353 IP (tos 0x0, ttl 128, id 26096, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.10.49201 > 192.168.1.2.20: ., cksum 0xcfff (correct), 1:1(0) ack 6614465 win 260 <nop,nop,timestamp 64570 117644>
19:35:27.645499 IP (tos 0x0, ttl 128, id 26097, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.10.49201 > 192.168.1.2.20: ., cksum 0xc4af (correct), 1:1(0) ack 6617361 win 260 <nop,nop,timestamp 64570 117644>
19:35:27.645646 IP (tos 0x0, ttl 128, id 26099, offset 0, flags [DF], proto TCP (6), length 52) 192.168.1.10.49201 > 192.168.1.2.20: ., cksum 0xb95f (correct), 1:1(0) ack 6620257 win 260 <nop,nop,timestamp 64570 117644>

Wie man erkennt wird jeglicher ausgehender Datenverkehr regelrecht zerhackt und das auf eine winzige Länge von "52" inkl. Prüfung via cksum.

Gibt es eine Schraube an der ich drehen kann um hier abhilfe zu schaffen ?


Vielen Dank im Voraus

Hier noch nen paar Infos:

Debina Lenny

SKYNET:~# uname -a
Linux SKYNET 2.6.26-2-686 #1 SMP Mon Jun 21 05:58:44 UTC 2010 i686 GNU/Linux

Hab beide Treiber (r8169 und r8169 probiert, kein unterschied)

SKYNET:~# ethtool -i eth0

Code: Alles auswählen

driver: r8169
version: 2.2LK-NAPI
firmware-version:
bus-info: 0000:02:00.0

SKYNET:~# ethtool eth0

Code: Alles auswählen

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 auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00000033 (51)
        Link detected: yes

SKYNET:~# ethtool -k eth0

Code: Alles auswählen

Offload parameters for eth0:
Cannot get device flags: Operation not supported
rx-checksumming: on
tx-checksumming: off
scatter-gather: off
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off
large receive offload: off

[Six]

Gucke dir deine Interfaces mal mit ifconfig an und richte besonderes Augenmerk auf den MTU Wert.

[xray]

Hi Six,

die MTU steht (unverändert) auf 1500.


Gruß
xray

[uname]

Kannst du mal versuchen nachgelagerte Netzwerkkomponenten auszuschließen, indem du vielleicht den Server mit einem (neutralen) Rechner direkt oder über einen anderen Switch verbindest. Was sagen dann die Werte?

[Danielx]

Hallo und willkommen im df.de!

Wie man erkennt wird jeglicher ausgehender Datenverkehr regelrecht zerhackt und das auf eine winzige Länge von "52" inkl. Prüfung via cksum.

Das ist zumindest aus dem von dir geposteten Mitschnitt nicht ersichtlich, denn das sind ausnahmslos ACK-Pakete und die sind eben üblicherweise nur 52 Byte lang, da wird also nichts zerhackt.

Gucke dir deine Interfaces mal mit ifconfig an und richte besonderes Augenmerk auf den MTU Wert.

Wenn es daran liegen würde, dann wären wahrscheinlich auch die eingehenden Pakete keine 1500 Byte lang.

Gruß,
Daniel

[xray]

Was ich schon probiert hatte, war die Kommunikation anderer Rechner (Laptop, Arbeitsrechner) über den Switch / Kabel und die war in Ordnung.
Mit FTP ca. 60-80 MB/s in beide Richtungen.

Ich versuch mal den ganzen tcpdump aufzuzeichnen. Für mich sah, was die length 52 betrifft, der komplette Stream beim Scrollen so aus.

Ich hab gestern mal den Debian-Rechner mit einer openSuse Live CD gestartet und hatte ein ähnliches Problem.
Incomming 60-80MB/s - Outgoing 10MB/s . Ich befürchte langsam das die interne Netzwerkkarte oder der Treiber ein Problem hat.

Borad: ASUS AT5NM10-I -> Realtek RTL8112L ethernet controller

Ich teste aber nochmal die Übertragungsgeschwindigkeit mit einem CrossOver-Kabel.

[xray]

... so hab jetzt mal mit einem CrossOver-Kabel getestet und siehe da, in beide Richtungen (Debina Rechner <-> openSuse Laptop) 80MB/s.

Sprich es müsste eigentlich am Switch (DLINK green power / DGS1005D) liegen aber dagegen spricht,
dass ich mit anderen Rechnern über eben diesen Switch meine 80MB/s in jede Richtung schaffe.

Woran kann das nur liegen ???

[123456]

vielleicht liegt das schlicht am Kabel, einfach mal tauschen.

[xray]

hab ich schon alle durchprobiert... kein unterschied btw. sind cat6

[123456]

hast du ausser dem einen Switch vielleicht noch einen anderen oder einen simplen Hub zu testen?

[xray]

leider nicht, bin aber am überlegen ob ich mir nicht einen von netgear bestellen soll ?

Ich habe noch mit der MTU size auf dem Linuxrechner experimentiert und wenn ich die mtu auf 600 stelle, erreiche ich ca. 18 MB/s download ... schonmal besser als 3 MB/s
Ich glaube langsam, dass der Switch nen schlag weg hat ...

[123456]

das kann auch an der Kommunikation zwischen Switch und Rechner liegen.
Hast du alle Ports durchprobiert?
Kannst du den Switch konfigurieren? mal das Manual checken wegen Parametern.
schon gegoogelt wegen dem Switch Modell und ähnlichen Problemen?

[xray]

Ich hab alle Ports durch, egal wo ich den Linuxrechner dran hab, immer das gleiche Problem. Der Switch hat so 30 Euro gekostet also nix mit Managment System Ist schon sehr komisch das dieser Switch nur den Linux-Server ausbremst.

Bei google hab ich einen Eintrag gefunden, dass es schon Probleme mit diesen Switchen gab. Diese äußerten sich in Verbindungseinbrüche bis hin zum "Hängen" bleiben.

Ich hab jetzt mal einen 8-Port Switch von Netgear bestellt. Sobald ich diesen getestet habe, werd ich diesbezüglich nochmal Feedback geben.

Gruß,
xray

[xray]

Hallo zusammen,

heute ist mein neuer Switch (Netgear GS108) gekommen und siehe da, keine Probleme mehr. Ich kann jetzt die Daten zwischen den Rechnern in beide Richtungen mit ca. 80-100MB/s übertragen. Einfach nur geil

Soviel zum Thema wer billig kauft, kauft 2 mal ...

Ein Bekannter meinte auch das die 5 Port-Switche generell nichts taugen sollen, nur komisch das die Kommunikation zwischen Windows auf diesen Switch ohne Probleme funktioniert hat.
Vieleicht gibt es eine Art inkompatibilität zwischen Realtek und Dlink ?!




Gruß
xray