VLAN in new "Bridge Only" config

CZFan · Tue Feb 20, 2018 12:35 pm

I am still struggling to get my head around this VLAN thing, I understand the concept, etc but struggling to fully understand the way of implementation in Mikrotik.

In my searches, I found a topic with an excellent, very easy to follow explanation/post by dasiu, viewtopic.php?t=82414

But with recent changes in ROS 6.41 onward, I am lost again, will someone be so kind and explain explain in a similar, easy to follow / understand way how to achieve this configuration in the new "Bridge Only" config of Mikrotik in order to benefit from the hardware offloading, routing between VLAN's on the same box, etc?

Thanking you in advance

sindy · Tue Feb 20, 2018 2:39 pm

As usually with this highly popular topic, I'm guessing based on the experience gathered up to now.

The new implementation moves part of switch chip configuration from the switch menu to the bridge menu.
The switch chips remain the same so it is still true that most of them have physical Ethernet ports and a single port towards the CPU.

Until you start thinking about VLANs, the only change which really matters is that you have to make each ethernet port a member of a bridge individually, while before you could use the so-called "master port".

When you start thinking about VLANs but not about vlan-filtering, it is still quite easy:

before, the idea was that you make one bridge for all the Ethernet interfaces where a given VLAN should appear tagged, and another bridge for all the Ethernet interfaces where the VLAN should be untagged. The joining interface between the two bridges was "/interface vlan" which was using the "tagged" bridge as its (bearer) "interface" and itself was a member port of the "untagged" bridge, to which you could add also e.g. WLAN interfaces.
"Hardware acceleration" was done by choosing one of the Ethernet ports as a "master port" which was made a member of the bridge, and choosing several others as its "slave ports". Between all the slave ports and the master, everything was forwarded by the switch chip.
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".

For the WLAN interfaces, you can set the VLAN ID and set them to use the common "tagged" bridge as well, both if set up directly or using cAPsMAN.

What is not so obvious is that this "tagged" bridge itself also constitutes an interface which can be given an IP configuration, and therefore it also has a "pvid" parameter. It then works much the same like an "/interface vlan" would. So if you use 3 different VLANs on a bridge, you may create only two "/interface vlan", the third VLAN ID may be configured directly at the "/interface bridge" (as "pvid") instead. No tagless frames can exist in this bridge.
WARNING:The information above was based on the description of pvid parameter on the Mikrotik wiki: "Port VLAN ID (pvid) specifies which VLAN the untagged ingress traffic is assigned to. It applies e.g. to frames sent from bridge IP and destined to a bridge port.". However, the reality is different. At least on hardware models using the AR8227 switch chip, the bridge interface ignores the pvid parameter and sends its packets to the switch chip tagless. So should e.g. VLAN 1 be supported on a trunk port of the switch chip, it is not enough to set pvid=1 in the bridge configuration, and it would be necessary to configure an /interface vlan with vlan-id=1 on that bridge.
On the other hand, this approach permits to configure hybrid ports with hardware acceleration even on AR8227, provided that the same VLAN will be tagless on all of them and that there is no need to have this VLAN tagged on other ports. The key is to use VLAN ID 0 for this tagless VLAN in switch chip configuration. Access ports to other VLANs must not be listed as VLAN 0 member ports.

Frames between member Ethernet ports of that single "tagged" bridge are forwarded by the switch chip without passing forth and back to the CPU, which is the substance of the "hardware acceleration". It works until you decide to use bridge filtering or some other L2 processing which requires CPU interaction. And it seems to work only on a single bridge like this. You may add several bridges with similar configuration but only one of them will be hardware accelerated even though all of them would be configured to be.

You can still use the switch chip's own VLAN handling (which differ notably between switch chip types!) using the switch menu (/interface ethernet switch). The possibilities of various switch chips are described quite clearly on the Mikrotik Wiki.

The rodeo begins when you want to use vlan-filtering at bridge configuration level. On almost all hardware platforms switching it on means that you lose the hardware acceleration because the vlan-filtering is (so far?) done by the CPU, but you cannot avoid it e.g. if you want to use MSTP.

For vlan-filtering, it is necessary to define the rules for the filtering using "/interface bridge vlan" rule list. The rules here provide, for each group of vlans (item "vlan-ids") and each bridge (item "bridge"), a list of ports on which the group of VLANs should be permitted as tagged and another list for untagged member ports of that VLAN group (items "tagged" and "untagged"). But beware - the bridge itself must be listed as its own tagged member interface, otherwise the path between the switch chip and the CPU will be closed for that VLAN group once you permit vlan-filtering on the bridge. So the Ethernet members of the VLAN would remain isolated from the CPU-side members - local interfaces (the /interface bridge itself, all the /interface vlan using it, and all the WLAN interfaces using it). I hope the need to do this confusing setting is only temporary.

Another source confusion is that some rows in this table are generated dynamically, much like in the "/interface bridge port" table:

there, you have to set Ethernet interfaces as bridge member ports manually, using "/interface bridge port add", while /interface vlan and /interface wireless become member interfaces "dynamically" - actually because their own configuration indicates the bridge they should become members of.
here, all elements whose configuration includes a VLAN ID (/interface vlan, /interface wireless) dynamically pop up in the "/interface bridge vlan" table on a line with that single VLAN ID on the "vlan-ids" list. I'm not sure whether this is the case also for Ethernet interfaces (which also have a pvid parameter), but in 6.41, it was not possible to add a manually created line to the table when the dynamically created one was present.

CZFan · Tue Feb 20, 2018 8:34 pm

Thx sindy, much appreciated

sindy · Tue Feb 20, 2018 8:53 pm

Thx sindy, much appreciated

I'd appreciate a feedback - of course at first place on anything which is not true in my desciption, but also on anything which is missing or incomprehensible.

CZFan · Tue Feb 20, 2018 9:01 pm

Will do, you will have to give me some time to work through this and practice in lab setup

sebastia · Tue Feb 20, 2018 9:27 pm

From what I've understood from docs, if vlan filtering is done at switch (so under switch menu), it will be in hardware for select switch chips.
https://wiki.mikrotik.com/wiki/Manual:S ... troduction

netflow · Tue Feb 20, 2018 10:23 pm

I am a software guy. Let me explain how I see it, even after 6.41:

Switch is to pilot the hardware switch. This is your best bet to control/achieve top notch performance.
Bridge was (initially) pure software to realize non homogenous switches (L2 link between wifi, ethernet, vpn, ...).

They both have exact same goals but achieve differently: once with some switch fabric, once with CPU power.

Now Mikrotik attempts to merge/reunify them and will attempt to figure out for you based on hardware capabilities were it can achieve some hw optimizations.
Switch menu will eventually disappear but it is likely it will take many iterations before it is complete.
Meanwhile and despite the confusion, Mikrotik is nice enough to leave the switch menu available.

So now to summarize:

If you care for maximum performance, are fully wired, then continue using switch features for your vlan + vlan filtering.
If you look for maximum flexibility to build non homogenous L2 then use bridge.
If you care for both and your applications permits it, then you should probably look for L3 routing anyway.
If you really need L2 with top performance, upgrade your hardware for beefy CPU (eg: CCU or x86), none have switch fabric built-in anyway

My recommendation (untested but seems logical given the above):
As of 6.41.2, continue doing vlan + vlan filtering at the switch level for ethernet, then use no filtering at the bridge level if you can for those ports as they will have been already filtered by switch fabric.
If you have to filter at the bridge port, then doing in both switch+bridge might remove some traffic and help the CPU. This may no longer hold once they continue imlementing hw optimizations.

Suggestion for Mikrotik:
Whatever switch features you pilot from bridge, should go as a dynamic entry in switch.

Sorry for the long post. Hope it helps.

acruhl · Tue Feb 20, 2018 11:58 pm

Maybe I'm a bit ignorant... I work with Cisco and Juniper all day, and they make this stuff really easy.

You either have a tagged vlan or you don't. You just push those around to whatever port you want them to go, and they go there. There's a little bit more to it than that in areas, but basically that's all it is.

I would really like to see this idea of a "native" vlan in MikroTik, because it's an easy concept to grasp, especially on a trunk link between devices (ISL as it's called). Or to an edge port for a device that wants tagged traffic.

I never wanted to know if the CPU has to "deal with it" or not, although I suppose on smaller not so integrated devices it's a pretty important thing to know.

Sindy or netflow (or anyone) - is this explanation valid for both SwOS and RouterOS? I really need to dig deeper into vlan config and trunk ports in MikroTik despite my incredulity at the complexity of it. Hopefully it will make more sense once I practice at it.

netflow · Wed Feb 21, 2018 12:32 am

You are right, hence the current move to bridge with automatic optimizations.
From a conceptual prospective understanding bridge feature is enough and you may skip the switch feature completely.

sindy · Wed Feb 21, 2018 4:18 pm

Maybe I'm a bit ignorant... I work with Cisco and Juniper all day, and they make this stuff really easy.

You either have a tagged vlan or you don't. You just push those around to whatever port you want them to go, and they go there. There's a little bit more to it than that in areas, but basically that's all it is.

It's almost like this but not exactly. The general principle with switches is that nothing like VLANs actually exists physically (that's why they are called "virtual"), it is all about the frame VLAN tags and filtering incoming and outgoing frames up to these tags. So if you say that a switch port is a member of a VLAN, it actually means that frames tagged with that VLAN ID are allowed to pass through it (bi-directionally).
On top of that, you can tell each port how to handle ingress (received from the wire) frames with no VLAN tag at all, but normally the only choices are "tag it with ID xxx" and "drop it". So on any switch with an elementary self-respect, you cannot meet frames without VLAN tag inside.

The rest, including the vernacular, is manufacturer dependent. You can have permit lists (no VLANs except the listed ones permitted on the port) or deny lists (all VLANs except the listed ones permitted on the port), you can have the "access ports" (with just a single VLAN permitted which is tagged on ingress and untagged on egress), "trunk ports" (where all permitted VLANs must be tagged), and "hybrid" ports which behave as "trunk" for N VLANs and "access" for one additional one; Cisco calls the same thing a "native VLAN" of a trunk port. There are switches where the tag handling in egress and ingress direction is configured separately, i.e. if you configure tagging of tagless ingress frames with VLAN ID x, it may not automatically mean that frames with this VLAN ID will be untagged on egress.

I would really like to see this idea of a "native" vlan in MikroTik, because it's an easy concept to grasp, especially on a trunk link between devices (ISL as it's called). Or to an edge port for a device that wants tagged traffic.

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.

What you do not have in Mikrotik unless you permit vlan-filtering in bridge configuration or do some middle level wizardry on switch configuration (and I deeply trust you should not do both unless you are really sure what you do) is filtering of VLANs on ports. So if some neighbouring equipment decides to broadcast frames in a VLAN you are not interested in, the Mikrotik switch would broadcast them to all its ports.

I never wanted to know if the CPU has to "deal with it" or not, although I suppose on smaller not so integrated devices it's a pretty important thing to know.

The thing here is the speed and how activation of some functionalities affects it. The switch is a hardware device whose throughput should basically be sufficient to forward everything it receives, unless e.g. incoming data from two ports should be forwarded through a single egress port. The bridge (in Mikrotik or linux sense) is a software which implements the same algorithms like a switch does in hardware. However, whereas on a PC it is theoretically possible to have a similar throughput if the bus is fast enough that several Ethernet cards can send and receive simultaneously without competing for the bandwidth, smaller Mikrotik hardware has two bottlenecks here - one is the CPU power itself and the one is the fact that the CPU is connected to just one of the ports of the switch chip whose bandwidth is not the sum of bandwidths of its Ethernet ports.

So you can pamper your ignorance about what is done by a switch and what is done by the CPU until you find out that you get a 80 Mbit/s throughput between two gigabit ports.

A bright example is MSTP. The purpose of STP is to prevent loops in complex L2 network topologies, as the founding fathers of L2 networking forgot to include a TTL field to the frames so if a loop topology incidentally occurs, broadcast frames circulate through that loop forever, until they eventually occupy the whole available bandwidth of the slowest member link of the loop.

So the STP monitors the topology and if a loop occurs, it cuts it at an optimal place by disabling a port at one end of the link closing the loop. But not only that the port must be disabled for any traffic except STP's control one; with MSTP, which controls several independent spanning trees (instances) with individual topologies, it may be necessary to disable a port only for member VLANs of one spanning tree instance but not for others. And unless the switch chip supports this simultaneously with the ability to deliver STP control frames to the CPU together with an information from which port they come, this must be done by the CPU and therefore at bridge level. So instead of forwarding frames between ports of the switch chips, they must all be delivered to the CPU for handling.

netflow · Thu Feb 22, 2018 9:19 am

What you do not have in Mikrotik unless you permit vlan-filtering in bridge configuration or do some middle level wizardry on switch configuration (and I deeply trust you should not do both unless you are really sure what you do) is filtering of VLANs on ports. So if some neighbouring equipment decides to broadcast frames in a VLAN you are not interested in, the Mikrotik switch would broadcast them to all its ports.

I probably did not get your point right.
If broadcasting was bypassing filtering by VLAN ports we can call it a major flaw and we will have to drop Mikrotik equipments for any L2 traffic using vlan.
Could you show any evidence of that ? Any configuration issue on your side maybe ?

sindy · Thu Feb 22, 2018 11:32 am

What you do not have in Mikrotik unless you permit vlan-filtering in bridge configuration or do some middle level wizardry on switch configuration (and I deeply trust you should not do both unless you are really sure what you do) is filtering of VLANs on ports. So if some neighbouring equipment decides to broadcast frames in a VLAN you are not interested in, the Mikrotik switch would broadcast them to all its ports.
I probably did not get your point right.
If broadcasting was bypassing filtering by VLAN ports we can call it a major flaw and we will have to drop Mikrotik equipments for any L2 traffic using vlan.
Could you show any evidence of that ? Any configuration issue on your side maybe ?

What I am saying is not specific to broadcast frames, I have used them just as an illustration to avoid additional details regarding handling of unicast frames.

So what I am saying is that without configuring the VLAN filtering rules under "/interface bridge vlan" and then activating them using "/interface bridge set vlan-filtering=yes" for a bridge, or without setting VLAN ID filters in the "/switch" configuration tree: if a frame tagged with any VLAN ID arrives through a member port of that bridge, it is forwarded to one or all member ports of that bridge according to the forwarding database (MAC table), of course still tagged with the same VLAN ID. So unicast frames towards MAC addresses the bridge has never seen before, as well as broadcast/multicast frames, are forked to all member ports of that bridge. And that this behaviour does not depend on whether an "/interface vlan vlan-id=X" is created on the bridge.

Or, in much simpler words, that the bridge is transparent for all VLANs unless you activate filtering by VLAN ID one way or the other.

What I am not saying is that broadcast frames would bypass VLAN filtering if it is activated.

CZFan · Thu Feb 22, 2018 5:55 pm

Ok, I am further behind than I thought and you clever guys are talking way above my head at the moment.

To give you some background, I have been in IT Industry for 25 years now, but the last 18 years of that has been in management managing IT Operations for multi national corporations, which also means I had to sit in meetings all day and have lost all the how to of the nuts & bolts, etc a long time ago

I came onto a perfect opportunity to practice this VLAN thing to help me understand it better, I learn better with practical experience. But need yous clever people's assistance, if I may.

Herewith the scenario:
At home I have a RB2011UiAS-2HnD, with ROS 6.41.2. All interfaces are in a bridge, including WLAN interface with a /24 subnet. Have a 1Gb down and 100Mb up fibre link, extremely happy with this little router but always felt the wireless response can be bit better.
So being bored today, I connected my laptop via WiFi, did not open any applications and started sniffing my home network to see what happens to/from my laptop and analyzed the frames/packets with Wireshark.
From all the packets sniffed, +- 40% of these were UDP broadcasts on port 54915 I received from 2 pc's, (2 of my boys pc's) which are connected via Ethernet cable on the Gb ports of RB2011. Some further research revealed that these might be possible from Logitech ARX Control software, so I was thinking, I have about 15 wireless devices on this router, every wireless device will also receive these packets and at 40% of traffic, surely it will affect the WiFi.

Now what I want to do is, place these 2 buggers in a VLAN on their own IP subnet, but do not want to lose the hardware offloading ability as that seems to happen when I create a 2nd bridge, the hardware offloading disables, is that by design?
This way they can broadcast each other broken and it will not affect the WiFi as much. PS. I will also instruct them to correct their settings which will be the best as it will not make use of any router resources then, but I first want to use this opportunity to practice the VLAN thing.

I tried following the previous posts in this topic, I reviewed 3 different VLAN configs on the Mikrotik Wiki, tried a bit but cant get what I want.

So if you can please explain to me like I am a six year old how to achieve this, it will be much appreciated.

As always, thanking you in advance, if you need more info, please shout

sindy · Thu Feb 22, 2018 6:09 pm

Now what I want to do is, place these 2 buggers in a VLAN on their own IP subnet, but do not want to lose the hardware offloading ability as that seems to happen when I create a 2nd bridge, the hardware offloading disables, is that by design?

Obviously yes, the switch chip can not handle two independent groups of ports using separate forwarding tables. So any port which needs individual treatment has to be handled by the CPU where each bridge has its independent forwarding tables.

So if you can please explain to me like I am a six year old how to achieve this, it will be much appreciated.

You say that you have all ports in the same bridge, including WLAN. Does that "all" include the WAN port? Or, from another perspective, is the box configured as a router at all?

I think the answer to all questions we may have is the output of "/export hide-sensitive" after systematically replacing each public IP eventually present with a distinctive token if you don't want to reveal them. So let's start from this.

CZFan · Thu Feb 22, 2018 6:46 pm

@sindy, yes, apologies, ether1 is not part of the bridge / switch group and is configured as WAN interface.

Then, if the 2nd bridge thing is true, then the process will be?

/interface bridge
add name=bridge2 igmp-snooping=no protocol-mode=none

/interface bridge port
add bridge=bridge2 interface=ether2 hw=yes
add bridge=bridge2 interface=ether3 hw=yes

/interface ethernet switch vlan
add ports=ether2,ether3 switch=switch1 vlan-id=100

/interface ethernet switch port
set ether2 vlan-mode=secure vlan-header=always-strip default-vlan-id=100
set ether3 vlan-mode=secure vlan-header=always-strip default-vlan-id=100

Add DHCP, etc to Bridge2
Continue as per normal for routing, etc

I have no problem posting my config, but have reverted all changes so currently no VLAN configs, do you still want me to post it?

CZFan · Thu Feb 22, 2018 7:34 pm

I think a light went on, and should be this?

/interface bridge
add name=bridge1 vlan-filtering=no

/interface bridge port
add bridge=bridge1 interface=ether2 pvid=100
add bridge=bridge1 interface=ether3 pvid=100
add bridge=bridge1 interface=ether"The rest in Bridge" pvid=200

/interface bridge vlan
add bridge=bridge1 tagged=bridge1 untagged=ether2 vlan-ids=100
add bridge=bridge1 tagged=bridge1 untagged=ether3 vlan-ids=100
add bridge=bridge1 tagged=bridge1 untagged=ether"The rest in Bridge" vlan-ids=200

/interface vlan
add interface=bridge1 name=vlan100 vlan-id=100
add interface=bridge1 name=vlan200 vlan-id=200


/ip address
add address=192.168.170.1/24 interface=vlan100 network=192.168.170.0
add address=192.168.168.1/24 interface=vlan200 network=192.168.168.0

/interface bridge set bridge1 vlan-filtering=yes

sindy · Thu Feb 22, 2018 9:01 pm

I think a light went on, and should be this?

Correct (at least as in terms that it matches my initial explanation), except that by setting "vlan-filtering=yes", you break the hardware offloading. And if you do not set vlan-filtering to yes, you don't need all the settings under "/interface bridge vlan".

Next, don't forget that you need the complete DHCP server settings for both VLANs/subnets (/ip pool, /ip dhcp-server network, /ip dhcp-server itself).

If your juniors' PCs flood the network only with broadasts, it is enough to give them their own subnet as you've suggested. If you suspect that there may be something worse than a broken Logitech driver, you may want to set firewall rules between this "quarantine LAN" and the basic one.

freemannnn · Thu Feb 22, 2018 10:02 pm

"except that by setting "vlan-filtering=yes", you break the hardware offloading."

thank you for pointing out this. i didnt think of that.

sindy · Thu Feb 22, 2018 10:21 pm

"except that by setting "vlan-filtering=yes", you break the hardware offloading."

thank you for pointing out this. i didnt think of that.

I still hope it is a temporary state at least for some of the switch chips for which it is currently true but I have no qualified reasons for that

See the reference in my first post in this topic.

CZFan · Thu Feb 22, 2018 10:55 pm

Thx sindy, seems there is still hope for this old geyser

CZFan · Fri Feb 23, 2018 12:20 am

Correct (at least as in terms that it matches my initial explanation), except that by setting "vlan-filtering=yes", you break the hardware offloading.
...

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?

sid5632 · Fri Feb 23, 2018 1:24 am

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.

sindy · Fri Feb 23, 2018 11:25 pm

What you do not have in Mikrotik unless you permit vlan-filtering in bridge configuration or do some middle level wizardry on switch configuration (and I deeply trust you should not do both unless you are really sure what you do) is filtering of VLANs on ports. So if some neighbouring equipment decides to broadcast frames in a VLAN you are not interested in, the Mikrotik switch would broadcast them to all its ports.
I probably did not get your point right.
If broadcasting was bypassing filtering by VLAN ports we can call it a major flaw and we will have to drop Mikrotik equipments for any L2 traffic using vlan.
Could you show any evidence of that ? Any configuration issue on your side maybe ?
...
So what I am saying is ... that the bridge is transparent for all VLANs unless you activate filtering by VLAN ID one way or the other.

What I am not saying is that broadcast frames would bypass VLAN filtering if it is activated.

@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.

acruhl · Sat Feb 24, 2018 4:28 am

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.

sindy · Sat Feb 24, 2018 9:35 am

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?

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.

netflow · Sat Feb 24, 2018 2:07 pm

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.

sebastia · Sat Feb 24, 2018 5:17 pm

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".

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:S ... d_Ports.29

See also: viewtopic.php?f=2&t=130283&p=640280&hilit=vlan#p640112

sindy · Sat Feb 24, 2018 5:50 pm

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".
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:S ... d_Ports.29

See also: viewtopic.php?f=2&t=130283&p=640280&hilit=vlan#p640112

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.

sebastia · Sun Feb 25, 2018 3:55 pm

Well,
1. CZFan hasn't expressed any need to do what you mentioned
2. even if he did, he can still chose to use the first switch group for that purpose.

So options are available.

sindy · Sun Feb 25, 2018 4:21 pm

Well,
1. CZFan hasn't expressed any need to do what you mentioned
2. 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.

acruhl · Mon Feb 26, 2018 9:15 pm

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.

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.

sindy · Mon Feb 26, 2018 10:52 pm

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.

CZFan · Tue Mar 06, 2018 5:19 pm

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

sindy · Tue Mar 06, 2018 10:30 pm

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.

anav · Sat Nov 17, 2018 6:43 pm

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."

Jotne · Sat Nov 17, 2018 9:16 pm

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?

anav · Sun Nov 18, 2018 3:09 am

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).

Jotne · Sun Nov 18, 2018 10:38 am

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:I ... _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

mkx · Sun Nov 18, 2018 1:51 pm

Ok, I redo my question.
When do I need to use
Code: Select all
Ingress Filtering
on a port?

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).

anav · Sun Nov 18, 2018 6:38 pm

Ahh, good I like the opportunity for discussion (meaning I think mkx missed the mark).

1. Ingress filtering applied to a specific etherport has nothing to do with the bridge (at least it appears to be port specific).
2. 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????

sindy · Sun Nov 18, 2018 7:00 pm

The following doesn't play well together:

/interface bridge port
add bridge=Roombridge interface=ether1 pvid=1
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

The pvid parameter of an item in /interface bridge port must match the untagged role of the port in /interface bridge vlan item for the respective vlan-ids. So the proper setting would be the following one:

/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,ether4 \
untagged=ether2,ether3 vlan-ids=100
add bridge=Roombridge tagged=Roombridge,ether1,ether2,ether3 \
untagged=ether4 vlan-ids=3

I.e. you must have a separate item in /interface bridge vlan for each VLAN which you want to untag on egress & tag on ingress on at least one port.

And a similar modifciation needs to be done on the other machine.

anav · Mon Nov 19, 2018 1:45 am

Hi Sindy, I will be quite honest, I have an inkling, a scratch that what I did was not entirely correct but do not yet understand what you said and will look at this for awhile.
It seemed to easy to have one rule with all the vlans and all the ethports/wlans involved on one line.
For now I just want to confirm then -
It is possible/acceptable/required to have more than one /ip interface bridge vlan rule in place?

If I accept at face value your line - I.e. you must have a separate item in /interface bridge vlan for each VLAN which you want to untag on egress & tag on ingress on at least one port.

Can I conclude that you mean a VLAN that requires ingress/egress tagging changes requires its own bridge vlan interface rule and thus in my rule below,
since there is another vlan that there needs to be two instances of interface bridge vlan, OR do you mean
If there two or more VLANS that require ingress/egress tagging changes, each of these vlans requires their own bridge vlan interface rule??
The reason I ask is because on the main router, I only have one such VLAN (vlan100) on the main router that required ingress/egress and not vlan3.
So I will assume that I do or do not need a second interface bridge vlan rule at the main router???

So the setup should be as follows
Main Router

/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

????? THIS ????????
/interface bridge vlan
add bridge=mainbridge tagged=mainbridge,ether6,ether8 \
vlan-ids=100
/interface bridge vlan
add bridge=mainbridge tagged=mainbridge, ether7,ether8 \
vlan-ids=3

OR SIMPLY THIS
/interface bridge vlan
add bridge=mainbridge tagged=mainbridge, ether6, ether7,ether8 \
vlan-ids=100,3

And for the Secondary Router (clearly multiple vlans needing ingress/egress)

/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 \
vlan-ids=100
/interface bridge vlan
add bridge=Roombridge tagged=Roombridge,ether1,ether4 \
vlan-ids=3
/interface vlan
add interface=Roombridge name=Data-VLAN vlan-id=100
add interface=Roombridge name=ISP-vlan vlan-id=3

I think what would help is an explanation of what will happen if I stuck with the above plan WITHOUT the additional /interface bridge vlan rule???? - what would happen at main or secondary router by missing this requirement

anav · Mon Nov 19, 2018 2:12 am

While waiting for the question to be answered by Sindy in the previous post, the OP noted he wants a simple configuration approach in that the LAN is shared by both the Main Router and Extended Room area.

In this case, the following below applies. In this case, there is no need for two ISP ports to go to the Main Router, will only need one ethport connection and will use eth7.
The Data vlan is NOT required. The bridge port for eth6 is NOT required. The extra /interface bridge vlan rule is NOT required.

Main Router

/interface vlan
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=ether7
add bridge=bridge interface=ether8
/interface bridge vlan
add bridge=mainbridge tagged=mainbridge, ether7,ether8 \
vlan-ids=3

In the main router, both data and voip traffic will arrive on eth7.
We have identified both eth7 and eth8 as viable paths for vlan3 traffic and thus the router will see the vlan3 packets and will flow them from eth7 to eth8.
Data as we have been shown is untagged at some point by the ISP before it exits the ISP switch and thus arrives untagged at ether7.
This Data (pvid:1) is then distributed to ALL bridgeports including eth8.

For the Secondary Router (and since there is only one vlan requiring egress and ingress tagging untagging, and there are NO OTHER VLANS, we only need the one /interface bridge vlan rule.

/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
add bridge=Roombridge interface=ether3
add bridge=Roombridge interface=ether4 ingress filtering=yes pvid=3
/interface bridge vlan
add bridge=Roombridge tagged=Roombridge,ether1,ether4 \
vlan-ids=3
/interface vlan
add interface=Roombridge name=ISP-vlan vlan-id=3

In this case, the normal LAN/internet data (via pvid:1) and voip traffic are arriving at eth1.
The secondary router/switch device knows to route the vlan3 traffic to ethport4 and the normal lan-internet data will flow to ethports 2,3.
SInce all packets coming to the device on eth4 will be tagged with vlan3, the regular lan path/data flow will not occur on this port.

Jotne · Mon Nov 19, 2018 8:34 am

For now I just want to confirm then -
It is possible/acceptable/required to have more than one /ip interface bridge vlan rule in place?

From what I do understand:

If you have only one vlan numer that is untagged across all ports, YES
Example on port 1,3 and 4 you have pvid 20, and on the rest there are one tagged vlan, then you are ok
Where you have tagged ports are not important

But If you have more than one vlan number that are untagged across the ports: NO
Example on port 1 and 2 you have pvid 20, on port 3 and 4 you have pvid 30, then you need two line in /interface bridge vlan

According to this post and my experience.

I.e. you must have a separate item in /interface bridge vlan for each VLAN which you want to untag on egress & tag on ingress on at least one port.

sindy · Mon Nov 19, 2018 2:30 pm

I think what would help is an explanation of what will happen if I stuck with the above plan WITHOUT the additional /interface bridge vlan rule???? - what would happen at main or secondary router by missing this requirement

I'm afraid I'm not deep enough into the implementation to tell you what exactly happens if you fail to use an individual row under /interface bridge vlan for each vlan which has at least one untagged port, but since there are two port lists (tagged and untagged) in each rule, I'd guess they are there on purpose. I wouldn't do it that way myself (because effectively the same information must be entered twice, so I'd either use tagged & untagged lists under /interface bridge vlan and no pvid under /interface bridge port, or just a single list such as member under /interface bridge vlan and keep the pvid under /interface bridge port), but gents in Riga did, so we have to follow that concept.

So if the pvid in a row of a given interface under /interface bridge port doesn't match the vlan-ids of the row under /interface bridge vlan where that same interface is on the untagged list, it simply Will Not Work. I cannot say what exactly will fail, whether the egress direction, the ingress direction, or both.

As there is nothing in the L2 part of the tagless frame coming from the wire which would allow to choose a particular VLAN ID to tag that frame with, it is clear that there can be only one pvid per bridge port; if there can be only one pvid per bridge port, that port can be on the untagged list for only one vlan-ids in the other table.

anav · Mon Nov 19, 2018 4:28 pm

..... it is clear that there can be only one pvid per bridge port; if there can be only one pvid per bridge port, that port can be on the untagged list for only one vlan-ids in the other table.

Still muddy!
The first half of the sentence I grasp, it is clear to me that there can only be one pvid per bridge port (typically default vlanid:1).
The second half does not because it is not clear to me what table you are talking about??

I think what you are saying is the following:
1- Bridge ports are assigned to all etherports/WLans served by the bridge.
2 -When vlan are also served by the bridge they have to pass through bridgeports.
4-When vlans are used, the /interface bridge vlan rule needs to be made to identify which bridgeports may be involved (tagged) and which vlans may be involved (vlan IDs).
and the assumption is
a. all LAN traffic is being passed on all bridge ports by default (pvid:1)
b. all bridgeports identified (tagged)in the /interface bridge vlan rule are capable of carrying all the identified vlan id traffic (no separation or routing specifically noted all is possible)
3-When one or more vlans are served by a bridge but do not require the bridge ports to do anything but act like hybrid ports, one only requires one /interface bridge vlan rule - Conclusion ONE RULE.
4-Whenever one has only one VLAN on a bridge, and an associated bridgeport carrying that vlan requires ingress filtering and pvid:!1 (or unique), then only one /interface bridge port vlan rule is required as there are no other VLANs requiring service. If there are other bridgeports that will carry that vlan, they can be so identified on the same rule - Conclusion ONE RULE.
5- However take the case in 4, and another vlan is being served by the bridge, then an additional rule is required, the 4 rule to deal specifically with the interaction between the bridge and that bridgeport, and any other bridgeports that will specifically handle that vlan traffic, and a separate rule to deal with all other vlans - Conclusion TWO RULES.
6. Extrapolating to a second bridgeport**** that requires ingress filtering/pvid:!1, then we will need /interface bridgevlan for each of the bridgeports with the ingress filtering and one rule for the other VLANS. Conclusion THREE RULES.

Note: In 5 and 6 I am assuming that there may be some overlap in bridgeports if a particular bridgeport is part of a 'normal' VLAN not affiliated with ingress filtering on other bridge ports but also part of the ingress filtered vlan, it could be in more than one rule...

Note: I do see the 'untagged' pattern described, as in each case where two or more rules are required (when there is at least two vlans and one of them requires ingress filtering on a bridgeport), the VLAN associated with the ingress filtering will then exist on a /interface bridge rule (THE OTHER RULE) where it is UNTAGGED (not identified) and this gives the bridge enough information as to breakdown the routing of the vlan traffic.

*****I am assuming if there are two bridgeports requiring ingress filtering and pvid!1 but for the same VLAN, that would not create/force an xtra rule as they would be on the same rule and there would be an additional rule if required (any other 'normal' vlan being served on the bridge) etc....

Basic questions thus become:
How many vlans are required
How many of those vlans will require ingress filtering at bridgeports
How many bridgeports require ingress filtering/pvid:!1 for unique PVIDS

Ex.
1:0 OR any X:0 = One rule
1:1 = One rule
++++++++++++++++++++++++++++
2:1 OR any (X>1):1 = Two rules
2:2 = Two rules
(X>2):2 = Three rules
+++++++++++++++++++++++++++
3:3 = Three rules
(X>3):3 = Four rules
+++++++++++++++++++++++++++

Conclusion, the number of vlans requiring ingress filtering = the number of /interface bridge vlan rules as a starting point. Add one more rule for any number of additional vlans that do not require the filtering.

sindy · Mon Nov 19, 2018 6:41 pm

You discuss too many cases, it is actually much simpler. There are just two factors to take care about:

whether the vlan is permitted or not on a given port of a bridge at all
whether that port should be treated as an access one for a given VLAN (so untagged on egress and tagged on ingress) or as a trunk one (so no tag manipulation on egress or ingress).

So you could use a single table as in the example below, not very practical but illustrative, to express the two properties above:

       | VLAN A | VLAN B | VLAN C | VLAN D | VLAN E |
-------+--------+--------+--------+--------+--------|
ether1 | access | trunk  | trunk  | trunk  | trunk  |
ether2 | trunk  | trunk  | trunk  | trunk  | trunk  |
ether3 | trunk  | trunk  | trunk  | forbid | forbid |
ether4 | forbid | access | forbid | forbid | forbid |

Using the two configuration tables of RouterOS, the same information is expressed as

/interface bridge vlan
bridge=br-x vlan-ids=A untagged=ether1 tagged=br-x,ether2,ether3
bridge=br-x vlan-ids=B untagged=ether4 tagged=br-x,ether1,ether2,ether3
bridge=br-x vlan-ids=C tagged=br-x,ether1,ether2,ether3
bridge=br-x vlan-ids=D,E tagged=br-x,ether1,ether2

The last line can be a common one for both VLAN D and VLAN E because both share the same topology on this device. VLAN C has a different local topology so it has to have its own row in the /interface bridge vlan table although it has no access port on this device.

/interface bridge port
add bridge=br-x interface=ether1 pvid=A
add bridge=br-x interface=ether2 pvid=4094
add bridge=br-x interface=ether3 pvid=4094
add bridge=br-x interface=ether4 pvid=B

Actually, the mandatory columns of this second table are redundant as the same information is already available in the /interface bridge vlan table; the optional columns in its rows are what makes it important, like the ingress-filtering which says whether the list of vlans permitted on this port should be taken into account already at ingress (yes) ot only at egress (no).

anav · Mon Nov 19, 2018 7:36 pm

Haha you did have to go and introduce a new term on me (forbidden).
Also, the untagging selection, in /interface bridge vlan is not a selection I have ever entered any values here and even worse I DONT KNOW WHEN TO USE IT

Lets assume we have an eth6 as well but it has no vlans associated (regular LAN).
As for the table, its an illegal/wrong table.
Take eth1 for example you have an access vlan associated with it and one can only HAVE ONE VLAN in that scenario!!
I cannot even begin to fathom any bridge port rules or interface bridge vlan rules until we clarify that.....

So here is what eth1 should look like

       | VLAN A | VLAN B | VLAN C | VLAN D | VLAN E |
-------+--------+--------+--------+--------+--------|
ether1 | access |  - |  -  |  -  | -  |
ether2 | trunk  | trunk  | trunk  | trunk  | trunk  |
ether3 | trunk  | trunk  | trunk  | forbid | forbid |
ether4 | forbid | access | forbid | forbid | forbid |

I have no clue as to the forbid. There is no setting for forbid I am aware of.
In this case one simply means one doesn not vlan traffic of that ilk on those ports.........
Then we get to ether4, and if I replaced all the forbids with "-" it would make more sense
because ingress filtering with pvid is a way of forbidding any vlans that are not at pvid.
(a-10, b-20, etc)

 | VLAN A | VLAN B | VLAN C | VLAN D | VLAN E |
-------+--------+--------+--------+--------+--------|
ether1 | access   |  -          |  -            |  -            | -           |
ether2 | trunk      | trunk    | trunk      | trunk       | trunk    |
ether3 | trunk      | trunk    | trunk      | forbid      | forbid   |
ether4 | -            | access | -             | -              |  -          |

So in this case we have two bridge ports that require ingress filtering and we have five vlans overall.
so i am suggesting we have the following........
/interface bridge vlan
tagged=localbridge, eth1,eth2,eth3 vladID=10

/interface bridge vlan
tagged=localbridge, eth4 ,eth2,eth3 vladID=20

/interface bridge vlan
tagged=localbridge, eth2,eth3 vlanID=30

/interface bridge vlan
tagged=localbridge, eth2 vlanid=40,50

sindy · Mon Nov 19, 2018 11:18 pm

Yes, I've used what I deemed a common English word, forbidden, to describe the case when the frames tagged with that VLAN ID are not allowed to egress or ingress on that port at all, neither tagged nor tagless. And whenever you have several possible values of a parameter, you can make one of them a "default" one, which means that it is used whenever no other one is specified. So if, for a given VLAN ID, the port is neither on the tagged list nor on the untagged list, it means that it is not a member of that VLAN, i.e. that frames belonging to that VLAN are forbidden to pass through that port. Sorry for confusing you by using "forbid" instead of "-", the meaning is the same.

As for "access", "hybrid" and "trunk" on one hand, and "tagged" and "untagged" on the other one, these are just several ways how to describe the same thing. On any switch or bridge port, you can normally permit as many VLANs as you want, but only one of them can be tagless on the wire, for the reason stated earlier - if a tagless frame arrives, some configuration item must indicate the VLAN ID to attach to that frame on ingress, and in the opposite direction, the VLAN ID to be removed on egress.

In Cisco vernacular, the term "access" is used to describe the mode of the port as a whole, so only a single VLAN may be permitted on an "access port"; some other vendors use the term "access" with regard to way how a particular VLAN is handled on that port, so you can have "hybrid" ports where one VLAN is processed in access mode while the rest of the VLANs permitted on that port is handled in "trunk" mode, i.e. their frames remain tagged on ingress and egress.

In Cisco vernacular, a "trunk" port is such where more than a single VLAN is permitted, and if a "native VLAN" is specified on such port, that VLAN is processed in access mode, i.e. untagged on egress etc.; other vendors call a "trunk" port one on which only tagged frames get in an out, while a "hybrid" port is one on which all VLANs but one are handled in trunk mode and exactly one in access mode.

What I'm trying to say is that the actual behaviour is simple, but the various methods of describing it by a single word are confusing because different vendors use the same words in a mutually shifted meaning.

So if we get back to how RouterOS configures that: if you want a port to be an "access-only" one for a given VLAN, that VLAN ID must be the only one permitted on it, and it must be permitted in untagged mode (i.e. the port name must be on the untagged list of that VLAN), and that VLAN ID must be set as pvid under /interface bridge port.

As for ingress-filtering on a bridge port, it seems to act before the tagless frames get tagged, as the manual says that ingress filtering checks both the VLAN ID and the frame-types value configured, which may be one of (admit-all, admit-only-untagged-and-priority-tagged, admit-only-vlan-tagged). So you can use ingress filtering for both purposes, but the required frame-types setting depends on whether you want to use only tagless or priority-only tagged frames on that port (i.e. access-only port), only vlan-tagged frames (i.e. trunk-only port), or both frame categories (i.e. a hybrid port).

To explain the "priority tagged" and "vlan tagged": the single tag has two fields, "priority" and "VLAN ID". If VLAN ID is 0, the frame is handled as if it was tagless from the point of view of VLANs, but the priority field is taken into account. Hence the "untagged-and-priority-tagged" name (which should actually read "untagged-or-priority-only-tagged").

RouterOS has one additional confusing feature different from all other vendors' products, which is that tagless frames may exist not only on the wire but also "inside" the bridge. On normal switches, frames can only be tagged on ingress and untagged on egress; RouterOS allows also the reverse. So if the VLAN ID of a tagged ingress frame matches the pvid parameter of the bridge itself, that frame gets untagged on ingress; vice versa, tagless frames are tagged with the pvid of the bridge on egress through the port. And if the pvid of the /interface bridge port row matches the pvid of the bridge, the frames remain tagless at both ingress and egress through that port.

anav · Tue Nov 20, 2018 1:18 am

Progress is slow, but thats okay.
Lets look at points where I lose the bubble.

So if we get back to how RouterOS configures that: if you want a port to be an "access-only" one for a given VLAN, that VLAN ID must be the only one permitted on it, and it must be permitted in untagged mode (i.e. the port name must be on the untagged list of that VLAN), and that VLAN ID must be set as pvid under /interface bridge port.

Q1. I understand the bridgeport aspect of assigning ingress-filtering and pvid:unique, and I understand that there will be probably TWO /interface bridge vlan rules (if there are any other vlans) so that there is at least one /interface bridge vlan rule where that unqique pvid is untagged. Is that what you mean??? If not please clarify

Q2. What would be the functional difference between.
a. setting a bridgeport to PVID: unique but not selecting ingress-filtering ( I dont know

)???????????
b. setting a bridgeport to PVID: unique but selecting ingress-filtering ( I think this shuts down any other vlans from ingresss or egressing the port and add unique tags to untagged packets and strips on egress)

Q3. Do you ever actually enter an untagged bridgeport in an /interface bridge vlan rule??? (ex. and why)??

sindy · Tue Nov 20, 2018 11:01 pm

Q1. I understand the bridgeport aspect of assigning ingress-filtering and pvid:unique, and I understand that there will be probably TWO /interface bridge vlan rules (if there are any other vlans) so that there is at least one /interface bridge vlan rule where that unqique pvid is untagged. Is that what you mean??? If not please clarify

I cannot clarify as I don't understand the question.

Q2. What would be the functional difference between.
a. setting a bridgeport to PVID: unique but not selecting ingress-filtering ( I dont know )???????????
b. setting a bridgeport to PVID: unique but selecting ingress-filtering ( I think this shuts down any other vlans from ingresss or egressing the port and add unique tags to untagged packets and strips on egress)

If you don't activate ingress-filtering on a bridge port, all ingress frames will get to the bridge, both those which come already tagged from the wire and those which get tagged with the PVID on ingress. Ingress filtering does not affect tagging (except if you activate ingress filtering and set frame-types to admit-only-vlan-tagged, as in that case tagless frames won't be let in and thus won't be tagged on ingress).

Q3. Do you ever actually enter an untagged bridgeport in an /interface bridge vlan rule??? (ex. and why)??

Sure - doing so is necessary to tell the bridge that on that port, frames belonging to that VLAN internally have to be untagged on egress and tagged with that VLAN's ID on ingress.

anav · Thu Nov 22, 2018 8:34 pm

Okay got it,
a. Untagged for generic cases where the port is like an access port, in that incoming traffic needs to be tagged with PVID of that vlan on ingress and stripped on egress, but other vlan traffic can be passed through as well which is more like a hybrid port (no additional security).

Use ingress filtering if you also want to ensure.
- all frames received with a VLAN ID that don’t match the port’s VLAN egress list are discarded
---> When ingress filtering is enabled on a port, the VLAN IDs of incoming frames are compared to the port’s egress list. If the received VLAN ID does not match a VLAN ID on the port’s egress list, then the frame is dropped

case1
With that in mind, lets take ether2 which is being used to pvid some incoming untagged packets from an unmanaged switch with several devices, with vlan-id=33. The incoming traffic also contains vlan traffic99 from a particular device.

the admin inadvertently makes the following rule.
/interface bridge vlan
add bridge=homebridge tagged=homebridge, ether2 vlan-id=33
/bridge port
add bridgeport=eth2 pvid=33
(In this case, all traffic without vlan tags are tagged with vlan33 and enter the bridge and are sent to other ports/wlans that are identified with vlan33. Return traffic is stripped of vlan33 on egress. Other VLANS that may be on this traffic are passed to the bridge???? If not what happens to vlan99 traffic and why???

case2
We now invoke ingress filtering.
/interface bridge vlan
add bridge=homebridge tagged=homebridge, ether2 vlan-id=33
/bridge port
add bridgeport=eth2 pvid=33 ingress-flltering=yes
(In this case, there is no change to the untagged packets behaviour, however, the ingress filtering now examines the other non-pvid packets and says, hmmm this packet (had vlans with other ports that allow it BUT its not identified for egress and thus dropped??????,,,,,,,

Case3 (what will happen now)?
add bridge=homebridge tagged=homebridge, ether2 vlan-id=33,99
add bridgeport=eth2 pvid=33 ingress-flltering=yes

Will be vlan99 now be allowed???
by the way, I cannot find any situation to use untagged ports............

sindy · Thu Nov 22, 2018 9:45 pm

by the way, I cannot find any situation to use untagged ports............

For the fourth time: the untagged list in vlan-ids=X row under /interface bridge vlan must contain ports which you want to tag ingress frames with VLAN ID X and untag that VLAN's frames on egress. Specifying pvid=X for such ports in /interface bridge port is mandatory but not enough. In yet another words, the tagged and untagged lists describe the state (tagged/untagged) of the frames at the outer (wire) side of the ports on the list for vlan-ids=X. So whenever you specify /interface bridge port add bridge=some-bridge interface=Y pvid=X, interface Y must also be on the untagged list in /interface bridge vlan add vlan-ids=X.

So:
case 1 will not work for VLAN ID 33 because you haven't fulfilled the requirement above (it may tag frames on ingress but not untag them on egress or vice versa, as said I don't understand what exactly made gents in Riga make the configuration this complex).
case 2 will not work at least for the same reason why case 1 will not work, but there is one more point. ingress-filtering=yes on a port not only checks whether already tagged frames bear an ID of a VLAN permitted on the port but it also checks whether the only tagless, only tagged or both types of frames are permitted on ingress using the frame-types parameter. As you haven't specified the value of this parameter in your example, the result cannot be predicted.
case 3 will not work for VLAN ID 33 for the same reason like case 1.

anav · Sun Nov 25, 2018 6:12 pm

Hi Sindy, so
Case1 Should look like
/interface bridge vlan
add bridge=homebridge tagged=homebridge, ether2 vlan-ids=33
add bridge=homebridge tagged=homebridge vlan-ids=33
/bridge port
add bridgeport=eth2 pvid=33

In this case vlan99 would get passed on ingress on eth2 through because we have not imposed ingress filtering??
If so, if no other bridgeports are identified with v99 they would then be discarded (not sent anywhere).
I still think this fails because the packets will not be tagged on ingress if we dont include ingress filtering??

Case2, was merely an extension of ingress filtering and I was supposing that now any other vlan besides 33 would not be permitted to ingress on eth2 and in this case vlan99 would surely not be permitted. (also with ingress filtering on, we can be sure now that untagged packets will get tagged with vlan33??)
/bridge port
add bridgeport=eth2 pvid=33 ingress-filtering=yes

Case 3, was a question of whether we could tag all untagged packets coming in on eth2 and respect vlan packets and specifically only vlan99 as well.
Not sure if this is possible??
/interface bridge vlan
add bridge=homebridge tagged=homebridge, ether2 vlan-ids=33,99
add bridge=homebridge tagged=homebridge vlan-ids=33,
/bridge port
add bridgeport=eth2 pvid=33 ingress-filtering=yes

Jotne · Sun Nov 25, 2018 7:46 pm

/interface bridge vlan
add bridge=homebridge tagged=homebridge, ether2 vlan-ids=33
add bridge=homebridge tagged=homebridge vlan-ids=33
/bridge port
add bridgeport=eth2 pvid=33
we can be sure now that untagged packets will get tagged with vlan33??)

I would say that in this config untagged ingress packet would get tagged with VLAN 33 on ether2
But you would not get VLAN 33 untagged out on ether2, so this is a half config.
Bridge should be told that it should remove tags for VLAN 33 egress like this:

/interface bridge vlan
add bridge=homebridge tagged=homebridge, ether2 vlan-ids=33
add bridge=homebridge tagged=homebridge untagged=eth2 vlan-ids=33
/bridge port
add bridgeport=eth2 pvid=33
 we can be sure now that untagged packets will get tagged with vlan33??

anav · Sun Nov 25, 2018 10:09 pm

Appreciate the feedback Jotne,
I think I understand my confusion a bit better.
I was assuming that my not including an interface in at least one other bridge vlan rule that contained the applicable VLAN, was GOOD ENOUGH!
I assumed the router assumed the ethport was thus untagged since it was not identified in the second rule as being tagged but the applicable VLAN was in the rule.

But what you and Sindy have been saying all along is its a two part answer.
1. need separate rule
2. plus need to state in that rule that specifically the ethport has to be entered as untagged (and it is not implicitly done by the router by omission).

What lead me astray was seeing the router/bridge automatically assigning un-tagged interfaces BUT I just realized that was ONLY for vlan1. Must be a special case.

Thus to get things right it should be........

/interface bridge vlan
add bridge=homebridge tagged=homebridge, ether2 vlan-ids=33
add bridge=homebridge tagged=homebridge untagged=eth2 vlan-ids=33
/bridge port
add bridgeport=eth2 pvid=33 ingress-filtering=yes

I had assumed that the ingress filtering also stripped the packets upon egress but what it seem is that its the untagged command that does this?

sindy · Sun Nov 25, 2018 10:56 pm

Some bridge ports (such as wireless interfaces with vlan tagging activated) do show up automatically in the lists.

At least in 6.43.4, you cannot use several lines with the same vlan-ids value under /interface bridge vlan. So you have to place both the untagged and tagged list to the same line for vlan-ids=33.

Jotne · Sun Nov 25, 2018 11:19 pm

I was thinking of making a diagram that shows ingress/egress packet and how and where they do get tagged.

But in short:
pvid controls what vlan should be added on incoming packed. (ingress)
tagged pakkets goes inn without anything done with them

Bridge VLAN handles outging packed (egress).
What packed should go to what port tagged or without tag.

But when you enable ingress filtering the Bridge VLAN are also used to control what packed should be allowed tagged inn.

This is important to prevent loop due to that spanning tree/bpdu packets always goes untagged, even on ports with only tagged packets.
By tagging packet that do contains spanning tree/bpdu this information gets lost and loop can occur since this information are lost.

sindy · Mon Nov 26, 2018 12:24 am

Are you serious you have seen BPDUs to get tagged on ingress with vlan-filtering=yes?

anav · Mon Nov 26, 2018 1:55 am

I was thinking of making a diagram that shows ingress/egress packet and how and where they do get tagged.

But in short:
pvid controls what vlan should be added on incoming packed. (ingress)
tagged pakkets goes inn without anything done with them

Bridge VLAN handles outging packed (egress).
What packed should go to what port tagged or without tag.

But when you enable ingress filtering the Bridge VLAN are also used to control what packed should be allowed tagged inn.

This is important to prevent loop due to that spanning tree/bpdu packets always goes untagged, even on ports with only tagged packets.
By tagging packet that do contains spanning tree/bpdu this information gets lost and loop can occur since this information are lost.

Actually what I interpreted was that ingress-filtering had two functions
a. only allow vlans specifically allocated to that port
b. only allow vlans that have other available ports to travel too.
Meaning if there were packets ingressing on an interface with vlantags of 33,99,101 and no other port on the bridge identified vlan 99
and the /interface bridge vlan line looked like tagged=bridge, interfacexx, vlan-ids=33,99 then
101 would trip on subrule a.
99 would trip on subrule b.

However I think I may be wrong, again!
The definitions found yield:
"Enabling the ingress-filter ['set port ingress-filter <port_string> enable'] prevents a packet from being accepted for port ingress if the packet's assigned VLAN would not be permitted to egress the same port"

If the above quote is the right way to interpret, then how does the router/bridge handle vlan99 (how does the router know if interfacexx allows or not 99 on egress)?

anav · Mon Nov 26, 2018 2:02 am

Some bridge ports (such as wireless interfaces with vlan tagging activated) do show up automatically in the lists.

At least in 6.43.4, you cannot use several lines with the same vlan-ids value under /interface bridge vlan. So you have to place both the untagged and tagged list to the same line for vlan-ids=33.

Thus it should be................
/interface bridge vlan
tagged=bridge,eth2 untagged=eth2 vlan-ids=33
????????????????????????

In another case, sfp1 is trunk to another switch, and eth4 is port for traffic - both on bridge1
/interface bridge port
...bridge1 interface=sfp1
...bridge1 interface=ether4 pvid=357 ingress-filtering=yes
and
/interface bridge vlan
add bridge=bridge1 tagged=bridge1,sfp1,eth4 untagged=eth4 vlan-ids=357

(before I had
/interface bridge vlan
add bridge=bridge1 tagged=bridge1,sfp1, vlan-ids=357
add bridge=bridge1 tagged=bridge1,eth4 vlan-ids=357)

sindy · Mon Nov 26, 2018 5:19 am

Almost there, just remove the ports on untagged list from the tagged list, as a port cannot be on both lists on the same vlan-ids line.

So

bridge=bridge tagged=bridge,eth2 untagged=eth2 vlan-ids=33
bridge=bridge1 tagged=bridge1,sfp1,eth4 untagged=eth4 vlan-ids=357

In the first case, at L2 you can only access devices connected to ether2/VLAN 33 from Mikrotik itself (using /interface vlan vlan-id=33 interface=bridge) because only a single port is a member of the bridge, so Mikrotik must be routing their traffic if they should get anywhere else, is that what you want?

Jotne · Mon Nov 26, 2018 7:56 am

bridge=bridge tagged=bridge,eth2 untagged=eth2 vlan-ids=33
bridge=bridge1 tagged=bridge1,sfp1,eth4 untagged=eth4 vlan-ids=357

Are you 100% sure abut this?
I would not have used both tagged and untagged on same port eth2, eth4
Packed should pass trough (ingress) as tagged, no pvid or not blocked by ingress filter.
They should go out (egress) tagged or untagged controlled by Birdge VLAN setting.

Edit
When doing a test setting up like this.
Bridge-test (vlan filter on, pvid=1)
vlan 40 connected to Bridge-test
Port 5 connected to Bridge-test using pvid=1

Then I try in Bridge VLAN to add Bridge-test as tagged, port 5 as tagged and port 5 as untagged, I do get:
Couldn't change Bridge VLAN <40> - interface cannot be in tagged and untagged at the same time (6)

mkx · Mon Nov 26, 2018 8:26 am

Actually what I interpreted was that ingress-filtering had two functions
a. only allow vlans specifically allocated to that port
b. only allow vlans that have other available ports to travel too.
Meaning if there were packets ingressing on an interface with vlantags of 33,99,101 and no other port on the bridge identified vlan 99
and the /interface bridge vlan line looked like tagged=bridge, interfacexx, vlan-ids=33,99 then
101 would trip on subrule a.
99 would trip on subrule b.

However I think I may be wrong, again!
The definitions found yield:
"Enabling the ingress-filter ['set port ingress-filter <port_string> enable'] prevents a packet from being accepted for port ingress if the packet's assigned VLAN would not be permitted to egress the same port"

If the above quote is the right way to interpret, then how does the router/bridge handle vlan99 (how does the router know if interfacexx allows or not 99 on egress)?

Ingress filtering just rejects ingress packet if the VLAN tag is not right for that particular interface. Egress filtering rejects to transmit packet (which is already present on bridge) on egress if the VLAN tag is not right for that particular interface. Egress configuration comes from

/interface bridge vlan
add bridge=bridge tagged=bridge untagged=ether1 vlan-ids=99

(ether1 could be tagged as well, it doesn't affect the selection logic).

So in the example above, router would follow these steps (after received packet is tagged with pvid if it arrives at port untagged and port has pvid set):

router consults VLAN ID list for particular port. Finds VLAN ID 99 as allowed VLAN and accepts ingress packet;
bridge now holds the said packet in its buffer and consults ARP table to find egress port with learned combination of station MAC address and VLAN ID (or only MAC address if learn=no) for destination address of packet. If one is found, packet gets transmitted through that port only;
as bridge did not find any particular egress port, it will "flood" with it all ports which are members of VLAN=99 (either tagged or untagged). Minus the ingress port of that packet. As there are no other ports with same VLAN ID other than ingress, packet is not transited anywhere.
Note that it doesn't to be ethernet port (which would have been HW offloaded if that worked with VLANs), it can be some other type of port (wlan, any kind of tunnel, LTE, ...);
bridge discards the packet.

.
If, however, a packet tagged with e.g. VLAN ID=42 arrived at port ether1, it would get rejected in the step #1.

If ingress-filtering was set to off, then all the steps would be performed (i.e. packet would not get rejected in the step #1). The reply, though, would not be transmitted via ether1 as steps #2 and #3 would not allow packet to leave through ether1. Unless independent learning was disabled (learn=no), in which case step #2 would probably succeed (I'm not sure about this though).

So to really enforce VLAN separation, one has to enable ingresss filtering and force independent learning.

anav · Mon Nov 26, 2018 2:22 pm

Super, thanks to all three of you for your input.
Hopefully I can now give reasonable advice to others, I think I am no longer a pretzel.

Who is online