Thanks a lot!!!, it worked.

Rajeev

Thanks for the help. i have 2 more questions. after i have the css working perfectly, the application guys are asking for the source address, which is the IP of the actual client who is requesting the service; to be seen in their application. right now their application sees the vip address of the css only. is it possible to configure the CSS to meet their requirement?

Q2: can i add more interfaces to VLAN5, if I add more interfaces, will the traffic pass through all of them or any additional configuration is requried?

Please help me on the above 2 as well

Thanks in Advance.

Hi,

Well the configuration suggested with the groups does source NATing so the servers will see the VIP ad the source IP instead of real client's IP.

You can remove the group and use the CSS as the default gateway of the servers, that way you are not doing source NATing and the traffic will flow back thru the CSS anyway.

You need to make sure that the servers will route traffic back thru the CSS (no static routes on the servers using any other next hop) and also disable icmp redirects on the CSS.

Hope it helps!!

hi

we cannot change the gateway in the servers. The current setup is fine, the only requirement is to pass the Ip address of the requesting host. is there any work around to make it possible keeping the current configuration?

Thanks

It is a requirement for the traffic to flow back thru the CSS. The reason why this is happening is because of the source NATing, without that you will have an asymmetric flow.

In a one-arm setup the group is what is currently used, anyway you can have the workaround of using the CSS as default gateway of the servers and disable ICMP redirects.

I do not think that there is anything else to change the behavior, with your current design and if the gateway change is not a possibility, well you will not be able to see real client's IP reaching the servers.

This is actually the issue,

Client 1.1.1.1

VIP 2.2.2.2

server 3.3.3.3

Client sends a SYN with source IP 1.1.1.1 destined to the VIP.

Without NAT the CSS will send the SYN to the server with source IP 1.1.1.1

The server will see the SYN coming from 1.1.1.1 and will answer the SYN/ACK to that IP which will bypass the CSS.

The client gets a SYN/ACK from 3.3.3.3 but it did send a SYN to 2.2.2.2, so the packet is dropped.

So, it is "must" that the frames flow back thru the Load Balancer.

There are other balancers (such the CSM) that support bypassing the LB on the way back by implementing DSR (Direct Server Return), but this is not a possibility on the CSS.

Hope it clarifies!!

hi

Thanks for the information, that was more convincing.

where can i find the source IP address of the real host in the CSS, if some one asks for the icoming IPs for a period of time.

show flows gives the current stats only.

can add more interfaces to the VLAN5 in order to increase the through put.

Thanks for all your help. I have my production set up, working on the CSS

Rajeevan