This KB describes the issue wherein adding a mac-address in a firewall filter term in a FF attached to et-0/1/4 interfaces causes the unreated ae member interfaces to land in attached/detached state

Customer are facing an unexpected behaviour/ issue where applying the firewall filter TEST1 to et-0/1/4 causes all the AE interfaces members in in attached state even though the filter is not applied to ae4.

Details:Filter applied to et-0/1/4:

set interfaces et-0/1/4 unit 0 family ethernet-switching filter input TEST1

set firewall family ethernet-switching filter TEST1 term MAC-FILTER from source-mac-address aa:bb:cc:dd:ee:ff/48

set firewall family ethernet-switching filter TEST1 term MAC-FILTER then accept

set firewall family ethernet-switching filter TEST1 term DENY-ALL then discard

ae4 has a different filter:

set interfaces ae4 unit 0 family ethernet-switching filter input TEST2

This issue has been identified due to a port number overlap between a process related to a packet injecting from packetio to asic with CPU_TO_VOQ mode.

In the cpu header the port number is using value 32 that could be also used by the wan port et-0/1/4.

When filter attach to a wan port that use the port num 32, the filter could also impact on the host inject l2 traffic which use the same port number.

To fix it, the packetio inject the traffic with port 88 that is assigned to the lcpu port for BT.

The work-around for the issue is to avoid using the firewall filter on port et-0/1/4.