My interpretation, stealing the graphic from @sindy
Consider if you had a Router with a dedicated routed port, perhaps on a RouterOS x86. And you want to have multiple subnets, so you create vlan interfaces on the eth port and connect it to a switch.
The base ethernet will still have a linux interface associated with it, and traffic coming from the ethernet base interface will not be tagged with any vlan, in fact there is no vlan. However when you connect this to a vlan-aware switch, that traffic will be “mapped” into one vlan on the switch, whatever vlan the switch’s port has its pvid set to. When you create vlan interfaces anchored to the ethernet interface, traffic from those vlan interfaces will be tagged with the vlan specified when creating the vlan interface.
What if you didn’t want any traffic “leaking” from the ethernet base port into the switch? One way would be to block all traffic without a tag by using frame-type filtering on the switch port. Likewise if you created a vlan interface for vlan 666 on the router, but didn’t have any vlan 666 defined on any port on the switch, using ingress filtering on the trunk port will drop the frame as soon as it arrived at the switch-port.
When the interface is a bridge device on the router instead of an ethenet port, I think creating the vlan interface will allow tagged frames to be sent to the switch. Until you add a bridge vlan to the “trunk” with the /interface bridge vlan … tagged=bridge … vlan-ids=#, the switch port connecting to the CPU port won’t have the vlan configured on the switch-port, but the switch-port could still receive a frame tagged with the vlan. So I think traffic could leak into the switch’s vlan, but any return traffic won’t be allowed back (because the vlan isn’t configured on the “switch-port to the CPU” I suppose this could be tested in a lab, but I don’t have time right now.
In summary:
a. I can’t think of any reason checking ingress filtering would break anything (other than “asymmetric vlans” where SVL must be used, and there are better ways to achieve “isolated ports” than using asymmetric vlans).
b. it prevents frames tagged with a vlan and arriving as ingress to the switch-port from the CPU-port from being accepted if the switch-port is not a member of the vlan (I think this corresponds to the switch feature vlan-mode=secure).
c. it is always an “ingress” feature. it just applies to the switch-port that doesn’t have an external physical port associated with it, the switch port that is connected to the “internal” trunk link to the CPU.
d. the unasked question. What does frame-type do on the “bridge”. I think this really applies to the switch-port side, e.g. it can block untagged frames from entering the switch. As I typed this, it makes me wonder it if could affect spanning tree protocol. Does anyone know? For example on the hEX, I think any spanning tree is done by the CPU.