SNMP bug in ieee8023_lag_pp.py in Cumulus VX 3.5.1- all LAGs have same OperKey


The values for dot3adAggPortActorOperKey and dot3adAggActorOperKey are always the same, meaning that all LAG members map to a single master, regardless of which LAG they are within.

For example in the cldemo-config-mlag sample topology, the leaf switch has three separate LAGs (peerlink, server1, server2) but the device returns the same ActorOperKey for all LAGs.

The cause seems to be that in /usr/share/snmp/ieee8023_lag_pp.py the code is looking for attributes "actor_key" and "actor_port_key" which do not exist in the JSON output of /usr/share/snmp/showprocnetbonding.

A solution is to use the following:
  • for dot3adAggActorOperKey use attribute "ifindex"
  • for dot3adAggPortActorOperKey use attribute "masterifindex"
I have tested this patch and it works well.

5 replies

Userlevel 3
Hi Oliver, I've raised this with engineering; hopefully someone will respond soon. Thanks for reporting this!
Userlevel 2
Pete B wrote:

Hi Oliver, I've raised this with engineering; hopefully someone will respond soon. Thanks for rep...

Hi Oliver,

Thanks for the suggestions.

But I found that I get values for "actor_key" and actor_port_key" from showprocnetbonding (you need to run this as root):
root@host1:/home/cumulus# /usr/share/snmp/showprocnetbonding | grep key 
"actor_key": "13",
"actor_port_key": "13",
"partner_oper_key": "13",
"actor_port_key": "13",
"partner_oper_key": "13",
"partner_key": "13",
These number are derived from /proc/net/bonding/bondX which is derived from the
linux kernel bonding driver. These keys are vendor specific and, for Linux, are not
related to the ifindex of the ports involved. For the linux implementation (at least
for the default mode), they are defined in

  drivers/net/bonding/bond_3ad.c:bond_3ad_bind_slave()

and are a combination of the port speed, duplex setting and some user defined key.

Pete B wrote:

Hi Oliver, I've raised this with engineering; hopefully someone will respond soon. Thanks for rep...

Hi Sam, thank you so much for looking into this in depth for me. You are right that this is data coming from Linux itself and not Cumulus (I should have spotted that, so apologies for wasting time!).

It still confuses our NMS that on a system with more than one configured LAG the keys are all the same, so it cannot differentiate each of the masters and their members. But as this comes from Linux there is nothing to be done (or our NMS is not working correctly according to 802.3ad - I can look into that too).

Feel free to mark this as resolved/closed. You may wish to re-do your dump of showprocnetbonding on a device with two configured LAGs to see what I'm on about, for interest. Thanks again.
Userlevel 2
Pete B wrote:

Hi Oliver, I've raised this with engineering; hopefully someone will respond soon. Thanks for rep...

In addition to the keys, a system identifier (mac address) is used to distinguish two remote peers for the purposes of bonds. And with MLAG, it gets even more complex.
Pete B wrote:

Hi Oliver, I've raised this with engineering; hopefully someone will respond soon. Thanks for rep...

Ah OK that does help for driving development of our NMS to address this, thanks!

Reply