bea.com | products | dev2dev | support | askBEA

Download Docs | Site Map | Glossary
Search

Creating and Configuring WebLogic Server Domains

Configuring Network Resources

The following sections describe how to configure WebLogic Server network resources in a domain:

- Overview of Network Configuration

- Understanding the Default Network Configuration

- Using Network Channels and NAPs

- Configuring a Domain-Wide Administration Port

- Using a Custom Channel to Simplify Domain Administration

- Configuring Network Channels with a Cluster

- Using NAPs to Configure Multiple NICs with a Server

- Segmenting Network Traffic by Port Number

- Separating Internal and External Network Traffic

- Network Channel and NAP Attributes

Overview of Network Configuration

In BEA WebLogic Server 7.0 and later, you can use multiple Network Interface Cards (NICs) and/or multiple port numbers in your domain to improve performance and solve common networking problems. These capabilities allow you to:

- Separate administration traffic from application traffic in a domain.

- Improve network throughput by using multiple NICs with a single WebLogic Server instance.

- Designate specific NICs or multiple port numbers on a single NIC for use with specific WebLogic Server instances.

- Physically separate external, client-based traffic from internal, server-based traffic in a domain.

- Prioritize network connections that servers use to connect to other servers in a domain.

The instructions in this chapter describe how to configure domain network settings using the Administration Console. You can also configure these settings programmatically by using the specific MBeans described in each section.

New Network Configuration Features in WebLogic Server 7.0

Prior to WebLogic Server 7.0, a WebLogic Server instance could accept connections only from a single NIC, and the TCP port numbers that a given server instance used were restricted. The following table compares earlier TCP port restrictions with the network configuration features available in WebLogic Server 7.0.

Table 3-1 Network Feature Comparison

Version 6.x Restriction | Version 7.0 Capability
--- | ---
Each WebLogic Server instance listened on a single IP address. | A WebLogic Server instance can listen on multiple IP addresses.
A server can use a maximum of three distinct port numbers: A standard port reserved for non-secure HTTP, IIOP, and T3 traffic (7001 by default). A secure port reserved for HTTPS, IIOPS, and T3S traffic (7002 by default). An optional port used to isolate administration traffic. | You can assign multiple port numbers to a server by creating and assigning multiple network channels. For more information, see Network Channels.
Administration Console traffic could take place on any port available in the default network configuration. | After you configure and enable a separate, SSL port for administration traffic, all WebLogic Server instances in the domain must use the administration port for all Administration Console network traffic.
Different quality of service levels could not be mixed among the available port numbers. For example, you could not support HTTPS traffic on one port and IIOPS traffic on another, because all secure traffic was restricted to the same port (7002 by default). | Protocol support can be tailored to individual TCP ports using network channels. For more information, see Network Channels.
Many network configuration fields, such as login timeout and backlog configuration applied to the server itself (the server's listen address), rather than the port. Those configuration settings could not vary by port. | Each of the configured network channels can use different protocol configurations for their TCP ports. In addition, servers that use the channels can override many protocol settings using Network Access Points. For more information, see Network Channels and Network Access Points (NAPs).
In a cluster, the multicast port number was copied from each server's listen port setting. Because all members of a cluster must use the same multicast address and port number, the copied port number required all servers in a cluster to use the same listen port. | A cluster's multicast configuration is no longer tied to individual servers' network configuration. Instead, you configure the cluster multicast port number independently of the port numbers used by cluster members. You can also identify which NIC each clustered server should use for multicast communication.

Understanding the Default Network Configuration

WebLogic Server 7.0's network configuration capabilities give you increased control over the characteristics of network connections used for client and server-to-server network traffic. Based on your requirements, you can configure network channels and Network Access Points to manage performance.

You must configure your domain to take advantage of these capabilities. If you do not configure channels and NAPs, your domain's network configuration will be similar to the that supported by previous versions of WebLogic Server, as summarized in the "Version 6.x Restriction" column of Table 3-1. This simple configuration, which does not utilize the new network configuration capabilities of WebLogic Server 7.0, is referred to as the default network configuration. For each server instance, the default network configuration enables a single listen address, one port for HTTP communication (7001 by default), and one port for HTTPS communication (7002 by default). You can configure the listen address and port assignments using the Configuration->General tab in the Administration Console; the values you assign are stored in attributes of the ServerMBean and SSLMBean, as in previous WebLogic Server versions.

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.

Regardless of the configuration you perform, the settings associated with the default network configuration remain stored in ServerMBean and SSLMBean, and are used if if necessary to provide connections to a server instance.

Tailoring the Default Network Configuration

A server instance's default listen address, listen port, and network settings are defined in the its ServerMBean. You can change the default listen address, listen port, and default listen port connection properties using the following instructions:

1. Start the Administration Server for the domain if it is not already running.

2. Login to the Administration Console for the domain.

3. Select the Servers node in the left pane to display the server instances configured in the domain.

4. Select the name of the server instance you want to configure in the left pane.

5. Click the Configuration->General tab in the right pane to display the server instance's current default network settings:

6. Enter values for the default listen address and port as follows:

   - Listen Address—Enter the default IP address or DNS name the server instance uses to listen for incoming connections.

Notes: If you identify the server instance's Listen Address as localhost, non-local processes will not be able to connect to the server instance. Only processes on the machine that hosts the server instance will be able to connect to the server instance. If the server instance must be accessible as localhost (for instance, if you have administrative scripts that connect to localhost), and must also be accessible by remote processes leave the Listen Address blank. The server instance will determine the address of the machine and listen on it.

If the server instance resides on a multi-homed machine, do not leave the Listen Address field blank or specify the localhost address. If the server uses a localhost address, it will bind the Listen Port and SSL Listen Port to all available IP addresses on the multi-homed machine.

- Listen Port—Enter the default TCP port the server uses to listen for incoming connections.

1. Click Apply to apply your changes.

2. Click the Connections->Protocols tab in the right pane to define the default connection properties for the server:

3. Edit the default connection attributes on this page and click Apply to apply your changes. For information about individual attributes, see "Server --> Connections --> Protocols" in Administration Console Online Help.

4. Restart the server to use the new default network configuration.

Viewing the Default Configuration at Server Startup

As described in Understanding the Default Network Configuration, unless you configure the network configuration features new in WebLogic Server 7.0, your server instances will have a simple network configuration that adheres to the restrictions that applied in previous versions of WebLogic Server. As in previous versions of WebLogic Server, this basic network configuration information is stored using ServerMBean and SSLMBean.

One of the new network configuration capabilities of WebLogic Server 7.0 is the ability to configure network channels. A network channel allows you to assign multiple port numbers to a server instance. Network channels and their capabilities are described in Network Channels

At startup, WebLogic Server automatically generates a "default" network channel using the listen address and port attributes defined in the ServerMBean.

A server's default network configuration is shown in its log file following the line:

Network Channel: Default

as shown in this log file excerpt:

>     ####<Apr 22, 2002 10:49:36 AM PDT> <Info> <RJVM> <myhostname>
>     <examplesServer> <main> <kernel identity> <> <000520> <Network Configuration
>     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,COM
>     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 COM:     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 COM:    10000000
>     Max Message Size IIOP:   10000000
>     >

Later in the log file, you can see the actual listen addresses and ports to which the server binds:

>     ####<Apr 22, 2002 10:58:52 AM PDT> <Notice> <WebLogicServer>
>     <myhost> <examplesServer> <SSLListenThread.Default> <kernel
>     identity> <> <000354> <Thread "SSLListenThread.Default" listening
>     on port 7002>

>     ####<Apr 22, 2002 10:58:52 AM PDT> <Info> <WebLogicServer> <myhost>
>     <examplesServer> <ListenThread.Default> <kernel identity> <>
>     <000213> <Adding address: myhost/192.168.1.11 to licensed client
>     list>

Using Network Channels and NAPs

WebLogic Server 7.0 introduces two new configurable network resources that you can administer using either the Administration Console or WebLogic Server MBeans: network channels and Network Access Points (NAPs). These resources are stored in two new MBeans: NetworkChannelMBean and NetworkAccessPointMBean.

The listen address and port number attributes from ServerMBean are also used in certain circumstances. For example,

- if you do not define a Listen Address using a NAP, the Listen Address defined in ServerMBean is used.

- if you configure a domain-wide administration port, and for some reason a Managed Server cannot bind to its configured administration port, the default listen port from ServerMBean or SSLMBean is used.

The following sections describe the features provided by network channels and Network Access Points.

Network Channels

Network Channels enable you to configure additional port numbers and protocol settings for use with one or more WebLogic Server instances.

These port numbers are in addition to the default port numbers associated with ServerMBean and SSLMBean (described in Understanding the Default Network Configuration).

A network channel defines the basic attributes of a network connection to WebLogic Server including:

- The protocols the connection supports (HTTP, HTTPS, T3, T3S, COM).

- Default listen ports to use for secure and non-secure communication.

- Default properties for the connection such as the login timeout 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.

You configure network channels as distinct entities in the Administration Console, and then assign one or more channels to servers in a domain. The server instances to which you assign a channel use the port numbers and protocol configuration associated with the channel, instead of the default network configuration.

Note: Messages sent via the T3 can contain DNS information about the hosts they originate on or are destined to. If a T3 connection is established across a firewall that has network address translation (NAT) enabled, it is possible that some information about the network configuration behind the firewall will be revealed. Using the firewall to prevent T3 connections through the firewall will prevent this problem.

Configuring Outgoing Connections

In addition to defining the connection attributes, channels allow you to separate incoming client traffic from internal, server-to-server traffic in the domain.

Each channel definition specifies whether or not the channel supports outgoing connections (supported by default). By assigning two channels to a server instance—one with support for outgoing connections and one without—you can independently configure network traffic for client connections and server connections. By combining the channels with multiple NAPs (see Network Access Points (NAPs)), you can also physically separate client and server network traffic onto different IP addresses or port numbers.

Channels also enable you to prioritize the connections that are used for outbound network traffic. If a server instance has several outbound-capable channels assigned, you can prioritize each channel with a weighted value. When the server instance initiates an outgoing connection, the NAPs assigned to channels with a higher-weighted value are used before those with lower-weighted channels. You can use this functionality to ensure that all server-to-server traffic has a guaranteed level of throughput, by assigning the highest weighting to an outbound channel/NAP combination that utilizes a fast NIC.

Note: Network channel weights apply only to internal connections made for remote references, such as a remote EJB reference or a resource located via JNDI. Channel weights are not used for connections initiated directly via a URL.

Common WebLogic Server Channels

Channels can be used to accomplish a variety of network configuration goals. Most WebLogic Server installations use one or more of the following common types of channels:

- "Default" Channel—WebLogic Server automatically generates a default channel to describe the listen address and listen port settings associated with the ServerMBean. You can view the default channel configuration during server startup, as described in Viewing the Default Configuration at Server Startup.

- Administration Channel—You can define an optional administration port to use for separating administration traffic from application traffic in your domain. When you enable the administration port, WebLogic Server automatically generates an Administration Channel based on the port settings. See Configuring a Domain-Wide Administration Port for more information.

- Custom Channels—A custom channel is a channel that you define and apply in a domain (rather than a channel that WebLogic Server automatically generates). See Common Uses for Network Channels and NAPs for examples of how to use custom channels in your domain.

Network Access Points (NAPs)

A Network Access Point (NAP) is a resource you can configure to assign the port numbers, protocol configuration, and optionally, IP address to be used with a network channel on a server. A NAP is only used in conjunction with a network channel, and only one NAP can be assigned to each channel on a server instance.

You can use NAPs to override certain network channel attributes on a specific WebLogic Server instance, or to associate a server's network channel with a specific IP address or NIC.

A NAP is optional. If you configure a server instance to use a Network Channel but do not configure a NAP, the server uses the network configuration associated with the channel. Because the channel itself does not specify a listen address, the new connection uses the listen address associated with the server's default network configuration (the listen address defined in ServerMBean).

If you do specify a NAP with a network channel on a server, the channel uses the listen address identified in the NAP (if one is defined) to generate a new network connection. The NAP may also override certain protocol and network configuration settings of the underlying network channel to tailor the connection on this server. Network Channel and NAP Attributes lists the attributes of Network Channels and NAPs, and explains which channel attributes a NAP can override.

Warning: If you use a network channel with a server that resides on a multi-homed machine, you must enter a valid listen address either in ServerMBean or in a NAP associated with the server. If the NAP and ServerMBean listen address are blank or specify the localhost address (IP address 0.0.0.0 or 127.*.*.*), the server will bind the network channel listen port and SSL listen ports to all available IP addresses on the multi-homed machine. See Understanding the Default Network Configuration for information on setting the listen address in ServerMBean.

Common Uses for Network Channels and NAPs

WebLogic Server uses an automatically-generated channel when you configure an Administration Port in a domain. See Configuring a Domain-Wide Administration Port for more information.

Using a single custom channel with multiple servers simplifies network configuration for a domain—changing a channel configuration automatically changes the connection attributes of all servers that use the channel. See Using a Custom Channel to Simplify Domain Administration for instructions on configuring and applying a channel.

You can also create and assign multiple channels to a single server. Using multiple channels helps you segment network traffic by protocol, listen ports, or any other channel configuration property. For example, you can use two channels with a single server to tailor the default connection properties for secure vs. non-secure traffic. You can also use multiple channels to separate external, client traffic from internal, server-to-server traffic. See Segmenting Network Traffic by Port Number for a simple example of using multiple channels. See Separating Internal and External Network Traffic for an example of using channels to configure outgoing connections.

You can also override many channel properties on a per-server basis by configuring an associated Network Access Point. See Using NAPs to Configure Multiple NICs with a Server for an example of using a NAP.

Configuring a Domain-Wide Administration Port

In WebLogic Server 7.0, you can enable an administration port for Managed Servers in a domain. An administration port is a port that a Managed Server uses only for communications with the domain's Administration Server.The administration port is optional, but it provides two important capabilities:

- It enables you to start a server in standby state. While in the standby state, the administration port remains available to activate or administer the Managed Server, although the server's other network connections are unavailable to accept client connections. See "Starting and Stopping WebLogic Server" in the Administration Guide for more information on the standby state.

- It enables you to separate administration traffic from application traffic in your domain. In production environments, separating the two forms of 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.

WebLogic Server implements the administration port by generating an administration channel when the Managed Server starts up.

Administration Port Restrictions

The administration port accepts only secure, SSL traffic, and that all connections via the port require authentication. Because of these features, 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 will be unable to connect with the Administration Server during startup—you will have to disable the administration port in order to configure those servers.

- 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's administration port number, but you cannot enable or disable the administration port for an individual Managed Server.

- 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. To establish the SSL connection, use the following startup arguments:

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

  Note: You cannot simply supply a hostname and port combination as with previous server releases; the HTTPS protocol is required.

  >     -Dweblogic.security.SSL.trustedCAKeyStore=path_to_keystore

  >     -Dweblogic.security.SSL.ignoreHostnameVerification=true

- After enabling the administration port, all Administration Console traffic must connect via the administration port. (Prior to WebLogic Server 7.0, Administration Console traffic could connect using any available server 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 multi-homed machine and assign each server instance a unique listen address, or

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

Administration Port Configuration and Startup

Before you enable the administration port,

- Enable the SSL protocol on each server instance in your domain, including the Administration Server and all Managed Servers, using the Connections->SSL Ports tab in the Administration Console. Follow the steps in "Configuring the SSL Protocol" in Managing WebLogic Security to obtain SSL security components and configure Administration Server to use SSL, or use the demo certificate files installed by default with new servers.

- Make sure that each server in the domain has a configured default listen port or default SSL listen port. (See Tailoring the Default Network Configuration for more information.) 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.

After performing these prerequisites, follow these steps to enable the administration port:

1. Start the Administration Server for the domain if you have not already done so.

2. Login to the Administration Console.

3. Click the name of your domain in the left pane to display the domain's configuration properties.

4. Click the Configuration->General tab in the right pane.

5. Select the Enable Domain Wide Administration Port (Please configure SSL) checkbox in the right pane.

6. Enter a value in the Domain Wide Administration Port attribute field to specify the default administration port all servers will use. By default, the domain-wide administration port is set to 9002.

7. Click Apply to apply your changes to the domain.

8. If you want to use the same administration port with all servers in the domain, skip to step 13 now.

9. To change the administration port that an individual server in the domain uses, select the Servers node in the left pane, then select the name of the server you want to configure.

10. Click the Connections->SSL Ports tab in the right pane to display the server's current SSL configuration.

11. Enter a value in the Local Administration Port Override: (0: no override) attribute field to specify the administration port this server uses to communicate with the administration console. A value of zero indicates that the server uses the domain wide administration port value you specified in step 6.

    Note: Choose a well-known, unused port number for the administration port on the Administration Server. All Managed Servers in the domain need to specify this port in order to start up in the domain.

12. Click Apply to apply your changes.

13. Reboot the Administration Server and all Managed Servers to use the new administration port.

    When rebooting the Managed Servers in the domain, you must specify the following options at the command line (or in the server start script) to connect to the Administration Server's administration port:

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

    >     -Dweblogic.security.SSL.trustedCAKeystore=path_to_keystore

    >     -Dweblogic.security.SSL.ignoreHostnameVerification=true

Viewing the Administration Channel at Server Startup

If you enable the Administration Port in a server's default network configuration, the server uses the listen address setting from the ServerMBean and SSL configuration settings from the SSLMBean to generate an "administration channel" for use with the server. The administration channel settings are similar to those of the default channel, except that the non-secure listen port settings are absent. The following log file excerpt shows default administration port setup:

>     Network Channel:         Administrator
>     Listen Address:          172.17.10.55
>     Listen Port:             none
>     SSL Listen Port:         9002
>     External DNS Name:       not configured
>     Cluster Address:         not configured
>     Protocol(s):             T3S,HTTPS
>     Tunneling Enabled:       false
>     Outgoing Enabled:        true
>     Admin Traffic Only:      true
>     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
>     Max Message Size HTTP:   10000000
>     Max Message Size T3:     10000000
>     >

>     ...

>     ####<Apr 22, 2002 3:14:34 PM PDT> <Notice> <WebLogicServer>
>     <myhost> <adminserver> <SSLListenThread.Administrator> <kernel
>     identity> <> <000355> <Thread "SSLListenThread.Administrator"
>     listening on port 9002, ip address 192.168.1.11>

Using a Custom Channel to Simplify Domain Administration

Network channels can simplify domain network administration by serving as a template for WebLogic Server connection properties. For example, the figure below shows a domain that utilizes a single custom channel to define the connection characteristics for all network traffic for all servers.

Figure 3-1 Using a Custom Network Channel

In this example, a network channel named BasicChannel is configured as follows:

- ListenPort is set to the default of 8001

- SSLListenPort is set to the default of 8002

- All network protocols are enabled for this channel.

The administrator has added BasicChannel to every server instance in the domain.

This sample domain does not use NAPs. Instead, the listen address for each server is obtained from the ListenAddress attribute in each server's ServerMBean. The channel specify default port numbers for secure and non-secure traffic, which open new ports in addition to those specified the servers' ServerMBean attributes.

During the testing phase for applications in this domain, the administrator can set default values for all protocols supported for this channel. As the domain is opened up to additional beta testers, the administrator can fine tune connection timeouts and maximum message sizes as needed by making a single change to BasicChannel.

Configuring a Custom Network Channel

To configure a network channel, refer to Network Channel and NAP Attributes and follow these steps:

1. Start the Administration Console for the domain that contains the server you want to configure.

2. Select the Network Channels node in the left pane of the Administration Console.

3. Click Configure a new Network Channel... in the right pane.

4. Enter the attribute values for the new network channel and click Create to create the new channel definition.

   Note: WebLogic Server uses the internal channel names .WLDefaultChannel and .WLDefaultAdminChannel and reserves the .WL prefix for channel names. You cannot create a custom channel that begins with .WL.

5. Select the Configuration->Tuning tab to change the backlog and timeout attributes for the new channel. Click Apply to apply your changes to this tab.

6. Select the Configuration->Protocols tab to enable, disable, or configure protocol support for the new channel. Click Apply to apply your changes to this tab.

7. After you configure the new network channel properties, select the Targets->Servers or Targets->Clusters tab to select the servers or clusters in the domain that will use the new channel. Select a server or cluster in the Available column, and use the arrow button to place the server or cluster in the Chosen column.

8. Click Apply to assign the network channel to the chosen servers or clusters.

9. To use the new channel port designations, you must reboot any servers that you assigned as targets.

Using NAPs to Configure Multiple NICs with a Server

By default, a newly configured WebLogic Server instance uses only the single ListenAddress, ListenPort, and SSLListenPort attribute associated with its ServerMBean and SSLMBean. However, in domains where application performance is network-bound, rather than server-bound, it may be desirable to configure a single WebLogic Server instance with multiple NICs (or with the multiple IP addresses provided by multihomed hardware).

To utilize multiple NICs or multihomed hardware with a single server, you must override the default ServerMBean configuration by setting up multiple network channels and multiple associated NAPs. In such a configuration, NAPs segment incoming network traffic by identifying individual NICs to use with the server. The channels provide the baseline network configuration for each NAP.

For example, in the sample domain shown in the following figure, each server instance listen on two separate NICs. On each server instance, one NIC is reserved for standard network traffic, and the other is used for secure traffic

Figure 3-2 Using Network Access Points

To create this configuration, the administrator configured two channels—StandardChannel and SecureChannel—and assigned both channels to both server instances. To segment secure and non-secure traffic, the two channels were configured as follows:

- StandardChannel enables the HTTP and T3 protocols, but disables HTTPS and T3S. This channel uses the ListenPort and SSListenPort values of 8001 and 8002, although the SSL port is unused.

- SecureChannel enables the HTTPS and T3S protocols, but disables HTTP and T3. This channel uses the ListenPort and SSListenPort values of 8001 and 8002, although the standard ListenPort is unused.

Four NAPs were configured—one for each NIC in the domain. For WebLogic Server A, NAP_A1 was configured with listen address 192.168.1.500, and assigned to StandardChannel. NAP_A2 was created with listen address 192.168.1.501, and assigned to SecureChannel.

For WebLogic Server B, NAP_B1 and NAP_B2 were configured in a similar manner, but using IP addresses 192.168.1.600 and 192.168.1.601.

For both servers, the administrator accepted the default ListenPort and SSLListenPort values associated with the available channels. Note, however, that the port numbers could vary by NIC, if unique port numbers were defined in the associated NAPs.

Configuring a Network Access Point

You can configure a network access point for a server only after you have configured a network channel and assigned it to the server, using the instructions in Configuring a Custom Network Channel.

Follow these steps to configure a server's network access points. See NAP Attributes for more information about individual attributes.

1. Start the Administration Console for the domain, if it is not already running.

2. In the left pane, select the Servers node, then select the server name you want to configure.

3. In the right pane, select the Configuration->Tuning tab to display the current backlog and tunneling settings for the server's default network configuration.

4. At the bottom of the right pane, click Configure Channel Fine Tunings... to display a table listing all network channels currently assigned to the server.

5. Click the name of the network channel for which you want to create a network access point. This displays a Configuration tab that allows you to override attributes of the selected channel.

6. Select the Configuration->General tab to override channel attributes such as the listen address or listen ports, then click Apply.

7. Select the Configuration->Tuning tab to override channel attributes for backlog and timeout settings, then click Apply.

8. Select the Configuration->Protocols tab to override channel configurations for supported network protocols, then click Apply.

   Note: You cannot enable or disable a network protocol from within the Network Access Point—only the network channel can enable or disable protocol support.

Configuring Network Channels with a Cluster

To use one or more custom channels with a WebLogic Server cluster, follow the guidelines described in the sections that follow.

If you do not intend to use custom channels with a WebLogic Server cluster, follow the instructions in "Setting up WebLogic Clusters" in Using WebLogic Server Clusters to set up your cluster.

Create Managed Servers

Use the Administration Console to create all Managed Servers that will participate in the cluster. Configure each Managed Server's listen address and listen ports as described in Tailoring the Default Network Configuration.

Managed Servers in a cluster require a default listen address and listen port to generate a default channel for the server. The custom channel you will add to the cluster is used in addition to the default channel, and its properties are applied to all members of the cluster.

Create the Cluster

Use the Administration Console to create a new cluster in the domain, as described in the Administration Console online help. When creating the cluster:

- Select an unused multicast address and enter that address in the Configuration->Multicast tab for the new cluster.

  For information about how Managed Servers in a cluster use multicast communications, and guidelines for setting the multicast address, see "One-to-Many Communication Using IP Multicast" in Using WebLogic Server Clusters.

- You do not need to enter a cluster address in the Configuration->General tab for the new cluster, if you will later apply a network channel to the cluster. The network channel has a Cluster Address attribute for specifying the address.

- Use the Servers tab to add Managed Servers to the new cluster. In a production environment, the Administration Server should not participate in a cluster.

Create and Assign the Network Channel

Use the instructions in Configuring a Custom Network Channel to create a new network channel for use with the cluster. When creating the new channel:

- Make sure that the new channel's listen port and SSL listen port do not use the same values as the clustered servers' default ports. If the network channel specifies the same port as a Managed Server's default port, the custom network 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.

- Enter a Cluster Address value on the new channel's Configuration->General tab. The cluster address should be a publicly-available address that identifies all managed servers in the cluster (for example, a DNS name that resolves to all IP addresses participating in the cluster). The network channel uses this value to generate EJB handles and failover addresses for use with the cluster.

  If you do not specify a cluster address in the network channel, the cluster will use the Cluster Address value specified in the cluster definition, if available.

- After creating the new channel, use the channel's Targets->Cluster tab to choose the cluster you created in Create the Cluster.

Define Multicast Address for each Server Instance

You can optionally designate which NIC each server in the cluster uses for multicast traffic. If you do not specify a multicast address for a server instance, it will use the multicast address you defined for the cluster in Create the Cluster

Follow these steps:

1. Start the Administration Console for the domain, if it is not already running.

2. In the left pane, select the Servers node, then select the server name you want to configure.

3. In the right pane, select the Configuration->Cluster tab.

4. In the Interface Address attribute field, enter the IP address of the NIC the server should use for multicast traffic.

5. Click Apply to apply your changes.

Segmenting Network Traffic by Port Number

You can use NAPs and channels to segment network traffic by port numbers. For example, if a WebLogic Server in your domain is not network bound, you may choose to use a single NIC with the server but configure multiple port numbers to direct connections to multiple physical servers in the domain. Using NAPs allows you to configure more port numbers than the standard three port numbers available in the ServerMBean.

In the sample domain below, the administrator has configured multiple NAPs to utilize a single NIC with three different server instances:

Figure 3-3 Segmenting Network Traffic

In this example, a single NIC is used to segment network connections to multiple servers. BasicChannel is used in conjunction with multiple NAPs to handle connections over unique port numbers.

All servers in the sample domain use the default NIC IP address, 192.168.1.600. However, each server uses a NAP to listen on different port numbers of the same IP address. Notice that while the BasicChannel configuration uses the port numbers 8001 and 8002, the NAP on each server overrides those port assignments.

You can use similar network configurations, in conjunction with load balancers, to distribute connection requests to multiple WebLogic Server instances in a cluster.

Separating Internal and External Network Traffic

A more specialized use of network channels and NAPs involves separating client-oriented, external network traffic from server-oriented, internal traffic. You may want to separate internal and external traffic in certain firewall configurations, or to guarantee different levels of throughput for servers and clients.

Configuring Edge Servers

An "edge" server is a WebLogic Server instance that external clients use to initiate contact with a Web application. Although components of the Web application may reside on other WebLogic Servers in the domain, direct client access is restricted to the edge server.

For example, you may deploy a servlet or JSP on a single WebLogic Server in your domain, and make that server's IP address available to external clients. The servlet or JSP may interact with a second server in the domain to obtain EJBs or other services. However, the WebLogic Server that hosts the EJBs is not made available to external clients. Instead, clients interact with EJBs only via the edge server itself. The following figure depicts a simple edge server configuration.

Figure 3-4 Edge Servers

Note: A WebLogic Server domain can contain any number of edge servers. Edge servers can be stand-alone Managed Servers, or be configured as cluster. See "Recommended Multi-Tier Architecture" in Using WebLogic Server Clusters for information about configuring a cluster of edge servers.

Network channels help you separate external, client-based network connections from internal, server-based connections with edge server configurations. The separation of network traffic can be either logical (separated by port numbers of a single NIC), or physical (separated by different NICs and IP addresses).

The following figure shows a simple edge server configuration that uses one NIC for internal traffic and another for external network traffic.

Figure 3-5 Simple Edge Server Configuration

In this example, the two servers uses the same channel, AppChannel, to communicate with each other. The OutgoingEnabled attribute is enabled in AppChannel to provide two-way communication between the servers.

The EdgeServer in this domain also uses a separate channel, ClientChannel, to handle network connections from Web application clients. The OutgoingEnabled attribute is disabled in ClientChannel; this forces EdgeServer to use the AppChannel as well as its associated NIC to initiate connections to SupportServer.

Tracing the network traffic through this configuration:

1. A client connects to EdgeServer over the public IP address, 192.168.1.500, defined in the associated NAP on EdgeServer. This NAP uses the connection properties in ClientChannel.

2. The client accesses the servlet on EdgeServer, which in turn looks up an EJB that resides in SupportServer.

3. To initiate the network connection and access the EJB, EdgeServer requires a channel that support outgoing connections. In this configuration only AppChannel supports outgoing connections, so it is used for communication with SupportServer.

4. Because AppChannel has an associated NAP on EdgeServer, the NAP's IP address of 192.168.1.505 is used for communication with SupportServer. This physically separates the internal network connection from the connection the client used to access the Web application.

Network configuration at the WebLogic Server domain level can be combined with firewall hardware or software to block access to supporting servers.

Prioritizing Outgoing Connections

If a WebLogic Server has several channels capable of initiating outgoing connections, the server must choose which channel to use when connecting to another server. WebLogic Server first selects channels based on the protocol required for the connection. If multiple channels have the same protocol support, you can prioritize those channels by assigning a different weight to each.

A channel weight is a simple numerical value that can be applied to the NetworkChannelMBean. Channel weights are considered only when multiple channels with the same service level could be used to initiate an outgoing connection. (If a channel with a higher service level is currently active, it is used regardless of channel weights). Higher-valued weights are selected over lower-weighted channels to choose a NAP for outgoing connections.

In a multihomed system, channel weights allow you to prioritize equivalent channels based on the known capacity of available network cards.

Note: The default channel and administration channel, derived from values in the ServerMBean and SSLMBean, are always considered for outgoing connections, and use a default weight of 50.

Handling Channel Failures

Although WebLogic Server always attempts to use the highest-weighted channels before lower-weighted ones, a network failure may render the selected channel unavailable. To handle potential failures, WebLogic Server selects outgoing channels using the following algorithm:

1. WebLogic Server first tries the highest-weighted channel having the required quality of service.

2. If a connection cannot be made using the highest-weighted channel, WebLogic Server tries the next-highest weighted channel with the required quality of service.

3. If the connection request fails again, the server continues the connection attempt using lower-weighted channels, until all channels have been attempted.

4. If the server cannot connect using any available channel, a failure message is returned to the calling user.

The above procedure ensures that users receive a connection error message only when all channels of the required quality of service level have been exhausted. If all channel combinations are exhausted and another user attempts to initiate an outgoing connection (or a connection is retried after a failure), WebLogic Server restarts the above algorithm beginning with the highest-weighted channel.

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://.

Network Channel and NAP Attributes

The following sections list the attributes available in a NetworkChannelMBean and NetworkAccessPointMBean, and explain which NAP attributes can override their channel counterparts.

Channel Attributes

A channel is represented in a WebLogic Server domain as a NetworkChannelMBean. This MBean consists of the configuration attributes described in the following table. Values of highlighted attributes can be overridden by specifying a complementary value in the channel's associated NetworkAccessPointMBean using the Administration Console. See NAP Attributes for more information about overriding channel properties.

Table 3-2 Network Channel Configuration Attributes

MBean Attribute Name | Default Value | Possible Values | Description
--- | --- | --- | ---
Name* | None | String | The name used to identify this channel in the console. WebLogic Server uses the internal channel names .WLDefaultChannel and .WLDefaultAdminChannel and reserves the .WL prefix for channel names. You cannot create a custom channel that begins with .WL.
Description | None | String | Optional text notes describing this channel.
ChannelWeight* | 50 | 1-100 | The relative weight to assign to this channel when selecting channels for outgoing connections. See Prioritizing Outgoing Connections for more information.
ListenPortEnabled | False | True, False | Specifies whether this channel provides a plain text listen port.
ListenPort* | 8001 | 1-65534 | The default listen port to use for non-secure network protocols.
SSLListenPortEnabled | False | True, False | Specifies whether this channel provides an SSL listen port.
SSLListenPort* | 8002 | 1-65534 | The default listen port to use for secure network protocols.
COMEnabled | False | True, False | Specifies whether this channel provides a plain text (non-SSL) port for COM traffic.
ClusterAddress | None | String | The address that this channel uses to generate EJB handles and failover addresses for use in a cluster
TunnelingEnabled* | False | True, False | Specifies whether this network channel supports tunneling. To enable tunneling for a network channel, you must also enable the HTTP and T3 protocols for the channel by setting the attributes: HTTP(S) Enabled=true T3(S) Enabled=true Although T3 is required for enabling tunneling, the T3 protocol is hidden from clients that use a tunneling connection. For general information about tunneling, see Setting Up WebLogic Server for HTTP Tunneling in the Administration Guide.
T3 Enabled* | False | True, False | Enables or disables the protocol.
T3S Enabled* | False | True, False | Enables or disables the protocol.
HTTP Enabled* | False | True, False | Enables or disables the protocol.
HTTPS Enabled* | False | True, False | Enables or disables the protocol.
OutgoingEnabled* | True | True, False | Specifies whether this channel can initiate outbound connections to other WebLogic Servers in the domain.
LoginTimeoutMillis | 5000 | 0 (Disabled), 1-100000 | Sets the number of milliseconds that WebLogic Server should wait for a connection before timing out.
LoginTimeoutMillisSSL | 25000 | 0 (Disabled), 1-2147483647 | Sets the number of milliseconds that WebLogic Server should wait for an SSL connection before timing out.
AcceptBacklog* | 50 | 0-2147483647 | Sets the number of connections available for backlog. To increase the number of connections to be processed, increase this number.
TunnelingClientPingSecs* | 45 | 0-2147483647 | Sets the time, in seconds, that the server will wait before pinging the client.
TunnelingClientTimeoutSecs* | 40 | 0 (Disabled) 1-2147483647 | Sets the time, in seconds, that the server will wait before timing out.
MaxT3MessageSize | 10000000 | 4096- 2000000000 | Sets the size, in bytes, of the maximum T3 message.
MaxHTTPMessageSize | 10000000 | 4096- 2000000000 | Sets the size, in bytes, of the maximum HTTP message.
MaxCOMMessageSize | 10000000 | 4096- 2000000000 | Sets the size, in bytes, of the maximum COM message.
CompleteT3MEssageTimeout | 60 | 0 (Disabled), 1-480 | The amount of time, in seconds, before the system times out while waiting to receive a T3 message.
CompleteHTTPMessageTimeout | 60 | 0 (Disabled), 1-480 | The amount of time, in seconds, before the system times out while waiting to receive an HTTP message.
CompleteCOMMessageTimeout | 60 | 0 (Disabled), 1-480 | The amount of time, in seconds, before the system times out while waiting to receive a COM message.

* Indicates the attribute is not dynamically configurable (requires server restart for changes to take effect).

NAP Attributes

A NAP is represented in a WebLogic Server domain as a NetworkAccessPointMBean. This MBean consists of the configuration attributes described in the following table. Note that many of the MBean attributes have counterparts in the NetworkChannelMBean described in Network Channel and NAP Attributes. When a NAP is assigned to a channel, it can potentially override the channel attribute values, as described below.

Table 3-3 Network Access Point (NAP) Configuration Attributes

MBean Attribute Name | Default Value | Possible Values | Description
--- | --- | --- | ---
ListenAddress* | Null | String host name or IP address | The IP address or DNS name this NAP uses to listen for incoming connections. If this attribute is null, the NAP uses the value of the ListenAddress attribute specified in the associated server's ServerMBean. (If no value is specified in ServerMBean, WebLogic Server listens to the localhost address.) Note: To resolve a DNS name to an IP address, Weblogic Server must be able to contact an appropriate DNS server or obtain the IP address mapping locally. Therefore, if you specify a DNS name for the listen address, you must either leave a port open long enough for the WebLogic Server instance to connect to a DNS server and cache its mapping or you must specify the IP address mapping in a local file. If you specify an IP address for ListenAddress and then a client request specifies a DNS name, WebLogic Server will attempt to resolve the DNS name, but if it cannot access DNS name mapping, the request will fail.
ListenPort* | -1 | -1 1-65534 | -1 forces the NAP to use the value defined in the associated NetworkChannelMBean. Setting any other value overrides the value defined in the associated NetworkChannelMBean. See the ListenPort channel attribute description for more information.
SSLListenPort* | -1 | -1 1-65534 | -1 forces the NAP to use the value defined in the associated NetworkChannelMBean. Setting any other value overrides the value defined in the associated NetworkChannelMBean. See the SSLListenPort channel attribute description for more information.
LoginTimeoutMillis | -1 | -1 0 1-100000 | -1 forces the NAP to use the attribute value defined in the NAP's NetworkChannelMBean. Setting any other value overrides the attribute value defined in the NAP's NetworkChannelMBean; 0 disables timeouts. See Network Channel and NAP Attributes for more information about this attribute.
LoginTimeoutMillisSSL | -1 | -1 0 1- 2147483647 | -1 forces the NAP to use the attribute value defined in the NAP's NetworkChannelMBean. Setting any other value overrides the attribute value defined in the NAP's NetworkChannelMBean; 0 disables timeouts. See Network Channel and NAP Attributes for more information about this attribute.
AcceptBacklog* | -1 | -1 0 1-2147483647 | -1 forces the NAP to use the attribute value defined in the NAP's NetworkChannelMBean. Setting any other value overrides the attribute value defined in the NAP's NetworkChannelMBean; 0 disables backlog. See Network Channel and NAP Attributes for more information about this attribute.
TunnelingClient PingSecs* | -1 | -1 0 1-2147483647 | -1 forces the NAP to use the attribute value defined in the NAP's NetworkChannelMBean. Setting any other value overrides the attribute value defined in the NAP's NetworkChannelMBean; 0 disables client pings. See Network Channel and NAP Attributes for more information about this attribute.
TunnelingClient TimeoutSecs* | -1 | -1 0 1-2147483647 | -1 forces the NAP to use the attribute value defined in the NAP's NetworkChannelMBean. Setting any other value overrides the attribute value defined in the NAP's NetworkChannelMBean; 0 disables the timeout. See Network Channel and NAP Attributes for more information about this attribute.
CompleteT3 MessageTimeout | -1 | -1 0 1-480 | -1 forces the NAP to use the attribute value defined in the NAP's NetworkChannelMBean. Setting any other value overrides the attribute value defined in the NAP's NetworkChannelMBean. See Network Channel and NAP Attributes for more information about this attribute.
CompleteHTTP MessageTimeout | -1 | -1 0 1-480 | -1 forces the NAP to use the attribute value defined in the NAP's NetworkChannelMBean. Setting any other value overrides the attribute value defined in the NAP's NetworkChannelMBean; 0 disables the timeout. See Network Channel and NAP Attributes for more information about this attribute.
CompleteCOM MessageTimeout | -1 | -1 0 1-480 | -1 forces the NAP to use the attribute value defined in the NAP's NetworkChannelMBean. Setting any other value overrides the attribute value defined in the NAP's NetworkChannelMBean; 0 disables the timeout. See Network Channel and NAP Attributes for more information about this attribute.

* Indicates the attribute is not dynamically configurable (requires server restart for changes to take effect).