Hi. I want to try and do an unorthodox thing on my home network.

There's an awful lot of protocols that you would want to work on a home network that depend on a single multicast packet emitted from one node on the network being able to reach all other nodes on the network. Multicast routing, however, is confusing at best, and even more so with MikroTik. There is very little documentation and it seems to be of no use to anyone but the network pros. I've found that the easiest solution, is to just put everything in a bridge and enable 'use-ip-firewall' setting, so that you can still put your servers into their own little walled garden, just in case.

For this reason, I'd like to do Inter-VLAN Bridging on my home network. (I also don't quite like how the router has to have a separate address for each VLAN, this seems pretty unnecessary)

Let's say I have two ports, ether1 and ether2. There's a device (172.16.1.1) connected to ether1 that uses native VLAN, i.e. does not send out packets with VLAN tags and does not accept packets with VLAN tags. Let's say there is a unicast packet coming in on ether2 with a VLAN tag (VLAN-ID=20, for specificity's sake) that has 172.16.1.1 as a destination address. I would like it to be forwarded to the device on ether1, stripped of its VLAN tag. I would also like for the device to be able to reply to that packet and reach whatever device was sending this packet. It would send an untagged packet towards ether1 with destination IP address, say 172.16.1.2, and the packet would be bridged and would come out of ether2 with an appropriate VLAN tag (VLAN-ID=20).

I would then like to use IP firewall to moderate which connections are allowed, and which aren't. For example, let's say, I'd like to expose my media server to my guest network (let's say VLAN-ID=10), but not the other way around. I would first put the media server on a separate VLAN (let's say 55), then set up a rule to drop any connections from vlan 55 to vlan 10, then a rule to allow established connections through.

Problem is, any way to make this real that I can come up with is either a known level 2 misconfiguration or simply doesn't work.

The most obvious way that comes to mind first, is to put all required physical interfaces in a bridge, set up VLAN interfaces on this bridge, and then put these VLAN interfaces in another bridge. But that's just "VLAN on a bridge in a bridge" L2 misconfiguration.

There's also a "Bridged VLAN" L2 misconfugration, which isn't a misconfiguration at all if you don't create loops or want STP, and seems to be exactly what I want, apart from being CPU-heavy. However, it doesn't seem to work with native VLAN. I can only think of one way to allow native VLAN to also be bridged, and it's to put physical interfaces into the bridge. But that's yet another L2 misconfiguration, "VLAN interface on slave interface".

Please help. I'm utterly confused as to how to do this. It seems like it should be simple.

(I also don't quite like how the router has to have a separate address for each VLAN, this seems pretty unnecessary)

It seems that you don't quite understand the (V)LAN concept, do you? I haven't read your explanation in depth, just skimmed it ... and it seems to me you want to have a flat LAN, so why bothering with VLANs etc.?

It seems that you don't quite understand the (V)LAN concept, do you? I haven't read your explanation in depth, just skimmed it ... and it seems to me you want to have a flat LAN, so why bothering with VLANs etc.?

Mhhm... As for the VLAN concept, in my understanding, at least with home networks, the only tangible benefit of VLANs is isolation of different network segments, so that, for example, your suspicious chinese IoT products don't get to play with the rest of your network. And that's kind of what I'm trying to achieve.

(And there isn't much of a concept to speak of, honestly. You add a 4-byte tag to packets, packet switching becomes different, you get multiple isolated broadcast domains going through one cable. Sure, there's also the network architecture side of things. But, again, as far as home networks are concerned, I think it's not particularly hard to think about tags and where they get added or stripped, and how packets get consequently bridged or routed, instead of whipping out a CCNA book and saying incantation-sounding words just to make Plex work on your guest network)

I'm kind of trying to achieve an embarrassingly simple thing here, if you think about it in terms of tags.

Think of it as adding 3 more symbols to all MAC addresses on the network, with two main rules: (1) the network equipment assigns these 3 symbols and (2) you can make firewall rules based on what these 3 symbols are. Everything gets bridged by default, but you can make adjustments here or there where it's needed. It's convenient.

In terms of tags, I need to separate packets into a few VLAN interfaces on ingress based on tag (or its absence) and bridge all those interfaces as though none of the tags were ever there, and also strip the tag on egress from any of the native-VLAN-related interfaces.

I know for a fact that this would be quite simple to do with the help of two (or even one, but for simplicity's sake let's say two) additional 802.1q-supporting switches:

1. Let's say there are two interfaces on the first switch, eth10 and eth11, two on the router, eth20 and eth21, and two on the second switch, eth30 and eth31.
2. Let's say eth11 is connected to eth20 and eth21 is connected to eth30.
3. We can configure the first switch to add a VLAN tag with id 10, if it's missing, on ingress on eth10, and set up forwarding from eth10 to eth11. We can also configure an additional VLAN, let's say with id 20, so that eth10 can receive tagged packets with that VLAN tag and forward it to eth11 if need be. Thus, eth10 is a hybrid port, and eth11 is a trunk.
4. We can configure two VLAN interfaces with ids 10 and 20 on eth20. We can do the same for eth21. Then we can put these VLAN interfaces in a bridge.
5. We can mirror the configuration of the first switch on the second switch by stripping the vlan tag with id 10 on egress from eth31. Thus, eth30 is a trunk and eth31 is a hybrid port.
6. Et voila. The thing can now be mirrored the other way around, and we have what I wanted.

Problem is, it seems to me like that 4 core 1.8 GHz CPU of an ax3 should be able to handle all of that on its own, without the need for two additional switches.

I admit that this is not a proper approach to networking. If one would do this in a corporate setting, it would probably result in a multitude of problems. It is definitely bad for overall network performance.

But if you only have 500 Mbps of internet connection to play with, duplex gigabit interfaces on all of the network equipment (with 2.5G here-or-there), and a topology simple enough to diagnose most of the problems resulting from such a setup with relative ease, I daresay none of this really matters at the end of the day.

If all ports are part of a bridge, and you enable IP firewall on the bridge, then, unless hardware offload (switching) is enabled on the individual ports (which it is by default), it should send all traffic through the firewall. At that point, you can use whatever Layer 3 rules you want to keep devices from talking to each other or the Internet. There are also filters available on bridges.

In both cases, HW offload would need to be disabled on the ports, which then drops wirespeed switching and puts your bandwidth between devices at the mercy of your CPU.

("Inter-VLAN bridging" is an oxymoron, by the way.)

Suggest you approach this in a logical manner instead of playing footsie with switch settings or bridge talk all without any real focus..

a. identify all the devices/users including the admin
b. identify all the traffic flows they actually require 9 (no mention of config etc.)
c. provide a network diagram (plan) detailing devices involved, where the internet connection(s) are coming from, expected subnet flows between devices down to the port if possible)..
d. provide current config of all attached MT devices to see how you have attempted to implement the plan laid out in a,b,c

At that point, you can use whatever Layer 3 rules you want to keep devices from talking to each other or the Internet.

And that is precisely the problem. You can only do it at that point. The moment you put a switch before the router, layer 3 filtering collapses, as it is possible for packets to be sent where they shouldn't be sent, before they ever reach the router. That's where VLANs come in.

("Inter-VLAN bridging" is an oxymoron, by the way.)

Well, Cisco seems to use this term.

In both cases, HW offload would need to be disabled on the ports, which then drops wirespeed switching and puts your bandwidth between devices at the mercy of your CPU.

Also, as stated previously, I couldn't care less. WiFi speeds are always at the mercy of the CPU, and they seem to be fine. So the CPU is probably merciful enough.

Nothing stops your inter-vlan bridging configuration, per se, but you make a mess of STP that needs to be managed (e.g configuring MSTP, or disabling STP everywhere). But certainly the doc aren't going to recommend bridging VLAN together because of all the side-effects. Doesn't mean you cannot do it... but unless you're pretty familar with STP, it be a tough climb. Now I agree other routers do "support" what you suggest, even some Netgear switches, but it not a "protocol" more a configuration option.

To me this sounds like a bridge filtering issue. If you have untrustworthy devices you want to restrict but also allow some access, do it by MAC address in bridge filter. e.g. put all your devices in one bridge/VLAN and then restrict forwarding in bridge filter. The filter rules can be wildcards, so likely can cover any "groups" of IoT devices since they should have the same starting MAC addresses. If the idea is security, blocking at Layer2 is better than Layer3, but multicast all still be on same subnet.

Underlying the problem here is there is no mDNS/DNS-SD support, which allow multicast discovery across subnets/VLANs. IGMP/PIM AFAIK do work for multicast routing. The issue is that per specs mDNS is a link-local multicast address, so it cannot be multicast routed. Other multicast protocols work via IGMP/PIM, but since mDNS is most common... IGMP/PIM routing appears not work.

So, it seems that my devious plan is foiled mainly by the fact that I want to bridge native VLAN with other VLANs. I can create a VLAN interface with id=1, that's for sure. But it appears that it's either not capturing traffic, or outputting traffic with tag present with vlan id set to 1, or both. I could potentially recreate a setup like the one I described above, with virtual switches inside ROS, but I'd need something like a virtual ethernet cable to make it happen, i.e. a pair of interfaces where whatever comes in one side comes out on the other side unchanged. Then I'd be able to make several bridges and connect them up inside the OS. But as ROS is now, it appears that this simply cannot be done. Which is kind of a bummer. They always say that you can do anything in ROS.

I can create a VLAN interface with id=1, that's for sure. But it appears that it's either not capturing traffic,

You're right, it's not capturing traffic. Reason being that native VLAN comes untagged off bridge interface while any VLAN interface expects tagged frames on "anchor" side. If you'd convert the bridge to "all tagged" (so bridge doesn't have pvid set ... which is not really possible, default is pvid=1, but setting frame-types=only-tagged overrides this) and setting bridge as tagged member of VLAN 1 makes VLAN interface actally usable.

So yes, it is possible to do almost anything in ROS but one has to know his trade

So, it seems that my devious plan is foiled mainly by the fact that I want to bridge native VLAN with other VLANs. I can create a VLAN interface with id=1, that's for sure. But it appears that it's either not capturing traffic, or outputting traffic with tag present with vlan id set to 1, or both. I could potentially recreate a setup like the one I described above, with virtual switches inside ROS, but I'd need something like a virtual ethernet cable to make it happen, i.e. a pair of interfaces where whatever comes in one side comes out on the other side unchanged. Then I'd be able to make several bridges and connect them up inside the OS. But as ROS is now, it appears that this simply cannot be done. Which is kind of a bummer. They always say that you can do anything in ROS.

Its not actually a plan ( its tinkering with config functionality and networking concepts with no basis in reality ), and it has nothing to do with User/Device Traffic requirements, with which, one can derive a straightforward (non devious) plan and an optimally efficient config

Reason being that native VLAN comes untagged off bridge interface while any VLAN interface expects tagged frames on "anchor" side. If you'd convert the bridge to "all tagged" (so bridge doesn't have pvid set ... which is not really possible, default is pvid=1, but setting frame-types=only-tagged overrides this) and setting bridge as tagged member of VLAN 1 makes VLAN interface actally usable.

Ah. Thank you. This will probably kind of do the thing that I was trying to achieve. But only with an L2 misconfiguration, i.e. if I put, say, ether1 through ether4 in bridge1, set up a few VLAN interfaces on bridge1 and then put them all in bridge2. The problem will be that the moment a packet actually gets bridged between VLANs, it will need to first get flooded to all ports in bridge1. Even I am not crazy enough to run a configuration like this one. I can tolerate going hard on the CPU. I draw the line at going hard on the rest of the network.

The story would be different if you could somehow have an "untagged VLAN interface", which would capture only untagged packets and output only untagged packets. Then I could have 1 "untagged VLAN interface" and multiple VLAN interfaces on each ethernet interface (ether1 through ether4), then put all these interfaces in a bridge. Then MAC learning wouldn't be broken and unicast packets wouldn't be flooded. Alas, it seems that this is not possible.

Its not actually a plan ( its tinkering with config functionality and networking concepts with no basis in reality ), and it has nothing to do with User/Device Traffic requirements, with which, one can derive a straightforward (non devious) plan and an optimally efficient config

Yes, but I don't like it. Isolating devices without VLANs by means of bridge filtering alone is tedious. Multicast routing is a pain. Bridging VLANs is thus theoretically the most flexible solution. You just plug everything into the "main router", with every port on it being a hybrid one with all VLANs, and it works automagically, without the need for complex configurations on any more devices but the aforementioned main router. A utopia, at the cost of high CPU usage.

But only with an L2 misconfiguration, i.e. if I put, say, ether1 through ether4 in bridge1, set up a few VLAN interfaces on bridge1 and then put them all in bridge2. The problem will be that the moment a packet actually gets bridged between VLANs, it will need to first get flooded to all ports in bridge1.

No, it's not really a L2 misconfiugration[*]. Both bridges will do the "switching" thing, meaning they will only forward packets to port to which destination is connected (if they have such information). So bridge2 will only forward packet to VLAN of destination and bridge 1 will then send it out of port where destination is accessible (via correct VLAN). Packets traverse the two bridges sequentially as if you had two layers of ethernet switches and a packet from one port of one access switch towards another port of another access switch has to pass the core switch (where access switches are connected to core switch and don't have direct connection to each other). In the two-bridge scenario, bridge1 with VLAN filtering enabled acts as access switches, each VLAN acts as one access switch. bridge2 then acts as core switch.

[*] I'd say that L2 misconfiguration is the fact you have VLANs but you want to join them. But this misconfiguration is conceptual rather than technical. Since I don't want to be part of such craziness, I'll avoid this thread from now on.