2 ports could not bond to a aggregator in 802.3ad mode issue

[lewis_zyxel]

I wish to be personally CC'ed the answers/comments posted to the list in
response to my posting.

I have 2 ports(eth0, eth1) in my device. I use kernel(2.6.23) bonding driver
v3.1.3 (June 13, 2007) to bond 2 ports to one aggregator and use the
following commands to setup the environment:
insmod ./bonding.ko mode=4 miimon=100
ifconfig bond0 172.23.26.223 netmask 255.255.255.0
ifconfig eth0 down
ifconfig eth1 down
ifenslave bond0 eth0 eth1

After the setting, I cat the proc entry and got the following information

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2 (0)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

802.3ad info
LACP rate: slow
Active Aggregator Info:
Aggregator ID: 1
Number of ports: 1
Actor Key: 17
Partner Key: 1
Partner Mac Address: 00:00:00:00:00:00

Slave Interface: eth0
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:e0:0c:48:00:04
Aggregator ID: 1

Slave Interface: eth1
MII Status: up
Link Failure Count: 0
Permanent HW addr: 6f:74:66:73:74:79
Aggregator ID: 2

It shows that 2 ports could not bond to a aggregator. After I trace the the
bonding driver code, I modify the ad_port_selection_logic() in bond_3ad.c as
following:

- ((MAC_ADDRESS_COMPARE(&(port->partner_oper_system), &(null_mac_addr)) &&
// partner answers
+ (!(MAC_ADDRESS_COMPARE(&(port->partner_oper_system), &(null_mac_addr)) &&
// partner answers
!aggregator->is_individual) // but is not individual OR
)

After the modification, I cat the proc entry again and the result is as
following:
/home/shares # cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.1.3 (June 13, 2007)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2 (0)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

802.3ad info
LACP rate: slow
Active Aggregator Info:
Aggregator ID: 1
Number of ports: 2
Actor Key: 17
Partner Key: 1
Partner Mac Address: 00:00:00:00:00:00

Slave Interface: eth0
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:e0:0c:48:00:04
Aggregator ID: 1

Slave Interface: eth1
MII Status: up
Link Failure Count: 0
Permanent HW addr: 6f:74:66:73:74:79
Aggregator ID: 1

The behavior changes from 'one aggregator with one port' to 'one aggregator
with 2 ports', the latter seems more accurate. Is there a bug in bonding
driver code v3.1.3 (June 13, 2007)?
Best regards,
Lewis Li

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Jay Vosburgh]

>After the setting, I cat the proc entry and got the following information

[...]

>802.3ad info
>LACP rate: slow
>Active Aggregator Info:
> Aggregator ID: 1
> Number of ports: 2
> Actor Key: 17
> Partner Key: 1
> Partner Mac Address: 00:00:00:00:00:00

[...]

>The behavior changes from 'one aggregator with one port' to 'one aggregator
>with 2 ports', the latter seems more accurate. Is there a bug in bonding
>driver code v3.1.3 (June 13, 2007)?

I do not believe so.

IEEE 802.3 section 43.3.9 states, in part,

"Links that are not successful candidates for aggregation (e.g.,
links that are attached to other devices that cannot perform aggregation
or links that have been manually configured to be non-aggregatable) are
enabled to operate as individual IEEE 802.3 links. For consistency of
modeling, such a link is regarded as being attached to a compatible
Aggregator that can only be associated with a single link. That is, from
the perspective of Link Aggregation, non-aggregated links are not a
special case; they compose an aggregation with a maximum membership of
one link."

I do not see that it is correct to attach the links to a common
aggregator, as your output indicates that no partner association has
been created (the Partner MAC is all zeroes) and the links are therefore
apparently connected to a device that cannot perform aggregation.

-J

---
-Jay Vosburgh, IBM Linux Technology Center, fu...@us.ibm.com

[Lewis Li]

Yes, you are right. The incorrect behavior is due to we don't setup the
lacpdu of switch correctly.
The bonding driver is correct. Thanks for your comment!

> I do not believe so.
>
> IEEE 802.3 section 43.3.9 states, in part,
>
> "Links that are not successful candidates for aggregation (e.g.,
> links that are attached to other devices that cannot perform aggregation
> or links that have been manually configured to be non-aggregatable) are
> enabled to operate as individual IEEE 802.3 links. For consistency of
> modeling, such a link is regarded as being attached to a compatible
> Aggregator that can only be associated with a single link. That is, from
> the perspective of Link Aggregation, non-aggregated links are not a
> special case; they compose an aggregation with a maximum membership of
> one link."
>
> I do not see that it is correct to attach the links to a common
> aggregator, as your output indicates that no partner association has
> been created (the Partner MAC is all zeroes) and the links are therefore
> apparently connected to a device that cannot perform aggregation.
>

> ---
> -Jay Vosburgh, IBM Linux Technology Center, fu...@us.ibm.com

Regards,
Lewis Li