On Wed, May 1, 2013 at 4:52 PM, Michael Mol <mikemol at gmail.com> wrote: > > Intent is to maintain the old, slow (but has an SLA) connection as a > fallback, and migrate services to the new connection piecemeal. > Meanwhile, the same DNS server on the new connection can be, e.g. "ns3". > The same mailserver can have a new MX on the new connection...likely > prioritized to it. Note that there are more straightforward ways to do this. One is to pretend you are big enough to have a distributed server farm and actually have independent servers at the other IPs, even if they are VMs. This is fairly easy for mostly-static or database-driven web sites, fairly difficult for apllications that are more statefull but perhaps possible with a common NFS backend. Another is to have application-level proxies or load balancers like haproxy, nginx, apache configured as a reverse-proxy, or even port forwarding with an xinetd 'redirect' configuration. This loses the source ip from the application logs, although the http proxys have an option to pass them. Similarly you could use iptables to source-nat on the receiving side and forward to a backend server. These all have some disadvantages, but with separate hosts each having one default gateway to the internet and static routes for your own local ranges you have a lot less black magic involved. -- Les Mikesell lesmikesell at gmail.com