Seeing the high dropping quote... (just compare this to the other NIC) - have you tried a new cable? Maybe it's a cheap hardware problem...
-----Ursprüngliche Nachricht----- Von: linux-ha-boun...@lists.linux-ha.org [mailto:linux-ha-boun...@lists.linux-ha.org] Im Auftrag von Lars Marowsky-Bree Gesendet: Donnerstag, 11. Juli 2013 11:20 An: General Linux-HA mailing list Betreff: Re: [Linux-HA] Antw: Re: beating a dead horse: cLVM, OCFS2 and TOTEM On 2013-07-11T08:41:33, Ulrich Windl <ulrich.wi...@rz.uni-regensburg.de> wrote: > > For a really silly idea, but can you swap the network cards for a test? > > Say, with Intel NICs, or even another Broadcom model? > Unfortunately no: The 4-way NIC is onboard, and all slots are full. Too bad. But then you could really try raising a support request about the network driver, perhaps one of the kernel/networking gurus has an idea. > RX packet drops. Maybe the bug is in the bonding code... > bond0: RX packets:211727910 errors:0 dropped:18996906 overruns:0 > frame:0 > eth1: RX packets:192885954 errors:0 dropped:21 overruns:0 frame:0 > eth4: RX packets:18841956 errors:0 dropped:18841956 overruns:0 frame:0 > > Both cards are identical. I wonder: If bonding mode is > "fault-tolerance (active-backup)", is it normal then to see such > statistics. ethtool -S reports a high number for "rx_filtered_packets"... Possibly. It'd be interesting to know what packets get dropped; this means you have approx. 10% of your traffic on the backup link. I wonder if all the nodes/switches/etc agree on what is the backup port and what isn't ...? If 10% of the communication ends up on the wrong NIC, that surely would mess up a number of recovery protocols. An alternative test case would be to see how the system behaves if you disable bonding - or if the names should stay the same, only one NIC in the bond. Regards, Lars -- Architect Storage/HA SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde _______________________________________________ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems _______________________________________________ Linux-HA mailing list Linux-HA@lists.linux-ha.org http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
