Configure an application server, a node, or a cell to use a single network interface

Application servers, by default, are configured to use all of the network interfaces that are available for them to use. We can change this configuration such that an application server only uses a specific network interface. However, we cannot configure it to use a subgroup of interfaces. For example, if we have three ethernet adapters, we cannot configure an application server to use two of the three adapters.

When an application server is configured to use all network interfaces, if it opens a socket on port 9901 on a machine with two TCP/IP addresses, it opens port 9901 on both IP addresses.

On a Microsoft Windows operating system, the netstat output displays *.9901 in the Local Address field, indicating that port 9901 is bound to all network interfaces in the system.

When an application server is configured to use a specific network interface, it only communicates on that one network interface. For example, on a Windows operating system, if an application server opens a socket on port 7842 on an ethernet adapter with an address of 192.168.1.150, the netstat output displays 192.168.1.150.7842 in the Local Address field, indicating that port 7842 is only bound to 192.168.1.150.

If we have more than one network interface and to use each one separately, you must have a separate configuration profile for each interface. When network interfaces are used separately, a separate node agent is required for each network interface that has an application server running on it. Two application servers bound to two separate network interfaces on the same machine cannot be in the same node because they have different TCP/IP addresses.

In a multi-homed environment you may need to separate inbound http and/or https traffic by forcing it to use a network adapter other than the one bound to the hostname used during installation. This separation can be accomplished by specifying the hostname or IP address be bound to a different network adapter for the defaulthost and defaulthost_secure ports on each application server that is to be redirected. This modification configures the application server so that it only accepts http and/or https traffic received over the specified adapter. Also, the deployment manager uses this hostname as the transport when generating the plugin for that application server. There are no known limitations to this modification provided only the defaulthost and defaulthost_secure ports are modified in this fashion.

Avoid trouble:

• If we want a specific application server to use a single network interface, perform the following steps for that application server.

• If we want an entire node to use a single network interface, perform the following steps for the node agent and all the application servers in that node.

• If we want an entire cell to use a single network interface, perform the following steps for the deployment manager, node agent, and all the application servers in the node.

• When performing the following steps, do not specify localhost, a loop back address, such as 127.0.0.1, or an * (asterisk) for the TCP/IP addresses.

• When the client ORB makes a TCP connection to a server, there are two possible scenarios:

  • The local socket side is bound to the single address, specified on either the ORB_LISTENER_ADDRESS property in the serverindex.xml file, or the com.ibm.CORBA.LocalHost custom property.

  • The local socket side is not bound to a particular address.

  These two scenarios occur because the Micosoft Windows networking stack does not forward packets across different scope zones. The loopback and public interfaces are in different scope zones.

  The first scenario fails with a SocketException if the client is running on Microsoft Windows7 or Microsoft Windows 2008 R2, and the com.ibm.ws.orb.transport.useMultiHome custom property on the client is set to false, because either:

  • The client ORB_LISTENER_ADDRESS host value, in the serverindex.xml file, or the com.ibm.CORBA.LocalHost custom property has an internal address of either localhost or 127.0.0.1, and the server has an external IP address or host name, such as 147.10.32.117).

  • Or the client has an external address and server has an internal address.

gotcha

1. Update the com.ibm.CORBA.LocalHost and com.ibm.ws.orb.transport.useMultiHome Object Request Broker(ORB) custom properties.

   1. In the console, navigate to the indicated panel.

      • For an application server, click Servers > Server Types > WebSphere application servers > server_name > Container Settings > Container services > ORB Service. Then in the Additional Properties section, click Custom properties.

      • For a deployment manager, click System Administration > dmgr. In the Additional Properties section, click ORB Service. Then, under Additional properties on the ORB Service panel, click Custom properties.

      • For a node agent, click System Administration > Node agents > node_agent . In the Additional Properties section, click ORB Service. Then, under Additional properties on the ORB Service panel, click Custom properties.

   2. Select the com.ibm.CORBA.LocalHost custom property and specify an IP address or hostname in the Value field. Do not set this property to either localhost or *.

      If the com.ibm.CORBA.LocalHost property is not in the list of already defined custom properties, click New and then enter com.ibm.CORBA.LocalHost in the Name field and specify an IP address or hostname in the Value field.

   3. Select the com.ibm.ws.orb.transport.useMultiHome custom property and specify false in the Value field. If the com.ibm.ws.orb.transport.useMultiHome property is not in the list of already defined custom properties, click New, and then enter com.ibm.ws.orb.transport.useMultiHome in the Name field and specify false in the Value field.

2. (zos) Update the daemon_protocol_iiop_listenIPAddress WebSphere variable to indicate the IP addresses to which we want the location service daemon to bind.

   1. In the console, click Environment > WebSphere variables.

   2. Select the DAEMON_protocol_iiop_listenIPAddress variable and specify * to specify bind all, or specify a specific IP address in the Value field. If the DAEMON_protocol_iiop_listenIPAddress variable is not in the list of already defined variables, click New, and then enter DAEMON_protocol_iiop_listenIPAddress in the Name field and specify the appropriate value in the Value field.

3. Update the JVM com.ibm.websphere.network.useMultiHome custom property for discovery and SOAP connections.

   1. In the console, navigate to the indicated page.

      • For an application server, click Servers > Server Types > WebSphere application servers > server_name > Java process management > Process definition > JVM > Custom properties.

      • For a deployment manager, click System Administration > dmgr > Java process management > Process definition > JVM > Custom properties.

      • For a node agent, click System Administration > Node agent > node_ agent > Java process management > Process definition > JVM > Custom properties.

      
      (zos)

      • For an application server, click Servers > Server Types > WebSphere application servers > server_name > Java process management > Process definition > process_type > JVM > Custom properties.

      • For a deployment manager, click System Administration > dmgr > Java process management > Process definition > process_type > JVM > Custom properties.

      • For a node agent, click System Administration > Node agents > node_ agent > Java process management > Process definition > Control > JVM > Custom properties.

   2. Select the com.ibm.websphere.network.useMultiHome custom property and specify false in the Value field. If the com.ibm.websphere.network.useMultiHome property is not in the list of already defined custom properties, click New and then enter com.ibm.websphere.network.useMultiHome in the Name field and specify false in the Value field.

4. Update the host name for TCP/IP connections.

   1. In the console, navigate to the indicated page.

      • For an application server, click Servers > Server Types > WebSphere application servers > server_name, and then, in the Additional Properties section, click Ports.

      • For a deployment manager, click System Administration > dmgr, and then, in the Additional Properties section, click Ports.

      • For a node agent, click System Administration > Node agents > node_ agent, and then, in the Additional Properties section, click Ports.

   2. Update the Host field for each of the listed ports to the value specified for the com.ibm.CORBA.LocalHost ORB custom property in the first step. When you finish, none of the entries listed in the Host column should contain an * (asterisk).

5. Change the Initial State setting for each of the Version 5 JMS servers to Stopped .

   1. In the console, click Servers > Server Types > Version 5 JMS servers.

   2. Click one of the listed JMS servers, and change the value specified for the Initial State field to Stopped.

   3. Repeat the previous step until the Initial State setting for all of the listed JMS servers is Stopped.

6. Save the changes.

   1. In the console, click System administration > Save Changes to Master Repository.

   2. Select Synchronize changes with nodes, and then click Save.

7. Stop and restart all the affected servers, node agents, and the deployment manager.

Results

You have configured an installation of WAS to communicate on one, and only one network interface on a machine that has more than one network interface.

Example

This example creates two nodes, each using a separate network interface, on a machine that has at least two network interfaces:

1. Use the Profile Management tool to create an application server and federate it into the desired cell.

2. Use the Profile Management tool to create an application server profile, specifying a host name that is different than the host name used for the previously created application server. Federate this application server into the desired cell.

3. Start the node agent and application server configured to the first network interface. Follow the preceding steps for the node agent and application server to prepare this node to communicate on the network interface specified when you configured this application server.

4. Start the second node agent and application server. Follow the preceding steps for the node agent and application server to prepare this node to communicate only on the network interface that specified when you configured the second application server.

5. Stop all of the node agents and application servers created in this example.

6. Restart all of these node agents and application servers.

You have two separate nodes running on two different network interfaces.

What to do next

For a stand-alone Java client or server to communicate with WebSphere Application Server, and you are using the WAS Software Development Kit (SDK), add the following properties to the Java command to enable the ORB for the application to communicate with a specific network interface.

-Dcom.ibm.ws.orb.transport.useMultiHome=false -Dcom.ibm.CORBA.LocalHost=host

host is the TCP/IP address or hostname of the network interface for the ORB to use.

Avoid trouble: Do not set host to localhost, a loop back address, such as 127.0.0.1, or an * (asterisk). gotcha