Greetings. I have a ccr 2216 with which I can implement hw offloading in many of the functions, but I can’t find a way to have it in this scenario:
I have 2 uplink interfaces. One segment which in this example will be 192.168.1.0/24 which will use uplink 1 (default route 0.0.0.0/0 gateway=uplink1) and then I have 192.168.2.0/24 which will use trunk number 2. So to accomplish this, I create a rule in mangle in which the 192.168.2.0/24 segment will use uplink2 through a routing mark. But since I’m using mangle, I can’t use l3hw. What is the correct way to use l3hw with 2 different defaults routes?
If I understand correctly, you want to choose a gateway based on the source IP address, right?
Firewall Mangle rules do not work with l3hw since hardware-routed packets do not enter the CPU, and therefore, the Firewall. The best solution would be creating a separate VRF table, but, unfortunately, l3hw-VRF support is not implemented yet
As a workaround, you can create a switch ACL rule to redirect the 192.168.2.0/24 traffic to the CPU while leaving l3hw enabled for the rest:
That’s how it is. Exactly this. It would be perfect if I could create a default route only for one source and not for the entire network in general, if I am not forced to use mangle and make my cpu go up pointlessly.
This means that half of the network has hw offload and the other half does not, right? Isn’t there a way for the whole network to have it? I think my requirement is extremely simple, it seems very strange to me that mikrotik does not have something for it in hwoffload
Mikrotik is limited by the capabilities of the switch chip and by developers’ capacity. If a given switch chip cannot take source address into account in its hardware routing tables, your application scenario will never be available on the Routerboard models using that switch chip.
@raimondsp’s post suggests that this is the case, but that the switch chip can take in-interface rather than source address into account when choosing a hardware routing table. But here the other limit comes into account, developers’ capacity and the associated need to prioritize development tasks. Many people complain about missing BGP functionalities in ROS 7, you seem to be the only one so far to ask for advanced L3HW functionalities.
I agree, this is a common scenario and should definitely be developed if possible. vrf support in hardware would be great as it would kill two birds with one stone.
I understand that some people who read me here are fans of the brand, so please try not to let my comment offend you.
Hwoffload in mikrotik is today the equivalent of having a switch in layer3, correct? You can’t route more than one path, you can’t mark traffic, you can’t have a firewall, you can’t queue. How is a Layer 3 switch different?
Switch chips used in CRS2x16 provide VRF support. We will implement VRF HW offloading eventually, but it is not a trivial task. Besides, other features are pending, so task prioritization is also a case. For instance, we released L3HW IPv6 functionality last week.
While you cannot offload the second VRF table (yet), FastTrack HW Offloading is still an option.
Half of the network gets fully routed by the hardware.
The remaining goes to the CPU by default; then the fastest FastTrack connections get HW-offloaded.
CCR2x16 CPU is very powerful and can provide decent routing performance, especially in combinations with hardware-accelerated FastTrack processing.
