CSM Server to Server

Muhammad Anser Khan · ‎01-30-2010

Dear All

Find the attached configuration.

When we try to access 10.1.100.50 (LB IP) from 10.1.100.20 (real server IP), it’s failing. Because CSM is assuming this request from server VLAN to server VLAN. 10.1.100.20 is already defined as a real server for 10.1.100.22 (LB IP).

!
vlan 802 server
ip address 10.1.100.200 255.255.255.0
alias 10.1.100.202 255.255.255.0
!

Here is the connection output from 10.1.100.20 to 10.1.100.50 (LB IP) :

SWITCH#sh module contentSwitchingModule 8 conns vserver PORTAL-HTTP | inc 10.1.100.20
In TCP 802 10.1.100.20:2673 10.1.100.50:80 ESTAB
Out TCP 802 10.1.100.51:80 10.1.100.20:2673 ESTAB

How can I solve this issue? Whereas If I bypass the LB IP (10.1.100.50), I can create the connection between 10.1.100.20 & 10.1.100.51.

Regards,

Anser

Sean Merrow · ‎02-01-2010

Hi Muhammad,

You will need to have the CSM perform source-NAT on the client connections so that when the servers receive the connection, they see the source address as an IP that the CSM owns. This will force them to send their responses back to the CSM instead of sending them directly back to the locally connected client. See sample config below. Only clients on the server/VIP subnet get source NAT'd. Clients from other subnets will not be NAT'd.:

======================================
On MSFC
======================================
ip access-list standard SERVER-SUBNET
permit 10.1.100.0 0.0.0.255

======================================
        On CSM
======================================
vlan 20 client
ip address 20.20.20.2 255.255.255.0
gateway 20.20.20.1
!
vlan 10 server
ip address 10.1.100.1 255.255.255.0
!
natpool SRC-NAT 10.1.100.100 10.1.100.100 netmask 255.255.255.0
!
probe PING icmp
!
serverfarm WEB
nat server
no nat client
real 10.1.100.51
   inservice
real 10.1.100.52
   inservice
real 10.1.100.33
   inservice
probe PING
!
policy SVR-TO-SVR
client-group SERVER-SUBNET
nat client SRC-NAT
serverfarm WEB
!
vserver WEB
virtual 10.1.100.50 tcp www
persistent rebalance
slb-policy SVR-TO-SVR
serverfarm WEB
inservice
!

Hope this helps!

Sean

Muhammad Anser Khan · ‎02-02-2010

Dear Sean,

Thanks for your reply.

Our CSM is in bridged mode. If I configure the following configuration, Will this solve our issue?

But in our case, Connection is initiating with the same server VLAN 802. As shown in this output:

SWITCH#sh module contentSwitchingModule 8 conns vserver PORTAL-HTTP | inc 10.1.100.20
In TCP 802 10.1.100.20:2673 10.1.100.50:80 ESTAB
Out TCP 802 10.1.100.51:80 10.1.100.20:2673 ESTAB

On MSFC
======================================
ip access-list standard SERVER-SUBNET
permit 10.1.100.0 0.0.0.255

or

Is this the client subnet(initiator of the connection) which is 10.1.100.20 in our case, So can I configure this:

ip access-list standard SERVER-SUBNET
permit host 10.1.100.20

======================================
On CSM
======================================
vlan 402 client
ip address 10.1.100.200 255.255.255.0
gateway 10.1.100.254
!
vlan 802 server
ip address 10.1.100.200 255.255.255.0
!

natpool SRC-NAT 10.1.100.100 10.1.100.100 netmask 255.255.255.0
!
probe PING icmp
!
serverfarm WEB
nat server
no nat client
real 10.1.100.51
   inservice
real 10.1.100.52
   inservice
probe PING
!
policy SVR-TO-SVR
client-group SERVER-SUBNET
nat client SRC-NAT
serverfarm WEB
!
vserver WEB
virtual 10.1.100.50 tcp www
persistent rebalance
slb-policy SVR-TO-SVR
serverfarm WEB
inservice
!

Regards,

Anser

Gilles Dufour · ‎02-02-2010

Anser,

Your CSM is in one-armed mode and probably set as the default gateway of your servers.

This does guarantee that all traffic from the server goes to the CSM.

However, for local clients, in the same subnet as the servers, the default gateway is not used and instead the servers can directly arp for the client address.

This is why in this case the resposne from the servers bypasses the CSM and create connection failures.

The solution provided by Sean is to src nat traffic coming from local clients to trick the servers into believing the request came from the CSM itself.

Your proposed configuration should work.

Gilles.

Muhammad Anser Khan · ‎02-02-2010

Dear Gilles,

I just mentioned in my last post that our CSM is in Bridged mode. And FWSM is the default gateway for all the subnets (including servers).

Regards,

Anser