LACP Trunk-member Compatibility Question

Latest response

At one point in time, I seem to recall that attempting to create LACP bonded interfaces that used different driver families  (e.g., create an aggregate from an two Intel 1Gbps NICs and two Broadcomm 1Gbps NICs) wouldn't work. At least, what I seem to recall is that it wouldn't work from the standpoint of having four active members of the bond - you'd end up with an active trunk-pair (e.g., the Intel NICs) and a passive trunk-pair (e.g. the Broadcomm NICs). I thought I'd read it in one of the bonding driver READMEs. Unfortunately, now that I've been asked to revisit the question, I can't seem to locate where I'd seen this. Does anyone know if my recollection is in error? If my recollection is correct, does anyone know which document I might have found that had that notation? My Google-fu is coming up short, this evening.

Th
Log in to join the conversation

Responses

Jamie Bainbridge's picture Red Hat Guru 7257 points
2 June 2013 10:05 PM

You can find the bonding documentation in bonding.txt in the kernel-doc package.

The LACP standard (802.3ad) requires that all slaves of a Mode 4 bond have the same speed.

You should be able to add dissimilar NICs without a problem, your Intel and Broadcom example should work fine. One thing which might be tripping you up is the underlying capabilities of each NIC. Make sure all the offloading settings (ethtool -k ethX) are the same. You can persist these settings if required with ifup-local.

The Linux bonding driver can only be a "passive" member of an LACP bond, you might need to set your Port-Channel on the switch to be the "active" member.

If you're connecting to two logically different switches, the switches need some sort of technology to share their MAC tables. Cisco's Virtual Port-Channel is an example of this.

If you connect to two completely separate switches, then you'll have two load-balanced "bundles" in the one bond, each bundle to one switch. One bundle takes over if the other switch goes down.

You can check the status of the bond with cat /proc/net/bonding/bondX

Phil Jensen's picture Guru 3262 points
3 June 2013 1:26 AM

Jamie's coverage is solid and right on--we've used dissimilar network interfaces with the same link speed and offload settings without event (two different kinds of Intel interfaces).

Th Guru 2987 points
6 June 2013 12:55 PM

Thanks for the reply. The system that originally brought up this question was hosted in a remote data center (no opportunity to self-verify the cabling). I'm assuming that at least some of the issues we were seeing were related to how it was physically connected, though the auto-negotiated line-speeds may have also contributed.

Jamie Bainbridge's picture Red Hat Guru 7257 points
6 June 2013 11:16 PM

Well, the 802.3ab spec requires auto-negotiation over 1000BASE-T, so don't hard-set your speed and duplex for copper twisted pair. Definitely make sure they are actually negotiating to 1000 FDX though! You can check that with just ethtool ethX

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.