topic Re: CSS Loadbalancing between internal servers in Application Networking

CSS Loadbalancing between internal servers

hoogen_82 — Thu, 07 Jun 2007 13:38:49 GMT

Hi,

I have my setup still in the design stage.

I am going to deploy a simple L4 loadbalancing. I have my clients sitting behind the CSS11501 trying to access my 4 weblogic servers.

So my config would look like

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

ip route 0.0.0.0 0.0.0.0 192.168.1.100 1

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

interface e12

bridge vlan 10

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

circuit VLAN1

ip address 192.168.1.50 255.255.255.0

circuit VLAN10

ip address 10.10.10.50 255.255.255.0

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

service www-server1

ip address 10.10.10.1

keepalive type http

active

service www-server2

ip address 10.10.10.2

keepalive type http

active

service www-server3

ip address 10.10.10.3

keepalive type http

active

service www-server4

ip address 10.10.10.4

keepalive type http

active

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

owner Sample

content web-servers

protocol tcp

port 80

add service www-server1

add service www-server2

add service www-server3

add service www-server4

vip address 192.168.1.1

active

So the above should do it. Now to the other part, my client says sometimes one of the servers might itself act like a client and talk to the other server(might be Server1 talking to Server2,3,&4 or might to only Server 2&3 alone) on a specific port and he needs this traffic also to be loadbalanced is this possible?

-Hoogen

Any help appreciated

Re: CSS Loadbalancing between internal servers

Gilles Dufour — Thu, 07 Jun 2007 13:52:06 GMT

Hoogen,

this is possible.

This is the same type of config except you have to add client nat to guarantee that the response from the servers do not bypass the CSS.

Client is configured with the command 'group'.

You can use it in combination with an ACL to limit the client nat function to server-to-server traffic.

Gilles.

Re: CSS Loadbalancing between internal servers

hoogen_82 — Thu, 07 Jun 2007 14:02:46 GMT

Hmm... Would it be like

!*************************** GROUP ****************************

group Servers

vip address

add destination www-server1

add destination www-server2

add destination www-server3

add destination www-server4

active

What would my ip address be then, and could you give me sample help on with the ACLS. Another thing is that the loadbalnce would happen on probably another port, how would i achieve this.

-Hoogen

Re: CSS Loadbalancing between internal servers

Gilles Dufour — Thu, 07 Jun 2007 16:20:47 GMT

Hoogen,

I don't think you want the solution you provided as it would do not for all traffic - not just servers to servers.

There is an example at

http://www.cisco.com/en/US/products/hw/contnetw/ps789/products_tech_note09186a0080093dfc.shtml

Gilles

Re: CSS Loadbalancing between internal servers

skumar1969 — Thu, 07 Jun 2007 23:45:13 GMT

Traffics using this src group can not be load balanced ever (can I say that Gilles?), rather use Content Rules for this purpose, as you might well aware of. In otherwords, if you are for load balancing there is no way but to make use of content rules. Lets think this way of implmentation.

Actually sometime ago, we had a very similar situation, what we asked the client was to use the domain name rather than an ip address, while talking to the other similar servers that are part of load balancing cloud. Configure weblogic servers to use external dns servers, if not the hosts files. The weblogic servers would then hit content rule VIPs and gets load balanced as usual.

If you want this (internally originated) traffic to hit a different content rule, use port numbers tagged in the domain name urls. eg. http://cisco.com:8090

As Gilles was saying destination services under groups, wouldn't do load balancing, rather just stop doing its default act of dest-NAT-ing (meaning stop spoofing client ip) and instead start doing source NAT-ing. This way you are actually making sure of not bypassing the CSS, however no load balancing though.

Thanks.

Re: CSS Loadbalancing between internal servers

hoogen_82 — Fri, 08 Jun 2007 05:04:00 GMT

hi gilles,

thanks a ton for your response - let me restate the issue. in my content rule, i have 4 services defined - when service 1 wants to talk to a backend server, it should loadbalance to service 2, 3, 4. similarly, when service 2 needs to contact a backend server, it should get loadbalanced between service 1, 3, 4.

now, i'm wondering if i do need client NAT at all? can't i create another 4 content rules, one for each service to use for backend communication. so for example, service 1 would talk to:

content service-1-backend

protocol tcp

port 80

add service www-server2

add service www-server3

add service www-server4

vip address x.x.x.x

active

this means that service1's src ip would remain its original ip so if it gets mapped to service2, for the backend communication, service2 can talk directly back to service1 - is there any reason this wouldn't work?

would it help to use the group/acl statement in my scenario?

thanks again for your continued support,

hoogen

Re: CSS Loadbalancing between internal servers

skumar1969 — Fri, 08 Jun 2007 05:23:13 GMT

Unfortunately, this config will not work in your case because of the CSS's ip spoofing behaviour. What it does mean is that CSS would use the real client ip (browser PC's, but in your case just another server) when it talks to any of the backend servers. Servers are not aware that CSS is actually spoofing. So they respond back directly, but no response, eventually CSS is bypassed. So, we need to stop this behaviour. So, use 'add destination service'. Yes, you can use 4 CRs for this purpose. Thanks

Re: CSS Loadbalancing between internal servers

Gilles Dufour — Sat, 09 Jun 2007 09:12:18 GMT

Hoogen,

it's easy to see why it would not work.

Let's says server1 sends a SYN to the VIP, the CSS forwards the SYN to server2 with source ip of server1.

So, server2 responds with SYN/ACK to server1 directly.

server1 did not send a SYN to server2 but to the VIP, so it does reject the connection and sends a RESET directly to server2 which drops the connection.

You need client nat if you want to go from vlan_A to vlan_A. It does not matter if the devices in the vlan participate or not to the loadbalancing.

So, in your case, you need the client nat with an acl and don't bother doing separate content rules for each server.

Gilles.

Re: CSS Loadbalancing between internal servers

maskmukesh — Sun, 10 Jun 2007 15:45:03 GMT

Hi Kumar,

is there any link where we can find the full CSS load balancing examples.

please if you could help me out this would be great help.

regards

Mukesh

Re: CSS Loadbalancing between internal servers

hoogen_82 — Mon, 11 Jun 2007 10:46:30 GMT

Hi Giles

As per your update i have created a config as per my understanding. would be possible for you to verify this?

CS100# configure

CS100(config)# acl 1

CS100(config-acl[1])# clause 50 permit any any destination any

CS100(config-acl[1])# apply circuit-(VLAN1)

CS100(config-acl[1])# ex

CS100(config)# acl enable

CS100(config)# group clients-group1

CS100(config-group[clients-group])# vip address 10.10.10.11

CS100(config-group[clients-group])# act

CS100(config)# group clients-group2

CS100(config-group[clients-group])# vip address 10.10.10.12

CS100(config-group[clients-group])# act

CS100(config)# group clients-group3

CS100(config-group[clients-group])# vip address 10.10.10.13

CS100(config-group[clients-group])# act

CS100(config)# group clients-group4

CS100(config-group[clients-group])# vip address 10.10.10.14

CS100(config-group[clients-group])# act

CS100(config)# acl disable

CS100(config)# acl 1

CS100(config-acl[1])# clause 10 permit any 10.10.10.0 255.255.255.0

destination 10.10.10.0 255.255.255.0

CS100(config-acl[1])# clause 15 permit any 10.10.10.2 255.255.255.255

destination any sourcegroup clients-group1

CS100(config-acl[1])# clause 16 permit any 10.10.10.3 255.255.255.255

destination any sourcegroup clients-group1

CS100(config-acl[1])# clause 17 permit any 10.10.10.4 255.255.255.255

destination any sourcegroup clients-group1

CS100(config-acl[1])# clause 25 permit any 10.10.10.1 255.255.255.255

destination any sourcegroup clients-group2

CS100(config-acl[1])# clause 26 permit any 10.10.10.3 255.255.255.255

destination any sourcegroup clients-group2

CS100(config-acl[1])# clause 27 permit any 10.10.10.4 255.255.255.255

destination any sourcegroup clients-group2

CS100(config-acl[1])# clause 35 permit any 10.10.10.2 255.255.255.255

destination any sourcegroup clients-group3

CS100(config-acl[1])# clause 36 permit any 10.10.10.1 255.255.255.255

destination any sourcegroup clients-group3

CS100(config-acl[1])# clause 37 permit any 10.10.10.4 255.255.255.255

destination any sourcegroup clients-group3

CS100(config-acl[1])# clause 45 permit any 10.10.10.2 255.255.255.255

destination any sourcegroup clients-group4

CS100(config-acl[1])# clause 46 permit any 10.10.10.3 255.255.255.255

destination any sourcegroup clients-group4

CS100(config-acl[1])# clause 47 permit any 10.10.10.1 255.255.255.255

destination any sourcegroup clients-group4

CS100(config-acl[1])# remove circuit-(VLAN1)

CS100(config-acl[1])# apply circuit-(VLAN1)

CS100(config-acl[1])# ex

CS100(config)# acl enable

Thank You

Hoogen