ACE sticky problem

Hi,
I have an issue with sticky server that I’m hope might just be a command I’m missing.
I am inserting a cookie and the sticky works fine.
When my browser has a successful sticky connection i take the server that has the sticky connection out of service. I try to make another connection, i see the connection round robin to all remaining servers but i don’t get a successful connection i do see the connection failure count increment on all other servers in the farm. Only when i bring the server back into service can i get a successful connection.
Any advice appreciated.
Sticky config below.
sticky http-cookie WEB-Cookie-1 WEB-Sticky-1
  cookie insert
  serverfarm WEB-SERVERS-80
Code
Version A3(2.0) [build 3.0(0)A3(2.0
Thanks
Chris

Hello Chris, This will be an easy fix for you.  The command you are looking for is defined under the serverfarm inwhich you are creating sticky entries against.. You need to add a failaction.. I'm pasting the command syntax and options for the command.. Based on your breif description failaction purge will give you the desired result:
(config-sfarm-host) failaction
To configure the action that the ACE takes if a real server in a server farm goes down, use the failaction command. Use the no form of this command to reset the ACE to its default of taking no action when a server fails.
failaction {purge | reassign [across-interface]}
no failaction
Syntax Description
purge
Specifies that the ACE remove the connections to a real server if that  real server in the server farm fails after you configure this command.  The appliance sends a reset (RST) both to the client and to the server  that failed.
reassign
Specifies that the ACE reassigns existing server connections to the  backup real server, if a backup real server is configured. If no backup  real server is configured, this keyword has no effect.
across-interface
(Optional) Instructs the ACE to reassign all connections from the failed  real server to a backup real server on a different VLAN that is  commonly referred to as a bypass VLAN. By default, this feature is  disabled.

Similar Messages

  • ACE Sticky Connections, Show Conn Output and Show serverfarm

    Hi Community,
    I'm deploying a Cisco ACE module and I have some questions about sticky connections and about the output of the show conn command and show serverfarm command.
    I have the follwoing configuration:
    rserver host srv_1  ip address 10.4.11.14  inservicerserver host srv_2  ip address 10.4.11.18  inserviceserverfarm host farm_144  rserver srv_1 144    weight 1    inservice  rserver srv_2 144    weight 3    inservice
    sticky ip-netmask 255.255.255.255 address source st_host144
      timeout 10080
      serverfarm farm_144
    class-map match-all vip_144
      2 match virtual-address 10.4.11.208 tcp eq 143
    policy-map type loadbalance first-match lb_144
      class class-default
    policy-map multi-match policy_vip_webcache
      class vip_webcache_144
        loadbalance vip inservice
        loadbalance policy lb_144
        loadbalance vip icmp-reply active
        nat dynamic 411 vlan 411
    We can assume that service policy was applied at the interface vlan. So, let's go to the questions:
    1- If sticky is enabled the output command "show conn" should show just one entry by ip address?
    The real output is:
    DC01-ACE-01-PRIMARY-SW1/context_servidores# show conn | inc :143333046     1  in  TCP   411  10.2.158.87:3616      10.4.11.208:143       ESTAB 286390     3  in  TCP   411  10.2.158.87:3562      10.4.11.208:143       ESTAB310233     1  in  TCP   411  10.1.5.87:3424        10.4.11.208:143       ESTAB
    Look that the ip address 10.2.158.87 is shown 2 times. In same times, the same ip address is shown 4 times to the same VIP and the same port. Is it a normal behavior?
    2- According to the configuration, the srv_2 has weight 3 and srv_1 has weigth 1, but the output of show serverfarm show somethin strange:
    DC01-ACE-01-PRIMARY-SW1/context_servidores# show serverfarm farm_144 serverfarm     : farm_144, type: HOST total rservers : 2 state          : ACTIVE DWS state      : DISABLED ---------------------------------                                                ----------connections-----------       real                  weight state        current    total      failures    ---+---------------------+------+------------+----------+----------+---------   rserver: srv_1       10.4.11.14:144        1   OPERATIONAL     11         386        0   rserver: srv_2       10.4.11.18:144        3   OPERATIONAL     35         66         0
    We can see that the weight is working good, but the total of connections is higher at srv_1 than srv_2. Why?
    Somebody can help me to understand better this problem of if its a normal behavior?
    Thanks in advance!!

    Hi Gaurav,
    About question 1, I got some informations too. It's perfectly normal the client open 2 or more connections at the same time. The client's application is the responsable. We removed the ACE and put the client directly to the server and the result of the total connections opened was the same.
    About question 2, I made some "clears" on the serverfarm, the sticky database and after that, the numbers were more real.
    DC01-ACE-02-SECONDARY-SW1/context_servidores# sh serverfarm farm_webcache_144
    serverfarm     : farm_webcache_144, type: HOST
    total rservers : 2
    state          : ACTIVE
    DWS state      : DISABLED
                                                    ----------connections-----------
           real                  weight state        current    total      failures
       ---+---------------------+------+------------+----------+----------+---------
       rserver: srv_webcache_1
           10.4.11.14:144        1   OPERATIONAL     1025       15499      4436
       rserver: srv_webcache_2
           10.4.11.18:144        2   OPERATIONAL     1794       33471      471
    DC01-ACE-02-SECONDARY-SW1/context_servidores#
    Anyway thank you very much for your feedback.
    Plínio Monteiro

  • ACE Sticky issue.

    Hi,
    The Sticky function of the ACE is not working. There were no changes been made on the device it was working fine before but not now,.
    We have 2 ACE one is Active(ACE1) and Second one is Standby (ACE2).
    Testing done till now:-
    ================
    Done the Failover from Active(ACE1) to Standby (ACE2).
    When ACE2 was Active the Sticky started working fine without any issues.
    2)  when I did the failover again back from ACE2 to ACE1 the problem arrise Sticky doesnt work any more.
    Any suggestion about this strange behaviour?
    Thanks in advance.
    Regards
    Alex.

    What version do you run ?
    What type of sticky method ?
    Could you get a
    - show np 1 me-stats "-slb"
    and a
    - show np 2 me-stats "-slb"
    Possibly get 2 occurences one before and one after a test.
    Thanks,
    Gilles.

  • ACE : Stickyness problem with http cookies

    Hi,
    I am facing a serious problem with stickyness in a e-commerce configuration.
    Here is the setup :
    An ACE load balance user requests on two Apache servers
    cookie-insert is used to stick a user on one Apache server
    The home page is accessed via http on port 80
    On the Home page, there is a link to allowing the user to login
    The login process uses SSL
    During the login, backend SSL is required between the ACE and the selected Apache server
    The login is a POST request to the Apache server
    After a successful login, the home page is reloaded on port 80 and the name of the user should appear on the top of the page
    The ACE configuration :
    Two sticky groups are configured : one for HTTP acess and another for HTTPS access
    Two server farms are defined, both using the same real servers, but with different ports (80 and 441)
         sticky http-cookie STICKED-TO ECOM_STICKY_TEST_HTTP
           cookie insert browser-expire
           timeout 240
           replicate sticky
           serverfarm ECOM_FARM_TEST_HTTP
              sticky http-cookie STICKED-TO ECOM_STICKY_TEST_HTTPS
           cookie insert browser-expire
           timeout 240
           replicate sticky
           serverfarm ECOM_FARM_TEST_HTTPS
         serverfarm host ECOM_FARM_TEST_HTTP
           description *** e-Commerce Test Server Farm ***
           probe ECOM_PROBE_TEST
           rserver HQCHECOM01 80
            inservice
           rserver HQCHECOM02 80
            inservice
             serverfarm host ECOM_FARM_TEST_HTTPS
          description *** e-Commerce Test Server Farm ***
          probe ECOM_PROBE_TEST
          rserver HQCHECOM01 443
           inservice
          rserver HQCHECOM02 443
           inservice
    The problem :
    Let analyse the sequence of events and the value of the http cookie for each of them :
    When the the home page is originally loaded, the ACE selects SERVER-1
    The ACE inserts the cookie "A" in the server responses
    The user is sticked to SERVER-1
    Then, the user tries to login and an SSL session is established with the ACE
    The user sends a POST request containing the cookie "A"
    A backend SSL session is established with SERVER-1
    The POST request is forwarded to SERVER-1
    SERVER-1 responds with a 200 OK and the ACE generates another cookie "B" as it belongs to the sticky group ECOM_STICKY_TEST_HTTPS
    The client browser reloads the page on port 80 and provides the cookie "B" (the last received) !!
    The ACE sees the cookie "B" but does not find it in its database for the sticky group ECOM_STICKY_TEST_HTTP
    The ACE perform another load balancing decision and selects SERVER-2 ! (instead of SERVER-1)
    The page is reloaded, but the name of the user does not appear on it
    The question :
    As it is not possible to have only one sticky group in this configuration what would be the solution to make sure that the same server is selected for http and https ?
    Thank you for any hints,
    Yves

    Hi Gilles,
    I followed your recommendation to configure static cookie entries in each sticky group, but I still experience the problem of sessions getting re-load balanced to the second server when returning from HTTPS to HTTP :
    It seems that the ACE ignores the static entries !
    To make my question clear, I repeat hereafter the setup and the encountered problem :
    Here is the setup :
    An ACE load balance user requests on two Apache servers
    cookie-insert is used to stick a user on one Apache server
    The home page is accessed via http on port 80
    On the Home page, there is a link to allowing the user to login
    The login process uses SSL
    During the login, backend SSL is required between the ACE and the selected Apache server
    The login is a POST request to the Apache server
    After a successful login, the home page is reloaded on port 80 and the name of the user should appear on the top of the page
    The ACE configuration :
    Two sticky groups are configured : one for HTTP acess and another for HTTPS access
    Two server farms are defined, both using the same real servers, but with different ports (80 and 443)
    In the ECOM_STICKY_TEST_HTTP stick group the two following cookies are automatically generated :
    R105816849   for the server HQCHECOM01
    R105852786   for the server HQCHECOM02
    In the ECOM_STICKY_TEST_HTTPS stick group the two following cookies are automatically generated :
    R355972695   for the server HQCHECOM01
    R357158616   for the server HQCHECOM02
    I statically configured in the each sticky group the cookies used by the other sticky group, to allow stickiness when the browser switches from HTTP to HTTPS and vice versa :
    sticky http-cookie STICKED-TO ECOM_STICKY_TEST_HTTP
      cookie insert browser-expire
      timeout 240
      replicate sticky
      serverfarm ECOM_FARM_TEST_HTTP backup WEB_REDIRECT_001
      56 static cookie-value "R355972695" rserver HQCHECOM01
      64 static cookie-value "R357158616" rserver HQCHECOM02
    sticky http-cookie STICKED-TO ECOM_STICKY_TEST_HTTPS
      cookie insert browser-expire
      timeout 240
      replicate sticky
      serverfarm ECOM_FARM_TEST_HTTPS backup WEB_REDIRECT_001
      72 static cookie-value "R105816849" rserver HQCHECOM01
      80 static cookie-value "R105852786" rserver HQCHECOM02
    serverfarm host ECOM_FARM_TEST_HTTP
      description *** e-Commerce Test Server Farm ***
      probe ECOM_PROBE_TEST
      rserver HQCHECOM01 80
       inservice
      rserver HQCHECOM02 80
       inservice
    serverfarm host ECOM_FARM_TEST_HTTPS
      description *** e-Commerce Test Server Farm ***
      probe ECOM_PROBE_TEST
      rserver HQCHECOM01 443
       inservice
      rserver HQCHECOM02 443
       inservice
    The problem :
    Let analyse the sequence of events and the value of the http cookie for each of them :
    When the the home page is originally loaded, the ACE selects SERVER-1
    The ACE inserts the cookie "A" in the server responses
    The user is sticked to SERVER-1
    Then, the user tries to login and an SSL session is established with the ACE
    The user sends a POST request containing the cookie "A"
    A backend SSL session is established with SERVER-1
    The POST request is forwarded to SERVER-1
    SERVER-1 responds with a 200 OK and the ACE generates another cookie "B" as it belongs to the sticky group ECOM_STICKY_TEST_HTTPS
    The client browser reloads the page on port 80 and provides the cookie "B" (the last received)
    The ACE sees the cookie "B" and should use the static cookie entry to select the SERVER-1
    But instead, the ACE perform another load balancing decision and selects SERVER-2 !
    The page is reloaded, but the name of the user does not appear on it
    LiveHTTP Trace on Firefox :
    GET /ecom/medias/sys_master/8800775602206/Home-page-main-banners-video.jpg HTTP/1.1
    Host: ecom.test.toto.com
    User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100202 (CK-IBM) Firefox/3.5.8
    Accept: image/png,image/*;q=0.8,*/*;q=0.5
    Accept-Language: en-us,en;q=0.5
    Accept-Encoding: gzip,deflate
    Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Keep-Alive: 300
    Connection: keep-alive
    Referer: http://ecom.test.toto.com/uk/en/home
    Cookie: STICKED-TO=R105816849;
    HTTP/1.1 200 OK
    Set-Cookie: STICKED-TO=R105816849; path=/
    Date: Mon, 18 Oct 2010 15:31:37 GMT
    Server: Apache/2.2.13 (Red Hat)
    Connection: close
    Transfer-Encoding: chunked
    Content-Type: image/jpeg
    Here we switch on HTTPS :
    https://ecom.test.toto.com/uk/en/j_spring_security_check
    POST /uk/en/j_spring_security_check HTTP/1.1
    Host: ecom.test.toto.com
    User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100202 (CK-IBM) Firefox/3.5.8
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language: en-us,en;q=0.5
    Accept-Encoding: gzip,deflate
    Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Keep-Alive: 300
    Connection: keep-alive
    Referer: http://ecom.test.toto.com/uk/en/home
    Cookie: STICKED-TO=R105816849; JSESSIONID=089DCF987DC03CAE0F516298EB886DAB.node1;
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 75
    spring-security-redirect=&j_username=yves144%40yahoo.com&j_password=junon01
    Here we see cookie for the same server but for the HTTPS sticky group :
    HTTP/1.1 302 Moved Temporarily
    Set-Cookie: STICKED-TO=R355972695; path=/
    Set-Cookie: _hybris.tenantID_=""; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/; HttpOnly
    Date: Mon, 18 Oct 2010 15:31:39 GMT
    Server: Apache/2.2.13 (Red Hat)
    Location: http://ecom.test.toto.com/uk/en/home
    Content-Length: 0
    Connection: close
    Content-Type: text/plain; charset=UTF-8
    Here we switch back to HTTP :
    http://ecom.test.toto.com/uk/en/home
    GET /uk/en/home HTTP/1.1
    Host: ecom.test.toto.com
    User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100202 (CK-IBM) Firefox/3.5.8
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language: en-us,en;q=0.5
    Accept-Encoding: gzip,deflate
    Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Keep-Alive: 300
    Connection: keep-alive
    Referer: http://ecom.test.toto.com/uk/en/home
    Cookie: STICKED-TO=R355972695; JSESSIONID=089DCF987DC03CAE0F516298EB886DAB.node1;
    Here we see that the second server has been wrongly selected !
    HTTP/1.1 200 OK
    Set-Cookie: STICKED-TO=R105852786; path=/
    Set-Cookie: _hybris.tenantID_=""; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/; HttpOnly
    Set-Cookie: JSESSIONID=5A0F6EB8FBF63D5D0590FECEC62A302E.node2; Path=/; HttpOnly
    Date: Mon, 18 Oct 2010 15:31:40 GMT
    Server: Apache/2.2.13 (Red Hat)
    Pragma: no-cache
    Expires: Thu, 01 Jan 1970 00:00:00 GMT
    Cache-Control: no-cache, no-store
    Content-Language: en-GB
    Connection: close
    Transfer-Encoding: chunked
    Content-Type: text/html;charset=UTF-8
    http://ecom.test.toto.com/ecom/medias/sys_master/8796174057502/uk.gif
    GET /ecom/medias/sys_master/8796174057502/uk.gif HTTP/1.1
    Host: ecom.test.toto.com
    User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100202 (CK-IBM) Firefox/3.5.8
    Accept: image/png,image/*;q=0.8,*/*;q=0.5
    Accept-Language: en-us,en;q=0.5
    Accept-Encoding: gzip,deflate
    Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Keep-Alive: 300
    Connection: keep-alive
    Referer: http://ecom.test.toto.com/uk/en/home
    Cookie: STICKED-TO=R105852786; JSESSIONID=5A0F6EB8FBF63D5D0590FECEC62A302E.node2;
    HTTP/1.1 200 OK
    Set-Cookie: STICKED-TO=R105852786; path=/
    Date: Mon, 18 Oct 2010 15:31:40 GMT
    Server: Apache/2.2.13 (Red Hat)
    Content-Length: 382
    Connection: close
    Content-Type: image/gif
    Hypothesis :
    It seems that the static entries are not considered by the ACE...

  • ACE sticky cookie value

    Hello,
    I have a following configuration:
    sticky http-cookie STICKY_TMP STICKY_TMP
    cookie insert ...
    Cookies are sent and stickiness works. Everything is ok... Almost :-)
    Now I have a question regarding value of cookies created by ACE.
    Currently cookies have values that look like this "R4224709512"
    Is it possible to change this value so it reflects the target node that processes requests for this sticky session. This cookie could contain i.e. ip address of real server.
    Arrowpoint cookie on CSS1150 worked this way...
    Another question. How do I identify this cookie value with sticky-entries in "show sticky database static" output?
    This command doesn't show anything like R4224709512, but only numbers like 18293255029648678255
    best regards
    Kuba

    I am using ACE with version A3(2.1).
    The “sticky-entry” in "show sticky data static"is a hash of the cookie-value set by ACE for the real server. so you need to use "show sticky database http-cookie " to determine which server are serving the client.
    ACE-1/routed(config-pmap-lb-c)# do show sticky database http-cookie
    sticky group : web-sticky
    type : HTTP-COOKIE
    timeout : 5 timeout-activeconns : FALSE
    sticky-entry rserver-instance time-to-expire flags
    ---------------------+----------------------+--------------+-------+
    16820511103801384579 lnx1:0 0 -
    sticky group : web-sticky
    type : HTTP-COOKIE
    timeout : 5 timeout-activeconns : FALSE
    sticky-entry rserver-instance time-to-expire flags
    ---------------------+----------------------+--------------+-------+
    3347854103021350619 lnx2:0 0 -
    ..sometimes they'd only show up w/ the static instead of the cookies option for some reason.
    found some explanation about this:
    http://docwiki.cisco.com/wiki/Session_Persistence_Using_Cookie_Learning_on_the_Cisco_Application_Control_Engine_Configuration_Example
    There is a difference between inserting an ACE-generated cookie or using one learned by the ACE. The cookie-insert feature creates a static cookie.
    To look at static cookies you need to use the command:
    show sticky database static
    if you try static cookie (cookie inserted by ACE), the value is placed in the static sticky table at the time of configuration...
    so no need to send traffic, once the static sticky config is in place, you should see an entry with 'show sticky database static'.
    Do not try to filter the table with some other parameters...they do not work until A2(1.4)
    There are 2 database:
    One for static entries and one for dynamic entries.
    Every show command that does not include the static keyword will look into the dynamic database.
    So, you won't see anything by using those commands.
    You could perform some test to identify which cookie is sent to which server.
    The cookie value is static, so the number of value is limited to the number of servers.
    There is a dynamic cookie learning feature available in ACE.
    Kinly tell me if you want to discuus about that.
    Kindly rate if possible.
    Kind regards,
    Sachin garg

  • Sticky problem

    Hi, we have an issue where the sticky tables on our CSS are too large, so that if a server fails, connections move to the rest of the farm. As the sticky table does not time out anytime soon the failed server does not get many connections when it is back online.
    Sticky-inact-timer command does not work as this only makes the entries eligible for removal.
    The content rule is a L4 on port 443, I tried to configure this as an L5 rule with arrowpoint cookies but I suspect this does not work as we are using SSL connection that is not terminated on the CSS.
    The servers themselves send a cookie ? Can I make use of this or as the connection is port 443 am I stuck ?
    Any other solutions would be much appreciated.
    cheers,
    Mike

    Mike,
    let me first say, that if you configure a sticky-inact-timeout, once the entry times out it is removed IMMEDIATELY. There is no concept of elligibility. [this for flows and garbage collection - nothing to do with stickyness].
    Here is an example
    CSS11503-2(debug)# show sticky-table l3-sticky
    L3 Sticky List on Slot 1, subslot 1:
    Entries for page 1.
    Entry Hash Rule Rule Srv Srv Time(Sec) Hit Col Elem Inact
    Number Value Indx State Indx State Elapsed Cnt Cnt Type Cfg(Min)
    1 c0a81429 5 ACT 9 EGRES 59 2 0 L3 1
    Total number of entries found is 1.
    L3 Sticky List on Slot 3, subslot 1:
    Entries for page 1.
    Entry Hash Rule Rule Srv Srv Time(Sec) Hit Col Elem Inact
    Number Value Indx State Indx State Elapsed Cnt Cnt Type Cfg(Min)
    Total number of entries found is 0.
    CSS11503-2(debug)# show sticky-table l3-sticky
    L3 Sticky List on Slot 1, subslot 1:
    Entries for page 1.
    Entry Hash Rule Rule Srv Srv Time(Sec) Hit Col Elem Inact
    Number Value Indx State Indx State Elapsed Cnt Cnt Type Cfg(Min)
    Total number of entries found is 0.
    L3 Sticky List on Slot 3, subslot 1:
    Entries for page 1.
    Entry Hash Rule Rule Srv Srv Time(Sec) Hit Col Elem Inact
    Number Value Indx State Indx State Elapsed Cnt Cnt Type Cfg(Min)
    Total number of entries found is 0.
    CSS11503-2(debug)# show sticky-table l3-sticky
    L3 Sticky List on Slot 1, subslot 1:
    Entries for page 1.
    Entry Hash Rule Rule Srv Srv Time(Sec) Hit Col Elem Inact
    Number Value Indx State Indx State Elapsed Cnt Cnt Type Cfg(Min)
    1 c0a81429 5 ACT 14 EGRES 3 1 0 L3 1
    As you can see, with a 1 min timeout, after 60 sec the entry is removed, and the next time the client comes in it is sent to a different server which creates a new entry.
    So, your problem is that you either do not have the sticky-inact-timeout, in which case you need to manually clear the sticky table when a server goes down/up, or you have the timeout configured but with a value too high so the sticky entry is never removed because always refreshed by a new connection.
    You can use 'advanced-balance ssl' without the ssl module but it only works with 1 type of ssl protocol - SSLv2 [I think] and for the other protocols it just reverts back to sticky-srcip.
    So, you should stick with sticky-srcip and just make it works correctly by setting correct parameter or by clearing the sticky table manually.
    Finally, I'd like to say that there is a known-issue with sticky-srcip in general.
    This is the use of mega-proxy on the Internet.
    A lot of people sitting behind a proxy and therefore appearing with a single ip address on the internet.
    This is known to cause un-even loadbalancing.
    That might be your problem and changing the inact-timeout would have no effect.
    This is one of the reason for a lot of people to buy the ssl module so they can use cookies.
    Gilles.

  • ACE balancing problems

    Hi everyone.
    We have a customer who has a server farm formed by 3 servers with the following real ip address:
    10.10.24.5-6-7  and a virtual 10.10.24.3 as configured in the ace module.
    We found the following behavior in the session number of the servers. We can conclude that there is a server with much more sessions than the others (10.10.24.6):
    Can sombody help me telling why can happen that?
    I am attaching the ACE config as a reference
    Thanks
    ACE-DIGENERAL/OCS# sh serverfarm Herramientas_Col
    serverfarm     : Herramientas_Col, type: HOST
    total rservers : 3
                                                    ----------connections-----------
           real                  weight state        current    total              
       ---+---------------------+------+------------+----------+--------------------
       rserver: SP1
           10.10.24.5:0          8      OPERATIONAL  390         296043280         
       rserver: SP2
           10.10.24.6:0          8      OPERATIONAL  1003        3371471400         
       rserver: SP3
           10.10.24.7:0          8      OPERATIONAL  354         164816790          
    Como se puede observar el sever 10.10.24.6 posee mas del doble de conexiones que los otros 2.
    5.       En el siguiente pantallazo también se observan conexiones detalladas y los puertos por donde habla:
    ACE-DIGENERAL/OCS# sh conn serverfarm Herramientas_Col
    conn-id    np dir proto vlan source                destination           state
    ----------+--+---+-----+----+---------------------+---------------------+------+
    70         1  in  TCP   951  10.10.22.13:3837      10.10.24.3:80         ESTAB
    17239      1  out TCP   324  10.10.24.7:80         10.10.22.13:3837      ESTAB
    76         1  in  TCP   951  10.83.21.32:1419      10.10.24.3:80         ESTAB
    5531       1  out TCP   324  10.10.24.6:80         10.83.21.32:1419      ESTAB
    95         1  in  TCP   951  10.20.7.51:1702       10.10.24.3:80         ESTAB
    16237      1  out TCP   324  10.10.24.6:80         10.20.7.51:1702       ESTAB
    98         1  in  TCP   951  10.80.31.55:3188      10.10.24.3:80         ESTAB
    11995      1  out TCP   324  10.10.24.6:80         10.80.31.55:3188      ESTAB
    32749      1  in  TCP   951  10.80.21.23:1926      10.10.24.3:80         ESTAB
    108        1  out TCP   324  10.10.24.7:80         10.80.21.23:1926      ESTAB
    110        1  in  TCP   951  10.25.14.231:1705     10.10.24.3:80         ESTAB
    37994      1  out TCP   324  10.10.24.6:80         10.25.14.231:1705     ESTAB
    7438       1  in  TCP   951  10.31.102.32:2329     10.10.24.3:80         ESTAB
    141        1  out TCP   324  10.10.24.7:80         10.31.102.32:2329     ESTAB
    31247      1  in  TCP   951  10.81.36.32:1650      10.10.24.3:80         ESTAB
    151        1  out TCP   324  10.10.24.5:80         10.81.36.32:1650      ESTAB
    176        1  in  TCP   951  10.20.208.124:2598    10.10.24.3:80         ESTAB
    13219      1  out TCP   324  10.10.24.7:80         10.20.208.124:2598    ESTAB
    32576      1  in  TCP   951  10.233.9.40:1577      10.10.24.3:80         ESTAB
    233        1  out TCP   324  10.10.24.6:80         10.233.9.40:1577      ESTAB
    27499      1  in  TCP   951  10.218.16.28:2902     10.10.24.3:80         ESTAB
    244        1  out TCP   324  10.10.24.5:80         10.218.16.28:2902     ESTAB
    248        1  in  TCP   951  10.85.19.55:1540      10.10.24.3:80         ESTAB
    14014      1  out TCP   324  10.10.24.7:80         10.85.19.55:1540      ESTAB
    27166      1  in  TCP   951  10.25.22.90:1766      10.10.24.3:80         ESTAB
    254        1  out TCP   324  10.10.24.6:80         10.25.22.90:1766      ESTAB
    380        1  in  TCP   951  10.23.22.62:1855      10.10.24.3:80         ESTAB
    11563      1  out TCP   324  10.10.24.6:80         10.23.22.62:1855      ESTAB
    397        1  in  TCP   951  10.212.35.30:1540     10.10.24.3:80         ESTAB
    15491      1  out TCP   324  10.10.24.7:80         10.212.35.30:1540     ESTAB
    35588      1  in  TCP   951  10.100.30.5:1773      10.10.24.3:80         ESTAB
    405        1  out TCP   324  10.10.24.6:80         10.100.30.5:1773      ESTAB
    31392      1  in  TCP   951  10.216.27.41:1524     10.10.24.3:80         ESTAB
    449        1  out TCP   324  10.10.24.6:80         10.216.27.41:1524     ESTAB
    592        1  in  TCP   951  10.25.21.219:1364     10.10.24.3:80         ESTAB
    2988       1  out TCP   324  10.10.24.5:80         10.25.21.219:1364     ESTAB
    614        1  in  TCP   951  10.25.42.221:1517     10.10.24.3:80         ESTAB
    18877      1  out TCP   324  10.10.24.6:80         10.25.42.221:1517     ESTAB
    21553      1  in  TCP   951  10.80.39.123:1634     10.10.24.3:80         ESTAB
    652        1  out TCP   324  10.10.24.6:80         10.80.39.123:1634     ESTAB
    13640      1  in  TCP   951  10.206.2.34:1385      10.10.24.3:80         ESTAB
    708        1  out TCP   324  10.10.24.6:80         10.206.2.34:1385      ESTAB
    26959      1  in  TCP   951  10.100.30.7:1289      10.10.24.3:80         ESTAB
    719        1  out TCP   324  10.10.24.5:80         10.100.30.7:1289      ESTAB
    29277      1  in  TCP   951  10.100.202.50:1248    10.10.24.3:80         ESTAB
    758        1  out TCP   324  10.10.24.5:80         10.100.202.50:1248    ESTAB
    6185       1  in  TCP   951  10.25.27.222:1497     10.10.24.3:80         ESTAB
    760        1  out TCP   324  10.10.24.6:80         10.25.27.222:1497     ESTAB
    767        1  in  TCP   951  10.97.21.28:1821      10.10.24.3:80         ESTAB
    23511      1  out TCP   324  10.10.24.7:80         10.97.21.28:1821      ESTAB
    826        1  in  TCP   951  10.31.105.140:3810    10.10.24.3:80         ESTAB
    13460      1  out TCP   324  10.10.24.6:80         10.31.105.140:3810    ESTAB
    21987      1  in  TCP   951  10.25.31.213:1855     10.10.24.3:80         ESTAB
    839        1  out TCP   324  10.10.24.5:80         10.25.31.213:1855     ESTAB
    874        1  in  TCP   951  10.88.29.27:1503      10.10.24.3:80         ESTAB
    29839      1  out TCP   324  10.10.24.6:80         10.88.29.27:1503      ESTAB
    945        1  in  TCP   951  10.27.122.13:1286     10.10.24.3:80         ESTAB
    32298      1  out TCP   324  10.10.24.6:80         10.27.122.13:1286     ESTAB
    24330      1  in  TCP   951  10.40.21.50:2368      10.10.24.3:80         ESTAB
    954        1  out TCP   324  10.10.24.6:80         10.40.21.50:2368      ESTAB
    961        1  in  TCP   951  10.80.26.76:1414      10.10.24.3:80         ESTAB
    11176      1  out TCP   324  10.10.24.5:80         10.80.26.76:1414      ESTAB
    28989      1  in  TCP   951  10.91.22.38:1408      10.10.24.3:80         ESTAB
    985        1  out TCP   324  10.10.24.5:80         10.91.22.38:1408      ESTAB
    1006       1  in  TCP   951  10.217.4.20:1522      10.10.24.3:80         ESTAB
    26946      1  out TCP   324  10.10.24.5:80         10.217.4.20:1522      ESTAB
    8360       1  in  TCP   951  10.11.3.28:1679       10.10.24.3:80         ESTAB
    1020       1  out TCP   324  10.10.24.6:80         10.11.3.28:1679       ESTAB
    9498       1  in  TCP   951  10.25.42.221:1519     10.10.24.3:80         ESTAB
    1031       1  out TCP   324  10.10.24.6:80         10.25.42.221:1519     ESTAB
    18510      1  in  TCP   951  10.165.55.51:1232     10.10.24.3:80         ESTAB
    1072       1  out TCP   324  10.10.24.7:80         10.165.55.51:1232     ESTAB
    5583       1  in  TCP   951  10.25.14.12:2086      10.10.24.3:80         ESTAB
    1142       1  out TCP   324  10.10.24.6:80         10.25.14.12:2086      ESTAB
    39713      1  in  TCP   951  10.25.36.58:1663      10.10.24.3:80         ESTAB
    1144       1  out TCP   324  10.10.24.7:80         10.25.36.58:1663      ESTAB
    8601       1  in  TCP   951  10.217.26.34:1677     10.10.24.3:80         ESTAB
    1167       1  out TCP   324  10.10.24.6:80         10.217.26.34:1677     ESTAB
    17209      1  in  TCP   951  10.165.40.45:1526     10.10.24.3:80         ESTAB
    1173       1  out TCP   324  10.10.24.5:80         10.165.40.45:1526     ESTAB
    18708      1  in  TCP   951  10.31.105.137:3714    10.10.24.3:80         ESTAB
    1175       1  out TCP   324  10.10.24.6:80         10.31.105.137:3714    ESTAB
    1180       1  in  TCP   951  10.201.18.40:4777     10.10.24.3:80         ESTAB
    6528       1  out TCP   324  10.10.24.6:80         10.201.18.40:4777     ESTAB
    1214       1  in  TCP   951  10.31.104.46:1501     10.10.24.3:80         ESTAB
    5924       1  out TCP   324  10.10.24.6:80         10.31.104.46:1501     ESTAB
    1228       1  in  TCP   951  10.231.37.32:1161     10.10.24.3:80         ESTAB
    15171      1  out TCP   324  10.10.24.6:80         10.231.37.32:1161     ESTAB
    28431      1  in  TCP   951  10.25.5.76:2317       10.10.24.3:80         ESTAB
    1293       1  out TCP   324  10.10.24.5:80         10.25.5.76:2317       ESTAB
    1328       1  in  TCP   951  10.201.2.26:1293      10.10.24.3:80         ESTAB
    19276      1  out TCP   324  10.10.24.7:80         10.201.2.26:1293      ESTAB
    1356       1  in  TCP   951  10.80.23.27:1396      10.10.24.3:80         ESTAB
    4141       1  out TCP   324  10.10.24.6:80         10.80.23.27:1396      ESTAB
    1368       1  in  TCP   951  10.80.36.124:1428     10.10.24.3:80         ESTAB
    19905      1  out TCP   324  10.10.24.6:80         10.80.36.124:1428     ESTAB
    30280      1  in  TCP   951  10.25.8.11:4836       10.10.24.3:80         ESTAB
    1438       1  out TCP   324  10.10.24.6:80         10.25.8.11:4836       ESTAB
    1478       1  in  TCP   951  10.216.6.46:4153      10.10.24.3:80         ESTAB
    12312      1  out TCP   324  10.10.24.6:80         10.216.6.46:4153      ESTAB
    23389      1  in  TCP   951  10.211.30.38:1593     10.10.24.3:80         ESTAB
    1527       1  out TCP   324  10.10.24.6:80         10.211.30.38:1593     ESTAB
    1562       1  in  TCP   951  10.90.21.58:2889      10.10.24.3:80         ESTAB
    36398      1  out TCP   324  10.10.24.7:80         10.90.21.58:2889      ESTAB
    1587       1  in  TCP   951  10.84.22.29:2121      10.10.24.3:80         ESTAB
    37031      1  out TCP   324  10.10.24.6:80         10.84.22.29:2121      ESTAB
    1624       1  in  TCP   951  10.25.21.218:1465     10.10.24.3:80         ESTAB
    4941       1  out TCP   324  10.10.24.6:80         10.25.21.218:1465     ESTAB

    Hello!
    A "show connection serverfarm Herramientas_Col detail"  and "show sticky database group POOL3" would be handy in this situation.  You have sticky configured which will intentionally throw off the loadbalancing predictor.  My guess at this point is that rserver SP2 might not close connections in the same manner that SP1 and SP3 do.  If that was true, that would result in a longer connection time, which means the sticky database would not idle out as fast, hence more connection for SP2.
    Regards,
    Chris

  • ACE Stickiness Question

    Hi Folks,
    First of all I am new the job and have very little ACE expierence. I work on a large campus. We have to 6513's with an ACE blade in each. A few contexts configured for different applications. Basically the server guys have come to me and asked me to enabled stickiness on one of there contexts.
    Now I am sure this is basic stuff to ye guys but I am just wondering what I need to do? Can I implement this on the fly without causing an outage? I have cut and paste  the relevant context below. And added the changes I think that need to be made. Do you guys think this will work and will it cause any outage?
    I appreciate any help at all guys:
    Here is current config:
    probe tcp APPS-PROBE
    port 8080
    interval 3
    passdetect interval 5
    parameter-map type ssl SSL-APPS-ADVANCED
    cipher RSA_WITH_RC4_128_MD5
    rserver host SERVER1
    ip address 10.10.10.1
    inservice
    rserver host SERVER2
    ip address 10.10.10.2
    inservice
    ssl-proxy service SSL-APPS-PROXY
    key appfiles.pem
    cert appfilesCAcert
    chaingroup APPFILES-CHAINGRP
    ssl advanced-options SSL-APPS-ADVANCED
    serverfarm host APPS-FARM
    predictor leastconns
    probe APPS-PROBE
    rserver SERVER1 8080
    inservice
    rserver SERVER2 8080
    inservice
    class-map match-any APPS-VIP
    2 match virtual-address 10.10.10.4 tcp eq https
    policy-map type management first-match MGT-POLICY
    class class-default
    policy-map type loadbalance first-match APPS-POLICY
    class class-default
    serverfarm APPS-FARM
    policy-map multi-match APPSPOLICY
    class APPS-VIP
    loadbalance vip inservice
    loadbalance policy APPS-POLICY
    loadbalance vip icmp-reply active
    ssl-proxy server SSL-APPS-PROXY
    service-policy input APPSPOLICY
    Will adding the following to the context make stickiness work?
    sticky ip-netmask 255.255.255.255 address source STICKY-APPS-FARM
    timeout 720
    timeout activeconns
    replicate sticky
    serverfarm APPS-FARM
    policy-may type loadbalance first-match APPS-POLICY
    class class-default
    sticky-serverfarm STICKY-APPS-FARM
    I am really lost on this and only getting this from looking at stickiness on other configs. Can you guys advise will this work.

    Also look at the following :
    www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/v3.00_A2/configuration/rtg_brdg/guide/vlansif.html
    Autogenerating a MAC Address for a VLAN Interface
    By default, the ACE does not allow traffic from one context to another  context over a transparent firewall. The ACE assumes that VLANs in  different contexts are in different Layer 2 domains, unless it is a  shared VLAN. The ACE allocates the same MAC address to the VLANs.
    When you are using a firewall service module (FWSM) to bridge traffic  between two contexts on the ACE, you must assign two Layer 3 VLANs to  the same bridge domain. To support this configuration, these VLAN  interfaces require different MAC addresses.
    To enable the autogeneration of a MAC address on a VLAN interface, use the mac address autogenerate command in interface configuration mode. The syntax of this command is as follows:
    mac address autogenerate
    For example, enter:
    host1/Admin(config-if)# mac address autogenerate
    To disable MAC address autogeneration on the VLAN, use the no mac address autogenerate command. For example, enter:
    host1/Admin(config-if)# no mac address autogenerate

  • ACE: sticky serverfarm

    Dear all,
    I do have a question about the configuration option of a sticky serverfarm. There is an option to timeout active conns. Originally my thinking was that this option changes the sticky behaviour to a session timeout instead an idle timeout. While testing this seems to be not correct
    sticky http-cookie myCookie myStickyServerfarm
    timeout 10
    timeout activeconns
    replicate sticky
    serverfarm myServerfarm backup mySorryfarm
    The manual explains it like this:
    Configuring a Cookie Sticky Timeout
    The sticky timeout specifies the period of time that the ACE keeps the HTTP cookie sticky information for a client connection in the sticky table after the latest client connection terminates. The ACE resets the sticky timer for a specific sticky-table entry each time that the module opens a new connection that matches that entry.
    This brings me to the question, what is this option used for. The only diffrence I can see is, that there is a http connection which is open for longer than the timeout value (here 10min) will be kicked out and in the meantime this sticky-entry isn't used (otherwise the idle time would be reset).
    Are there any other explanations what this feature can do?
    best regards
    Oliver

    Hi Oliver,
    I'm afraid the official documentation is not very clear on this section.
    The sticky timeout doesn't count since the moment that the last connection is closed, but since it's established. However, by default it will not remove the sticky entry as long as there are connections still active. This is what can be tuned with the "timeout activeconns".
    When the "timeout activeconns" option is present, the ACE will remove the sticky entry as soon as the timer is reached, regardless of whether there are active connections or not.
    I hope this answers your question, but if you want some further clarification, let me know.
    Regards
    Daniel

  • ACE RHI problem

    Hello,
    I have two 6509 switches with ACE modules installed and configured as active/standby. There is no FWSM installed, so MSFC shares a common subnet with the external interface of ACE. On both MSFCs, I can see the static route injected (RHI) by ACE. However, those routes are different. On the MSFC hosting the active ACE, the next hop of the static route installed is the alias IP address of the external ACE interface. On the MSFC hosting the standby ACE has the next hop as the IP address of the external interface of the standby ACE not the alias.
    This causes a problem when traffic is routed through the second MSFC where it will send traffic destined to my VIP to the standby ACE causing traffic to be dropped.
    Why this behaviour happens? I started to see this behaviour after a sudden reboot on the standby ACE. Before that, I am not sure what was the route injected into the second MSFC but I had no problem with my VIP.
    Can anyone help me how I can tell the second MSFC to route traffic towards the alias instead of the interface IP?
    Thanks.

    The TAC case is resolved.  Posting back to the community so the solution can be shared with a wider audience.
    Thanks to Mohammed for keeping outputs of troubleshooting at the time of problem, it was found that after the standby ACE rebooted, BOTH the active ACE and standby ACE were injecting the host route to the VIP, this is not expected behaviour.  The expected behaviour is for the active ACE to inject the host route with the ACE alias IP as the next hop, and the standby to not inject the route.
    This problem is due to a software defect CSCsx67908 "When you configure ACEs for redundancy and Route Health Injection (RHI) and the standby ACE reboots, duplicate RHI entries can exist on the supervisor."
    ref: http://www.cisco.com/en/US/partner/docs/interfaces_modules/services_modules/ace/v3.00_A2/release/note/racea2_x.html
    Software fix integrated is available.  There is also workaround by a "FT switchover" on the ACE.
    Another workaround by routing is to disable RHI for the VIP, and instead advertise the VIP subnet by routing protocol on the switch supervisor (eg, advertising the connected Vlan via EIGRP, OSPF, etc...).
    RHI of the VIP is not enable by default, and can be disabled with the following from ACE:
    policy-map multi-match XYZ
      class ABC
        no loadbalance vip advertise active
    More info on RHI can be found here:
    http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/ace/vA4_1_0/configuration/getting/started/guide/rhi.html
    Regards,
    Simon

  • Ace Sticky Configuration

    Hi Guys,
    I'm trying to set up a sticky configuration on an ACE modeule in a 6500.
    I've got the loadbalancing woking happily but need to ammend the config to add stickiness.
    As far as I know the first command is someting on the lines of...
    sticky http-cookie COOKIENAME STICKYGROUP
    however when I put this in I get the following error.
    Error: Sticy resource not available
    I suspect that i'm missing something obvious.
    Any assistance is greatly appreciated.
    Regards
    Steve

    By default all the resources are available to ACE contexts except sticky resource.
    You need a resource class with sticky resource defined and this class applied to the context.
    for example
    resource-class GOLD
    limit-resource sticky minimum 1 maximum equal-to-min
    Thanks
    Syed Iftekhar Ahmed

  • ACE Sticky Slow-Start License

    Hi,all,
    I am testing ACE module@7606,
    system image file: [LCP] disk0:c6ace-t1k9-mz.A2_1_1_69.bin
    installed license: ACE-SSL-05K-K9.
    I wanta know if it is caused by license,Please help~~:)
    Phenomenon:
    1. Client sends a HTTP request to server
    2. server returns a HTTP response to Client, the response contains a HTTP URL and HTTP body, server sends HTTP URL first, then sends HTTP body right now.
    3. Client receives the HTTP URL first, after about 200ms, Client receives the HTTP body.
    . Root cause:
    1. If ACE receives the HTTP URL from rserver, it forwards the URL to Client. Then ACE will wait for a TCP ACK from client, before ACE receive the TCP ACK from client, it will not forward the HTTP body following to Client, the action is caused by TCP Slow Start algorithm. Windows Client will send the TCP ACK to ACE after about 200ms(40ms for Linux), the action is caused by TCP Delayed ACK algorithm. So from client side, it costs more than 200ms(or 40ms) to receive the entire HTTP response.
    . Solution:
    1. Disable Slow Start algorithm to VIP on ACE
    . Existing Issue:
    1. After disable Slow Start algorithm, the response time will be normal if Client access WAPI by VIP with SSL(means HTTPS). But the issue still exist if Client access server by VIP without SSL(means HTTP).
    2. I associate a policy of stickiness to VIP, both SSL and non-SSL. If I remove the policy of stickiness, the response time will be normal. It seems the policy of stickiness will make Slow Start algorithm enable.

    slowstart is disabled by default on ACE.
    switch/Admin# show parameter-map AllowMss
    Parameter-map : AllowMss
    Type : connection
    nagle : disabled
    slow start : disabled
    buffer-share size : 32768
    inactivity timeout (seconds) : TCP: 3600, UDP: 120, ICMP: 2
    embryonic timeout (seconds) : 5
    ack-delay (milliseconds) : 200
    But the ack-delay is indeed 200msec.
    Try to set the ack-delay to a lower value and see if that improves the situation.
    Gilles.

  • ACE License Problem

    Hi,
    I've a problem with license install procedure on ACE. If I try to perform cisco procedure:
    LICENSE KEY INSTALLATION INSTRUCTIONS
    After you have received the software license key for a new or upgraded license in an e-mail from Cisco Systems, you must copy the license file to a network server and then use the copy command in Exec mode to copy the file to disk0 on the ACE. The syntax for this command is:
    3-4
    copy tftp://server_name/path_filename disk0:
    The arguments are:
    . server_name-Network server where you copied the license file.
    . path_filename-URL location of the license file and the name of the file.
    . disk0:-Flash disk in the ACE.
    For example, to copy the ACE-VIRT-020.lic license file from the license directory on the track network server, enter:
    host1/Admin# copy tftp://track/license/ace-virt-020.lic disk0:
    To install a new software license on your ACE or to update an existing license to increase the number of virtual contexts, use the license install command in Exec mode. The syntax of this command is:
    license install disk0:filename
    The arguments are:
    . disk0:-Flash disk in the ACE.
    . filename-Filename for the license file.
    For example, enter:
    host1/Admin# license install disk0:ACE-VIRT-020.lic
    I received this message:
    Installing license... failed: License server does not support this feature
    Could somebody help me?
    Regards,
    Dino

    Hi Dino,
    the first license that i received was a text file with ASCII DOS control codes but the ACE needs Unix/Linux style ASCII control codes.
    If you have Linux machine around you should be able to use the programm dos2unix and convert it.
    There are also Editors around which can save the file in DOS or UNIX flavor.
    Anyhow if the license file is converted and you created an online lincse this should work.
    Copy the file with tftp: to disk0: and use license install disk0:name.lic.
    Hope it helps.
    Roble

  • ACE - Sticky using XFF client value

    Might be a stupid question  ....but we have a situation where client traffic is LB to our proxy infrastructure , at the LB the XFF client address is inserted into the header and source sticky is enabled. We now need to LB to addtional servers( more than within our proxy infrastructure) downstream from our proxy servers and retain the client sessions, if we use source sticky we will have a one to one relationship with the downstream servers . This we don't want as we want to spread the load across all downstream servers. My question is instead of source IP sticky could we use say the XFF info or something else to stick sessions to the downstream servers.

    Hi,
    So your proxy server will need to contact different servers through loadbalancer?
    You can use cookies for the same and make the ACE to insert cookie. I haven't tried using XFF header and value for sticky but ACE let's you configure it so it can be tried too.
    Regards,
    Kanwal
    Note: Please mark answers if they are helpful.

  • ACE Stickyness problem

    I am trying to configure stickyness on an ACE appliance. I can't seem to get it to work. I have tried a http cookie and a IP Netmask and can't get it to work. When I do a show stat sticky or a show sticky database I get nothing. Attached is the config of my ace.

    you need to assign sticky resources to your context before you can start using it.
    Use the following command to see if you have allocated sticky resources
    switch/Admin# show np 1 me-stats "-slb -v" | i Stick
    Num Active Sticky Entry: 1 0
    Num Active Reverse Sticky Entry: 0 0
    Free Sticky Entry Count: 944765 0
    switch/Admin#
    Gilles.

Maybe you are looking for