TCP/IP using Service Guard

[Patrick Meade]

I have a clustered environment which uses service guard. I've been told by my sys admin that the virtual IP address functionality of service guard only works for inbound connections - i.e. when a client enters the virual name in a web browser it will automatically come to the active machine in the cluster.

That sounds great, but I need to use the virtual IP address for outbound connections - i.e. when my application connects to an outside server, I want the outside server to see the virtual ip address, and not the physical ip address of my machine. I'm being told that this is not possible with service guard, however I have doubts about whether or not that is true. I know that there are serveral packages out there that will do what I am asking.

Does anyone know if service guard supports this type of virtual ip use?

Thanks,
Patrick Meade

[James R. Ferguson]

Hi Patrick:

What has been described to you is what I have experienced, too. Interrogation of the source of a connection yields the fixed IPAddress of the node hosting the application, not the virtual (floating) IPaddress as one might wish.

Regards!

...JRF...

[Christopher Caldwell]

This behavior is dependent on the application and the option the application used when binding to an IP/port combination.

Older apps (telnet, rlogin, etc.) tend to bind with the INADDR_ANY option (bind to every available IP). Communications from these services "appear" like they're coming from the base IP of the box.

Newer apps (webservers, sendmail with port options added, etc), bind to the IP/port combination you specify, and the communications "appear" like they're coming from the IP/port combination.

In our SG implementation, we float these IPs.

So the answer is yes - Service Guard supports what you'd like to do with virtual IPs if your application support it this use of virtual IPs.

[Steve Bonds]

For an example of socket programming using bind() look at:

http://pont.net/socket/prog/tcpClient.c

The important part (apologies if the HP forums mangle the spacing):

-----
localAddr.sin_family = AF_INET;
localAddr.sin_addr.s_addr = htonl(INADDR_ANY);
localAddr.sin_port = htons(0);

rc = bind(sd, (struct sockaddr *) &localAddr, sizeof(localAddr));
if(rc<0) {
printf("%s: cannot bind port TCP %u\n",argv[0],SERVER_PORT);
perror("error ");
exit(1);
}

/* connect to server */
rc = connect(sd, (struct sockaddr *) &servAddr, sizeof(servAddr));
if(rc<0) {
perror("cannot connect ");
exit(1);
}
-----

In your case the INADDR_ANY would be replaced with the virtual IP address you want to use as your source IP.

-- Steve

[Patrick Meade]

Thanks for all the answers guys, but the problem I'm having is with connections initiated in the other direction. Binding to the virtual IP would help me if I were a server, but in this case my application is a client, so I don't ever bind to an address. I need to request a connection from a foreign server and use my virtual IP address. Its beginning to look like that might not be possible.

[Jim Keeble · Accepted solution]

Hi Patrick,

Even though you are a client calling connect(), you can still call bind() first to bind the local address for the socket. That will force the local IP on the TCP connection to the address you choose, in your case, the package IP.

Best regards,

Jim

[Steve Bonds]

Yes, if you look at the code I copied over you do not see any listen() call-- this is TCP *client* side code. (I.e. this code initiates the TCP connection.)

This threw me off at first until I realized that even though it's unusual to call bind() from a TCP client it's possible.

You can get more info from the connect() man page:

http://docs.hp.com/cgi-bin/onlinedocs.py?mpn=B2355-90682&service=hpux&path=../B2355-90682/00/00/31&title=HP-UX%20Reference%20Volume%203%3A%20Sections%202%20and%204

In particular:

-----
If the AF_INET socket does not already have a local address bound to it (see bind(2) ), connect() also binds the socket to a local address chosen by the system.
-----

-- Steve