Hi all,

I have a CCR1016 configured with a default gateway on ETH1 (10.20.10.1), distance 1, check gateway via ping. Then, another route on ETH5 (10.20.16.1) with distance 2. When I disable the primary interface on the upstream router, the CCR correctly marks the primary route as unreachable, and makes the secondary route active.

However, almost no traffic is sent towards the secondary route in this scenario. I have Hotspot and PPPoE servers on the CCR, pulling in some 250Mbps. All sessions stay active, the RADIUS server is reachable on the secondary route, and I can run a bandwidth test on the secondary route against the upstream router, all good.

Any ideas as to reasons for this?

Do you using masquerading? Do you assign out interfaces for masq in failover direction?

I have seen that when the WANs are from a different providers with a different public IP and gateway subnet, many stateful connections hang. This occurs when connection marks are used and the corresponding connections are not expired. Over time I have seen that the traffic slowly increases on the new gateway, and in a few minutes most connections are trafficking correctly. I think that this behavior occurs because the servers interpret the change in client IP as a man in the middle hack. Sometimes I have had to delete all active connections that correspond to the change of WAN. This of course forces the affected user to have to sign into some services again, but this is a small negative compared to zero access.

I have also seen that if the new WAN has dynamically added DNS entries (like with pppoe connections and some DHCP client connections), I have had to delete the dns cache after a wan change. It appears that my ISPs usurp many services by overwriting their DNS entries, so as to keep them local, and a switch causes problems with the most common services like youtube, gmail, etc.

If you find that this is your problem, your could write a scheduled script that tests for active WAN interface and when it detects a change, takes the appropriate actions such as delete all corresponding active connections and/or clears the dns cache.

Hope this helps. Kind regards -

Connections get hanging in conn tracker only if you choose whatever source nat action except masquerade. Masq will drop all connection by himself if route though masq interface is unreachable.

Connections get hanging in conn tracker only if you choose whatever source nat action except masquerade. Masq will drop all connection by himself if route though masq interface is unreachable.

Anumrak, thank you for this info. There is one interface that I was using src-nat instead of masquerade. It was the main interface, running the majority of the traffic. This explains why most connections would hang. Thank you again, I will change and test.

Connections get hanging in conn tracker only if you choose whatever source nat action except masquerade. Masq will drop all connection by himself if route though masq interface is unreachable.

Anumrak, thank you for this info. There is one interface that I was using src-nat instead of masquerade. It was the main interface, running the majority of the traffic. This explains why most connections would hang. Thank you again, I will change and test.

Be careful with processor utilization.

Anumrak: I can confirm that your suggestion solved my problem, thanks again. The routing failover is now very fast and the connections do not hang. CPU is good. Hopefully you OP had the same problem, and this will help him as well. Back to the OPs original topic request ...

@stoser how did you fix specifically? I believe the issue is how our masquerade is configured - we masquerade PPPoE to a specific upstream IP address, which of course breaks when the secondary route takes over, as the upstream IP range is different.

I'm simulating all this in the lab but have a few details to work out.