Forum Discussion

Haluk_Yildirim_'s avatar
Icon for Nimbostratus rankNimbostratus
Apr 12, 2011

Using HTTPClasses vs. iRules path & domain selection

This has been an ongoing discussion at my company and we do get conflicting answers from F5. What we are doing is basic traffic handling / pool selection based on host/FQDN or path and send it to a pool/different pool(s).



Obviously HTTPClasses are very easy to configure and dummy proof where when we get into iRules, it can always get interesting (we are a large provider where lots of engineers touch lot of different LTMs)




From what I gather, LTM will only capture new flows when HTTPclasses are used so if there are multiple selections are done via HTTPClass, like /appA goes to POOL-AppA, /appB goes to POOL-AppB, and if persistence is enabled for the VS (e.g. cookie insert), when a user switches from appA to AppB things do not function.




Some F5 engineers tell us that HTTPClass should only be used for ASM purposes to filter ASM related traffic (bind ASM policy etc) and some of them tell us HTTPclasses are safe to use for any kind of traffic (with or without persistence). Currently we try to do everything with iRules, but I just want to see what your thoughts/experiences may be.




Regards, Haluk


3 Replies

  • I believe that HTTP classes can be used for more than ASM. This SOL gives three scenarious in which HTTP classess are used. Could be helpful.

  • I believe that HTTP classes can be used for more than ASM. This SOL gives three scenarios in which HTTP classess are used. Could be helpful.

  • Hi Haluk,

    Sorry for the conflicting info you've received. HTTP classes were designed for exactly the scenario you've described. To be honest, I'm not certain whether there is special logic built in for current versions to handle multiple HTTP requests to different HTTP classes. To be safe, you can always add a OneConnect profile to ensure each HTTP request is persisted/load balanced to the correct pool member. Or more ideally, you could test this by setting up a test virtual server with two classes. Set one class to filter on URIs ending with 0 and the other as a catch all. Then use curl to make request to a URI of 0 through 9: curl -v[0-9]. Curl will reuse the same TCP connection to send requests to /test0 through /test9. You can use an iRule to log the URI and selected server:

       when HTTP_REQUEST {
          log "Client [IP::client_addr]:[TCP::client_port] -> [HTTP::host][HTTP::uri]"
          log "Client [IP::client_addr]:[TCP::client_port] -> [HTTP::host][HTTP::uri] went to [HTTP::class] HTTP class"
       when HTTP_CLASS_FAILED {
          log "Client [IP::client_addr]:[TCP::client_port] -> [HTTP::host][HTTP::uri] did not match an HTTP class!"
       when LB_SELECTED {
          log "Client [IP::client_addr]:[TCP::client_port] -> selected server: [LB::server]"
       when SERVER_CONNECTED {
          log "Client [IP::client_addr]:[TCP::client_port] -> connected server: [IP::server_addr]:[TCP::server_port]"

    See this article for details on OneConnect:

    If you use SNAT on the serverside connections, you could use the default OneConnect profile with a /0 source mask. If you're not using SNAT, then you'd want to create a custom OneConnect profile with a /32 source mask.