Strange behaviour of link-monitor

Question

Hello!I am testing a redundant VPN solution with AWS. We have clients where there already is one tunnel set up (actually two because AWS always creates a backup tunnel too on their side). I try to implement this: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html, section "Using Redundant VPN Connections to Provide Failover". This is 4 tunnels between our client and AWS for full redundancy. I didn't see any note how to perform this so I tested that if I will just create another Customer Gateway (which is the same router but having the backup internet connection's IP-address) and a VPN to it with the same internal subnet, then maybe AWS is able to choose which tunnels to use. Unfortunately, there isn't a clear method for this, like route distances on AWS side. So I set a link-monitor working for all 4 tunnels and then changed the ping-address so that the main tunnels' routes should be remove from routing table. By the logs, this happened ("Route removed") but in route monitor, these routes were still present. I pinged a server on the other side all the time and it was constantly up, no outage. So it looks like the link-monitor activated and reported that the routes were removed but this really didn't happen by the monitor (I also checked from CLI). The device where I am testing this has 5.4.0 software, FGT60D.

echo · Answer

Little update: I created backup tunnels against secondary ISP's IP-address (which in that router has equal distance with the primary ISP's defualt route but with higher priority number, that is, less preferred) and then, for a test, I changed the IP-addresses of primary AWS tunnels to wrong ones so that the tunnels must go down (and then routes as well). I pinged a server in AWS during this. Result: It just worked without a single ping loss and the change to backup ISP was evident from a little longer ping time in milliseconds. After changing the IP-s back to correct ones, the primary tunnels were restored and there was no single ping loss either. So far so good. Next test will be in a router where the backup ISP's default route is inactive when the primary ISP is OK.

Sign up

Login with SSO

Login to the community

Login with SSO