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?
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.
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.
How about this possible approach of using load balancing and routing.
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
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.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...