cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1229
Views
0
Helpful
9
Replies

url based load balancing

lindacitron
Level 1
Level 1

I have my load balancing configured as follows:

URLs

/xxx/1 and /xxx/2 route to server1

URLs

/xxx/3 and /xxx/4 route to server2

This is working fine when the client application opens and closes the tcp connection for each http packet. For performance reasons we would prefer to open one connection and keep it open. When I try to do that I see that the first few packet that are all for server1 succeed, but the first one for server2 fails, and all subsequent packets on that connection fail.

Is there a way to configure the CSS to do what I want to do?

Thanks

Linda

9 Replies 9

Gilles Dufour
Cisco Employee
Cisco Employee

Linda,

in your content rule, use the command 'no persistent' and in global config mode, use the command 'persistence reset remap' to have the client redirected to the new server transparently.

You should also increase the default idle timeout.

The reason is that a persistent connection is very often idled and the CSS can't remapped idle connection.

To increase the timeout use 'flow-timeout-multiplier' if you have a CSS 11500 otherwise use the command 'flow port1 80 timeout 600'

Regards,

Gilles.

Thanks Gilles, It now load balances between the two servers, but when a packet gets routed to server2 server1 gets a ECONNRESET (connection reset by peer). The next packet to server1 opens a new connection. But once that connection is open the remaining packets whether to server1 or server2, go to server1..

I.E. if my configured rules are

/1 /2 route to server1

/3 /3 route to server1

This is what happens..

/1 goes to server1

/2 goes to server1

/3 goes to server2

server1's socket gets closed

/1 goes to server1 (new socket)

/3 goes to server1

What am I doing wrong?

Thanks

could you please attach a 'show run' so I can see what's wrong.

Thanks,

Gilles.

Thanks, Here it is..

User Access Verification

Username:cisco

Password:

CSS11050# show run

!Generated on 01/01/2079 00:00:51

!Active version: ap0610405

configure

!*************************** GLOBAL ***************************

username cisco des-password xxxx

no restrict web-mgmt

no restrict xml

persistence reset remap

flow port1 80 timeout 600

dns primary 10.63.3.60

dns secondary 10.63.2.32

dns suffix il.nds.com

host eshames-lin 10.63.60.191

host lcitron-lin 10.63.61.38

ip route 0.0.0.0 0.0.0.0 10.63.61.254 1

!************************* INTERFACE *************************

interface e1

bridge port-fast enable

interface e2

bridge port-fast enable

interface e3

bridge vlan 61

bridge port-fast enable

interface e4

bridge vlan 61

bridge port-fast enable

interface e5

bridge vlan 61

bridge port-fast enable

interface e6

bridge vlan 61

bridge port-fast enable

interface e8

bridge vlan 2

!************************** CIRCUIT **************************

circuit VLAN1

ip address 10.63.31.241 255.255.254.0

circuit VLAN61

ip address 10.63.61.245 255.255.254.0

circuit VLAN2

ip address 192.168.1.1 255.255.255.0

!************************** SERVICE **************************

service Atnds

ip address 10.63.5.12

active

service Citron

ip address 10.63.61.38

active

service Gershon

ip address 10.63.31.228

active

service Shames

ip address 10.63.60.191

active

!**************************** URQL ****************************

urql Linda-urls

description "Linda Web Server"

url 1

url 2

url 3

url 4

url 5

url 6

url 7

url 8

url 1 url "/bin/0/IB"

url 2 url "/bin/1/IB"

url 3 url "/bin/2/IB"

url 4 url "/bin/3/IB"

url 5 url "/bin/4/IB"

url 6 url "/bin/5/IB"

url 7 url "/bin/6/IB"

url 8 url "/bin/7/IB"

active

urql Shames-urls

description "Shames Web Server"

url 1

url 2

url 3

url 4

url 5

url 6

url 7

url 8

url 1 url "/bin/8/IB"

url 2 url "/bin/9/IB"

url 3 url "/bin/10/IB"

url 4 url "/bin/11/IB"

url 5 url "/bin/12/IB"

url 6 url "/bin/13/IB"

url 7 url "/bin/14/IB"

url 8 url "/bin/15/IB"

active

!*************************** OWNER ***************************

owner NDS.COM

content L3

vip-ping-response local-remote

vip address 10.63.31.229

protocol tcp

port 80

url "/*"

add service Gershon

active

content L5-Linda

vip-ping-response local-remote

vip address 10.63.61.244

add service Citron

protocol tcp

port 7001

url urql Linda-urls

no persistent

active

content L5-Shames

vip-ping-response local-remote

vip address 10.63.61.244

add service Shames

protocol tcp

port 7001

url urql Shames-urls

no persistent

active

CSS11050#

The config looks good.

The disconnect that you see on server1 is normal once the connection is remapped to server2.

Could you capture a sniffer trace of this issue ?

On client side and server side.

Thanks,

Gilles.

Hi Gilles,

I think I got a better handle on the problem..

My server's operation: - reads a packet from the tcp port,

- sends back a response. (in this case as you will see in the tcpdump its the server name)

When my client does the following:

- sends a packet

- reads the response.

Everything works fine...

When my client doesn't always read the response, things start not working.

The following traces are for the following scenario:

Client:

SendandRead(1)

SendandRead(2)

SendandRead(8)

SendandRead(9)

Send(3)

Send(10)

Send(4)

Send(4)

In the trace that is attached, the server never even gets 3. But sometimes it does. (when sniffing is on it never gets it!)

BTW I know that normal operation is that clients should always read the responses, but clients don't always work right...

Thanks

Linda

Hi Gilles,

Is it true that with http messages the css always expects the client to read the response before sending something else on the same connection, otherwise the css gets confused?

Please confirm.

Thanks

Linda

Linda,

looks like your client is doing pipelining.

It is sending request without waiting for the response.

This is not supported by any loadbalancer including the CSS.

Go into your browser setup and disable HTTP pipelining.

Thanks,

Gilles.

My client is doing pipeling, I wrote the client. If the CSS can't handle pipling it seems to me that it also can't handle things like a response getting lost, or takes so long to get back to the client that the read times out.

Responses can't really get lost because its tcp, but

would the correct thing to do then on a read timeing is to close the connection and open another one?

Thanks

Review Cisco Networking for a $25 gift card