Forum Discussion
Michael_Mau_108
Nimbostratus
NimbostratusProblem with I-rule that routes based on payload information
I have an i-rule that I am writing, to route requests to particular pool members based on information within a clients payload. The rule synxtax is below.
when HTTP_REQUEST {
if { [HTTP::header exists "Content-Length"] } {
set content_len [HTTP::header "Content-Length"]
} else {
set content_len 1000000000
}
if { $content_len > 0 } {
HTTP::collect $content_len
}
}
when HTTP_REQUEST_DATA {
if { ([matchclass [HTTP::payload] contains $::maui-qos])} {
if { [LB::status pool fbt-maui-sit-qa-8980-v-dcc member 10.86.33.80 8980] eq "down"
or
[LB::status pool fbt-maui-sit-qa-8980-v-dcc member 10.86.33.80 8980] eq "session_disabled"
} {
pool fbt-maui-sit-qa-8980-v-dcc
} else {
pool fbt-maui-sit-qa-8980-v-dcc member 10.86.33.80 8980
}
}
}
If a string in the payload matches a matchclass object, then I want them to go to one pool member (out of three); which I made a priority 7 (the other two are 10). If they do not match, then I want to send them to the pool, where they get load balanced between the two priority 10 pool members.
My problem seems to be with the matchclass command, because when I remove that line and point to a pool, I am routed as expected.
Does anyone have any ideas as to why my I-rule won't work; and know of another way to do this?
Thank you,
-Mike
2 Replies
hoolioCirrostratus
Hi Mike,
I think the issue is with the hyphen in the class name. If you really need the hyphen, you can reference it using braces ${::maui-qos}. If that doesn't fix the issue, then check what's in the class compared with the payload. Can you add a log statement with [HTTP::payload] and $::maui-qos?
log local0. "\[HTTP::payload\]: [HTTP::payload], \${::maui-qos}: ${::maui-qos}"
Also, you should be able to replace the two checks to see if the pool member is down or disabled with one check to see if it's "up".
Aaron
Michael_Mau_108That did the trick! It works just as expected now.
Thanks for the suggestion on verifying the health of the server. I had the two lines in there to account for a health check failure, and also in the event our monitoring group routed out the member using their scripts. This allows me to do that all in one line, looking for the server to be up; rather than down or session disable.
Thanks for your help!
