I have a CCR1072 with two 10gig interafces bonded together (LACP, L2 only, mainly for failover).
I noticed that on the server side, one of the interface is down (the RX sid eof the link is at loss), and the server side LACP process also indicates the failing interface.
The interesting thing is, on the Mikrotik side (6.45.1 on both ROS and Routerboard image), nor the interface, nor the LACP indicates there is any problem:
The interface indicates: enabled, running, slave, link ok
The LACP also indicates everything is fine, which is interesting as the MII packets are not going through the faulty interface (0 packets as a matter of fact).
The log is also not indicating anything.
I use Mikrotik SFP modules (S+85DLC03DI). Both interfaces in the LACP group have disabled auto nego and TX/RX flow controls, and the link is fixed at 10gig.
The link monitoring attribute of the bond is MII, and that is the only choice for 802.3ad mode (LACP).
To add to this: the failing interface on the Mikrotik end might be in an UP state because it receives data from the server side, only the Mikrotik → Server direction is at fault, therefor the Mikrotik side does receives the MII frames from the server.
I am not sure how the MII link monitoring should work, but I suspect that the standard developers were not as stupid to leave this type of a (half sided) fault out of the plan
Mii monitoring works approximately as well as speed (and duplex) auto-negotiation. I.e. it can sometimes fail if connection is marginal … Which opens a question: is there a good reason not to allow autonegotiation on those two links?
You mean that MII alone is not able to detect outage if only a single direction of a fiber link is affected?
So if I would enable auto nego, then the ethernet port would be able to detect the loss of the RX side loss and get the port state to down?
The LACP group consists of two 10gig fiber links, so I am not sure what would I gain to allow auto nego again (I believe it was not working with that setting by the way).
The whole thing depends heavily on how particular interface vendor implemented MII stuff inside their hardware … But yes, generally speaking fiber modules have no idea about Tx part of the link, they can only detect failing Rx. If autonegotiation process was running, it might detect link failure as the autonegotiation process itself is two-way and the remote end, detecting problems with its Rx (which is this side’s Tx), can signal the peer and this side thus gets some limited feedback. When link properties are manually set, such procedures don’t have to exist.