Re: [load balancing] CSS11500 rule matching breaks

From: Jason Edgerton <edgerton_jason [izzat] hotmail.com>
Date: Wed Feb 18 2009 - 13:42:50 EST

Since the default of persistence enabled mandates that connections will use the same service that they were directed to initially for the life of the flow table entry it makes sense to me that making port 80 flows permanent mitigates your issue. Since the flow table entry doesn't disappear the CSS doesn't need to make a load balancing decision. That would be if the clients were using http1.1. For http1.0 it would be a different story.

I don't know an authoritative way to determine if the spanning packet issue is what you are encountering without looking at a packet capture. Can you see the cookie that the client is using in the logs of the servers that are getting the wrong content requests? If you could determine that all of the misguided content requests had a large cookie as a commonality that would be a case for the spanning packet problem.

> From: sfletcher@dabs.com
> To: lb-l@vegan.net
> Date: Wed, 18 Feb 2009 17:02:07 +0000
> Subject: [load balancing] CSS11500 rule matching breaks
>
> 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: sfletcher@dabs.com
>
>
>
> 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:assistance@dabs.com.
>
>
> _______________________________________________
> lb-l mailing list
> lb-l@vegan.net
> 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

_________________________________________________________________
Stay up to date on your PC, the Web, and your mobile phone with Windows Live.
http://clk.atdmt.com/MRT/go/msnnkwxp1020093185mrt/direct/01/

_______________________________________________
lb-l mailing list
lb-l@vegan.net
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
Received on Wed Feb 18 13:42:49 2009

This archive was generated by hypermail 2.1.8 : Wed Feb 18 2009 - 13:42:49 EST