Forum Discussion

CraigM_17826's avatar
CraigM_17826
Icon for Altocumulus rankAltocumulus
Jul 25, 2012

Rather confusing pool behaviour and tmm error

Hi everyone,

 

 

I have run into two issues when migrating our BigIP iRule to our cloud providers BigIP. Our BigIP is still on LTM 10.2.3 Build 1120.Final and our cloud provider is on 11.0 Build 2179.0 HF3

 

 

 

Issue 1. I have some session persistance code in the iRule. This portion runs fine under 10.2.3 but returns a tmm error on the unit running 11.0

 

 

Here is the code

 

 

 

if { [string tolower [HTTP::cookie value "jsessionid"]] ne "" and $add_persist } {

 

persist add uie [HTTP::cookie "JSESSIONID"] 1800

 

set add_persist 0

 

}

 

and the error is

 

 

Jul 24 10:52:09 slot1/tmm1 err tmm1[8232]: 01220001:3: TCL error: - Illegal value (line 5) (line 5) invoked from within "persist add uie [HTTP::cookie "JSESSIONID"] 1800"

 

 

Issue 2.

 

This is a realy wobbly one because it is intermittent and can't be reproduced on demand.

 

Our website uses a product called Alterian. This replaced WebSphere. In turn, Alterian uses a mixture of Apache and Tomcat to serve the content. We also run a IIS server that hosts some content that has not been merged with the main website. To maintain the illusion the content is all coming from one URL we have the IIS box in it's own pool and then check for specifc URIs and pool to the IIS pool for the URIs the IIS server handles. This has worked fine, but since

 

 

a) running on LTM 11

 

b) using IIS 7.5 (previously we used IIS6)

 

 

in some rare cases a fully qualified URL on one of the pages being hosted the IIS server back to our main website (hosted on Alterian) would not work and the IIS server tried to answer the request and obviously fails because the URI does not exist on the IIS server. This is intermittent, say one in every 100 or so requests. Doing a browser refresh would cause the redirect to work as it sholuld.

 

 

 

To confirm the 404 page was comming from our IIS server I checked the IIS logs and found 404 entries in the log files for one of the IIS virtual servers we pool to. So that confirmed the 404 page was in fact comming from our IIS server

 

 

On our old test envionment I setup a IIS7.5 server to replicate the setup in the cloud and cannot get it to fail. The ony difference at this point is LTM 10 vs LTM11.

 

 

 

Out of desperation I added a catch all pool statement at the very end of the iRULE so anything that gets that far will pool to the Alterian server pool. I didn't have this in because the VIP running this site has the same pool set as the default pool. Once I did this all reports of this random break have stopped and the IIS logs are no longer reporting 404 errors for the URIs.,

 

 

 

Has anyone else run into this issue or something similar? Why would the catch all pool command at the end of the iRule have an effect when the default pool for the VIP is set to the same pool?

 

 

 

Any comments/thoghts most welcome.

 

 

Regards,

 

 

Craig

 

application delivery
dev
devops
iRules
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Jul 25, 2012
    Hi Craig,

    I think the HTTP::cookie command might be case sensitive. So you're checking if the jsessionid cookie is not null but then persisting on the JSESSIONID cookie value which might not exist or have a null value.

    Can you try this instead? 

    
if { [HTTP::cookie value "JSESSIONID"] ne "" and $add_persist } {
persist add uie [string tolower [HTTP::cookie "JSESSIONID"]] 1800
set add_persist 0 
}

    Also for L7 persistence or pool switching, you should use a OneConnect profile to ensure LTM performs per-request logic instead of connection based. As you're doing both this is particularly important.

    https://devcentral.f5.com/Wiki/default.aspx/AdvDesignConfig/OneConnect.htm

    Aaron
  • CraigM_17826's avatar
    CraigM_17826
    Icon for Altocumulus rankAltocumulus
    Aug 01, 2012

    Hi Hoolio,

     

    many thanks for your suggestions. With regard to the oneconnect profile, I do not know how I missed it but the VIPs used for internal connections had this enabled but the VIPs handling external connections did not and it was on the external connections this was happening. I was sure I compared both VIPs and couldn't see any difference. Time for new glasses. :(

     

    I'll try the modified cookie code and see how it goes.

     

    Regards,

     

     

    Craig

     

  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Aug 01, 2012
    Hi Craig,

     

     

    That sounds good. Let us know how the testing goes.

     

     

    Aaron