Uplink-Probleme BCM5709/ProLiant DL360 G6

05/10/2011 - 23:59 von Oliver Sch | Report spam
Heyho,

ich hab hier ein paar HP-Server, DL360 G6, die zwischendurch meinen
keinen Uplink haben zu müssen, wobei das etwa für 4 Sekunden passiert.

Aktuelles Beispiel aus dem Syslog:

Oct 5 14:03:31 server04 kernel: [5301110.502171] bnx2: eth1 NIC Copper
Link is Down
Oct 5 14:03:35 server04 kernel: [5301114.398470] bnx2: eth1 NIC Copper
Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON

Die anderen Eintràge sind von den Abstànden àhnlich.

Der Fehler tritt allerdings so selten auf (alle 2-4 Wochen hab ich da
mal Ereignisse über alle Server hinweg), dass das Debuggen da echt
mühsam ist. Komischerweise scheinen sich die Fehler aber zeitlich zu
sammeln, aber sauber statistisch ausgewertet habe ich das noch nicht.

Genauere Modellbezeichnung laut lshw übrigens des Netzwerkadapters:
NetXtreme II BCM5709 Gigabit Ethernet

Auf den Kisten làuft ein Debian Lenny, ethtool sagt:

# ethtool -i eth1
driver: bnx2
version: 1.7.5
firmware-version: 4.6.4 NCSI 1.0.3
bus-info: 0000:02:00.1

# ethtool -a eth1
Pause parameters for eth1:
Autonegotiate: on
RX: on
TX: on

# ethtool -S eth1
NIC statistics:
rx_bytes: 6599090081
rx_error_bytes: 0
tx_bytes: 13605825883
tx_error_bytes: 0
rx_ucast_packets: 12936300
rx_mcast_packets: 0
rx_bcast_packets: 317898
tx_ucast_packets: 14911297
tx_mcast_packets: 0
tx_bcast_packets: 0
tx_mac_errors: 0
tx_carrier_errors: 0
rx_crc_errors: 0
rx_align_errors: 0
tx_single_collisions: 0
tx_multi_collisions: 0
tx_deferred: 0
tx_excess_collisions: 0
tx_late_collisions: 0
tx_total_collisions: 0
rx_fragments: 0
rx_jabbers: 0
rx_undersize_packets: 0
rx_oversize_packets: 0
rx_64_byte_packets: 3700077
rx_65_to_127_byte_packets: 4891204
rx_128_to_255_byte_packets: 147460
rx_256_to_511_byte_packets: 252592
rx_512_to_1023_byte_packets: 545219
rx_1024_to_1522_byte_packets: 3717646
rx_1523_to_9022_byte_packets: 0
tx_64_byte_packets: 476715
tx_65_to_127_byte_packets: 4574453
tx_128_to_255_byte_packets: 281164
tx_256_to_511_byte_packets: 638302
tx_512_to_1023_byte_packets: 575012
tx_1024_to_1522_byte_packets: 8365651
tx_1523_to_9022_byte_packets: 0
rx_xon_frames: 0
rx_xoff_frames: 0
tx_xon_frames: 0
tx_xoff_frames: 0
rx_mac_ctrl_frames: 0
rx_filtered_packets: 17746
rx_discards: 0
rx_fw_discards: 0

# uname -r
2.6.26-2-amd64

Jetzt ist die spannende Frage, ob die Switch-Infrastruktur hintendran
spinnt, die Racks an der falschen Stelle im Raum stehen oder aber es ein
Bug ist im Treiber/Firmware oder Murphy eingezogen ist.

Laut Provider sind die Kisten an unterschiedlichen Switchen in
unterschiedlichen Racks, also sollte zumindest eine Beschàdigung eines
Switches ausfallen als Ursache. Auch sollten die Kisten dann getrennt
abgesichert sein.

Kennt jemand ein àhnliches Problem? Hat schonmal jemand davon gehört?
Das empfohlene Firmware-Upgrade für die Netzwerkkarte auf Anraten des
Providers schmeckt mir ehrlich gesagt gar nicht, das bedeutet für jeden
einzelnen Server eine Downtime + manuelle Arbeit. Das wird lustig.

Davon ab, dass ich mich frage, was das für ein Problem sein soll, dass
nur wir haben, aber der Provider davon soviele Maschinen fàhrt, dass das
auch anderweitig hàtte bemerkt werden müssen.

Im Moment bin ich dem Provider gegenüber recht skeptisch und vermute
eher, dass dort was nicht in Ordnung ist, aber ohne den Switch selbst zu
verwalten ist der Nachweis da noch schwierig.

mfg
Oli

Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen
 

Lesen sie die antworten

#1 Juergen P. Meier
06/10/2011 - 06:48 | Warnen spam
Oliver :
ich hab hier ein paar HP-Server, DL360 G6, die zwischendurch meinen
keinen Uplink haben zu müssen, wobei das etwa für 4 Sekunden passiert.

Aktuelles Beispiel aus dem Syslog:

Oct 5 14:03:31 server04 kernel: [5301110.502171] bnx2: eth1 NIC Copper
Link is Down
Oct 5 14:03:35 server04 kernel: [5301114.398470] bnx2: eth1 NIC Copper
Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON



Was sagt der Switch dazu?

Die anderen Eintràge sind von den Abstànden àhnlich.



Hmm, 4 sekunden - das stinkt egentlich nicht nach spanning-tree.

Haben diese Server irgendein "inline!!1elf" integriertes
Plattform-Managemnet-Ding wie IPMI oder so nen Kaese?

Dann dieses einfach mal Abschalten.

Genauere Modellbezeichnung laut lshw übrigens des Netzwerkadapters:
NetXtreme II BCM5709 Gigabit Ethernet

Auf den Kisten làuft ein Debian Lenny, ethtool sagt:



Ich verwende wo es nur geht Intel-Karten um keine Broadcom NICs
nutzen zu muessen. (und wenn das nicht geht, dann halt aeltere RTLs wo
CPU-performance fuer Programme nicht unbedingt wichtig ist)

# ethtool -i eth1
driver: bnx2
version: 1.7.5
firmware-version: 4.6.4 NCSI 1.0.3
bus-info: 0000:02:00.1

# ethtool -a eth1
Pause parameters for eth1:
Autonegotiate: on
RX: on
TX: on



Kann der Switch Flowcontrol? In beide Richtugen?

Kann der Broadcom-Chip das ueberhaupt fehlerfrei? Schon mal die HP
Treiber fuer Wintendo ausprobiert und geschaut, ob die das per default
sicherheitshalber abschalten? Falls ja: Mal abschalten.

rx_filtered_packets: 17746



Sagt der Treiber, wraum der NIC diese Frames verworfen hat?

Jetzt ist die spannende Frage, ob die Switch-Infrastruktur hintendran
spinnt, die Racks an der falschen Stelle im Raum stehen oder aber es ein
Bug ist im Treiber/Firmware oder Murphy eingezogen ist.



Ich tippe eher auf letzteres - oder eine Unvertraeglichkeit zwischen
Switch und Broadcom mit den Linux-Treibern.

Kennt jemand ein àhnliches Problem? Hat schonmal jemand davon gehört?



Leider zur Genuege. IdR. sind es fehlerhafte NICs, kaputte Treiber
oder (immer) seltener Inkompatibiliteten zwischen NIC und Switchport.
Manchmal ist es aber auch einfach nur ein Wackelkontakt.

Das empfohlene Firmware-Upgrade für die Netzwerkkarte auf Anraten des
Providers schmeckt mir ehrlich gesagt gar nicht, das bedeutet für jeden



Es koennte das Problem beheben - und/oder interessante neue Probleme
bringen.

einzelnen Server eine Downtime + manuelle Arbeit. Das wird lustig.



Was ist besser: Eine Downtime in der hoffentlich vorgesehenen
Wartungszeit, oder sporadische Abbrueche?

Und warum probierst du das nicht einfach vorher auf dem Testsystem aus?
(hr hr hr)

Davon ab, dass ich mich frage, was das für ein Problem sein soll, dass
nur wir haben, aber der Provider davon soviele Maschinen fàhrt, dass das
auch anderweitig hàtte bemerkt werden müssen.



Vielleicht laeuft bei denen Wintendo mit Wintendo-Treibern, die die
Firmware gleich patchen oder zumindest die interessanten Features
abschalten, weil der NIC-Chip einfach kaputt ist*...

Im Moment bin ich dem Provider gegenüber recht skeptisch und vermute
eher, dass dort was nicht in Ordnung ist, aber ohne den Switch selbst zu
verwalten ist der Nachweis da noch schwierig.



Selbst von den Billigheimern HP und 3Com bekommt man heutzutage
eigentlich keine kaputten Gigabit-Switche mehr.

* Alle NICs sind kaputt. Es ist bei allen Herstellern und allen
Modellen immer mit die Aufgabe des Treibers, den NIC durch abschalten
von Features, Workarounds, Delays, Firmware-UPdates (sofern moeglich),
oder anderen kreativen fixes so weit zu kastrieren, dass er mehr oder
weniger Fehlerarm funktioniet.
Wer mir das nicht glaubt, soll doch bitteschoen einfach mal selbst
einen Blick in die Quellen aktueller NIC-Treiber im Linux-Kernel werfen.
Bitte einen Kotzkuebel bereithalten.

Juergen
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)

Ähnliche fragen