|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: BGP announcements and small providers
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 - [email protected] > > This is how I sign all my messages. > > - - - - - - - - - - - - - - - - -
|