"Joe Abley" writes:
> http://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-02
>
> There are privacy concerns, here. But we might posit that you've
> already in the business of trading privacy for convenience if you're
> using a public resolver.
Personally, I've always thought the p
> On Jun 18, 2015, at 10:19 PM, James Hartig wrote:
> Just curious, how does DNS load balancing work if people are using
> 8.8.8.8/208.67.222.222 or basically any public resolvers that cache and
> have a significant (relatively speaking) user-base? Is the actual percent
> of requests so small tha
On Fri, Jun 19, 2015 at 3:42 PM, Joe Abley wrote:
> On 19 Jun 2015, at 8:12, Christopher Morrow wrote:
>
>> On Fri, Jun 19, 2015 at 7:19 AM, James Hartig
>> wrote:
>>
>>> Just curious, how does DNS load balancing work if people are using
>>> 8.8.8.8/208.67.222.222 or basically any public resolv
On Fri, Jun 19, 2015 at 2:47 PM, Tony Finch wrote:
> James Hartig wrote:
>>
>> Just curious, how does DNS load balancing work if people are using
>> 8.8.8.8/208.67.222.222 or basically any public resolvers that cache and
>> have a significant (relatively speaking) user-base?
>
> http://www.afaste
On 19 June 2015 at 10:39, Mike Meredith wrote:
> On Thu, 18 Jun 2015 15:51:31 -0400, "Joe Abley"
> may have written:
> > Since DHCP uses broadcast and multicast addresses when a client is
> > discovering a server, it's not obvious why you'd have to.
>
> And broadcast/multicast when renewing a le
On 19 Jun 2015, at 8:12, Christopher Morrow wrote:
On Fri, Jun 19, 2015 at 7:19 AM, James Hartig
wrote:
Just curious, how does DNS load balancing work if people are using
8.8.8.8/208.67.222.222 or basically any public resolvers that cache
and
If the client that performs the upstream query
James Hartig wrote:
>
> Just curious, how does DNS load balancing work if people are using
> 8.8.8.8/208.67.222.222 or basically any public resolvers that cache and
> have a significant (relatively speaking) user-base?
http://www.afasterinternet.com/ietfdraft.htm
Tony.
--
f.anthony.n.finchh
On Fri, Jun 19, 2015 at 7:19 AM, James Hartig wrote:
>
> Just curious, how does DNS load balancing work if people are using
> 8.8.8.8/208.67.222.222 or basically any public resolvers that cache and
don't know exactly, but you might get some interesting clues from the
f-root or as112 designs, eh?
On Thu, 18 Jun 2015 15:51:31 -0400, "Joe Abley"
may have written:
> Since DHCP uses broadcast and multicast addresses when a client is
> discovering a server, it's not obvious why you'd have to.
And broadcast/multicast when renewing a lease (DHCPREQUEST). You will
of course see unicast addresses
>
> You can achieve the above DNS trickery using various load balancers that
> other people in this thread have already mentioned. You can also install
> your own geomaps in your own nameservers and handle it yourself, or you can
> buy managed DNS service from various people that can do this kind o
On 19 June 2015 at 04:18, Larry Sheldon wrote:
> On 6/18/2015 16:40, Jonas Björk wrote:
>
> The clients speak unicast with one single ip-helper which address is
>> shared by all the servers.
>> They can't choose which ever server to talk to.
>>
>
> One of us is confused (and it may well be me) b
On 6/18/2015 16:40, Jonas Björk wrote:
On Jun 18, 2015, at 11:29 PM, Larry Sheldon wrote:
On 6/18/2015 16:25, Jonas Björk wrote:
Because clients will switch to unicast for renewal. Also clients will stay
with the current server forever, so you might have a bad distribution of
load between
On 2015/06/19 4:43, Jonas Björk wrote:
While risking being slightly off topic: Does anyone use anycast dhcp servers?
Have you run into any problems considering synching the leases?
In general, multiple anycast servers on a link, which is the anycast
model of IPv6, is a bad idea, because broadca
> On Jun 18, 2015, at 11:29 PM, Larry Sheldon wrote:
>
>> On 6/18/2015 16:25, Jonas Björk wrote:
>>
>>> Because clients will switch to unicast for renewal. Also clients will stay
>>> with the current server forever, so you might have a bad distribution of
>>> load between the servers. If one se
On 6/18/2015 16:25, Jonas Björk wrote:
Because clients will switch to unicast for renewal. Also clients will stay
with the current server forever, so you might have a bad distribution of
load between the servers. If one server was down everyone will switch to
the other and never go back until f
> Because clients will switch to unicast for renewal. Also clients will stay
> with the current server forever, so you might have a bad distribution of
> load between the servers. If one server was down everyone will switch to
> the other and never go back until forced.
Why wouldn't they go back
Den 18/06/2015 21.52 skrev "Joe Abley" :
>
> On 18 Jun 2015, at 15:43, Jonas Björk wrote:
>
>> While risking being slightly off topic: Does anyone use anycast dhcp
servers?
>> Have you run into any problems considering synching the leases?
>
>
> Since DHCP uses broadcast and multicast addresses whe
On 18/06/2015 20:51, Joe Abley wrote:
> Since DHCP uses broadcast and multicast addresses when a client is
> discovering a server, it's not obvious why you'd have to.
most non trivial (i.e. routed networks) would use dhcp relay, in which case
anycast dns could be argued to make some sense. TBH, t
On 18 Jun 2015, at 15:43, Jonas Björk wrote:
While risking being slightly off topic: Does anyone use anycast dhcp
servers?
Have you run into any problems considering synching the leases?
Since DHCP uses broadcast and multicast addresses when a client is
discovering a server, it's not obvious
While risking being slightly off topic: Does anyone use anycast dhcp servers?
Have you run into any problems considering synching the leases?
Ray Soucy writes:
> 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.
In my experience, the thing that makes anycast work *well* is having
the con
On Thu, Jun 18, 2015 at 09:08:13AM -0400, Joe Abley wrote:
> On 18 Jun 2015, at 7:51, Ray Soucy wrote:
>
> >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 int
On 18 Jun 2015, at 7:51, Ray Soucy wrote:
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.
It's really difficult to apply broad "can" or "can't",
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 th
On Thu, Jun 18, 2015 at 4:13 AM, Kurt Kraut via NANOG 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, alw
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
melin
> Cc: NANOG list
> Subject: Re: Anycast provider for SMTP?
>
>
> >As such, you typically only see it leveraged for simple services (e.g.
> DNS, NTP).
>
> I've been thinking about this for NTP. Wouldn't you end up with constant
> corrections with NTP and
On Jun 17, 2015, at 17:15, Chuck Church wrote:
>> As such, you typically only see it leveraged for simple services (e.g. DNS,
>> NTP).
>
> I've been thinking about this for NTP. Wouldn't you end up with constant
> corrections with NTP and Anycast?
I am not a time geek, but the general and con
Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Ray Soucy
Sent: Wednesday, June 17, 2015 3:14 PM
To: Joe Hamelin
Cc: NANOG list
Subject: Re: Anycast provider for SMTP?
>As such, you typically only see it leveraged for simple services (e.g. DNS,
>NTP).
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 yo
https://www.google.com/intl/en/ipv6/statistics.html
On Mon, Jun 15, 2015 at 8:26 PM, Matt Palmer wrote:
> On Mon, Jun 15, 2015 at 05:07:22PM -0700, Dave Taht wrote:
> > On Mon, Jun 15, 2015 at 5:00 PM, Randy Bush wrote:
> > >> "What about IPv6? We have a plan! We plan to be dead before custom
On Mon, Jun 15, 2015 at 05:07:22PM -0700, Dave Taht wrote:
> On Mon, Jun 15, 2015 at 5:00 PM, Randy Bush wrote:
> >> "What about IPv6? We have a plan! We plan to be dead before customers
> >> demand IPv6".
> >> I am pretty sure the authors are still alive(?).
> >
> > and customer demand for ipv6 s
On Tue, Jun 16, 2015 at 9:02 PM, Rafael Possamai wrote:
> Any luck on a DNS based solution?
>
I'm looking into a F5 GTM solution based out of a colo we have in Europe to
direct SMTP between France and the US hubs. Now I just have to work layers
8 & 9.
Remember when users didn't expect sub-minu
Any luck on a DNS based solution?
On Mon, Jun 15, 2015 at 12:50 PM, Joe Hamelin 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
In message <82d10008-cb76-42c7-a78c-ee876924d...@pch.net>, Bill Woodcock writes:
>
> > If you read what Joe wrote, he doesn't currently have an AS number or
> > employ BGP with his Internet providers. Extrapolate for his IPv4
> > assignment situation and the /24 announcement barrier. In an
> > IPv
On Mon, Jun 15, 2015 at 5:08 PM, Joe Hamelin wrote:
> It seems to be more of a last-mile backhoe fade issue right now. I'm
> trying to convince them that a manufacturing facility isn't a good place
> for a data center.
Backhoes seem to have gotten you for a day or so now. My mail to you
is defer
On Jun 15, 2015, at 1:50 PM, Joe Hamelin 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 b
On Tue, 16 Jun 2015, Owen DeLong wrote:
On Jun 16, 2015, at 12:49 , Masataka Ohta
wrote:
William Herrin wrote:
If you read what Joe wrote, he doesn't currently have an AS number or
employ BGP with his Internet providers. Extrapolate for his IPv4
assignment situation and the /24 announceme
> On Jun 16, 2015, at 12:49 , Masataka Ohta
> wrote:
>
> William Herrin wrote:
>
>> If you read what Joe wrote, he doesn't currently have an AS number or
>> employ BGP with his Internet providers. Extrapolate for his IPv4
>> assignment situation and the /24 announcement barrier. In an
>> IPv4-
William Herrin wrote:
> If you read what Joe wrote, he doesn't currently have an AS number or
> employ BGP with his Internet providers. Extrapolate for his IPv4
> assignment situation and the /24 announcement barrier. In an
> IPv4-depleted world, he won't be doing anycast any time soon, even if
>
>Uh huh. The numbers are clear: 99.99% of the time it works. The other
>0.01% of the time you're screwed and had better pray the user is one
>of the ones you can afford to lose.
>
>Unicast TCP breaks too, but it has the virtue of being fixable 100% of the
>time.
I love the wry humor on the nanog
> If you read what Joe wrote, he doesn't currently have an AS number or
> employ BGP with his Internet providers. Extrapolate for his IPv4
> assignment situation and the /24 announcement barrier. In an
> IPv4-depleted world, he won't be doing anycast any time soon…
…which is one of the reasons why
On Tue, Jun 16, 2015 at 12:43 PM, Bill Woodcock wrote:
>> On Jun 15, 2015, at 11:54 AM, William Herrin wrote:
>> I think you've offered some really bad advice here Bill.
>
> As I said, there are lots of people who _think_ it doesn’t work. And then
> there are people who’ve actually done it, and
> On Jun 15, 2015, at 11:54 AM, William Herrin wrote:
> I think you've offered some really bad advice here Bill.
As I said, there are lots of people who _think_ it doesn’t work. And then
there are people who’ve actually done it, and know better.
Besides, you seem to not have read what I actua
> On Jun 15, 2015, at 8:00 PM, Randy Bush wrote:
>
> dns is udp
15 years ago when we set up 4.2.2.1, there was a fair amount of TCP based DNS.
We tried for a bit to support it via the anycast address, but ultimately we
decided the support issues weren’t worth it. The few customers that
a
On Mon, Jun 15, 2015 at 5:00 PM, Randy Bush wrote:
>> "What about IPv6? We have a plan! We plan to be dead before customers
>> demand IPv6".
>> I am pretty sure the authors are still alive(?).
>
> and customer demand for ipv6 still holds strong, right?
Does seem to be on the uptick!
>> I have be
> "What about IPv6? We have a plan! We plan to be dead before customers
> demand IPv6".
> I am pretty sure the authors are still alive(?).
and customer demand for ipv6 still holds strong, right?
> I have been using anycast at a small scale on mesh networks, for dns,
> primarily. Works.
dns is ud
On Mon, Jun 15, 2015 at 1:58 PM, Rafael Possamai wrote:
> You're welcome. I hope that helps.
>
> On another note, if your internet pipe in Europe isn't as stable as your
> pipe in the US, then you could also try and have your infrastructure
> provider blend your uplink with two or more carrier-gr
You're welcome. I hope that helps.
On another note, if your internet pipe in Europe isn't as stable as your
pipe in the US, then you could also try and have your infrastructure
provider blend your uplink with two or more carrier-grade paths. You
wouldn't have to worry about signing up for and main
On Mon, Jun 15, 2015 at 12:34 PM, Joe Abley wrote:
> On 15 Jun 2015, at 15:05, Dave Taht wrote:
>
>> I have been using anycast at a small scale on mesh networks, for dns,
>> primarily. Works.
>
>
> Many of us have been using anycast at Internet scale for DNS for a couple of
> decades. I would go f
On Mon, Jun 15, 2015 at 12:45 PM, Rafael Possamai
wrote:
>
>
> The other step would be to setup HA in each SMTP node (US and France) such
> as LB or Failover. Just an idea.
>
> I'll look at the AWS doc, thanks.
The mailserver is seldom the problem (it's an AS/400) but the ISP pipe
experiences pr
I could be mistaken, but you might get all of this done with AWS's Route53.
I would read this:
http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html#routing-policy-geo
The other step would be to setup HA in each SMTP node (US and France) such
as LB or Failover. Just an idea.
On 15 Jun 2015, at 15:05, Dave Taht wrote:
I have been using anycast at a small scale on mesh networks, for dns,
primarily. Works.
Many of us have been using anycast at Internet scale for DNS for a
couple of decades. I would go further than "works" and perhaps say
"necessary".
There were s
>but 'well behaved smtp clients' should already be falling back right?
If you have multiple SMTP servers at the same priority, it's a pretty
broken client that doesn't try them all until one works.
That said, there is a depressing number of pretty broken SMTP clients.
R's,
John
I see no major problems to use anycast for that.
The problem will be in rare case when particular routing chain from
client to one of your servers will be changed until TCP stream is active.
SMTP have short connections. Even if it happens, it will look as just
broken connection for client, and it
On Mon, Jun 15, 2015 at 2:13 PM, Joe Hamelin wrote:
> The two MX sites are connected via third party MPLS. The problem is when
> one MX site loses Internet connectivity the sending MTA may take up to 4
> hours to resend and hopefully the DNS coin toss gives it the address of the
> site that is st
On Mon, Jun 15, 2015 at 11:28 AM, Nick Hilliard wrote:
> On 15/06/2015 19:09, William Herrin wrote:
>> Anycast + TCP = much pain, for reasons which should be obvious.
>
> This was presented at some conference or other a couple of years ago:
>
>> https://www.nanog.org/meetings/nanog37/presentations
Hi Joe,
On 15 Jun 2015, at 13:50, Joe Hamelin 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 b
On Mon, Jun 15, 2015 at 2:54 PM, William Herrin wrote:
> Okay, granted you can probably cover your corner case here with a
> priority 20 MX that leads to a unicast address on one of the two
> servers. SMTP can let the rare fellow with the bisected packet flow
> gracefully fall back.
but 'well beh
On Mon, Jun 15, 2015 at 2:13 PM, Bill Woodcock wrote:
> Or you could skip the MX records, and just put both US and European
> SMTP servers on the same IP address, which would save a lot of
> steps and simplify the system, but leave you with the _very_
> occasional corner-case of someone equal-path
Give a look at hosted GSLB service, FortiDirector, which I have set up for a
customer (for SMTP, Exchange, ActiveSync world wide services.
> Le 15 juin 2015 à 19:50, Joe Hamelin a écrit :
>
> I have a mail system where there are two MX hosts, one in the US and one in
> Europe. Both have a D
On 15/06/2015 19:09, William Herrin wrote:
> Anycast + TCP = much pain, for reasons which should be obvious.
This was presented at some conference or other a couple of years ago:
> https://www.nanog.org/meetings/nanog37/presentations/matt.levine.pdf
Nick
On Mon, Jun 15, 2015 at 11:02 AM, Christopher Morrow <
morrowc.li...@gmail.com> wrote:
>
> 'when one site goes down' ... then the other works fine, right? smtp
> is not latency sensitive in the sense that a 30second timeout for a
> server will mean delivery to the secondary... right?
The two MX
> On Jun 15, 2015, at 10:50 AM, Joe Hamelin 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 wi
On Mon, Jun 15, 2015 at 1:50 PM, Joe Hamelin wrote:
> 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 sessio
m: Joe Hamelin [j...@nethead.com]
> Received: Montag, 15 Juni 2015, 19:51
> To: NANOG list [nanog@nanog.org]
> Subject: Anycast provider for SMTP?
>
> 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 ba
Well we, Genuity, use to use Cisco Distributed Director to do this. Basically
it was a DNS server that ran on a Cisco Router, and could use a lot of
different metrics to give an answer, which included routing based metrics.
Johno
> On Jun 15, 2015, at 1:50 PM, Joe Hamelin wrote:
>
> I h
Received: Montag, 15 Juni 2015, 19:51
To: NANOG list [nanog@nanog.org]
Subject: Anycast provider for SMTP?
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
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 co
69 matches
Mail list logo
