I did some testing, and yes, as you said, in the bridge ports the “H” disappears which indicates that Hardware-Offload has been disabled, but I noticed it does not say in the logs that it has been deactivated, so I am wondering if it is only cosmetics and the hardware-offload is actually still active?
It’s not only cosmetics. The hardware-offload really is not happening. The only devices it works on with VLAN filtering are the CRS-3xx series. As you have a 2011, you need to do the VLAN filtering on the switch chip, as you already did in #15.
@netflow, you have shaken my confidence so much that I have checked that right now.
- eth1 of a voyage box with tagged vlan 33 on it is connected to ether3 of one RB952Ui-5ac2nD, ether5 of that Mikrotik is connected to ether5 of another 952Ui-5ac2nD.
- On the “Mikrotik in the middle”, both ether3 and ether5 are member ports of the only bridge, with hardware acceleration. VLAN 33 is not mentioned anywhere in this Mikrotik’s configuration. vlan-filtering at bridge is set to no, interface ethernet vlan is empty, no interface vlan vlan-id=33 exists.
- On the “Mikrotik at the end”, interface vlan vlan-id=33 uses the only bridge as its bearer interface.
- two IP addresses from the same subnet, 192.168.33.0/24, are attached to interfaces in vlan 33 at the voyage box and at the “Mikrotik at the end”
The two addresses, 192.168.33.1 and 192.168.33.2, can ping each other. Other interconnections between the boxes exist, so in order to double-check that the ping cannot get through some other way (which is actually not possible even theoretically but just to be bullet-proof), I’ve disabled the membership of ether5 on the “Mikrotik in the middle” in the bridge - yes, once I’ve disabled it, the ping has stopped getting through.
Did you just say that you have a “trunk” where the tagged vlan ID is not known on the “machine in the middle”, but it’s still getting across anyway like It was attached to a regular switch?
I suppose intuitively this should be happening but if you’re configuring trunks all day it wouldn’t be obvious if you come from Cisco or something similar where the tag has to exist on the interface for it to pass.
I’m paranoid these days so I turn on packet sniffer on interfaces quite often, open it in Wireshark, then peel back the stuff that I know should be there until I find the stuff that shouldn’t be there. It’s surprising if you haven’t done it or haven’t done it in a while.
Yes, exactly.
I suppose intuitively this should be happening but if you’re configuring trunks all day it wouldn’t be obvious if you come from Cisco or something similar where the tag has to exist on the interface for it to pass.
As I wrote in #10, that’s just a matter of setting and of defaults. Try “switchport trunk allowed vlan all” (or “switchport trunk allowed vlan except …”) on Cisco, you’ll get exactly the behaviour like here, everything gets through transparently.
Or take a “stupid” switch with no management - it will also do exactly this because it only looks at the frames’ destination and source MAC addresses. Which is, until you tell it to behave otherwise, what the switch chip in a common routerboard model is doing.
And that also puts a big question mark over what exactly happens if you set a different pvid to two Ethernet ports of such a switch chip when making them member ports of the same bridge. Because the manual says that the switch chip has a defaul-vlan-id configuration item for each port but that it works only on ingress, while the most common chips do not handle this VLAN ID in a unique way in egress direction, which means you cannot have hybrid ports on these chips.
This uncertainty is what makes me refrain from using the bridge and switch menu simultaneously. I can imagine the ROS to adjust the switch chip configuration according to the bridge settings to get the maximum possible hardware acceleration, but if you decide to have VLAN A tagged at port 1 and untagged at port 2, and VLAN B untagged at port 1 and tagged at port 2, I believe this is something the switch chip alone cannot handle so neither VLAN A nor VLAN B frames can be “hardware accelerated”.
I’m paranoid these days so I turn on packet sniffer on interfaces quite often, open it in Wireshark, then peel back the stuff that I know should be there until I find the stuff that shouldn’t be there. It’s surprising if you haven’t done it or haven’t done it in a while.
Doing that is so useful and time-consuming that various companies offer automated solutions doing almost exactly that - analysing network traffic patterns, detecting anomalies and reacting on them.
Reading #13, I understood you bridged wifi and ethernet. I guess that was for simplicity.
Then you saw unexpected traffic on wifi and decided for whatever reason to solve it by creating VLANs.
Seems you are just making trials but keep ignoring some hardware facts.
You cannot avoid CPU when going to Wifi ! Look at your device block diagram, it will definitely help you understand.
Also remember the behavior on standard wifi is absolutely not comparable to wires.
Back to your initial problem. Since all the ports seems to be access port in your case, I am guessing your best solutions would be in decreasing performance order:
1a. Use the built-in switch feature to isolate your vlan-game (include switch cpu for routing/dhcp purpose on that vlan). Use proper routing to reach wifi.
1b. Use the built-in switch feature of Atheros8327 to filter out the offending packets from switch cpu port (menu rule). No routing needed, this is the easiest given you initial situation.
2. If you want to use bridge to tests 6.41, then 1st bridge should include ethernet ports. Second bridge with wifi+other ports will be only powered by cpu. As you notice, from documentation, HW offload is possible only for 1st bridge. You should pick carefully the ports for which you need wirespeed and place them in first bridge. Both solutions 1a and 1b above are going to serve you much better as you would be able to achieve wirespeed on all your ether ports.
3. (Your solution) According to documentation, having a single bridge with VLAN is going to be CPU only no matter what you try unless you have a CRS3xx series. And no such beasts have wifi.
Good luck.
It’s doable, but will require using two domains in post v41 world: bridge for forwarding functionality and switch chip filtering of vlans.
There is even a dedicated example for that:
https://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features#VLAN_Example_2_.28Trunk_and_Hybrid_Ports.29
See also: VLAN not working with Switch Chip - #6 by sebastia
That remark was relevant to switch chips like AR8227 which do not support hybrid ports. E.g. the OP has a box where one group of ports is on an 8327 which supports hybrid ports and another group of ports is on an 8227 which doesn’t.
And I still believe that gradually the vlan-filtering will bubble down from bridge configuration to the switch chips which can handle that, so that it wouldn’t disable the “hardware acceleration” e.g. on the 8327 and so that you wouldn’t need to activate the secure mode and provide the VLAN list “manually” on the chip. Dynamically adding and removing VLAN IDs to switch chip’s tables should even allow MSTP to work without breaking hardware acceleration.
Well,
- CZFan hasn’t expressed any need to do what you mentioned
- even if he did, he can still chose to use the first switch group for that purpose.
So options are available.
CZFan has initially asked for a complete overview, only later he’s provided more details regarding the particular configuration 
So I was trying to provide a complete overview.
Now as experimenting with it I’ve found an even worse moment in all that, if you keep the switch transparent and assign an IP to the bridge itself, the pvid value in the bridge configuration is ignored (or used in a way I don’t understand) and the packets to/from this IP address (interface bridge) live on the bridge tagless. But on the other hand, it is logical, as this is what makes it possible to have hybrid ports on switch chips which do not support them in hardware, e.g. AR8227, by setting vlan-mode=disabled on switch ports.
Yes but…
Expecting something to work a certain way, and then verifying it by looking at the actual traffic are 2 separate things. I’ll continue looking at raw traffic when possible because I like to do it. The only real problem for me is the limitations on what the packet sniffer and/or Wireshark are really telling you, which a whole separate topic.
Looking at the raw traffic will tell you which VLAN tags are actually traveling across the links, which is another way to verify all the functionality being discussed in this thread.
Yes, that’s how I’ve discovered that the bridge sends frames from its own address tagless although the pvid parameter is there, tcpdumping at the linux machine connected to the μTik. And then I’ve spent hours trying to understand how to disable untagged frames to egress on a particular switch port, and when I’ve finally found a way using default-vlan-id=0 on the CPU port along with vlan-mode=secure and using vlan 0 to define the list of ports allowed to egress tagless frames, I’ve ended up with tagless frames travelling bidirectionally through ether1 but not through ether2 although their settings were identical. And I could control egress of the tagless frames through ether5 but they wouldn’t ingress through it although it also had default-vlan-id 0 and vlan-mode=secure like the other two. So I must have messed something but I have no idea what it was.
And I also couldn’t find out how to properly use the egress mode “add-tag-if-missing”. It never added one. The documentation for ar8227 seems to be kept secret, documentation from a similar Atheros chip says that the VLAN ID is the default-vlan-id of the port through which the frame ingressed, but it does not work either.
The idea of the whole exercise was to be able to make the μTik with 8227 have a hardware accelerated bridge with hybrid ports and hardware vlan discrimination per port. The tagless VLAN would have to be the same one on all hybrid ports but it is still better than no hybrid ports at all.
Thank you all, especially sindy & sebastia for all your input, learned a lot and think I have made some good headway.
@sindy, yes, I did request a “Full Overview”, so special thanx to you for all your input
I have edited my initial response to fix the incorrect information provided regarding “/interface bridge pvid”, based on the investigation done in the meantime triggered by another topic.
Sindy, great thread and I keep coming back to it for reference purposes however…
On that topic of PVID but on the /interface VLAN side of the equation (not the bridge).
It seems you have left out valuable information (not intentionally) with respect to /interface vlan and PVID.
Here is where one has an access port situation (be it a PC, a printer, any device incapable of tagging frames) where one needs frames coming into the etherport to be directed to specific egress ports (using 802.1q).
In order for the router to mark the frames with the PVID (vlan1 is the default) and besides obviously entering in the desired PVID one ALSO HAS TO select/enable ingress filtering.
The purpose of ingress filtering in general is to.
a. accept frames with VLAN tags assigned to that etherport.
b. accept frames with VLAN tags that have egress ports associated with same VLAN tag
c. accept untagged frames and tag them with the port assigned PVID
d. (and as you noted, remove the tags from that port when egressing back to said devices.
In the previous posts this ALSO step is not specifically stated:
“…after, you can still use the method of handling tagged and untagged ports described above, but it is better to use only a single bridge for all VLANs. When adding an Ethernet port to that bridge, you set its “pvid” parameter to the VLAN ID for which it should behave as “access port”, i.e. frames with this VLAN ID will be untagged at egress, and frames without a VLAN tag will be tagged with this VLAN ID at ingress; the frames bearing tags with other VLAN IDs will remain tagged at both ingress and egress through that port. So instead of bridging all the untagged Ethernet ports together using the dedicated bridge at the untagged side of the “/interface vlan”, you tag the previously tagless ingress frames in the switch chip as they come in through the Ethernet port, and untag them as they pass from the tagged side to the untagged side of the “/interface vlan”.”
“…But you do have it on Mikrotik (at least in the 6.41+ concept), except that the “native VLAN” is called “pvid” here. When you tell the bridge that a given port has “pvid=5”, it means that ingress tagless packets will be tagged with VLAN ID 5 and egress packets tagged with VLAN ID 5 will be untagged.”
So if I am correct, you do not (need to) use Ingress Filtering when setting up VLAN (tagged/untagged) on a MikroTik router when you do use the VLAN aware bridge config with the 6.41 + RouteOS?
Not quite sure what you are getting at but basically I think of the bridge as a trunk port, and all etherports attached to the bridge that carry vlans as either hybrid ports or access ports and specifically access ports if they do not have a device at the other end of the ethernet cable somewhere (be it a managed switch, a capAC) should be viewed as “access ports”. Thus the data coming from these sources need to be tagged if they are to travel and connect with specific entities (other ports or internet only for example).
Ok, I redo my question.
When do I need to use
Ingress Filtering
on a port?
On 6.41, the PVID is used to tell what VLAN goes untagged on the port and the Bridge VLAN tells what VLAN goes tagged and untagged to the port.
So all my configuration using single Bridge VLAN does not need it??? Or I am totally lost.
Bear with my, just trying to understand it.
From the Manual found here:
https://wiki.mikrotik.com/wiki/Manual:Interface/Bridge#Bridge_VLAN_Filtering
ingress-filtering (yes | no; Default: no)
Enables or disables ingress filtering, which checks if an entry exists for the ingress port and the VLAN ID in the bridge VLAN table. Should be used with frame-types to specify if the ingress traffic should be tagged or untagged. This property only has effect when vlan-filtering is set to yes
This setting is a matter of security and kicks in when there are VLAN capable end devices (let’s assume network devices are configured correctly). So in theory it’s possible to configure end device with VLAN which is not allowed on given access port (I’m using word access meaning used for connecting end device, I’m not referring to its VLAN-related configuration). If ingress-filtering is not enabled, RB would forward those frames to intended destination, replies however would not be forwarded to the plaintiff due to bridge vlan-filtering (which obviously works on egress). Such behaviour might seem harmless (no bi-directional connection can occur, right?), but if protocol used is UDP (stateless on L3/L4!), this could still lead to some kind of service degradation. When ingress-filtering is enabled (and frame-types set to something more restrictive than admit-all), then the non-allowed VLAN frames are dropped immediately.
BTW, manual says ingress-filtering is bridge-wide setting and hence applies to all bridge ports (including bridge as interface, vlan interfaces, wifi, pppoe and what not).
Ahh, good I like the opportunity for discussion (meaning I think mkx missed the mark).
- Ingress filtering applied to a specific etherport has nothing to do with the bridge (at least it appears to be port specific).
- Ingress filtering has both security (specify vlan security and vlan access port functionality purposes. (vlans are already a security process)
Two cases.
One Simple Functionality.
One has a PC that needs to be on a VLAN20 from the rest of the LAN in the house.
It is directly connected via a cable to ether5 on my hex. How to accomplish. Easy peasy. Use ingress filtering with PDVID.
Now all packets coming from the PC at ether5, which are obviously untagged, will get tagged by the switch with VlanID:20
They will get routed appropriately by the router (to internet only for example).
All return packets will reach the etherport 5 and lose their tags.
Complex Functionality
Imagine I have an ISP switch that has both data and vlan3 for voip on its ports.
How do I send both data and voip to another area that also has a hex router but also provide regular data to the rest of the LAN.
The problem is how to separate the VOIP and data from each other so that I dont get two streams of data coming from two ports on the ISP switch into the first main router??
( the normal LAN data basically travels on vlan default ID:1)
The solution (I think - best guess) consists of using two of the ISP switch ports, one for data and one for voip.
On the VOIP intended connection, use normal vlan port settings and both VOIP and normal data will flow to the router.
On the data for external area intended connection, use ingress filtering PVID:100 (this removes in effect the VOIP data packets but captures all the data packets and puts them on vlan100).
Create DHCP for vlan100 of course on the main router.
Example…
MAIN ROUTER (eth6 intended data input for vlan, eth7 intended voip input for network and data for normal lan, eth8 going to next hex(as a switch -carrying vlans (data and voip)
/interface vlan
add interface=mainbridge name=Data-VLAN vlan-id=100
add interface=mainbridge name=ISP-vlan vlan-id=3
/interface bridge
add admin-mac=CC:2D:E0:2F:07:5C auto-mac=no name= \
mainbridge protocol-mode=none vlan-filtering=yes
/interface bridge port
add bridge=bridge interface=eth6 ingress filtering=yes pvid=100
add bridge=bridge interface=ether7
add bridge=bridge interface=ether8
/interface bridge vlan
add bridge=mainbridge tagged=mainbridge,ether6, ether7,ether8 \
vlan-ids=100,3
Secondary hex (ether1 is like a trunk port, eth2-3 get data from vlan, eth4 is a voip port)
/interface bridge
add admin-mac=CC:2D:E0:D8:6C:16 auto-mac=no comment=defconf name=Roombridge \
vlan-filtering=yes
/interface bridge port
add bridge=Roombridge interface=ether1
add bridge=Roombridge interface=ether2 ingress filtering=yes pvid=100
add bridge=Roombridge interface=ether3 ingress filtering=yes pvid=100
add bridge=Roombridge interface=ether4 ingress filtering=yes pvid=3
/interface bridge vlan
add bridge=Roombridge tagged=Roombridge,ether1,ether2,ether3,ether4 \
vlan-ids=100,3
/interface vlan
add interface=Roombridge name=Data-VLAN vlan-id=100
add interface=Roombridge name=ISP-vlan vlan-id=3
In the room vlans, ingress filtering is used to provide vlan100 traffic to the internet from the other location.
All packets are tagged with vlan 100 on the way in on ports 2 and 3, and stripped when egressing back to the PCs.
I am not quite sure how VLAN tagging for VOIP works so assume its traffic coming from the Provider and thus it has a pathway to the Main router and a path to the Secondary Router.
What I am not sure of here is what to do on ether4 on the second hex.
Two cases: Incoming call and outgoing call.
Due to the outgoing call I thought it would be necessary to add ingress filtering and PVID of 3 to etherport4
Hoping someone can shed light on why this may or may not work???