Forum Discussion
Ian_Smith
Mar 20, 2010Ret. Employee
The rule has two data points that matter -
1. the data group, which matches pool member IP addresses to cluster identifiers (i.e. which physical server do pool members share?)
2. the table entry, which records whether or not a client IP has visited any cluster in the last timeout interval (300 seconds by default )
During the iteration where the table entry is compared to the pool member's cluster ID, if it finds a match, then the client is sent to the pool member in the correct cluster.
If a match can't be found, it interprets that as a down cluster member and makes an LB decision based on the default pool (in the vs config; which may or may not break the application), and it logs an error.
The mappings are in an internal data group, which is about the most static place to store them; you could use iControl to update and re-initialize the group, but that seems excessive when your list is 9 or 10 pool members spread across 3 or 4 servers.
You could replace the class lookup with a DNS PTR query where the answer is a cluster ID and then store the results in an array, making all of the comparisons from the array if you wanted to do something like this in a very large or dynamic environment.
If a client arrives and there is no corresponding table entry for that IP, then an LB decision is made and a table entry is made to prepare for traffic on other virtuals.