RE: [load balancing] Alteon - Client Web Proxy Problems

From: Pete Tenereillo (ptenereilloIZZATadelphia.net)
Date: Thu Jul 15 2004 - 11:37:19 EDT

Next message: Frank Yue: "RE: [load balancing] ServerIronXL - Real servers failing L4 check for no apparent reason"

Previous message: Basil Hussain: "RE: [load balancing] ServerIronXL - Real servers failing L4 check for no apparent reason"
Maybe in reply to: Giorgio Solari V.: "[load balancing] Alteon - Client Web Proxy Problems"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Lance, again I did not intend for this message to be broadcast. Your
specific question is covered in the papers referenced below.

If your customers understand the caveats and complexity, yet still choose to
use that method, then you have served them well. Faced with the alternative
of modifying site architecture, many customers knowingly make that choice,
though from what I've seen, usually only as an interim solution to an
unexpected problem.

Pete.

_____

From: owner-lb-lIZZATvegan.net [mailto:owner-lb-lIZZATvegan.net] On Behalf Of Lance
McCallum
Sent: Thursday, July 15, 2004 7:20 AM
To: lb-lIZZATvegan.net
Cc: lb-lIZZATvegan.net
Subject: RE: [load balancing] Alteon - Client Web Proxy Problems

Pete,

Did you write up an analysis on the weakness of site cookies and HTTP certs
for site-specific domain names? I have been involved in several
e-commerce deployments that required persistence and we have had good
success with this solution.

Maybe we are doing something different or we are not addressing the
specific issue you have uncovered.

At 01:55 PM 7/14/2004 -0700, Pete Tenereillo wrote:

OK, looks like you just changed it now, in fact I can t even get to the
CNAME any more, but the more basic question I guess do you have the Alteons
themselves configured for RR? i.e. do you intend to balance traffic between
sites? If so, you are going to definitely have issues with some ISPs/caches.
It s pretty much the opposite problem to that described in the documents.
The silver lining in the browser DNS cache is that it provides 30 min of
persistence for free . Sounds like this problematic proxy is not one of
those that caches TTLs for a fixed amount of time.

There is a feature called DNS persistence that is available in the Alteon
Content Director, but not in the standard WebOS. If you are OK with using
single A records, that is probably what you need. I wrote a post that
described it some time ago.

There s also a really stupid solution peddled mostly by F5 et all which uses
site cookies and HTTP certs for site-specific domain names. Alteon can offer
this too with the integrated SSL offloader or even the standalone appliance,
but they don t really push it and I m not sure it 100% works yet (there were
issues when I left the company).

Pete.

_____

From: owner-lb-lIZZATvegan.net [mailto:owner-lb-lIZZATvegan.net] On Behalf Of
Giorgio Solari V.
Sent: Wednesday, July 14, 2004 1:35 PM
To: lb-lIZZATvegan.net
Subject: RE: [load balancing] Alteon - Client Web Proxy Problems

Hi Pete, the configuration is set to answer only one IP. Thanks for the
documents. But the problem persist.

On Wed, 2004-07-14 at 15:24, Pete Tenereillo wrote:

Giorgio, I just did a sniff, you are returning multiple A records on each
resolution (the default on the Alteon, and most GSLBs for that matter).
Likely either BIND on the Squid box, or the caching nameserver the Squid box
is pointed at, is RRing those. You can shut off multiple A records on the
Alteons, using the command:

/cfg/slb/gslb/one

but then you will need to live with a reduced level of HA described here:
http://www.tenereillo.com/GSLBPageOfShame.htm
Given it's ScotiaBank, HA is probably the primary objective of doing
multisite in the first place.

You can mitigate those potential problems somewhat by doing something like
this:
http://www.tenereillocom/ShoppingCart.htm
<http://www.tenereillo.com/ShoppingCart.htm>
but you would still need to return single A records for the site-specific
URLs (or you would be back to the original issue).

The only bulletproof solution is to sync state between sites so that it does
not matter what site a subsequent SSL session goes to. I know that's tough
to do right.

Pete.

_____

From: owner-lb-lIZZATvegan.net [mailto:owner-lb-lIZZATvegan.net] On Behalf Of
Giorgio Solari V.
Sent: Wednesday, July 14, 2004 11:25 AM
To: lb-lIZZATvegan.net
Subject: [load balancing] Alteon - Client Web Proxy Problems

Hello to all people. I nedd great aid. I formed two Alteon Application
Switch 2208 (Version 21.0.4) successfully doing GSLB. The services are http
and https. The problem I have is from certain clients that are behind some
Web Proxy. Those proxy do not maintain the ssl (tcp) connection, changing
the servant to the other alteon.

Let me show a real log from a Squid proxy server which have the problem:

1089670996.757 7955 191.1.200.203 TCP_MISS/200 564 CONNECT
test.scotiabank.cl:443 - DIRECT/200.14.209.102 -
1089670998.789 983 191.1.200.203 TCP_MISS/200 3145 CONNECT
test.scotiabank.cl:443 - DIRECT/200.14.209.102 -
1089671010.119 7658 191.1.200.203 TCP_MISS/200 2160 CONNECT
test.scotiabank.cl:443 - DIRECT/200.14.209.102 -
1089671010.550 8564 191.1.200.203 TCP_MISS/200 28085 CONNECT
test.scotiabank.cl:443 - DIRECT/200.14.209.102 -
1089671010.556 8306 191.1.200.203 TCP_MISS/200 32611 CONNECT
test.scotiabank.cl:443 - DIRECT/200.14.209.102 -
1089671010.556 8106 191.1.200.203 TCP_MISS/200 4071 CONNECT
test.scotiabank.cl:443 - DIRECT/200.14.209.102 -
1089671100.271 2795 191.1.200.203 TCP_MISS/200 3145 CONNECT
test.scotiabank.cl:443 - DIRECT/200.14.209.102 -
1089671118.082 16450 191.1.200.203 TCP_MISS/200 46618 CONNECT
test.scotiabank.cl:443 - DIRECT/200.14.209.102 -
1089671118.090 16229 191.1.200.203 TCP_MISS/200 14760 CONNECT
test.scotiabank.cl:443 - DIRECT/200.14.209.102 -
1089671118.090 11676 191.1.200.203 TCP_MISS/200 6357 CONNECT
test.scotiabank.cl:443 - DIRECT/200.14.209.102 -
1089671118.091 11675 191.1.200.203 TCP_MISS/200 760 CONNECT
test.scotiabank.cl:443 - DIRECT/200.14.209.102 -
1089671119.789 369 191.1.200.203 TCP_MISS/200 3145 CONNECT
test.scotiabank.cl:443 - DIRECT/200.14.209.102 -
1089671130.362 9426 191.1.200.203 TCP_MISS/200 9334 CONNECT
test.scotiabank.cl:443 - DIRECT/200.14.209.102 -
1089671130.384 9672 191.1.200.203 TCP_MISS/200 27865 CONNECT
test.scotiabank.cl:443 - DIRECT/200.14.209.102 -
1089671165.589 36409 191.1.200.203 TCP_MISS/200 27621 CONNECT
test.scotiabank.cl:443 - DIRECT/200.14.209.102 -
1089671165.603 36411 191.1.200.203 TCP_MISS/200 3721 CONNECT
test.scotiabank.cl:443 - DIRECT/200.14.209.102 -
1089671167.220 442 191.1.200.203 TCP_MISS/200 3157 CONNECT
test.scotiabank.cl:443 - DIRECT/200.55.208.28 -
1089671176.455 4578 191.1.200.203 TCP_MISS/200 5088 CONNECT
test.scotiabank.cl:443 - DIRECT/200.55.208.28 -
1089671176.519 39 191.1.200.203 TCP_MISS/200 39 CONNECT
test.scotiabank.cl:443 - DIRECT/200.55.208.28 -

I have tested a lot of proxy servers including squid, without problems.
Somebody can help me please?. This it is the only ponit of fail that I have.

Greetings.

-- Giorgio Solari V. <gsolariIZZATcientec.cl> Cientec S.A.

Lance McCallum

Product Line Manager

GSS and SCA

1414 Massachusetts

Avenue

Boxborough, MA

01719

Pager:800-365-4578

Phone:(978)-936-0998

____________________ 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

Next message: Frank Yue: "RE: [load balancing] ServerIronXL - Real servers failing L4 check for no apparent reason"
Previous message: Basil Hussain: "RE: [load balancing] ServerIronXL - Real servers failing L4 check for no apparent reason"
Maybe in reply to: Giorgio Solari V.: "[load balancing] Alteon - Client Web Proxy Problems"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

This archive was generated by hypermail 2.1.4 : Thu Jul 15 2004 - 11:48:55 EDT