Ursache dropped Pakete

[slu]

Hallo,

auf einem Server steigt die Anzahl an eth1 (gehört zum bond0) der gedroppten Paket an.
Was ist hierfür die Ursache?
Man bekommt zwar viele Treffer bei Google, aber so eine richtige Erklärung konnte ich mir daraus nicht ableiten.

Code: Alles auswählen

bond0     Link encap:Ethernet  Hardware Adresse 00:15:17:xx:xx:xx  
          inet Adresse:10.23.0.42  Bcast:10.23.255.255  Maske:255.255.0.0
          inet6-Adresse: fe80::215:17ff:fe61:e746/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metrik:1
          RX packets:320015692 errors:2 dropped:23383 overruns:0 frame:1
          TX packets:359666310 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:262806365061 (244.7 GiB)  TX bytes:320205015744 (298.2 GiB)

eth0      Link encap:Ethernet  Hardware Adresse 00:15:17:xx:xx:xx  
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metrik:1
          RX packets:126497367 errors:0 dropped:0 overruns:0 frame:0
          TX packets:228170883 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:112555849117 (104.8 GiB)  TX bytes:215974560049 (201.1 GiB)
          Interrupt:17 Speicher:ea180000-ea1a0000 

eth1      Link encap:Ethernet  Hardware Adresse 00:15:17:xx:xx:xx  
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metrik:1
          RX packets:193518325 errors:2 dropped:23383 overruns:0 frame:1
          TX packets:131495427 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX bytes:150250515944 (139.9 GiB)  TX bytes:104230455695 (97.0 GiB)

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:333057779 errors:0 dropped:0 overruns:0 frame:0
          TX packets:333057779 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0 
          RX bytes:57176752908 (53.2 GiB)  TX bytes:57176752908 (53.2 GiB)

[rendegast]

Vielleicht hat der angeschlossene switch Ausfallserscheinungen?

Evtl. Meldungen vom Treiber?

Kabel hat Knickstelle oder kritisch verlegt?

[slu]

Ich habe inzwischen das Kabel und den Port am Switch getauscht sowie den Server neu gestartet (um nochmal zu nullen).
Aber bereits nach kurzer Zeit gehts wieder los.

Heute Nacht gibts ein neues Mainboard (identisches), eigentlich hatte ich das ja auf Lager gelegt das ich es nicht brauche
Es scheint auch einfach so daß die magische Zeit von 5 Jahren erreicht ist, bis Wheezy Stable wird muss er noch durchhalten

Dmesg Zeigt übrigens keine Fehler, ich werde berichten ob es besser wurde.

[dufty]

"physikalische Fehler" würden sich eher in "errors" niederschlagen,
bei "dropped" würd ich mal auf "Überlast" eher tippen ("bursts"), kannst ja mal mit "ethtool" versuchen,
Dir die Statistik anzusehen.
Bei einer Intel e1000 kann man zum Bleistift den Receive-Buffer erhöhen, falls es daran liegen sollte.

[slu]

"physikalische Fehler" würden sich eher in "errors" niederschlagen,

Das macht Sinn.
Nur warum passiert es nur auf eth1? Ich hab mal das Kabel abgezogen und geschaut ob es diese Fehler auch auf eth0 gibt und
das ist nicht der Fall.

bei "dropped" würd ich mal auf "Überlast" eher tippen ("bursts"), kannst ja mal mit "ethtool" versuchen,
Dir die Statistik anzusehen.
Bei einer Intel e1000 kann man zum Bleistift den Receive-Buffer erhöhen, falls es daran liegen sollte.

Ja sind zwei Intel, allerdings unterschiedliche.

Code: Alles auswählen

03:00.0 Ethernet controller: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (rev 03)
04:05.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05)

Code: Alles auswählen

Settings for eth1:
	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: 1
	Transceiver: internal
	Auto-negotiation: on
	MDI-X: off
	Supports Wake-on: pumbag
	Wake-on: g
	Current message level: 0x00000001 (1)
	Link detected: yes

Mhm wie muss ich die Statisik nun deuten? Hier wird wieder von rx_missed_errors gesprochen.

Code: Alles auswählen

ethtool -S eth1
NIC statistics:
     rx_packets: 2191054
     tx_packets: 1782892
     rx_bytes: 2231297519
     tx_bytes: 1250470382
     rx_broadcast: 1419
     tx_broadcast: 4543
     rx_multicast: 405
     tx_multicast: 275
     rx_errors: 0
     tx_errors: 0
     tx_dropped: 0
     multicast: 405
     collisions: 0
     rx_length_errors: 0
     rx_over_errors: 0
     rx_crc_errors: 0
     rx_frame_errors: 0
     rx_no_buffer_count: 0
     rx_missed_errors: 306
     tx_aborted_errors: 0
     tx_carrier_errors: 0
     tx_fifo_errors: 0
     tx_heartbeat_errors: 0
     tx_window_errors: 0
     tx_abort_late_coll: 0
     tx_deferred_ok: 0
     tx_single_coll_ok: 0
     tx_multi_coll_ok: 0
     tx_timeout_count: 0
     tx_restart_queue: 4171
     rx_long_length_errors: 0
     rx_short_length_errors: 0
     rx_align_errors: 0
     tx_tcp_seg_good: 214023
     tx_tcp_seg_failed: 0
     rx_flow_control_xon: 0
     rx_flow_control_xoff: 0
     tx_flow_control_xon: 0
     tx_flow_control_xoff: 0
     rx_long_byte_count: 2231297519
     rx_csum_offload_good: 2189773
     rx_csum_offload_errors: 0
     alloc_rx_buff_failed: 0
     tx_smbus: 0
     rx_smbus: 0
     dropped_smbus: 0

Edit:
So richtig schlau werde ich nicht, eth0 und eth1 sind identisch.

Code: Alles auswählen

Ring parameters for eth1:
Pre-set maximums:
RX:		4096
RX Mini:	0
RX Jumbo:	0
TX:		4096
Current hardware settings:
RX:		256
RX Mini:	0
RX Jumbo:	0
TX:		256

Code: Alles auswählen

driver: e1000
version: 7.3.21-k5-NAPI
firmware-version: N/A
bus-info: 0000:04:05.0

Warum kommt der Fehler nur auf eth1?

[dufty]

So richtig schlau werde ich nicht, eth0 und eth1 sind identisch.

Code: Alles auswählen

Ring parameters for eth1:
Pre-set maximums:
RX:		4096
RX Mini:	0
RX Jumbo:	0
TX:		4096
Current hardware settings:
RX:		256
RX Mini:	0
RX Jumbo:	0
TX:		256

Das sind die Ring "Buffers",
ich meinte das "PBA buffer"-Zeugs.

Die 82541GI ist das ältere Modell von beiden; ob's daran liegt? Wer weiss ...

Kannst ja mal beide mittels ethregs ("Register Dump Tool") auslesen.

[slu]

Ich denke das Problem gefunden zu haben:

Code: Alles auswählen

kernel: [    0.388195] pci 0000:04:05.0: BAR 6: address space collision on of device [0xfffe0000-0xffffffff]

Code: Alles auswählen

04:04.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02)
04:05.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05)

Kann man das beheben?

[unitra]

Ich denke das Problem gefunden zu haben:

Code: Alles auswählen

kernel: [    0.388195] pci 0000:04:05.0: BAR 6: address space collision on of device [0xfffe0000-0xffffffff]

Code: Alles auswählen

04:04.0 VGA compatible controller: ATI Technologies Inc ES1000 (rev 02)
04:05.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller (rev 05)

Kann man das beheben?

Vielleicht ist das Problem mit einem neueren linux behoben. Schau mal hier:
https://patchwork.kernel.org/patch/39988/

[dufty]

Ich denke das Problem gefunden zu haben:

Code: Alles auswählen

kernel: [    0.388195] pci 0000:04:05.0: BAR 6: address space collision on of device [0xfffe0000-0xffffffff]

Macht für mich nicht so rechten Sinn:
Der "address conflict" wird recht früh in der boot-phase erkannt, wenn der "real" wäre und nicht behebbar,
müsste der kernel nicht einen (oder beide) devices aus der config nehmen?

Desweiteren müsstest Du den conflicht ja schon immer gehabt haben und Deine Ausgangsfrage interpretiere ich so, dass die Fehler resp. drops erst seit kurzem kommen.

Nichtsdestotroz kannst ja auch mal kernel-upgraden probieren

[slu]

Macht für mich nicht so rechten Sinn:
Der "address conflict" wird recht früh in der boot-phase erkannt, wenn der "real" wäre und nicht behebbar,
müsste der kernel nicht einen (oder beide) devices aus der config nehmen?

Ich bin da leider zu unerfahren um diese Frage beantworten zu können

Desweiteren müsstest Du den conflicht ja schon immer gehabt haben und Deine Ausgangsfrage interpretiere ich so, dass die Fehler resp. drops erst seit kurzem kommen.

Ich zweifel langsam daran, vielleicht ist mir das in den letzten zwei Jahre wirklich nie aufgefallen seit der Server mit Squeeze und Bonding läuft.

Jedenfalls habe ich noch das Board getauscht, ist übrigens ein Intel S3000AH, natürlich ist der Fehler weiterhin vorhanden was auch zu deiner Vermutung passt.
Wir haben noch zwei weitere identische Server, einer davon läuft auch mit Bonding und hat das Problem nicht, ABER er hat auch keine Last im vergleich zum "Problem" Server.

[slu]

Ich hab nun eine Intel i350-T2 verbaut, damit hat sich auch der Treiber auf igb geändert.

Jedenfalls sind die dropped Pakete nun weg.