Forum Discussion

Stefan_Klotz's avatar
Stefan_Klotz
Icon for Cumulonimbus rankCumulonimbus
Jun 08, 2011

persist lookup with any virtual option

Using the following command:

[persist lookup source_addr "[IP::client_addr] any virtual" node]

What happend if there a multiple entries in the persistence table for the same source address? I guess I get back the result of the first match.

Is there any possibility to get some kind of a list back? Otherwise how can I ensure to get back only the entries from the VS where this persistence should be used?

Or is this a basic drawback of the any virtual option?

Or do I have to use the "pool " option with all possible pool names lets say in a foreach loop until I have a match?

Thank you!

Ciao Stefan üôÇ

7 Replies

  • Hi Stefan,

     

     

    There should only be one persistence table entry for the client IP. Are you seeing something else?

     

     

    Aaron
  • I have two virtual servers where I need sourceIP persistence when jumping between them. That's normally no problem using the default Across Virtuals option. The problem now is, that the poolmembers of each virtual server are different. It's something like this:

     

    VS1: 10.10.10.10

     

    - member1: 10.10.10.20

     

    - member2: 10.10.10.21

     

    VS2: 10.10.10.11

     

    - member1: 10.10.10.30

     

    - member2: 10.10.10.31

     

    Members 1 and members 2 from each pool are corresponding, means if persistence for VS1 is pointing to member2, switching to VS2 must also be forwarded to member2.

     

    Currently I have no Persistence profile configured, but handle this only with an iRule which looks like this:

     

    - in the LB_SELECTED event I add/update the sourceIP in the persistence table

     

    - in the CLIENT_ACCEPTED event I make a lookup for the sourceIP with the any virtual option

     

    - if there isn't an entry for both VS the normal pool balancing decision takes place

     

    - if the request was for VS1 and there is a persistence entry for this VS1, it will be used

     

    - if the request was for VS2 and there is a persistence entry for VS1, the corresponding poolmember will be choosen (pool-command with member option)

     

    Now my question is, what happend when there is any other VS which has nothing to do with this setup, but which has also sourceIP persistence configured and there is a sourceIP entry in the persistence table for this VS. What would be the result of the lookup?

     

    Maybe I'm thinking in the wrong direction at the moment, but could this be a problem? Alternative I could use the dedicated pool-option for the lookup instead the any virtual, but then I need to loop through all possible allowed pools (two in the above example, later four because each VS will listen both on port 80 and 443, SSL can't be offloaded to the BIG-IP) until I have a positive result.

     

    Or are there even any other or better ideas to solve this problem?

     

    Thank you!

     

     

    Ciao Stefan :)

     

  • Default persistence requires that the pool name and member be the same. Do you want to map pool1's member1 to pool2's member1 and pool1's member2 to pool2's member2?

     

     

    If so, I think it would be easier to do this using a custom cookie (assuming the two virtual server FQDN's are on the same subdomain. You could check for a cookie value of 1 or 2 and select the first member of the current pool using [lindex [active_members -list [LB::server pool]] 0] (or 1 for the second pool member).

     

     

    Aaron
  • Hi Aaron,

     

    your described mapping is correct, but both VS are NOT in the same subdomain.

     

    But your idea looks interesting, I will keep this in mind for any other future problem.

     

    I currently checked the iRule wiki, what happend when I add two cookies (one for each domain with the "domain "-option)? Is this valid?

     

    But back to my original question/problem with the lookup and any virtual option, could this be a problem with sourceIP persistence of other VS?

     

    Thank you!

     

     

    Ciao Stefan :)

     

  • Source IP persistence maps the client IP to a pool name and member IP:port. So it won't work if the pool members are different. Browsers will ignore a cookie set for one domain (example1.com) when they requested a different domain (example2.com). Just to clarify, are the two FQDNs different subdomains (sub1.example.com and sub2.example.com) on the same domain? If so, the cookie idea would work if you set the domain on the cookies to .example.com.

     

     

    Another option if the domains are different would be to do manual tracking of the client IP to pool member mapping using a subtable for 10.1.0+. Subtables are global objects which are accessible from any virtual server's iRule.

     

     

    http://devcentral.f5.com/wiki/default.aspx/iRules/table

     

    http://devcentral.f5.com/Tutorials/TechTips/tabid/63/articleType/ArticleView/articleId/2375/v101--The-table-Command--The-Basics.aspx

     

     

    Aaron
  • Hi Aaron,

    you are my hero of the day!

    Yes as already mentioned the domains are completely different. So I tried you table solution and it's working perfect.

    I wasn't aware of the fact that the sourceIP and persistence table entries will NEVER match for different VS even with the "any virtual" option.

    But ok, I replaced all the persist commands with the table command and I also implemented your tip from the cookie idea, which makes me very flexible.

    I will test this now with the application guys if everything is working as required.

    btw.:

    pool [LB::server pool] member [lindex [active_members -list [LB::server pool]] $instance]

    seems to not working correctly for me, but if I use

    pool [LB::server pool] member [lindex [lindex [active_members -list [LB::server pool]] $instance] 0]

    everything is fine.

    Thank you!

    Ciao Stefan üôÇ