Hi all,

I am trying to understand how bridge level filtering works.

What I am trying to achieve (and have done it more less, but I am curious if there is a better solution):
Three separate networks within my router: guest, multimedia and home. Multimedia should be visible for guest and home, but guest and home should not be allowed to talk to each other. Multicast traffic should be also allowed between multimedia and other networks (but again, not between home and guest).

What I've done so far is two vlans (guest and multimedia are only on wifi, ether10 is connected to access point and AP is tagging the packets correctly). VLANs are defined only in "Interfaces -> VLANs", each of them has a name (e.g. vlan-multimedia and vlan-guest) and a vlan id assigned to it.
All interfaces (physical and vlans) are connected to one (and only) bridge. And on bridge->filters level I can filter packets based on interfaces (e.g chain=forward, interface in=vlan-guest out=!vlan-multimedia > drop). This seems to work fine, however there are some questions I have:

1. There is also Bridge->VLANs submenu - is it used for tagging outgoing packages from a bridge?

2. There is also Switch->VLAN submenu - what is it for (I can select more than one interface there, as opposed to Interfaces>VLANs)?

3. In Switch->Port, I can configure port to always mark a package with a given vlan id, but this does not create new interface to be used in bridge filters - how would I filter traffic between vlans then?

4. Why can't I select more ports in "Interfaces -> VLANs" for a given vlan name?

5 Let's say I connect some multimedia device to ether2 and want to add it to multimedia vlan, my intuition tells me that steps should be following:
- in Switch->Port->ether2 set "vlan header" to "always strip" and set "default vlan id" to the one used by vlan-multimedia
- in Interfaces -> VLANs create new vlan (e.g. vlan-multimedia-ether2) with the vlan-multimedia id
- use vlan-multimedia-ether2 in bridge->filters
That sounds like a lot of work to do - adding one eth port to vlan requires me to create two bridge filters. It would be better if the filtering was done based on the VLAN header.

I'm only starting with new bridge myself, but from few simple tests it looks like nice and intuitive way to configure things.

1) It's used to define VLAN / port mapping. It tells router where the given VLAN(s) should be tagged, untagged or not at all.

2, 3) I thought this should be gone with new bridge implementation...

4) This is how you define interface for given VLAN, if you need router to be part of it. You only select one parent interface (in this case bridge) and define ports in 1).

5) I'm confused about Switch menu, I really thought it shouldn't be there (so far I did my tests only with CHR, where it wasn't even before, so I couldn't see that it stayed). For VLAN filtering, you shouldn't need any bridge filters, the new Bridge VLAN Filtering should take care of that.

I am trying to understand how bridge level filtering works.

Let's clarify the terms first. Filtering in general means that you let some packets (when talking about L3) or frames (when talking about L2) get through and some not.

VLAN filtering in particular enforces that frames tagged with a particular VLAN ID are only forwarded between physical or virtual ports made "members" of that VLAN - nothing more and nothing less. So when a frame with a particular VLAN ID in the tag arrives from outside to a non-member port of that VLAN, it is dropped, and when it arrives to a member port and is either a multicast/broadcast one or a unicast one with a yet unknown to the switch/bridge destination MAC address, it is sent out only via member ports of that VLAN ID.

To make things more complex, in network topologies with multiple links between nodes, you may need to dynamically disable frame forwarding on some ports to prevent loops, and depending on the version of the STP protocol controlling such process, you may even need to have the same port open for some groups of VLANs and closed for others.

Other types of filtering (up to L2 or L3 headers or other packet/frame properties, or up to incoming or outgoing physical interfaces, or a combinaton of all that) are normally a job of a firewall. While technically L2 filtering is very similar to VLAN filtering, its purpose and implementation are usually different.

The whole enigma of the "bridge" and "switch" configuration trees comes from the fact that the switch chip does things like frame forwarding and possibly filtering on MAC addresses, VLAN filtering, tagging and untagging in hardware, which means fast but in one of just a few pre-defined ways, while the bridge does the very same things plus some more in software, so significantly slower than the switch chip but with more flexibility (at least potentially).

Historically, the switch chips available in the required price category were nonexistent or with just a few features, some of them weirdly implemented, and even some RouterBoard models currently sold still use switch chips with serious limitations. Other contain no switch chips at all and all the L2 functionalities are done by the CPU.

Due to the above, the functionality provided by the switch chip and by the bridge used to be configured using separate menus and overlaps to some degree. Starting from 6.41, Mikrotik started integrating them, probably with the ultimate goal of removing the duplicity of configuration and do as much as possible in hardware, but at the current stage of development it causes some confusion, as the same functionality can still be configured independently at both levels, possibly in contradiction with each other.

If we come back to VLAN filtering in particular, in the old implementation of the bridge or when is set to in the new implementation, a frame with any VLAN ID is received and processed, and if it needs to be broadcast, it is broadcast to all ports. Between the bridge and the cables, you may configure vlan filtering on the switch chip.

But as soon as you need to control forwarding down to a group of VLANs per port using MSTP, you currently (6.42.x) have to activate at bridge level, which automatically switches off the direct hardware forwarding between the external ports of the switch chip, causing it to start forwarding packets from all ports only to the CPU (additionally tagged with the port ID so that the CPU could identify the source port). Also if you want to use bonding or the bridge filtering capabilities of the firewall, all frames have to be delivered to the CPU, so the "hardware acceleration" is automatically disabled too. But deactivation of direct forwarding between switch chip ports does not deactivate vlan filtering and tagging/untagging rules configured in the switch chip, which may cause headaches if you don't know exactly what you are doing.

So depending on your application, you may prefer the so-called hardware accelerated bridging, which means that member ports of at most one of the bridges defined can forward traffic to each other at the switch chip level (which is similar to the old implementation of "master" and "slave" ports of the bridge), or you may prefer to let the switch chip only mark the packets with port IDs and let the CPU do everything, which costs you some throughput on the wired/optical L2 forwarding but gives you more features.

I personally hope that Mikrotik will proceed with the integration further and start controlling the switch chip dynamically, so use of MSTP will not exclude direct forwarding in the switch chip any more, but it is just a hope, they haven't revealed the target functionality planned.

The only path from the switch chip to wireless interfaces, as well as to PPPoE and various virtual interfaces including tunnel and VPN ones, or even to another switch chip, is the CPU port of the switch chip, so a bridge between a single Ethernet port and a wireless port cannot be hardware accelerated.

From your description, you have a separate L3 subnet and VLAN ID for each "security domain" (home, guest, multimedia), so you route between these domains and the firewall rules can be L3 ones, using both in and out vlan interfaces or source and destination subnet addresses as filtering criteria. VLAN filtering as such is likely not necessary because you'll probably use Ethernet ports in access mode (tagging on ingress, untagging on egress), which alone kind of acts as a vlan filtering. You don't need to e.g. prevent packets from locally non-existent VLANs to occupy bandwidth of the switch chip if they arrive over a cable from another switch where these VLANs exist. Such need would be a reason to activate vlan filtering on the switch chip.

So to your questions:

1. Code: Select all

   /interface bridge vlan

   menu is used to configure vlan filtering rules for bridges, indicating which VLANs are permitted on which ports and whether they are permitted there tagged or tagless. The rules for any given bridge are only taken into account when
   Code: Select all

   vlan-filtering

   is set to
   Code: Select all

   yes

   in the configuration of that bridge.
2. Code: Select all

   /interface ethernet switch vlan

   menu is used to define vlan filtering rules for switch chips, which work regardless whether the bridge vlan filtering is active or not. So if you permit a VLAN ID on ether1 in bridge, or switch off vlan-filtering ot the bridge completely, but forbid that VLAN ID in this part of configuration, frames with that VLAN ID will not be let in on this port
3. this setting defines how the switch chip handles taggless packets on ingress, i.e. with what VLAN ID they are tagged. On "normal" switch chips, this also means that frames tagged with this VLAN ID are untagged on egress; on "weird" switch chips, this functionality is not available: you can untag all frames, or none, or leave the tag untouched, but you cannot selectively untag only one VLAN ID.
4. Code: Select all

   /interface vlan

   creates a virtual interface which untags frames received from the bridge with a given VLAN ID and tags tagless frames sent to the bridge with that VLAN ID. So it is a virtual access port of that VLAN, which can hold an IP configuration on its tagless side. It does not define membership of other interfaces in the bridge and/or VLAN, and it is only necessary if the router part needs to access that VLAN; if it doesn't, the VLAN ID can only be used in the other menus.
5. • as the device itsellf probably doesn't send or expect tagged packets, you only need to set "always strip" in the switch port menu if you expect that someone could connect some other device to the port and that device would send packets tagged as "guest", or that the proper connected device could be hacked and start sending tagged packets to get access to other VLANs/subnets
   • you don't need to create another
     Code: Select all

     /interface vlan

     for each physical port you use: as explained above, one per VLAN ID is sufficient and maximum possible
   • you don't need to configure bridge filters for that port because you would only drop eventual received frames with wrong VLAN ID a couple of CPU cycles earlier; if you do want to prevent them from getting in at all, use the switch chip settings to do that as they do it in hardware and the "wrong" packets never reach the CPU. As said, maybe one day in future the vlan filtering will be configured on one place and executed where appropriate, but we're not there yet.