Dual Routes no longer in recent FW?

[DanJ]

I have updated a second RUTX11 to the latest fw; and it seems I can no longer set the failover policy priority like I used to?

On my first RUTX11 using RUTX_R_00.07.14.2
I have two interfaces; br-lan and vlan172; before I had failover policy so that br-lan used sim1, then wan.. and vlan172 used wan, then sim1. This permitted br-lan to use sim1 as the daefault route. and vlan172 to use wan as the default route… but in the latest firmwares; the interface has changed; and I can set the priority in the failover policies any more?

This has changed and is confusing me in RUTX_R_00.07.15; as now I can’t seem to get this working anymore.

[DanJ]

Ok I think I sorted this out. somehow the configuration changed.
It still confuses me how this operates.

If someone can confirm I have this understanding correct?

I have policy based routing enabled.. and my understanding is that default route for each internal network is defined here via the table ID (route table) depending on the source interface or traffic.. and the multiwan failover can be priorised; but doesn’t have an impact on PBR and route preference to the internet?

My rules are

root@RUTX11:~# ip rule
0:	from all lookup local
1:	from all to 10.8.0.0/24 iif br-lan lookup 1
1:	from all iif eth0.172 oif eth1 lookup 2
1:	from all iif br-lan lookup 4
1001:	from all iif eth1 lookup 1
1002:	from all iif qmimux0 lookup 2
1501:	from 10.10.20.54 lookup 1
2001:	from all fwmark 0x100/0x3f00 lookup 1
2002:	from all fwmark 0x200/0x3f00 lookup 2
2061:	from all fwmark 0x3d00/0x3f00 blackhole
2062:	from all fwmark 0x3e00/0x3f00 unreachable
3001:	from all fwmark 0x100/0x3f00 unreachable
3002:	from all fwmark 0x200/0x3f00 unreachable
32766:	from all lookup main
32767:	from all lookup default


root@RUTX11:~# ip route show table 1
default via 10.10.20.1 dev eth1 proto static src 10.10.20.54 metric 1
10.8.0.0/24 dev tun_c_ovpn proto kernel scope link src 10.8.0.38
10.10.20.0/24 dev eth1 proto static scope link src 10.10.20.54 metric 1
172.16.1.0/24 dev eth0.172 proto kernel scope link src 172.16.1.1
192.168.7.0/24 dev br-lan proto kernel scope link src 192.168.7.200


root@RUTX11:~# ip route show table 2
default dev qmimux0 proto static scope link src 100.95.167.42 metric 2
10.8.0.0/24 dev tun_c_ovpn proto kernel scope link src 10.8.0.38
100.95.167.42 dev qmimux0 proto static scope link src 100.95.167.42 metric 2
172.16.1.0/24 dev eth0.172 proto kernel scope link src 172.16.1.1
192.168.7.0/24 dev br-lan proto kernel scope link src 192.168.7.200

root@RUTX11:~# ip route show table 4
default dev qmimux0 proto static scope link metric 1

root@RUTX11:~# ip route show table main
default via 10.10.20.1 dev eth1 proto static src 10.10.20.54 metric 1
default dev qmimux0 proto static scope link src 100.95.167.42 metric 2
10.8.0.0/24 dev tun_c_ovpn proto kernel scope link src 10.8.0.38
10.10.20.0/24 dev eth1 proto static scope link src 10.10.20.54 metric 1
100.95.167.42 dev qmimux0 proto static scope link src 100.95.167.42 metric 2
172.16.1.0/24 dev eth0.172 proto kernel scope link src 172.16.1.1
192.168.7.0/24 dev br-lan proto kernel scope link src 192.168.7.200

This appears to be working now; br-lan internet traffic goes via 4G; and vlan172 traffic goes via WAN(10.10.20.1).
10.8.0.0/24 is my openvpn network.

What confuses me is vlan172 internet traffic is going via eth1; but from the route table output ; all iif eth0.172 oif eth1 lookup 2; shouldnt’ this be going via qmimx0 ?

I have it working; but I have no idea if I’ve got this all wrong in the configuration and just got lucky.

These are my failover multiwan settings.

[Matas]

Hello,

You have a policy-based routing rule:

from all iif eth0.172 oif eth1 lookup 2

This means, that for any traffic coming in via eth0.172 and going out via eth1, use routing table 2.

Routing table 2 currently has the following default route:
default dev qmimux0 proto static scope link src 100.95.167.42 metric 2

This means that if there’s no more specific route, the traffic will go out through the mobile interface ( qmimux0 ), not through eth1, even though your rule mentions oif eth1.

This is because Linux routing decisions are made based on the routing table, and even though oif is specified in the rule, the actual next hop is still selected via the default route in the table.

So if there’s no route in table 2 that says “send this traffic out via eth1,” it won’t go out through eth1 - it’ll go through the default route to qmimux0.
To force traffic matching the rule to actually go out eth1, you need to add a default route via eth1 in routing table 2. And to make sure it’s preferred over the qmimux0 default route, give it a lower metric: for example, 1 in this case.

If you wanna test and see which routing table you’re using, you can do the following:

• Run ip route get 8.8.8.8 from 192.168.10.10 (the 192.168.10.10 is the VLAN IP) in the CLI of the device.

Regards,
M.