topic Connection is not following the Sticky database when one router in Application Networking

Connection is not following the Sticky database when one router is comming to up state.

ranjith.kanisan — Mon, 13 Aug 2012 10:36:31 GMT

Dear Team,

We have 2 routers configured in Cisco ACE.( Router 1: 10.250.226.4,Router 2: 10.250.226.6) and VIP 10.250.226.19. In a normal scenario all the client connections are perfectly handled by ACE and Its sending to client request to router as per the sticky database. When the router 10.250.226.4 is down, ACE cleared all the sticky database entry belongs to the 10.250.226.4. All the client connections are shifted to router 10.250.226.6.

when router 10.250.226.4 is comes, backup connections are not loadbalance properly. That is connection not following sticky database for second connections of the same ip and giving issue in establishing IPSEC connectivity. Please find the below output.

switch/RRI# sh sticky database client 10.239.10.86

sticky group : STIK-RRI-FRM

type : IP

timeout : 1440 timeout-activeconns : FALSE

sticky-entry rserver-instance time-to-expire flags

---------------------+--------------------------------+--------------+-------+

10.239.10.86 CISCO-7206-06:0 65274 -

switch/RRI# show conn | i 10.239.10.86

1517152 2 in UDP 90 10.239.10.86:4500 10.250.226.19:4500 --

1427552 2 out UDP 9 10.250.226.4:4500 10.239.10.86:1637 --

3051606 2 in UDP 90 10.239.10.86:500 10.250.226.19:500 --

3049659 2 out UDP 9 10.250.226.6:500 10.239.10.86:44977 --

Please find the below sample configuration we are done in ACE.

parameter-map type connection UDP_PARAM_MAP

set timeout inactivity 86450

sticky ip-netmask 255.255.255.255 address source STIK-RRI-FRM

replicate sticky

serverfarm RRI-FRM

class-map match-all RRI-VIP

2 match virtual-address 10.250.226.19 any

policy-map type loadbalance first-match RRI-VIP-l7slb

class class-default

sticky-serverfarm STIK-RRI-FRM

policy-map multi-match RRI

class RRI-VIP

loadbalance vip inservice

loadbalance policy RRI-VIP-l7slb

loadbalance vip icmp-reply

connection advanced-options UDP_PARAM_MAP

interface vlan 90

ip address 10.250.226.17 255.255.255.240

peer ip address 10.250.226.18 255.255.255.240

access-group input ALL

access-group output ALL

service-policy input REMOTE_MGMT

service-policy input RRI

no shutdown

As per the analysis its looks seems to be tthe bug CSCsv63364, CSCsu95356. Kindly suggest how we can resolve this issue.

Image version: A2(3.4)

Thanks in advance.

Regards,

Ranjith

Connection is not following the Sticky database when one router

sivaksiv — Mon, 13 Aug 2012 13:46:07 GMT

Hi Ranjith,

It looks like timer issue not appropriate for both connections. Did you check the sticky entry for the client before the router came back up? I believe the sticky timeout should be higher than the connectionidle timeout. Something like 1 day for sticky timeout and 1 hour for connection idle timeout.

Regards,

Siva

Connection is not following the Sticky database when one router

ranjith.kanisan — Mon, 13 Aug 2012 14:56:28 GMT

Hi Siva,

We dont have the Sticky databse details before the router came to back to up. We are only facing this issue, when the router is coming back to the up state. Kindly suggest Sticky with leasedconnection will cause this issue? and also tell me, how this issue will happening when connection idle timeout value higher than the sticky time out value?

Thanks in advance?

Regards,

Ranjith

Connection is not following the Sticky database when one router

sivaksiv — Mon, 13 Aug 2012 15:15:43 GMT

Hi,

Its important to know whether there was a sticky entry when the router went down and the time it came back up. Leastconnection shouldn't be a problem here.

If the IPSEC connection is active but not the UDP 500 connections, after timeout the UDP 500 connections will be removed as well as the sticky entry. If the current active IPSEC connection suddently needs to refresh SA's a new UDP 500 connection will be open and it could be sent to a different server. There is no evidence that this is the problem but want to try a higher sticky timeout has a fix for this.

Siva