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?
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…
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…?
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
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.
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
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:
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?
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.
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?
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)
