Forum Discussion
routing to a pool based on protocol
I have have a set of optimization servers that I want to route all http traffic to, and I want all other non-http traffic on port 80 to route to a different pool. This is what I have, but when non-http traffic comes through, my else statement never seems to fire.
Is there a more elegant way to accomplish this?
when CLIENT_ACCEPTED {
TCP::collect 1024
log "collecting"
}
when CLIENT_DATA {
if {([TCP::payload] contains "HTTP") }{
log "Optimization"
pool Optimization_Pool
log "Optimization Pool"
}
else {
log "FW"
pool Firewall_Pool
}
TCP::release
}
Thanks for the help.
9 Replies
hoolioCirrostratus
Hi,
Can you add a log statement in the CLIENT_DATA event before the if, to log the TCP::payload output?
What actually happens with non-HTTP requests? Are they also being sent to the optimization pool, or are they hanging?
Aaron- I added the following. log "Payload =[TCP::payload]"
I never see anything in the logs with the payload, I only see the "collecting" log entry. It does not seem to ever get to the CLIENT_DATA portion of the rule.
I am using the 8800 platform with 9.4. - hoolioI would guess that the client isn't sending the number of bytes you're waiting to collect. Can you lower the collect to 10 or 100 and retest?
Aaron - I retested using the following.
when CLIENT_ACCEPTED {
TCP::collect 10
log "collecting"
}
when CLIENT_DATA {
log "Payload = [TCP::payload]
if {([TCP::payload 10] contains "HTTP") }{
log "Optimization"
pool Optimization_Pool
log "Optimization Pool"
}
else {
log "FW"
pool Firewall_Pool
}
TCP::release
}
I also noticed this in the release notes for 9.4. Could this be causing an issue also?
Using TCP::release and TCP::connect commands (CR63722)
If you use the TCP::release command in a CLIENT_DATA event, and then use the TCP::collect command to collect a specific amount of data, the TMM service becomes unavailable. To avoid this issue, use the TCP::collect command without an argument, and then use logic to determine whether enough data has been collected in the CLIENT_DATA event. - hoolioI'm fairly sure other people have used TCP::collect x in CLIENT_ACCEPTED and TCP::release in CLIENT_DATA, in 9.4.
I hadn't seen that CR before. Thanks for pointing it out. I checked AskF5 for more detail on it, but didn't find any solutions about it.
I think this issue doesn't apply to your rule, as you're using TCP::collect X in CLIENT_ACCEPTED and not using it in the CLIENT_DATA event.
Perhaps someone with access to CR notes could provide more detail on this?
If you change the collect to 10, do you get any logging in CLIENT_DATA? Else, what if you do try it collecting without a byte count?
Aaron - I have tried using both 10 as well as no value, and no matter what I use I cannot get the CLIENT_DATA portion of the rule to fire. The rule just hangs before the CLIENT_DATA event.
You were right about the issue in the release notes not affecting this. I checked out the notes in the CR and it definitely applies only to using TCP::collect within the CLIENT_DATA event. - Also, when I log the TCP::payload length in the CLIENT_ACCEPTED event, I get a 0.
May 23 13:41:55 tmm tmm[1708]: 01220002:6: Rule Non_HTTP_Rule_1 : 0
when CLIENT_ACCEPTED {
if {[TCP::local_port] == 80}{
TCP::collect 5
log "[TCP::payload length]"
}
}
Is this valid or will I get an incorrect response when logging this at the CLIENT_ACCEPTED level? - "TCP::payload length" isn't available until the CLIENT_DAT event. Basically that value is the amount of payload that has been retrieved. When you issue the TCP::collect, method that triggers a collection sometime between exiting the CLIENT_ACCEPTED event and before the CLIENT_DATA event.
-Joe - Is there anything that would keep my CLIENT_DATA event from firing? When I send valid HTTP traffic, the CLIENT_DATA event fires, but when it is non http traffic i never get out of the CLIENT_ACCEPTED event and everything hangs.
Any ideas?
