@Clive_A Let's take a step back and establish some facts.

I am seeing unwanted traffic coming into a particular port <src-switch-port> on my switch; this port has PVID <vlan> and is in the untagged list for <vlan>. I have identified the IP range <network-to-reject> of the unwanted traffic. I have determined that the unwanted packets all have ethertype <ethertype> and are sent with eth.src=<device1-mac> and typically with eth.dst=ff:ff:ff:ff:ff:ff. I have determined that acceptable packets of ethertype <ethertype> also originate from device1, but with ip <device1-ip> within the range <network-to-accept> (outside of <network-to-reject>). The acceptable packets are destined for device2 with MAC <device2-mac> and IP <device2-ip>. device2 is a DHCP client of device1.

A reasonable user in my position would expect that a simple IP ACL could be used to block all packets from a given IP range. I created a new IP ACL with ID 500 and added a rule with operation = Deny, S-IP = <network-to-reject>, Mask = mask of <network-to-reject>. I bound this rule to <src-switch-port>, then separately to <vlan>. Neither works; the switch only blocks some packets but lets others through; in particular, it has no effect on packets with ethertype <ethertype>.

OK, packets of type <ethertype> technically don't have an IPv4 section, though they do call out IPv4 addresses, so that could explain this behavior. Maybe the IP ACLs just don't look at the IPv4 addresses in packets of ethertype <ethertype>?

Per the switch documentation 1910013560 REV5.0.0:

"If there is configured ACL rules and no matching rule is found, the packets will be dropped." [Page 911]

and

"Every ACL has an implicit deny all rule at the end of an ACL rule list. That is, if an ACL is applied to a packet and none of the explicit rules match, then the final implicit deny all rule takes effect and the packet is dropped." [Page 913]

Therefore, I should be able to make a simple bogus pass rule which will match no packets, and all packets should get dropped, regardless of ethertype, MAC address, etc. I created a MAC ACL with a single rule with Action = Permit, D-MAC = 12-34-56-78-9a-bc, mask = ff-ff-ff-ff-ff-ff. I bound this MAC ACL to <src-switch-port>. As expected, zero packets match this rule, and all TCP/IP traffic is blocked, yet packets of ethertype <ethertype> are still coming through, even though they do not match any rule in the ACL and should be dropped by the implicit deny rule. Clearly, the ACLs do not apply to packets with ethertype <ethertype>. Please point me to any place in the documentation where any ethertype limitation on MAC ACLs is noted.

Please let me know if I am doing something obviously wrong here; otherwise, the ACLs on this switch do not behave per the documentation and are objectively useless for my scenario. Regardless of how you think I should be using my equipment, I purchased this switch under the premise that the ACLs would function on arbitrary networks and ethertypes, since they are functionally advertised as such, but on the real hardware they appear to have significant undocumented deficiencies, which result in significant undocumented security risks. The UI (including the emulator, which I evaluated before purchasing the switch) happily accepts a rule with ethertype = <ethertype-to-reject> and then totally ignores that constraint with no warning or clarification. It also happily accepts a rule with IP = <network-to-reject> and then totally ignores some undocumented subset of packets from that network with no warning or clarification. Please provide the list of ethertypes that an IP ACL ignores. Please provide the list of ethertypes that a MAC ACL ignores. Please provide the list of ethertypes that a combined ACL ignores. Please provide the kinds of packets that the various ACLs will ignore.

The only other potential solution I could find was IPv4 IMPB, since in my case, <ethertype> happens to be 0x0806 (ARP).

I created a manual binding with IP = <device1-ip> MAC = <device1-mac> vlan = <vlan> port = <src-switch-port> protect type = both (also tried protect type = "ARP Detect"). I enabled "ARP Detect" and enabled vlan <vlan>. I can see that ARP packets from device1 destined for <device2-mac> / IP <device2-ip> arrive at device2, and device2 replies back. In the log files for the switch, I see:

Dropped ARP reply PKT SMAC <device2-mac> DMAC <device1-mac> SDMAC <device2-mac> SDIP <device2-ip> TMAC <device1-mac> TIP <device1-ip> on Po2 in vlan <vlan>, due to - IMPB MATCH FAILURE.

Why is the switch rejecting these replies? How can I configure switch port <src-switch-port> to pass ARP requests originating from <devcie1-mac>/<device1-ip> and ARP replies destined for <device1-mac>/<device1-ip> but reject all other ARP packets?