Forum Discussion

benoit_9199's avatar
benoit_9199
Icon for Nimbostratus rankNimbostratus
Mar 05, 2009

persist source_addr in iRule ... doesn't persist

Hi,

I have the following iRule: 

  
  when HTTP_REQUEST {  
  if { [HTTP::uri] ends_with "/" or [HTTP::uri] contains "cgi-bin/" or [HTTP::uri] contains ".dyn" } {  
   dynamic content, use default pool  
  if { [matchclass [HTTP::host] contains $::high_traffic_site] } {  
                           case 1a: special high traffic vhost, maximise pool usage:  
  persist source_addr 255.255.255.255 3600  
  } else {  
                           case 1b: normal low traffic vhost, limit pool usage (one vhost to 
                           one node) to maximise backend cache 
  persist hash [crc32 [domain [HTTP::host] 2]] 3600  
  }  
  } else {  
   case 2: static content, goes directly to pool_static with no persistence  
  pool pool_static  
  }  
  }

cases 1b and 2 work perfectly, however case 1a is weird, when tracking the backend node used

i see two node used per source ip. Eg: request 1 goes to 10.0.0.21, request 2 to 10.0.0.26, request 3 back to 10.0.0.21, etc...
application delivery
dev
devops
iRules

6 Replies

Sort By
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Mar 06, 2009
    Do you actually see case 1a being hit? You can check this by adding logging in the iRule. If so, do you see a persistence record created for the client? You can check under Statistics >> Persistence or via the command line using 'b persist all show all'?

     

     

    Aaron
  • benoit_9199's avatar
    benoit_9199
    Icon for Nimbostratus rankNimbostratus
    Mar 06, 2009

     

    Yes, i used to log case 1a and it was reached, and Statistics >> Persistence give:

     

    82.XXX.YYY.ZZZ Source Address Affinity vs_customers pool_web 10.2.2.26:80 7 seconds

     

    82.XXX.YYY.ZZZ Source Address Affinity vs_customers pool_web 10.2.2.18:80 8 seconds

     

     

    Two entries with the same source ip address

     

     

    Also, there used to be a third (and initial entry) to 10.2.2.6:80 which disapeared after less that 30s
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Mar 06, 2009
    Which LTM version are you running? Is CMP enabled on the VIP? If so, check SOL7751 (Click here) for details.

     

     

    Aaron
  • benoit_9199's avatar
    benoit_9199
    Icon for Nimbostratus rankNimbostratus
    Mar 06, 2009

     

    Hi,

     

     

    I have a BIG-IP 3600 with LTM 9.4.6 Build 401.0 Final.

     

     

    Te virtual server does show "CMP: enable".

     

    However according to SOL7751 it shouldn't since i have an iRule that use session persistence, shouldn't it ?

     

     

    I have even set-up a default persistence profil of source_addr with the web interface and it still have CMP: enable ...

     

  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Mar 09, 2009
    SOL7751 solution states:

     

     

     

    If a virtual server references any of the following BIG-IP system features, CMP is disabled for that virtual server and handled by TMM0 only:

     

     

    A session persistence profile or iRule

     

     

    Note: Session Persistence is any persistence method that requires the BIG-IP system to track session data in memory, such as Destination Address Affinity, Microsoft Remote Desktop, SIP, Source Address Affinity, SSL, Universal.

     

     

     

     

    So maybe there is a problem where CMP isn't automatically disabled on the VIP? If you manually disable CMP on the VIP, does the persistence work? If so, I'd suggest opening a case with F5 Support to document the problem. And actually, either way it would be good to open a case to have F5 help troubleshoot the problem(s).

     

     

    Aaron
  • Deb_Allen_18's avatar
    Deb_Allen_18
    Historic F5 Account
    Mar 09, 2009
    Check out AskF5 SOL9628: The BIG-IP system does not update a virtual server's CMP status Click here

     

     

    We've just observed the same issue with iRules which invoke the session command.

     

     

    It apparently can happen both when updating iRules from the GUI or CLI or via iControl: Until the new configuration is actually loaded (b load or Update on the affected virtual server config in the GUI), the bigpipe parser has not yet run against the new virtual server configuration. Once it does, the VS is appropriately demoted. Until then, although the CMP-incompatible iRule has been added to the running config, the VS is not demoted. Connections are distributed across all TMMs, & global values such as session table & global vars are instantiated and maintained separately on all TMMs.

     

     

    Working on a solution update to include more specific information on this phenomenon. The CR mentioned only seems to have dealt with the global var handling, so will be following up on session /rateclass / anything else that might not forcing demotion when added via iRules.

     

     

    /d