What does setting the PVID against the bridge rather than just the individual bridge ports do? What are the situations when you would use this?

I understand that PVIDs tag untagged traffic on ingress to a port but I can't quite wrap my head around what implications this has when setting the PVID on the bridge itsself.

If you want to do routing between ports of different pvid, the bridge needs to know about each of them.
If not, it passes simply by since the bridge can not " read" the packets.

That's my probably too simplistic understanding.

Some of the /interface bridge settings relate to the intrinsic bridge-to-CPU port rather than the bridge itself, see viewtopic.php?t=173692

usually i'm changing PVID on the bridge interface.

Good practice for security reason

I did some further testing on this and it seems as if setting the PVID on the bridge as whatever your management VLAN is is a reallyyy good idea from a security perspective (as Nichky kindly mentioned) as I can then only access it from interfaces with the same PVID (e.g. the interface my PC is on).

In case anyone was confused like me and stumbles across this in the future, I've got it setup so that the PVID on the bridge is 5 and VLAN 5 is also tagged in the bridge in /interface bridge VLAN. Eth 6 also has a PVID of 5 so I can only get in through that port. The ports that go to my other switches also have a PVID of 5 and are untagged for VLAN 5 so they are all getting management addresses. The rest of my VLANs are tagged on the ports to my switches.

Having the same VLAN tagged and untagged on ports (either a physical ethernet or the intrinstic bridge-to-CPU ones) often breaks communications as packets end up being tagged in one direction but not the other, so you are using a side-effect of this misconfiguration to limit access. The correct way to limit management access is with firewall rules.

I was under the impression that having having all your VLANs tagged over your trunk and then your management as untagged VLAN over that same port was the done thing since that's how you would send traffic for multiple VLANs over the trunk but also tell your switch at the other end "you should have an IP from the management VLAN".

Is that incorrect?

I know it should be done with firewall rules too but my thought was just, the more security when it comes to management the better.

Purists argue that on trunks all VLANs should be tagged, so you would set frame-types=admit-only-vlan-tagged ingress-filtering=yes - the pvid= setting can be anything as it is ignored.

Others prefer hybrid trunks where one VLAN is untagged, often for management and with limited access to other devices and/or internet, and any other VLANs tagged. However the VLAN which is presented untagged should never also be presented tagged.

Another perspective...........

Dont mess with the bridge, keep it at defaults and dont use it for any data traffic. KISS!!
Managment vlan would be typically identified also as a member of the management INTERFACE LIST and used for neighbours discovery and mac-server winmac-server setting.
All smart devices that can read vlans would get their IP address from the management vlan.

All ports going to smart devices are trunk ports ingress-filtering=yes, frame-types=admit-only-vlan-tagged.
All ports going to dumb devices are access ports ingress-filtering=yes, frame-types=admit-priority-and-untagged pvid=XX

I think this is a perfectly reasonable secure process to use, and I see no purpose in butt phucking myself by changing the bridge default to be cute!
This works with all smart devices, other MTs, and all other vendors APs and switches I have used. LIKE BUTTA!!

The only reason in this day and age to even discuss hybrid ports is the DUMB Twats at unifi and maybe some others*** that setup the management interface to be untagged as default.
Therefore, if one is not able to change the default setup, one has to hybrid into the moronic device with the management subnet untagged and all the data vlans as tagged, and yes it sounds and is stewpid.
In this case case its probably better to just set the interface and required PVID as who knows what stating ingress-filtering=yes will do.......

*** other hybrids: some Phones and perhaps other devices typically have in the past accepted the tagged traffic coming to the phone for VOIP and can pass the untagged traffic onto an attached computer.
(phone as two ethernet jacks)

Some of the /interface bridge settings relate to the intrinsic bridge-to-CPU port rather than the bridge itself, see viewtopic.php?t=173692

good explanation, to the point

The only reason in this day and age to even discuss hybrid ports is the DUMB Twats at unifi and maybe some others*** that setup the management interface to be untagged as default.
Therefore, if one is not able to change the default setup, one has to hybrid into the moronic device with the management subnet untagged and all the data vlans as tagged, and yes it sounds and is stewpid.
In this case case its probably better to just set the interface and required PVID as who knows what stating ingress-filtering=yes will do.......

*** other hybrids: some Phones and perhaps other devices typically have in the past accepted the tagged traffic coming to the phone for VOIP and can pass the untagged traffic onto an attached computer.
(phone as two ethernet jacks)

Would you be able to speak to why Hybrid ports are so bad? For example if I had VLAN 10 as management and I had 3 switches in a configuration where Switch 1 connects to Switch 2 which then connects to Switch 3 that all needed various VLANs trunking between them, surely I would need to utilise Hybrid ports for the trunks between the switches so that VLAN 10 is tagged and untagged on the trunk ports therefore allowing VLAN traffic for all VLANs but also providing addresses to each switch from VLAN 10.

Is there a better way of achieving this? For example, would using an actual VLAN interface for VLAN 10 on Switch 2 tagged on the trunk to Switch 1 work better? Since that way you could stick a DHCP client on the VLAN 10 interface and wouldn't need to untag VLAN 10 on the Switch 1 side of the trunk in order to give Switch 2 a VLAN 10 address.

There might be brain-dead network gear (managed switches, APs) which support VLANs but not for management access. For those one has to use hybrid ports inside LAN infrastructure. However, many (if not most) support using a dedicated VLAN for management access ... and that allows to get rid of untagged frames inside LAN infrastructure, hence all involved ports are trunk (tagged only).

IMO it's much better to configure everything in same manner and not having to play different game for one particular VLAN (where ID is nil).

But I guess that the dilemma about hybrid vs. trunk is mostly one from "holly wars" category ... a matter of personal preference of network admin.

@mkx thanks for the reply. How would you recommend configuring it so that the Mikrotik receives an IP address from a management VLAN without using hybrid ports? As mentioned the only other way I can think of is creating a VLAN interface at the Switch end of the trunk for the management VLAN and sticking a DHCP client on that.

Is there a more widely accepted method? As based on yours and Anav's replies it seems like Hybrid Ports aren't necessarily a problem but are definitely not the best way of going about this.

As mentioned the only other way I can think of is creating a VLAN interface at the Switch end of the trunk for the management VLAN and sticking a DHCP client on that.

Nope. Since trunk port is member of bridge, then any other business with that port is strictly off limits.

Instead you should configure that port as tagged (frame-types=admit-only-vlan-tagged ingress-filtering=yes), add it as tagged member of all necessary VLANs (including management VLAN). Now comes the magic: bridge (the CPU-facing virtual switch) port should be added to tagged members of management VLAN (so there will be at least two such members, trunk port and bridge port) and you should create vlan interface with vlan-id set to management VLAN ID and anchored to bridge interface. As the last step you can set bridge interface with frame-types=admit-only-vlan-tagged to cut the untagged bridge acccess to networks (this makes pvid setting on bridge port irrelevant).

Then use the vlan interface to setup management IP address and the rest of bells and whistles.

And the above is essentially what setting "management VLAN" to some VID does on GUI-driven switches.