Forum Discussion

Rikardo_77456's avatar
Rikardo_77456
Icon for Nimbostratus rankNimbostratus
May 07, 2011

Priority Group not working correctly

Hi, I've only been using the F5 BIG-IP for a few weeks and am trying to get priority groups working for one of our pools. I'm sure i've set it up correctly but connections still keep appearing on the lower priority member when they shouldn't. Connections should only appear when the higher priority member becomes unavailable, if i'm correct?

 

 

The pool consists of only 2 members, one with priority group 1, the other with priority group 2. Priority Group Activation is set when there is less than 1 available members, but I am still having the issue described above. Any help would be greatly appreciated.

 

8 Replies

  • Hi Rikardo,

     

     

    Do you see the higher priority pool member being marked down by a monitor when the stats increment for the lower priority member?

     

     

    Aaron
  • Hi Aaron, thanks for the reply.

     

     

    No, both members are available the whole time. Could it be something to do with persistence of another pool crossing over? It's the only explanation I can think of.

     

     

    How we have it set up is one virtual server that by default sends http traffic through pool1 (this includes 2 members, that have cookie persistence), but have an irule that checks the uri for a specific starting string. If the uri starts with this specific string we send it to pool2 (problem pool, as stated above. This includes the same members as pool1, but instead of load balancing we are trying to use priority groups in an active/passive type setup, so that traffic only ever gets sent to one member at a time). Could it be that because the user has already been through pool1, and has a cookie to persist this, that when they get passed through pool2 they get sent to the same member as in pool1? I don't fully understand the cookie persistence and if this could be the case?

     

     

    Rikardo
  • What kind of persistence are you using on this virtual server? Do you have the same persistence profile defined on a second virtual server with the same pool member or node defined?

     

     

    Do you have a OneConnect profile on the virtual server? If so, do you have the same OneConnect profile enabled on another virtual server?

     

     

    Aaron
  • We only have one virtual server, with the standard oneconnect profile. The persistence profile is set to cookie, the standard one. The default pool is set as Pool1. Both pools have the same members, using the same nodes. I guess this is the problem then? Is there a better way for this to work?
  • Can you list the VS, pool and OneConnect configs and reply with the anonymized output? You can use 'b virtual VS_NAME list', 'b pool POOL_NAME list' and 'b profile oneconnect OC_NAME list' to get this.

     

     

    Thanks, Aaron
  • I hope this is what you are after:

     

     

    virtual Web_VS {

     

    snat automap

     

    pool Web_Pool1

     

    fallback persist source_addr

     

    destination 192.168.1.25:http

     

    ip protocol tcp

     

    rules {

     

    Force_HTTPS

     

    InsertXForwardedFor

     

    Cache_Selective

     

    ServerSpecificForwarding

     

    URI_Forwarding

     

    RSS_Forwarding

     

    }

     

    persist cookie

     

    profiles {

     

    ABC_HTTP_Compression_Caching {}

     

    oneconnect {}

     

    tcp-lan-optimized {

     

    serverside

     

    }

     

    tcp-wan-optimized {

     

    clientside

     

    }

     

    }

     

    }

     

     

    pool Web_Pool1 {

     

    lb method member ratio

     

    monitor all ABC_Web_Monitor

     

    members {

     

    192.168.1.20:http {}

     

    192.168.1.23:http {

     

    ratio 3

     

    }

     

    }

     

    }

     

     

    pool Web_Pool2 {

     

    min active members 1

     

    monitor all ABC_Web_Monitor

     

    members {

     

    192.168.1.20:http {

     

    priority 1

     

    }

     

    192.168.1.23:http {

     

    priority 2

     

    }

     

    }

     

    }

     

     

    profile oneconnect oneconnect {

     

    source mask 0.0.0.0

     

    max size 10000

     

    max age 86400

     

    max reuse 1000

     

    idle timeout override disable

     

    }

     

     

    monitor ABC_Web_Monitor {

     

    defaults from http

     

    send "GET / HTTP/1.1\r\nHost:www.abc.com\r\nConnection: Close\r\n"

     

    }

     

     

    rule URI_Forwarding {

     

    when HTTP_REQUEST {

     

    if { [HTTP::host] equals "www.abc.com" && [HTTP::uri] starts_with "/abc/" } {

     

    pool Web_Pool2

     

    }

     

    }

     

    }
  • That's exactly it. Do you have the default OneConnect profile associated with the another virtual server? If so, I think that's the most likely candidate. You can test this by creating a new OneConnect profile and replacing the default OneConnect profile on this virtual server. If that's not it, can you post the other iRules that are enabled on the virtual server?

     

     

    Thanks, Aaron
  • We do have another virtual server, but it's completely unrelated and not used by the same users. Web_VS is http, while Web_VS2 is https for a different set of users. Should I have another virtual server setup instead of just redirecting the user to a different pool in irule URI_Forwarding?

     

     

    Other irules:

     

     

    rule InsertXForwaredFor {

     

    when HTTP_REQUEST {

     

    if {[HTTP::header exists X-Forwarded-For]}{

     

    HTTP::header replace X-Forwarded-For "[HTTP::header X-Forwarded-For], [IP::client_addr]"

     

    } else {

     

    HTTP::header insert X-Forwarded-For [IP::client_addr]

     

    }

     

    }

     

    }

     

     

    rule Cache_Selective {

     

    when HTTP_REQUEST {

     

    if { [HTTP::host] equals "static.abc.com" } {

     

    CACHE::enable

     

    } else {

     

    CACHE::disable

     

    }

     

    }

     

    }

     

     

    rule Force_HTTPS {

     

    when HTTP_REQUEST {

     

    if { [HTTP::host] equals "www2.abc.com"} {

     

    HTTP::redirect "https://[HTTP::host][HTTP::uri]"

     

    }

     

    }

     

    }

     

     

    rule RSS_Forwarding {

     

    when HTTP_REQUEST {

     

    if { [HTTP::host] equals "www.abc.com" && ( [HTTP::uri] starts_with "/rss1/" || [HTTP::uri] starts_with "/rss2/" ) } {

     

    pool Web_Pool1 member 192.168.1.20 80

     

    }

     

    }

     

    }

     

     

    rule ServerSpecificForwarding {

     

    when HTTP_REQUEST {

     

    if {[HTTP::uri] contains "20.html"} {

     

    pool Web_Pool1 member 192.168.1.20 80

     

    } elseif {[HTTP::uri] contains "23.html"} {

     

    pool Web_Pool1 member 192.168.1.23 80

     

    }

     

    }

     

    }