Hello, while configuring the MLAG configuration on two CRS326-24S+2Q+ switches, I encountered incomprehensible behavior that could potentially lead to a service failure during operation. I have attached a physical connection diagram (png) and updated to the latest version of the ROS7 branch.

To connect the server, I use SFP-DAC-001 cables.

The first problem is that when disconnecting the network adapter on the server, the status of the sfp plus interface remains active. At the same time, if I disable the interface from the switch side, then it will be in the disconnected status on the server (network cable is not connected)

The second problem is that the bonding used as the basis for MLAG uses the state of the physical link (Mii monitoring) to determine the state of the logical LACP channel (802.3ad), which leads to packet losses as soon as I disable the interface from the server side.

It is very strange that the physical state of the link is used to check the state of the logical LACP channel, while the physical link may be active but not configured on the other side and this will also lead to packet loss.

At the same time, when I disconnect the interface from the server side, despite the fact that the physical link on the switch remains active, as well as the bonding interface attached to it, the failure indicator may be the lack of LACP negotiation. At the same time, this field is visible in winbox (bonding interface - status - lacp partner system id) and it becomes empty as soon as the agreement is violated.

For what reason can I not select this field as the activity of the bonding interface?

I wrote to technical support on this issue (SUP-114652), but maybe there will be some thoughts here. I recently set up exactly the same configuration on arista switches (but 1g ethernet). They can clearly separate the stages: after connecting the cable and after agreeing on the LACP protocol, as well as configure different VLAN settings

Hello!
Could you post the configuration part of mlag, and interfaces (including vlans).
I think could be related to the propagation of vlans on peerport, but I can be wrong.

Best Regards!

Mlag is completely broken in mikrotik. Doesn't work right at all and never should have been released.

Mlag is completely broken in mikrotik. Doesn't work right at all and never should have been released.

I am not agree with that, we have been using it with crs317 since July 2022 in production (test were made first on lab to check all our needs would work).

Mlag is completely broken in mikrotik. Doesn't work right at all and never should have been released.

I am not agree with that, we have been using it with crs317 since July 2022 in production (test were made first on lab to check all our needs would work).

So it doesn't bother you when one switch reboots and the lacp system Id flaps, causing a traffic drop? Or spanning tree interoperability issues?

In a nutshell. It works fine until you need the functionality it is supposed to provide. In your case, you have likely never used a good working mlag setup to know what you are missing.

Is nice to hear people to know what I should know or not.

I am not a fanboy of any company.

Probably I will not answer more on this thread as I feel it will not add anything up to the discussion as OP did not answer with anything that could be helped here.
I was only trying to help others with their mlag setups when I got time.

I consider that most of problems while people is setup a technology they are learning are configuration ones, and when that is solved there could be also bugs but not in the opposite direction (someone that have never used a hammer, could blame it the first time he hammers his finger but is not the hammer's bug), and of course is true that any software have bugs and I am not telling anything regarding it should not be solved when we find any of them, just the opposite.

Best Regards