The behaviour of link aggregation on switches running the HPE Comware NOS struck me as odd, like everything about Comware does. I wanted to set up two gigabit interfaces as an LACP link to a Proxmox hypervisor and figured the knowledge I gained is worth sharing.
The password to enter is
Jinhua1920unauthorized. Now we have the full Comware CLI available, the behavior is representative of the enterprise-grade Comware switches (as sold by HPE under the H3C brand). Of course there can be differences between switch models and software versions.
The main thing I ran into is the fact that you need to make sure configuration applied to the aggregate interface is the same as configuration applied to the underlying physical interfaces. I’m used to Cisco, where configuration applied to the aggregate interface gets applied to the underlying interfaces automatically.
In the following example I will explain how to set up an aggregate interface called Bridge-Aggregation4 (this is the Comware version of a port-channel). The member interfaces will be GE1/0/41 and GE1/0/42.
I like to define the Bridge-Aggregation interface first, then apply some config to it:
This interface now looks like I want it to in the running config:
At this moment, the two physical interfaces still have their default config. Time to change that:
GE1/0/42 would get the same configuration. Note that executing the config commands in this order works the easiest. If the physical interface is already a member of the aggregate interface, changing these settings results in a warning, even if the physical interface is configured wrong/different than the aggregate interface config.
I configured just the aggregate interface and the membership when first trying this, being used to the Cisco behavior. When frames were not being bridged even though all other config was correct on both sides and everything seemed to be up, I had to investigate. Entering the VLAN config etc on the physical interfaces too solved my problem.