The issue may relate do with our default behavior of delaying responses to LBMs by a random delay between 0 to 1 second as per section 7.2.2 Multicast ETH-LB in the Y.1731 spec: Upon reception of a Multicast frame with ETH-LB request information, the receiving MEPs validate the Multicast frame with ETH-LB request information and transmit a Unicast frame with ETH-LB reply information after a randomized delay in the range of 0 to 1 second. The spec does not specify a random delay when responding to unicast LBMs, but it does not prohibit it either. There is no requirement in Y.1731 that mandates that the LBRs have to be sent in the same order as the LBMs. Our EOAM solution does support a port level option that eliminates the delay and causes us to respond immediately to received LBMs. This should guarantee that we respond to LBMs in the same order that they are received. In the GUI, Select Port -> EOAM -> Response Options -> Immediate LB Response If required, please check attached screenshot that demonstrates
The issue may relate do with our default behavior of delaying responses to LBMs by a random delay between 0 to 1 second as per section 7.2.2 Multicast ETH-LB in the Y.1731 spec:
In the GUI, Select Port -> EOAM -> Response Options -> Immediate LB Response
If required, please check attached screenshot that demonstrates