Cisco Distributed Director

[Dan Considine]

Yes, the LD might be the answer. But unfortunately, this is the environment that was
handed off to us.  DNS and the DD work fine until there's a mass rush for ip's,
this is what's happening when we restart our socks servers.  All the connections are
dropped,  3,000 clients start looking for ip's right away..

Thanks again,

Dan..


Kevin Darcy wrote:

> IMHO, if one's load-balancing needs are so rigorous that they require sub-second
> volatility, then perhaps one shouldn't be using a DNS-based load-balancing
> mechanism at all. DNS is already burdened enough without having scads of TTL 0
> RR's forcing servers to work overtime. I see that Cisco also sells
> LocalDirector, which load-balances transparently without relying on DNS. (Note
> that I've never used either product, so don't take this as an endorsement).
>
> - Kevin
>
> Werner Wiethege wrote:
>
> > On Fri, 16 Jun 2000, Barry Margolin wrote:
> >
> > > Since your TTL is 0 seconds, the caching nameserver shouldn't actually
> > > cache the record.  It should forward it to the client machine, and then
> > > discard it.  The next time a client tries to look it up, the caching server
> > > should go back to the DD.  If you have even load balancing configured on
> > > the DD, it should alternate which address it gives out each time.  AFAIK,
> > > the fact that all the queries are coming from the same nameserver shouldn't
> > > matter.
> >
> > The BIND 8.2.3T5B code checks for staleness of a record with the
> > following comparison (in function stale in ns_eq.c):
> >                   dp->d_ttl >= (u_int32_t)tt.tv_sec
> > where d_ttl is the time when a record expires and tv_sec the current
> > time. I assume older versions have the same kind of check.
> > Considering records to be valid as long as the times in seconds are
> > the same can explain the behaviour that a caching nameserver keeps
> > returning the same value for almost a second when the TTL is 0.
> > Tests done by Pete Taylor where he left out the equal sign have
> > shown the expected behaviour for TTL 0.
> > Does TTL have inclusive or exclusive interpretation in the standards
> > or is it an implementation issue?
> >
> > Werner