ACE Probing throws errors in application log's

[mroettgen]

Hi all,

i hope i can find some help here within the forums. we ran into the following issue during a migration from foundry to the ACE-20 loadbalancers:

ACE: with normal TCP probing on (example) port 7525 the ACE opens the socket, waits for the 3 way handshake to be completed and is then closing the connection with either a FIN (default) or a reset (per command in the probe config)

FOUNDRY: (same setup as on the ACE) doing the probing a bit differently: It opens the socket and sends out a SYN and after receiving the SYN ACK it is resetting the connection with an RST directly.

in one of our applications this is causing an error as the ACE is doing the complete handshake and then the applications "thinks" it has an connect which is closed unexpected and therefore is throwing an error message in the log. in the configuration with the foundry the application does not really see the probing at all.

is there any known way to change this behavior on the ACE? maybe with tcl scripts ? i'm far away of to be a scripter. i took already a look into the config guides for tcl scripts but havent seen a chance at a first glance.

so ideas and input are very appreciated and welcome.

many thanks in advance

Martin

[mwinnett]

Martin, I did see one previous instance where this behaviour of F5 was discussed, but nothing appeared to come of it. There is no way to generate a tcp based probe without a full 3-way handshake. For the scripting, the sample scripts use the "socket" linux command. There is nothing in the man pages to indicate how socket could send reset in response to syn-ack. However, for that particular application, would it be possible to use a probe that sent some acceptable date and monitoring for the reply before terminating. eg:

probe tcp test1

  port 7525

  send-data "Are_you_up_and_running"

  expect regex "^I_am_functioning_properly"

Matthew

[mroettgen]

HI Matthew,

i will discuss this with our application owner and come back with that. the thing is, that the application is a bit b*tchy when it doesnt get the correct data in the correct way (as it is normally mobile traffic thats coming in there)

but i will have a discussion about it. As it is not working anymore as it was done before we need to find a way around that and not filling up logs with errors anymore.

many thanks

Martin

[mwinnett]

Martin,

we have released EOL notifications for the ace20s

http://www.cisco.com/en/US/prod/collateral/modules/ps2706/end_of_life_c51-674430.html

We are still fixing defects, but I find it unlikely that new features will be addef to the A2.3.x code train. If you want to try, you can open a tac case and point it to me and we can see what can be achieved.  We can certainly aim at getting this feature into the ace30/4710 code base (A5.x).

Matthew

[mroettgen]

HI Matthew,

we've already heard of that and our cisco sales manager is pushing us to migrate to the ACE 30 in the near future (budget thingie).

I havent spoken to the application the guys yet. It will be a discussion and i will try to push them in the direction of an HTTP probing which is more reliable then tcp probing only.

Lets see whats the outcome of this will be.

Quote:

  We can certainly aim at getting this feature into the ace30/4710 code base (A5.x).

Do you guys need a feature request then from a customer or are you planning to have this as an option in any case?

BR

Martin

[mwinnett]

Michael, there are 2 ways to get features added, via a TAC case and TAC open a defect report as sev 6 (enhancement) or a PERS (might have been superceded by something newer) request via your local Cisco account manager. What I mean't to say was that we (me & you) can try to get the feature added to the A5 code. It will not go into the A2 (ace20) code base. There are no plans for such a feature at the moment. Matthew