Question for those who have done Dual WAN mail servers

Question

Level 1

25 points

Question for those who have done Dual WAN mail servers

One of our offices is considering a Dual WAN setup to provide a high level of connectivity (they have had poor luck with their DSL service).

I have arranged to provide a more reliable ISP to be their other ISP on the dual WAN setup, but I'm wondering if I need to concerned about reverse lookup problems affecting our outgoing mail. On the client retrieval side there are some question marks as well...

I'm wondering what is better practice:
mail A WAN1 IP
mail A WAN2 IP
@ MX 10 mail

Or 2 separate hostnames?
mail A WAN1 IP
mail2 A WAN2 IP
@ MX 10 mail
@ MX 20 mail2

The first example is a frank round robin... and I'm not sure how email clients resolve hostnames (would they skip a dead IP and use the active one?).

SRV records maybe? I need a way to "prioritize" or show client connections the path to the functioning IP.

2nd Example: I can train employees to employ a separate POP/IMAP server when necessary, but unfortunately I'm wondering if this is avoidable...? I kind of wish Outlook had the Lotus Notes simple ability of just clicking off to a separate Domino when necessary.

And in terms reverse lookup... I wonder if the 1st example would be a problem? I wonder if I would need to use a relay to cover the inconsistency in IP (after a failover) eventually.

Any suggestions would be neat.

Windows XP Pro

Posted on Jan 26, 2011 10:32 PM

Reply

Answer 1

Best reply

Camelot

Level 9

54,333 points

Jan 27, 2011 12:14 AM in response to MAkahane

If the two WAN addresses map to the same physical server then either method is fine, although I'd err on the side of method 2 (two separate hostnames) since it gives you two MX records which remote servers will use to prioritize traffic (they'll try the one with the lowest priority value first, enabling you to focus incoming mail traffic on one of the links).

For the clients, though, approach #1 (two IP addresses for the same hostname) has slight advantages (namely that there's no need to reconfigure the mail client if one link goes down).
On the other hand, there's nothing that says you have to configure your clients with the same hostname as posted in your MX records, so it's entirely possible to have:

mail A WAN1_IP
mail A WAN1_IP
smtp1 A WAN1_IP
smtp2 A WAN2_IP
@ MX 10 smtp1
@ MX 20 smtp2

In this way you can configure your clients to use 'mail' and they'll load balance across the two links, while remote mail servers use the MX resolvers to determine where to send your mail.

And in terms reverse lookup... I wonder if the 1st example would be a problem? I wonder if I would need to use a relay to cover the inconsistency in IP (after a failover) eventually.

That's a fair point, and depends somewhat on how many IP addresses you have, but the primary point is that the reverse lookup of the IP address has to match (or at least resemble) the server name that postfix identifies itself with.

Reply

Answer 2

MAkahane Author

Level 1

25 points

Jan 27, 2011 7:51 AM in response to Camelot

Ahhh I see.

The same hostname to WAN1 and WAN2 from an external client side works without any worry about reverse lookup and the use of the smtp1 smtp2 (differing names vs. the "mail") provides an individual name for an individual IP (again providing a way to clear away the reverse lookup problem on server-to-server MX communications).

I guess the last bit would be wondering how clients would connect in the case of a failure on one of the two links. I'm guessing IMAP or POP3 SRV records may provide an additional way...

Strange thing is I had this office's mail name pointing to two separate servers at one point, but one was not setup at the time. I never was told of any connectivity issues. Maybe modern email clients can discern an dead-end route?

Reply

Answer 3

Jan 27, 2011 8:42 AM in response to MAkahane

Have a look at a dual-uplink capable D-Link DFL-series or Cisco RV042-series box for dual connections, or any of various equivalent devices.

For in-bound IP traffic, this case can usually be frugally dealt with via DNS-based failover, though there are some issues with how fast the fail-over can happen with this, and there are other and generally more expensive solutions available when you need faster fail-overs.

Specifically for in-bound SMTP mail, it's common to have a couple of MX records established at different priorities and particularly at different sites and preferably in entirely different geographies and ISPs, and to have one of these intermediate-priority SMTP servers queue up the incoming mail until you can unsnarl the particular network issue. SMTP is pretty good at that stuff.

Reply

Answer 4

MAkahane Author

Level 1

25 points

Jan 28, 2011 8:00 AM in response to MrHoffman

Hi Mr. Hoffman.

I have looked at Cisco and a few other brand models. The sort of "better failover" I think I would probably feel safer with is some sort of internet gateway DNS. Authoritative DNS that would provide the change to IP when necessary to client machines.

It looks like I have to look at models like Xincom and Syswan in order to get that built into the router though. It would be neat to have a Peplink... since they have very easy to read documentation on this failover ability in their knowledge base ( http://www.peplink.com/index.php?view=faq&id=125&path=21). Maybe too far out of budget perhaps.

MrHoffman, do you have any recommendation on email spooling in case of both WANs failing? Postini perhaps?

Reply

Answer 5

Jan 28, 2011 9:47 AM in response to MAkahane

Spool into a cloud? Whether a mail server on your own host slice, or a virtual host, or with one of the various available email hosting cloud services. These can be easy, cheap and quite cost-effective. Particularly when compared with running your own redundant networks. (Even if you have multiple sites and structures and network connections for some other purpose, there are the incremental costs of the servers and the server upkeep.)

And look at how often both servers are likely to be down, too, and why that outage might be, and how fast you can have mail server(s) back on-line somewhere. If you have a DNS Time To Live (TTL) setting of an hour or three, most SMTP servers will queue mail for you, and that'll usually get you enough time to switch DNS and get an alternate mail host on-line.

You're headed down the path toward Disaster Tolerance (DT), and that's an interesting topic in its own right. And each one of those nines you want to add to your 99% or 99.9% uptime gets (more) (and more) expensive. And DT can be a surprisingly subtle and complex undertaking; there are a plethora of stupid little things that can trip you up.

Reply