I’d like to set up an AP in a vlan (vlan 55)with my hapac2. The diag like below.
I read about the wiki re how to set up vlan with the switch chip in RB device. But I’m little confused that how I can set up the dhcp for the vlan. Shall I create a bridge including the trunk port(eth1) and a logic port vlan55 set Pvid =55? So I can make a dhcp range to listen the request on it?
following are the final conf, i removed some parts.
hapac2.rsc (5.46 KB)
My advice is to go with vlan-filtering approach on hAP ac2 … with its powerful CPU it us capable of wire-speed bridging without much sweat. OTOH I’ve been experiencing instabilities (lock-ups) on my hAP ac2 when VLANs were configured on switch-chip …
thanks for the info. Yet I still want to know how to get it work by switch chip vlan as I can learn the knowledge.
Basically you’re right: make ether1 (with all it’s VLANs configured on switch chip) member of bridge. Then create /interface vlan add name=vlan55 interface=bridge vlan-id=55. All of relevant L2 and L3 stuff goes to interface=vlan55 (that includes IP address, DHCP server, …).
Also adjust firewall rules, by default they reference interface lists … LAN is used as internal network and if your vlan55 will be trusted, you can /interface list member add list=LAN interface=vlan55.
thank you, MKX, I will take your suggestion using the bridge vlan but not switch chip.
This is what I did on my HAPAC2 VLAN config using switch chip (not bridge). As I understand it, if I use vlans using bridge, I believe it disables hardware offloading to the switch chip, and therefore may reduce performance. I would like to use the HAPAC2 only as a switch therefore I set the vlan on the switch chip. Experts correct me if I am wrong.
/interface bridge
add name=bridge1 protocol-mode=none
/interface bridge port
add bridge=bridge1 interface=ether1 hw=yes
add bridge=bridge1 interface=ether2 hw=yes
add bridge=bridge1 interface=ether3 hw=yes
add bridge=bridge1 interface=ether4 hw=yes
add bridge=bridge1 interface=ether5 hw=yes
/interface ethernet
set [ find default-name=ether1 ] comment=“UPLINK (TRUNK)” (note: from previous HAPAC2, trunk = default vl1 (untagged) and all vlans (tagged) active on trunk)
set [ find default-name=ether2 ] comment=“DOWNLINK (TRUNK)” (note: to next HAPAC2, trunk)
set [ find default-name=ether3 ] comment=“HOTSPOT (TRUNK)” (note: to Wifi AP)
set [ find default-name=ether4 ] comment=“OFFICE VL10”
set [ find default-name=ether5 ] comment=“CCTV VL35”
/interface vlan
add interface=bridge1 name=“VL03 - Network Device” vlan-id=3 (note: I put all my network devices on vl3. If I don’t add this, the HAPAC2 won’t get its ip from the dhcp server on vl3. If your device is on the default vlan, you don’t need this.)
/ip dhcp-client
add dhcp-options=hostname,clientid disabled=no interface=“VL03 - Network Device” (note: related to above)
/interface ethernet switch vlan
add ports=ether1,ether2,ether3,switch1-cpu switch=switch1 vlan-id=1
add ports=ether1,ether2,ether3,switch1-cpu switch=switch1 vlan-id=3
add ports=ether1,ether2,ether3 switch=switch1 vlan-id=5
add ports=ether1,ether2,ether3,ether4 switch=switch1 vlan-id=10
add ports=ether1,ether2,ether3 switch=switch1 vlan-id=15
add ports=ether1,ether2,ether3 switch=switch1 vlan-id=20
add ports=ether1,ether2,ether3 switch=switch1 vlan-id=25
add ports=ether1,ether2,ether3 switch=switch1 vlan-id=30
add ports=ether1,ether2,ether3,ether5 switch=switch1 vlan-id=35
/interface ethernet switch port
set ether1 vlan-mode=fallback vlan-header=leave-as-is (note: trunk)
set ether2 vlan-mode=fallback vlan-header=leave-as-is (note: trunk)
set ether3 vlan-mode=fallback vlan-header=leave-as-is (note: trunk)
set ether4 vlan-mode=secure vlan-header=always-strip default-vlan-id=10 (note: access port vl10)
set ether5 vlan-mode=secure vlan-header=always-strip default-vlan-id=35 (note: access port vl35)
set switch1-cpu vlan-header=leave-as-is vlan-mode=fallback default-vlan-id=0 (note: I am not 100% sure I have this right. I had the switch-cpu on vl3 with vlan-header=secure, which is the vlan I want the HAPAC2 to be in, but I can’t access the HAPAC2 with that setting.)
thank you, @ashpri. After reading the post in wiki(https://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features) and forum(http://forum.mikrotik.com/t/using-routeros-to-vlan-your-network/126489/1). I found hapac2 switch chip could have some issue as it ignore the vlan-header.(Note: Atheros8327 switch chips ignore the vlan-header property and uses the default-vlan-id property to determine which ports are access ports. For Atheros8327 switch chips the vlan-header is set to leave-as-is and cannot be changed while the default-vlan-id property should only be used on access ports to tag all ingress traffic. ) And mkx mentioned it’s an old way, and I also use ac2 as a router. So finally, I use the modern way and it works well.
For completeness sake: all ports configured in /interface ethernet switch port should have setting vlan-mode=secure … which will actually enforce VLAN filtering on ingress. Without this setting (set to, e.g. fallback) any VLAN tag is accepted on ingress (including untagged on ports where only tagged is expected) and poses security risk.
And the above comment includes switch1-cpu pseudo-interface. BTW, default setting for default-vlan-id is auto.
And … I won’t comment on use of vlan-id=1 because I promised as much in another topic. 
@mkx
If it’s an “old way”, how come that the docs advise that Switch VLAN should be preferred over Bridge VLAN filtering for non-CRS devices?
Note: Currently only CRS3xx series devices are capable of using bridge VLAN filtering and hardware offloading at the same time, other devices will not be able to use the benefits of a built-in switch chip when bridge VLAN filtering is enabled. Other devices should be configured according to the method described in the Basic VLAN switching guide. If an improper configuration method is used, your device can cause throughput issues in your network.
I also have a built-in Atheros8327.
The reason I am moving from my multi-bridge setup to a single bridge + switch vlan is the above note and this article, which says that HW offloading can only be done for one bridge (with a device that has one switch chip):
https://wiki.mikrotik.com/wiki/Manual:Layer2_misconfiguration#Bridges_on_a_single_switch_chip
This is part of what I’d like to achieve:
TRUNK (VLAN 101,102,103)
+--------------------------------------+
| |
|ether2 |port1
ether1+-----------+ +----------+
+---------------+ mikrotik | | switch |
WAN(PPPoE) +-----------+ +----------+
|ether3 (access port VLAN 102)
|
|
+
In a Switch-Router configuration, should one just ignore the intra-VLAN forwarding (and isolation) benefits of the Switch VLAN and despite not being HW offloaded, just use VLAN-aware bridges?
The quoted text says nothing about preferred way … it’s a note about potentially lower performance due to lack of HW offload. On the other hand, in the “old way” exact VLAN config depended on type of switch chip used in RB. Now it’s the same SW implementation in all devices making Mikrotik appeal (by having same set of functionality and config methods the same over all their devices) even stronger.
The linked article has nothing to do with VLANs, it’s about bridges and HW offload in general. If VLANs are properly configured on switch chip, and everything is under single bridge … which then acts as dumb switch as opposed to “managed switch” if vlan-filtering is enabled. The only problem (which is not real anymore, but used to be before other interfaces, such as wlan, became vlan-aware) is that you have to properly deal with VLANs on other peripheral devices instead on bridge.
Whichever way (the old or the new) properly done will assure you proper VLAN separation. The only difference is the performance and one can estimate performance when not using HW offload from “Test Results” subpage of product specification … by looking at Bridging performance … My favourite spot is cross-section between “Bridging - 25 bridge filter rules” and “512 byte”. If the figure suffices then go for SW VLANs. If not, then go for HW VLANs.
My personal view is that SW VLANs are (slightly) easier to configure and don’t have any bugs (not that I know of). HW VLANs are (slightly) harder to configure and have a few bugs - but those depend on particular HW type, there are a few bugs on RBD52G and none on RB951G (as the former is fast, I’m running SW VLANs on that … the later is too slow and I’m running HW VLANs on it).
The quoted text says nothing about preferred way.
Well, that’s true, it is just sufficiently confusing for a novice, or like me, who configures a device only once in every few months whether to go with SW VLAN. 
The “L2 misconfigurations” only shed light on my misconceptions that I previously thought I needed multiple bridges for my setup.
Thanks for the hint on evaluating potential performance!
As I understand, this configuration already gets me where I want to be
# feb/19/2019 16:30:45 by RouterOS 6.43.11
# software id = VTC1-4D2N
#
# model = 951G-2HnD
/interface ethernet switch vlan
add independent-learning=yes ports=ether2,ether3,switch1-cpu switch=switch1 vlan-id=102
add independent-learning=yes ports=ether2,switch1-cpu switch=switch1 vlan-id=101
add independent-learning=yes ports=ether2,switch1-cpu switch=switch1 vlan-id=103
/interface ethernet switch port
set 0 default-vlan-id=auto vlan-header=leave-as-is vlan-mode=disabled
set 1 default-vlan-id=auto vlan-header=leave-as-is vlan-mode=secure
set 2 default-vlan-id=102 vlan-header=always-strip vlan-mode=secure
set 3 default-vlan-id=auto vlan-header=leave-as-is vlan-mode=disabled
set 4 default-vlan-id=auto vlan-header=leave-as-is vlan-mode=disabled
set 5 default-vlan-id=auto vlan-header=leave-as-is vlan-mode=secure
I don’t know how to make the CLI print interface names, but
0-4
is ether1-5 and
5
is switch1-cpu.
Even though the docs say that on Atheros8327, “vlan-header” is ignored I set it to “always-strip” for consistency and to hint on that it’s an access port.
Now my assumption is that to prevent inter-VLAN routing I will have to define the VLAN interfaces over a bridge with “vlan-filtering=off” put ether2-5 in that bridge and then use FW rules like
in:VLAN103
out:VLAN102
action:drop
… or similar. What is unclear to me is that if a tagged L2 broadcast frame, say from 103 enters this “dumb” bridge over the trunk (ether2), what will be the bridging decision? Will the VLAN103 interface defined over the bridge somehow magically handle it, or would the bridge, being unaware of VLAN tags flood the tagged frame on all its member interfaces + virtual interfaces and that’s how VLAN103 eventually sees it?
Seems like it …
Something like this. Just in routeros-ish language
Bridge won’t care about VLAN tags at all. It’ll just forward frames to ports according to dst MAC address (which in this case is broadcast), just like dumb ethernet switch does. Which includes the VLAN103 interface. And VLAN102 and all the rest of VLAN interfaces. Every port will apply their own VLAN filter, so any port which is member of that VLAN will transmit it (either tagged or untagged according to its settings), while other ports will ignore it. VLAN interfaces have implicit filter which only allows frames tagged with appropriate VID on one side and untagged frames on the other side, so VLAN103 inteface will pass it while other VLAN interfaces will ignore it.
Thanks, not all is lost then!
Bridge won’t care about VLAN tags at all. It’ll just forward frames to ports according to dst MAC address (which in this case is broadcast), just like dumb ethernet switch does.
If I put ether4 in the bridge with the following settings:
/interface bridge port
add auto-isolate=no bpdu-guard=no bridge=bridge1 broadcast-flood=yes disabled=no edge=auto fast-leave=no frame-types=admit-all horizon=none hw=yes ingress-filtering=no interface=ether4 internal-path-cost=10 learn=auto multicast-router=temporary-query \
path-cost=10 point-to-point=auto priority=0x80 pvid=1 restricted-role=no restricted-tcn=no tag-stacking=no trusted=no unknown-multicast-flood=yes unknown-unicast-flood=yes
/interface ethernet switch port
set 3 default-vlan-id=auto vlan-header=leave-as-is vlan-mode=disabled
# rest of the switch config is the same as in my earlier post
# I noticed switch ports also have parameters in Webfig corresponding to egress/ingress rate, limit-broadcast, limit-unknown-{uni, multi}cast, but these are not printed in CLI nor mentioned in the docs
So we established that the bridge is “dumb”. ether4 is member of the bridge, but in the Switch it is configured to ignore VLAN tags.
Am I wrong to expect that those VLAN103 L2 broadcasts from the trunk should appear on ether4 as well? Because it does not seem to be the case. I can’t see them in the Port Sniffer, I can’t see them coming into the interface connected to ether4 either. I can see them on bridge1 in the Port Sniffer though, so they get to the CPU.
According to documentation, setting vlan-mode affects ingress behaviour. Egress behaviour is slightly more complex, so check it with manual. I don’t understand all the options every time I look at them, you might have better luck with it
…you might have better luck with it.
Thanks. Been there many times, I felt my brain melting every time.
I may not have interpreted ingress/egress correctly though.
So how I see the flow now:
So my conclusion is that the “vlan-mode=disabled” is not in play here.
Instead, the “vlan-mode=secure” mode of switch1-cpu (or ether2 in case the frame coming from the bridge does not change what the original ingress port was) and ether4 not being in VLAN table results in the packet being dropped on egress, which sounds good but I may be wrong.
Thanks for patiently escorting me in my journey @mkx
I think that actual steps are fewer when bridge is a dummy kind of switch:
Other than that, I trust your head spun less than mine when constructing item #5. (4. in the list above) and that the outcome in the last line is correct.
Anyway, my personal view is that device admin deserves peace in mind and thus should not play games with half baked VLAN solutions. Either do it properly (which has vlan-mode=secure) or not at all. All the rest makes head spinning … even more so of some colleague/manager looking at admin’s solution without having background of thoroughly thinking the whole lot.
Anyway, my personal view is that device admin deserves peace in mind and thus should not play games with half baked VLAN solutions. Either do it properly (which has vlan-mode=secure) or not at all. All the rest makes head spinning … even more so of some colleague/manager looking at admin’s solution without having background of thoroughly thinking the whole lot.
Agree with that, I’m doing this after having had a working (but maybe not optimal) VLAN setup for over 2 years.
Strangely, my experiment contradicts that ingress is ether2 in this case.
After changing “vlan-mode=secure” to “vlan-mode=disabled” on switch1-cpu, this were my Switch Port and Switch VLAN tables:
/interface ethernet switch port
set 0 default-vlan-id=auto vlan-header=leave-as-is vlan-mode=disabled #ether1
set 1 default-vlan-id=auto vlan-header=leave-as-is vlan-mode=secure #ether2
set 2 default-vlan-id=102 vlan-header=always-strip vlan-mode=secure #ether3
set 3 default-vlan-id=auto vlan-header=leave-as-is vlan-mode=disabled #ether4
set 4 default-vlan-id=auto vlan-header=leave-as-is vlan-mode=disabled #ether5
set 5 default-vlan-id=auto vlan-header=leave-as-is vlan-mode=disabled #switch1-cpu
/interface ethernet switch vlan
add disabled=no independent-learning=yes ports=ether2,ether3,switch1-cpu switch=switch1 vlan-id=102
add disabled=no independent-learning=yes ports=ether2,switch1-cpu switch=switch1 vlan-id=101
add disabled=no independent-learning=yes ports=ether2,switch1-cpu switch=switch1 vlan-id=103.
I started receiving the L2 broadcasts sent from VLAN102 (connected on ether3) on ether4, which, if we follow the rule table should not be possible if ingress is ether3.
I also see them in the Packet Sniffer on bridge1 which means they must have hit the CPU, right?
And (!) as a side effect, my internet connection stops working on devices connected to these VLANs on the “vlan-mode=secure” ports which also seems to back up the theory that ingress is switch1-cpu when that decision happens.
I though that the architecture of a RB device with a switch chip is so that the physical interfaces on the switch chip are connected to the CPU exclusively via switch1-cpu, so anything coming from the CPU (e.g. frames from a SW-defined bridge) has to come into the switch via switch1-cpu. I drew this conclusion from this image in the “L2 misconfigurations article”:
Is this a wrong understanding?
The “dumb” bridge composed of ether{2,3,4} and VLAN{101,102,103} is HW offloaded and bridges have the following overall settings.
/interface bridge settings
set use-ip-firewall=yes use-ip-firewall-for-vlan=yes
What do you think?
You have to be careful when thinking about VLAN interfaes which you create using /interface vlan add interface=bridge name=VLANxx vlan-id=xx … whatever traffic, which involves those interfaces, will always pass CPU and switch1-cpu interface. So port 5 (switch1-cpu) has to be appropriately configured. When talking about broadcasts … they should hit all interfaces and if broadcast originates from VLANxx interface, it will appear as originating from switch1-cpu interface for VLAN logic of the switch.
There are some essential differences in how individual switch chips implement different VLAN-related options … some are documented (such as that AR8327 ignores vlan-header setting for egress) and some might not be.
If you run packet sniffer, then I suspect all MAC filters everywhere will be disabled to make sure your sniffer gets the frames.
Again, I strongly suggest you to revamp whole VLAN config on your RB … it’ll take some time but at the end you’ll save yourself perhaps even more time (as opposed to trying to make current setup fly) and you’ll definitely save yourself some headaches …
Again, I strongly suggest you to revamp whole VLAN config on your RB
Yes, that’s what I’m doing, I just want to make sure that this time I fully understand the configuration.
Can’t share the previous config, for I have not exported it, but its gist was that:
Then I came across the Switch-Router manual https://wiki.mikrotik.com/wiki/Manual:Switch_Router#VLAN_switching which avoids VLAN-aware bridges, instead it does port switching on the switch chip, and deals with routing,internet,+dhcp, etc. using “dumb” bridges. I understand that I can setup so intra-VLAN traffic will never hit the CPU (assuming no wlan interfaces participate), and VLAN separation can happen partly on the switch chip, partly with FW rules.
What was confusing is that there was still too many ways to achieve the same thing, WebFig not being 100% helpful about what will and will not work on the specific device.
All the above are just experiments to get a grip on how things really work in MTROS. Thanks again for all the expert insight!
I reviewed RouterSwitchAP.rsc from the other thread as well, which is a great resource, but uses VLAN-aware bridges and for the RB951-2HnD, as you said so earlier too, this hybrid switch VLAN + dumb bridge config is better.
Just a final suggestion: avoid using VLAN VID=1 … different vendors treat it slightly differently … ROS, when using switch-chip setup, treats VID=1 as untagged when it comes to “dumb” bridge. Better use explicit VLANs and use VIDs between 2 and 3999. I’ve heard rumours that some devices, again different vendors, don’t support VIDs between 4000 and 4096 (both inclusive) due to some strange reason.
Even if you want to have a pair (or three) ports on your RB951G that should interconnect untagged parts of same LAN, have those ports as access ports of VLAN with a well defined VID. If you have some VLAN, it doesn’t mean it has to exit from your device via some trunk port.