Filter rules to isolate DHCP traffic between specific bridged interfaces

RouterOS General
1

Hello,
I have been trying unsuccessfully to use filter rules to isolate DHCP traffic between specific bridged interfaces.
The context is the following: I live on a campus where internet is provided to me. I have a few RJ45 jacks that I can use for wired connections to the internet, but these are FastEthernet which is not great for large transfers between my devices. So I got a CRS326-24G-2S+RM that runs RouterOS, on which I connect all my devices, and which I also connect to one of the campus jacks.
The problem is that I am now limited by the fact that all my devices share the same relatively slow link to the gateway.
To address that, what I would like to do is group the interfaces on my switch in pairs such that each pair contains one interface connected to the gateway and one connected to a device, and use filter rule to ensure that the traffic from each device to the gateway goes exclusively through the other interface in the pair. I have been trying to achieve that by using filter rules on DHCP traffic, which has not been working. My hope was to avoid using VLANs with inter-VLAN routing, which I saw as an alternative.
Specifically, starting from the default switch configuration, I ran the following commands:

/interface bridge filter
:for n from=1 to=11 do={
    :local iface1 ("ether" . (2 * $n - 1))
    :local iface2 ("ether" . (2 * $n))

    add chain=forward mac-protocol=ip in-interface=$iface1 out-interface=$iface2 ip-protocol=udp dst-port=67-68 action=accept
    add chain=forward mac-protocol=ip in-interface=$iface2 out-interface=$iface1 ip-protocol=udp dst-port=67-68 action=accept
}

add chain=forward mac-protocol=ip in-interface=ether23 out-interface=sfp-sfpplus1 ip-protocol=udp dst-port=67-68 action=accept
add chain=forward mac-protocol=ip in-interface=sfp-sfpplus1 out-interface=ether23 ip-protocol=udp dst-port=67-68 action=accept

add chain=forward mac-protocol=ip in-interface=ether24 out-interface=sfp-sfpplus2 ip-protocol=udp dst-port=67-68 action=accept
add chain=forward mac-protocol=ip in-interface=sfp-sfpplus2 out-interface=ether24 ip-protocol=udp dst-port=67-68 action=accept

add chain=forward mac-protocol=ip ip-protocol=udp dst-port=67-68 action=drop

/interface bridge settings
set use-ip-firewall=yes

Now if I plug a device in

ether4

and use

ether1

to connect to the gateway, with no other interface in use, I would expect that my device does not get assigned an ip address, but it does.
What am I missing?

2

I’m afraid that what follows is just an anwswer to your last question, not a solution.

The bridge filter only sees frames that pass through the CPU port of the switch chip. CRS326 is designed as a switch device, so by default, the switch chip forwards frames between Ethernet ports on its own, without involving the CPU. You can change that by changing the hw parameter of the /interface bridge port rows for the “uplink” ports to yes, forcing traffic between any uplink port and any downlink one through the CPU, but if the CPU does not become a throughput bottleneck in this case, the link between the CPU and the switch chip will, as it only has 1.3 Gbps - see https://cdn.mikrotik.com/web-assets/product_files/CRS326-24G-2SRM_220921.png .

So a better way (but still not a solution) would be to use the switch chip “port isolation” feature. Assuming odd ports are uplink ones and even ones are downlink ones, you could use the following instead of bridge filter rules:
/interface ethernet switch port-isolation set ether1 forwarding-override=ether2
/interface ethernet switch port-isolation set ether2 forwarding-override=ether1,ether4,ether6,ether8,…,ether22, ether24,switch1-cpu

However, the actual show stopper is that even with these rules in place, the switch keeps behaving as a switch, so it learns the associations between MAC addresses and ports. So any frame that comes from the gateway, which has a single MAC address, will update the MAC->port table with the port through which it has arrived, and until another frame from the gateway arrives through a different port, the switch will choose that last port learned for egress of all frames for the MAC address of the gateway. But since the port isolation rules will deny them from being forwarded through that port unless they come from the “proper” ingress one, a lot of frames will get lost if more than one device attempts to talk through the gateway.

If each uplink port was in its own VLAN, it wouldn’t matter that frames from the MAC address of the gateway would be coming via multiple ports as each VLAN has its own MAC->port mapping table. But the CRS would have to act as a router with NAT in order that all the downlink ports could share the same VLAN, and whilst the CS236-24G-2S+ can do routing in hardware, it can only do NAT in software. So the CPU-switch chip interconnection lane and the CPU power would be back in the game, leaving aside the fact that it would be complicated to make the router choose the WAN (uplink) VLAN based on the ingress port on the LAN (downlink) side.

Check with the campus admin whether it would be possible to set up a bond (team) of multiple ports on the campus side. A bonded group of ports is treated as a single one from the point of view of MAC address learning and use, so depending on the structure of the traffic, the aggregated throughput might be almost the sum of the individual ports’ bandwidths (in reality, it will always be lower).

It would suffice to set up bonding only on your end if the switch chip could be told to use source MAC address alone to choose the egress link among the bonded ones, but that’s again not possible, at least in hardware.

3

If bonding is not an option,

A possible (but somewhat expensive) solution might be to get an RB5009, and have it connected to the multiple internet WAN ports.
With your devices on the CRS326 being on a natted private subnet.
Perhaps using the SFP+ port to connect the RB5009 to the CRS326

You have a few potential strategies to route via the WAN ports.
1:1 NAT configured so a device behind the CRS326 always uses same WAN port.
ECMP Apparently works ok, (I have not used it)
PCC Seems to work ok.

You might want to confirm what you want to do is within the bounds of the Campus network terms of service.
I have seen fairly strict enforcement on rogue AP’s attached to the network, where confiscation was at least part of the punishment.
(probably fair enough in that high-risk case)

4

I reached to my admin and they told me that bonding was not allowed, installing a router is probably not a option too. It looks like I’ll have to settle with sharing the uplink port between my devices. At least now I have a better understanding of my switch.