Kevin,
1. The client is sending this information only for certain requests. The destination information is provided to client by the server application. If for whatever reason the information become erroneous, the application will send an update to the client.
2. I would still need the pool name because I want to be able to forward the request to the next member in the pool if the intended member is down
3. Basically the irule come into play only if the member address header, affinity, is found in the HTTP request. The member IP and port information is extracted and used to check the status of that member. If the status is up, the request is routed to it. If not, it is routed following the lb method configured for the pool.
In a simple set up where I have only a single pool associated with the virtual, there would be no problem as the pool would always be known. In my set up, however, I have a number of channels all converging into a single virtual and routing to the appropriate pool is done based on the Host via httpclass profiles. Since the affinity header is only used for certain requests of a given type, there is absolutely no impact on the other services. All works nicely.
In some edge cases where the client loses the connection for whatever reason and tries to re-establish it for the same session that this starts breaking down. For a new connection, the client does not send the affinity header as it hasn't received it from the server-application yet. It sends it with the subsequent requests. In the case of a re-connect it tries to re-use the same session information (as designed) and sends the affinity header.
What is happening during re-connect is that the irule is kicking in before httpclass is selected. This means that the pool has not been selected yet. This causes the irule to trigger a tcl error when it tries to check for the status of the member:
if {[LB::status pool [LB::server pool] member $mem_ip $mem_port] eq "up"} {
pool [LB::server pool] member $mem_ip $mem_port
}
As a quick fix I did configure a default pool in the irule and that works fine. However since I have multiple set ups sitting behind the same LB pair and all need to use the same irule logic, I wanted to see if I can apply a single irule to all of them without having to statically load all the pool - member information into the irule. That would not be a good solution from a management perspective as it would require an update to the irule every time a new server is added to the cloud.