IBM Dynamic Virtual IP Address (Dynamic VIPA) Support

IBM® SecureWay Communications Server provides for dynamic virtual IP addresses (dynamic VIPA). This feature enables you to define a TCP/IP stack so that a TCP/IP address is dynamic and exists only when the application that defines it is active. Following is an example:

        	VIPARange    DEFINE     address_mask     network_prefix
Note: Refer to IBM documentation for options and definitions.

To use Dynamic VIPA for IBM Connect:Direct®, define a unique VIPA for each IBM Connect:Direct instance. An instance of IBM Connect:Direct is an “application” per the IBM SecureWay Communications documentation. When that instance is active, it defines the VIPA address, and when it terminates, it deactivates the VIPA address.

For IBM Connect:Direct Extended Recovery, define VIPA requirements the same way, but you must define the dynamic VIPA range in each TCP/IP stack. Each IBM Connect:Direct node must have a unique VIPA, meaning that in a IBM Connect:Direct/Plex environment, the manager and each server must have a unique VIPA to bind to. For HOT recovery, the standby server may have the same VIPA as the primary. The standby will not use the VIPA until it becomes the active server. In this way, it does not violate the VIPA rules as defined by IBM SecureWay Communications documentation.

IBM Distributed Dynamic Virtual IP Address and CD/Plex

Use Distributed Dynamic VIPA (DDVIPA) with Connect:Direct/Plex to allow the same IP address across all LPARS where it is defined. DDVIPA will allow Extended Recovery jobs/tasks to handle switching using the DDVIPA IPs. When using DDVIPA, the TCP.SOURCEIP must be set to the DDVIPA because the defaulted TCP.SOURCEIP will be associated to the local TCP stack, not the DDVIPA IP.

The API SIGNON, whether DMBATCH or TSO, is done based on the NETMAP entry for the LOCAL node, so that entry should specify the DDVIPA as well. Alternately, TCP.API.LISTEN in the Manager may include an entry for ANYADDR after the DDVIPA entry.