ACE ICMP probe

Hi,
I have a strange behavior on a ACE blade :
The blade is configured in bridge mode, when a configured reals server, if they are on the same site, the probe is ok, if they are on another site, the probe is failed.
What I found is that the echo reply on the PO of the blade is padded with 23 bytes of "0" only for the probe.
This is really strange...
the version of the blade and ios:
blade : 3.0(0)A1(4a)
Sup (720): 12.2(18)SXF8
I found on the forum that it could be related to the PFC3b but I don't see how I could try to bypass it.
Thanks for your help ;-)

I understand the reply will come on some ethernet module and be forwarded into the ACE PO.
So, what is the the ethernet hardware module type ? 'show mod'.
Could you also give us the trace so we can look at the icmp packet.
Thanks,
Gilles.

Similar Messages

ACE HTTP Probe with regex

ACE HTTP Probe with regex
Hi,
I'm trying to setup a HTTP probe with expected string rather then a code (config below). I do a GET for the page then a search for a string in the response however it's not working, as probe appears as failed.
I've tested the connection to the server by using telneting and then looking at the page displayed to make sure the string I want to match is in the response.
probe http HTTP-PROBE
port 43050
interval 30
passdetect interval 30
passdetect count 1
request method get url /action=help
open 43050
expect regex action=help
Q. Is there anything wrong with this configuration and what I'm trying to achive?
Thanks,
Pritesh

Use "expect status" under probe config. expect regex doesnt work if expect status is not configured.
expect regex work flawlessly with static pages. It doesnt work all the time with dynamic pages.
Specially if "content-length" header is missing from Server response.
Hope it helps
Syed Iftekhar Ahmed

ACE ping probe

Hi,
I have a strange problem on my ACE in one-arm design.
I have a real server which I can ping from the ACE, but a ping probe always fails:
server : APACHE4
10.144.131.6 28 28 0 FAILED
Socket state : CLOSED
No. Passed states : 0 No. Failed states : 1
No. Probes skipped : 4 Last status code : 0
No. Out of Sockets : 0 No. Internal error: 0
Last disconnect err : Server reply timeout (no reply)
Last probe time : Sat Dec 9 11:42:57 2006
Last fail time : Sat Dec 9 11:29:57 2006
Last active time : Never
ace/INTRANET# ping 10.144.131.6
Pinging 10.144.131.6 with timeout = 2, count = 5, size = 100 ....
Response from 10.144.131.6 : seq 1 time 0.335 ms
Response from 10.144.131.6 : seq 2 time 0.181 ms
Response from 10.144.131.6 : seq 3 time 0.340 ms
Response from 10.144.131.6 : seq 4 time 0.266 ms
Response from 10.144.131.6 : seq 5 time 0.341 ms
5 packet sent, 5 responses received, 0% packet loss
I have a couple of other real servers which do not have this problem.
Any ideas?
According to netflow on the 6500 the server answers correctly.
There are no syslog messages.
interface vlan 552
ip address 10.144.130.3 255.255.255.0
alias 10.144.130.1 255.255.255.0
peer ip address 10.144.130.2 255.255.255.0
no normalization
no icmp-guard
access-group input PERMIT
service-policy input MANAGEMENT
service-policy input SLB
no shutdown
probe icmp PING
interval 2
faildetect 5
passdetect interval 30
passdetect count 2
rserver host APACHE1
ip address 10.144.131.131
probe PING
inservice
rserver host APACHE2
ip address 10.144.131.132
probe PING
inservice
rserver host APACHE3
ip address 10.144.131.133
probe PING
inservice
rserver host APACHE4
ip address 10.144.131.6
probe TEST
probe PING
inservice
probe tcp TEST
port 22
interval 2
faildetect 5
passdetect interval 30
passdetect count 2
ace/INTRANET# sh probe
probe : PING
type : ICMP, state : ACTIVE
port : 0 address : 0.0.0.0 addr type : -
interval : 2 pass intvl : 30 pass count : 2
fail count: 5 recv timeout: 10
--------------------- probe results --------------------
probe association probed-address probes failed passed health
------------------- ---------------+----------+----------+----------+-------
rserver : APACHE1
10.144.131.131 2312 0 2312 SUCCESS
rserver : APACHE2
10.144.131.132 2311 0 2311 SUCCESS
rserver : APACHE3
10.144.131.133 2311 0 2311 SUCCESS
rserver : APACHE4
10.144.131.6 38 38 0 FAILED
rserver : IIS1
10.144.131.129 2311 0 2311 SUCCESS
rserver : IIS2
10.144.131.130 2311 0 2311 SUCCESS
probe : TEST
type : TCP, state : ACTIVE
port : 22 address : 0.0.0.0 addr type : -
interval : 2 pass intvl : 30 pass count : 2
fail count: 5 recv timeout: 10
--------------------- probe results --------------------
probe association probed-address probes failed passed health
------------------- ---------------+----------+----------+----------+-------
rserver : APACHE4
10.144.131.6 557 0 557 SUCCESS
I have 3.0(0)A1(3b)

Hi,
unfortunately your URL did not help me.
I found out that the sup720-3b adds a 23bytes zero-byte padding to exact the frames corresponding to the failing ping probe. I saw this by spanning the internal te4/1 port from the switch to the ACE to a sniffer.
The strange thing is that the frame is padded although it's larger than the minimum frame size of 64 bytes.
When I configure a log-input ACL on the sup720-3b to force the traffic to be routed by the MSFC3 instead of the PFC3 then the ping probe works and the same frames are not padded any more!!
We run IOS modularity on the sups and according to the 12.2SX release notes they do not support the ACE. I suppose that's the root cause. We will change the sup sw ASAP.

ACE - TCP probe goes into INVALID state

Hello,
I have a problem with the following configuration of a sticky serverfarm with a backup serverfarm
(this setup is ofcourse used only for failover purposes, not loadbalancing):
probe tcp tcp-8888-probe
port 8888
interval 5
faildetect 2
passdetect interval 3
passdetect count 1
rserver host rsrv1
ip address 10.1.2.10
inservice
rserver host rsrv2
ip address 10.1.2.11
inservice
serverfarm host rfarm-primary
predictor leastconns
probe tcp-8888-probe
rserver rsrv1 8888
    inservice
serverfarm host rfarm-backup
predictor leastconns
probe tcp-8888-probe
rserver rsrv2 8888
   inservice
sticky http-cookie RFARM-COOKIE sticky-rfarm-1
cookie insert browser-expire
serverfarm rfarm-primary backup rfarm-backup
etc....
The problem is that every time probe state changes (from SUCCESS to FAIL or otherwise), the tcp-8888-probe on the server that changed
the state of service, goes into INVALID state:
#show probe tcp-8888-probe detail
probe       : tcp-8888-probe
type        : TCP
state       : ACTIVE
description :
   port      : 8888    address     : 0.0.0.0         addr type : -
   interval : 5       pass intvl : 3               pass count : 1
   fail count: 2       recv timeout: 10
   conn termination : GRACEFUL
   expect offset    : 0         , open timeout     : 10
   expect regex     : -
   send data        : -
                       --------------------- probe results --------------------
   probe association   probed-address probes     failed     passed     health
   ------------------- ---------------+----------+----------+----------+-------
   serverfarm : rfarm-backup
     real      : rsrv2[8888]
                       10.1.2.11    291        0          291        SUCCESS
   Socket state        : CLOSED
   No. Passed states   : 1         No. Failed states : 0
   No. Probes skipped : 0         Last status code : 0
   No. Out of Sockets : 0         No. Internal error: 0
   Last disconnect err : -
   Last probe time     : Thu Jun 17 22:12:31 2010
   Last fail time      : Never
   Last active time    : Thu Jun 17 21:48:21 2010
   serverfarm : rfarm-primary
     real      : rsrv1[8888]
                       10.1.2.10    0          0          0          INVALID
   Socket state        : CLOSED
   No. Passed states   : 0         No. Failed states : 0
   No. Probes skipped : 0         Last status code : 0
   No. Out of Sockets : 0         No. Internal error: 0
   Last disconnect err : -
   Last probe time     : Never
   Last fail time      : Never
   Last active time    : Never
I have managed to get the probe into FAIL state again for a moment by removing it from serverfarm, and then reapplying, but in a few seconds it goes again from FAIL to INVAILD state, and stays in this state regardless of avaliability of probed TCP port. Only when i'm reapplying it when the port is avaliable/up, it can stay in SUCCESS state, and work till the failure of service, when INVALID state reappears.
What can be the cause of such behavior ?
thanks,
WM

Hello,
It looks very similar to this bug: CSCsh74871
You may need to collect a #show tech-support and do the following:
-remove the serverfarm in question
-reboot the ace module under a maintenance window.
You may upgrade to a higher version since your version is kind of old.
Jorge

ACE Health probe for SIP

I've setup a SIP probe to check the health of a Microsoft OCS. The health of this server is always failed. What am I missing? I also tried it with a telnet probe on port 5061, but got the same result. A telnet from ACE to the server on port 5061 works fine.
See below a show probe SIP detail and the relevant configuration.
ACE21_Secondary/MOCS# sh probe SIP det
probe : SIP
type : SIP
state : ACTIVE
description :
port : 5061 address : 0.0.0.0 addr type : -
interval : 10 pass intvl : 10 pass count : 3
fail count: 3 recv timeout: 4
request-method : OPTIONS
conn termination : GRACEFUL
expect offset : 0 , open timeout : 2
expect regex : -
------------------ probe results ------------------
associations ip-address port porttype probes failed passed health
------------ ---------------+-----+--------+--------+--------+--------+------
rserver : OCS_11
10.105.11.70 5061 -- 7566 7566 0 FAILED
Socket state : CLOSED
No. Passed states : 0 No. Failed states : 0
No. Probes skipped : 0 Last status code : 0
No. Out of Sockets : 0 No. Internal error: 0
Last disconnect err : Server reply timeout (no reply)
Last probe time : Thu Oct 30 14:18:42 2008
Last fail time : Tue Oct 28 16:31:30 2008
Last active time : Never
ACE21_Secondary/MOCS# sh run
probe sip tcp SIP
port 5061
interval 10
passdetect interval 10
receive 4
expect status 200 200
open 2
rserver host OCS_11
ip address 10.105.11.70
probe SSL
probe PING
probe SIP
probe SIP_TELNET
inservice
Cheers
Peter

Peter,
make sure to NOT run version A2(1.1a) as SIP probes are broken in that specific release.
If your version is something else, get a sniffer trace on the server to see what is going on.
Seems like we don't get a reply according to the line :
"Last disconnect err : Server reply timeout (no reply) "
Gilles.

ACE http probe "request method type" mandatory on A3(2.6)?

Hi people,
I recently upgraded to A3(2.6) from A3(2.0) and I don't see the N/A option on the http probe "request method type".
It also has an asterisk * which means it's mandatory.
I tried to set up a new http probe for another farm I am creating and the probe shows status failed, although I can ping and telnet to the http server on port 80 from the ACE context. My probe is like that:
probe http http_probe_WWW
interval 15
passdetect interval 60
expect status 200 200
open 10
My other http probes for other farms work ok after the upgrade and they are similar.
So my question is: Do I need to set the request method type or something else causes the probe to fail?
thanks a lot.
George

What you see is a problem with the GUI.
CSCtg78008 while creating http probe default method slected should be get as in CLI
But the request-method is not required.
So your config should work.
Do a 'show probe detail' to see the failure reason.
Get a sniffer trace as well.
Regards,
Gilles.

Ace HTTP Probe expect regex

Hi,
I have a question about the config of the ACe probe.
I have the following probe defined :
probe http P_HTTP_TEST
interval 5
passdetect interval 2
passdetect count 2
request method get url /test
expect status 200 200
expect regex trululu
I would like to use the regex just like the expect string on the csm probe...
The regex doesn't seem to work as the strin trululu is not on the page tested.
I guess the expect status override the regex but without the expect status it doesn't work either.
Anyone know how exactly the probe expect works for http ?
Another question, on the CSM module, the tcp probe by default use the real port for the probe, not the default port of the probe type, is it possible to change that so it mimmicks the CSM way of working ?
Thanks a lot ;-)

This seems to be bug related to some version of ACE software as HTTP return code overrides missing regexp. For sure this bug is present in:
system:    Version A2(2.0) [build 3.0(0)A2(2.0)]
Notice the difference between 192.168.1.1 (is missing regex in HTTP response) and 192.168.1.2 (sends regexp in HTTP response). Both are successful and as addition 192.168.1.1 (missing regexp) is showing last status code 200 which seems to be sufficient for probe to pass. 192.168.1.2 (which sends expected regexp) doesn't show last status code.
probe       : tw2_http_81
type        : HTTP
state       : ACTIVE
description :
   port      : 81      address     : 0.0.0.0         addr type : -
   interval : 30      pass intvl : 30              pass count : 1
   fail count: 1       recv timeout: 10
   http method      : GET
   http url         : /knowtw2-f/livelink.exe?func=ll&objtype=142&bypass
   conn termination : GRACEFUL
   expect offset    : 0         , open timeout     : 10
   expect regex     : lbmonitor
   send data        : -
                       --------------------- probe results --------------------
   probe association   probed-address probes     failed     passed     health
   ------------------- ---------------+----------+----------+----------+-------
     real      : 192.168.1.1[81]
                       192.168.1.1    2          0          2          SUCCESS
   Socket state        : CLOSED
   No. Passed states   : 1         No. Failed states : 0
   No. Probes skipped : 0         Last status code : 200
   No. Out of Sockets : 0         No. Internal error: 0
   Last disconnect err : -
   Last probe time     : Mon Nov 7 12:38:42 2011
   Last fail time      : Never
   Last active time    : Mon Nov 7 12:38:22 2011
     real      : 192.168.1.2[81]
                       192.168.1.2    2          0          2          SUCCESS
   Socket state        : CLOSED
   No. Passed states   : 1         No. Failed states : 0
   No. Probes skipped : 0         Last status code : 0
   No. Out of Sockets : 0         No. Internal error: 0
   Last disconnect err : -
   Last probe time     : Mon Nov 7 12:38:27 2011
   Last fail time      : Never
   Last active time    : Mon Nov 7 12:37:58 2011

ACE HTTP probe hash md5 value

Hi,
We would like to see the hash value calculated by the ACE when the HTTP probe hash command configured.
This is possible on CSS via the "sh service" command. We have tried to get it from sh rserver , sh probe XXX detail sh serverfarm XXX det but we do not get it.
Is this possible to get it on the ACE as we do on the CSS?
We need this to manually configure it via the hash <value> command because if the ACE probe is reseted for any reason, the probe http hash will be re-calculated based on the first http response of the server and we can not predict that the server will give the expected web page at this time.
A // question is: on what the md5 value is calculated? HTTP header + payload or only http object payload? We have calculated the md5 hash value by ourselves but the probe is still failing whatever the http portion used for the calculation is.
Many thanks for your help.
Regards/ludovic.

probe http MD5-HTTP
interval 15
passdetect interval 15
request method get url /index.html
expect status 200 200
hash 2441DA7F68A265F8CFB4426B6897CE33
And here is how I computed the hash on the server itself [linux machine]
md5sum /var/www/HTML/index.html
2441da7f68a265f8cfb4426b6897ce33 /var/www/HTML/index.html
[root@linux-1 tftpboot]#
The probe is UP
switch/Admin# sho probe MD5-HTTP detail
probe : MD5-HTTP
type : HTTP
state : ACTIVE
description :
port : 80 address : 0.0.0.0 addr type : -
interval : 15 pass intvl : 15 pass count : 3
fail count: 3 recv timeout: 10
http method : GET
http url : /index.html
Hash-value : 2441da7f68a265f8cfb4426b6897ce33
conn termination : GRACEFUL
expect offset : 0 , open timeout : 10
expect regex : -
send data : -
--------------------- probe results --------------------
probe association probed-address probes failed passed health
------------------- ---------------+----------+----------+----------+-------
serverfarm : linux1
real : linux1[0]
192.168.30.27 13 4 9 SUCCESS
md5sum is a standard tool.
Nothing fancy about it.
Gilles.

ACE -- SSH probe

Hello,
We are trying to configure an SSH probe.
I've tried creating a TCP port which checks for port 22, but I want to go further and get the probe to actually log on.
I noticed that only HTTP probes have an option to configure credentials.
Is there a way that I can configure a probe on the ACE to do this without having to create a script?
Thanks.

Hi Michelle,
If you manage to have a TCL script that connects through SSH, you can pass the username and password through arguments of the scripted probe and those arguments could be use to login.
Now how can you use TCL to login through SSH, I'm sorry but I don't know.
Regards,
Nicolas

ACE Health probe using get URL

Hello,
We are trying to create a health probe for our google search appliances and as part of the URL get there is a question mark but the ACE doesn't like that. Is there a way around this or should it be done differently?
request method get url /searchq? (This is what we want the URL to be)
request method get url /searchq (This is where it thinks i'm asking it for help)
Thanks in Advance.

Hello,
You need to typ CRTL+v prior to entering the ?
That's the Control key then lowercase v, then your question mark.
Hope this helps,
Sean

ACE failed probe and established connections

Hello,
I have four ACE 4710. Each pair of ACE is in one geographical location. Probes are configured so that it is checking regular regex (HTTP GET).
When there is need rserver update we change text in our testpage.html (for ie. from "OK" to "SUSPEND" ) so that probe detect fail.
In fact rservers are still operational, but should not accept new connections. This works fine.
BUT I observed that established connection/sessions did not end up after probe fails. ACE probably wait for openned/established connections to end up and it is what I am askign for.
What happens if probe fails but in fact rserver is operational? I thought that if probe fails it also end up/cut all established connections to rserver. But seems it is not true. Does anybody has this experience?
Thanks for your opinion.
Jan

Hello Jan,
if I understood correctly what you're looking for is domented in the area for the failaction command which actually makes the ACE behavior on this aspect configurable:
http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/ace_appliances/vA4_2_0/configuration/slb/guide/rsfarms.html#wp1117375
indeed the default behavior of the ACE is to take a failed real server out of load-balancing rotation for new connections and to allow existing connections to complete.
Hope it helps,
Francesco

ACE dual probe AND-action

Hi,
I have the need of a dual probe with a AND-action, ie both probes needs to be down to take the service down.
The following configuration is an OR-operation but I need a AND-operation.
Any? Scripted?
probe https HEALTHCHECK-OPEN-SSL
interval 10
passdetect interval 5
receive 2
ssl version all
request method get url /open/healthcheck.html
expect status 200 200
header User-Agent header-value "Cisco-Probe"
hash
connection term forced
open 2
probe https HEALTHCHECK-SSL
interval 10
passdetect interval 5
receive 2
ssl version all
request method get url /healthcheck.html
expect status 200 200
header User-Agent header-value "Cisco-Probe"
hash
connection term forced
open 2
serverfarm host MOBI-SSL
probe HEALTHCHECK-SSL
probe HEALTHCHECK-OPEN-SSL
rserver MOBI-NY-L 443
inservice
rserver MOBI-NY-R 443
inservice

Hi,
Use the "fail-on-all" command to configure the ACE to take the rserver out of service if all the associated probes fail. You can use this command under the serverfarm or the rserver.
-Alex

ACE HTTP Probe Question (HTTP Version)

Hello, I am wondering what HTTP version ACE uses when sending HTTP/HTTPS probes to a web server. I am currently running A2(3.3) if that has any bearing. TIA

Hi,
The default get request method is HTTP/1.1 when the ACE is sending the probe and i dont
think there is a way to change this default behavior.
Regards,
Siva

ACE HTTP Probe

Hi,
This is the current probe that I am using:
probe http http-probe
interval 3
passdetect interval 3
passdetect count 3
request method head
expect status 200 200
Someone told me that I should be using a more sophisticated web page to probe. If you agree with that statement, could someone please provide a sample config?
Thank you...

Hi,
I'm not sure what your colleague meant by more sophisticated. When I've set up an HTTP probe I've asked that the server management team set up a simple static page on the server that can be tested. So in my probe I'd specify something like:
request method head url /serverhere.html
This enables the team to take a server out of service by renaming the page (e.g. to servernothere.html) without having to ask me to modify the ACE configuration. The server can then be tested without real users having access and brought back in when they're happy.
HTH
Cathy

ACE - peer probes

Hi,
We have a scenario where we PBR certain certain source IP`s back into the ACE to perform server NAT`ing. This is routed into the ACE via a alias IP.
Problem we have is this breaks probes on the back up ACE as we health check the same IP`s for a inbound VIP ( when the FT pairs are flipped the problem is reversed ) as I assume the Alias interface has no record of the flow and bins the traffic ( as it originated from the backup ACE interface not the alias )
So my quick question would be is their any way a backup peers probes can be disabled as it creates a lot of half open connections on the servers ?
I dont want to change the PBR to use real IP`s as could break some failover scenarios and adding a more complex ACL to the PBR creates issues with the NAT we`re doing
Thanks

The short answer is no the back up probes cannot be disabled. In fact you want the probes to be working in the case of a failover. I am not sure how you have your pbr working, but the probes are sourced from the interface ip addresss on the vlan (not the alias). The ACTIVE and the STANDBY have unique ip addresses, so as long as you account for this in your pbr you should be fine.
Chris

ACE ICMP probe

Similar Messages

Maybe you are looking for