Hello,
I’m a newbie who don’t understand how to implement VLAN on mikrotik’s products.
Router : HEX POE
Ap : CAP AC
Switch : CISCO 2960
This is what I want to make :
Cisco is ready but I’m not able to setup hex end cap.
Can you help me pls ?
Thx you
Ok as i see from your Network topology HEX will be the router…
Here is a nice article http://forum.mikrotik.com/t/using-routeros-to-vlan-your-network/126489/1 that talks about VLANs and how you can configure them.
The first example Router - Switch is enough so that you understand what you can do, it is totally simple…
However, HEX POE does not support Bridge Hardware offload allong with VLANs, only CRS3xx series do, so am not sure if it would be best to follow the VLAN switching for devices with built in switch chip https://wiki.mikrotik.com/wiki/Manual:Basic_VLAN_switching#Other_devices_with_built-in_switch_chip instead of the Bridge VLAN Filtering as described in the above article…
Given that OP’s got a decent switch (the Cisco), I’d recomend to use hEX only as a router … i.e. connect the wifi AP to Cisco instead to hEX. And in this scenario HW offload doesn’t play any role as all traffic is routed and hence handled by CPU anyway.
I would not use vlan1, use a different number…
I’d recomend to use hEX only as a router
If you had to create a trunk port between Cisco and Mikrotik, as the initial plan of the OP, would you go with Bridge VLAN Filtering or Switch VLAN filtering ?
With routing-only tasks it doesn’t really matter … the dilemma is only real when there are multiple ether ports members of same VLAN and there are devices within same VLAN communicating with each other over those ether ports.
Given the above explanation I’d skip the bridge altogether and configure /interface vlan interfaces directly on trunk ether interface. Yes, that’s burning bridges behind 
Given the above explanation I’d skip the bridge altogether and configure /interface vlan interfaces directly on trunk ether interface. Yes, that’s burning bridges behind >
What is the point of just creating a VLAN interface in /interface vlan without using either Bridge or Switch filtering ?
If there are VLANs 100, 200 and 300 in the trunk and router has to route between them, router needs IP addresses in all of them. IP addresses are bound to vlan interfaces.
Now, if a single ether interface is in the game, do we need intermediate layer of a bridge? I don’t think so, it is perfectly fine to create /interface vlan add interface=ether2 vlan-ids=100 name=vlan100.
And switch chip setup is not needed as well, it’ll forward traffic between that single ether port in use and CPU. As to the port security: if there’s no other ports in game and one only creates (and uses) few select vlan interfaces, then frames tagged with other VIDs or untagged frames will be discarded by ROS kernel driver.
ok @mkx got it… am just used in creating trunks with bridge filtering etc…
But what you suggest makes sense, creating vlan interfaces on ether2 for every VID100,200,300…and thats it…
then frames tagged with other VIDs or untagged frames will be discarded by ROS kernel driver.
However, since there is no ingress filtering, how would those frames be discarded?
For example on a Trunk Port with Bridge VLAN Filtering enabled i would set on my trunk ports, ingress filtering enabled, admit only VLAN tagged…
So what blocks an untagged frame ?
ok, thx all.
My first working config :
/interface bridge
add name=BR1 protocol-mode=none vlan-filtering=yes
/interface vlan
add interface=BR1 name=BASE_VLAN vlan-id=666
add interface=BR1 name=guest_VLAN vlan-id=200
add interface=BR1 name=iSCSI_VLAN vlan-id=7
add interface=BR1 name=nicapigi_VLAN vlan-id=100
/interface list
add name=WAN
add name=VLAN
add name=BASE
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=BASE_POOL ranges=172.16.1.10-172.16.1.50
/ip dhcp-server
add address-pool=BASE_POOL disabled=no interface=BASE_VLAN lease-time=4h \
name=BASE_DHCP
/interface bridge port
add bridge=BR1 frame-types=admit-only-vlan-tagged ingress-filtering=yes \
interface=ether2
add bridge=BR1 frame-types=admit-only-vlan-tagged ingress-filtering=yes \
interface=ether3
add bridge=BR1 frame-types=admit-only-vlan-tagged ingress-filtering=yes \
interface=ether4
add bridge=BR1 frame-types=admit-only-vlan-tagged ingress-filtering=yes \
interface=ether5
add bridge=BR1 frame-types=admit-only-vlan-tagged ingress-filtering=yes \
interface=sfp1
/ip neighbor discovery-settings
set discover-interface-list=BASE
/interface bridge vlan
add bridge=BR1 tagged=BR1,ether2,ether3,ether4,ether5,sfp1 vlan-ids=666
add bridge=BR1 tagged=BR1,ether2,ether3,ether4,ether5,sfp1 vlan-ids=7
add bridge=BR1 tagged=BR1,ether2,ether3,ether4,ether5,sfp1 vlan-ids=100
add bridge=BR1 tagged=BR1,ether2,ether3,ether4,ether5,sfp1 vlan-ids=200
/interface list member
add interface=ether1 list=WAN
add interface=BASE_VLAN list=VLAN
add interface=iSCSI_VLAN list=VLAN
add interface=nicapigi_VLAN list=VLAN
add interface=guest_VLAN list=VLAN
add interface=BASE_VLAN list=BASE
/ip address
add address=172.16.1.254/24 interface=BASE_VLAN network=172.16.1.0
add address=192.168.1.253/24 interface=ether1 network=192.168.1.0
add address=172.16.7.254/24 interface=iSCSI_VLAN network=172.16.7.0
add address=172.16.100.254/24 interface=nicapigi_VLAN network=172.16.100.0
add address=172.16.200.254/24 interface=guest_VLAN network=172.16.200.0
/ip dhcp-server network
add address=172.16.1.0/24 dns-server=172.16.1.254 gateway=172.16.1.254
/ip dns
set allow-remote-requests=yes servers=192.168.1.254
/ip firewall filter
add action=accept chain=input comment="Allow Estab & Related" \
connection-state=established,related
add action=accept chain=input comment="Allow VLAN" in-interface-list=VLAN
add action=accept chain=input comment="Allow Base_Vlan Full Access" \
in-interface=BASE_VLAN
add action=drop chain=input comment=Drop
add action=accept chain=forward comment="Allow Estab & Related" \
connection-state=established,related
add action=accept chain=forward comment="VLAN Internet Access only" \
connection-state=new in-interface-list=VLAN out-interface-list=WAN
add action=drop chain=forward comment=Drop
/ip firewall nat
add action=masquerade chain=srcnat comment="Default masquerade" \
out-interface-list=WAN
/ip route
add distance=1 gateway=192.168.1.254
/system clock
set time-zone-name=Europe/Paris
/system identity
set name=rt-mikrotik-01
/tool mac-server
set allowed-interface-list=BASE
/tool mac-server mac-winbox
set allowed-interface-list=BASE
VLAN1 is now VLAN666
VLAN2 is now VLAN7
Problems :
from vlan666, I can’t “ping” other VLAN (firewall rules not good ?)
If I plug cap ac into cisco, CAPvMAN will work ?
I want ether2 to be access port, is it possible ?
Thx a lot in advance for your help !
(1) /ip pool (missing rest of pools)
add name=BASE_POOL ranges=172.16.1.10-172.16.1.50
(2) /ip dhcp-server (missing rest of dhcp-servers)
add address-pool=BASE_POOL disabled=no interface=BASE_VLAN lease-time=4h
name=BASE_DHCP
(3a) If you want to make ether 2 an access port (aka connected to a non vlan aware device such as a PC).
/interface bridge port
add bridge=BR1 frame-types=admit-only-untagged and priority tagged
interface=ether2 pvid=(whatever vlan its supposed to be on)
(3b) /interface bridge vlan
add bridge=BR1 tagged=BR1,ether3,ether4,ether5,sfp1 untagged=ether2 vlan-ids=(whatever vlan ether2 is an access port on)
(4) /ip dhcp-server network (missing the rest of the networks)
add address=172.16.1.0/24 dns-server=172.16.1.254 gateway=172.16.1.254
(5) The first rule includes the second rule so the second one is redundant.
/ip firewall filter
add action=accept chain=input comment=“Allow VLAN” in-interface-list=VLAN
add action=accept chain=input comment=“Allow Base_Vlan Full Access”
in-interface=BASE_VLAN
However, for better security one should only allow the admin full access to the router itself and for everybody else, just the services they require with the most common being DNS and yes this includes other users (not the admin) on the base vlan.
So I would change the two rules and for example provide 3…
/ip firewall filter
add action=accept chain=input comment=“Allow Admin” in-interface-list=BASE_VLAN src-address-list=adminaccess
add action=accept chain=input comment=“Allow VLAN DNS queries-UDP”
dst-port=53 in-interface-list=VLAN protocol=udp
add action=accept chain=input comment=“Allow VLAN DNS queries - TCP”
dst-port=53 in-interface-list=VLAN protocol=tcp
where
/ip firewall address-list
add address=192.xxxx list=adminaccess comment=“admin desktop”
add address=192.xxxy list=adminaccess comment=“admin laptop”
add address=192.xxxz list=adminaccess comment=“admin smartphone”
(6) Finally, it absolutely makes sense for your base vlan not to be able to ping other vlans. The VLANs themselves create layer 2 blocking AND due to your last rule in the forward chain ‘drop all else’ ( an excellent rule to have), you have only permitted vlan to wan traffic in the forward chain!
If you want the base vlan to be able to access the other vlans then make the necessary firewall rule.
Do you want this for all base vlan users or just yourself??
/ip firewall filter (all base vlan users)
add action=accept chain=forward comment=“Allow Base VLAN to VLANS” in-interface-list=BASE_VLAN
out-interface-list=VLAN
/ip firewall filter (just the admin)
add action=accept chain=forward comment=“Allow Admin” to all VLANS" in-interface-list=BASE_VLAN
out-interface-list=VLAN src-address-list=adminaccess
Because there’s no “user” for frames with other VIDs … vlan interface explicitly filters when frame passes from tagged side to untagged.
Mind that if one has bridge with multiple ports attached, individual ports don’t filter frames, it’s up to bridge to make sure VLANs don’t leak.
For example on a Trunk Port with Bridge VLAN Filtering enabled i would set on my trunk ports, ingress filtering enabled, admit only VLAN tagged…
So what blocks an untagged frame ?
Nothing really blocks untagged frame. However, the vlan interfaces will block it from passing those interfaces. When interface lacks L3 config, there’s no upper layer “user” for those frames (ditto for tagged frames with wrong VID) and interface driver (either in software or using HW filters) will discard such frames.
It is different when interface gets enslaved to bridge, in this case interface is put into promiscous mode and it’s up to bridge to rake care about frames - either deliver them to another member interface (can be bridge interface as well) or discard them due to bridge filter rules, e.g. vlan-filtering.
Because there’s no “user” for frames with other VIDs … vlan interface explicitly filters when frame passes from tagged side to untagged.
Ok, got it.. Do you have any reference for this for a more in depth look? Wiki does not mention anything on that…
Mind that if one has bridge with multiple ports attached, individual ports don’t filter frames, it’s up to bridge to make sure VLANs don’t leak.
Sure, but in case of Bridge VLAN Filtering, we do enable ingress filtering on the port… So filtering is on the bridge but the port will block the e.g. untagged frame and another port on the same bridge can be configured to allow it… So am i missing something or ?
Also, the difference if i enable ingress filtering on the Bridge itself and not on the port ?
Edit: Bridge ingress filtering, filters what comes from the CPU…
Bridge Port ingress filtering, filters what comes from the physical port…
No, I don’t have any referece on that. It’s based on 25 years (I’m not kidding) of experience with linux networking.
There are quite a few layers of frame/packet processing. Lowest one is performed either by NIC hardware or driver and involves matching of dst MAC address. Frames which don’t pass are discarded at this time (discards are mostly frames flooded by switch to all ports because switch did not know any better). Frames passing the criteria are then passed to kernel network layer which then optionally performs VLAN checks and untagging (this is function of vlan interface in ROS), decapsulates L3 packet out of L2 frame and passes packet to appropriate L3 stack (nowadays it’s usually IP or IPv6 stack) which then performs further checks on L3 dst address (e.g. dst IP address). And packet continues further up the OSI 7 layers if necessary (when packet needs to be routed somewhere else, L3 checks are the last … and I’m not going into firewall packet flows right now). Each and every layer has its own checks which can drop the packet.
The above description is a fairly general one, there are a few schemes to cut the corners in order to boost performance (MT’s own fastpath and fast-track are fine examples). But the description should explain why no explicit ingress filtering on non-bridged ports is just fine … because certain frames / packets won’t pass the checks.
When multiple L2 interfaces are bridged, they are configured into “promiscous” mode, meaning that L2 checks are not performed by individual NICs or drivers. Instead another L2 entity (bridge) passes frames between member interfaces and may (not necessarily, but most often) implement some logic. Without any logic it’s a network hub, with some logic it’s a switch, with some more logic it’s a “smart switch”. As bridge is an L2 entity and interfaces’ own checks are disabled, none of linux kernel’s checks apply, hence need for special checks implemented by bridge (e.g. ingress and egress filters, etc.).
Mind that implicit bridge interface is a linux kernel feature as well and being L2 interface it does implement all the kernel machinery … but only for frames directed towards kernel’s higher layers, not for inter-interface traffic.
There are two cases[*] and so far we’re talking about bridge with vlan-filtering enabled. In this case, unless it’s about CRS3xx, it’ll be the bridge on CPU which is filtering and switch chip (HW entity running the ether port) will not do any filtering what so ever. Yes, it’s true, bridge does filter with regard to ingress and egress port config, but it’s bridge as software entity doing it none the less.
[*] The second case is when one configures VLANs on switch chip either manually through /interface ethernet switch or if it’s on CRS3xx and ROS does it automatically. In this case HW will do the filtering. But this case is not so relevant to our discussion.
However, I guess we steered quite away from OP’s problems, why don’t we get back to helping him solve his problems?
ok @mkx thanks… i edited my previous post as for the difference of ingress on bridge itself and the bridge port…
And for CAPvMAN ?
is it possible to plug on cisco ?
Capsman will run only on a RouterOS device… The APs can be connected to Cisco and provisioned on the Mikrotik…
Yes, CAP MAN is on RouterOS, I know.
Thx a lot !
Also being new to this forum a question to jmnicolas or anav
I also have a new hEX S (RB760iGS) and a Cisco SF350 switch connected and would like to configure these correctly to allow the various Vlans on the network
I already have a working environment but it’s not complete or working as I would like it.
Could you share the complet config you have with me to get things started