Direct HTTP request from an IP to specific pool members

tqu

 

 

The iRule becomes effective straight away as it's compiled as soon as you save it.

 

 

What Lies Beneath was right about OneConnect - apologies for not mentioning it myself. You may want to take a look at this askf5 KB article to see if this helps:

 

 

http://support.f5.com/kb/en-us/solutions/public/9000/800/sol9800.html

 

 

Rgds

 

Nathan

@tqu

 

 

As nathan pointed out, you can use: pool member member.ip.address member.port to specify the specific member of a pool that you want to direct traffic to. The caveat is that you have to hard code it to the iRule.

 

 

This is because there is no simple way to get the BIG-IP to look at a pool, gather a list of members, designate a numeric value of membership, and then make a decision to direct traffic to something as generic as pool member 1, 2, etc.

 

 

What Lies Beneath’s suggestion could assist you with your automated testing. The OneConnect profile has several uses, but the one that will specifically help you in your automated testing is the ability to re-use existing connections and a deeper inspection of all incoming traffic allowing individual TCP Requests from the same source IP to be handled independently.

 

 

This is used in situations where you have a large amount of traffic coming into your BIG-IP from a NAT (or a service like Akamai) or a single testing server.

 

 

Without OneConnect enabled, persistence data is examined only in the first request of a Keep-Alive connection, so if multiple requests are sent on the same clientside Keep-Alive connection, LTM will persist them all to the same destination as the first unless a OneConnect profile is applied (even if logic contained in an iRule dictates otherwise).

 

 

@Mohamed Lrhazi

 

 

You can get strange behavior if you try and redirect traffic to a specific pool member after the initial load balancing decision has been made. The traffic will bounce back and forth between the Cookie Persistence pool member and the specified pool member.

 

 

If you capture the request initially like tqu is trying to do then the default cookie persistence should hold the traffic to the specified node for all remaining request.

 

 

If you are routing traffic to a different pool based on something like the [HTTP::uri] value then you should get another BIG-IP Cookie to hold the load balancing decision to the new pool’s pool member.

 

 

iRule’s can override and change persistence though see the command.

 

 

Hope this helps.

 

It's hardly desirable but you could also try one other thing; setup three new pools, each containing only the single member you'd like used by IP 1.2.3.4 and then reference those in your iRule. It would be interesting to see if this worked or not.

Oh, and I know you have a OneConnect profile assigned, but do you also have the OneConnect Transformations option enabled in your HTTP Profile?

tqu,

 

 

What OneConnect Mask are you using and are you using SNAT?

 

 

If you're using SNAT then the default /0 mask is fine, if not then you'll need to configure the mask as /32

 

 

Rgds

 

N

Thank you again all for your replies.

 

 

OneConnect Transformations option is enabled, pool member ports are there too.

 

It is working perfect now :) I guess it's the cookie persistent issue. Once I wait until cookie expired, no test fails at all.

Glad to hear it.