Re: CSS11500 rule matching breaks

Hello Steven,

This sounds like it may be an "attention span" problem. See here: 
http://lbdigest.com/2008/11/20/when-your-load-balancer-has-a-short-attention-span/

The CSS would match against the URL in the first HTTP request, and send 
all subsequent HTTP requests from the same TCP connection to that 
server.  If a subsequent HTTP request should have matched to another set 
of servers, it would be ignored if the CSS is only paying attention to 
the first HTTP request.
I'm not sure if the CSS can be configured to look at all HTTP requests 
in an TCP connection (it's been a while since I've been hands-on with a 
CSS), but a quick workaround is to turn KeepAlive off on the servers.  
This may impact performance on the servers a bit (so of course, be 
careful), but it will force only one connection per HTTP request, and 
the CSS would look at every HTTP request.

-Tony



Steven Fletcher wrote:
> 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 accepta!
 nce 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