North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Anycast 101

  • From: Paul Vixie
  • Date: Fri Dec 17 13:44:28 2004

i don't think iljitsch is in a position to teach an "anycast 101" class.

here's my evidence:


From: Paul Vixie <[email protected]>
To: [email protected]
Subject: Re: [dnsop] Re: Root Anycast (fwd) 
X-Mailer: MH-E 7.4; nmh 1.0.4; GNU Emacs 21.3.1
Date: Mon, 04 Oct 2004 22:26:18 +0000
Sender: [email protected]
X-Evolution: 0000020e-0000

note-- harald asked us to move this thread off of [email protected], so i've done that.
iljitsch added [email protected] back to the headers in his reply to me.  i'm taking it
back off again.  iljitsch, please leave it off, respecting harald's wishes.

> ... It's possible for bad things to happen if:
> 1. some DNS server is anycast (TLD servers are worse than roots because the
> root zone is so small)
> 2. fragmented UDP packets or TCP are used as a transport
> 3. a network is built such that packets entering it through router X may
> prefer a different external link towards a certain destination than packet
> entering it through router Y
> 4. a customer of this network is connected to two different routers
> 5. the customer enables per packet load balancing

#1 and #2 are normal, even though fragmented udp isn't very common nowadays.
#3 is extremely common.  #4 is normal for high-end customers.  and #5 will
only affect customers whose ISP shares an IGP with the anycast -- in other
words, "other customers of the same ISP".  if this problem erupts, the ISP
will take care of it.  it's not an internet-level (BGP-level) problem at all.

> Now the question is: how do we deal with this? I don't think removing
> anycast wholesale makes sense and/or is feasible. Same thing for declaring
> per packet load balancing an evil practice.

as i said the other day, "all power tools can kill."  if you turn on PPLB
and it hurts, then turn it off until you can read the manual or take a class
or talk to an expert.  PPLB is a link bundling technology.  if you turn it
on in non-parallel-path situation, it will hurt you, so, "don't do that."

> A better solution would be to give network operators something that
> enables them to make sure load balancing doesn't happen for anycasted
> destinations. A good way to do this would be having an "anycast" or
> "don't load balance" community in BGP, or publication of a list of
> ASes and/or prefixes that shouldn't be load balanced because the
> destinations are anycast.

since PPLB won't affect BGP (since BGP is not multipath by default), this is
not an issue.

> > and they would know that PPLB is basically a link bundling technology used
> > when all members of the PPLB group start and end in the same router-pair;
> It doesn't make much sense to have multiple links terminate on the same
> router on both ends as then both these routers become single points of
> failure.

i don't even know what conversation we're in any more.  why does it matter
whether they are single points of failure, if this is the configuration for
which PPLB was intended?  if you have two 155Mbit/sec links and you want to
be able to treat them as a 310Mbit/sec link rather than upgrading them to
a single 622Mbit/sec link, then PPLB is a godsend.  otherwise, don't use it.

> Often, the end sending out most traffic will have the links terminate
> on one router (so load balancing is possible) while the other ends of
> the links terminate on two or more routers.

there are other safe configurations for PPLB, to be sure.  turning it on
toward your transits and doing PPLB among two default routes, and turning
it on toward your transits and turning on BGP multipath, are not two of them.

the fact that an unsafe configuration can be built using PPLB is not news,
since as we all know, "all power tools can kill."

Paul Vixie