Two different VIPs for servers on cisco css

[kalugotla1]

Why do we use tow different vip ips for same real servers in content and group.

[stmccabe]

If the real servers are running mutiple web services on different ports, you could get away with a single VIP.  Also, there are considerations with unique IP for SSL offloaded traffic.

What is the scneario that you are referring to?  Can you provide more detail?

[kalugotla1]

In this scenario we Content and Group are using same servers ,but different vips .Can you let me know ,when will we consider this option.

ip route 10.192.134.0 255.255.255.0 10.192.133.40 1

circuit VLAN10

ip address 10.192.133.92 255.255.255.0
ip redundant-vip 32 10.192.133.132

service server1
keepalive type script ap-kal-ldap "10.192.134.181"
ip address 10.192.134.181
active

service server2
keepalive type script ap-kal-ldap "10.192.134.185"
ip address 10.192.134.185
active

owner LDAP_PEER

content ldappeerservers
add service server1
add service server2
protocol tcp
vip address 10.192.133.132
active

group LDAPpeer
add destination service server1
add destination service server2
vip address 10.192.133.215
active

[stmccabe · Accepted solution]

You only have one VIP/content rule below.  The group command with VIP defined is for source nat'ing:

group LDAPpeer
add destination service server1
add destination service server2
vip address 10.192.133.215
active

When a client request hits the VIP address 10.192.133.132, the request will be load balanced to one of the two real server/services defined.  When the server receives the first TCP SYN, if there was no group LDAPpeer source nat VIP address, then the server would see a source IP of the client, not the CSS.  This would cause a problem as the SYN/ACK would be sent back to the servers default GW.  If the server's DFGW isn't the CSS, then the CSS wouldn't see the server's return traffic theirfore the client connection would be RST. 

The group VIP allows all client requests to be nat'd to 10.192.133.215, allowing the servers turn SYMETRICALLY returned through the CSS maintaining the flow through the CSS..

HTH.

[kalugotla1]

stmccabe  Thanks for  explaining me.

[kalugotla1]

Just in case ,If we are not using the group (SNAT) and we just   have the content  VIP defined .

Then in that case will the  server  know the actual client IP. Or does the server respond back to the loadbalancer VIP

[stmccabe · Accepted solution]

If the group SNAT isn't in place the server will see the client's IP, not the VIP.  This will work if the servers default GW is the CSS, but if it's router GW (e.g., HSRP address), then the server traffic will bypass the CSS and follow the configured routing table for the OS.