Need Cookie Hash iRule Help

When using the pool command to direct traffic to a particular pool in your config it should absolutely take on the load balancing method that's applied to that pool. Is there perhaps persistence set up? If not, could you send us the pool config snippet as well to take a look?

 

 

Thanks,

 

Colin

I'm using the iRule in the cookie hash persistence profile.

Thanks for looking, btw.

 

 

I've changed the persistence method to a cookie insert at this time, but I'd really like to get the cookie hash working. I haven't changed any of the pool config though.

 

 

Here's the pool info.

 

 

POOL amtrial_https LB METHOD member least conn MIN/CUR ACTIVE MEMBERS 0/2

 

| (cur, max, limit, tot) = (0, 1059, 0, 17443)

 

| (pkts,bits) in = (3.912M, 4.063G), out = (6.019M, 52.14G)

 

+-> POOL MEMBER amtrial_https/192.168.1.1:https active,up

 

| | session enabled priority 1 ratio 1

 

| | (cur, max, limit, tot) = (0, 632, 0, 11133)

 

| | (pkts,bits) in = (2.847M, 2.832G), out = (4.401M, 37.88G)

 

| | requests (total) = 623026

 

+-> POOL MEMBER amtrial_https/192.168.1.2:https active,up

 

| session enabled priority 1 ratio 1

 

| (cur, max, limit, tot) = (0, 427, 0, 6310)

 

| (pkts,bits) in = (1.065M, 1.231G), out = (1.618M, 14.25G)

 

| requests (total) = 230794

Picking this one back up - Have you been able to confirm via log statements in the iRUle that the other matches are actually being met via the traffic and the iRule is firing the commands inside of those switch cases?

 

 

Colin

Yes I have, here's some log entries...

 

Dec 8 15:19:42 tmm tmm[1717]: Rule iamlbcookie : default

 

Dec 8 15:19:44 tmm tmm[1717]: Rule iamlbcookie : 01

 

Dec 8 15:19:46 tmm tmm[1717]: Rule iamlbcookie : 01

 

Dec 8 15:22:40 tmm tmm[1717]: Rule iamlbcookie : default

 

Dec 8 15:22:41 tmm tmm[1717]: Rule iamlbcookie : 01

 

Dec 8 15:22:44 tmm tmm[1717]: Rule iamlbcookie : 01

 

 

 

As an FYI, I have recreated the issue in our dev environment. I am using the same iRule and seeing the same results. I listed the wrong pool info above... here's the http pool info for the current dev environment...

 

 

POOL AccessManager_Pool LB METHOD round robin MIN/CUR ACTIVE MEMBERS 0/2

 

| (cur, max, limit, tot) = (0, 7, 0, 227)

 

| (pkts,bits) in = (1293, 1.920M), out = (1062, 2.123M)

 

+-> POOL MEMBER AccessManager_Pool/192.168.72.38:http active,up

 

| | session enabled priority 1 ratio 1

 

| | (cur, max, limit, tot) = (0, 4, 0, 193)

 

| | (pkts,bits) in = (892, 847712), out = (727, 979344)

 

| | requests (total) = 65

 

+-> POOL MEMBER AccessManager_Pool/192.168.72.44:http active,up

 

| session enabled priority 1 ratio 1

 

| (cur, max, limit, tot) = (0, 3, 0, 34)

 

| (pkts,bits) in = (401, 1.072M), out = (335, 1.144M)

 

| requests (total) = 126

 

 

Here's the matching iRule for dev:

 

when HTTP_REQUEST {

 

if { [HTTP::cookie exists "iamlbcookie"] } {

 

log local0. "[HTTP::cookie "iamlbcookie"]"

 

switch [HTTP::cookie "iamlbcookie"] {

 

*01* {

 

node 192.168.72.38

 

log local0. "matched 01"

 

}

 

*02* {

 

node 192.168.72.44

 

log local0. "matched 02"

 

}

 

 

}

 

}

 

else {

 

pool AccessManager_Pool

 

log local0. "default"

 

}

 

}

I'm not sure I'm following the problem. You say that things aren't being load-balanced when sent to the AccessManager Pool, but I'm not sure how you're measuring that. All you're showing is the traffic to the two pool members, and both members are receiving traffic.

 

 

Where is it that you're seeing traffic not load-balancing? How are you confirming this? What does the actual config of the pool, not the stats, look like?

 

 

Colin

"Where is it that you're seeing traffic not load-balancing?" I'm watching my pool statistics under Local Traffic / Pools / Statistics. All of the traffic is directed to node 192.168.72.38.

 

 

"How are you confirming this?" I've confirmed this by looking at the iRule statements being matched in the logs. The way I see it, there's three matches that can be made in the iRule - node 192.168.72.38 (01), node 192.168.72.44 (02), or pool AccessManager_Pool (default). Again, I see the matches in the logs that look like this...

 

 

Dec 8 15:19:42 tmm tmm]: Rule iamlbcookie : default

 

Dec 8 15:19:44 tmm tmm]: Rule iamlbcookie : 01

 

Dec 8 15:19:46 tmm tmm]: Rule iamlbcookie : 01

 

Dec 8 15:22:40 tmm tmm]: Rule iamlbcookie : default

 

Dec 8 15:22:41 tmm tmm]: Rule iamlbcookie : 01

 

Dec 8 15:22:44 tmm tmm]: Rule iamlbcookie : 01

 

 

I would expect to see matches like this (see arrow) ...

 

 

Dec 8 15:19:42 tmm tmm]: Rule iamlbcookie : default

 

Dec 8 15:19:44 tmm tmm]: Rule iamlbcookie : 01

 

Dec 8 15:19:46 tmm tmm]: Rule iamlbcookie : 02 <-----

 

Dec 8 15:22:40 tmm tmm]: Rule iamlbcookie : default

 

Dec 8 15:22:41 tmm tmm]: Rule iamlbcookie : 01

 

Dec 8 15:22:44 tmm tmm]: Rule iamlbcookie : 02 <-----

 

 

 

"What does the actual config of the pool, not the stats, look like?"

 

 

pool AccessManager_Pool {

 

 

monitor all tcp

 

 

members

 

 

192.168.72.38:http

 

 

192.168.72.44:http

 

 

}

 

 

pool AccessManager_Pool_HTTPS {

 

 

monitor all AccessManager_HTTPS

 

 

members

 

 

192.168.72.38:https

 

 

192.168.72.44:https

 

 

}

 

 

In case of "least connections" algorithm, (as you had first selected) it is possible that the BIG-IP will pick the same member over and over again if all pool members have the same number of connections.

 

e.g. if pool member A and B both have 0 connections. Assume request 1 will be handled by A. When request 2 comes in, if A is done with request 1, then it is possible that A will also handle request 2 (since A and B are again at 0 conns).

 

 

I briefly tried the irule you provided with my machine and for round robin I could see my requests going to both pool members (i'm using version 9.3.1).

 

 

Could you add the following event/log statement to your irule?

 

when SERVER_CONNECTED {

 

log local0. "[LB::server addr]"

 

}

 

 

This will show the actual pool member selected by big-ip each time after it hits the else clause with the "default" log message in the rule.