Traffic-loop-through-the-MC-LAG-peer.

Topology: two qfx10002-72q (Junos: 20.2R2-S3.5) that connect to EX4300 [4 member VC (Virtual-Chassis), running 18.4R2-S7.4] over interface ae56.

Issue: Intermittent connectivity to the endpoint devices on the EX4300 VC. On EX4300 VC mac moves were observed. 

During the problematic state, mac moves are see as below: 

{master:0}[edit]
user@hostname# run show ethernet-switching mac-learning-log | last 3 | refresh 1 | match xx:xx:xx:xx:xx:e4  
---(refreshed at 2023-01-24 00:30:33 UTC)---
Tue Jan 24 00:30:33 2023 vlan_name vlan81+81 mac xx:xx:xx:xx:xx:e4 was moved from xe-1/2/0.0 to ae0.0 with flags: 0x2101f
Tue Jan 24 00:30:33 2023 vlan_name vlan81+81 mac xx:xx:xx:xx:xx:e4 was moved from ae0.0 to xe-1/2/0.0 with flags: 0x2101f
---(refreshed at 2023-01-24 00:30:34 UTC)---
Tue Jan 24 00:30:34 2023 vlan_name vlan81+81 mac xx:xx:xx:xx:xx:e4 was moved from xe-1/2/0.0 to ae0.0 with flags: 0x2101f
Tue Jan 24 00:30:34 2023 vlan_name vlan81+81 mac xx:xx:xx:xx:xx:e4 was moved from ae0.0 to xe-1/2/0.0 with flags: 0x2101f
---(refreshed at 2023-01-24 00:30:35 UTC)---<>

For some reboot cases, we will observe BUM traffic coming from the ICL link and will loop through the MC-LAG interface.  At issue time, it's seen that some events between kernel and PFE are out of sync and because of that it is affecting the programming of MC-LAG copy in replication.  And because of that the local bias filter for the MC-LAG copy will not hit. Because of the traffic loop, we will see mac-move in the downstream box. Disable/enable or deactivate/activate the MC-LAG interface to resolve this issue.