RE: [load balancing] Global Server Loadbalanicing with CISCO CSS 11503

From: P (pt_lbIZZAThotmail.com)
Date: Thu Jan 29 2004 - 11:28:48 EST

  • Next message: Thomas Krwawecz III: "[load balancing] Route Optimizers, BIG-IP Link Controller"

    IE has a built in DNS cache (the one you are referring to below), but
    Windows2K and later have an additional system-wide DNS cache.

    Supposedly you can shut it off as follows:
    http://support.microsoft.com/default.aspx?scid=kb;en-us;318803

    Pete.

    -----Original Message-----
    From: owner-lb-lIZZATvegan.net [mailto:owner-lb-lIZZATvegan.net] On Behalf Of Claret
    Carvalho
    Sent: Wednesday, January 28, 2004 9:34 PM
    To: lb-lIZZATvegan.net
    Subject: Re: [load balancing] Global Server Loadbalanicing with CISCO CSS
    11503

    Has anyone had any luck with changing the below registry settings for DNS
    Cache Timeout in IE as has been posted on Microsoft ? I have tried it on IE
    5.0 on XP and it did not seem to have any effect.

    >>>>
    In most cases, 30 minutes is a reasonable setting. In situations where you
    have a lot of clients all doing numerous DNS queries, however, that time
    limit might be too short and you're seeing too much unnecessary DNS traffic
    on the network. In that case, you can increase the DNS cache timeout period.
    To do so, open the Registry Editor and browse to the HKEY_CURRENT_USER\
    Software\ Microsoft\ Windows\ CurrentVersion\ Internet Settings branch. Add
    the value DnsCacheTimeout as a DWORD and set it to the number of seconds the
    cached entries should be maintained.
    <<<<<<

    Thanks,
    Claret
    ----- Original Message -----
    From: "P" <pt_lbIZZAThotmail.com>
    To: <lb-lIZZATvegan.net>
    Sent: Tuesday, January 27, 2004 12:02 PM
    Subject: RE: [load balancing] Global Server Loadbalanicing with CISCO CSS
    11503

    > Giuseppe,
    >
    > This is of course a very old problem, with many solutions out there, but
    > also many associated problems with those solutions.
    >
    > The most recent solution is usually referred to as "DNS persistence".
    Alteon
    > (ACD) and F5 (3DNS) already have this feature, I'm quite certain Cisco and
    > everyone else will add it soon. It is definitely useful, only a slight
    > departure from existing functionality, and not a big deal to implement.
    > Older solutions include proxy/NAT (i.e. just load-balance the request to
    the
    > other site as if that site were a local real server), triangulation, and
    > HTTP redirection. Most GSLB solutions support at least a couple of these
    > older methods.
    >
    > Here's how DNS persistence works in a nutshell:
    >
    > The GSLB device uses a function similar to source IP address persistence
    in
    > local load balancing, remembering IP address affinities and distributing
    > those to all devices that act as authoritative nameservers for the sites
    to
    > be GSLBed. For example, if a client's DNS server ("local DNS server" or
    > whatever you want to call it - the one the client gets assigned at DHCP
    > time) has IP address 1.1.1.1, and DNS persistence is used, all subsequent
    > DNS requests from DNS server 1.1.1.1 will be directed to the same site for
    > some amount of time, usually a rolling timer that expires only after a
    > period of inactivity (also can work for network 1.1.1.x or 1.1.x.x or
    > whatever). Now of course DNS persistence can in theory be subject to all
    of
    > the problems that source IP address persistence is subject to ("AOL
    > problem", "megaproxy problem", details of which are widely available), but
    > in practice it is not nearly as likely that a client DNS request gets
    > "megaproxied". Also DNS persistence can be layered on top of another
    > persistence method such as 302 redirection, proxy, NAT, or triangulation,
    > and greatly reduce the side effects of these.
    >
    > I don't recommend the 302 redirect, proxy/NAT, or triangulation solutions
    > standalone, especially for sites with typical session times longer than 30
    > minutes. All of these, especially proxy/NAT/triangulation, add significant
    > overhead. Here's why: they "only" redirect when a client ends up on the
    > wrong site, but if the application is such that the typical user session
    is
    > longer than the browser DNS cache timeout (30 minutes IE, 15 minutes
    > Netscape), then the number of clients that get
    > redirected/proxied/NATed/triangulated will quickly get very, very,
    > significant. (Note: Such persistence mechanisms are often used in
    > conjunction with proximity metrics, but proximity metrics do not in
    practice
    > select the same site with nearly enough consistency to be considered
    > reliable for persistence). All of these, especially
    NAT/proxy/triangulation
    > add overhead in such situations. The 302 redirect solution is slightly
    more
    > efficient than NAT/proxy/triangulation because it acts as a handoff rather
    > than a change in flow of all subsequent connections, but can be a bit
    messy
    > because it requires the use of unique FQDNs at each site. These unique
    FQDNs
    > cause client bookmark issues and, for sites that use SSL, requires the
    > purchase of additional certificates for each site (effectively doubling
    the
    > total certificate expense). Triangulation adds the additional headache of
    > convincing your provider, co-lo, etc. to allow your equipment to spoof
    > outbound IP address.
    >
    > So I would suggest bugging Cisco until they give you DNS persistence in
    the
    > CSS!
    >
    >
    >
    > Pete.
    >
    >
    > PS For anyone who is interested - I wrote up a paper when I worked at
    Alteon
    > that explains this issue in detail (information applies to any product,
    > obviously the punch line is "buy Alteon" but the general info is there).
    It
    > has diagrams, detailed step-by-step examples, etc. explaining all this.
    That
    > paper is the property of Alteon - if you are nice to him maybe our friend
    > Giles Scott will e-mail it to you.
    >
    >
    > -----Original Message-----
    > From: owner-lb-lIZZATvegan.net [mailto:owner-lb-lIZZATvegan.net] On Behalf Of Jay
    > Cedrone
    > Sent: Tuesday, January 27, 2004 6:32 AM
    > To: lb-lIZZATvegan.net
    > Subject: RE: [load balancing] Global Server Loadbalanicing with CISCO CSS
    > 11503
    >
    > Giuseppe,
    > There is a feature you can turn on the CSS call "location cookie" which
    > will set a cookie for the datacenter (slb) and if a user were to
    > re-resolve, and show up at the wrong datacenter, the CSS would then
    > either redirect (302) back to the correct datacenter or NAT the request
    > back to the correct datacenter.
    >
    > - Jay
    >
    > Jay Cedrone
    > CISCO SYSTEMS INC
    > Internet Systems Business Unit
    > TME
    >
    > 1414 Massachusetts Avenue
    > Boxborough MA 01719
    >
    > Office 978-936-0930
    > Mobile 857-498-1818
    > EMAIL jcedroneIZZATcisco.com
    > EPAGE jcedroneIZZATepage.cisco.com
    >
    >
    > -----Original Message-----
    > From: owner-lb-lIZZATvegan.net [mailto:owner-lb-lIZZATvegan.net] On Behalf Of
    > casablancagIZZATpost.ch
    > Sent: Tuesday, January 27, 2004 8:39 AM
    > To: lb-lIZZATvegan.net
    > Subject: [load balancing] Global Server Loadbalanicing with CISCO CSS
    > 11503
    >
    >
    > Hi
    > I have two aactive sites, where a make a global loadbalancing with two
    > Cisco CSS 11503. If I make a witch over of one site, the DNS Record will
    > be updated and the traffic will be directed too the other site. But If
    > the browser or the dns servers cache the DNS-Records then the client
    > still have the old record with the wrong Information and the traffic
    > will be directed too the old Site where no server will answer the
    > request. Does anybody have a suggestion ????
    >
    > Thank you in advance
    >
    > Giuseppe Casablanca
    > Dipl. Inf. Ing. FH
    >
    > Network Access Solutions
    >
    > Die Schweizerische Post
    > Information Technology Services
    > Webergutstrasse 12
    > CH-3030 Bern (Zollikofen)
    >
    > Tel. +41 (0)31 338 67 73
    > Fax +41 (0)31 338 95 70
    > Mailto: casablancagIZZATpost.ch
    >
    > Visit our homepages:
    > Intern: http://pww.post.ch/oe/IP/corp/index.htm
    > Extern: http://www.post.ch
    >
    >
    >
    > ____________________
    > The Load Balancing Mailing List
    > Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
    > Archive: http://vegan.net/lb/archive
    > LBDigest: http://lbdigest.com
    > MRTG with SLB: http://vegan.net/MRTG
    > Hosted by: http://www.tokkisystems.com
    >
    > ____________________
    > The Load Balancing Mailing List
    > Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
    > Archive: http://vegan.net/lb/archive
    > LBDigest: http://lbdigest.com
    > MRTG with SLB: http://vegan.net/MRTG
    > Hosted by: http://www.tokkisystems.com
    >
    > ____________________
    > The Load Balancing Mailing List
    > Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
    > Archive: http://vegan.net/lb/archive
    > LBDigest: http://lbdigest.com
    > MRTG with SLB: http://vegan.net/MRTG
    > Hosted by: http://www.tokkisystems.com
    >

    ____________________
    The Load Balancing Mailing List
    Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
    Archive: http://vegan.net/lb/archive
    LBDigest: http://lbdigest.com
    MRTG with SLB: http://vegan.net/MRTG
    Hosted by: http://www.tokkisystems.com

    ____________________
    The Load Balancing Mailing List
    Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
    Archive: http://vegan.net/lb/archive
    LBDigest: http://lbdigest.com
    MRTG with SLB: http://vegan.net/MRTG
    Hosted by: http://www.tokkisystems.com



    This archive was generated by hypermail 2.1.4 : Thu Jan 29 2004 - 11:44:34 EST