No as in “enabling use-ip-firewall in bridge settings will not change the fact that you cannot match on ports, IP protocol etc. in bridge filter if the ethernet protocol field (mac-protocol) is different from IPv4 or IPv6”:
[me@myTik] > system/resource/print
uptime: 1w4d21h5m46s
version: 7.9 (stable)
...
architecture-name: x86_64
board-name: CHR
platform: MikroTik
[me@myTik] > interface/bridge/filter/add chain=forward mac-protocol=vlan vlan-encap=ip src-address=10.0.0.3/24 action=log
failure: ip matchers are valid only when mac-protocol is set to ip
You can match IP traffic with mac-protocol=ip on a VLAN-aware bridge but you can’t select a specific VLAN as well. When VLAN-aware bridges were introduced Mikrotik should have separated the filter functionality so you can apply both a VLAN and another filter, rather than the limited either/or situation that exists.
Certainly on 6.48.7 the following works as expected:
/interface bridge
add admin-mac=D6:CA:6D:xx:xx:xx auto-mac=no ingress-filtering=yes name=bridge priority=0x4000 vlan-filtering=yes
…
/interface bridge filter
add action=log chain=forward mac-protocol=ip src-address=192.168.44.0/24
I’m not sure I’ve understood you well - I’ve tested on 7.9 and the rule only counts if I remove the mac-protocol=ip src-address=192.168.229.1/32 conditions:
everyone has his own preferred wording, which makes it sometimes challenging to grasp the entire concept being explained.
For that purpose I started making some drawings, they may help here as well (may watch Understanding Packet Flow in RouterOS v6 - YouTube first)
all flow options
hardware switching, dedicated switch chip, hardware offloaded switch (Flow of Hardware Offloaded Packet
From one port to another port, according to
/interface/bridge/vlan
3. still only on L2 but target (or source) port is connected to CPU not switch chip, so VLAN has to be allowed to flow through Bridge CPU Port, frames “bypass” the router (only if you set IP Firewall etc. to yes).
4. frames leave Bridge, in this case for inter-VLAN routing. To do so it has to leave the bridge through “Bridge Input”, via the Bridge CPU Port (so VLAN has to be allowed on it again).
Bridge input is a process that takes place when a packet is destined for the bridge interface. Most commonly this happens when you need to reach some services that are running on the bridge interface (e.g. a DHCP server) or you need to route traffic to other networks
I hope that all that is said and shown in the image is correct, conformation/feedback is welcome.
I’m still searching for a better option than only using plain images to visualise it.
Well, as @sindy describes, the bridge interface is a “two faced”. And the packet flow diagrams show a decapsulation step, so from the vlan-enabled=yes bridge’s POV, VLAN tagged traffic is in an input or output and can be matched by vlan-id=XX and mac-protocol=vlan (e.g. NOT =ip). Once traffic is forward it is necessarily untagged at that point for the router-side since it only deal with Layer3, so has to be matched with mac-protocol=ip in the bridge filter. And if “use IP firewall” is enabled, than these packets go directly to regular IPv4/IPv6 firewall, which understandably has no idea about vlan-id/port from the bridge as the traffic is fro the vlan interface as that point.
Agreed confusing, but still logical…since you do want some separation between Layer2 and Layer3 things. And RouterOS is somewhat constrained how Linux kernel & hw drivers handle these things – e.g. Linux is similarly confusing when it comes to a software bridge.
I have to disagree here. input, output, and forward in the context of the bridge filter are all L2 operations, so even during forward (between any two ports of the virtual switch other than the router-facing one), the VLAN tags remain in place.
Yes, this is indeed where things stop being logical, because use-ip-firewall=yes forces even L2-forwarded frames through layers of the packet processing stack that normally only handle the L3 packets. The whole purpose is to allow QoS handling of L2-forwarded frames using queues. And the list of the associated side effects is quite big - most notably, NAT behaves strangely.
@sindy, I could have said that better…your right L2 forward also goes through filter. I was more trying to make the point that things are easier if you do Layer2 filtering in bridge & do IP/Layer3 filtering in /ip[v6]/firewall. Once you want to violate the L2/L3 separation in bridge filter, your stuck reading the packet flow diagrams and hardware switch specs (and re-reading this post a few times )
Although I understand how to configure bridges correctly to ensure:
Zero performance problems
FastPath/FastForward
Hardware offloading
CPU usage close to 0% for inter-VLAN switching/routing
Can someone explain why MikroTik is the ONLY networking vendor that requires a bridge to accomplish the above? I’ve never seen this on Juniper, Arista, Huawei, or even Cumulus Linux (though yes, you can use a bridge or something called an IRB on those vendors).
I guess that MT tried to hide switch chip peculiarities and unify configuration interface across the hardware portfolio. And my opinion is that this is a really good move.
Whether the UI for configuring bridge is pleasant, self-descritptive, intuitive … it’s debatable and largely subjective, so let’s not go there.
I mean, all network vendors use different chips with different peculiarities. But NOBODY requires this weird bridge thing. Which itself is not unified across hardware.
It’s easy for me, sure. But thousands of MikroTik customers still configure in Cisco style and then assumes MikroTik is underperforming because no HW/Off. Or FastX features without bridge.
9/10 I’ve never seen people correctly configuring the bridge. Even those with MikroTik certifications.
I’m pretty sure I’d have helluva hard time configuring anything from cisco. So why does everybody assume that a monkey could configure MT while for Cisco a CCNA grade is needed?
Let’s accept the reality (which is that in MT we’ve got the bridge thingy) and move on …
Which ROS-driven hardware doesn’t support bridge thing? And if you’re about to bring up HW offload: which recent HW, where switching/bridging performance actually matters, doesn’t have HW offload available?
Don’t know about “CCNA” requirement. I never got certs, no problem working with multi-vendors including MikroTik, but MikroTik’s configuration philosophy is just broken, at least it could’ve been something like Juniper or FRR.
To be clear, I loathe Cisco configuration as well. Trashy shit.
Well, I asked about “recent HW”. Mikrotik introduced VLAN to bridge in 6.42 … when was it released? Somewhere around 2019? Dunno. Since then, new devices got HW offload and some old ones as well. The very old ones did not and I guess they never will, even though MT didn’tnEOL them it’s obvious MT is working on replacing them with newer hardware.
And, besides, as I wrote: if you put HW offload aside, all devices capable of running RIS 6.42 or later will have unified bridge. And that’s my point.
We can discuss the bridge concept back and forth (which is done in this very thread), you may loathe it … but when one wraps their head around it, it’s logical. And as I wrote: I don’t see it gone away anytime soon.
Translated PDF document is OK! Can be downloaded via that WeTransfer link (for a few days), but uploading such a 4MB PDF file as attachment seems not possible.
That is probably a good idea, take images, to jpegs which will reduce the doc in size and then maybe try to pdf it. ( open word doc and insert images )???
The only reason:
MT has using cheap consumer chips which has “slow shared bus” to the physical ports ( eth1, eth2, eth3, … ) and all the processing is done by the limited CPU. Other “large” vendors, they using ASIC chips for packet processing.
The difference in short:
“You trying to play a 3D game without a Graphics-card”
vs.
“You playing a game with a Graphics-card”
)