Forum Discussion
NimbostratusConvert from ACE
Hi, I have converted from Cisco's ACE to the LTM. I am having a problem building one of the custom stickys that Cisco helped us build. Can anyone help convert this:(as it sits this is ACE language)
sticky layer4-payload stagehub-sticky
timeout 240
replicate sticky
serverfarm stagehub-farm
response sticky
layer4-payload offset 43 length 32 begin-pattern "(\x20|\x00\xST|([^\x20 ^\x00]\xST))"
I have tried building this in the LTM but it does not work as it did before. Here is how it looks now:
ltm persistence hash /Common/stageHUB {
app-service none
defaults-from /Common/hash
hash-algorithm default
hash-buffer-limit 0
hash-end-pattern none
hash-length 32
hash-offset 43
hash-start-pattern "(\\x20|\\x00\\xST|([^\\x20 ^\\x00]\\xST))"
match-across-pools disabled
match-across-services disabled
match-across-virtuals disabled
mirror disabled
override-connection-limit disabled
rule none
timeout 14400
}
Any help would be greatly appreciated.
6 Replies
ACE regex engine is likely to be different than the one used by iRules. iRules use tcl regex.
BigiP uses tcl version 8.4, so according to this page: http://www.regular-expressions.info/nonprint.html you need four digits after the \x
so try this:
(\\x0020|\\x0000\\xST|([^\\x0020 ^\\x0000]\\xST))HTH
Tim_Petersen_15Bummer, didn't work. Let me explain more of what we are doing and maybe someone can help me find out what it should be. When we take a lync call, our front ends send the call off to be recorded. We need that to be persistent, but we can't use the built in sip persistence because it is converted to RTAudio. Somehow we have to do a layer 4 offload inspection to get that hash. I guess it is possible I am using the wrong begining hash... is there a way to log what the F5 sees at that offset? If I remove the start pattern the call seems to go through without an issue, as soon as I add anything the call fails.
You can use an iRule to log part of the tcp payload but, it would be easier to do a tcpdump and view it using wireshark.
You can also use an iRule for the persistence instead of the hash operation. The irule would have a similar regex expression but at least you will be able to troubleshoot.
BTW: what is the \xST supposed to match.
- Tim_Petersen_15It was put in before I got there, but I believe this is supposed to grab the call-ID and if this were sip I would just use that prebuilt profile. Do you have to have an sample irule that could help with the persistence?
kmg_atl_118558so in the ACE config the "layer4-payload offset 43 length 32 begin-pattern "(\x20|\x00\xST|([^\x20 ^\x00]\xST))"" should generally correlate to BIGIP SSL persistence. SSL persistence is usually used for non-terminated SSL sessions, and tracks user connections using the SSL session ID. At least that has been my experience converting 50+ ACE's to LTM. That said SSL persistence is NOT always reliable as I do believe that IE specifically re-negotiates every 2 minutes, so that session ID value can change whenever client re-negotiation takes place. if you use SSL persistence you should also use source ip as a backup persistence.
- Tim_Petersen_15
I never fully got this working for what I needed... however, I did finally figure out a solution that works for us.(really has nothing to do with the original question!)
Long story short, what I needed was to adjust the idle timeout so it would create a "new" connection each time a call comes in so they are load balanced rather than getting stuck to one server for all calls. So this whole time I should not even been looking for a persistence solution, no clue how it was working with the ACE before. Either way, works like a champ.
