I have API related paths where we want to send API traffic to another set of servers.
The app is not compatible with session cookies, so I must used source-addr persistence on the VS.
The problem is that because the VS has source-addr persistence enabled, if I simply send the API traffic to another pool, we are still persisting to this API pool by source address, so not a balanced load.
If I disable persistence in the irule for these API paths, we are having issues where clients are no longer persisting on the root path, which I believe is related to the source-addr persistence. (I'm assuming that the clients having these issues are at the same source address as other users who are accessing the API paths, as we use RDS, so multiple users can come from the same IP.)
So my solution is to LB::reselect virtual [the API VS], that does not have persistence enabled.
When I look at a pcap, I see many retransmissions, even though I get successful results from the API servers.
The retransmissions begin right after the LB::reselect virtual occurs, and only pertain to the traffic that is related to the reselected VS.
The servers in the root are listeining on port 80, and the VS I'm reselecting is on 443
If I adjust the irule to use the API VS on port 80, I still get the retransmissions, so these are not related to TLS.
The issue you're experiencing could be potentially due to the LB::reselect function. In a TCP connection, when a reselect occurs, the connection is essentially abandoned and a new one is made, which could cause retransmissions as TCP tries to recover the abandoned connection. A possible solution could be to use a different method to direct your API traffic to the correct pool. Instead of using LB::reselect, you might want to use an iRule to direct traffic to the correct pool based on the HTTP::path. Below is an example of how you might modify your iRule: