Bridge VLAN Filtering

marktomlinson · Wed Jun 20, 2018 10:30 pm

Hello All

I am looking for a little support with the implementation of bridge vlan-filtering following the advise from MikroTik support that this is way it should now be done.

The configuration is pretty basic in the test network, comprising of a 3011RB and a CRS.

I have managed to get the ports working with assigned PVID, nodes connected to ether2 and ether8 obtain an IP address in 10.46.1.0/24 but unable to get anything on the VLAN at the CRS

3011RB Config

/interface bridge
add fast-forward=no name=bridge vlan-filtering=yes

/interface vlan
add interface=bridge name=vlan5-management vlan-id=5

/interface bridge port
add bridge=bridge hw=no interface=ether2-management pvid=5
add bridge=bridge hw=no interface=ether5-voip
add bridge=bridge hw=no interface=ether1-downstairs
add bridge=bridge interface=ether8-printer pvid=5
add bridge=bridge hw=no interface=ether3-dell
add bridge=bridge hw=no interface=ether7-WiFi
add bridge=bridge hw=no interface=sfp1-switch

/interface bridge vlan
add bridge=bridge tagged=bridge,ether1-downstairs untagged=ether2-management,ether8-printer vlan-ids=5

/ip address
add address=10.46.1.1/24 interface=vlan5-management network=10.46.1.0
add address=172.16.1.10/24 interface=bridge network=172.16.1.0

/ip dhcp-server
add address-pool=dhcp-management authoritative=after-2sec-delay disabled=no interface=vlan5-management lease-time=1w1d \
name=dhcp-management
add address-pool=dhcp-BTnet disabled=no interface=bridge lease-time=1w1d name=dhcp-LAN

CRS

/interface bridge
add admin-mac=CC:2D:E0:2E:04:B5 auto-mac=no fast-forward=no name=LAN vlan-filtering=yes

/interface vlan
add interface=LAN name=vlan5-management vlan-id=5

/interface bridge port
add bridge=LAN hw=no interface=ether1
add bridge=LAN hw=no interface=ether2
add bridge=LAN hw=no interface=ether3
add bridge=LAN hw=no interface=ether4
add bridge=LAN hw=no interface=ether5
add bridge=LAN hw=no interface=ether6
add bridge=LAN hw=no interface=ether7
add bridge=LAN hw=no interface=ether8

/interface bridge vlan
add bridge=LAN tagged=LAN vlan-ids=5

/ip dhcp-client
add dhcp-options=hostname,clientid disabled=no interface=LAN
add add-default-route=no dhcp-options=hostname,clientid disabled=no interface=vlan5-management

Many thanks in advance

Mark

artz · Thu Jun 21, 2018 10:18 am

You are missing a tagged port on the CRS, most probably in your setup it is going to be ether8.
Add ether8 to bridge VLAN table as a tagged port for VLAN5.

Also note that RB3011 is capable of VLAN switching on a hardware level, you can find an example how to set it up here:
https://wiki.mikrotik.com/wiki/Manual:B ... witch_chip

marktomlinson · Thu Jun 21, 2018 11:19 am

Hi Artz

I put the LAN interface (bridge) in the tagged, is that not suitable then?

Mark

artz · Thu Jun 21, 2018 11:23 am

The bridge interface itself (LAN) is needed to allow VLAN5 to communicate with the CPU in order for DHCP to work. A physical port is also needed to allow the specified port to forward VLAN5 packets to the CPU. With your current configuration VLAN5 is allowed to access the CPU, but there is no way VLAN5 is able to reach your device.

marktomlinson · Thu Jun 21, 2018 11:29 am

Hi Artz

Many thanks - i've managed to get that working now, I had assumed that by adding the bridge interface into the tagged section, this would work for all ports within that bridge.

Mark

tippenring · Fri Jun 22, 2018 10:53 pm

Also note that RB3011 is capable of VLAN switching on a hardware level, you can find an example how to set it up here:
https://wiki.mikrotik.com/wiki/Manual:B ... witch_chip

Hello Artz. Could you possibly elaborate on the wiki URL you posted?

/interface ethernet switch vlan
add ports=ether1,ether2 switch=switch1 vlan-id=20
add ports=ether1,ether3 switch=switch1 vlan-id=30
add ports=ether1,switch1-cpu switch=switch1 vlan-id=99

I've spent a few hours trying to figure out what Mikrotik is trying to do with VLANs. I think the switch vlan configuration may be deprecated. I think the VLAN tagging may now happening in the bridge vlan config.

In the URL you posted, the IP address is assigned to the VLAN interface "MGMT." Similarly in https://wiki.mikrotik.com/wiki/Manual:I ... _Bridge.29 the IP addresses are assigned to VLAN interfaces. However, my router (an RB2011 in this particular case) is only reachable if I assign the IP address to a bridge interface.

I'm finding Mikrotik's implementation of VLANs, and possible transition to a new configuration format with poorly updated documentation very difficult to figure out. Perhaps I'm misunderstanding it for some reason.

Thanks!

idlemind · Sun Jun 24, 2018 4:50 am

You are missing a tagged port on the CRS, most probably in your setup it is going to be ether8.
Add ether8 to bridge VLAN table as a tagged port for VLAN5.

Also note that RB3011 is capable of VLAN switching on a hardware level, you can find an example how to set it up here:
https://wiki.mikrotik.com/wiki/Manual:B ... witch_chip

Isn't your advice dated Artz? The go-forward approach is to use the bridge configuration in modern versions of RouterOS. It will manage enabling the hardware underneath.

artz · Mon Jun 25, 2018 10:22 am

The wiki page is not outdated, we try to keep our wiki pages updated, the provided wiki link is fairly new, only 1 month old. You can always check how old is the wiki page by clicking on "View history".

As shown in the wiki link, only CRS3xx is capable of bridge VLAN filtering in conjunction with hardware offloading. Other devices (including RB3011) requires to configure VLAN switching in /interface ethernet switch.
If you are not interested in hardware offloading, then you can use bridge VLAN filtering. Note that as soon as you set "vlan-filtering=yes", then hardware offloading will be disabled automatically on non-CRS3xx devices.

If you have followed the guide and are not able to access the MGMT interface, then it is very likely that you did not set "switch1-cpu" (or "switch2-cpu") vlan-mode to secure.

stormeporm · Tue Jul 10, 2018 6:52 pm

Is there any chance that the bridge vlan filtering with hardware offloading will be expanded to the devices that at this moment are capable of doing it in the switch chip like the crs, rb2011, rb3011?
I was used to doing it in the switch chip then the new bridge thing came along and I to thought that you dont need to do it manually in the switch settings but it turns out you do.
You made the vlan thing more confusing than it was before. Basic switching got easier I will admit.

mkx · Tue Aug 21, 2018 10:05 am

I'm playing with bridge VLANs on hAP ac2 (ROS version 6.42.7). I'm trying to do it in "the new way" only, so I don't want to touch /interface ethernet switch settings ...

It's not clear to me what does setting vlan-filtering=yes on bridge change compared to setting vlan-filtering=no in sense of VLAN functionality of bridge? I've defined VLANs on bridge ports and things seem to work regardless of how I set vlan-filtering. There are a few VLANs that need to pass through CPU (either because of admin access or because of bridging wlan interfaces) and there are VLANs that don't need to pass CPU (RBD52G should act as VLAN capable switch for those).

Setting it to yes means loosing HW offload on all ether ports (which I kind of don't like), but do I need this setting to yes?

xvo · Tue Aug 21, 2018 11:39 am

I'm playing with bridge VLANs on hAP ac2 (ROS version 6.42.7). I'm trying to do it in "the new way" only, so I don't want to touch /interface ethernet switch settings ...

It's not clear to me what does setting vlan-filtering=yes on bridge change compared to setting vlan-filtering=no in sense of VLAN functionality of bridge? I've defined VLANs on bridge ports and things seem to work regardless of how I set vlan-filtering. There are a few VLANs that need to pass through CPU (either because of admin access or because of bridging wlan interfaces) and there are VLANs that don't need to pass CPU (RBD52G should act as VLAN capable switch for those).

Setting it to yes means loosing HW offload on all ether ports (which I kind of don't like), but do I need this setting to yes?

With vlan-filtering=no all other settings regarding vlans on bridge are ignored, bridge won't tag/untag incoming packets, everything will pass as is.
So if everything seems to work fine it's either a coincidence... or a new bug for 6.42.7

hAP ac2's switch chip doesn't support hw offloading with vlan filtering configured, so disappearing HW flag is the expected behaviour.

sindy · Tue Aug 21, 2018 11:50 am

do I need this setting to yes?

You do because it makes the tagging/untagging on access (hybrid) ports possible. Without vlan-filtering=yes, the /interface bridge port pvid and /interface bridge vlan tagged/untagged values can not be used because the switch chip does not even send the frames to the CPU. Some chips can do equivalent handling using the /interface ethernet switch port and /interface ethernet switch vlan setting, but some cannot. And the point which isn't obvious is that although we are used to talk about switch chips, the functionality is actually provided by a functional block of the SOC (system-on-a-chip), not by a standalone switch chip, so the capabilities of this switch block are not the only criteria for hardware designer's choice of the SOC.

Other than that, it also allows to overcome the different hardware limitations of different switch chips. E.g. the BPDU frames are normally (except Cisco's PVST/PVST+ and the old Mikrotik's RSTP implementation) not tagged with any VID, which the simpler switch chips cannot fulfil simply because they cannot distinguish BPDUs from other frames. The software bridge can do this, so the "real" MSTP can be implemented.

mkx · Tue Aug 21, 2018 2:17 pm

Thanks @xvo and @sindy.

I guess it seemed to me that everything just work is due to the fact @sindy outlined: use of hybrid ports. I haven't tested that use case yet, I was about to do it today. Yesterday I only used trunk ports and explicit vlan interface built on top of bridge (I'm not going to use bridge device directly with its pvid setting, I like the more explicit way of doing it with vlan devices. Plus one can only deal with one VLAN in the bridge pvid way and I need to deal with 3). I have a couple of ports set up as hybrid and I'm using pvid on those ports to tag untagged packets (so the bridge won't ever see untagged packet). I guess that would bite me today without vlan-filtering set to yes.

In my simple setup I don't need any STP protocol active, so I guess this reason for having vlan-filtering enabled is not valid for me. Tagging/untagging on hybrid ports definitely is my use case.

I'll just have to check CPU load when doing some intra VLAN port to port transfer to see if this device sweats or not due to lack of HW offload.
And I certainly hope Mikrotik devs will improve VLAN handling in future releases. Block diagram for RBD52G shows AR8327 as switch chip being part of IPQ4018 SoC (I highly doubt that it's actually AR8327) and AR8327 is also used in RB951G. If I configure switch chip on RB951G, device is quite capable of dealing with hybrid ports (tagging/untagging) ... so I guess this is functionality that yet needs to be offloaded on devices capable of doing it.

mkx · Tue Aug 21, 2018 2:23 pm

Without vlan-filtering=yes, the ..... /interface bridge vlan tagged/untagged values can not be used because the switch chip does not even send the frames to the CPU.

Is this the whole truth? Indeed I tried to replicate switch chip setup by including bridge to be tagged part of most of VLANs and that seemed to do the trick. There is one VLAN that is intended to completely bypass RB's CPU and bridge is not configured to carry that VLAN. I guess it could happen (without vlan-filtering set) that packets from that VLAN would not pass from one ether port to another. I'll have to test myself

sindy · Tue Aug 21, 2018 4:11 pm

Without vlan-filtering=yes, the ..... /interface bridge vlan tagged/untagged values can not be used because the switch chip does not even send the frames to the CPU.
Is this the whole truth?

It is

The bypass of the CPU is the essence of "hardware acceleration" of a bridge. So the frames are forwarded by the switch chip itself directly from one of its ports to another one using the switch chip's own MAC address table. Whether you can or cannot use hybrid ports in this case depends on the switch chip features; with 8327 you can, with 8227 you cannot.

I certainly hope Mikrotik devs will improve VLAN handling in future releases.

That returns us back to the various functionalities of the switch chips and the amount of effort which has to be spent on each of them.

E.g. to deal with MSTP while preserving hardware acceleration, on 8327 it should be sufficient to add the following "dynamic" switch chip rule if MSTP would be configured on the bridge:
/interface ethernet switch rule add dst-mac-address=01:80:c2:00:00:f00/ff:ff:ff:ff:ff:ff redirect-to-cpu=yes switch=switch1 ports=ether1,ether2,ether3,ether4,ether5
and let the CPU strip off the VLAN tag likely added by the switch chip before processing the BPDU.
The equivalents of /interface bridge port and /interface bridge vlan items would also have to be added as dynamic items to /interface ethernet switch port and /interface ethernet switch vlan respectively; even more complex, the /interface ethernet switch vlan settings would have to be dynamically modified, disabling and enabling individual ports in individual VLANs according to the current state of the spanning tree.

But whether it is the direction in which Mikrotik's R&D is currently digging is, well, a question for Mikrotik R&D

mkx · Wed Aug 22, 2018 8:52 am

I've checked the /interface ethernet switch sections on my hAP ac2 when VLANs are configured on bridge. /interface ethernet switch export produces empty script, which is expected as nothing was set-up there. /interface ethernet switch port print detail produces this output:

Flags: I - invalid 
 0   name="ether1" switch=switch1 vlan-mode=disabled vlan-header=leave-as-is 
     default-vlan-id=auto 

 1   name="ether2" switch=switch1 vlan-mode=disabled vlan-header=leave-as-is 
     default-vlan-id=auto 

 2   name="ether3" switch=switch1 vlan-mode=disabled vlan-header=leave-as-is 
     default-vlan-id=auto 

 3   name="ether4" switch=switch1 vlan-mode=disabled vlan-header=leave-as-is 
     default-vlan-id=auto 

 4   name="ether5" switch=switch1 vlan-mode=disabled vlan-header=leave-as-is 
     default-vlan-id=auto 

 5   name="switch1-cpu" switch=switch1 vlan-mode=disabled 
     vlan-header=leave-as-is default-vlan-id=auto

And /interface ethernet switch vlan print detail produces empty result. So yes, switch is configured so that it does essentially nothing.

Now to my current problem: I've configured VLANs on bridge and things seem to work as desired, including trunk ports, hybrid ports (one VLAN tagged, one untagged) and access ports (one untagged VLAN). However I'm having problems with wlan ... WiFi clients connect (as: successfully authenticate using WPA2 pre-shared key), but obviously don't communicate on L2 (e.g. they can't obtain DHCP lease).

My configuration:

/interface bridge
add admin-mac=B8:69:F4:20:A5:4A auto-mac=no comment=defconf name=bridge \
    protocol-mode=none vlan-filtering=yes
/interface bridge port
add bridge=bridge comment=defconf interface=ether2 pvid=40
add bridge=bridge comment=defconf interface=ether3 pvid=42
add bridge=bridge comment=defconf interface=ether4 pvid=42
add bridge=bridge comment=defconf interface=ether5 pvid=42
add bridge=bridge comment=defconf interface=wlan1 pvid=42
add bridge=bridge comment=defconf interface=wlan2 pvid=42
add bridge=bridge frame-types=admit-only-vlan-tagged ingress-filtering=yes \
    interface=ether1
/interface bridge vlan
add bridge=bridge tagged=bridge,ether1 untagged=ether3,ether4,ether5 \
    vlan-ids=42
add bridge=bridge tagged=bridge,ether1 vlan-ids=2
add bridge=bridge tagged=ether1,ether2 vlan-ids=3999
add bridge=bridge tagged=bridge,ether1 vlan-ids=41
add bridge=bridge tagged=bridge,ether1 untagged=ether2 vlan-ids=40
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-g/n channel-width=20/40mhz-Ce \
    country=slovenia disabled=no distance=indoors frequency=auto \
    frequency-mode=regulatory-domain mode=ap-bridge security-profile=mkxNet \
    ssid=mkxNet-2G vlan-id=42 vlan-mode=use-tag wireless-protocol=802.11 \
    wps-mode=disabled
set [ find default-name=wlan2 ] band=5ghz-n/ac channel-width=20/40/80mhz-Ceee \
    country=slovenia disabled=no distance=indoors frequency=auto \
    frequency-mode=regulatory-domain mode=ap-bridge security-profile=mkxNet \
    ssid=mkxNet-5G vlan-id=42 vlan-mode=use-tag wireless-protocol=802.11 \
    wps-mode=disabled

It seems like something is rotten with regard to dealing with VLAN tags. What am I doing wrong?

mkx · Wed Aug 22, 2018 9:11 am

I'll just have to check CPU load when doing some intra VLAN port to port transfer to see if this device sweats or not due to lack of HW offload.

While verifying my VLAN setup (it's not right yet, see my previous post) I also did some throughput tests. I used iperf UDP tests, Windows laptop as client and linux back in "LAN core" as server. Linux is on Gbps ethernet while laptop was connected either via Gbps ethernet or WiFi. The results are somehow interesting:

Windows jperf could not push more than around 120Mbps in single UDP stream (linux can do almost Gbps) so when testing wired connection, I had to use 12 parallel UDP streams to get cumulative throughput near Gbps.
just the opposite was with WiFi connection (with RB951G as AP): if I used more than 3 parallel UDP streams, DL was severely limited by RB's CPU going to 100%. If I used single or twin UDP streams, CPU stayed below 100% and I got some decent DL throughput (but still lower than UL) ... During UL tests CPU usage stayed below 50% and throughput was not limited.
when doing tests via RB951G, configured to deal with VLANs in switch chip, obviously CPU stayed idle. When doing tests via RBD52G, configured with VLANs on bridge, CPU usage increased, but stayed relatively low nevertheless. When pushing 12 UDP streams in DL, cumulative CPU usage raised to around 10% (of single core), while when doing test in UL, CPU usage raised to around 20% (of single core). As RBD52G has 4 CPU cores and CPU load was distributed between all cores, this means RBD52G in "switch" mode should be able to do wire-speed transfers on all ports full duplex.
But: yes, RBD52G does sweat during high speed tests when HW offload is not available.

When WiFi starts to work on RBD52G, I'll do throughput tests as well and will post more results (with comparison to RB951G).

mkx · Wed Aug 22, 2018 9:50 am

What am I doing wrong?

Hummm, I noticed that wlan1 and wlan2 interfaces are not mentioned nowhere in /interface bridge vlan setup. I've added them

/interface bridge vlan
add bridge=bridge tagged=bridge,ether1,wlan1,wlan2 untagged=\
    ether3,ether4,ether5 vlan-ids=42

Will test if this made some change in the evening when I'll be back at home.

sindy · Wed Aug 22, 2018 10:16 am

Will test if this made some change

It did

If I remember correctly, the wireless interfaces recently started to be added automaticaly to the vlan-ids rows in /interface bridge vlan if the wireless interfaces are controlled using CAPsMAN.

mkx · Wed Aug 22, 2018 9:05 pm

Will test if this made some change
It did

It did indeed

Next I'll do some configuration tidying up, some tests to see CPU load when doing full speed data transfer over WiFi and then I'll be all set to forget about switch chip I paid for

dma24hs · Thu Nov 01, 2018 7:48 pm

I have a problem communicating between vlan on the same bridge

CCR1016 - V6.42.9
/interface vlan
add interface=ether3 name=vlan100 vlan-id=100
add interface=ether3 name=vlan200 vlan-id=200
/interface bridge
add name=Bridge_1
/interface bridge port
add bridge=Bridge_1 interface="vlan100"
add bridge=Bridge_1 interface="vlan200"
/ip address
add address=192.168.110.1/24 interface=Bridge_1 network=192.168.110.0

RB750(1) - V6.42.9
/interface bridge
add name=Bridge
/interface bridge port
add bridge=Bridge interface="ether1"
add bridge=Bridge interface="ether2"
add bridge=Bridge interface="ether3"

RB750(2) - V6.42.9
/interface vlan
add interface=ether1 name=vlan100 vlan-id=100
/ip address
add address=192.168.110.2/24 interface=vlan100 network=192.168.110.0

RB750(3) - V6.42.9
/interface vlan
add interface=ether1 name=vlan101 vlan-id=101
/ip address
add address=192.168.110.3/24 interface=vlan101 network=192.168.110.0

- RB750 (2) and RB750 (3) I can ping 192.168.110.1 ok
- RB750 (2) not ping 192.168.110.2
- RB750 (3) not ping 192.168.110.3
- With versions prior to 6.42.9 I get communication between vlan's on the same bridge

Jotne · Thu Nov 01, 2018 9:11 pm

Make a new post and upload image to site (use Attachments below). I do not see it.

mkx · Thu Nov 01, 2018 9:25 pm

I wonder if that RB750(1), configured as dummy switch, is not spoiling the party? I'd try to configure VLANs properly on it (all ports being trunk ports with appropriate VLANs admitted). Being a dummy switch, seeing frames with correct MAC addresses but not considering VLAN tags it might use shortcut and send frames from RB750(2) received via ether2 directly to RB750(3) via ether3 ... but without affecting the VLAN tag.

All of the above wile considering VLAN id mismatch on CCR and RB750(3) (200 v.s. 101) to be a typo.

Bridge VLAN Filtering

Bridge VLAN Filtering

Re: Bridge VLAN Filtering

Re: Bridge VLAN Filtering

Re: Bridge VLAN Filtering

Re: Bridge VLAN Filtering

Re: Bridge VLAN Filtering

Re: Bridge VLAN Filtering

Re: Bridge VLAN Filtering

Re: Bridge VLAN Filtering

Re: Bridge VLAN Filtering

Re: Bridge VLAN Filtering

Re: Bridge VLAN Filtering

Re: Bridge VLAN Filtering

Re: Bridge VLAN Filtering

Re: Bridge VLAN Filtering

Re: Bridge VLAN Filtering

Re: Bridge VLAN Filtering

Re: Bridge VLAN Filtering

Re: Bridge VLAN Filtering

Re: Bridge VLAN Filtering

Re: Bridge VLAN Filtering

Re: Bridge VLAN Filtering

Re: Bridge VLAN Filtering