Properties pvid, ingress-filtering (and similar), set on bridge, are about behaviour of bridge CPU-facing port (see explanation in this tutorial). So essentially there’s no difference in what settings do, the difference is on which bridge port they are effective.
The way untagged (access) ports work on bridge with vlan-filtering enabled is the following:
- upon arrival of ingress frame, port first checks frame-types property. If ingress frame doesn’t satisfy the setting (e.g. ingress frame is untagged while frame-types is set to admit-only-vlan-tagged), it gets discarded
- if ingress frame is untagged, it gets tagged with VLAN header, VID set to value of PVID (per port)
Mind that there’s implicit default setting of pvid=1 on every bridge port in ROS and if vlan-filtering is enabled, then this setting kicks into action. Implicit meaning this setting is not explicitly shown in exported config (and IIRC neither in GUIs). It’s shown when e.g. executing export verbose though.
When vlan-filtering is enabled, every frame passing bridge (the “virtual switch functional block”) will be tagged (even if with VLAN ID=1). - if property ingress-filtering is enabled, then bridge consults VLAN table (defined in /interface/bridge/vlan) whether frame’s VLAN value is one of allowed VIDs for ingress port. If it’s not, then ingress frame gets discarded
If port is set to accept untagged frames, then in recent ROS versions (where ports get added to appropriate VLAN table automatically) it’s highly unlikely to see frame dropped. In older versions device admin had to maintain VLAN table manually and if he fogot to add ingress port as untagged member of that particular VLAN, untagged frames could get discarded.
If ingress frame is VLAN tagged, then step #2 obviously doesn’t get executed. The rest of steps are the same.
And in this case, it’s more likely for step #3 to discard ingress frames … if connected device tries to pass frame with VLAN ID set to value which is not permitted on ingress port according to VLAN table. Without ingress-filtering enabled, such ingress frame (with invalid VALN ID set) would be accepted on ingress … however any return traffic (using same VID) would not be able to egress through this port. This might seem to suffice to block unsolicited traffic … but it’s not enough, broadcast traffic (or unicast UDP packets) can still be injected into disallowed VLAN, hence need for ingress-filtering to be enabled on any security-conscious network.
[edit] better structuring of the post