ACE Probing

Hi All,
Is there any option in ACE to probe the application based on its state,
if the application goes hang, the tcp ports are still open and hence the VIP is alive.So the ACE always has the VIP active.
Is there an option to probe the server based on the application status.
Please inform me since it is a very urgent requiremnt for us.
Regrds
Aslam ....

Hi Aslam,
To a large degree this depends on your application - you haven't said what it is. There are built-in probes for some applications and additional sample probe scripts that may be installed.
If there isn't a suitable script already, then you have the option of writing custom code in Tcl.
HTH
Cathy

Similar Messages

  • ACE probing of "virtual hosts" on web servers

    We got some web servers that hosts multiple web sites and would like to probe each of these sites.  Is there a way to configure a probe to present the request for a particular web site versus the other without falling into the catch all clause of the http server configured on the box ?
    Thanks

    Hello Folks,
    I wonder if you could get away with just using the built-in HTTP probe rather than the scripted probe?  With the built-in HTTP probe, you can configure all sorts of HTTP headers, including the Host header which might be all you need for your server hosting multiple sites.
    Just to clarify on the support for scripted probes that TAC supports:  If the script is downloaded from cisco.com, and is not modified, then TAC will support it.  It is not supported if it is modified, and TAC will not support custom-created scripts.
    Hope this helps,
    Sean

  • ACE keep probing real servers using "https get 302"

    Hi all,
    I got one problem with cisco ACE in my company. Currently, two ACE appliances are working as HA redundancy. Previously I enabled some https and http probing using get 302 for some servers and services. But then I was told to remove all https or http probing, and instead use tcp port 443 and 80. After that, one of the serverfarm (server groups) is receiving https get 302 and I already checked in the monitoring and see whether there's any https probing regarding the respected real servers. But I could not find any. Even I disable all probing to that serverfarm, all the server members still receiving https get 302. Is this behavior a bug?
    The ACE version is A3(2.1). And the HA status is on standby cold. Can standby cold cause this kind of trouble?

    Hi Daniel,
    I just corrected the cert problem and made the state peer into standby hot. But still it still keep probing the get 302. And then I tried to restart both ACEs. The first step is to restart the second ACE (standby) and then switched over all context to the second one. The problem is that when I made the second one to be active, some services were not working, especially the ones with ssl terminated in ACE. I'm pretty sure that both ACEs were in sync.
    Any idea what is the problem?

  • ACE Rserver "inservice" - probing?

    Hello all
    We recently upgraded an ACE module from A1 code straight through to A2(3.4)
    Theres a behaviour change we werent expecting -
    probe tcp t2-probe-3133
      port 3133
      interval 4
      faildetect 4
      passdetect interval 4
      passdetect count 4
      receive 1
    serverfarm host ext-gxr-3133
      probe t2-probe-3133
      rserver server-testing 3133
      inservice
    If I take the "rserver server-testing" out of service and then bring it back in, it goes straight to OPERATONAL even if the service listening on port 3133 is not there - the probe eventually fails, the server drops to OUTOFSERVICE.
    During this time we drop transactions on the serverfarm.
    This is different from the A1 behaviour - it used to wait till the probe finished (We're pretty sure anyway :-) )
    Am I dreaming - this hasnt changed ? - And regardless, is there a way to make the behaviour "Wait until the probes work before bringing the server in" ?
    Cheers
    Graeme.

    Graeme-
      I just tested this on A1(6.3) and A2(3.3) - both do exactly the same in terms of thier default action.  When the rserver is operational with no probe configured, and you add a probe, the rserver stays operational until the probe fails.  If the rserver was in probe failed state to begin with and you add a 2nd probe to the serverfarm, the rserver stays in probe-failed while testing the the new probe. 
    There was a difference in A1(6.X) vs A2(3.X) - the addition of "fail-on-all" under the serverfarm which makes all probes have to fail prior to removing it from loadbalancing rotation.  I did test with that feature on, and it still has the same result.
    If you are getting something different from this, go ahead and get a TAC case open to have a bug investigated/filed.
    Regards,
    Chris Higgins

  • 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: How does one probe "rservers redirect" in "serverfarm redirect"?

    Probes can be used with serverfarms of type host
    probe http WEB_SERVERS
    interval 5
    passdetect interval 10
    passdetect count 2
    request method get url /index.html   expect status 200 200
      !--- Probe used to detect the status  !--- of the servers in the serverfarm.
    rserver host S1
    ip address 192.168.0.200
    inservice
    rserver host S2
      ip address 192.168.0.201
      inservice
    rserver host S3
      ip address 192.168.0.202
      inservice
    rserver host S4
      ip address 192.168.0.203
      inservice
    serverfarm host SF-1
      probe WEB_SERVERS
      rserver S1
       inservice
      rserver S2
       inservice
      rserver S3
       inservice
      rserver S4
       inservice
    When it comes to "serverfarm redirect" how would one emulate the probing to work as above. (When one is loadbalancing servers of type redirect, the probe command is not available for serverfarm redirect SF-2)
    Its also not possible to mix reservers of type redirect with serverfarm of host. If it was possible, This would have answered my question, which is.
    How does one emulate the probe functionality found in rsever host and serverfarm host in serverfarm redirect?

    Probing a redirect server was supported on A2(3.2) or later.
    So, you can use the probe configuration on 'serverfarm redirect', where 'ip address [ip_address] routed' option is required.
    http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/vA2_3_x/Release/Note/RACEA2_3_X.html#wp620109
    Unfortunately, 'rserver host' and 'rserver redirect' cannot exist together in the same serverfarm since 'serverfarm host' is
    for real server and 'serverfarm redirect' is for redirect rserver.
    http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/vA2_3_0/command/reference/config.html#wp1117844
    When you use backup serverfarm as below, you can use both serverfarms. However, you cannot use primary serverfarm
    and backup serverfarm at the same time.
    policy-map type loadbalance first-match lb
      class class-default
        serverfarm SF1 backup SF2
    Regards,
    Yuji

  • ACE VIP OK HTTP, NOK other TCP port

    Hi,
    we are having issues in configuring load balancing for a TCP port. For HTTP it's working without issues and we have the ACE also balancing for other TCP ports.
    Here goes the relevant config:
    probe http PROBE-HTTP
      interval 5
      passdetect interval 2
      passdetect count 1
      request method get url /idc/
      expect status 200 200
    probe tcp PROBE-TCP
      port 4444
      interval 5
      passdetect interval 10
    rserver host PRD1
      ip address 10.10.10.1
      inservice
    rserver host PRD2
      ip address 10.10.10.2
      inservice
    serverfarm host SF-HTTP
      probe PROBE-HTTP
      rserver PRD1 80
        inservice
      rserver PRD2 80
        inservice
    serverfarm host SF-TCP
      probe PROBE-TCP
      rserver PRD1 4444
        inservice
      rserver PRD2 4444
        inservice
    sticky ip-netmask 255.255.255.255 address source SC-IP-PRD-HTTP
      timeout 10
      serverfarm SF-HTTP
    class-map match-all NAT-VIP-HTTP
      2 match virtual-address 10.10.35.1 any
    class-map match-all NAT-VIP-TCP
      2 match virtual-address 10.10.35.1 tcp eq 4444
    policy-map type loadbalance first-match LB-VIP-HTTP
      class class-default
        sticky-serverfarm SC-IP-PRD-HTTP
        insert-http x-forward header-value "%is"
    policy-map type loadbalance first-match LB-NAT-VIP-TCP
      class class-default
        serverfarm SF-TCP
    policy-map multi-match POLICY-RSERVER-VIP
      class NAT-VIP-TCP
        loadbalance vip inservice
        loadbalance policy LB-NAT-VIP-TCP
        loadbalance vip icmp-reply active
        nat dynamic 1 vlan 200
      class NAT-VIP-HTTP
        loadbalance vip inservice
        loadbalance policy LB-VIP-HTTP
        loadbalance vip icmp-reply active
        nat dynamic 1 vlan 200
    interface vlan 200
      description SERVER-SIDE
      ip address 10.10.14.2 255.255.255.0
      alias 10.10.14.1 255.255.255.0
      peer ip address 10.10.14.3 255.255.255.0
      access-group input EVERYONE
      nat-pool 1 10.10.4.6 10.10.4.6 netmask 255.255.255.255 pat
      service-policy input AllowICMP
      service-policy input POLICY-RSERVER-VIP
      no shutdown
    The probe are OK, but nothing seems to get to the VIP:
    ACE/CTX# show probe PROBE-TCP
    probe       : PROBE-TCP
    type        : TCP
    state       : ACTIVE
       port      : 4444    address     : 0.0.0.0         addr type  : -
       interval  : 5       pass intvl  : 10              pass count : 3
       fail count: 3       recv timeout: 10
                           --------------------- probe results --------------------
       probe association   probed-address  probes     failed     passed     health
       ------------------- ---------------+----------+----------+----------+-------
       serverfarm  : SF-TCP
         real      : PRD1[4444]
                           10.10.10.1     8853       1          8852       SUCCESS
         real      : PRD2[4444]
                           10.10.10.2     8853       1          8852       SUCCESS
    ACE/CTX# show serverfarm SF-TCP detail
    serverfarm     : SF-TCP, type: HOST
    total rservers : 2
    active rservers: 2
    description    : -
    state          : ACTIVE
    predictor      : ROUNDROBIN
    failaction     : -
    back-inservice    : 0
    partial-threshold : 0
    num times failover       : 0
    num times back inservice : 1
    total conn-dropcount : 0
    Probe(s) :
        PROBE-TCP,  type = TCP
                                                    ----------connections-----------
           real                  weight state        current    total      failures
       ---+---------------------+------+------------+----------+----------+---------
       rserver: PRD1
           10.10.10.1:4444      8      OPERATIONAL  0          0          0
             max-conns            : -         , out-of-rotation count : -
             min-conns            : -
             conn-rate-limit      : -         , out-of-rotation count : -
             bandwidth-rate-limit : -         , out-of-rotation count : -
             retcode out-of-rotation count : -
             load value           : 0
       rserver: PRD2
           10.10.10.2:4444      8      OPERATIONAL  0          0          0
             max-conns            : -         , out-of-rotation count : -
             min-conns            : -
             conn-rate-limit      : -         , out-of-rotation count : -
             bandwidth-rate-limit : -         , out-of-rotation count : -
             retcode out-of-rotation count : -
             load value           : 0
    ACE/CTX# show service-policy POLICY-RSERVER-VIP
    Status     : ACTIVE
    Interface: vlan 1 200
      service-policy: POLICY-RSERVER-VIP
        class: NAT-VIP-TCP
          nat:
            nat dynamic 1 vlan 200
            curr conns       : 0         , hit count        : 0
            dropped conns    : 0
            client pkt count : 0         , client byte count: 0
            server pkt count : 0         , server byte count: 0
            conn-rate-limit      : 0         , drop-count : 0
            bandwidth-rate-limit : 0         , drop-count : 0
          loadbalance:
            L7 loadbalance policy: LB-NAT-VIP-TCP
            VIP ICMP Reply       : ENABLED-WHEN-ACTIVE
            VIP State: INSERVICE
            curr conns       : 0         , hit count        : 0
            dropped conns    : 0
            client pkt count : 0         , client byte count: 0
            server pkt count : 0         , server byte count: 0
            conn-rate-limit      : 0         , drop-count : 0
            bandwidth-rate-limit : 0         , drop-count : 0
          compression:
            bytes_in  : 0
            bytes_out : 0
    I see a lot of this messages in the logging of the ACE:
    show logging | i 4444
    22:02:52 : %ACE-6-302023: Teardown TCP connection 0x18b6 for vlan200:10.10.14.2/26768 to vlan200:10.10.10.2/4444 duration 0:00:00 bytes 1051 TCP FINs
    22:02:55 : %ACE-6-302022: Built TCP connection 0x14dc for vlan200:10.10.14.2/30318 (10.10.10.1/30318) to vlan200:10.10.10.1/4444 (10.10.14.2/4444)
    22:02:55 : %ACE-6-302023: Teardown TCP connection 0x14dc for vlan200:10.10.14.2/30318 to vlan200:10.10.10.1/4444 duration 0:00:00 bytes 1103 TCP FINs
    22:02:57 : %ACE-6-302022: Built TCP connection 0xc6c for vlan200:10.10.14.2/26784 (10.10.10.2/26784) to vlan200:10.10.10.2/4444 (10.10.14.2/4444)
    22:02:57 : %ACE-6-302023: Teardown TCP connection 0xc6c for vlan200:10.10.14.2/26784 to vlan200:10.10.10.2/4444 duration 0:00:00 bytes 1103 TCP FINs
    22:03:02 : %ACE-6-302022: Built TCP connection 0x151a for vlan200:10.10.14.2/26800 (10.10.10.2/26800) to vlan200:10.10.10.2/4444 (10.10.14.2/4444)
    show logging | i 4444
    22:02:52 : %ACE-6-302023: Teardown TCP connection 0x18b6 for vlan200:10.10.14.2/26768 to vlan200:10.10.10.2/4444 duration 0:00:00 bytes 1051 TCP FINs
    22:02:55 : %ACE-6-302022: Built TCP connection 0x14dc for vlan200:10.10.14.2/30318 (10.10.10.1/30318) to vlan200:10.10.10.1/4444 (10.10.14.2/4444)
    22:02:55 : %ACE-6-302023: Teardown TCP connection 0x14dc for vlan200:10.10.14.2/30318 to vlan200:10.10.10.1/4444 duration 0:00:00 bytes 1103 TCP FINs
    22:02:57 : %ACE-6-302022: Built TCP connection 0xc6c for vlan200:10.10.14.2/26784 (10.10.10.2/26784) to vlan200:10.10.10.2/4444 (10.10.14.2/4444)
    22:02:57 : %ACE-6-302023: Teardown TCP connection 0xc6c for vlan200:10.10.14.2/26784 to vlan200:10.10.10.2/4444 duration 0:00:00 bytes 1103 TCP FINs
    22:03:02 : %ACE-6-302022: Built TCP connection 0x151a for vlan200:10.10.14.2/26800 (10.10.10.2/26800) to vlan200:10.10.10.2/4444 (10.10.14.2/4444)
    The client request it's going trough an ASA, in the ASA side I see that the TCP connection it' half-open with SAaB flags. It seems that the VIP never replies with SYN+ACK to the ASA...
    Thank you.
    Best regards

    Hi Norberto,
    The log messages you are getting are most probably the probe connections and not a failure, looking to them you will see your ACE is establishing TCP connection on 4444 then it will teardown the connection with FIN which is expected since you are using TCP keepalives.
    I would recommend to go back and define the problem exactly, what are you exteriancing when you try to telnet on port 4444 toward the VIP from the client?
    Run sniffing software on the client, the server and enable capture on ACE and ASA will give you exact idea what you are experiencing.
    Note: The ASA and the ACE has great capture feature which will show you exactly the packet flows.
    Note: Since you are applying NAT on the client requests, you should see the NATed IP address on the server capture.
    Note: With L4 load balancing the ACE is not spoofing the clients' request, it just forward the SYN, SYN+ACK and ACK between the server and the client.
    Let me know if you have any other questions.
    Best regards,
    Ahmad

  • Ace ssl-proxy problem, Online store.

    Hello!
    I have a problem with moving our online store loadbalancing to a Cisco ACE solution from Windows NLB that it runs on now. And also relive the servers from the ssl encrypt and decrypting of sessions.
    The load balancing works', as long the session is Http, but when the "customer" comes to the point that i is going to pay. Our shop is jumping over to HTTPs and this is where the problem appear.
    The "customer" is getting the certificate right but the site is not displayed = the session to the shop seems to die.
    If i have missed something in the config or if someone have any other idea why this dont work for me..
    Appreciate any help!
    My config:
    (at the moment only web5 is in use)
    ACE-1/CO-WEB1# show run
    access-list ANY line 10 extended permit ip any any
    access-list icmp line 8 extended permit icmp any any
    probe http PROBE-HTTP
    interval 3
    passdetect interval 10
    passdetect count 2
    expect status 200 200
    expect status 300 323
    parameter-map type ssl SSLPARAMS
    cipher RSA_WITH_RC4_128_MD5
    rserver host vmware-server1
    description testserver1
    ip address 219.222.4.180
    probe PROBE-HTTP
    inservice
    rserver host vmware-server2
    description testserver 2
    ip address 219.222.4.181
    probe PROBE-HTTP
    inservice
    rserver host web5
    description testserver from windows nlb
    ip address 219.222.4.185
    probe PROBE-HTTP
    inservice
    ssl-proxy service SSL-PROXY-SE
    key cert-se.key
    cert cert-se.pem
    ssl advanced-options SSLPARAMS
    serverfarm host WM-ware_servers
    rserver vmware-server1
    inservice
    serverfarm host webtest
    description testserver-farm
    predictor leastconns
    rserver vmware-server1 80
    rserver vmware-server2 80
    rserver web5
    inservice
    sticky ip-netmask 255.255.255.0 address source STICKY-GROUP1
    timeout 60
    serverfarm webtest
    class-map match-all VIP-HTTP
    2 match virtual-address 219.222.4.178 tcp eq www
    class-map match-all VIP-HTTPS
    2 match virtual-address 219.222.4.178 tcp eq https
    class-map type management match-any icmp
    description for icmp reply
    2 match protocol icmp any
    policy-map type management first-match icmp
    class icmp
    permit
    policy-map type loadbalance first-match VIP-HTTP
    class class-default
    sticky-serverfarm STICKY-GROUP1
    policy-map type loadbalance first-match VIP-SSL
    class class-default
    serverfarm webtest
    policy-map multi-match SLB-VIP-HTTP
    class VIP-HTTP
    loadbalance vip inservice
    loadbalance policy VIP-HTTP
    loadbalance vip icmp-reply
    class VIP-HTTPS
    loadbalance vip inservice
    loadbalance policy VIP-SSL
    loadbalance vip icmp-reply
    ssl-proxy server SSL-PROXY-SE
    interface vlan 21
    description ### ACE OUTSIDE mot FW ###
    ip address 219.222.4.171 255.255.255.240
    access-group input ANY
    access-group output ANY
    service-policy input icmp
    service-policy input SLB-VIP-HTTP
    no shutdown
    interface vlan 22
    description ### ACE INSIDE Gateway for Web-servers ###
    ip address 219.222.4.177 255.255.255.240
    access-group input ANY
    access-group output ANY
    service-policy input icmp
    no shutdown
    ip route 0.0.0.0 0.0.0.0 219.222.4.161
    ACE-1/CO-WEB1#
    as seen in "show conn" the sessions is established, first when i enter site, and go to payment (jumping over to SSL):
    ACE-1/CO-WEB1# show conn
    total current connections : 4
    conn-id np dir proto vlan source destination state
    ----------+--+---+-----+----+---------------------+---------------------+------+
    4 1 in TCP 21 219.222.0.2:49972 219.222.4.178:443 ESTAB
    14 1 out TCP 22 219.222.4.185:443 219.222.0.2:49972 ESTAB
    11 2 in TCP 21 219.222.0.2:49923 219.222.4.178:80 ESTAB
    3 2 out TCP 22 219.222.4.185:80 219.222.0.2:49923 ESTAB
    ACE-1/CO-WEB1#

    Hello Krille
    i had the same problem.
    The HTT Probe you define will do a check if
    the return code is
    expect status 200 200
    expect status 300 323
    Now if a user is accessing the hppts site, in the flow there will be an expect status like 404, the ACE now is not establish an sticky connection, cause it think that the flow is not ok.
    The only output after ther Certificates is a blank site.
    If you change the Probing to ICMP you will be able to access the https site and the connection is sticky. With a litte tool like IE Watch you will be able to see the wrong Status codes.
    regards
    eberhard

  • 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

  • HTTP probe in ACE

    we have a simple layer3-4 port 80 app thta is being load balanced by ACE and created an HTTP probe that actually acts more like a TCP probe, since we took a default on just about all the attributes:
    probe http WEB_SERVERS
    expect status 200 200
    Unfortunately, when we activated this probe, we saw the following:
    probe : WEB_SERVERS
    type : HTTP
    state : ACTIVE
    description :
    port : 80 address : 0.0.0.0 addr type : -
    interval : 120 pass intvl : 300 pass count : 3
    fail count: 3 recv timeout: 10
    http method : GET
    http url : /
    conn termination : GRACEFUL
    expect offset : 0 , open timeout : 10
    expect regex : -
    send data : -
    --------------------- probe results --------------------
    probe association probed-address probes failed passed health
    ------------------- ---------------+----------+----------+----------+-------
    real : Planview_136.39[0]
    167.238.136.39 1 1 0 FAILED
    Socket state : CLOSED
    No. Passed states : 0 No. Failed states : 1
    No. Probes skipped : 0 Last status code : 302
    No. Out of Sockets : 0 No. Internal error: 0
    Last disconnect err : Received invalid status code
    Last probe time : Wed Jul 22 15:07:20 2009
    Last fail time : Wed Jul 22 15:07:21 2009
    Last active time : Never
    real : Planview_136.40[0]
    167.238.136.40 1 1 0 FAILED
    Socket state : CLOSED
    No. Passed states : 0 No. Failed states : 1
    No. Probes skipped : 0 Last status code : 302
    No. Out of Sockets : 0 No. Internal error: 0
    Last disconnect err : Received invalid status code
    Last probe time : Wed Jul 22 15:07:20 2009
    Last fail time : Wed Jul 22 15:07:21 2009
    Last active time : Never
    The obvious culprit here is the return code. How do we assign the correct return code here?
    Thanks...

    Hi,
    I wouldn't just let it default. It is better to probe for a particular page if that is possible. If this is a page you create, then it offers the possibility of being able to take a server out of rotation simply by renaming the page. E.g.
    probe http PROBE-iamhere
    interval 30
    passdetect interval 10
    request method head url /serverhere.html
    expect status 200 200
    Alternatively, it looks like you are getting a 302 response code (a redirect) then you could just change the line in the probe to expect that.
    probe http WEB_SERVERS
    expect status 302 302.
    HTH
    Cathy

  • Status-Tracking on ACE

    Hello
    On the CSM there was a feature called status tracking, it's description:
    Router(config-module-csm)# vserver
    dependent_virtserver_name
    Identifies the dependent virtual server and enters the virtual server configuration mode.
    Router(config-slb-vserver)#
    virtual ip-address [ip-mask]
    protocol port-number [service {ftp
    | rtsp | termination}]
    Sets the IP address for the dependent virtual server optional port number or name and the connection coupling and type2. The protocol value is tcp, udp, any (no port number is required), or a number value (no port number is required).
    Router(config-slb-vserver)#
    status-tracking
    tracked_virtserver_name
    Identifies the tracked virtual server. When this virtual server is taken out of service or fails, the dependent virtual server identified in Step 1 is automatically taken out of service.
    From http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/csm/4.2.x/configuration/guide/mapolcy.html
    I am wondering if anyone knows of a similar feature in ACE?
    The additional complexity is now the dependant vserver and tracked vserver are in different ACE contexts, does anybody know if there is way to track vservers in a different context?
    Got to admit I'm relatively new to ACE but hope this makes sense.
    Thanks for any replies in advance
    Martin

    Hi Ulrich
    Thanks for the reply. I'm not sure I was clear on my question, the PROBE would allow me to check the first service is up. What I want to do is make the internal server unavalaible if the external is not PROBING correctly or vice versa. I recognise now this is not identical to status-tracking which operates at a VIP level.
    In an example I have two FTP servers which are dual homed with internal and external interfaces in a DMZ both of which are load balanced using the ACE. If the external interface goes down I would want the internal real server to be marked out of service so as FTP traffic is no longer sent there and vice versa if the internal went down I would want to mark the external as down. The configuration in this case is there are different contexts for the internal and external - not saying that's ideal from a security perspective but you can only play with the cards your dealt!.
    Thanks
    Martin
    /* Style Definitions */
    table.MsoNormalTable
    {mso-style-name:"Table Normal";
    mso-tstyle-rowband-size:0;
    mso-tstyle-colband-size:0;
    mso-style-noshow:yes;
    mso-style-priority:99;
    mso-style-qformat:yes;
    mso-style-parent:"";
    mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
    mso-para-margin:0cm;
    mso-para-margin-bottom:.0001pt;
    mso-pagination:widow-orphan;
    font-size:11.0pt;
    font-family:"Calibri","sans-serif";
    mso-ascii-font-family:Calibri;
    mso-ascii-theme-font:minor-latin;
    mso-fareast-font-family:"Times New Roman";
    mso-fareast-theme-font:minor-fareast;
    mso-hansi-font-family:Calibri;
    mso-hansi-theme-font:minor-latin;}
    /* Style Definitions */
    table.MsoNormalTable
    {mso-style-name:"Table Normal";
    mso-tstyle-rowband-size:0;
    mso-tstyle-colband-size:0;
    mso-style-noshow:yes;
    mso-style-priority:99;
    mso-style-qformat:yes;
    mso-style-parent:"";
    mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
    mso-para-margin:0cm;
    mso-para-margin-bottom:.0001pt;
    mso-pagination:widow-orphan;
    font-size:11.0pt;
    font-family:"Calibri","sans-serif";
    mso-ascii-font-family:Calibri;
    mso-ascii-theme-font:minor-latin;
    mso-fareast-font-family:"Times New Roman";
    mso-fareast-theme-font:minor-fareast;
    mso-hansi-font-family:Calibri;
    mso-hansi-theme-font:minor-latin;}

  • 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 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 Module - HTTP Probe failure

    Hi,
    I have configured the http probe with expect status 200 202, but the probe fails despite availability of the port on rserver.
    I tried head/get method to see the return code, and it came back with HTTP1.1/302. How can I configure an http probe to understand HTTP 302 code as success return.
    Thanks.

    I changed the expect status value as below
    probe http TEST-HTTP
    interval 30
    passdetect interval 10
    request method head
    expect status 302 302
    The probe is still failing with the log message
    Apr 20 2009 12:04:35 : %ACE-3-251010: Health probe failed for server 192.168.1.10 on port 80, received invalid status code
    On 'show probe detail' it shows the last status code as 400 which means Bad Request
    --------------------- probe results --------------------
    probe association probed-address probes failed passed health
    ------------------- ---------------+----------+----------+----------+-------
    serverfarm : TEST-APP
    real : TEST-SERVER1[80]
    192.168.1.10 27 27 0 FAILED
    Socket state : CLOSED
    No. Passed states : 0 No. Failed states : 1
    No. Probes skipped : 0 Last status code : 400
    No. Out of Sockets : 0 No. Internal error: 0
    Last disconnect err : Received invalid status code
    Last probe time : Mon Apr 20 12:05:33 2009
    Last fail time : Mon Apr 20 12:00:53 2009
    Last active time : Never
    The http page is showing perfectly on the web browser. Also, using the http head/get tool, I can see that 302 is returned.
    What could be the problem.
    Regards.

  • Cisco Ace GSS Vs Bind

    I have a client that implements its data center redundancy via BIND using its DNS features. I´m trying to sell cisco Gss to that customer. What are the improvements that I could get with Cisco GSS? Just the DOS protection and interconection with ACE for health checking?

    Mario-
    The GSS itself is meant to be an intelligent DNS server.  What it provides:
    1.) Probing for the answers it sends back to clients, dynamic removal of answers if probes fail.
    2.) Failback clauses - if a primary set of answers are all unavailable, multiple other groups can be configured. This allows multiple levels of failure mitigation.
    3.) Load based answering - using Kal-AP, the GSS can probe a CSS, CSM, or ACE device to determine which site is most/least loaded and send answers for a site accordingly.
    4.) Proximity based answering.  The GSS uses DRP agents to find which GSS is local to the client D-proxy and pull answers for that specific site.
    5.) DOS attack prevention.
    6.) CNR (full DNS server - a stand alone GSS only responds to A queries or forwards requests to an NS server.)
    GSS Admin Guide
    http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/gss4400series/v3.1.1/administration/guide/gssadmg.html
    GSS Configuration Guide
    http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/gss4400series/v3.1.1/configuration/cli/gslb/guide/cli_gslb.html
    GSS - CNR Installation
    http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/gss4400series/v2.0/administration/guide/Man_CLI.html#wp1059313
    CNR configurations
    http://www.cisco.com/en/US/docs/net_mgmt/network_registrar/6.0/administration/guide/02GStart.html#wp1069420
    http://cco.cisco.com/en/US/docs/net_mgmt/network_registrar/6.0/command/reference/cliref.html

Maybe you are looking for