dispatch http request to all pool members instead of only one pool member

Hey Robbie!

Out of curiosity, could you tell me for what reason? IPS scanning?

Yes, you can clone the traffic, either with an iRule or with the clone pool option in the virtual server. In your case I guess the iRule is what you need.

https://devcentral.f5.com/wiki/iRules.clone.ashx

/Patrik

the reason why I need clone traffic is : delete http://x.x.x/1.test Pool A has 4 blades server , if F5 only send delete to one blade in pool they need to sync to each other,but need 30 seconds

so PD come to me and ask for a smarter way such as whether F5 can send request to all of them ,then delete all in 4 blades,so no need sync up now

hmm if pool A has one blade clonepoolA has 3 blades, with irule ,it can send traffic to all 3 blades in clonepoolA,right?

when HTTP_REQUEST {
  if { [HTTP::uri] starts_with "/clone_me" } {
    pool real_pool
    clone pool clonepoolA

Sorry man. Stumbled across an article. Turns out the F5 might not handle clone pools the way you want.

https://devcentral.f5.com/community/group/aft/2166574/asg/50

/Patrik

This is an interesting question and one that comes up from time to time. A clone pool is a one-way mechanism. It accepts no responses and establishes no sessions. It possibly could be made to work, but might require some substantial tweaking to your environment. Ultimately, you're confined to a single "flow" in a request or response event, so to make this work you'd have to do something to force new flows for each backend server. For example, you could:

1. Save the request
2. Send the request to a pool member
3. Catch the response
4. Reselect a new pool member
5. Use HTTP::retry to send the saved request to the new pool member
6. Rinse and repeat

This may have changed in recent versions, but I believe there's still an issue with how many times you can call LB::reselect, so you may be limited to that number. Another option is an internal sideband call. This basically launches a separate "tangent" flow to wherever you want it to go, without affecting the main flow. Here's an example:

proc send_to_sideband { data server } {
     this is the sideband processing procedure (function)

     create a new sideband connection
    set sbserver [connect -protocol TCP -timeout 100 -idle 5 -status conn_status $server]

     send the sideband request
    send -status send_status -timeout 100 $sbserver $data

     return the sideband response
    return [recv -status recv_status -timeout 300 $sbserver]
}
when HTTP_REQUEST {
    if { [HTTP::method] equals "DELETE" } { 
        foreach x [active_members -list [LB::server pool]] {
            set sb [call send_to_sideband [HTTP::request] [join $x ":"]]
        }
        HTTP::respond 200 content "Complete"
    }   
}

Both sideband and procs are really cool. You need 11.4 to do procs and sideband has been around since 11.1 I think. You can do this without a proc by just putting the sideband code inside the loop, but this looks cooler. The idea is that, for every pool member, you launch a sideband call to that pool member with the original request. at the end of that loop you simply return a status "complete" to the user. A few words of caution though.

1. Looping through all of the pool members will induce some latency. It'd do that no matter how you sent the request to each, but just keep that in mind.

    

2. Be careful. Assuming the DELETE semantic is allowed in your web servers, you should probably take care to make sure unintentional deletes can't happen.