4 Configuring Network Resources

Oracle WebLogic Server configurable network resources such as network channels and domain-wide administration ports help you effectively use the network features of the machines that host your applications and manage quality of service.

Overview of Network Configuration

For many development environments, configuring WebLogic Server network resources is simply a matter of identifying a Managed Server listen address and listen port. However, in most production environments, administrators must balance finite network resources against the demands placed upon the network. The task of keeping applications available and responsive can be complicated by specific application requirements, security considerations, and maintenance tasks, both planned and unplanned.

WebLogic Server lets you control the network traffic associated with your applications in a variety of ways, and configure your environment to meet the varied requirements of your applications and end users. You can:

  • Designate the Network Interface Cards (NICs) and ports used by Managed Servers for different types of network traffic.

  • Support multiple protocols and security requirements.

  • Specify connection and message time-out periods.

  • Impose message size limits.

You specify these and other connection characteristics by defining a network channel—the primary configurable WebLogic Server resource for managing network connections. You configure a network channel in the WebLogic Server Administration Console (Servers > Protocols > Channels) or by using the NetworkAccessPointMBean.

Understanding Network Channels

Learn about network channels, the standard channels that WebLogic Server pre-configures, and common applications for channels.

What Is a Channel?

A network channel is a configurable resource that defines the attributes of a network connection to WebLogic Server. For instance, a network channel can define:

  • The protocol the connection supports.

  • The listen address.

  • The listen ports for secure and non-secure communication.

  • Connection properties such as the login time-out value and maximum message sizes.

  • Whether or not the connection supports tunneling.

  • Whether the connection can be used to communicate with other WebLogic Server instances in the domain, or used only for communication with clients.

Rules for Configuring Channels

Follow these guidelines when configuring a channel.

  • You can assign a particular channel to only one server instance.

  • You can assign multiple channels to a server instance.

  • Each channel assigned to a particular server instance must have a unique combination of listen address, listen port, and protocol.

  • You can configure a custom identity keystore, and other channel-specific SSL attributes, that are separate from and that override the default keystore and SSL configuration settings for the Managed Server instance or the domain.

  • If you assign non-SSL and SSL channels to the same server instance, make sure that they do not use the same port number.

Custom Channels Can Inherit Default Channel Attributes

If you do not assign a channel to a server instance, it uses the WebLogic Server default channel, which is automatically configured by WebLogic Server, based on the attributes in ServerMBean or SSLMBean; the operating system determines the network interface. The default channel is described in The Default Network Channel.

ServerMBean and SSLMBean represent a server instance and its SSL configuration. When you configure a server instance listen address, listen port, and SSL listen port, using the Server > Configuration > General page, those values are stored in the ServerMBean and SSLMBean for the server instance.

If you do not specify a particular connection attribute in a custom channel definition, the channel inherits the value specified for the attribute in ServerMBean. For example, if you create a channel, and do not define its listen address, the channel uses the listen address defined in ServerMBean. Similarly, if a Managed Server cannot bind to the listen address or listen port configured in a channel, the Managed Server uses the defaults from ServerMBean or SSLMBean.

Why Use Network Channels?

You use network channels to manage quality of service, meet varying connection requirements, and improve utilization of your systems and network resources. For example, network channels allow you to:

  • Segregate different types of network traffic—You can configure whether or not a channel supports outgoing connections. By assigning two channels to a server instance—one that supports outgoing connections and one that does not—you can independently configure network traffic for client connections and server connections, and physically separate client and server network traffic on different listen addresses or listen ports.

    You cannot create an outbound only network channel; there always has to be a corresponding inbound interface, port, and protocol associated with the channel. However, you can avoid directing your traffic to it or use a firewall to block it. Also remember that a custom channel is protocol specific, so you will need a network channel defined per protocol (HTTP, HTTPS, t3, t3s, and such). See, also NetworkAccessPointMBean.OutboundEnabled.

    You can also segregate instance administration and application traffic by configuring a domain-wide administration port or administration channel. See Administration Port and Administrative Channel.

  • Support varied application or user requirements on the same Managed Server—You can configure multiple channels on a Managed Server to support different protocols, or to tailor properties for secure versus non-secure traffic.

    By configuring a network channel to use a custom identity keystore, you can assert an identity on that channel that is different from the identity configured for the Managed Server or domain.

  • Segregate internal application network traffic—You can assign a specific channel to a an EJB.

If you use a network channel with a server instance on a multihomed machine, you must enter a valid listen address either in ServerMBean or in the channel. If the channel and ServerMBean listen address are blank or specify the localhost address (IP address 0.0.0.0 or 127.*.*.*), the server binds the network channel listen port and SSL listen ports to all available IP addresses on the multihomed machine. See The Default Network Channel for information on setting the listen address in ServerMBean.

Handling Channel Failures

When initiating a connection to a remote server, and multiple channels with the same required destination, protocol and quality of service exist, WebLogic Server will try each in turn until it successfully establishes a connection or runs out of channels to try.

Upgrading Quality of Service Levels for RMI

For RMI lookups only, WebLogic Server may upgrade the service level of an outgoing connection. For example, if a T3 connection is required to perform an RMI lookup, but an existing channel supports only T3S, the lookup is performed using the T3S channel.

This upgrade behavior does not apply to server requests that use URLs, since URLs embed the protocol itself. For example, the server cannot send a URL request beginning with http:// over a channel that supports only https://.

Standard WebLogic Server Channels

WebLogic Server provides pre-configured channels that you do not have to explicitly define.

  • Default channel—Every Managed Server has a default channel.

  • Administrative channel—If you configure a domain-wide administration port, WebLogic Server configures an administrative channel for each Managed Server in the domain.

The Default Network Channel

Every WebLogic Server domain has a default channel that is generated automatically by WebLogic Server. The default channel is based on the listen address and listen port defined in the ServerMBean and SSLMBean. It provides a single listen address, one port for HTTP (non-secure) communication (7001 by default), and one port for HTTPS (secure) communication (7002 by default). You can configure the listen address and listen port using the Configuration > General page in the WebLogic Server Administration Console; the values you assign are stored in attributes of the ServerMBean and SSLMBean.

The default configuration may meet your needs if:

  • You are installing in a test environment that has simple network requirements.

  • Your server uses a single NIC, and the default port numbers provide enough flexibility for segmenting network traffic in your domain.

Using the default configuration ensures that third-party administration tools remain compatible with the new installation, because network configuration attributes remain stored in ServerMBean and SSLMBean.

Even if you define and use custom network channels for your domain, the default channel settings remain stored in ServerMBean and SSLMBean, and are used if necessary to provide connections to a server instance.

Note:

Unless specified, WebLogic Server uses the non-secure default channel for cluster communication to send session information among cluster members. If you disable the non-secure channel, there is no other channel available by default for the non-secure communication of cluster session information. To address this, you can:

Administration Port and Administrative Channel

You can separate administration traffic from application traffic in your domain by defining an optional administration port. When configured, the administration port is used by each Managed Server in the domain exclusively for communication with the domain Administration Server. If an administration port is enabled, WebLogic Server automatically generates an administrative channel for your domain, based on the port settings upon server instance startup. The administrative channel provides a listen address and listen port to handle administration traffic.

Administration Port Capabilities

An administration port enables you to:

  • Start a server in standby state. This allows you to administer a Managed Server, while its other network connections are unavailable to accept client connections. See STANDBY State in Administering Server Startup and Shutdown for Oracle WebLogic Server.

  • Separate administration traffic from application traffic in your domain. In production environments, separating traffic ensures that critical administration operations (starting and stopping servers, changing a server's configuration, and deploying applications) do not compete with high-volume application traffic on the same network connection.

  • Administer a deadlocked server instance using WLST. If you do not configure an administration port, administrative commands such as threadDump and shutdown will not work on deadlocked server instances.

Administration Port Restrictions

The administration port accepts only secure, SSL traffic, and all connections via the port require authentication. Enabling the administration port imposes the following restrictions on your domain:

  • The Administration Server and all Managed Servers in your domain must be configured with support for the SSL protocol. Managed Servers that do not support SSL cannot connect with the Administration Server during startup—you will have to disable the administration port in order to configure them.

  • Because all server instances in the domain must enable or disable the administration port at the same time, you configure the administration port at the domain level. You can change an individual Managed Server administration port number, but you cannot enable or disable the administration port for an individual Managed Server. The ability to change the port number is useful if you have multiple server instances with the same listen address.

  • After you enable the administration port, you must establish an SSL connection to the Administration Server in order to start any Managed Server in the domain. This applies whether you start Managed Servers manually, at the command line, or using Node Manager. For instructions to establish the SSL connection, see Administration Port Requires SSL.

  • After enabling the administration port, all WebLogic Server Administration Console traffic must connect via the administration port.

  • If multiple server instances run on the same computer in a domain that uses a domain-wide administration port, you must either:

    • Host the server instances on a multihomed machine and assign each server instance a unique listen address, or

    • Override the domain-wide port on all but one of the servers instances on the machine. Override the port using the Local Administration Port Override option in the Advanced Attributes section of the Server > Connections > SSL Ports page in the WebLogic Server Administration Console.

Administration Port Requires SSL

The administration port requires SSL, which is enabled by default when you install WebLogic Server. If SSL has been disabled for any server instance in your domain, including the Administration Server and all Managed Servers, re-enable it using the Server > Configuration > General page in the WebLogic Server Administration Console.

Ensure that each server instance in the domain has a configured default listen port or default SSL listen port. The default ports are those you assign on the Server > Configuration > General page in the WebLogic Server Administration Console. A default port is required in the event that the server cannot bind to its configured administration port. If an additional default port is available, the server will continue to boot and you can change the administration port to an acceptable value.

By default WebLogic Server is configured to use demonstration certificate files. To configure production security components, follow the steps in Configuring SSL in Administering Security for Oracle WebLogic Server.

Configure Administration Port

Enable the administration port as described in Enabling the Domain-Wide Administration Port in Oracle WebLogic Server Administration Console Online Help.

After configuring the administration port, you must restart the Administration Server and all Managed Servers to use the new administration port.

Booting Managed Servers to Use Administration Port

If you reboot Managed Servers at the command line or using a start script, specify the administration port in the port portion of the URL. The URL must specify the https:// prefix, rather than http://, as shown below.

-Dweblogic.management.server=https://host:admin_port

Note:

If you use Node Manager for restarting the Managed Servers, it is not necessary to modify startup settings or arguments for the Managed Servers. Node Manager automatically obtains and uses the correct URL to start a Managed Server.

If the hostname in the URL is not identical to the hostname in the Administration Server's certificate, disable hostname verification in the command line or start script, as shown below:

-Dweblogic.security.SSL.ignoreHostnameVerification=true
Booting Managed Servers to Use Administrative Channels

To allow a Managed Server to bind to an administrative channel during reboot, use the following command-line option:

-Dweblogic.admin.ListenAddress=<addr>

This allows the Managed Server to startup using an administrative channel. After the initial bootstrap connection, a standard administrative channel is used.

Note:

This option is useful to ensure that the appropriate NIC semantics are used before config.xml is downloaded.

Custom Administrative Channels

If the standard WebLogic Server administrative channel does not satisfy your requirements, you can configure a custom channel for administrative traffic. For example, a custom administrative channel allows you to segregate administrative traffic on a separate NIC.

To configure a custom channel for administrative traffic, configure the channel as described in Configuring a Channel, and select "admin" as the channel protocol. Note the configuration and usage guidelines described in:

Using Internal Channels

Previous version of WebLogic Server allowed you to configure multiple channels for external traffic, but required you to use the default channel for internal traffic between server instances. WebLogic Server now allows you to create network channels to handle administration traffic or communications between clusters. This can be useful in the following situations:

  • Internal administration traffic needs to occur over a secure connection, separate from other network traffic.

  • Other types of network traffic, for example replication data, need to occur over a separate network connection.

  • Certain types of network traffic need to be monitored.

Channel Selection

All internal traffic is handled via a network channel. If you have not created a custom network channel to handle administrative or clustered traffic, WebLogic Server automatically selects a default channel based on the protocol required for the connection. See The Default Network Channel.

Internal Channels Within a Cluster

Within a cluster, internal channels can be created to handle to the following types of server-to-server connections:

  • Multicast traffic

  • Replication traffic

  • Administration traffic

See Configuring Network Channels For a Cluster.

Configuring a Channel

Use the WebLogic Server Administration Console or NetworkAccessPointMBean to configure a network channel.

From the console, navigate to Servers > Protocols > Channels page to configure the channel properties. To configure a channel for clustered Managed Servers see, Configuring Network Channels For a Cluster.

For a summary of key facts about network channels, and guidelines related to their configuration, see Guidelines for Configuring Channels.

Guidelines for Configuring Channels

Follow these guidelines when configuring a channel.

Channels and Server Instances
  • Each channel you configure for a particular server instance must have a unique combination of listen address, listen port, and protocol.

  • A channel can be assigned to a single server instance.

  • You can assign multiple channels to a server instance.

  • If you assign non-SSL and SSL channels to the same server instance, make sure that they do not use the same combination of address and port number.

Dynamic Channel Configuration
  • In WebLogic Server, you can configure a network channel without restarting the server. Additionally, you can start and stop dynamically configured channels while the server is running. However, when you shutdown a channel while the server is running, the server does not attempt to gracefully terminate any work in progress.

Channels and Identity
  • By default, when you configure a network channel, the channel uses the SSL configuration that is set for the server instance. This means that the channel uses the same identity and trust that is established for the server. The server might use a custom identity that is specific to that server, or it might be a single domain-wide identity, depending on how the server instance and domain are configured.

  • You can configure a network channel to use a custom identity keystore, and other SSL attributes, that are specific to that channel. This allows you to use an identity on that channel that is different from the one configured for the server. Using this capability, you can configure a server that can switch to a different identity when communicating with a particular client.

    See Configuring an Identity Keystore Specific to a Network Channel in Administering Security for Oracle WebLogic Server.

Channels and Protocols
  • Some protocols do not support particular features of channels. In particular the COM protocol does not support SSL or tunneling.

  • You must define a separate channel for each protocol you wish the server instance to support, with the exception of HTTP.

    HTTP is enabled by default when you create a channel, because RMI protocols typically require HTTP support for downloading stubs and classes. You can disable HTTP support on the Advanced Options portion of the Servers > Protocols > Channels page in the WebLogic Server Administration Console.

Reserved Names
  • WebLogic Server uses the internal channel names .WLDefaultChannel and .WLDefaultAdminChannel and reserves the .WL prefix for channel names. Do not begin the name of a custom channel with the string .WL.

Channels, Proxy Servers, and Firewalls

If your configuration includes a a firewall between a proxy Web server and a cluster (as described in Firewall Between Proxy Layer and Cluster in Administering Clusters for Oracle WebLogic Server), and the clustered servers are configured with two custom channels for segregating HTTPS and HTTP traffic, those channels must share the same listen address. Furthermore, if both HTTP and HTTPS traffic needs to be supported, there must be a custom channel for each—it is not possible to use the default configuration for one or the other.

If either of those channels has a PublicAddress defined, as is likely given the existence of the firewall, both channels must define PublicAddress, and they both must define the same PublicAddress.

Configuring Network Channels For a Cluster

To configure a channel for clustered Managed Servers, note the information in Guidelines for Configuring Channels, and follow the guidelines described in the following sections.

Create the Cluster

If you have not already configured a cluster you can:

  • Use the Configuration Wizard to create a new, clustered domain, following the instructions in Create a Clustered Domain in Administering Clusters for Oracle WebLogic Server, or

  • Use the WebLogic Server Administration Console to create a cluster in an existing domain, following the instructions Create and configure clusters in Oracle WebLogic Server Administration Console Online Help.

For information and guidelines about configuring a WebLogic Server cluster, see Before You Start in Administering Clusters for Oracle WebLogic Server.

Create and Assign the Network Channel

Use the instructions in Configuring a Network Channel in Oracle WebLogic Server Administration Console Online Help to create a new network channel for each Managed Server in the cluster. When creating the new channels:

  • For each channel you want to use in the cluster, configure the channel with the same name and protocol on each Managed Server in the cluster.

    Note:

    Failure to configure channel names and protocols identically on each server in a cluster can result in severe performance degradation when accessing RMI based objects. Examples of RMI based objects include JMS Connection Factories and EJB Homes.

    If an RMI object is obtained via a channel, and it attempts to connect to a server in a cluster that does not have a channel with the same name as the original channel, the object may then try to use the server's default channel. This might in turn result in unacceptable performance.

    While rare in practice, if the intent is to create similar but differently named channels within a cluster, then setting the server side property weblogic.rmi.t3.replicaList.customChannel.excludeDefaultChannels=true will result in RMI objects only attempting to accessing those channels with the exact specified name.

    Note that failure to name channels identically can result in severe performance degradation when accessing JMS or EJB remote objects.

  • Make sure that the listen port and SSL listen port you define for each Managed Server's channel are different than the Managed Server's default listen ports. If the custom channel specifies the same port as a Managed Server's default port, the custom channel and the Managed Server's default channel will each try to bind to the same port, and you will be unable to start the Managed Server.

  • If a cluster address has been explicitly configured for the cluster, it will be appear in the Cluster Address field on the Server > Protocols > Channels > Configuration page.

    If you are using dynamic cluster addressing, the Cluster Address field will be empty, and you do not need to supply a cluster address. For information about the cluster address, and how WebLogic Server can dynamically generate the cluster address, see Cluster Address in Administering Clusters for Oracle WebLogic Server.

    Note:

    If you want to use dynamic cluster addressing, do not supply a cluster address on the Server > Protocols > Channels > Configuration page. If you supply a cluster address explicitly, that value will take precedence and WebLogic Server will not generate the cluster address dynamically.

Configuring a Replication Channel

A replication channel is a network channel that is designated to transfer replication information between clusters. If a replication channel is not explicitly defined, WebLogic Server uses a default network channel to communicate replication information.

When WebLogic Server uses a default network channel as the replication channel, it does not use SSL encryption by default. You must enable SSL encryption using the secureReplicationEnabled attribute of the ClusterMBean. You can also update this setting from the WebLogic Server Administration Console.

Enabling SSL encryption can have a direct impact on clustered application throughput as session replication is blocking by design. in other words, no response is sent to the client until replication is completed. You should consider this when deciding to enable SSL on the replication channel.

If a replication channel is explicitly defined, the channel's protocol is used to transmit replication traffic.

Increase Packet Size When Using Many Channels

Use of more than about twenty channels in a cluster can result in the formation of multicast header transmissions that exceed the default maximum packet size. The MTUSize attribute in the Server element of config.xml sets the maximum size for packets sent using the associated network card to 1500. Sending packets that exceed the value of MTUSize can result in a java.lang.NegativeArraySizeException. You can avoid exceptions that result from packet sizes in excess of MTUSize by increasing the value of MTUSize from its default value of 1500.

Assigning a Custom Channel to an EJB

After you configure a custom channel, assign it to an EJB using the network-access-point element in weblogic-ejb-jar.xml, you can assign a custom channel to an EJB.

See network-access-point in Developing Enterprise JavaBeans, Version 2.1, for Oracle WebLogic Server.

Using IPv6 with IPv4

WebLogic Server supports host machines that are configured to use either Internet Protocol (IP) versions 4 or 6 (IPv4 and IPv6).

If you have a domain that includes some machines that use IPv4 in network communications and others that use IPv6, and the Administration Server is hosted on a machine using IPv4, the status of the Managed Server instances hosted on the machines using IPv6 might be displayed as "unknown" in the WebLogic Server Administration Console.

To make the status of these Managed Server instances available in the WebLogic Server Administration Console, you must specify a listen address for them. If your server is running, you will have to restart it after specifying the listen address. For information on assigning the listen address for a Managed Server in an existing domain using the WebLogic Server Administration Console, see Configure listen addresses in the Oracle WebLogic Server Administration Console Online Help.

You can also specify the listen address for your Managed Server when configuring it with the Configuration Wizard. On the Managed Servers page, enter the physical IP address of each Managed Server in the Listen Address field, save changes and continue configuring.