06-07-2007 06:38 AM
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
Solved! Go to Solution.
06-07-2007 06:52 AM
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.
06-07-2007 06:52 AM
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.
06-07-2007 07:02 AM
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
06-07-2007 09:20 AM
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
06-07-2007 04:45 PM
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.
06-07-2007 10:04 PM
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
06-07-2007 10:23 PM
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
06-10-2007 08:45 AM
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
06-09-2007 02:12 AM
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.
06-11-2007 03:46 AM
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
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