I have 2 WANs connect to my RB951ui, let’s say WAN1 and WAN2.
My requirement is pretty simple, for some hosts, I want all the traffic from these hosts go to WAN1 and other hosts go to WAN2, so I did:
If I do this, it seems everything works fine. so I’m confused that the priority of policy route and the default route.
According to my understanding, policy route has it’s own routing table and ROS should pick it and ignore the main route table rules when a packet has a routing mark.
Can somebody help to explain why my policy route doesn’t work?
Thanks a lot.
There is a subtle difference. You can think of it as if “no routing mark” was also a routing mark. When routing a packet, the routing engine takes into account only routes with the same routing mark like the packet has. So there is no priority based on routing mark. Therefore, the reason why your first example works is not because packets not marked with “go-wan-1” use a route with higher “distance” = lower priority, these packets simply do not “see” the route marked with “go-wan-1” at all.
Priority/distance is only taken into account when several routes with identical dst-address and identical routing-mark exist.
So in another words, both your configurations should result in the same behaviour. Is there any other route than the two default ones which you haven’t listed when posting?
@sindy@CZFan, I have the same thoughts before but it seems that it’s not right.
It seems that ROS is picking the routing rules randomly.
In order to make this simple, I reset(reset configuration) my RB951 just now and created 2 WAN PPPOE interface(link), then:
[admin@MikroTik] > /ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=srcnat action=masquerade out-interface=all-ppp log=no log-prefix=""
[admin@MikroTik] > /ip firewall mangle print detail
Flags: X - disabled, I - invalid, D - dynamic
0 D ;;; special dummy rule to show fasttrack counters
chain=prerouting action=passthrough
1 D ;;; special dummy rule to show fasttrack counters
chain=forward action=passthrough
2 D ;;; special dummy rule to show fasttrack counters
chain=postrouting action=passthrough
3 chain=prerouting action=mark-routing new-routing-mark=go-wan1 passthrough=no src-address=192.168.88.251 log=no log-prefix=""
[admin@MikroTik] > /ip route print detail
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit
0 A S dst-address=0.0.0.0/0 gateway=WAN1 gateway-status=WAN1 reachable distance=1 scope=30 target-scope=10 routing-mark=go-wan1
1 A S dst-address=0.0.0.0/0 gateway=WAN2 gateway-status=WAN2 reachable distance=1 scope=30 target-scope=10
2 ADC dst-address=112.82.140.1/32 pref-src=112.82.141.25 gateway=WAN2 gateway-status=WAN2 reachable distance=0 scope=10
3 ADC dst-address=180.116.2.1/32 pref-src=180.116.2.154 gateway=WAN1 gateway-status=WAN1 reachable distance=0 scope=10
4 ADC dst-address=192.168.88.0/24 pref-src=192.168.88.1 gateway=bridge gateway-status=bridge reachable distance=0 scope=10
So that’s all I did and I can ping some sites without issues like:
C:\Users\kartw>ping www.baidu.com
Pinging www.a.shifen.com [180.97.33.108] with 32 bytes of data:
Reply from 180.97.33.108: bytes=32 time=5ms TTL=55
Reply from 180.97.33.108: bytes=32 time=5ms TTL=55
Reply from 180.97.33.108: bytes=32 time=5ms TTL=55
Reply from 180.97.33.108: bytes=32 time=5ms TTL=55
Ping statistics for 180.97.33.108:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 5ms, Maximum = 5ms, Average = 5ms
The default configuration contains a firewall rule with “action=fasttrack-connection”, and fasttracking is incompatible with packet marking because majority of packets belonging to established connections bypass the mangle table. Only a small share of these packets is not fasttracked, and so they get their routing mark and the “action=accept” rule right next to the fasttrack one lets them through. Effectively the biggest share part of the packets is sent through a wrong WAN so the recipient ignores them as it cannot relate them to the initially established connection as they come from a different public address.
To confirm that this is your issue, disable the fasttrack rule and try to get to the web again. Only after that it makes sense to create some more complex rules to prevent only connections which need to use the non-default routing table from getting fasttracked.
Another point,
0 A S dst-address=0.0.0.0/0 gateway=WAN1 gateway-status=WAN1 reachable distance=1 scope=30 target-scope=10 routing-mark=go-wan1
1 A S dst-address=0.0.0.0/0 gateway=WAN2 gateway-status=WAN2 reachable distance=1 scope=30 target-scope=10
>
There are no gateway IPs on your routes, are they point-to-point based? I've already seen people experience problems with automatic detection of routers on subnets with multiple devices.
“disable the fasttrack rule”, do you mean I should go to “ip → Settings” then uncheck the “Allow Fast Path”? Or just disable those 3 fasttrack mangle rules?
Yes, both WAN1 and WAN2 are PPPOE connections so I think it should be fine to set the interface in the routing rule right?
To be honest I doubt that fasttrack is the root cause because if it was the cause, how do we explain if we mark all traffics and set 2 policy routes to WAN1 and WAN2, then the issue is gone?
No, fatspath and fasttrack are not the same thing. You should go to IP → Firewall → Filter, and find a rule in chain forward with action=fasttrack-connection. In WebFig it is displayed with a >> symbol. To the left of the rule, there is a [-] button for deletion and [D] button for disabling. I guess the WinBox graphic is very similar. Press the D button, the rule changes to gray color and the button becomes [E] for re-enabling. And bear in mind that already established connections will stay fasttracked, the disabling of the rule only has effect on connections initiated while the rule is disabled. So open a web page you which wasn’t open at least 10 minutes before you’ve disabled the rule (many browsers keep tcp sessions alive for quite some time after use).
Yes, both WAN1 and WAN2 are PPPOE connections so I think it should be fine to set the interface in the routing rule right?
Yes, I just wanted to be sure.
To be honest I doubt that fasttrack is the root cause because if it was the cause, how do we explain if we mark all traffics and set 2 policy routes to WAN1 and WAN2, then the issue is gone?
I also have a feeling that there is something else in it but we need to get rid of obvious causes before investigating into some special ones.
Sindy, sebastia, thank you guys I’ve tested that both disabling “rule in chain forward with action=fasttrack-connection” and “Allow Fast Path” are working.
So the only question left is if fasttrack is the root cause, why defining 2 policy routes also work…
The only explanation which comes to my mind is that fastpath uses the default routing mark, and if no route with default routing mark is present, fasttracking (or fastpath as a whole) it is not activated at all.
You could verify this using “/ip firewall connection print” - fasttracked connections are marked with F in the list. So if in your setup with two mangle rules and two routing marks, with fastpath enabled and the fasttrack rule enabled as well, none of the tracked connections in the list shows the F, the guess is correct.
Sindy I tested your idea but sadly it seems that it’s not right. After enabling 2 policy routes, I still saw lots of connections with a “F” tag.
I tried to clear all connections, reboot the router and tested a few times, still the same result.
Thanks for the discussion done above.
Was facing the same issue with similar configuration and disabling FastTracking has helped to get optimum speed at both the PPPoE WANs.
