Forum Discussion
ta11ey_89826
Nimbostratus
NimbostratusNeed Cookie Hash iRule Help
I have an iRule performing a cookie hash that is working... for the most part.
The pool 'amtrial_http' contains the two nodes referenced in the iRule. Obviously, when the 1st request comes into the virtual server, it does not have a cookie so it is sent to the 'amtrial_http' pool - and I can confirm this in the ltm log...
Oct 29 18:10:22 tmm tmm[2134]: Rule iamlbcookie_http : default
My issue is that when a request matches this rule, the request is always sent to one server. There is no load balancing and I would have thought that when the request is sent to the pool 'amtrial_http', then the request takes on the load balancing methodology of the pool. I have changed my 'Load Balancing Method' from Least Connections to Round Robin, to Ratio... I've tried just about all of them with no success. Is there some load balancing logic that I need in the iRule for the pool? Please help.
when HTTP_REQUEST {
if { [HTTP::cookie exists "iamlbcookie"] } {
log local0. "[HTTP::cookie "iamlbcookie"]"
switch [HTTP::cookie "iamlbcookie"] {
*01* {
node 192.168.1.1
log local0. "matched 01"
}
*02* {
node 192.168.1.2
log local0. "matched 02"
}
}
}
else {
pool amtrial_http
log local0. "default"
}
}
- 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 
ta11ey_89826I'm using the iRule in the cookie hash persistence profile.- ta11ey_89826Thanks 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 - ta11ey_89826Yes 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 - ta11ey_89826As 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 - ta11ey_89826"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.
