Summary

...

Since RouterOS v6.41 it It is possible to use a bridge to filter out VLANs in your network. To achieve this, you should use the Bridge VLAN Filtering feature. This feature should be used instead of many known VLAN misconfigurations that are most likely causing you either performance issues or connectivity issues, you can read about one of the most popular misconfigurations in the VLAN in a bridge with a physical interface section. The most important part of the bridge VLAN filtering feature is the bridge VLAN table, which specifies which VLANs are allowed on each port, but configuring it might get quite complex if you are trying to make a more advanced setup, for generic setups you should be able to configure your device using the Trunk and Access ports example, but the purpose of this guide is to provide in-depth explanation and point out some of the behavior characteristics when using bridge VLAN Filtering.

...

Before explaining bridge VLAN filtering in-depth, you should understand a few basic concepts that are involved in bridge VLAN filtering.

• Tagged/Untagged - Under /interface bridge vlan menu, you can specify an entry that contains tagged and untagged ports. In general, tagged ports should be your trunk ports and untagged ports should be your access ports. By specifying a tagged port the bridge will always set a VLAN tag for packets that are being sent out through this port (egress). By specifying an untagged port the bridge will always remove the VLAN tag from egress packets.
• VLAN-ids - Under /interface bridge vlan menu, you can specify an entry in which certain VLANs are allowed on specific ports. The VLAN ID is checked on egress ports. If the packet contains a VLAN ID that does not exist in the bridge VLAN table for the egress port, then the packet is dropped before it gets sent out.
• PVID - The Port VLAN ID is used for access ports to tag all ingress traffic with a specific VLAN ID. A dynamic entry is added in the bridge VLAN table for every PVID used, the port is automatically added as an untagged port.
• Ingress filtering - By default, VLANs that don't exist in the bridge VLAN table are dropped before they are sent out (egress), but this property allows you to drop the packets when they are received (ingress).
• Management access - The bridge is supposed to simply forward packets between bridge ports and it would seem to other devices that there is simply a wire between them. With bridge VLAN filtering you can limit which packets are allowed to access the device that has the bridge configured, the most common practice is to allow access to the device only by using a very specific VLAN ID, but there are other ways you can grant access to the device. Management access is a great way to add another layer of security when accessing the device through a bridge port, this type of access is sometimes called the management port. For devices that support VLAN Filtering with hardware offloading, It is also related to the CPU port of a bridge.
• CPU port - Every device with a switch chip has a special purpose port called CPU port and it is used to communicate with the device's CPU. For devices that support VLAN filtering with hardware offloading, this port is the bridge interface itself. This port is mostly used to create management access but can be used for other purposes as well, for example, to route traffic between VLANs, to mark packets, and to apply queues.
• frame-type - You can filter out packets whether they have a VLAN tag or not, this is useful to add an extra layer of security for your bridge ports.
• EtherType - By default, a VLAN aware bridge will filter VLANs by checking the C-TAG (0x8100), all other VLAN tags are considered as untagged packets (without a VLAN tag). The selected EtherType will be used for VLAN filtering and VLAN tagging/untagging.
• VLAN Tunnelling - If the EtherType of the packet does not match with the EtherType configured for the bridge, then ingress packets are considered as untagged packets, this behavior gives a possibility to encapsulate VLANs into another, different VLAN. This also gives a possibility to divert specific traffic through different devices in your network.
• Tag stacking - If a packet has a VLAN tag that matches the EtherType, then the packet is considered as a tagged packet, but you can force another VLAN tag regardless of the packet's content. By setting tag-stacking=yes on a bridge port, you will add another VLAN tag with the PVID value on top of any other tag for all ingress packets.

...

In such a setup you would connect some generic devices like Desktop PCs to ether2 and ether3, these can be considered as workstations and they generally only use untagged traffic (it is possible to force a VLAN tag for all traffic that is sent out a generic workstation, though it is not very common). To isolate some workstations from other workstations you must add a VLAN tag to all packets that enter ether2 or ether3, but to decide what VLAN ID should the packet get is , you need to use a concept called Port-based VLANs. In this concept, packets get a VLAN tag with a VLAN ID based on the bridge port to which the device is connected. For example, in this setup the device on ether2 will get a VLAN tag with VLAN20 and the device on ether3 will get a VLAN tag with VLAN30, this concept is very scalable as long as you have enough bridge ports. This should give you the understanding that traffic between the bridge and devices behind ether2/ether3 is untagged (since there is no VLAN tag, hence the name).

When we have determined our untagged ports, we can now determine our tagged ports. Tagged ports are going to be the trunk ports (the port, that carries multiple VLANs) and usually, this port is connected to a router or another switch/bridge, you can have multiple trunk ports as well. Tagged ports are always carrying packets with a VLAN tag (hence the name) and you must ALWAYS specify the tagged ports for each VLAN ID you want this port to forward. It is possible that a port is a tagged port for one VLAN ID and the same port is an untagged port for a different VLAN ID, but this is for a different type of setup (Hybrid port setup).

Special A special note must be added for the PVID property. This property should be used on access ports, but it can be used for trunk ports as well (in Hybrid port setup). By using the PVID property you are adding a new VLAN tag with a VLAN ID that is specified in the PVID to all UNTAGGED packets that are received on that specific bridge port. The PVID does not have any effect on tagged packets, this means that, for example, if a packet with a VLAN tag of VLAN40 is received on ether2 that has PVID=20, then the VLAN tag is NOT changed and forwarding will depend on the entries from the bridge VLAN table.

...

Do NOT use multiple VLAN IDs on access ports. This will unintentionally allow both VLAN20 and VLAN30 on both access ports. In the example above, ether3 is supposed to set a VLAN tag for all ingress packets to use VLAN30 (since PVID=30), but this does not limit the allowed VLANs on this port when VLANs are being sent out through this port. The bridge VLAN table is responsible for deciding whether a VLAN is allowed to be sent through a specific port or not. The entry above specifies that both VLAN20 and VLAN30 are allowed to be sent out through ether2 and ether3 and on top of that the entry specifies that packets should be sent out without a VLAN tag (packets are sent out as untagged packets). As a result, you may create a packet leak from VLANs to ports that are not even supposed to receive such traffic, see the image below.

Misconfigured A misconfigured VLAN table allows VLAN20 to be sent through ether3, it will also allow VLAN30 through ether2

...

There is a dynamic entry added for VLAN1 since PVID=1 is set by default to all bridge ports (including our trunk port, ether1), but you should also notice that the bridge1 interface (the CPU port) is also added dynamically. You should be aware that bridge1 is also a bridge port and therefore might get added to the bridge VLAN table dynamically. There is a chance that you might unintentionally allow access to the device because of this feature. For example, if you have followed this guide and left PVID=1 set for the trunk port (ether1) and did not change the PVID for the CPU port (bridge1) as well, then access through ether1 to the device using untagged traffic is allowed, this is also visible when you print out the bridge VLAN table. This scenario is illustrated in the image below:

...

There is a simple way to prevent the bridge (CPU port) from being added as an untagged port, you can simply set the PVID on the trunk port to be different than the bridge's PVID (or change the bridge's PVID), but there is another option, which is more intuitive and recommended. Since you are expecting that the trunk port is only supposed to receive tagged traffic (in this example, it should only receive VLAN20/VLAN30), but no untagged traffic, then you can use ingress-filtering along with frame-type to filter out unwanted packets, but in order to fully understand the behavior of ingress filtering, we must first understand the details of management access.

Management access is used to create a way to access a device through a bridge that has VLAN filtering enabled. You could simply allow untagged access and to do so it doing that is fairly simple. Let us say you wanted the workstation behind ether3 to be able to access the device, we assumed before that the workstation is a generic computer that will not use tagged packets and therefore will only send out untagged packets, this means that we should add the CPU port (bridge1) as an untagged interface to the bridge VLAN table, to do so, simply use the same PVID value for the bridge1 and ether3 ports and set both ports as untagged members for the VLAN ID. In this case, you are going to connect from ether3 that has PVID=30, so you change the configuration accordingly:

...

Allowing access to the device using untagged traffic is not considered a good security practice, a much better way is to allow access to the device using a very specific VLAN sometimes called the management VLAN, in our case, this is going to be VLAN99. This adds a significant layer of security since an attacker must guess the VLAN ID that is being used for management purposes and then guess the login credentials, on top of this you can even add another layer of security by allowing access to the device using only certain IP addresses. The purpose of this guide is to provide an in-depth explanation, for that reason, we are adding a level of complexity to our setup to understand some possible caveats that you must take into account. We are going to allow access from an access port using tagged traffic (illustrated in the image below). In order to To allow access to the device using VLAN99 from ether3, we must add a proper entry in the bridge VLAN table. Additionally, a network device connected to ether3 must support VLAN tagging.

...

At this point, we can benefit from using ingress-filtering filtering and frame-type. First, we are going to focus on frame-type, which limits the allowed packet types (tagged, untagged, both), but in order for for frame-type type to work properly, ingress-filtering filtering must be enabled, otherwise it will not have any effect. In our example, where we wanted to allow access from ether3 using tagged traffic (VLAN99) and at the same time allow a generic workstation to access the network, we can conclude that this port needs to allow tagged and untagged packets, but ether1 and ether2 is are supposed to receive only specific types of packets, for this reasons we can enhance our network's security. Since Since ether1 is our trunk port, it is only supposed to carry tagged packets, but ether2 is our access port so it should not carry any tagged packets, based on these conclusions we can drop invalid packets:

...

Let's say that you forgot to enable ingress-filtering and change the frame-type property on ether1, this would unintentionally add access to the device through ether1 using untagged traffic since PVID matches for bridge1 and ether1, but you are expecting only tagged traffic to be able to access the device. It is possible to drop all untagged packets that are destined to for the CPU port:

/interface bridge
set bridge1 frame-types=admit-only-vlan-tagged ingress-filtering=yes

This does not only drop untagged packets, but disables the feature that dynamically adds untagged ports to the bridge VLAN table. If you print out the current bridge VLAN table you would will notice that bridge1 is not dynamically added as an untagged port:

[admin@MikroTik] > /interface bridge vlan print 
Flags: X - disabled, D - dynamic 
 #   BRIDGE       VLAN-IDS  CURRENT-TAGGED        CURRENT-UNTAGGED
 0   bridge1      20        ether1
 1   bridge1      30        ether1                ether3
 2 D bridge1      1                               ether1
 3   bridge1      99        bridge1
                            ether3  

While frame-type can be used to drop a certain type of packet, the ingress-filtering can be used to filter out packets before they can be sent out. To fully understand the need for ingress filtering, consider the following scenario: VLAN99 is allowed on ether3 and bridge1, but you can still send VLAN99 traffic from ether1 to ether3, this is because the bridge VLAN table checks if a port is allowed to carry a certain VLAN only on egress ports. In our case, ether3 is allowed to carry VLAN99 and for this reason, it is forwarded. To prevent this you MUST use ingress-filtering. With ingress filtering, ingress packets are also checked, in our case, the bridge VLAN table does not contain an entry that VLAN99 is allowed on ether1 and therefore will be dropped immediately. Of course, in our scenario without ingress filtering connection cannot be established since VLAN99 can be forwarded only from ether1 to ether3, but not from ether3 to ether1, though there are still possible attacks that can be used in such a misconfiguration (for example, ARP poisoning). The packet dropping behavior is illustrated in the image below:

...

Trunk/access port setup with and without ingress filtering. Ingress filtering can prevent unwanted traffic from being forwarded. Note that ether1 is not allowed to carry VLAN99 in the bridge VLAN table.

The ingress-filtering can be used on the CPU port (bridge) as well, this can be used to prevent some possible attack vectors and limit the allowed VLANs that can access the CPU. It is better to drop a packet on an ingress port, rather than on an egress port, this reduces the CPU load, this which is quite crucial when you are using hardware offloading with bridge VLAN filtering.

...

VLAN Tunnelling setup

...

In some cases, you might want to forward already tagged traffic through certain switches. This is a quite common setup for backbone infrastructures since it provides a possibility to encapsulate traffic from, for example, your edge routers and seamlessly forward it over your backbone to another edge router. Below you can find an example of a VLAN tunneling topology:

Provider bridge topology

SVID stands for Service VID, indicating the tag type along with the VID.

Since RouterOS v6.43 there There are two possible ways to achieve this, one is the standardized IEEE 802.1ad way, and the other way is using Tag stacking, we will first review the standardized way since the same principles apply to both ways and only a couple of parameters must be changed to use the other method. The way VLAN tunneling works is that the bridge checks if the outer VLAN tag is using the same VLAN tag as specified as ether-type. If the VLAN tag matches, the packet is considered as a tagged packet, otherwise, it is considered as an untagged packet.

...

The ether-type property allows you to select the following EtherTypes for the VLAN tag:

• 0x88a8 - SVID, IEEE 802.1ad, Service VLANTag
• 0x8100 - CVID, IEEE 802.1Q, Customer VLAN (regular VLAN tag)
• 0x9100 - Double tagged (not very common)Unofficial tag type (rarely used)

To In order to properly configure bridge VLAN filtering, you must understand how does the bridge distinguish distinguishes between tagged and untagged packets. Like As mentioned before, the bridge will check if EtherType matches with the outer VLAN tag in the packet. For example, consider the following packet:

...

Let us assume that we have set ether-type=0x88a8, in this case, the packet above is going to will be considered untagged since the bridge is looking for a different VLAN tag. Lets now consider the following packet:

...

This time let us assume that we have set ether-type=0x8100, in this case, the packet above is considered as untagged as well since the outer tag is using an IEEE 802.1ad VLAN tag. The same principles apply to other VLAN related functions, for example, the PVID property will add a new VLAN tag on access ports and the VLAN tag will be using the EtherType specified in ether-type.

...

In this example, we are assuming that all routers are passing traffic that is using a CVID VLAN tag (the inner regular/customer VLAN tag). Such traffic on switches will be considered as untagged traffic based on the principle described above. Switches will encapsulate this traffic using an SVID a Service VLAN tag tag (the outer VLAN 802.1ad tag) and traffic between SW1 and SW2 is going to will be considered as tagged. Before traffic reaches its destination, the switches will decapsulate will decapsulate the outer tag and forward the original CVID VLAN 802.1Q tagged frame to routers. See a packet example below:

A packet example before and after SVID 802.1ad VLAN encapsulation 

In case you want to create management access from, let's say, ether3 to the device and wanted want to use VLAN99, then you would use such commands:

...

As you may notice, the only difference is that the VLAN interface is using use-service-tag=yes, this sets the VLAN interface to listen to SVID ( IEEE 802.1ad ) VLAN tags. This will require you to use the IEEE 802.1ad VLAN tag to access the device using the management VLAN . This means that - you will not be able to connect to the device using a CVID regular VLAN tag while using bridge VLAN filtering , theis enabled. The ether-type is set globally and will have an effect on affect all bridge VLAN filtering functions.

Tag Stacking

In the VLAN Tunnelling setup, we were adding a new VLAN tag that was different from the VLAN tag, but it is possible to add a new VLAN tag regardless of the packet contents. The difference between the regular VLAN tunneling setup is that the bridge does not check if the packet is tagged or untagged, it assumes that all packets that are received on a specific port are all untagged packets and will add a new VLAN tag regardless of whether a VLAN tag is present or not, this is called Tag Stacking since it "stacks" VLAN tags on top of the previous tag, regardless of the VLAN tag type. This is a very common setup for networks that do not support the IEEE 802.1ad standard, but still want to encapsulate VLAN traffic into a new VLAN.

The VLAN tag that is going to be added depends on ether-type and PVID. For example, if you have ether-type=0x8100 and PVID=200 on a port, then the bridge will add a new IEEE 802.1Q VLAN tag right on top of any other tag (if such are present). The same VLAN filtering principles still apply, you have to determine which ports are going to be your trunk ports and mark them as a tagged portports, determine your access ports, and add them as untagged ports.

...

What we want to achieve is that regardless of what is being received on ether2 and ether3, a new VLAN tag will be added to encapsulate the traffic that is coming from those ports. What tagTag-stacking does is forces  forces a new VLAN tag, so we can use this property to achieve our desired setup. We are going to be using the same configuration as in the Trunk/Access port setup, but with tag, -stacking enabled on the access ports:

...

...