I'm trying to setup a router with this config:

* ether1 goes to ISP
* ether2, ether2 and ether4 are part of a bridge
* there are two vlans vlan20 and vlan30
* ether2 should be untagged access port on vlan20
* ether3 should be untagged access port on vlan30
* ether4 should be tagged trunk port for vlan20 and vlan30

I have also added a wlan with a separated "rescue" bridge. It can rescue me if I lock out myself from the router.

I was trying to follow the https://wiki.mikrotik.com/wiki/Manual:B ... witch_chip guide.
I just added some dhcp servers.
This is only a test, so I can post the whole config, unaltered. The actual production router will be a HAP AC2, but this one is a HAP Lite.
The problem with this config is that it does not work. When I plug an ethernet cable into ether2 or ether3, I don't get an IP address with DHCP. Actually, I'm not able to connect to the router with winbox, because it does not show the device in "neighbours". The LED on the port is lit, there is physical connection. But otherwise it is completely dead.

What did I do wrong?

Set pvid on ether2 and ether3
Doesn't help either.

You have configured both methods, i.e. bridge vlan as well as switch vlan.

Should just be one or the other, and in neither did you configure access to the Bridge / Switch CPU interface

HINT: From URL you quoted:

add ports=ether1,switch1-cpu switch=switch1 vlan-id=99

I want to operate dhcp servers for these vlans. I need a single interface for that. So I guess I must use the bridge vlan method, and not the switch vlan method?

You can use any method, but you have to give access to the Bridge / Switch CPU interface on that device in order to access resources, i.e. DHCP, Management, etc on it

Either method will work. Using a VLAN-aware bridge is the simplest, you really only need to use the switch chip if you expect a lot of traffic between ethernet ports in the same VLAN as any routed traffic (between VLANs or between VLAN and internet) has to pass through the CPU in any case.

Example using a VLAN-aware bridge https://wiki.mikrotik.com/wiki/Manual:I ... _Filtering (parts of 11.1, 11.2, 11.3 & 11.4 cover your use), or using the switch chip https://wiki.mikrotik.com/wiki/Manual:Switch_Router

Thanks for your help. I decided to use bridge vlan filtering. Dropped all switch-chip vlan config.

I read most of "bridge vlan tables" wiki. I understand why I can't manage the device through ether2 and ether3 untagged ports. (They belong to vlan20 and vlan30, and the bridge has pvid=1).

I also realized that I have to add vlan20 and vlan30 interfaces to the bridge as untagged ports. Otherwise there will be no connection between the dhcp server (listening on the vlan20/vlan30 interface) and the ethernet ports.

Problem: I still can't get an IP address with dhcp on ether2 or ether3. Something is still missing...

The bridge has two sides to it, on is bridging interfaces, other is a interface itself which provides access to the CPU for accessing resources on device itself like DHCP, management of the device itself, etc.

So like I mentioned earlier, to achieve above, you need to provide access to this in vlan table.

add bridge=bridge tagged=ether4,bridge untagged=ether2,vlan20 vlan-ids=20

I have added the bridge/bridge port to the vlan table, as you suggested. The dhcp server now works!

After adding the bridge cpu port as a tagged port, the vlan table looks like this:
There is a dynamic entry added for pvid=1, untagged port=bridge. If I'm not mistaken, that is because /interface bridge has pvid=1, and vlan-filtering=yes.

So I think I'm beginning to grasp this.

Now I know how to create vlans with bridge filtering, but I have doubts about what is happening exactly.

If you have time, please read these and correct me if I'm wrong.

1. **port** is a layer 2 concept. Anything that has a MAC address is an ethernet port. Phyisical interfaces: ether2, ether3 and ether4 are ports. The bridge itself is a port (it has a MAC address). The virtual interfaces vlan20 and vlan30 are also ports.
2. When I add a port to a bridge (/interface bridge port add) then the bridge's internal port is connected to the port of the interface. The term "port" is somewhat distorted in routeros. A real layer 2 ethernet port is called an interface (with a mac address) in RouterOs. What RouterOS calls the "port of a bridge" is in fact a connection between the bridge's internal port, and the interface's port.
3. Inside a single routeros instance, one interface can only be connected to one bridge at most. All virtual interfaces connected to the same bridge share the same MAC address with the bridge. (I guess it is more efficient that way?) It includes tunnel, vlan and wlan interfaces etc. Physical ethernet interfaces always have their own unique mac addresses, even when they are connected to the same bridge.
4. When vlan-filtering is disabled on the bridge, then /interface bridge vlan table is not used, and any packet can leave on any port. (Or maybe it is used for tagging/untagging packets? But not for filtering.)
5. When vlan-filtering is enabled on the bridge, then /interface bridge vlan table is used to control which packet can leave on which port, based on the vlan id of the packets. When we say that a package "can leave the bridge on interfaceX", we actually mean that the packet can be copied to the port of the interfaceX interface, making it an egress port for the packet. The source MAC address of the copied packet is modified to match the MAC address of the interfaceX interface in this process.

The bridge is always implemented in software. (In contrast, switch is usually implemented in hardware.) Bridge based vlan filtering is also implemented in software - it requires the packet to be copied from the switch chip to the CPU, where it is processed. (This processing includes not just the vlan based filtering, but also execution of IP firewall rules, when it is enabled for the bridge.) The copying of the packet into the CPU is represented by the packet "leaving on the bridge CPU port".

My misunderstanding came from an apparently wrong assumption about packet processing in bridges. I had this mental construct:

1. packet enters the bridge
2. CPU processes the packet
3. packet leaves the bridge

Now I believe this is happening instead:

1. the packet **enters** the bridge on an interface that is added as a port to the bridge
2. the packet **leaves** on the bridge CPU port
3. the CPU processes the packet
4. the packet **enters** on the bridge CPU port
5. the packet **leaves** the bridge on one or mode interfaces that are added as ports to the bridge

It seemed counter-intuitive to me first, because **the packet leaves before it enters**. But I guess it just depends on how you look at it: it enters the CPU when it leaves the bridge and vice versa. We just don't say that "it enters the CPU" when we are talking about bridging, because packets can only enter and leave on ports, and "port" is a layer 2 networking concept. So we are not looking at it from the CPU's point of view.

I hope I have the correct concepts and a good view about how it works, but I'm going to write down an example, just to check that.

1. dhcp server2 sends a packet (for example, DHCPOFFER)
2. the packet **enters** the port of the vlan20 interface. It ges assigned vlan-id=20, because vlan20 interface has pvid=20.
3. the packet **enters** the bridge at same time as a tagged packet, because vlan20 is added to the bridge, and the bridge's internal port is added to the bridge as a tagged port.
4. then the packet **leaves** the bridge on the CPU bridge port. This requires that the bridge CPU port is present as an untagged port in the bridge vlan table for vlan-ids=20
5. the CPU processes the packet. If ip firewall is turned on for the bridge, then firewall rules are excuted. They may change or block the packet. The vlan id of the packet is not changed.
6. the packet **enters** the bridge on the CPU bridge port again, as a tagged packet with vlan-id=20
7. if there is an entry for the destination MAC address of the packet in the bridge's host table, then it is used to determine the outgoing interface for the packet. Otherwise flooding occurs, and the bridge will use all possible ports to send out the packet. For any possible egress port, the vlan table is checked again. In any case, ports that are not listed in the vlan table for the vlan id (=20) of the packet are excluded.
8. the packet is copied to the selected port(s) and **leaves** the bridge again

Some things that I I'm not sure about:

* I'm not sure if the packet actually re-enters the bridge on the CPU port. If it does, then is it subject to ingress filtering? I suspect that packets coming from the CPU are not subject to ingress filtering on the bridge.
* I'm not sure if vlan-filtering happens in the CPU before it enters the bridge on the cpu port, or after that. Or maybe packages do not enter on the CPU port, but they are directly created in the bridge, by the CPU?
* I did not try yet, but I guess I need to enable ip firewall on the brige to separate vlans from each other? Or maybe, if the source and the destination IP addresses are on different subnets, then layer 3 routing happens? So If I choose different subnets for different vlans, then maybe I don't need to turn on ip filtering on the bridge?

And finally, I wonder what would be the point of adding the bridge's internal CPU port to the bridge as an untagged port?

E.g. instead of this:
I can also do this:
But it makes no point to me, because internally all packets are "tagged" (they always have a vlan-id), and the CPU always sees that. It must mean something (because it is allowed by RouterOS).

> But it makes no point to me, because internally all packets are "tagged" (they always have a vlan-id), and the CPU always sees that. It must mean something (because it is allowed by RouterOS).

Apparently, there is no difference between adding the bridge CPU port as tagged vs. untagged port. Interesting.

1. **port** is a layer 2 concept. Anything that has a MAC address is an ethernet port. Phyisical interfaces: ether2, ether3 and ether4 are ports. The bridge itself is a port (it has a MAC address). The virtual interfaces vlan20 and vlan30 are also ports.

Bridge itself is not a port. Bridge has two personalities: 1) something like a switch, spanning member ports, and 2) interface which allows ROS interact with L2 subnet bridged by perdonality #1. So the bridge interface is an implicit bridge port.
This distinction helps to understand that VLAN interfaces are not bridge ports, they are kind of add-ons ... on bridge interface (much like they are add-ons when anchored to physical ethernet interface if those are not bridge ports). VLAN interfaces are kind of pipes with two ends: tagged which anchors to an underlying interface (interface=bridge vlan-id=XX) and untagged (name=vlanXX)which is available for further use (most often it's used for L3 setup). This pipe passes frames tagged with correct VLAN ID from tagged end to untagged end, stripping the header on the way. And passes frames from untagged end towards the tagged end adding appropriate VLAN header on the way.

2. When I add a port to a bridge (/interface bridge port add) then the bridge's internal port is connected to the port of the interface. The term "port" is somewhat distorted in routeros.

Bridge by definition transparrently spans ports and as such doesn't need any MAC address. In typical ethernet switch individual ports don't have MAC addresses. Interface OTOH is used to terminate connection and thus needs MAC address. In ROS world, every ethernet port can be used individually an if used so, it becomes interface (and its own MAC address becomes important).

4. When vlan-filtering is disabled on the bridge, then /interface bridge vlan table is not used, and any packet can leave on any port. (Or maybe it is used for tagging/untagging packets? But not for filtering.)

Property vlan-filtering is slightly ill-named ... if it's not set, bridge becomes like a dumb-switch and entirely ignores VLAN tags.

5. ... The source MAC address of the copied packet is modified to match the MAC address of the interfaceX interface in this process.

Not true. MAC address is not modified. If packet originates from router's higher layers, then source MAC address will be set to MAC address of originating interface (bridge interface's if ports are bridfe or physical interface's if not bridged). If packet originates from elsewhere and bridge only "switches" it between member ports, then source MAC address will remain.

The bridge is always implemented in software. (In contrast, switch is usually implemented in hardware.) Bridge based vlan filtering is also implemented in software - it requires the packet to be copied from the switch chip to the CPU, where it is processed.

Mostly true, but some devices (CRS3xx) can offload some functions to underlying hardware (such as VLAN filtering).

My misunderstanding came from an apparently wrong assumption about packet processing in bridges. I had this mental construct:

1. packet enters the bridge
2. CPU processes the packet
3. packet leaves the bridge

This is correct (apart from possibke offloading). Conceptually there is no bridge-CPU port as whole bridge is run by CPU. The closest to switchX-cpu port of a switch chip is the (implicitly created) bridge interface.


The packet flow is rather as follows:

1. DHCP server srnds an untagged packet to its L3 interface
2. the packet enters VLAN interface which adds VLAN header (tags it) and sets source MAC address
3. tagged frame gets injected in the bridge interface which is bridge port and injects the frame in vlan-aware bridge
4. optionally CPU executes bridge filters or IP firewall. This is different than packet egressing bridge to CPU port because L3 functions, such as firewall, doesn't have some information, such as out-interface, it doesn't exist for bridged traffic (and out-port is not determined yet), for L3 of router it would be either bridge or some vlan interface anyway
5. bridge (CPU executing bridge implementation) examines its ARP caches and selects egress port (one or many)
6. egress port checks if frame can pass and (if configured so) strips VLAN header (if port is access port for that particular VLAN), passing frame to underlying hardware (let's say it's an ethernet port but any other type of ports behaves similarly)