Re: BGP announcements and small providers

[Dean Gaudet <dgaudet () arctic org>]

Navigator versions up to and including 3.01 (excluding a special release
version made for @home) do not go rotate through the A records.  If the
first one fails they don't bother with the rest.

MSIE 3.0 does time out and try later addresses (although it seems to
have a silly bug where it displays the wrong address in the status line
at the bottom).

Navigator also exhibits another problem (I'm not sure if MSIE has this
problem or not, it probably does).  It caches DNS results forever.
I've renumbered web servers, done the ttl game, and seen traffic at the
old ips three weeks after the change "should" have propagated everywhere
and the old records timed out everywhere.  I'm guessing people running
unix boxes who don't restart their browser...

Assuming you don't have an address 10.10.10.10 on your network you can
try <http://rotate.arctic.org/~dgaudet/blank>.

Dean

On Tue, 25 Feb 1997, Matt Ranney wrote:

> On Tue, 25 Feb 1997, Alex.Bligh wrote:
>
> [...]
> > Swamp /24, or use most of a /18|/19 underutilized, or better use more
>
> Given current address allocation policies, how are you supposed to go
> about getting a /19 to waste in the first place?
>
> > intelligence than "just" BGP - for instance Paul Vixie's stuff at the
> > last NANOG.
>
> Paul's solution certainly adds more reliability as long as the clients
> doing the connecting do the right thing WRT rotating through the A
> records for your servers.  As far as I can tell, it still doesn't do
> anything to solve the problem of choosing the "best" interface for the
> connection to happen on.  Obviously the definition of "best" is up for
> debate, but if the squid machine was doing BGP, there would at least
> be some path optimization done.  
>
> As it is, if the interface-defaulted squid machine was dual-homed to
> providers X and Y that don't peer, a customer of X could get the A
> record for the interface in Y's space.  The client would then have to
> take the transit path between X and Y, which for many X's and Y's,
> sucks.  If the dual-homed machine was doing BGP, the customer of X
> would always use the interface on X's side, and vice versa.
>
> Of course, we all know that we need to aggregate, shrink the routing
> table, shrink peer lists, etc., and Paul's solution certainly wins
> in that repect.  
> --
> Matt Ranney - mjr () ranney com
>
> This is how I sign all my messages.

- - - - - - - - - - - - - - - - -