Backup link via PBR. What about published services?

Question

Cisco

There is a task to connect a backup ISP in the office, inside the company there are several services used by remote employees - Web, VPN, SMTP. The main problem is how to deal with published services so that when one of the providers fails, our services continue to be available to remote employees. The most obvious way is to deploy BGP, buy an AS number and provider-independent addresses. Then, on the published services, the addresses will not change if a channel goes down. The second method, which is easier to deploy in our conditions, and, accordingly, it is more preferable is the organization of switching to a backup channel using the PBR and IPSLA policies. But in this case, if the main channel fails, the IP address will change on the published servers. How to make sure that the service remains available when changing the IP address, even with a session break? Well, it’s clear with mail, we create several MX records. Cisco Easy VPN is also not difficult to configure in this regard - we specify backup servers. But what about the Web? will DNS round robin help here? Or is it easier to deploy BGP after all?

Answer 1

If there are problems with BGP, then one of the solutions that I use now is traffic proxying.
1 - We buy a VPS, we raise nginx / vpn on it (depending on what we want to reserve), we correct DNS - profit.
2 - There is an option to use ready-made cloud solutions, such as CloudFlare.
3 - We agree with providers that they allow forwarding and routing of packets not from their pool. Turn on DNS RR - done. I've done this trick twice and it still works. We first agree with the Provos about which prefixes to allow whom, set up the equipment - and voila! It’s not beautiful, of course, but it doesn’t contradict the basics of building networks, with the proper approach to implementation. Another thing is that providers may not agree because of the complexity of the topology.

Answer 2

You hang up DNS on a hosting which always survives. Well, or buy a slave service, and keep the master at your place and direct the slave to update from it.
You make a dynamically updated zone for these services, and the corresponding A-records with a timeout of 5 minutes. In the off state, there will be no recordings. When a channel is raised, an A-record with its address is added to the zone, when it falls, the record is deleted. When both providers work, you will even have some load distribution across channels, because there will be two active records.

Answer 3

I don't like DDNS and similar solutions because you need a client that will update records. Well, and many other shortcomings.
There is a more interesting solution based on DNS. We deploy two NS servers within the organization for our zone, each NS is available only through its own channel and is not available through the other. NS have different A-records for the same zone, which issue different ip-addresses for the same hosts depending on the channel on which the particular NS hangs. TTL for zone 5 minutes. When one of the channels is cut down, the cache is cleared after 5 minutes and the zone is downloaded from the surviving NS, which reports the current IP on the working channel.
Now the question is - what is the minimum TTL value for the zone? You can set anything, but providers are likely to ignore too low a value. Can there be any other problems with this scheme?

Answer 4

Yesterday I set TTL to 5 minutes for the zone, google DNS updates IP addresses in about an hour.

Answer 5

Two views through different channels - from the point of view of external observers, these are two different DNS servers that give two different versions of the zone. With all the ensuing problems like "zone versions given by different DNS servers are different." You shouldn't do that.
And yes, it's generally very tricky. In addition, if you already have where to put the bind, then there is where to run nsupdate from. And a solution like “hang a pinger on the hosting that will delete an unnecessary entry if the ping through this channel is down” is much simpler. In addition, it is external, i.e. simulates a real external client, since it is outside, the loss of access through one or another channel will be real, and not “according to the cisca”.