The ARP link monitoring is not recommended, because the ARP replies might arrive only on one slave port due to transmit hash policy on the LACP peer device. This can result in unbalanced transmitted traffic, so MII link monitoring is the recommended option.
Of course, the MII link monitoring has a flaw: it can only check connection state, but it cannot reliably tell if the packets are actually flowing. The ARP link monitoring is better from this perspecitve, and I was wondering if I would be safe to use it if I happen to know that the switch on the other side happens to be running SwOs. I went through this documentation: https://wiki.mikrotik.com/wiki/SwOS/CSS610#LAG and it only says that “IEEE 802.3ad (LACP) compatible link aggregation is supported”. But it does not say what kined of transmit hash policy is used.
So the question is this: what kind of transmit hash policy is used in SwOs? Is it documented somewhere?
IEEE 802.3ad (LACP) compatible link aggregation is supported, as well as static link aggregation to ensure failover and > load balancing is based only on Layer2 hashing.
That sounds pretty clear to me. And logical since SwOS is switching platform, devices don’t analyze packets beyond ethernet headers … those contain only src and dst MAC addresses and VLAN ID.
I can’t say if the bolded information was there when OP read the document, but it’s there now.
IEEE 802.3ad (LACP) compatible link aggregation is supported, as well as static link aggregation to ensure failover and load balancing based on > Layer2, Layer3 and Layer4 > hashing. Up to 16 link aggregation groups with up to 8 ports per group are supported.
I had problem with SwOS, LACP hashing/load balancing. We kept seeing TCP Retransmissions/Out of order (leading to DUP ACK), etc, and customers complaining about bufferbloat/latency.
I switched over everything to RouterOS v7 (latest stable) with fresh netinstall.
We are using this config everywhere (on both sides of the LACP bond), we stopped seeing TCP issues like Retransmissions/Out of order (leading to DUP ACK), etc.
