Help needed with bridge VLANs & DHCP

[Buckeye]

I guess one of most under-valued topics/tutorials is post explaining all the bridge functionalities by forum legend @sindy. I’d say that every new Mikrotik admin (i.e. people who leave QuickSet trap in quest for better configuration) should read it before even trying to change L2 setup (let alone adding VLANs into the mix).

With regard to @sindy’s RouterOS bridge mysteries explained, while arguably one of the best discussions about the vlan-filtering bridge (and it was one of my primary sources of learning how MikroTik filtering bridge works, coming from EdgeOS ER-X switch0), there are some things that I don’t agree with. And considering the source, I have to be very careful in disagreeing, but I think @sindy should review and possibly edit his post if he is convinced by my argument:

In [url-RouterOS bridge mysteries explained]post #1[/url] of RouterOS bridge mysteries explained, the following is stated:

@afuchs

And now the confusing points.

Since, when you add a “bridge”,

• all the three elements (interface of a router, port of a switch, and the switch itself) are created,
• the relationship among the three is a fixed one,
• none of the elements has got any configuration parameter that would overlap with a configuration parameter of the remaining two,

the configuration parameters for all the three elements have been grouped on a single row of the /interface bridge table.

In particular:

• parameters bearing the same names as those on the /interface bridge port rows, such as pvid or ingress-filtering, are parameters of the router-facing port of the virtual switch
• parameters bearing the same names as those on the /interface ethernet rows, such as mtu or arp-timeout, are parameters of the switch-facing interface of the router
• parameters that don’t fit to any of the two groups above are mostly parameters of the virtual switch; an exception are the admin-mac and auto-mac parameters, which are also parameters of the switch-facing interface of the router.

The name item is common for all the three elements. So when specifying the membership of the router-facing port of the switch in VLANs, the same name is used to identify the virtual switch and to identify the router-facing port:
/interface bridge vlan
add bridge=bridge-row-name vlan-ids=10,… tagged=bridge-row-name,…

In the bridge filter, the relationship of the frame to the router-facing port of the switch determines the chain to be used: input handles frames that egress from the virtual switch through that port, output handles frames that ingress to the virtual switch through that port, and forward handles frames that bypass that port.

The part I take issue with is

In particular:

• parameters bearing the same names as those on the /interface bridge port rows, such as pvid or ingress-filtering, are parameters of the router-facing port of the virtual switch

Where I disagree is what /interface bridge port rows apply to; my claim is that they apply to the real exterior switch-ports, not the “internal” router-facing trunk port of the virtual switch. In other words these are analogous to configuring the switch-ports of the vlan-aware switch other than the “uplink” to the CPU/routing engine block; that uplink trunk is controlled by the /interface bridge vlan rows, and by the [optional] pvid specified in the /interface bridge which specifies the vlan that won’t be tagged at the CPU end, (the switch-facing interface of the router). The pvid specified on the /interface bridge is the vlan on the switch ASIC that will be associated with the base bridge interface, and if not specified, it will be pvid 1.

See Bridge port settings for the “official” documenation, which agrees with my experience with playing with vlans on an RB760iGS with v7.2+ firmware (currently running v7.5).

If anyone disagrees with my understanding, please present your reasoning; if I am wrong I want to understand what I am misunderstanding.