I have an 802.11ad bond from my Mikrotik CRS317 to a Cisco switch. The link only has one member and traverses through a layer 2 network before reaching the Cisco, essentially a 10Gb Layer 2 leased line in this case.
When the link is broken the 802.11ad bond only goes down if the physical link from the tik goes down and the interface goes down.
These are my settings on my CRS317, the cisco is setup as default for 802.3ad.
I don’t think your LACP works at all, since you have not specified a primary Link…
Whats the point of 802.3ad if you just add only one member? It’s totally wrong to me…
Yes this and also what does Link is broken mean and what is your expected behavior. I use LACP for redundancy on a hardware level and it is not application aware at all.
Yes it does seem a little silly. It’s a requirement from our provider who delivers us the layer2 tails to customer premises. It’s useful for adding extra capacity/redundancy in without causing an outage.
Primary is not an option for 802.3ad bonds, you get the following message when trying to set failure: primary interface setting is valid only in active-backup, balance-tlb, balance-alb mode
.
Because the circuit back to the Cisco is quite long it has other active equipment along the line maintainted by another carrier. It is delivered as a layer2 pipe essentially. There is the chance the link gets broken in the middle causing no physical port down on the Mikrotik. In this situation the Cisco drops the bond as it receives no 802.3ad packets. The Mikrotik however stays up. My biggest gripe is not knowing whether the link is up and speaking LACP or just up because one or more of the slave interfaces has a link light. LACP is also acting as a rudimentary Link Loss Forwarding tool which makes it easy to monitor.
Interested to hear your thoughts, Mikrotik is the only vendor I have seen whose 802.3ad implementation works like this and doesn’t down when it stops getting LACP packets.
So for a test I removed all the cables from a LACP Interface and the bonding itself went down and reported down. So I’m not seeing the same behavior as you do.
That is a different case to the scenario the OP describes - you are disconnecting the cables, not interrupting traffic flow.
From the wiki “MII monitoring monitors only the state of the local interface … Main disadvantage is that MII monitoring can’t tell if the link can actually pass packets or not, even if the link is detected as being up.”
OK I get that but a dumb switch will not support LACP. I fail to see the scenario when this is needed and when L2 goes down with this being noticed in L3. I get the issue now and guess that is a MT limitation.
If we flip the question What do you want to accomplish? Maybe this can be fixed via script or other method?
LACP is definitely working with the Cisco. There is only one slave currently. The idea is we can add others in later. The bond on the cisco goes up and down as the link drops/recovers.
Unfortunately it’s standard for these networks to only do 802.3ad.
I do not know how other Manufacturers implement LACP, what i know is that you need 2 slaves for an LACP implementation…
And it totally makes sense, what would be the point of LACP with 1 link ? None…
Imagine that the two switches are not interconnected by a passive cable but by some active transport equipment (microwave radio, Ethernet over SDH channel), where the Ethernet connection may stay up but the actual data path may be broken. Devices like SHDSL modems or electrical/optical Ethernet converters often have the possibility to shut down the Ethernet port when the media side reception goes down, but if their own transmission across the media doesn’t reach the destination, they get no information about that as there is no overhead channel available to convey that feedback.
In the OPs case, the LACP peers are separated by a number of active elements, no matter what kind of. So he needs to learn the state of the remote LACP peer, not of the first hop’s Ethernet.
That won’t save you unless you don’t mind sending traffic to a blackhole when only the you->them direction is broken. If the transit network between the Tik and the Cisco consists of more hops, some of them carrying aggregated traffic, there is no way how the transit carrier could indicate a failure to you except if they monitored the whole path end-to-end somehow on their own.
So back to the question of @Kindis, what is the actual goal at your side, i.e. what should change once the bond becomes inactive? It doesn’t matter much whether you send one ping per second in addition to one LACP frame per second, so what prevents you from setting up a netwatch to ping some destination, making the bond the only route to that destination (as the interface never goes down, you even don’t need a blackhole route to the same destination preventing the default one from taking over) and using an /ip firewall raw rule to drop any responses which would eventually come through any other interface than the bond, and setting on-up and on-down of the netwatch to do the action which would normally be triggered by the bond going up/down?
What do you want to accomplish? Maybe this can be fixed via script or other method?