60D failover does not restore route

ddemland · ‎08-29-2018

I have a 60D running 5.2.3. I have one network for the VoIP phones and its traffic is routed out wan2 to one ISP. All the other data is routed out wan1 to a different ISP. I have link health monitor on both WAN interfaces and when I unplug one WAN cable all the traffic in rerouted to the other WAN interface with no problem. This change happens in seconds and is what I would expect. However, when I plug the cable back in trace routes, from clients, show that it path is not restored the proper ISP. When I look at the routing table in the 60D, the routing table is updated almost immediately when the cable is unplugged or plugged in, which leads me to believe that the routing table is correct for each event. Since the trace route on the clients do not show the path being restored when the cable is plugged back in, I think something is caching the routing table. How do I get the restore of the route to be as fast as the fail over of the route?

ede_pfau · ‎08-30-2018

Routing decisions are only made when establishing a new session. Existing sessions will follow whatever route had been chosen.

In your case, do you have both default routes in the Routing table, or do you use policy routing? With static routes, you could try to use different weights: same distance, lower (!) priority for the preferred route. Route priority is only available in the CLI.

Ede

"Kernel panic: Aiee, killing interrupt handler!"

ddemland · ‎08-30-2018

That you for the information. I do have both static routes and I also have policies as well. This was the only way I got the fail over to work and keep the client systems up. I cannot use different distances since that takes one of the WANs down and the goal is to have both working for the two networks and I also set the priorities as well. The only thing I did not know was the session issue. That now makes total sense with the behavior I am seeing.

In short it looks like I have every configured correctly I just could not understand the lag in the returning of the routing table when a connection came back up. A new session explains it and I now understand what I am seeing and why.