Connections between servers using CSS VIP?

[veriton]

In our new pre-production environment we have several servers connected to a 3750 switch, which is then connected to a CSS 11503. Upstream the CSS is then connected to an ASA firewall pair. The CSS VIPs are 10.22.1.0/24 on the "outside" and the servers have 10.21.1.0/24 addresses on the inside. The CSS inside & server 3750 switchports are all on the same VLAN. There is no PAT/NAT configured (except for the VIP being translated to a chosen server IP I suppose).

Whilst the clients will connect to the servers via the VIPs what we want is for each server to also be able to talk to other servers via a VIP. This is because some of the servers provide a service (LDAP actually) that we would like to be load balanced.

Now, what is curious, is that *this works* in our production environment where the servers are *directly* attached to the 8 port switch module in the CSS. However in this new environment, where the 3750 is between the servers and the CSS, it doesn't (actually you can ping the VIP sucessfully but nothing else works).

I have seen other postings on NetPro where people are trying similar things, like: http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Networking%20Solutions&topic=Application%20Networking&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.1dd81312 and http://forums.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Emerging%20Technologies&topic=Content%20Networking&CommCmd=MB?cmd=display_location&location=.1dd72fd0

The relevant CSS config I think (there are lots more services etc but they are all similar) is:

circuit VLAN1

ip address 10.21.1.100 255.255.255.0

circuit VLAN2

ip address 10.22.1.1 255.255.255.0

keep alive ssokeepalive

type http

keepalive port 7777

uri "/sso/status"

keepalive frequency 10

keepalive maxfailure 2

tcp-close fin

active

service pulpldp001sso

ip address 10.21.1.6

keepalive type named ssokeepalive

active

content SSO

vip address 10.22.1.12

protocol tcp

port 7777

application http

url "/*"

advanced-balance cookie

add service pulldp001

active

i.e. VIP 10.22.1.12 will be directed to the server 10.21.1.6 (only the one shown above).

Q1) My first question is: is server to server communication via an outside VIP possible?!

Q2) Given that this seems to work our production environment without the 3750s any idea what areas of config could be wrong on the 3750 or the servers? (we've tried default routes of both the 3750 and the ISS inside address but that hasn't worked). Note the ping from a server works but when we try, say, "telnet 10.22.1.12 7777" that doesn't connect.

Q3) Let's assume that the servers run more than one service, e.g. an HTTP and an LDAP service. If a server can communicate with another server using its VIP, will it work from one server up to the CSS/VIP and back to itself? (of course it may or may not actually return to itself depending on the load etc)

I can provide full configs on Monday if required.

Hope these aren't dumb questions! Many thanks!

Simon

PS. the CSS is running 7.50 at the moment but could upgrade to 8.2 if required

[wong34539]

Server to server to communication is actually possible. The reason why telnet is not working could be because of the ASA firewall pair. Could you please take a look at the ASA fireawall configuration and check whether all the required ports are allowed ?

[veriton]

Hello

Thanks for your response - I'm pleased that the CSS will do server-server communication.

You made a good point about the ASAs, however in theory the packets shouldn't be going as far as that level - the servers (10.21.1.x) should be connected (via the 3750) to the 10.22.1.x VIP addresses on the CSS. The ASAs sit between the CSS and the rest of the net so shouldn't be involved in these routes.

It does sound to me like it might be a routing or VLAN issue. The strange thing is that a ping from a server to a VIP works but IP doesn't. That suggests the routing is OK (unless perhaps the CSS is replying to the ping irrespective of server response?).

I'm also puzzled as to why it works when the servers are directly attached to the CSS switch module - that sounds like a VLAN issue on the 3750... but how could the ping work?!

Any theories/suggestions greatly received! Thanks!

Simon

[aolabisi]

I was in your shoes although I'm running v8.2...

this fixed it for me. use "add dest service" in your group config instead of "add service".

let me know if this helps.

[veriton]

Thank you Adedayo - that appears to have done the trick! I can't believe it: one little keyword!

I have to say, even once you told me the answer I still didn't find the Cisco content config manual very helpful on this point (perhaps I'm looking in the wrong place?).

Note: we're not currently doing any PAT on the CSS so don't have any source groups set up - perhaps most people do and so don't have the same problem.

I'll get chance to report back on some proper testing next week and promise to update this conversation.

Adedayo: sorry, I wanted to flag your post as solving my problem once I was sure next week but now the tick box has gone - if you reply again I'll flag that! I appreciate you taking the trouble to post.

One final question: do you have a situation where you use a VIP from a server to potentially connect back to itself? If so, does it work OK? (e.g. if you have a webserver can you connect to the content VIP that it belongs to?)

Simon

[veriton]

This is all working like a dream now! Just to recap, here are the important parts of the final config:

circuit VLAN1

ip address 10.21.1.100 255.255.255.0

circuit VLAN2

ip address 10.22.1.1 255.255.255.0

service pulpldp001

ip address 10.21.1.6

active

content SSO

vip address 10.22.1.12

add service pulpldp001

active

group ldp

vip address 10.22.1.12

add destination service pulpldp001

active

===> note it is this final "group" definition that makes the server-server connections work. The CSS is running v8.20 (sg0820101) but this configuration may work with older versions.

In answer to my final question: yes, once you have the group defined a server can access a VIP and connect back to itself.

Thanks to everyone who contributed to this conversation!