Anycast provider for SMTP?

Thu Jun 18 11:51:37 UTC 2015

I gave a pretty broad answer because the question was about hosting mail
servers using anycast.

I don't think what I was getting at in regards to stateful vs. stateless
was incorrect, but I was talking about the application level not the nature
of the protocol and throwing TCP in there confused the issue (I wasn't
talking about TCP itself as a stateful protocol; notice I said "most
things").

You can certainly do anycast with TCP, and for small stateless services it
can be effective.  You can't do anycast for a stateful application without
taking the split-brain problem into account.

The entire CDN model was developed with anycast in mind, so yes, I'm sure
it does work quite well.  It generally fits the description of a stateless
service, and if it does implement a stateful service it's designed such
that nodes have a method of sharing information (perhaps using an
eventually consistent model).

Taking a normal application, like mail or a dynamic website, and just using
anycast for load balancing without designing the service with the anycast
model in mind is probably not a good idea.  You need to expect that the
same user could access different systems, and design for that.

The real point here is the problem OP is describing should be easily
handled by having proper MX records, and getting into anycast for mail is
likely not the right choice (unless maybe your goal is to be really
efficient at SPAM).

I'd like to know more on what problems he's seeing.

On Thu, Jun 18, 2015 at 4:13 AM, Kurt Kraut <listas at kurtkraut.net> wrote:

> Ray,
>
>
> "Anycast is generally not well-suited for stateful connectivity (e.g. most
> things TCP)."
>
> I don't know anything that would support that claim. I have been using for
> years BGP anycast for audio and video streaming, always in TCP (RTMP, HLS,
> WMS, and even the good and old ShoutCast) and works like a charm. And this
> is the 'secret sauce' of the company I work for, the thing we do better
> than our competitors that make our users happy and never wanting to leave
> us: anycast.
>
> We have customers that are TV stations and stream 24x7x365 their content
> and they have watchers getting their streaming also 24x7x365 (like waiting
> rooms, airports) with no complaints or instability.
>
>
> Best regards,
>
>
> Kurt Kraut
>
> 2015-06-17 16:13 GMT-03:00 Ray Soucy <rps at maine.edu>:
>
>> Anycast is generally not well-suited for stateful connectivity (e.g. most
>> things TCP).  The use case for anycast is restricted to simple
>> challenge-response protocol design.
>>
>> As such, you typically only see it leveraged for simple services (e.g.
>> DNS,
>> NTP).
>>
>> The reason for this, as you suspect, is you can never guarantee that the
>> path and thus the server will remain consistent across client connections.
>>
>> Ideally you can leverage DNS to provide a response to a unicast resource
>> rather than trying to make the service itself anycast.  DNS can be
>> anycast,
>> and DNS can provide different responses based on geographical location,
>> but
>> these can happen independently or together.
>>
>> As you still want failover, you might opt to announce the MX record with
>> the priorities reversed but still pointing to each server.  For example MX
>> 10 server1, MX 20 server2 on one side, and MX 10 server2, MX 20 server1 on
>> the other.
>>
>> Typically you would use a DNS load balancer rather than simple anycast DNS
>> to achieve this though.
>>
>>
>> On Mon, Jun 15, 2015 at 1:50 PM, Joe Hamelin <joe at nethead.com> wrote:
>>
>> > I have a mail system where there are two MX hosts, one in the US and
>> one in
>> > Europe.  Both have a DNS MX record metric of 10 so a bastardized
>> > round-robin takes place.  This does not work so well when one site goes
>> > down.   My solution will be to place a load balancer in a hosting site
>> > (virtual, of course) and have it provide HA.  But what about HA for the
>> > LB?  At first glance anycasting would seem to be a great idea but there
>> is
>> > a problem of broken sessions when routes change.
>> >
>> > Have any of you seen something like this work in the wild?
>> >
>> >
>> > --
>> > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474
>> >
>>
>>
>>
>> --
>> Ray Patrick Soucy
>> Network Engineer
>> University of Maine System
>>
>> T: 207-561-3526
>> F: 207-561-3531
>>
>> MaineREN, Maine's Research and Education Network
>> www.maineren.net
>>
>
>

-- 
Ray Patrick Soucy
Network Engineer
University of Maine System

T: 207-561-3526
F: 207-561-3531

MaineREN, Maine's Research and Education Network
www.maineren.net