And it doesn’t work like that. One CPU core maxes out at 100% when I do iperf3 -R -c 172.16.98.1 (download) on 192.168.12.2.
As soon as I change the network to /24:
/ip address set [find network=192.168.12.2] address=192.168.12.1/24 network=192.168.12.0
HW offloading kicks in immediately (CPU usage drops to ~0%).
What’s up with that ?
What law of nature prevents me from doing wirespeed point-to-point routing ?
Maybe there is some workaround allowing me to route IP addresses one by one to different interfaces like that:
Here’s general idea of how netmask and network address works: sender needs to determine if target device is directly accessible via certain L2 interface. So it takes destination IP address, applies own network mask to it. Then it compares result to network address. If these two match, target can be directly accessed.
Examples:
address=192.168.88.1/24 network=192.168.88.0
dst-address=192.168.88.200 … and-ed with 255.255.255.0 (a /24 subnet mask) gives 192.168.88.0
which matches network address
Another example:
dst-address=192.168.89.1 … and-ed with /24 gives 192.168.89.0
which doesn’t match network address, hence use of a gateway is necessary
.
2. address=192.168.12.1/32 network=192.168.12.2
dst-address=192.168.12.2 … and-ed with /32 gives 192.168.12.2
which matches network address and thus dst can be directly connected
This is a typical PtP case … interface address and network address (i.e. the PtP link partner’s address) can be completely distinct
To the OP’s issue: what seems to be a bit misplaced is proxy-arp setting on PtP interface …
I can’t explain why changing subnet mask to /24 enables L3HW but I guess that proxy-arp needs CPU involvement this way or another. Another possibility is that L3HW (as currently implemented) doesn’t like /31 or /32 addressing (it’s a well known fact that MT doesn’t support /31, it coukd be that /32 is missing in L3HW - for now).
mkx, thanks, that concept you described explains how p2p addresses actually work.
An update to my original problem:
On CRS309-1G-8S+, RouterOS 7.7rc3, and with upgraded FIRMWARE, p2p addresses + l3 hardware offloading works as expected.
Maybe if I bothered to upgrade firmware on my CRS326 unit, it would have worked too, but now I’m focused on devices with higher-end chips (CRS309-1G-8S+, CRS317-1G-16S+) and lost interest in CRS326