03-10-2004 06:38 PM
i had a requirement of having a Primary and Backup server scenario, i.e users will only be directed to the backup server if the primary is down.
It did failover (by suspending the primary server).
But when I bring up the primary server, it still points me to the backup server.
I had read that either we manually suspend the backup server, or wait for the connection to be timed out, then the subsequent connection will be directed to the Primary server.
My requirement is that I do not wish to perform the manual task(i.e suspend the backup server).
But it did work successfully.
I did try to disconnect my session, and clear the cache on my browser (sort of new connection). But I am still being directed to the backup server.
So would like to check whether my config is wrong ?
this is my config:
service hpod02_02
ip address 1.1.1.1
protocol tcp
keepalive method get
keepalive port 80
keepalive type http
keepalive uri "/servername/apcsstest.asp"
active
service hpod03_02
ip address 1.1.1.2
protocol tcp
keepalive method get
keepalive port 80
keepalive type http
keepalive uri "/servername/apcsstest.asp"
active
owner hpod-test
content http/ssl-sg
vip address 2.2.2.1
advanced-balance sticky-srcip
sticky-mask 255.255.240.0
protocol tcp
add service hpod03_02
primarySorryServer hpod02_02
active
CSS11150# sho rule hpod-test
>>>>>>>>
Name: http/ssl-sg Owner: hpod-test
State: Active Type: HTTP
Balance: Round Robin Failover: N/A
Persistence: Enabled Param-Bypass: Disabled
IP Redundancy: Not Redundant
L3: 161.114.189.161
L4: TCP/Any
Url:
Redirect: ""
TCP RST client if service unreachable: Disabled
Rule Services:
1: hpod03_02-Alive
>>>>>>>>
Name: http/ssl-sg/hpod02 Owner: hpod-test
State: Active Type: HTTP
Balance: Round Robin Failover: N/A
Persistence: Enabled Param-Bypass: Disabled
IP Redundancy: Not Redundant
L3: 161.114.189.162
L4: TCP/Any
Url:
Redirect: ""
TCP RST client if service unreachable: Disabled
Rule Services:
1: hpod02_02-Alive
>>>>>>>>
Name: http/ssl-sg/hpod03 Owner: hpod-test
State: Active Type: HTTP
Balance: Round Robin Failover: N/A
Persistence: Enabled Param-Bypass: Disabled
IP Redundancy: Not Redundant
L3: 161.114.189.163
L4: TCP/Any
Url:
Redirect: ""
TCP RST client if service unreachable: Disabled
Rule Services:
1: hpod03_02-Alive
CSS11150# version ?
<cr> Execute command
CSS11150# version
Version: ap0500045 (5.00 Build 45)
Flash (Locked): 5.00 Build 10
Flash (Operational): 5.00 Build 45
Type: PRIMARY
Licensed Cmd Set(s): Standard Feature Set
Enhanced Feature Set
03-10-2004 09:14 PM
From the CSS Basic Configuration Guide:
"If you configure the 'persistence reset remap' command in the global configuration and no persistent command on the content rule, when a local service becomes available again, the CSS remaps any new or in-progress persistent connections to the local server from the sorry server. Otherwise, new connections go to the available local services, but in-progress persistent connections stay on the sorry server."
~Zach
03-10-2004 09:32 PM
thanks.
I did that. But the problem still persist.
But when I removed advanced-balance sticky-srcip from the content-rule. It works. So I think that the stickiness is the main culprit.
However "no persistence" is still required. And persistence reset redirect works as well.
03-11-2004 02:02 AM
why do you need the sticky setup anyway ?
You only have 1 service, so for sure the traffic will be sticky to this only server.
The 'no persistent' command guarantees that when the primary server comes alive, persistent connections to the backup server will be rebalanced to the primary server.
Let us know if you still need clarification.
Gilles.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide