Forum Discussion

woliver_163458's avatar
woliver_163458
Icon for Altocumulus rankAltocumulus
May 06, 2015
Solved

No traffic going to pool, but works with different name

I'm seeing an odd issue on our LTM where traffic will not flow to one of my pools. It's inside an irule, but the issue isn't with the rule itself. In a bit of desperation, I created a new pool which was the exact same as the problem pool, except with a '_Test' appended to the name. I updated the irule with the new pool name and traffic flowed as expected.

I then deleted the original pool, saved the config, re-created it, modified the irule with the original pool name and once again no traffic. The stats are 0's across the board for the pool, no traffic even attempting to go to it.

It seems odd that the name of the pool would matter, but I can't come up with any other explanation. Anyone seen something like this?

For what it's worth, I'm on 11.6.0 HF1

ltm pool /D04TS/DP_REST_FIREWALL_Servers {
    members {
        /D04TS/DP-1:8149 {
            address X.X.X.X
        }
    }
    monitor /Common/gateway_icmp
}

ltm pool /D04TS/DP_REST_FIREWALL_Servers_Test {
    members {
        /D04TS/DP-1:8149 {
            address X.X.X.X
        }
    }
    monitor /Common/gateway_icmp
}
  • Just in case anyone else runs into the same issue, the problem wound up being we had pools in different partitions/route domains with the same name, i.e. 'DP_REST_FIREWALL_Servers', which confuses the device if the partition is not explicitly called out. So the fix was just a matter of updating the irule to read

     

    pool /D04TS/DP_REST_FIREWALL_Servers

     

    instead of

     

    pool DP_REST_FIREWALL_Servers

     

7 Replies

    • woliver_163458's avatar
      woliver_163458
      Icon for Altocumulus rankAltocumulus
      The node currently has no health monitor and the pool is up and available according to the LTM, it just won't send any traffic to it.
  • irule below when HTTP_REQUEST { switch -glob [HTTP::URI] { "/BackOffice/*" - "/WebClient/*" { pool BKO_SSL_Servers set doSSL 1 } "/cdds/wfs-receiver*" - "/cdds/local-receiver*" { pool RTM_SSL_Servers set doSSL 1 } "/SchemaRepository*" { pool SOA_HTTP_Servers set doSSL 0 } "/Services/*" - "/QueryBroker" { pool DP_REST_FIREWALL_Servers set doSSL 2 } default { pool DP_SSL_Servers set doSSL 2 } } } when SERVER_CONNECTED { if {$doSSL == 0} { SSL::disable serverside } elsif { $doSSL == 1} { SSL::enable serverside SSL::profile SSL_1way_Server_profile } elsif { $doSSL == 2} { SSL::enable serverside SSL::profile SSL_2way_Server_profile } }
  • OK, thanks. So, is there an ServerSSL profile assigned to the Virtual Server?

     

    Also, I've suggest LB_SELECTED is a better even in which to select the SSL profile.

     

    Also, why are you enabling SSL? It should be enabled on the Virtual Server and only disabled when unwanted.

     

  • Hmmm, I wonder if that's the issue. Can you remove one of the profiles and try again. You should be able to switch between any available on the system as long as at least one is assigned.

     

    LB_SELECTED occurs before there is any communication with the backend server; it simply feels better to me to do it before the 3WHS but technically, after is OK and will work. I also think using LB_SELECTED means the selection only occurs once for that session. With SERVER_CONNECTED it may occur multiple times.

     

    Out of interest, which Pool is causing the issue?

     

  • Just in case anyone else runs into the same issue, the problem wound up being we had pools in different partitions/route domains with the same name, i.e. 'DP_REST_FIREWALL_Servers', which confuses the device if the partition is not explicitly called out. So the fix was just a matter of updating the irule to read

     

    pool /D04TS/DP_REST_FIREWALL_Servers

     

    instead of

     

    pool DP_REST_FIREWALL_Servers