routing to a pool based on protocol

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.

I 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.

I'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?