anycast (Re: .ORG problems this evening)

Thu Sep 18 18:01:07 UTC 2003

> Date: Thu, 18 Sep 2003 13:47:01 -0400
> From: Keptin Komrade Dr. BobWrench III esq.

> And, I might add, in the case of a highly complex anycast
> application, you will need to check not only for correctness,
> but for timeliness.

In a realtime system, something that is late is considered
incorrect.  A DNS response that arrives after three seconds is
unsat, and (from a RT perspective) incorrect.  I should have been
more clear in my wording.

> And, again, in the case of a highly complex app such as an
> anycast DNS, you need to check several behind the scenes apps,
> such as maybe a db, the responsivness of your high avail
> partner server, the dns daemon, connectivity through two or
> more network paths, connectivity to master update servers, BGP
> on whatever boxes are providing BGP, etc, the list goes on.

Yes on all counts, except perhaps connectivity... BGP handles
that.  If you mean killing the link in case of saturation, I'd
argue that's a bad idea -- that just means the large traffic
quantity will go elsewhere.

> But again, that's just my opinion, I could be wrong. ;-)

That's why one uses a daemon with main loop including something
like:

	success = 0 ;
	for ( i = checklist ; i->callback != NULL ; i++ )
		success &= i->callback(foo) ;
	if ( success )
		send_keepalive(via_some_ipc_mechanism) ;

The BGP mechanism listens for keepalives via the IPC mechanism.

Eddy
--
Brotsman & Dreger, Inc. - EverQuick Internet Division
Bandwidth, consulting, e-commerce, hosting, and network building
Phone: +1 785 865 5885 Lawrence and [inter]national
Phone: +1 316 794 8922 Wichita
_________________________________________________________________
          DO NOT send mail to the following addresses :
  blacklist at brics.com -or- alfra at intc.net -or- curbjmp at intc.net
Sending mail to spambait addresses is a great way to get blocked.