Is there anyway to make this Siebel iRule more efficient?

Unfortunately, I do not have direct access to this customers LTMs so getting logs and dumps is a lil tedious to say the least. I am adding logging rules to each event to capture complaints after tweaking the iRule further and reapplying. My apologies to all and many thanks for the great help.

The now tweaked iRule:

 

 

when CLIENT_ACCEPTED {

 

TCP::collect 1

 

}

 

 

when CLIENT_DATA {

 

switch -glob [findstr [TCP::payload] "/siebel" 0 " "] {

 

"/siebel/finsobjmgr_enu" -

 

"/siebel/smobjmgr_enu" -

 

"/siebel/eaiobjmgr_enu" -

 

"/siebel/sccobjmgr_enu" -

 

"/siebel/finsobjmgr_enu/rr" -

 

"/siebel/smobjmgr_enu/rr" -

 

"/siebel/eaiobjmgr_enu/rr" -

 

"/siebel/sccobjmgr_enu/rr" {

 

log local0. "Using pool company.org_2321_pool"

 

pool company.org_2321_pool

 

}

 

"*/!5.*" {

 

log local0. "Using pool company.org_APP01_2321_pool"

 

pool company.org_APP01_2321_pool

 

}

 

"*/!7.*" {

 

log local0. "Using pool company.org_APP02_2321_pooll"

 

pool company.org_APP02_2321_pool

 

}

 

"*/!9.*" {

 

log local0. "Using pool company.org_APP03_2321_pool

 

pool company.org_AP03_2321_pool

 

}

 

"*/!b.*" {

 

log local0. "Using pool company.org_APP04_2321_pool"

 

pool company.org_APP04_2321_pool

 

}

 

"*/!d.*" {

 

log local0. "Using pool company.org_APP05_2321_pool"

 

pool company.org_APP05_2321_pool

 

}

 

default {

 

log local0. "Rejected request for [findstr [TCP::payload] "/siebel" 0 " "]"

 

discard

 

}

 

}

 

}

 

 

...so I now need to get a change request to apply this new rule (sigh) and test. The string does usually looks something like:

 

 

pool.company.org:2321/siebel/finsObjMgr_enu/!5.8d0ac.d0005c.4d9e146d.000013964d9d0cf4

 

 

but also:

 

 

pool.company.org:2321/siebel/finsObjMgr_enu/RR/!5.8d0ac.d0005c.4d9e146d.000013964d9d0cf4

 

 

and...

 

 

pool.company.org:2321/siebel/finsObjMgr_enu/rr/!5.8d0ac.d0005c.4d9e146d.000013964d9d0cf4

 

 

You're on the right track, there, Sully! A two-wildcard glob match is still going to be more efficient than a regex match, and it looks like, based on the output, that you're not going to run into duplicate matching with the strings you have. Let us know how it goes!

Thanx for the feedback Joel - appreciate it man! I'll get this iRule applied again, test and let ya know what happens.

What was the outcome of the double-glob configuration? I'd like to make similar changes to our Siebel lb regime.

Double glob? Meaning two wildcard match? That should work just fine. Or was it something else you were asking about?

 

 

Colin

I am trying to implement the same solution to load balance Siebel Application servers using the F5 and not the native lbconfig file. I am running v11.1 and using the Siebel template to create the iRule and associated configuration items.

 

 

I get traffic to the "/siebel/finsobjmgr_enu" object manager pool, but never to the "/siebel/finsobjmgr_enu/rr" pool or any of the server pools.

 

 

Did you have to make any adjustments in the Siebel configuration outside of the eapps.cfg file to utilize a 3rd party load balancer?

 

 

My iRule seems to match yours above, but the Siebel traffic does not seem to ever match the URI triggers for the server pools or /rr pool

 

 

I have triple checked the lbconfig file from the Sieble administrators and everything is correctly captured in the iRule (server numbers and object names)

 

 

I have captured the traffic with a analyzer and I never see the /rr or server id's in the TCP payload to trigger the iRule.

 

 

when CLIENT_ACCEPTED {

 

TCP::collect 1

 

}

 

when CLIENT_DATA {

 

switch -glob [findstr [TCP::payload] "/cmsngdtst1" 0 " "] {

 

"/cmsngdtst1/finsobjmgr_enu" {

 

log local0. "Using pool ngdtst_app_FINSObjMgr_enuConnPool"

 

pool ngdtst_app_FINSObjMgr_enuConnPool

 

}

 

"/cmsngdtst1/finsobjmgr_enu/rr" {

 

log local0. "Using pool ngdtst_app_FINSObjMgr_enuRRPool"

 

pool ngdtst_app_FINSObjMgr_enuRRPool

 

}

 

"*/!4.*" {

 

log local0. "Using pool ngdtst_app_ndl58070ServerPool"

 

pool ngdtst_app_ndl58070ServerPool

 

}

 

"*/!b.*" {

 

log local0. "Using pool ngdtst_app_ndl58039ServerPool"

 

pool ngdtst_app_ndl58039ServerPool

 

}

 

"*/!e.*" {

 

log local0. "Using pool ngdtst_app_ndl58041ServerPool"

 

pool ngdtst_app_ndl58041ServerPool

 

}

 

"*/!6.*" {

 

log local0. "Using pool ngdtst_app_ndl58028ServerPool"

 

pool ngdtst_app_ndl58028ServerPool

 

}

 

"*/!8.*" {

 

log local0. "Using pool ngdtst_app_ndl58029ServerPool"

 

pool ngdtst_app_ndl58029ServerPool

 

}

 

"*/!10.*" {

 

log local0. "Using pool ngdtst_app_ndl58048ServerPool"

 

pool ngdtst_app_ndl58048ServerPool

 

}

 

default {

 

log local0. "Rejected request for [findstr [TCP::payload] "/cmsngdtst1" 0 " "]"

 

}

 

}

 

}

 

Hello all

 

Sorry for digging out this old thread, but it perfectly matches my question. I'm migrating an existing Siebel Installation from Cisco ACE to F5 BigIP LTM 11.3.

 

Question: Is there a good reason to do the URL matching on the TCP layer instead of doing it with HTTP URI matching? On the ACE we did it with HTTP URI matching and it has been working fine for ages.

 

Greetings Mat

 

Well, to response my own question: The traffic doesn't look like pure HTTP traffic. I guess the HTTP profile won't work. To be confirmed. On the ACE we had the URL matching rules restricted to POST requests. That could be an enhancement to the iRules posted above.

 

Greetings Mat