Best practice for IP address failover.

Answered Question
Jul 13th, 2007

I'm trying to find the best method for keeping a set of redundant servers at a remote site, and being able to fail over automatically. Essentially, I have a backup mail server at a remote site, and I would like to be able to fail over without needing to change IP addresses. I've seen discussions involving spanning VLANs across the WAN, or using NAT to achieve the same effect (although I didn't completely understand the latter).

My goal is to keep the mail server IP the same, and somehow make it available at the remote site. If the remote site is uses the 10.2.x.x subnet, and our primary site uses 10.1.x.x, how would I go about doing this?

I have this problem too.
0 votes
Correct Answer by bborsos about 9 years 6 months ago

Have you considered using LAM ( Local Area Mobility ) ? We use it for AS-400 failover between data centers when we want to keep the IP addresses the same. http://www.cisco.com/warp/public/cc/pd/iosw/ioft/lam/tech/lamso_wp.pdf

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Wilson Samuel Fri, 07/13/2007 - 06:07

Hi,

Just wondering, we can easily achieve fault-tolerance for any SMTP based servers, with an extra MX entry in the DNS.

Why create complications in the L-3 when things are easily handled in the L-7

Please comment.

Regards

Wilson Samuel

jasonfaraone Fri, 07/13/2007 - 06:21

Perhaps using the mail server as a prime example wasn't the best idea; we also intend to provide the same functionality with a few other servers (File server, Database, etc).

I don't manage our mail server, so I can't give a very good answer to your question, but I do know that our current practice of using DNS aliases has introduced as many problems as it has solved.

I really would like the ability to migrate an IP address to a remote site quickly, and automatically.

harveyl Thu, 07/19/2007 - 12:51

LAM is only meant to be a temporary solution and is prone to its own issues. An attacker can bloat your routing table with host entries or disrupt traffic from servers by causing the router to install routes to resource hosts that it should not. This is a temporary tactical tool, not a strategic solution.

harveyl Thu, 07/19/2007 - 12:40

Honestly, just dont do it. There is no good way to stretch a broadcast domain across a WAN. I defy anyone to produce a best practices document that supports such a practice.

If you wnat to try it, the only way that I can think of is to use bridge groups on GRE tunnels, but that would likely be a disaster because of potential for isolating that portion of the broadcast domain if WAN issues arise, potential for CPU spiking if you run HSRP over it, etc... Give yourself a large test window with test resources before you attempt to rely on it with production traffic.

I have also heard of using L2TP as the transport but have yet to see any configurations that support L2TP used in this way.

Leroy

umamytov Sat, 07/21/2007 - 01:52

How about this possible approach of using load balancing and routing.

Assumptions:

1) 10.1.X.0/24 is a VIP net that hosts IPs of various services (SMTP, etc)

2) 10.2.A.0/24 is a network that hosts actual servers at location A

3) 10.2.B.0/24 is a network that hosts actual real servers at location B

4) location A is a primary site, location B is a backup site

Approach:

1) Announce 10.1.V.0/25 & 10.1.V.128/25 out of location A and 10.1.V.0/24 out of location B, or do some other routing engineering such that VIP net is routed to Site A as long as local router is up but routed to Site B when router at site A is down.

2) At primary site deploy a load balancer and have service VIPs (Virtual IPs) from VIPnet configured and load balanced to local server 10.2.A.x and to remote backup server 10.2.B.x (various load balancers have typically a feature that allows designate some of the real servers behind VIP as backup that will be used only and only all regular servers fail).

3) At backup site deploy a load balancer and have service VIPs from VIPnet configured and load balanced to local server 10.2.B.x and to remote backup server 10.2.A.x

This is just a general idea, that is somewhat vendor agnostic.

Actions

This Discussion