Forum Discussion

James_Greenlee_'s avatar
James_Greenlee_
Icon for Nimbostratus rankNimbostratus
May 02, 2008

Siebel iRule

Hi all, first time poster here.

I've got a Siebel deployment that looks like it was configured using the tools outlined in the Deployment Guide for Siebel 7 and F5 v9.

The iRule looks like this...

when CLIENT_ACCEPTED { TCP::collect 1 }
when CLIENT_DATA {
if { [findstr [TCP::payload] "/siebel" 0 " "] == "/siebelpro/eautoobjmgr_enu" } {
    log local0. "Using pool eautoObjMgr_enuConnPool" 
   pool eautoObjMgr_enuConnPool 
}
elseif { [findstr [TCP::payload] "/siebel" 0 " "] == "/siebelpro/eautoobjmgr_enu/rr" } {
    log local0. "Using pool eautoObjMgr_enuRRPool" 
   pool eautoObjMgr_enuRRPool 
}
elseif { [findstr [TCP::payload] "/siebel" 0 " "] == "/siebelpro/eautoobjmgrext_enu" } {
    log local0. "Using pool eautoObjMgr_enuConnPool" 
   pool eautoObjMgr_enuConnPool 
}
elseif { [findstr [TCP::payload] "/siebel" 0 " "] == "/siebelpro/eautoobjmgrext_enu/rr" } {
    log local0. "Using pool eautoObjMgr_enuRRPool" 
   pool eautoObjMgr_enuRRPool 
}
elseif { [findstr [TCP::payload] "/siebel" 0 " "] contains "/!6." } {
    log local0. "Using pool rilpros7om01lbbServerPool" 
   pool rilpros7om01lbbServerPool 
}
elseif { [findstr [TCP::payload] "/siebel" 0 " "] contains "/!3." } {
    log local0. "Using pool rilpros7om02lbbServerPool" 
   pool rilpros7om02lbbServerPool 
}
elseif { [findstr [TCP::payload] "/siebel" 0 " "] contains "/!4." } {
    log local0. "Using pool rilpros7om03lbbServerPool" 
   pool rilpros7om03lbbServerPool 
}
elseif { [findstr [TCP::payload] "/siebel" 0 " "] contains "/!5." } {
    log local0. "Using pool rilpros7om04lbbServerPool" 
   pool rilpros7om04lbbServerPool 
}
else { 
   log local0. "Rejected request for [findstr [TCP::payload] "/siebel" 0 " "]"
   discard }
}

We had a failure yesterday that was pretty odd and it looked like all the client data streams lost their affiliation with Siebel server. Based on the rule, if it already has a session but it doesn't match an OM server ID then it hits the log and discard statement.

The log and discard statement logged the following information into the LTM log file...

May 1 09:56:53 tmm tmm[728]: Rule siebelproRule : Rejected request for

So it looks like the log statement at the end of the iRule is improperly written? I would think some other information would be nice to have. Source IP? Destination OM? Anything would be nice.

For the record, of the 4 OM's, only one appeared to be accepting sessions during this issue, but none of the health monitors failed on any server in the pools.

And speaking of the health monitor...Why is there a GET but no receive statement in the recommended monitor? What good does that do?

Forgive the ignorance...I'm not a Siebel person.

Thanks,

James
application delivery
dev
devops
iRules
  • Nicolas_Menant's avatar
    Nicolas_Menant
    Icon for Employee rankEmployee
    May 02, 2008
    The fact that your log doesn't contain anything simply means that it didn't find in the TCP payload some data starting with /siebel. look at the findstr command definition Click here

     

     

    if you want IP data to your log you may use [IP::client_addr], [IP::server_addr]: Click here

     

     

    You should have a look at the iRules wiki to find other data you may wish to troubleshoot: Click here

     

     

    A monitor with only GET will at least ensure the service is open and available. If you want to ensure for example that the request is fine then you may add 200 for example to the response analysis. I'm not a siebel person either so can't say what may be the best to monitor such a service!

     

     

    HTH