Forum Discussion
Ian_Stewart_390
Nimbostratus
NimbostratusiRules, URL Routing and Cookie Persistance
Hi Everyone,
We have a BigIP 1500, configured with several virtual servers and pools. We use an iRule to make routing decisions to direct traffic to the correct pool based on request URL, since the site is distributed across several pools.
The iRule for one of the virtual servers is as follows. It has a default pool of webnode3_pool.
when CLIENT_ACCEPTED {
set defpool [LB::server pool]
}
when HTTP_REQUEST {
set request_uri [string tolower [HTTP::uri]]
set request_host [string tolower [HTTP::host]]
if { $request_uri contains "/aspnet_client/" } {
pool webnode_pool
}
elseif { $request_uri contains "/ig_common/" } {
pool webnode_pool
}
elseif { $request_uri contains "/cpm/" } {
pool cpmweb_pool
}
elseif { $request_uri contains "/agentrequest/" } {
pool webnode_pool
}
elseif { $request_uri contains "/agents/" } {
pool webnode_pool
}
elseif { $request_uri contains "/home/" } {
pool webnode_pool
}
else {
pool $defpool
}
}
The URL routing works fine. The virtual server is configured to use cookie-insert persistance. If I look at my cookies when I browse the site, I can see BigIP cookies. My concern is that in the administration webpage, under persistance records, every record is showing SOURCE ADDRESS AFFINITY. We recently tried to run a load balancing test, (one machine that makes multiple connections to the site to generate a load), and the BigIP failed to load balance any of the requests.
Does using the iRule not allow the default persistance method defined on the virtual server to take effect? Is there something else I'm missing here -- why isn't cookie-insert persistance working?
Thanks in advance,
Ian
22 Replies
Ian_Stewart_390Thank you so much. =)
-Ian- Rupert_80016Hi all,
I've got a similar issue to the original poster.
I've writen an iRule which directs the client to the relevant pool based on URI however I'd also like them to persist once they get to that pool.
So far I've tried all the peristence methods, persistence records ARE being inserted in to the persistence table however whenever the client returns and the persistence is still valid, it's ignored, they are round robined to a new server and get a new persistence record.
Please could anyone shed any light on this, kinda tearing my hair out!!
Further info:
Datastore contents:
URIA!xxxx-80_pool!cookie!hash MYCOOKIE
Persistence table contents (this shows an initial connections and then a further request getting a new persistence record):
[root@myloadbalancer:Active] config b persist pool xxxx-80_pool show all
PERSISTENT CONNECTIONS --
Mode: cookie Value: VpHyJlKJdk
Virtual: 10.1.1.1:http Node: 10.2.2.2:12346 Age: 1sec
Mode: cookie Value: JlK8JlKLzs
Virtual: 10.1.1.1:http Node: 10.2.2.2:12346 Age: 6sec
iRule in question:
when HTTP_REQUEST {
parse the URI for the content provider, this is the first key
set content_provider [lindex [split [HTTP::uri] "/"] 1]
find the content provider in the data group
set idx [matchclass $::xxxx_httpuri_datastore contains $content_provider]
log "idx=$idx"
check if the content provider is in the conf
if {$idx > 0}{
if it is let's dance
set cfg [lindex $::xxxx_httpuri_datastore [expr $idx - 1]];
set lbpool [lindex [split $cfg "!"] 1];
set permethod [lindex [split $cfg "!"] 2];
set perargs [lindex [split $cfg "!"] 3];
if {$permethod equals "cookie"}{
persist cookie [lindex [split $perargs " "] 0] [lindex [split $perargs " "] 1];
use pool $lbpool;
} else {
persist $permethod;
use pool $lbpool;
}
} else {
content provider not in conf, drop connection
log "Sorry, Rejecting $content_provider not in conf."
reject
}
}
