Logical Interfaces HP-UX 11i

[Greg Robertson]

Hi,
I have 2 HP RP2470 server acting a applications servers. I have create a script that will create a logical interface on starting the application so that on failing the application on to the second host up steam system just connect to the logical interface. The problem is on starting this application it opens a tcp link to a NAT address on a router to connect to a third party system. The NAT entry in the router if configured for the logical interfaces. Now for the question is is possible to force all traffic out the so call logical interface so that the source address is correct and NATing will work when the application fails over to the other system


Thanks in advance

[Duncan Edmonstone · Accepted solution]

Greg,

Although it doesn't llok like you are using MC/ServiceGuard, this is a common problem that we get when using 'relocatable' IP addresses, and the ServiceGuard manual has a short section describing this...

--------------------------------------
Bind to Relocatable IP Addresses

When sockets are bound, an IP address is specified in addition to the port number. This indicates the IP address to use for communication and is meant to allow applications to limit which interfaces can communicate with clients. An application can bind to INADDR_ANY as an indication that messages can arrive on any interface.
Network applications can bind to a stationary IP address, a relocatable IP address, or INADDR_ANY. If the stationary IP address is specified, then the application may fail when restarted on another node, because the stationary IP address is not moved to the new system. If an application binds to the relocatable IP address, then the application will behave correctly when moved to another system.
Many server-style applications will bind to INADDR_ANY, meaning that they will receive requests on any interface. This allows clients to send to the stationary or relocatable IP addresses. However, in this case the networking code cannot determine which source IP address is most appropriate for responses, so it will always pick the stationary IP address.
For TCP stream sockets, the TCP level of the protocol stack resolves this problem for the client since it is a connection-based protocol. On the client, TCP ignores the stationary IP address and continues to use the previously bound relocatable IP address originally used by the client.
With UDP datagram sockets, however, there is a problem. The client may connect to multiple servers utilizing the relocatable IP address and sort out the replies based on the source IP address in the server's response message. However, the source IP address given in this response will be the stationary IP address rather than the relocatable application IP address. Therefore, when creating a UDP socket for listening, the application must always call bind(2) with the appropriate relocatable application IP address rather than INADDR_ANY.
If the application cannot be modified as recommended above, a workaround to this problem is to not use the stationary IP address at all, and only use a single relocatable application IP address on a given LAN card. Limitations with this workaround are as follows:
??Local LAN failover will not work.
??There has to be an idle LAN card on each backup node that is used to relocate the relocatable application IP address in case of a failure.
Call bind() before connect()
When an application initiates its own connection, it should first call bind(2), specifying the application IP address before calling connect(2). Otherwise the connect request will be sent using the stationary IP address of the system's outbound LAN interface rather than the desired relocatable application IP address. The client will receive this IP address from the accept(2) call, possibly confusing the client software and preventing it from working correctly.

--------------------------------------

So if you don't have access to your applications source code, and it doesn't already have a feature to bind to specific IP address, then the only option is not to have a stationary IP address on the same subnet...

-OR- (and this is untested)

You could also add a static route which forces all traffic bound for your subnet out the logical interface...

e.g. if your network is 10.0.0.0, and your logical IP address is 10.1.2.3, then you could try:

route add net 10.0.0.0 netmask 255.0.0.0 10.1.2.3 0

HTH

Duncan