Re : CSS11500 rule matching breaks

As tony said, the default behavior for L7 load balancing is to take load decision on the first request in a TCP session. After the descision is made there is a fast path written in the data plane and all the requests in this TCP session goes to the same server.

So if you use L7 switching (based ont the URL or something else) it will not work if multiple requests are present in the same TCP session. You can break the "fast path" but then all requests will be processed by the control plane (CPU). In the ACE this problem is solved by using the "persistence rebalance" feature.

In the CSS the solution seems to be described here :

http://www.cisco.com/en/US/products/hw/contnetw/ps792/products_tech_note09186a0080093e06.shtml

regards,

Surya

--- En date de : Mer 18.2.09, Steven Fletcher <[email protected]> a écrit :
De: Steven Fletcher <[email protected]>
Objet: [load balancing] CSS11500 rule matching breaks
À: "[email protected]" <[email protected]>
Date: Mercredi 18 Février 2009, 18h02

Hi all,

I hope someone can help - I've had a search through the list archives but
can't seem to find anything relevant to my situation, so here goes.

We have 2 CSS11503's running WebNS 8.20.2.01, which are configured in
redundancy mode. All traffic flows over a 1Gig interface on the SCM which is
split into three VLAN circuits - one for the public side, one for the private
side, and one for the redundancy protocol.

There are quite a number of content rules active, most of which involve Layer 5
header and wildcard URL inspection. The problem we're having is that very
occasionally the CSS will direct incoming HTTP requests to the wrong service,
i.e. the request appears to be matched against the wrong rule. Basically we see
requests for URL's on servers that should never have received those
requests, because the content rule URL pattern did not match the request
pattern.

>From reading the documentation, I know that there are software requirements
which mean that the CSS will only look at the first 6-20 packets of a request
before making a switching decision (the spanning-packets parameter), but I'm
stumped on how I can actually prove that the erroneous requests are in fact
spanning more than the configured number of packets.

Moreover, the problem is very much lessened, although not completely solved,
when we add the configuration command "flow permanent port1 80" to our
setup. Unfortunately I don't know what's going on inside the box to
determine precisely *why* this command is having such an effect.

Has anyone suffered from this problem before and can you help me with any
workarounds? (Or is it that we're just doing something very stupid?)....

I'd be willing to post excerpts of the configuration files, if necessary.

Many thanks for reading,

Steven




--------------------------------------------------------------------------
Steven Fletcher
Senior Systems Support Technician
dabs.com plc
http://www.dabs.com/

Tel: 0870 429 3488
Fax: 0870 429 7488
Mobile: 0781 258 4132
Email:  [email protected]



The information in this e-mail (which includes any files transmitted with it)
is intended for the addressee only. Access to this e-mail by anyone else is
unauthorised. If you have received this e-mail in error please notify us
immediately, destroy any copies and delete it from your computer system. Any
use, dissemination, forwarding, printing or copying of this e-mail is
prohibited. Copyright in this e-mail and any document created by us and sent as
an attachment to this e-mail will be and remain vested in us and will not be
transferred to you. We assert the right to be identified as the author of and to
object to any misuses of the contents of this e-mail or such documents. Whilst
we run anti-virus software on all internet e-mails we are not liable for any
loss or damage. The recipient is advised to run their own anti-virus software.
Nothing in this e-mail or any attachment shall be an acceptance of any offer
previously made nor shall be itself an offer capable of acceptanc!
 e to form a legally binding contract. dabs.com plc, Registered in England
number 2621728. Registered Office: NLC, Wingates Industrial Estate,
Westhoughton, Bolton, BL5 3XU. Contact mailto:[email protected].


_______________________________________________
lb-l mailing list
[email protected]
http://vegan.net/mailman/listinfo/lb-l
Searchable Archive: http://vegan.net/lb/archive
http://lbdigest.com Load Balancing Digest
http://lbwiki.com Load Balancing Wiki

_______________________________________________
lb-l mailing list
[email protected]
http://vegan.net/mailman/listinfo/lb-l
Searchable Archive: http://vegan.net/lb/archive
http://lbdigest.com Load Balancing Digest
http://lbwiki.com Load Balancing Wiki