Domain Network Configuration

In a simple server setup, you usually would assign a single network address and port number to a WebLogic instance and use this address and port for all communication with the server. Each different protocol supported by WebLogic is then multiplexed onto the same host address and port. You can tune the setup by specifying various connection and messaging timeouts and enabling tunneling. This default network configuration for a server is called the default network channel (although not explicitly in the Administration Console). You can further refine this basic setup by creating an administration channel, which provides an additional port exclusively for administration traffic. In this way, all administration traffic will use the dedicated administration port, while all other traffic will use the default network channel. This separation provides many benefits, including increased reliability and security of administration traffic.

Finally, WebLogic lets you exploit a far more complex network configuration that assigns different protocols to different addresses and ports on the same server. You can achieve this by creating custom network channels. Each network channel can be tuned independently and even be assigned different NICs on a multihomed machine.

13.6.1 The Default Network Channel

The most important connection settings for a Managed Server are its listen address and port. These settings form the basis of all communication with the server, using any of the permitted connection protocols. You also can adjust other network characteristics by enabling SSL ports and refining individual protocol settings through timeout values and tunneling. All these network settings can be configured individually for each server in the domain.

Use the Administration Console to adjust the network configuration for a particular server. Select the server node from the left pane, and then choose the Configuration/General tab. If you want to view or modify the more advanced network settings, choose the Protocols[3] tab. All of these settings come under the scope of the default network channel. Its significance in creating custom network channels will become clearer a bit later.

[3] In WebLogic 7.0, use the Connections tab instead.

13.6.1.1 General settings

The most general settings are available under the Configuration/General tab. This tab lets you configure the listen address and ports:

Listen Address

This is perhaps the most important of all the IP address or DNS name of the server used to listen for incoming connections. If you leave this field blank or specify a localhost address, you implicitly bind the Listen Port and SSL Listen Port to all IP addresses available for the machine hosting the server.

Listen Port and Listen Port Enabled

If the listen port is enabled, plain-text connections are allowed on the specified port. Otherwise, no plain-text connections are allowed.

SSL Listen Port and SSL Listen Port Enabled

If the SSL port is enabled, SSL traffic is allowed on the specified port. Otherwise, no SSL traffic is allowed.

If you disable the plain-text listen port, make sure that you enable an SSL port for secure traffic otherwise, the server instance will be isolated. To properly configure SSL, you need to configure the server's identity and a list of certificates of trust CAs. SSL setup is covered in more detail in Chapter 16.

13.6.1.2 Protocols

WebLogic supports a number of different protocols, listed in Table 13-1. To configure these protocols using the Administration Console in WebLogic 8.1, select a server from the left pane, and then choose from one of the tabs under the Protocols tab. The General tab provides the configuration for all types of connections, whereas the HTTP, COM, and IIOP tabs cover the individual protocols. In WebLogic 7.0, the tabs under the Connections tab for the selected server provide similar functionality.

Table 13-1. Supported network protocols

Protocol	Description
HTTP and HTTPS	These protocols are used primarily for HTTP communication between the browser and the web server.
IIOP and IIOPS	These protocols are used for IIOP traffic between WebLogic and Java clients.
T3 and T3S	WebLogic uses the T3 protocols for internal and external connections to the servers. The T3 protocol often is used in WebLogic's implementation of RMI.
COM	This allows Windows-based COM objects to talk to WebLogic. You can enable COM traffic on the plain-text port, but not on the SSL port.

By default, COM is not enabled for a server. You can customize each protocol individually by clicking the appropriate tab.

All of these protocols are, by default, multiplexed over the same connection to the server's address and port. So you can access a web page hosted by the server using a URL such as http://host:port/page.jsp. An external client can set up an initial JNDI context to a server using the URL t3://host:port/. All that has changed is the protocol over which the client must communicate with the server.

13.6.1.3 Tuning

There are a number of places where you can tune network characteristics. Use the Tuning tab to adjust the more general network characteristics. In particular, you can tune the following parameters:

Accept Backlog

This parameter determines the maximum number of connection requests on the listen port(s) that may be queued. It defaults to 50.

Login Timeout and SSL Login Timeout

Use these timeouts to set the maximum amount of time allowed for a new plain-text or SSL connection to be established. The default timeout for plain-text connections is 5000 ms, and for SSL connections it is 25000 ms.

Maximum Open Sockets

This setting determines the maximum number of open sockets allowed by the server at any given time. If this value is exceeded, the server will stop accepting any new requests until the number of active sockets drops below this threshold. The default value for this setting is 2147483647.

The Protocols/General tab in WebLogic 8.1 lets you tune the default network channel. These settings are relevant particularly to withstanding denial-of-service attacks:

Complete Message Timeout

Use this parameter to set the maximum amount of time that WebLogic will wait for a complete message to be received. It defaults to 60 seconds.

Idle Connection Timeout

Use this parameter to set the maximum duration (in seconds) that a connection may be idle before WebLogic closes it. It defaults to 65 seconds.

Maximum Message Size

Use this parameter to set the maximum size allowed for the message header. It defaults to 10000000 bytes.

The final set of tuning parameters is protocol-specific. Simply select the appropriate tab: HTTP, COM, or IIOP (in WebLogic 7.0, use the additional attributes found in the Protocols tab itself). For example, you can specify the maximum size allowed for an HTTP POST message (to help prevent denial-of-service attacks).

13.6.1.4 Tunneling

You can configure WebLogic to tunnel various protocols from the Protocols/General tab. When tunneling is enabled, a client can connect to WebLogic in a way that allows requests using one protocol to be sent over another protocol. For example, an RMI client typically would use a T3 URL to connect to a WebLogic instance. By default, WebLogic uses its proprietary T3 protocol for all RMI interaction. However, your network may not allow you to always use T3 for instance, this is the case if all client requests must pass through a protocol-filtering firewall that permits only HTTP connections. In such a situation, you may need to tunnel T3 requests over HTTP connections. To enable this setup, the server must be explicitly configured to support tunneling, as well as the HTTP and T3 protocols and either plain-text or secure connections (or both).

Tunneling generally is quite expensive. A remote client can communicate much faster and more efficiently if it creates connections using the correct protocol, and does not tunnel requests over another protocol. So, for example, T3 calls are far more efficient than if they were tunneled over HTTP.

RMI tends to be a common source of confusion. RMI is an API for building remote clients and servers, and it can use any number of communication protocols. By default, WebLogic implements RMI using the T3 protocol. It also can use the IIOP protocol. RMI clients can indicate their preference by selecting the protocol when constructing the URL. T3 tends to be the fastest. Other application servers may use a different protocol for example, JRMP. Things are a little different for WebLogic JMS. By default, most communication takes place using RMI implemented over T3. However, JMS thin clients will communicate using RMI over IIOP, even if you specify a T3 URL!

You always should be aware of which protocols are in effect in a given situation, as well as whether tunneling is being used. Besides the performance implications, there also are behavioral consequences. For example, a remote JMS thin client will use the IIOP protocol and therefore be subjected to IIOP timeouts.

Two other options are relevant to tunneling on the Protocols/General tab, and are needed only if tunneling is enabled:

Tunneling Client Ping

This setting determines how often WebLogic pings a tunneling client to see if it is still alive. This defaults to 45 seconds.

Tunneling Client Timeout

This setting determines the duration after which an unreachable tunneled client is considered dead. This defaults to 40 seconds.

13.6.2 The Administration Channel

Usually all administration traffic flows through the same channels as application traffic. That is, the administration traffic uses the same address and port as the default channel. By creating a separate channel for all administration traffic, you get the following benefits:

• The administration and application traffic are physically separated. This ensures that you always can send administration operations to a server regardless of the volume of application traffic. For instance, you would be assured of having enough network capacity to deploy an application or optimize a server setting.
• A Managed Server can be started in standby mode if you use an Administration Channel. When a server starts in standby mode, only its Administration Channel is active; all other network channels are unavailable to its clients. Additionally, all applications and services are initialized. This is essentially a hot standby mode, ready for a signal to activate to the "running" state.
• Servers that have an Administration Channel support the shutdown and thread_dump administrative commands in case the server is deadlocked. Without an Administration Channel, these commands may not work on a deadlocked server.

When you enable the "Enabling the domain wide administration port" setting for a domain, you implicitly create an Administrator channel, much like the default network channel that is available to each server. When this is enabled, all of the Managed Servers in the domain are required to use the secure administration port for all administration traffic.

13.6.2.1 Consequences on domain configuration

Once the administration port has been enabled, all administration traffic flows through it. All Managed Servers will communicate with the Administration Server on this channel, and all administration tasks must be routed through the Administration Channel to any of the Managed Servers. Administration channels impose some demands on the design of the domain. The primary requirement is that SSL is enabled on the Administration Server and all of the Managed Servers. When starting a Managed Server, you always specify the URL of the Administration Server:

-Dweblogic.management.server=http://10.0.10.10:7001

Here 7001 is the listen port for the Administration Server. Because the Administration Channel operates in SSL mode, the URL of the Administration Server now must use the HTTPS protocol:

-Dweblogic.management.server=https://10.0.10.10:9002

In this case, 9002 is the default domain-wide administration port. Furthermore, the Administration Console now will be accessible via an HTTPS URL e.g., https://10.0.10.10:9002/console.

All Managed Servers are required to support SSL and use the secure administration port to talk to the Administration Server. For this reason, the administration port is a domain-specific setting that cannot be configured separately for each Managed Server.

13.6.2.2 Configuration changes

You can use the Administration Console to enable the administration port. Select the domain from the lefthand pane and then tick the "Enable the domain-wide administration port" setting from the Configuration/General tab. You must specify a port number that should be used (by default, it is 9002). You also must configure SSL on all the servers in the domain. SSL setup is described in detail in Chapter 16. The administration port number can be customized for each Managed Server. Select a server and choose the Configuration/General tab.[4] Under the advanced section, change the Local Administration Port Override setting. All servers, including the Administration Server, will need to be restarted for these changes to take effect.

[4] In WebLogic 7.0, this setting is in the Connections/SSL Ports tab.

If you need to further refine the Administration Channel, perhaps by binding it to a different IP address, you must create a custom network channel that uses the admin protocol.

13.6.3 Custom Network Channels in WebLogic 8.1

We've just seen how you can use the Administration Console to define the network characteristics for each server in the domain. The configuration options are rather limited, though, because each protocol is multiplexed onto the same host and port. To build on the server's setup for the default channel, you need to create one or more custom network channels. As explained earlier, a network channel is a combination of host, port, and protocol. It lets you assign a protocol to a particular host and port combination. You can create a number of network channels for every server, each capturing the configuration for a particular protocol. This lets you accomplish a number of things:

• Because a channel assigns a specific protocol to a particular host and port, you can designate different NICs to different protocols.
• A network channel can be configured independently, allowing you to change the connection settings such as timeout values and message size limits on a per-protocol basis.
• A network channel can be configured to support outbound connections (to an external client). By creating two separate channels, one for outbound traffic only and another for local server-to-server traffic only, you can segregate client traffic from interserver traffic.

All of these options provide you with a richer network configuration with which to design the physical architecture of your system.

Without any custom network channels, a server uses the settings for the default channel supplied in the Configuration/General tab. When you create additional network channels for the server, you can choose to not set certain connection attributes of the channel, such as the host address. In these cases, the custom network channel inherits its settings from the default channel. For this reason, whenever you set up custom channels, keep an eye on the default channel configuration as well.

13.6.3.1 Creating network channels

Network channels are created on a per-server basis. If a number of servers must share the same network configuration, you need to create network channels with identical settings on each server. Select the server from the left pane of the Administration Console and then select the Protocols/Channels tab. You can use this same tab to list previously created network channels.

For a new network channel, you should supply the listen address, listen port, and a network protocol for the channel. The protocol can take any one of following values: t3, t3s, iiop, iiops, com, http, https, or admin. Each channel for the server must have a unique combination of host, port, and protocol. If you create two channels with the same host, port, and protocol combination, it may result in a network configuration error during startup. Once you create a network channel, you can tune its configuration independently of other channels. Note that new network channels come into effect only after you restart the server.

Use the admin protocol to create a custom administration channel. A custom channel for administration traffic provides you with just a little more flexibility and security. For example, on a multihomed machine, you can bind the administration channel to the IP address of a NIC that is used only in internal communications, and that is hidden from external clients.

Note that for a T3 network channel, you also can enable tunneling of T3 requests over HTTP by setting the Tunneling Enabled flag to true. If you do this, remember also to enable HTTP on the same channel set the HTTP Enabled for this Protocol flag to true.

13.6.3.2 Enabling interserver communication

Network channels let you tune an important network attribute the Outbound Enabled setting. When this attribute is set to true, a network channel will support internal server-to-server communication. WebLogic then can use the channel to initiate outbound connections to other WebLogic servers. For example, if the server needs to make an EJB call to a remote server, it will use a channel that supports server-to-server communication. By default, a network channel will support internal, server-to-server communication. If this setting is disabled, the channel will not be used for interserver communication.

You can use this feature if the machine hosting the server was equipped with multiple NICs. In such a case, you could set up a channel dedicated for client traffic on one NIC (by disabling server-to-server traffic), and another channel to support inter-server communication on the other NIC. In this way, you can separate external, client traffic from internal server-based communication. Later, we shall examine various network configurations that make use of this feature.

13.6.4 Network Channels and Access Points in WebLogic 7.0

Network channels were introduced in WebLogic 7.0 and also are available in WebLogic 8.1. There is one crucial difference, though. In WebLogic 8.1, network channels are server-specific and cannot be shared. In WebLogic 7.0, however, network channels can be shared across servers i.e., you could assign a channel to multiple servers in the domain. So, for instance, you could assign a channel to all members of a cluster to ensure that they all use the same multicast address.

Because the same network channel could be targeted to multiple servers, WebLogic 7.0 also provides a mechanism for adjusting the behavior of the channel for any of the targeted servers. WebLogic 7.0 supports this through a NAP. A NAP allows you to adapt the behavior of a network channel for individual servers. Thus, a NAP is a server-specific customization of a network channel. You can use a NAP only in conjunction with a network channel for instance, to override the listen address and ports, to adjust the tuning properties, and to override the protocol settings. Clearly, because network channels cannot be shared in WebLogic 8.1, it does not need to support NAPs. If you want to ease future migration to WebLogic 8.1, avoid using NAPs and avoid sharing network channels.

The Administration Console does not explicitly list the NAPs for the network channels for a server. Instead, you have to choose a server from the left pane and select the Connections tab. Then select the Channel Overrides link at the bottom, from either the Tuning Protocols or the SSL Ports tabs, to view the network channels associated with the server. When you select a particular channel, you implicitly view the details of the associated NAP.

Because a NAP customizes the network channel for a particular server, you can specify, at most, one NAP for each network channel for each server in the domain. Remember that a NAP is optional set up a NAP only if the default configuration provided by the network channel isn't adequate. However, if you do specify a NAP, only the changed values override the network settings for the channel. The NAP will inherit all settings from the channel that are left unaltered.

Other than NAPs, the configuration of network channels and their use follows that of WebLogic 8.1.

13.6.4.1 Getting a summary

Earlier, we looked at how to configure the various characteristics of the default channel. In general, a network resource has a listen address, listen ports for plain-text and SSL connections, support for one or more allowed protocols, and finer adjustments on connection settings. The Connections/Summary tab for a server provides a snapshot of all these settings. Here's an overview of a sample network configuration for a server:

Cluster Participant: false
Native Socket IO Enabled: true
Reverse DNS Allowed: false
Network Channel: Default
Listen Address: not configured
Listen Port: 7001
SSL Listen Port: 7002
External DNS Name: not configured
Cluster Address: not configured
Protocol(s): T3,T3S,HTTP,HTTPS,IIOP,IIOPS
Tunneling Enabled: false
Outgoing Enabled: true
Admin Traffic Only: false
Admin Traffic OK: true
Channel Weight: 50
Accept Backlog: 50
Login Timeout: 5000 ms
Login Timeout SSL: 25000 ms
Message Timeout HTTP: 60000 ms
Message Timeout T3: 60000 ms
Message Timeout IIOP: 60000 ms
Idle Timeout IIOP: 60000 ms
Max Message Size HTTP: 10000000
Max Message Size T3: 10000000
Max Message Size IIOP: 10000000

13.6.4.2 Viewing network configurations

The easiest way to view the domain's network configuration is to use the Administration Console and then select the Network Channels node on the left pane. If you choose the "View network summary table (all servers, without channels)" option, it will show the default channels for the servers. This includes the Default and Administrator channels for the Administration Server and all of the Managed Servers. The information includes a list of all listen addresses, listen ports, SSL listen ports, and allowed protocols.

If you choose the "View network summary table (all servers and all channels)" option, you additionally can view the configuration settings for all network channels targeted to each server. However, in order to view all the NAPs for a server, you must select the Channel Override option for that server. Even though it returns a list of network channels targeted to the server, when you click a network channel, you actually view the server-specific overrides for that channel.

13.6.4.3 Channel priority for outgoing connections

WebLogic can have multiple network channels associated with it, some of which may support internal, server-based communication. WebLogic lets you prioritize network channels used for interserver communication. Each channel has an associated channel weight, which is an integer value between 1 and 100. When a server needs to initiate a connection to another server, it first determines all outbound-enabled channels that support the required protocol. Then, from this list it picks the network channel with the higher-weighted value over channels with a lower weight.

If the server runs on a system with multiple NICs, you can create multiple network channels, one corresponding to each NIC, and assign weights to each NIC based on known speeds of the network cards (so, the faster the NIC, the higher the weight). This way you can ensure all interserver communication has a guaranteed level of throughput because the server always will try to use the higher-priority channels.

Channel weights apply only to internal connections to other servers (e.g., a method call to a remote EJB). Channel weights are ignored when a connection is initiated directly via a URL.

Sometimes WebLogic may upgrade the service level needed for an outgoing connection. For instance, if the server needs to perform an RMI lookup using a T3 connection, and the server can resolve only to a network channel that support T3S connections, the server will initiate an outgoing T3S connection.

WebLogic also is capable of handling channel failures usually it will pick the higher-weighted channel before the lower-weighted ones. However, if a channel becomes unavailable because of a network failure, it automatically tries the channel with the next-highest weight. WebLogic returns a connection failure only when all available channels for a requested outgoing connection are exhausted.

Channel weights are no longer available in WebLogic 8.1. Instead, WebLogic 8.1 relies on the operating system to handle NIC failover. Most modern operating systems do support some sort of NIC failover and QoS levels. You comfortably can use this support instead of channel weights in WebLogic 7.0 as well.

13.6.5 Best Practices for Configuring Networks

Earlier we saw how the network configuration for a server is spread across its default configuration and across any network channels. A well-designed network configuration facilitates ease of management, adaptability, and optimization. You should be able to incorporate future changes to the physical network easily, and continue to get the best performance out of your network resources. This means that you need to be aware of the relative benefits and limitations of using the default network configuration and network channels.

If your domain has multiple Managed Servers that are running on separate machines or on a multihomed machine with multiple NICs, or if the domain caters to clients that communicate via different protocols, you should consider using network channels. Let's look at how a judicious setup of network channels can help you achieve interesting network configurations.

13.6.5.1 Segmenting network traffic by port number

Task: You can use channels to segment network traffic by port numbers, typically assigning different protocols to different ports. For instance, you could demand that HTTP traffic arrive on port 8001 only, while T3 traffic arrives on port 9001. You don't have to force each different server to use the same port number either any server can use different port numbers of the same protocol, something that you will need to do if you run more than one server on a single machine.

Reason: When a listen port is dedicated to connection requests for particular protocols, the server automatically maintains a separate queue for each protocol. This way you don't have T3 connection requests in the same queue as for HTTP requests. Having a dedicated network channel for each protocol provides greater flexibility. If you ever add another NIC to the machine, you can create a channel that assigns the HTTP traffic to the faster NIC, while the T3 channel still can be targeted to the existing NIC. It also provides additional flexibility when designing the security aspects of the hardware setup. If external clients use only HTTP, you should only expose a port that runs the HTTP protocol.

Sample Configuration: Figure 13-2 illustrates a network configuration that places HTTP traffic on its own port.

Figure 13-2. Segmenting traffic by port numbers

Here we create a network channel dedicated to HTTP traffic. This channel should listen on port 80, while the other channel, which handles traffic on all other protocols, listens on port 8001.

To create such a configuration, you must perform the following tasks:

1. Set up the default network configuration on the server. In the example, the default channel is set for the address 10.0.10.10 and for port 8001.
2. Create a custom network channel on the server, using the HTTP protocol and setting the port to 80.

If you want to duplicate this network setup on several servers, you need to create the same network channel on each server. In WebLogic 7.0, you simply can create one network channel and assign it to each machine.

Even though this example creates two ports for the different types of traffic, they are still on the same physical network. That is, both ports are configured to run on the same NIC, and so there is no physical separation of traffic.

13.6.5.2 Physically segmenting network traffic

Task: To physically separate network traffic by assigning different protocols to different NICs.

Reason: A physical separation of network traffic could be useful for both security and performance reasons. If the server traffic is network-bound, for instance, it may be useful to add an additional NIC and network, and configure WebLogic to use this NIC as well.

Sample Configuration: Figure 13-3 illustrates how you can physically separate network traffic.

Figure 13-3. Physically segmenting network traffic

Here we have a server with two NICs. The first is assigned the IP address 10.0.10.10, and the second is assigned 10.0.10.11. The intention is to get HTML traffic to flow through one NIC, while other traffic is to flow on the other NIC.

To create this setup, ensure that the default channel is configured for the NIC hosting the 10.0.10.10 IP address, and create a custom channel for the HTTP protocol, making sure that it is assigned the 10.0.10.11 IP address. All HTTP traffic will use the 10.0.10.11 NIC, while all T3 and other traffic will use the 10.0.10.10 NIC.

13.6.5.3 Separating internal and external traffic

Task: To physically separate internal server-to-server traffic from external client traffic. Server-to-server traffic occurs when one server communicates with another e.g., when a servlet needs to invoke a remote EJB method. Client-facing servers also are called edge servers, and typically use HTTP-based traffic in their communication with the clients.

Reason: A physical separation between client and server traffic improves the security of your domain. In addition, because the traffic flows on different NICs, you can guarantee different levels of throughput for the client and server traffic, if desired.

Sample Configuration: Figure 13-4 shows how we want to separate the client traffic from the internal server traffic.

Figure 13-4. Separating internal and external traffic

Here we have installed two NICs on the edge server, with IP addresses 10.0.10.10 and 10.0.10.11 assigned to the NICs. The 10.0.10.11 address will be exposed to the client. Now you need to perform the following tasks:

1. On Server1, configure the default channel to use the 10.0.10.10 IP address. Ensure that its Outgoing Enabled attribute is set to true, thereby allowing it to be used for interserver communication. Create a custom channel for the HTTP protocol to listen on the 10.0.10.11 IP address, and ensure that its Outgoing Enabled attribute is set to false, thereby disabling its use for interserver communication.
2. On Server2, configure a default channel in the usual way.

All client traffic will arrive on the 10.0.10.11 NIC, which is exposed to the public. If the edge server needs to call a method on a remote EJB, it will try and find a channel that supports outgoing connections. Because the custom channel is the only channel available that supports interserver communication, it will use the 10.0.10.10 NIC.