Bridge firewall

silviub · Sat Jun 15, 2024 9:37 am

Hello,

I am trying to limit the amount of broadcast I'm sending out. The problem is that the bridge firewall rules don't seem to work, or I'm doing something wrong:
After failing to limit the amount of broadcast, I said that I want to filter out ALL traffic from a certain MAC address. I've set the following rule:

add action=drop chain=forward disabled=yes log=yes log-prefix="DROP Test " src-mac-address=BC:24:11:D1:63:67/FF:FF:FF:FF:FF:FF

This should, at least in theory, drop all traffic coming from MAC address BC:24:11:D1:63:67, right?

Well, I'm pinging from the machine with that MAC address and it goes through without any issues. What's going on?

jvanhambelgium · Sat Jun 15, 2024 12:26 pm

Limit the amount of broadcast you are sending out ? Where to ?
Broadcasts will not pass the boundaries of the segment you are in anway.
What problems are you encountering ? What product-type are you using?

Without a detailed schematic (container interfaces/IP's etc) it is impossible to even comment on your issue.
The full config export is also helpful and will trigger more experts to even look at your post...without any of this...not going to happen!

People have to understand that RouterOS is extremely flexible and quite complex, so the problems/behaviours you describe can have dozens of reasons.

silviub · Sat Jun 15, 2024 1:31 pm

Limit the amount of broadcast you are sending out ? Where to ?
Broadcasts will not pass the boundaries of the segment you are in anway.
What problems are you encountering ? What product-type are you using?

Without a detailed schematic (container interfaces/IP's etc) it is impossible to even comment on your issue.
The full config export is also helpful and will trigger more experts to even look at your post...without any of this...not going to happen!

People have to understand that RouterOS is extremely flexible and quite complex, so the problems/behaviours you describe can have dozens of reasons.

I want to limit the broadcast sent out on a certain bridge port. That should be simple enough, but I'm missing something.
The setup's simple: one bridge with all the ports connected to it, connected to an upstream switch that has broadcast storm enabled - cutting me off when I exceed a certain broadcast limit. So I need to somehow limit the broadcast the bridge is forwarding to the upstream switch.
If you really thing a schematic / config export will help, I'll do that, but as I said, one bridge, all the ports in the bridge, need to limit the broadcast going out on a certain port....

jvanhambelgium · Sat Jun 15, 2024 1:42 pm

What product are you using ?
I'm pretty sure hardware-offloaded stuff/config will not always behave as simple as you might think. Which then can explain what you are seeing.

I've think I remember reading somewhere that you can only perform MAC-filtering in the forward-chain when HW Offloading is DISABLED, so the CPU can see the frames...

silviub · Sat Jun 15, 2024 1:46 pm

What product are you using ?
I'm pretty sure hardware-offloaded stuff/config will not always behave as simple as you might think. Which then can explain what you are seeing.

I've think I remember reading somewhere that you can only perform MAC-filtering in the forward-chain when HW Offloading is DISABLED, so the CPU can see the frames...

I forgot to specify the switch: It's a CRS317-1G-16S+ and yes, HW offloading is enabled (by default).
If that's the case, I guess I can create a switch rule to copy all the broadcast to the CPU and then create bridge rules?

It's hard to believe though that Mikrotik is making broadcast storm control so difficult, to be honest. In Cisco / Juniper / almost any other vendor, you just enable storm control and set a pps/bps limit...?

mkx · Sat Jun 15, 2024 1:51 pm

I've think I remember reading somewhere that you can only perform MAC-filtering in the forward-chain when HW Offloading is DISABLED, so the CPU can see the frames...

Indeed, none of advanced bridge functionality is HW offloaded (AFAIK on any of MT devices). So at least the port in question has to be exempt from being HW offloaded (but that may mean reduced throughput if device's CPU is one of the weaker ones).

Depending on actual "bridge" device model it may be possible to filter those broadcasts using switch ACLs.

[edit] CRS317 should do ACLs just fine ... and disabling HW offload would severely reduce throughput

mkx · Sat Jun 15, 2024 1:57 pm

If that's the case, I guess I can create a switch rule to copy all the broadcast to the CPU and then create bridge rules?

copying frames to CPU port doesn't directly affect normal frame paths ... so dropping some of copied frames with bridge firewall rules wouldn't prevent them from being forwarded by switch chip as per normal forwarding rules. Redirecting frames via switch CPU does and disabling port HW offload is exactly that: redirecting frames via CPU.

silviub · Sat Jun 15, 2024 1:59 pm

I've think I remember reading somewhere that you can only perform MAC-filtering in the forward-chain when HW Offloading is DISABLED, so the CPU can see the frames...
Indeed, none of advanced bridge functionality is HW offloaded (AFAIK on any of MT devices). So at least the port in question has to be exempt from being HW offloaded (but that may mean reduced throughput if device's CPU is one of the weaker ones).

Depending on actual "bridge" device model it may be possible to filter those broadcasts using switch ACLs.

[edit] CRS317 should do ACLs just fine ... and disabling HW offload would severely reduce throughput

This means that I would have to filter the broadcast coming into the bridge, rather than the broadcast going out on a specific interface, if I get it right: https://help.mikrotik.com/docs/display/ ... Rules(ACL)

ports (ports)	Matching ports on which will the rule apply on received traffic.

Still, I tried with the following rule:

add comment="Limit broadcast" dst-mac-address=FF:FF:FF:FF:FF:FF/FF:FF:FF:FF:FF:FF ports=P1\
    rate=500.0kbps switch=switch1 vlan-id=3

But it doesn't seem to do anything. Pinging from P1 to P2 on the broadcast address, using

ping -b 10.10.10.254 -f -v

goes through just fine.

If that's the case, I guess I can create a switch rule to copy all the broadcast to the CPU and then create bridge rules?

copying feames to CPU port doesn't directly affect normal frame paths ... so dropping some of copied frames with bridge firewall rules wouldn't prevent them from being forwarded by switch chip as per normal forwarding rules. Redirecting frames via switch CPU does and disabling port HW offload is exactly that: redirecting frames via CPU.

Also tried to use:

add comment="Limit broadcast" dst-mac-address=FF:FF:FF:FF:FF:FF/FF:FF:FF:FF:FF:FF ports=\
    P1 rate=500.0kbps redirect-to-cpu=yes switch=switch1 vlan-id=3

And then set a bridge rule. From what I understood, this would send all the packets over the specified rate to the CPU, which would block them, due to the bridge firewall being set to drop all broadcast. Pinging the broadcast address still works without any packet loss

silviub · Sat Jun 15, 2024 2:37 pm

I might have solved it - still testing now.
I added a switch rule:

/interface ethernet switch rule
add comment="Limit broadcast" dst-mac-address=FF:FF:FF:FF:FF:FF/FF:FF:FF:FF:FF:FF new-dst-ports="" \
    ports=P1 rate=2.0Mbps switch=switch1 vlan-id=3

This is limiting the ingress broadcast (without disabling hw offload) to 2M per port (which is not what I want, but I can live with it). I would love to be able to limit broadcast going OUT on a specific interface... The reason for this is because the switch I'm connecting to has a 3Mbps broadcast limit so if I'd have 2/3[...] ports each shooting 2Mbps, I would be way over the limit.
Any idea if / how can I achieve limiting the egress broadcast on a specific interface?

[edit]
I might have understood this wrong. Is the rate limit on a per rule basis or on a per port basis?
I mean, if I've got the following rule:

/interface ethernet switch rule
add comment="Limit broadcast" dst-mac-address=FF:FF:FF:FF:FF:FF/FF:FF:FF:FF:FF:FF new-dst-ports="" \
    ports=P1,P2,P3,P4,P5 rate=2.0Mbps switch=switch1 vlan-id=3

Does this limit the traffic to broadcast on ALL 5 ports to 2Mbps or does it put a limit of 2Mbps per port => 10 Mbps in total? I don't get it from the documentation

(https://help.mikrotik.com/docs/display/ ... Rules(ACL))
Thank you!

silviub · Sat Jun 15, 2024 2:55 pm

Okay, might have hit a bug:

/interface ethernet switch rule
add comment="Limit broadcast" dst-mac-address=FF:FF:FF:FF:FF:FF/FF:FF:FF:FF:FF:FF new-dst-ports="" \
    ports=P1 rate=2.0Mbps switch=switch1 vlan-id=3

stops ALL the traffic with dst-mac-address=FF:FF:FF:FF:FF:FF, not only after 2Mbps rate. Even if I increase the rate to 1Gbps, I still can't ping the broadcast address. Disabling/removing the rule allows me to ping the broadcast address. Any clue why?

mkx · Sat Jun 15, 2024 3:28 pm

Try to remove (unset) the new-dst-ports property. Often setting some property to empty value means something different than not setting it at all. This particular one is used to redirect traffic which is matched to a different port ... and having it set to empty value might mean that traffic is redirected to void.

silviub · Sat Jun 15, 2024 3:35 pm

Try to remove (unset) the new-dst-ports property. Often setting some property to empty value means something different than not setting it at all. This particular one is used to redirect traffic which is matched to a different port ... and having it set to empty value might mean that traffic is redirected to void.

new-dst-ports (can be used to drop packets)

So I was under the impression that my rule would mean: from src-mac to dst-mac, rate > 2M, change dst port to none => drop.
I removed the change-dst-port and, for now, it seems to be fine.

Any clue about how the rate is being applied? Is it on a per rule basis, or on a per interface basis? If I set the rate to 2M does it mean that ALL the interfaces in that group are limited to 2M or that each interface in the rule is limited to 2M?

Thank you!

mkx · Sat Jun 15, 2024 4:04 pm

Any clue about how the rate is being applied?

I've no idea. I guess you'll have to check.

silviub · Sat Jun 15, 2024 5:07 pm

Just for whoever's interested in this info: Switch ACL rate limits seem to apply on a per rule basis, no matter how many ports you've got in that rule.
I have a rule limiting dst-mac FF:FF:FF:FF:FF:FF to a rate of 2.5Mbps, and it's applied on the traffic coming from ALL the interfaces in the rule (I've got 3 interfaces in that rule, the total traffic coming in from those 3 interfaces, going to FF:FF:FF:FF:FF:FF is not going to exceed 2.5Mbps)

jaclaz · Sat Jun 15, 2024 7:09 pm

I have a rule ...

Can you post the export of your actual (final) rule?

silviub · Sat Jun 15, 2024 7:16 pm

I have a rule ...
Can you post the export of your actual (final) rule?

Sure, here's the final rule:

/interface ethernet switch rule
add comment="Limit broadcast" dst-mac-address=FF:FF:FF:FF:FF:FF/FF:FF:FF:FF:FF:FF ports=P1,P2,P3 rate=2.5Mbps switch=switch1 vlan-id=3

Bridge firewall [SOLVED]

Bridge firewall

Re: Bridge firewall

Re: Bridge firewall

Re: Bridge firewall

Re: Bridge firewall

Re: Bridge firewall

Re: Bridge firewall

Re: Bridge firewall

Re: Bridge firewall

Re: Bridge firewall

Re: Bridge firewall

Re: Bridge firewall

Re: Bridge firewall

Re: Bridge firewall [SOLVED]

Re: Bridge firewall

Re: Bridge firewall