Contenido

• 1 Resumen
• 2 Fondo
• 3 Configuración del puerto troncal/de acceso
• 4 Configuración de túnel VLAN
o 4.1 Apilamiento de etiquetas

Resumen
Desde RouterOS v6.41 es posible utilizar un puente para filtrar las VLAN en su
red. Para lograr esto, debe utilizar la función de filtrado de VLAN de puente.
Esta función debe usarse en lugar de muchas configuraciones de VLAN
incorrectas conocidas que probablemente le estén causando problemas de
rendimiento o problemas de conectividad, puede leer sobre una de las
configuraciones incorrectas más populares en la VLAN en un puente con una
sección de interfaz física. La parte más importante de la función de filtrado de
VLAN de puente es la tabla de VLAN de puente, que especifica qué VLAN están
permitidas en cada puerto, pero configurarla puede resultar bastante compleja si
está tratando de realizar una configuración más avanzada, para configuraciones
genéricas debería poder configurar su dispositivo usando el ejemplo de puertos
troncales y de acceso, pero el propósito de esta guía es proporcionar una
explicación detallada y señalar algunas de las características de comportamiento
cuando se utiliza el filtrado de VLAN de puente.

Fondo
Antes de explicar en profundidad el filtrado de VLAN de puente, debe
comprender algunos conceptos básicos que están involucrados en el filtrado de
VLAN de puente.

• Etiquetado/Sin etiquetar: en puede especificar una entrada que contenga

y puertos. En general, los puertos etiquetados deben ser los puertos
troncales y los puertos no etiquetados deben ser los puertos de acceso. Al
especificar un puerto etiquetado, el puente siempre establecerá una
etiqueta VLAN para los paquetes que se envían a través de este puerto
(salida). Al especificar un puerto sin etiquetar, el puente siempre eliminará
la etiqueta VLAN de los paquetes de salida./interface bridge
vlantaggeduntagged
• vlan-ids: en puede especificar una entrada en la que se permiten las
VLAN en puertos específicos. El ID de VLAN se verifica en los puertos
de salida. Si el paquete contiene un ID de VLAN que no existe en la tabla
VLAN del puente para el puerto de salida, el paquete se descarta antes de
que se envíe./interface bridge vlan
• PVID: el ID de VLAN de puerto se utiliza para que los puertos de acceso
etiqueten todo el tráfico de entrada con un ID de VLAN específico. Se
agrega una entrada dinámica en la tabla VLAN del puente para cada PVID
utilizado, el puerto se agrega automáticamente como un puerto sin
etiquetar.
• Filtrado de entrada: de forma predeterminada, las VLAN que no existen
en la tabla de VLAN de puente se descartan antes de que se envíen
(salida), pero esta propiedad le permite descartar los paquetes cuando se
reciben (entrada).
• Acceso de administración: se supone que el puente simplemente reenvía
paquetes entre los puertos del puente y a otros dispositivos les parecería
que simplemente hay un cable entre ellos. Con el filtrado de VLAN de
puente, puede limitar qué paquetes pueden acceder al dispositivo que tiene
configurado el puente, la práctica más común es permitir el acceso al
dispositivo solo mediante un ID de VLAN muy específico, pero hay otras
formas de otorgar acceso al dispositivo. El acceso de administración es
una excelente manera de agregar otra capa de seguridad al acceder al
dispositivo a través de un puerto de puente, este tipo de acceso a veces se
denomina puerto de administración y está relacionado con el puerto de
CPU de un puente.
• Puerto de CPU: el puente en sí también es un puerto, que se puede llamar
puerto de CPU, ya que este es el puerto que se utiliza para comunicarse
con la CPU del dispositivo. Cuando se utiliza el filtrado de VLAN de
puente, el puerto de la CPU se utiliza principalmente para crear acceso de
administración. La configuración relacionada con el puerto de la CPU se
encuentra en /interface bridge
• frame-type: puede filtrar los paquetes ya sea que tengan una etiqueta
VLAN o no, esto es útil para agregar una capa adicional de seguridad para
los puertos de su puente.
• EtherType: de forma predeterminada, un puente compatible con VLAN
filtrará las VLAN verificando la etiqueta C (0x8100), todas las demás
etiquetas VLAN se consideran paquetes sin etiquetar (sin una etiqueta
VLAN). El tipo de Ether seleccionado se utilizará para el filtrado de
VLAN y el etiquetado/desetiquetado de VLAN.
• Túnel VLAN: si el EtherType del paquete no coincide con el EtherType
configurado para el puente, los paquetes de entrada se consideran paquetes
 sin etiquetar, este comportamiento brinda la posibilidad de encapsular
VLAN en otra VLAN diferente. Esto también brinda la posibilidad de
desviar tráfico específico a través de diferentes dispositivos en su red.
• Apilamiento de etiquetas: si un paquete tiene una etiqueta VLAN que
coincide con el tipo Ether, el paquete se considera un paquete etiquetado,
pero puede forzar otra etiqueta VLAN independientemente del contenido
del paquete. Al establecer en un puerto de puente, agregará otra etiqueta
VLAN con el valor encima de cualquier otra etiqueta para todos los
paquetes de ingreso.tag-stacking=yesPVID

Configuración del puerto troncal/de acceso

A continuación puede encontrar un diagrama muy común para un tipo de
configuración muy típico que consta de un puerto troncal y varios puertos de
acceso:

Conmutación básica de VLAN

Esta configuración es muy común, ya que brinda la posibilidad de dividir su red

en múltiples segmentos mientras usa un solo conmutador y tal vez un solo
enrutador, tal requisito es muy común para las empresas que desean separar
varios departamentos. Con las VLAN, puede usar diferentes servidores DHCP,
que pueden proporcionar una dirección IP de una subred diferente en función del
ID de VLAN, lo que facilita mucho la creación de reglas de firewall y QoS.
En una configuración de este tipo, conectaría algunos dispositivos muy genéricos
como PC de escritorio a ether2 y ether3, estos pueden considerarse como
estaciones de trabajo y, por lo general, solo usan tráfico sin etiquetar (es posible
forzar una etiqueta VLAN para todo el tráfico que se envía a una estación de
trabajo genérica, aunque no es muy común). Para aislar algunas estaciones de
trabajo de otras estaciones de trabajo, debe agregar una etiqueta VLAN a todos
los paquetes que ingresan a ether2 o ether3, pero para decidir qué ID de VLAN
debe obtener el paquete es usar un concepto llamado VLAN basadas en
puertos. En este concepto, los paquetes obtienen una etiqueta VLAN con un ID
de VLAN basado en el puerto de puente al que está conectado el dispositivo. Por
ejemplo, en esta configuración, el dispositivo en ether2 obtendrá una etiqueta
VLAN con VLAN20 y el dispositivo en ether3 obtendrá una etiqueta VLAN
con VLAN30, este concepto es muy escalable siempre que tenga suficientes
puertos de puente. Esto debería darle la comprensión de que el tráfico entre el
puente y los dispositivos detrás de ether2/ether3 no está etiquetado (ya que no
hay etiqueta VLAN, de ahí el nombre).

Cuando hemos determinado nuestros puertos sin etiquetar, ahora podemos

determinar nuestros puertos etiquetados. Los puertos etiquetados van a ser los
puertos troncales (el puerto que transporta varias VLAN) y, por lo general, este
puerto está conectado a un enrutador u otro conmutador / puente, también puede
tener varios puertos troncales. Los puertos etiquetados siempre transportan
paquetes con una etiqueta VLAN (de ahí el nombre) y SIEMPRE debe
especificar los puertos etiquetados para cada ID de VLAN que desea que reenvíe
este puerto. Es posible que un puerto sea un puerto etiquetado para un ID de
VLAN y el mismo puerto sea un puerto sin etiquetar para un ID de VLAN
diferente, pero esto es para un tipo diferente de configuración (configuración de
puerto híbrido).

Se debe agregar una nota especial para la propiedad. Esta propiedad debe usarse
en los puertos de acceso, pero también se puede usar para los puertos troncales
(en la configuración de puertos híbridos). Al usar la propiedad, está agregando
una nueva etiqueta VLAN con un ID de VLAN que se especifica en todos los
paquetes UNTAGGED que se reciben en ese puerto de puente específico. El no
tiene ningún efecto en los paquetes etiquetados, esto significa que, por ejemplo,
si se recibe un paquete con una etiqueta VLAN de VLAN40 en ether2 que tiene ,
entonces la etiqueta VLAN NO se cambia y el reenvío dependerá de las entradas
de la tabla VLAN del puente. PVIDPVIDPVIDPVIDPVID=20

To configure the trunk/access port setup, you need to first create a bridge:
/interface bridge
add name=bridge1

Warning: Don't enable VLAN filtering yet as you might get locked out from the
device because of the lack of the management access, which is configured at the
end.

Add the bridge ports and specify for each access port: PVID
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2 pvid=20
add bridge=bridge1 interface=ether3 pvid=30

Note: has no effect until VLAN filtering is enabled. PVID

Add appropriate entries in the bridge VLAN table:

/interface bridge vlan
add bridge=bridge1 tagged=ether1 untagged=ether2 vlan-ids=20
add bridge=bridge1 tagged=ether1 untagged=ether3 vlan-ids=30

You might think that you could simplify this entry with a single entry, similar to
this:
/interface bridge vlan
add bridge=bridge1 tagged=ether1 untagged=ether2,ether3 vlan-ids=20,30

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 ), 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 is
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. PVID=30

Misconfigured VLAN table allows VLAN20 to be sent through ether3, it will

also allow VLAN30 through ether2

Warning: Don't use more than one VLAN ID specified in a bridge VLAN table
entry for access ports, you should only specify multiple VLAN IDs for trunk ports.

It is not necessary to add a bridge port as an untagged port, because each bridge
port is added as an untagged port dynamically with a VLAN ID that is specified
in the property. This is because of a feature that automatically will add an
appropriate entry in the bridge VLAN table for convenience and performance
reasons, this feature does have some caveats that you must be aware of. All ports
that have the same will be added to a single entry for the appropriate VLAN ID
as untagged ports, but note that the CPU port also has a VLAN ID. PVIDPVID

For testing purposes we are going to enable VLAN filtering, but note that it
might make you lose access to the device since it does not have a management
access configured yet (we will configure it later). It is always recommended to
configure VLAN filtering while using a serial console, though you can also
configure a device through a port, that is not added to a bridge. Make sure you
are using a serial console or connected through a different port (that is not in a
bridge) and enable VLAN filtering:
/interface bridge set bridge1 vlan-filtering=yes

Note: You might not lose access to the device as soon as you enable VLAN
filtering, but you might get disconnected since the bridge must reset itself in order
for VLAN filtering to take any effect, which will force you to reconnect (this is
mostly relevant when using MAC-telnet). There is a chance you might be able to
access your device using untagged traffic, this scenario is described below.

If you have enabled VLAN filtering now and printed out the current VLAN table,
you would see such a table:
[admin@MikroTik] > /interface bridge vlan print
Flags: X - disabled, D - dynamic
# BRIDGE VLAN-IDS CURRENT-TAGGED CURRENT-
UNTAGGED
0 bridge1 20 ether1 ether2
1 bridge1 30 ether1 ether3
2 D bridge1 1 bridge1
ether1

There is a dynamic entry added for VLAN1 since is set by default to all bridge
ports (including our trunk port, ether1), but you should also notice
that bridge1 interface (the CPU port) is also added dynamically. When ports are
added to a single bridge VLAN table entry, the bridge can skip adding a VLAN
tag and removing it when packets is being forwarded between these ports (since
changing packets is not necessary and decreases the throughput), for this reason
all ports with the same are added as untagged ports dynamically. PVID=1PVID

You should be aware that the CPU port (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 set for the trunk
port (ether1) and did not change the 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: PVID=1PVID
Unintentionally allowed management access using untagged traffic through the
trunk port

Warning: Always check the bridge VLAN table if you have not unintentionally
allowed certain VLANs or untagged traffic to specific ports, especially the CPU
port (bridge).

There is a simple way to prevent the bridge (CPU port) being added as an
untagged port, you can simply set the on the trunk port to be different than the
bridge's (or change the bridge's ), 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 along
with 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. PVIDPVIDPVIDingress-filteringframe-type

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 is fairly simple. Lets 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 specify
the bridge1 and ether3 as untagged ports, but you should set these untagged
ports for the VLAN entry that matches the on the port, from which you will be
connecting. In this case, you are going to connect from ether3 that has , so you
change the untagged ports for VLAN30: PVIDPVID=30
/interface bridge vlan set [find vlan-ids=30] untagged=bridge1,ether3

Note: You can use the feature that dynamically adds untagged ports with the same
value, you can simply change the to match
between ether3 and bridge1. PVIDPVID

Allowing access to the device using untagged traffic is not considered as 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 a certain IP addresses. The
purpose of this guide is to provide 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 allow access
to the device using VLAN99 from ether3, we must add a proper entry in the
bridge VLAN table:
/interface bridge vlan
add bridge=bridge1 tagged=bridge1,ether3 vlan-ids=99
Management access using tagged traffic through an access port (which makes it a
hybrid port)

Note: If for ether1 and bridge1 matches (by default, it does matches with 1), then
access to the device is allowed using untagged traffic from ether1 because of the
feature that dynamically adds untagged ports to the bridge VLAN table. PVID

But you might notice that access using VLAN99 does not work at this point, this
is because you need a VLAN interface that listens for tagged traffic, you can
simply create this interface for the appropriate VLAN ID and you can set an IP
address for the interface as well:
/interface vlan
add interface=bridge1 name=VLAN99 vlan-id=99
/ip address
add address=192.168.99.2/24 interface=VLAN99

Note: Our access port (ether3) at this point expects tagged and untagged traffic at
the same time, such a port is called a hybrid port.
At this point we can benefit from using and . First we are going to focus on ,
which limits the allowed packet types (tagged, untagged, both), but in order for to
work properly, 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 supposed to receive only specific types of
packets, for this reasons we can enhance our network's security. 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: ingress-filteringframe-typeframe-typeframe-
typeingress-filtering
/interface bridge port
set [find where interface=ether1] ingress-filtering=yes frame-
types=admit-only-vlan-tagged
set [find where interface=ether2] ingress-filtering=yes frame-
types=admit-only-untagged-and-priority-tagged

Lets say that you forgot to enable and change the property on ether1, this would
unintentionally add access to the device through ether1 using untagged traffic
since 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 the CPU port: ingress-filteringframe-typePVID
/interface bridge
set bridge1 frame-types=admit-only-vlan-tagged ingress-filtering=yes

This does not only drop untagged packets, but this disables the feature that
dynamically adds untagged ports to the bridge VLAN table. If you print out the
current bridge VLAN table you would 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
 Note: When is used on a port, then the port is not dynamically added as untagged
port for the . frame-type=admit-only-vlan-taggedPVID

While can be used to drop a certain type of packet, the 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 . 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 from ether1->ether3, but not from ether3->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: frame-typeingress-filteringingress-filtering
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.
 Warning: Always try to use wherever it is possible, it adds a significant layer of
security. ingress-filtering

The 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 is quite crucial when you are using hardware
offloading with bridge VLAN filtering. ingress-filtering

Note: The property only has effect on ingress traffic, but has effect on egress and
ingress traffic. ingress-filteringframe-type

Even though you can limit the allowed VLANs and packet types on a port, it is
never a good security practice to allow access to a device through access ports
since an attacker could sniff packets and extract the management VLAN's ID,
you should only allow access to the device from the trunk port (ether1) since
trunk ports usually have better physical security, you should remove the previous
entry and allow access to the device through the port that is connected to your
router (illustrated in the image below):
/interface bridge vlan
add bridge=bridge1 tagged=bridge1,ether1 vlan-ids=99
Basic VLAN switching

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 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 tunnelling topology:

Provider bridge topology

 Note: To fully understand how to configure VLAN tunnelling properly, you
should first read the Trunk/Access port setup section before proceeding any
further.

Since RouterOS v6.43 there are two possible ways to achieve this, one is the
standardised IEEE 802.1ad way, the other way is using Tag stacking, we will
first review the standardised 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 tunnelling works is that the bridge checks if the outer VLAN tag is
using the same VLAN tag as specified as . If the VLAN tag matches, the packet
is considered as a tagged packet, otherwise it is considered as an untagged
packet. ether-type

Note: The bridge checks only the outer tag (closest to the MAC address), any
other tag is ignored anywhere in bridge configuration. The bridge is not aware of
the packet contents, even though there might be another VLAN tag, only the first
VLAN tag is checked.

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

• 0x88a8 - SVID, IEEE 802.1ad, Service VLAN

• 0x8100 - CVID, IEEE 802.1Q, Customer VLAN
• 0x9100 - Double tagged (not very common)

In order to properly configure bridge VLAN filtering, you must understand how
does the bridge distinguish tagged and untagged packets. Like mentioned before,
the bridge will check if EtherType matches with the outer VLAN tag in the
packet. For example, consider the following packet:
FFFFFFFFFFFF 6C3B6B7C413E 8100 6063 9999
----------------------------------------
DST-MAC = FFFFFFFFFFFF
SRC-MAC = 6C3B6B7C413E
Outer EtherType = 8100 (IEEE 802.1Q VLAN tag)
VLAN priority = 6
VLAN ID = 99 (HEX = 63)
Inner EtherType = 9999

Lets assume that we have set , in this case the packet above is going to be
considered as untagged since the bridge is looking for a different VLAN tag. Lets
now consider the following packet: ether-type=0x88a8
FFFFFFFFFFFF 6C3B6B7C413E 88A8 6063 8100 5062 9999
----------------------------------------
DST-MAC = FFFFFFFFFFFF
SRC-MAC = 6C3B6B7C413E
Outer EtherType = 88A8 (IEEE 802.1ad VLAN tag)
VLAN priority = 6
VLAN ID = 99 (HEX = 63)
Inner EtherType 1 = 8100 (IEEE 802.1Q VLAN tag)
VLAN priority = 5
VLAN ID = 98 (HEX = 62)
Innter EtherType 2 = 9999

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

Both SW1 and SW2 are using the same configuration:

/interface bridge
add name=bridge1 vlan-filtering=yes ether-type=0x88a8
/interface bridge port
add interface=ether1 bridge=bridge1 pvid=200
add interface=ether2 bridge=bridge1 pvid=300
add interface=ether3 bridge=bridge1
/interface bridge vlan
add bridge=bridge1 tagged=ether3 untagged=ether1 vlan-ids=200
add bridge=bridge1 tagged=ether3 untagged=ether2 vlan-ids=300

In this example traffic between SW1 and SW2 is going to be tagged and it will
be using the SVID VLAN tag. Here we are assuming that all routers are passing
traffic that is using a CVID VLAN tag and such traffic will be considered as
untagged traffic based on the principle described above.
 Note: All principles that applies to the regular trunk/access port setup using IEEE
802.1Q, they also apply to VLAN tunnelling setups, make sure you are limiting
VLANs and packet type properly using the bridge VLAN table and ingress
filtering.

In case you want to create management access from, lets say, ether3 to the
device and wanted to use VLAN99, then you would use such commands:
/interface bridge vlan
add bridge=bridge1 tagged=bridge1,ether3 vlan-ids=99
/interface vlan
add interface=bridge1 name=VLAN99 use-service-tag=yes vlan-id=99
/ip address
add address=192.168.99.2/24 interface=VLAN99

As you may noticed, the only difference is that the VLAN interface is using , 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 VLAN tag while using bridge VLAN filtering, the is set
globally and will have an effect to all bridge VLAN filtering functions. use-
service-tag=yesether-type

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
tunnelling 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 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 and . For example, if you
have and 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 tagged port, determine your access ports and add them as
untagged ports. ether-typePVIDether-type=0x8100PVID=200

To explain how VLAN tagging and untagging works with tag stacking, lets use
the same network topology as before:

Basic VLAN switching

What we want to achieve is that regardless 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 does is 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: tag-stacking
/interface bridge
add name=bridge1 vlan-filtering=yes ether-type=0x8100
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=ether2 tag-stacking=yes pvid=20
add bridge=bridge1 interface=ether3 tag-stacking=yes pvid=30
/interface bridge vlan
add bridge=bridge1 tagged=ether1 untagged=ether2 vlan-ids=20
add bridge=bridge1 tagged=ether1 untagged=ether3 vlan-ids=30

Note: The added VLAN tag will use the specified . The selected EtherType will
also be used for VLAN filtering. Only the outer tag is checked, but with tag
 stacking the tag checking skipped and assumes that a new tag must be added either
way. ether-type

Lets assume that the devices behind ether2 and ether3 are sending
tagged VLAN40 traffic. With this configuration ALL packets will get
encapsulated with a new VLAN tag, but you must make sure that you have added
the VLAN ID from the outer tag to the bridge VLAN table. The VLAN40 is not
added to the bridge VLAN table since it is the inner tag and it is not checked, we
are only concerned about the outer tag, which is
either VLAN20 or VLAN30 depending on the port.

Similarly to other setups, the bridge VLAN table is going to be used to determine
if the VLAN tag needs to be removed or not. For example, ether1 receives
tagged VLAN20 packets, the bridge checks that ether2 is allowed to
carry VLAN20 so it is about to send it out through ether2, but it also checks the
bridge VLAN table whether the VLAN tag should be removed and
since ether2 is marked as an untagged port, then the bridge will forward these
packets from ether1 to ether2 without the VLAN20 VLAN tag.

From the access port perspective the same principals as in the Trunk/Access port
setup apply. All packets that are received on ether2 will get a new VLAN tag
with the VLAN ID that is specified in , in this case a new VLAN tag will be
added with VLAN20 and this VLAN will be subjected to VLAN filtering. PVID

Retrieved from
"https://wiki.mikrotik.com/index.php?title=Manual:Bridge_VLAN_Table&oldid
=34339"
Categories:

• Bridging and switching

• Case Studies