Comware

Greetings,

I have two switches on my internal network that are interconnected via fiber with two media converters on each end.
It turns out that the trunk I'm trying to do between these switches only closes via network cable, via fiber, with media converters it doesn't work.
We have done everything, changed the converters, tested with other switch models, changed the network cable standards (CAT6), adjusted the settings on both sides, nothing corrects.
I believe it is not a configuration because via the network cable the trunk and loadbalance works very well

The models and their relative configurations are as follows:
First switch: 
Model: HP 1920-48G Switch JG927A
LACP:  Dynamic
Ports: GigabitEthernet1/0/37  GigabitEthernet1/0/38
VLANs: Untagged (1) Tagged (2,4-6,8)
Trunk Ports: GigabitEthernet1/0/37  GigabitEthernet1/0/38
Link type: Trunk

Second switch:
Model: HPE 1920S 48G 4SFP JL382A
LACP Mode: Enable
Trunk: Static Mode Disabled
Trunk Ports: GigabitEthernet1/0/47  GigabitEthernet1/0/48
VLANs: Untagged (1) Tagged (2,4-6,8) "Only Tagged"

Does anyone have any ideas?

#switch1920s
#LACP
#converter
#Cable
#fiber
#Trunk
#switch
#HP

Hi @Douglas-Souza !

Did you test both links with standalone ports, without aggregation configured? I mean we need to exclude medium and converters as possible issue.

 

Hi! I fear the issue (and culprit) can be tracked down to Media-Converters usage...AFAIK Links Aggregation using especially (but not limited to) LACP as link aggregation control protocol sholud not accept anything different by a point-to-point connection (either copper or fiber). Two Media-Converters in between per each Trunks' leg shouldn't be "transparent" enough to LACP to render it successful.

Hi @parnassus !

If a media converter doesn't try to be smarter as it should be, then LACP, as well as CDP/LLDP, BFD etc. all normally work fine. However, your point makes perfect sense - both links need to be tested in standalone mode (normal Ethernet ports, outside any aggregation), then I would check if LLDP works over those links (since it's also a link-local L2 multicast frame) and only after confirming it works fine start troubleshooting LACP.

 

Greetings friends,

Thanks for the answers.
Yes, already test the links with the converters, without aggregation. That is, all tests related to fiber and media converters were done and successful without LACP / TRUNK.

To be honest 1920S is out of my scope as its support is outside my department, but I can help you with 1920 which is Comware-based - we can see from this switch if LLDP packets from the other side of the link are seen on its aggregated ports. In order to see it, you need to unlock full CLI of the 1920. I will send you the exact procedure as PM. As soon as you will unlock the CLI, connect 1920 and 1920S over your media-converters, wait for a minute and then collect output of the following command:

display link-aggregation verbose

Paste the output here, but in short we are looking for the 'Remote' part of the output and in particular 'SystemID' column. Any value other than '0000-0000-0000' will mean that 1920 gets LACP PDUs from the 1920S. If we confirm that there are values other than all-zeroes, then you need to check if those values of the remote side are equal on all ports members of this aggregation. So, let's see the output and we'll figure out what to do next.

 

Good morning friends,

I was able to identify a solution. Through a specific media converter, LACP does not work. But in the others it works well. I have already opened a connection with the manufacturer and I am waiting for your return. As much as it doesn't make sense, it is he who is causing it.

Hi! Glad you fixed it. What you discovered confirms that some media-converters are more transparent than others (or, conversely, that some others tend to interact with some higher level protocols in a way it potentially causes undesired malfunctions).