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

From: P (
Date: Tue Jan 27 2004 - 13:02:35 EST

  • Next message: Andy Gravett: "RE: [load balancing] Load Balancer Evaluation: Which would you pick?"


    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, and DNS persistence is used, all subsequent
    DNS requests from DNS server 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


    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: [] On Behalf Of Jay
    Sent: Tuesday, January 27, 2004 6:32 AM
    Subject: RE: [load balancing] Global Server Loadbalanicing with CISCO CSS

    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
    Internet Systems Business Unit
    1414 Massachusetts Avenue
    Boxborough MA 01719
    Office 978-936-0930
    Mobile 857-498-1818

    -----Original Message-----
    From: [] On Behalf Of
    Sent: Tuesday, January 27, 2004 8:39 AM
    Subject: [load balancing] Global Server Loadbalanicing with CISCO CSS

    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

    Visit our homepages:

    The Load Balancing Mailing List
    MRTG with SLB:
    Hosted by:

    The Load Balancing Mailing List
    MRTG with SLB:
    Hosted by:

    The Load Balancing Mailing List
    MRTG with SLB:
    Hosted by:

    This archive was generated by hypermail 2.1.4 : Tue Jan 27 2004 - 13:18:42 EST