Forum Discussion

5 Replies

  • unRuleY_95363's avatar
    unRuleY_95363
    Historic F5 Account
    The following instances of the persist command select persist:

    NOTE: items marked with are meant to be replaced with some sort of value or evaluated expression. Arguments bracketed by [] are used to note they are optional and should not be confused with Tcl command evaluation.

      
      persist simple [] []        
      persist source_addr [] []        
      persist sticky [] []        
      persist dest_addr [] []        
      persist ssl []        
      persist msrdp []        
      persist cookie [insert [] [] |        
                      rewrite [] [] |        
                      passive [] |        
                      hash  [{  [] } []] ]        
      persist uie  []        
      persist hash  []        
      

    The following instances of the persist command can be used to manipulate the persistence table directly:

      
      persist add   []        
      persist lookup   [all|node|port|pool]  
        "all" or no specification returns a list containing        
        the node, port and pool name.  Specifying any of the other        
        return types will return the specified item only.        
                    
      persist delete          
          = simple | source_addr | sticky | dest_addr | ssl | uie | hash        
          =  |        
               {  [any virtual|service|pool] [pool ] }        
        the latter key specification is used to create/access        
        persist entries across virtuals, services, or pools.        
      

  • unRuleY_95363's avatar
    unRuleY_95363
    Historic F5 Account
    This is a great question! We have been expecting that it would probably be asked at some point.

    When redesigning v9, we went back and forth on the issue about moving the configuration of persistence from the pool to profiles.

    However, we believe the new flexibility afforded with the new profiles architecture outweighed the slight inconveniece and relearning that would be required for this one case.

    You are actually very close and a few additional details will undoubtably get you going.

    Basically, there are two ways to configure persistence: 1) via the persistence profile on the virtual; and 2) via the persist command in a rule. These two methods are not necessarily exclusive and often will work in conjunction to give explicit control over how persistence should be enabled.

    The best way to think about it is like this: The persistence profile on the virtual enables the persistence feature and identifies the default values. The persist rule command can then be used to update or modify the current persistence attributes. Additionally, several persist types like: source address (simple), destination address (sticky), and uie (universal) don't need to be specifically enabled by a persistence profile on the virtual and can be selected solely by the persist command in a rule.

    So, in using your example, you really only need one persistence profile - so let's just use AppCookie:

            
      profile persist AppCookie {         
         defaults from cookie         
         mode cookie         
         cookie mode insert         
         cookie name App         
      }        
      

    Keep your virtual just as you already have it:

       
      virtual appswitch {    
         destination 172.30.1.2:http    
         ip protocol tcp    
         profile http tcp    
         pool app    
         persist AppCookie    
         rule appswitch_uri    
      }   
      

    Also keep all your pools just as you already have them and simply modify your rule to update the cookie persistence with a new name, like so:

            
      rule appswitch_uri {       
         when HTTP_REQUEST {       
            if { [HTTP::uri] starts_with “/app1” } {       
               persist cookie insert App1       
               pool app1       
            } elseif { [HTTP::uri] starts_with “/app2” } {       
               persist cookie insert App2       
               pool app2       
            } elseif { [HTTP::uri] starts_with “/app3” } {       
               persist cookie insert App3       
               pool app3       
            } elseif { [HTTP::uri] starts_with “/app4” } {       
               persist cookie insert App4       
               pool app4       
            }       
         }       
      }       
      

    So, as you can see, you can actually modify/select additional attributes with the persist rule command. It's really not all that different from the way it would be in 4.x - just that you simply need to select both the pool and the persistence attributes in the rule.

  • Posted By unRuleY on 12/01/2004 12:44 AM

     

     

    profile persist AppCookie {

     

    defaults from cookie

     

    mode cookie

     

    cookie mode insert

     

    cookie name App

     

    }

     

     

     

    From your posting I would like to find out how do I maintain persistance between services, my problem is that I can get persistance to one pool until you switch services from 80 -> 443 or vice-versa, and my pool changes. Any help on Expanding the AppCookie declaration would be awesome?

     

     

     

  • My problem is where, I have made that assignment on my profile:

    
    profile persist cookie_hash_4_hours_across_pools_services_vips {
       defaults from cookie
       mode cookie
       timeout 144000
       cookie mode hash
       cookie name BigIpCookieHash
       across services enable
       across virtuals enable
       across pools enable
    }

    and my VIP says:

    
    virtual communities_http {
       destination 216.xxx.180.123:http
       ip protocol tcp
       profile http tcp
       persist cookie_hash_4_hours_across_pools_services_vips
       rule communities_http_contains_phoenix_pool_split
    }
    virtual communites_https {
       destination 216.206.180.123:https
       ip protocol tcp
       profile http communities_clientssl communities_serverssl tcp
       persist cookie_hash_4_hours_across_pools_services_vips
       rule communities_https_contains_phoenix_pool_split
    }

    and my iRules:

    
    rule communities_http_contains_phoenix_pool_split {
       when HTTP_REQUEST {
       if { ([HTTP::uri] contains "Phoenix") or ([HTTP::uri] contains "phoenix") } {
         pool communities.com_phoenix_http
       } else {
               pool communities.com_http
       }
     }
    }
    rule communities_https_contains_phoenix_pool_split {
       when HTTP_REQUEST {
       if { ([HTTP::uri] contains "Phoenix") or ([HTTP::uri] contains "phoenix") } {
         pool communities.com_phoenix_https
       } else {
               pool communities.com_https 
       }
     }
    }

    Yet my persistence does not stick! The idea was to remove the project phoenix from the main community site, since they over-grew, but keeping persistence does not work...

  • It is use full info but i have miss understanding.

    I have VIP and on it have default persistence profile. also i have iRule on VIP that redirecting to different pools like:

      "/site1*" {
         persist cookie
          use pool pool1
              }  
      "/site2*" {
         persist none
         use pool pool2
    
      } 
     default {
         use pool defaultpool
      }
    

    if i am not specify any persistence value that pool will get default persistence profile (like defaultpool), if i specify "persist none" pool will not get any persistence.

    So the question what will be with pool1 that has "persist cookie"????

    thanks