Forum Discussion
Andre_12127
Nimbostratus
Aug 09, 2012Ok the Thread is smelling a little necrotic already, yet I wanted to share how things turned out.
First of all, the Hoolios hint on using the "sh sys conn" command on the TMSH was a great help. We could monitor the connecting session for the specific VS that way very nicely and it ultimately helped us tracking the correct connection down.
Our original focus was to add a new forwarding VS which would match when the load balanced applicationservers behind the LTM would open a connection to the database server to fetch their data. We used a client protocol profile (based on the fast L4 profile) which had a longer timeout setting then the default profile. We then tracked the matching of the VS in another try and saw the longer timeouts. At the same moment we also noticed that this connection was never even close to hitting that time out since the application and the database server had a lot of pakets going back and forth between them. Nevertheless the application broke down after exactely 3600 seconds.
After some more testing we finally found out that it wasn´t the server<->server communication between those two servers mentioned earlier that caused the problem, but the client component installed on a regular PC. The responsible person for the application jumped to some conclusions from the applications error logs and send us on a wild goosechase.
Since the application only runs once a year (but is nevertheless very important) and since it does not need any HA features, we have decided to port it onto a server outside the LTM segments.
Thanks for your help folks, you contributed a lot to the solution .... even though things turned out quite different from what we orginally assumed.
XL