Hello..
I have googled and found several ways to send both tagged and untagged traffic out the same ethernet port. Some more confusing than others.
Can anyone show me the ultimo 2019 updated way of achieving this ? Here’s the simple scenario.
My router is an RouterBOARD 3011UiAS, current-firmware: 6.45.7
Thank you for the link, but I read in other posts that creating hybrid ports with “/interface ethernet switch vlan” is the old way of doing it and should not be done like that anymore. Is that true ?
WhenMT came out with bridge vlan-filtering, it seemed that the old /interface ethernet switch subtree would be phased out sooner or later … currently it seems to be later … so the old way is still more resource-friendly way of doing it as most of hardware doesn’t HW offload the new way (it’s done entirely in CPU, only CRS3xx series does it in hardware).
Anyway, there’s a nice tutorial about doing it modern way.
Your use case would look like this:
/interface bridge
add bridge=bridge vlan-filtering=yes
/interface bridge port
add bridge=bridge interface=etherX pvid=10 # port towards unifi
add bridge=bridge interface=etherY # trunk port towards core router
/interface bridge vlan
add bridge=bridge tagged=bridge,etherY untagged=etherX vlan-ids=10
add bridge=bridge tagged=bridge,etherX,etherY vlan-ids=20
add bridge=bridge tagged=bridge,etherX,etherY vlan-ids=30
/interface vlan
add interface=bridge name=vlan10 vlan-id=10
You would then use interface vlan10 for communication with management of unifi (bind DHCP server or whatever needed). If RB3011 is actual core router, then you’d create vlan interfaces for VLANs 20 and 30, set IP addresses and let router route between all those vlan interfaces (and internet).
Nice.. Thanks for the quick answer.
So you would recommend the old-school way because of HW offloading ?
Could you make make an example, doing it the old-school way ?
The old school is a nasty beast because exact syntax depends on switch chip model built into RB device. I think RB3011 and RB951G should be similar (my example originates from my working config on a RB951G), only that RB3011 has got two switch chips (consult block diagram) so config will refer to switch2 as well …
Let’s assume hybrid port will be ether2 (etherX in bridge vlan-filtering example) and trunk port will be ether3 (etherY in bridge vlan-filtering example). The config might look something like this:
/interface ethernet switch port
set [ find name=ether2 ] default-vlan-id=10 vlan-mode=secure # ether2 is hybrid
set [ find name=ether3 ] vlan-mode=secure # ether3 is trunk
set [ find name=switch1-cpu ] vlan-mode=secure # switch-to-CPU interconnect
# note that default setting for vlan-header property on ports above is leave-as-is
# if vlan-header=leave-as-is and default-vlan-id is set, switch chip untags frames from
# that vlan on egress. Not true for AR8227 chip, no hybrid ports there
/interface ethernet switch vlan
add independent-learning=yes ports=switch1-cpu,ether2,ether3 switch=switch1 vlan-id=10
add independent-learning=yes ports=switch1-cpu,ether2,ether3 switch=switch1 vlan-id=20
add independent-learning=yes ports=switch1-cpu,ether2,ether3 switch=switch1 vlan-id=30
/interface bridge
add bridge=bridge
/interface bridge port
add bridge=bridge interface=ether2
add bridge=bridge interface=ether3
/interface vlan
add interface=bridge name=vlan10 vlan-id=10
As usual your example makes no sense to me at all!!
Perhaps the idea of sending untagged vlan10 traffic to the UA AP is what I find confusing???
Where is vlan10 ever tagged then??
Why do you have two separate interfaces?
Why do you have one interface going to an imaginary core router? (I want some of your drugs ;-p)
Typically one uses one bridge on one etherport (yes, no)?
There is no OTHER router. There is the RB3011 connecting to the Unifi AP on one etherport2 lets say.
/interface bridge
add bridge=bridge1 vlan-filtering=yes
/interface bridge port
add bridge=bridge interface=etherport2 pvid=10 # port towards unifi (says that ether2 is an access port and thus cannot transport the other two vlans on this etherport.
/interface bridge vlan Solution NOT possible.
/interface vlan
add interface=bridge name=vlan10 vlan-id=10
++++++++++++++++++++++++++++++++++++++
however if the router can assign vlan tags and the UA AP can read them then…
/interface bridge
add bridge=bridge1 vlan-filtering=yes
/interface bridge port
add bridge=bridge interface=etherport2 becomes a trunk port…
/interface bridge vlan
add bridge=bridge tagged=bridge1,ether2 vlan-ids=10,20,30
/interface vlan
add interface=bridge name=vlan10 vlan-id=10
+++++++++++++++++++++++++++++++++++++++++++++++
But are you saying that one needs TWO bridge vlan rules???
/interface bridge vlan
add bridge=bridge tagged=bridge1,ether2 vlan-ids=10,20,30
add bridge=bridge untagged=bridge1,ether2 vlan-id=10
My example config is partly based on OP’s initial description of his problem (from post #1). And partly imaginary (the core router) to illustrate the case where bridge was actually necessary because of multiple ether ports involved in same VLAN(s).
add bridge=bridge interface=etherport2 pvid=10 # port towards unifi (says that ether2 is an access port and thus cannot transport the other two vlans on this etherport.
Seting pvid on port doesn’t necessarily define it as access … this only says port will handle untagged frames on ingress. So it can be hybrid as well (“tagged VLAN membership” is only mentioned in /interface bridge vlan).
Thanks mkx. That clears up a mystery to me. I was under the false impression that setting the pvid on a bridge port definition was only possible on an access port.
Better than going to church and getting my sins excused LOL.
So in the ops case, setting the untagged frames pvid for the management LAN, allows the UA accesspoint to talk to the router on vlan 10 without vlan tags, get assigned DHCP from the vlan10 and then continue communicating. If the UA could tag packets then there would have been no need for pvid setting in bridge port??
Yes exactly. And create SSID’s on different VLAN’s.
UAP’s are able to tag packets.
I like the idea that UAP does not need the management network to be tagged. I can just plug it in any user-vlan port (vlan10) and it can communicate the controller. It does add an extra layer of complexity, IMO Mikrotik’s approach to achieving this is a bit complicated. I did get it working by following Zacharias example, but I am considering to trunk all VLAN’s instead, as it seems a bit simpler considering my modest Mikrotik skills.
