Forum Discussion

NiHo_202842's avatar
NiHo_202842
Icon for Cirrostratus rankCirrostratus
Jan 13, 2016
Solved

Incorrect load balancing when disabling Oneconnect

Hello,

 

so sketch the situation; we have a $app-pool and an $app-report-pool. $app-pool serves the regular web interface, while $app-report generates reports and sends this to the user. Default pool is $app-pool and $app-report-pool is chosen by an iRule which just checks if the URI starts with "/report".

 

Due to some circumstances, we disabled OneConnect. During this, loading reports only works half of the time. (really a 50/50 change it loads correctly)

 

As far as I understand, using OneConnect only load balances once based on your TCP connection. So user connects to the vip and is load balanced to server1. He then requests a report via /report/xxx, which is load balanced to server-report1. How can this not work? Our default persistence is cookie persistence with source IP as the fallback.

 

cookie persistence
devops
iRules
LTM
oneconnect
  • Hannes_Rapp_162's avatar
    Hannes_Rapp_162
    Jan 13, 2016

    Is the app-pool configured as Default Pool in your Virtual Server settings? If you conditionally select another pool, ie. the server-report1 pool in an iRule, you will need to include a 'Default or Else' clause in the iRule to 'Re-Confirm' your Default Pool. Just having the app-pool as your Default Pool setting in Virtual Server properties will not be enough.

    You may see a similar problem occuring in your environment:

    - Your first request to app-pool is routed correctly
- Your second request to app-pool is routed correctly
- .. All requests destined to app-pool are routed correctly, until the first occurence where a request is routed to server-report1 pool
- .. All the requests that should go to app-pool (default) thereafter are now incorrectly routed to server-report1 pool.

    For a solution, if you're using the 

    if
    conditional statement, append an 
    else
    statement to specify the app-pool as your default selection in iRule. If you're using 
    switch
    conditional statement, append a 
    default
    statement.

    Give it a try, if the conditions described match your configuration. This would be a generic iRule problem, not related to OneConnect by any means.

6 Replies

Sort By
  • Hannes_Rapp's avatar
    Hannes_Rapp
    Icon for Nimbostratus rankNimbostratus
    Jan 13, 2016

    Is the app-pool configured as Default Pool in your Virtual Server settings? If you conditionally select another pool, ie. the server-report1 pool in an iRule, you will need to include a 'Default or Else' clause in the iRule to 'Re-Confirm' your Default Pool. Just having the app-pool as your Default Pool setting in Virtual Server properties will not be enough.

    You may see a similar problem occuring in your environment:

    - Your first request to app-pool is routed correctly
- Your second request to app-pool is routed correctly
- .. All requests destined to app-pool are routed correctly, until the first occurence where a request is routed to server-report1 pool
- .. All the requests that should go to app-pool (default) thereafter are now incorrectly routed to server-report1 pool.

    For a solution, if you're using the 

    if
    conditional statement, append an 
    else
    statement to specify the app-pool as your default selection in iRule. If you're using 
    switch
    conditional statement, append a 
    default
    statement.

    Give it a try, if the conditions described match your configuration. This would be a generic iRule problem, not related to OneConnect by any means.

    • NiHo_202842's avatar
      NiHo_202842
      Icon for Cirrostratus rankCirrostratus
      Jan 14, 2016
      It is! I accidently discovered this behaviour while trying things out. You would think it reverts back to the 'default pool'. Thank you!
  • Hannes_Rapp_162's avatar
    Hannes_Rapp_162
    Icon for Nacreous rankNacreous
    Jan 13, 2016

    Is the app-pool configured as Default Pool in your Virtual Server settings? If you conditionally select another pool, ie. the server-report1 pool in an iRule, you will need to include a 'Default or Else' clause in the iRule to 'Re-Confirm' your Default Pool. Just having the app-pool as your Default Pool setting in Virtual Server properties will not be enough.

    You may see a similar problem occuring in your environment:

    - Your first request to app-pool is routed correctly
- Your second request to app-pool is routed correctly
- .. All requests destined to app-pool are routed correctly, until the first occurence where a request is routed to server-report1 pool
- .. All the requests that should go to app-pool (default) thereafter are now incorrectly routed to server-report1 pool.

    For a solution, if you're using the 

    if
    conditional statement, append an 
    else
    statement to specify the app-pool as your default selection in iRule. If you're using 
    switch
    conditional statement, append a 
    default
    statement.

    Give it a try, if the conditions described match your configuration. This would be a generic iRule problem, not related to OneConnect by any means.

    • NiHo_202842's avatar
      NiHo_202842
      Icon for Cirrostratus rankCirrostratus
      Jan 14, 2016
      It is! I accidently discovered this behaviour while trying things out. You would think it reverts back to the 'default pool'. Thank you!
  • Kai_Wilke's avatar
    Kai_Wilke
    Icon for MVP rankMVP
    Jan 13, 2016

    Hi NiHo,

    if you need to switch pools or persistence profiles without using a ONECONNECT profile, then you have to issue a 

    [LB::detach]
    command on every single change.

    See the links below for further information...

    https://support.f5.com/kb/en-us/solutions/public/7000/900/sol7964.html

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

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

    BTW: You may also want to try the (experimental) syntax below, to implement a simple request flow mechanism, with the purpose to only detach the server-side connection and re-apply the pool settings when its required.

    when CLIENT_ACCEPTED {
    set last_pool ""
}
when HTTP_REQUEST {
    if { [string tolower [HTTP::uri]] starts_with "/somepath" } then {
        if { $last_pool equals "my_pool_a" } then {
            do nothing
        } else {
            LB::detach
            pool my_pool_a
            set last_pool my_pool_a
        }
    } else {
        if { $last_pool equals "my_pool_b" } then {
            do nothing
        } else {
            LB::detach
            pool my_pool_b
            set last_pool my_pool_b
        }
    }
}

    Cheers, Kai

  • Stanislas_Piro2's avatar
    Stanislas_Piro2
    Icon for Cumulonimbus rankCumulonimbus
    Jan 13, 2016

    Hi,

    In irule changing the pool based on URI, don't forget to change back to default pool URI which does not match specific URI.

    Pool decision is done for the entire tcp connection when one connect is not enabled. 

    when CLIENT_ACCEPTED {
  set default_pool [LB::server pool]
}

when HTTP_REQUEST {
    if {[HTTP::uri] starts_with "/reports"} { 
        pool report
    } else {
        pool $default_pool
    }
}