3 Preparing the Network for an Enterprise Deployment

This chapter describes the prerequisites for the Oracle Identity and Access Management Infrastructure enterprise deployment topology.

This chapter includes the following topics:

3.1 Overview of Preparing the Network for an Enterprise Deployment

You must configure several virtual servers and associated ports on the load balancer for different types of network traffic and monitoring. These virtual servers should be configured to the appropriate real hosts and ports for the services running. Also, the load balancer should be configured to monitor the real host and ports for availability so that the traffic to these is stopped as soon as possible when a service is down. This ensures that incoming traffic on a given virtual host is not directed to an unavailable service in the other tiers.

3.2 Planning Your Network

As shown in the deployment topology figures in Section 2.3, "Understanding the Topology," each deployment can be spread across multiple zones. A zone is a means of restricting access to components of your infrastructure to those that actually need it. In the examples in this guide, two zones are shown.

  • The public zone–This is where the outside world gains access to your systems. You place into this zone only those components that the outside world must access, such as the Load Balancers and Web Tiers. If users from the outside world attempts to access any servers or services below this zone, they are prevented from doing so by firewalls.

    The public zone is configured so that the servers in this zone can interact with the application servers in the private zone.

  • The intranet zone–This is where you place servers that contain core services, such as databases. These services are very tightly controlled by the organization as they contain the most sensitive data.

By using this approach, you restrict access to information to only those components that require it. This approach is useful where you have users coming in from outside of your organization.

If, instead of an extranet, you are setting up an intranet, where all communication is from trusted sources, then you might reasonably decide to do away with one or more of the zones.

3.3 Virtual Server Names Used by the Topology

Virtual Server names are used to hide the identities of the real host names used by the organization, and are used as the entry points into the applications.

One benefit of using virtual server names is that the backend server names can change without the application having to be reconfigured with new host names.

Another advantage of using virtual server names is that these server names can be attached to a load balancer, allowing the load balancer to use a single name to distribute requests amongst a number of back end servers which serve the same function. This ensures availability and simplified scalability.

When attached to a load balancer the load balancer can also terminate SSL allowing the applications to maintain encrypted traffic between the application and the client but at the same time to allow the application to perform more efficiently without having to encrypt traffic between each component.

Virtual Server names are included in the organizations DNS servers. External application entries are configured in external DNS servers.

This ensures that public access points are resolvable in the internet and private access points available only inside the organization.

On Prem Only:

Some of the virtual servers, such as IDSTORE.mycompany.com and IDMINTERNAL, you may wish to exclude from DNS altogether and to resolve only those servers you are using.

Both:

Virtual Server Names resolve to a single IP address. This IP address can be associated with a virtual host on a load balancer.

Exalogic:

Ensure that the virtual server names are associated with IP addresses and are part of your DNS. The computers on which Oracle Fusion Middleware is running must be able to resolve these virtual server names.

You define the virtual server names on the load balancer using the procedure in Section 3.4, "Configuring the Hardware Load Balancers"

The rest of this guide assumes that the deployment is one of those shown in Chapter 2, "Introduction and Planning."

3.3.1 IDSTORE.mycompany.com

  • This virtual server acts as the access point for all Identity Store LDAP traffic. Traffic to both the SSL and non-SSL is configured. The clients access this service using the address IDSTORE.mycompany.com:636 for SSL and IDSTORE.mycompany.com:389 for non-SSL.

  • Because your Identity Store in Oracle Unified Directory is accessed directly, you must monitor the heartbeat of the Oracle Unified Directory processes. If an Oracle Unified Directory process stops, the load balancer must continue to route the LDAP traffic to a surviving Oracle Unified Directory instance.

  • This virtual server directs traffic received on port 389 (LDAP_LBR_PORT) to each of the Oracle Unified Directory instances on port 1389 (LDAP_DIR_PORT).

  • This virtual server directs traffic received on port 1636 (LDAP_LBR_SSL_PORT) to each of the Oracle Unified Directory instances on port 1636 (LDAP_DIR_SSL_PORT).

  • This virtual server is resolvable only locally (in Exalogic).

3.3.2 IADADMIN.mycompany.com

  • This virtual server acts as the access point for all internal HTTP traffic that gets directed to the administration services in the Access Domain. The incoming traffic from clients is non-SSL enabled. Thus, the clients access this service using the address IADADMIN.mycompany.com:80 and in turn forward these to port 7777 (WEB_HTTP_PORT) on WEBHOST1 and WEBHOST2. The services accessed on this virtual host include the WebLogic Administration Server Console and Oracle Enterprise Manager Fusion Middleware Control.

  • This virtual server is resolvable in the corporate DNS only.

  • Create rules in the firewall to block outside traffic from accessing the /console, /oamconsole, /oaam_admin, and /em URLs using this virtual host. Only traffic inside the DMZ should be able to access these URLs on the IADADMINVHN.mycompany.com virtual host.

3.3.3 IGDADMIN.mycompany.com

  • This virtual server acts as the access point for all internal HTTP traffic that gets directed to the administration services in the Governance Domain. The incoming traffic from clients is non-SSL enabled. Thus, the clients access this service using the address IGDADMIN.mycompany.com:80 (HTTP_PORT) and in turn forward these to ports 7777 (WEB_HTTP_PORT) on WEBHOST1 and WEBHOST2. The services accessed on this virtual host include the WebLogic Administration Server Console, and Oracle Enterprise Manager Fusion Middleware Control,and Oracle Authorization Policy Manager.

  • Create rules in the firewall to block outside traffic from accessing the /sysadmin, /apm, /console and /em URLs using this virtual host. Only traffic inside the DMZ should be able to access these URLs on the IGDADMINVHN.mycompany.com virtual host.

  • This virtual server should be resolvable only in the corporate DNS.

3.3.4 IDMINTERNAL.mycompany.com

  • The incoming traffic from clients is non-SSL enabled. Thus, the clients access this service using the address IDMINTERNAL.mycompany.com:80 and in turn forward these to port 7777 (WEB_HTTP_PORT) on WEBHOST1 and WEBHOST2. The SOA Managed servers access this virtual host to callback Oracle Identity Manager web services

  • Create rules in the firewall to block outside traffic from accessing this virtual host. Only traffic inside the DMZ should be able to access these URLs on the IDMINTERNAL.mycompany.com virtual host.

  • This virtual server should be resolvable either locally or in the corporate DNS

  • Because IDMINTERNAL is designed for interprocess communication, you might want to NOT include this in DNS, but have it resolvable only in internal host files.

3.3.5 SSO.mycompany.com

  • This is the virtual name which fronts all Identity and Access Management components, including Access Manager and Oracle Identity Manager.

  • This virtual server acts as the access point for all HTTP traffic that gets directed to the single sign on services. The incoming traffic from clients is SSL enabled. Thus, the clients access this service using the address SSO.mycompany.com:443 and in turn forward these to port 7777 (WEB_HTTP_PORT) on WEBHOST1 and WEBHOST2. All the single sign on enabled protected resources are accessed on this virtual host.

  • Configure this virtual server in the load balancer with both port 80 (HTTP_PORT) and port 443 (HTTP_SSL_PORT).

  • This virtual server should be resolvable either locally or in the corporate DNS

  • This virtual host must be configured to preserve the client IP address for a request. In some load balancers, you configure this by enabling the load balancer to insert the original client IP address of a request in an X-Forwarded-For HTTP header.

3.4 Configuring the Hardware Load Balancers

A hardware load balancer directs requests to the application in this case Oracle Identity and Access Management to the individual hosts which make up the application components.

A load balancer is configured with virtual hosts. Each virtual host is associated with a different IP address, which is serviced by the load balancer. The Load balancer virtual host is then associated with a pool of origin servers consisting of the web servers in the deployment.

Virtual servers and associated ports must be configured on the load balancer for different types of network traffic and monitoring. These should be configured to route request to the appropriate real hosts and ports running the services. The load balancer should be configured to monitor the real host and ports for availability so that the traffic to these is stopped as soon as possible when a service is down. This ensures that incoming traffic on a given virtual host is not directed to an unavailable service in the other tiers.

There are two load balancer devices in the recommended topology. One load balancer is set up for external HTTP traffic and the other load balancer is set up for internal LDAP traffic. A deployment may choose to have a single load balancer device due to a variety of reasons. While this is supported, the deployment should consider the security implications of doing this and if found appropriate, open up the relevant firewall ports to allow traffic across the various zones. It is worth noting that in either case, it is highly recommended to deploy a given load balancer device in fault tolerant mode.

This section contains the following topics:

3.4.1 Load Balancer Requirements

The enterprise topology uses an external load balancer. This external load balancer must have the following features:

  • Ability to load-balance traffic to a pool of real servers through a virtual server name: Clients access services using the virtual server name (instead of using actual server names). The load balancer can then load balance requests to the servers in the pool.

  • Port translation configuration.

  • Monitoring of ports (HTTP and HTTPS).

  • Virtual servers and port configuration: Ability to configure virtual server names and ports on your external load balancer, and the virtual server names and ports must meet the following requirements:

    • The load balancer should allow configuration of multiple virtual servers. For each virtual server, the load balancer should allow configuration of traffic management on more than one port. For example, for Oracle WebLogic Clusters, the load balancer must be configured with a virtual server and ports for HTTP and HTTPS traffic.

    • The virtual server names must be associated with IP addresses and be part of your DNS. Clients must be able to access the external load balancer through the virtual server names.

  • Ability to detect node failures and immediately stop routing traffic to the failed node.

  • Resource monitoring / port monitoring / process failure detection: The load balancer must be able to detect service and node failures (through notification or some other means) and to stop directing non-Oracle Net traffic to the failed node. If your external load balancer has the ability to automatically detect failures, you should use it.

  • Fault tolerant mode: It is highly recommended that you configure the load balancer to be in fault-tolerant mode.

  • Sticky routing capability: Ability to maintain sticky connections to components based on cookies or URL.

  • Other: It is highly recommended that you configure the load balancer virtual server to return immediately to the calling client when the back-end services to which it forwards traffic are unavailable. This is preferred over the client disconnecting on its own after a timeout based on the TCP/IP settings on the client machine.

  • SSL acceleration, which refers to off loading the public-key encryption algorithms involved in SSL transactions to a hardware accelerator. This feature is recommended, but not required.

  • Ability to terminate SSL requests at the load balancer and forward traffic to the backend real servers using the equivalent non-SSL protocol. For example, the load balancer must be able to forward HTTPS requests as HTTP. This feature is sometimes called "SSL termination." It is required for this Enterprise Deployment.

  • Ability to Preserve the Client IP Addresses: The Load Balancer must have the capability to insert the original client IP address of a request in an X-Forwarded-For HTTP header to preserve the Client IP Address.

  • Ability to add WL-Proxy-SSL: true to the HTTP Request Header. Some load balancers do this automatically.

3.4.2 Load Balancer Configuration Procedures

The procedures for configuring a load balancer differ, depending on the specific type of load balancer. Refer to the vendor supplied documentation for actual steps. The following steps outline the general configuration flow:

  1. Create a pool of servers. This pool contains a list of servers and the ports that are included in the load balancing definition. For example, for load balancing between the web hosts you create a pool of servers which would direct requests to the web servers in the topology which accept requests using port 7777 (WEB_HTTP_PORT).

  2. Create rules to determine whether or not a given host and service is available and assign it to the pool of servers described in Step 1.

  3. Create a Virtual Server on the load balancer. This is the address and port that receives requests used by the application. For example, to load balance Web Tier requests you would create a virtual server for SSO.mycompany.com:80.

  4. If your load balancer supports it, specify whether or not the virtual server is available internally, externally or both. Ensure that internal addresses are only resolvable from inside the network.

  5. Configure SSL Termination, if applicable, for the virtual server.

  6. Assign the Pool of servers created in Step 1 to the virtual server.

  7. Tune the time out settings as listed in Table 3-3, "Ports Used in the Oracle Identity and Access Management Enterprise Deployment Topology". This includes time to detect whether a service is down.

3.4.3 Load Balancer Configuration

For an Identity and Access Management deployment, configure your load balancer as shown in Table 3-1.

Table 3-1 Load Balancer Configuration

Virtual Host Server Pool Protocol SSL Termination External Other Required Configuration/Comments

SSO.mycompany.com:80 (HTTP_PORT)

WEBHOST1.mycompany.com:7777

WEBHOST2.mycompany.com:7777

HTTP

No

Yes

Identity and Access Management requires that the following be added to the HTTP header:

Header Name: IS_SSL

Header Value: ssl

SSO.mycompany.com:443 (HTTP_SSL_PORT)

WEBHOST1.mycompany.com:7777 WEBHOST2.mycompany.com:7777

HTTPS

Yes

Yes

Identity and Access Management requires that the following be added to the HTTP header:

Header Name: IS_SSL

Header Value: ssl

IADADMIN.mycompany.com:80 (HTTP_PORT)

WEBHOST1.mycompany.com:7777 WEBHOST2.mycompany.com:7777

HTTP

No

No

IADADMINVHN.mycompany.com:80 (HTTP_PORT)

IGDADMIN.mycompany.com:80 (HTTP_PORT)

WEBHOST1.mycompany.com:7777 WEBHOST2.mycompany.com:7777

HTTP

No

No

IGDADMINVHN.mycompany.com:80 (HTTP_PORT)

IDMINTERNAL.mycompany.com:80 (HTTP_PORT)

WEBHOST1.mycompany.com:7777 WEBHOST2.mycompany.com:7777

HTTP

No

No

  

IDSTORE.mycompany.com:389

LDAPHOST1.mycompany.com:1389

LDAPHOST2.mycompany.com:1389

LDAP

No

No

Only required if Identity and Access Management users are stored in an Oracle Unified Directory.

IDSTORE.mycompany.com:636

LDAPHOST1.mycompany.com:1636

LDAPHOST2.mycompany.com:1636

LDAPS

No

No

Only required if Identity and Access Management users are stored in an Oracle Unified Directory.

3.5 About IP Addresses and Virtual IP Addresses

A virtual IP address is an unused IP Address which belongs to the same subnet as the host's primary IP address. It is assigned to a host manually and Oracle WebLogic Managed servers are configured to listen on this IP Address. In the event of the failure, the IP address is assigned to another node in the same subnet, so that the new node can take responsibility for running the managed servers assigned to it.

The following is a list of the Virtual IP addresses required by Oracle Identity and Access Management:

  • IADADMINVHN.mycompany.com

    In Enterprise deployments the WebLogic Administration Server must be able to continue processing requests after the host it is residing on fails. A virtual IP address should be provisioned in the application tier so that it can be bound to a network interface on any host in the application tier. The WebLogic Administration Server is configured later to listen on this virtual IP address, as discussed later in this manual. The virtual IP address fails over along with the Administration Server from OAMHOST1 to OAMHOST2, or vice versa.

  • IGDADMINVHN.mycompany.com

    In Enterprise deployments the WebLogic Administration Server must be able to continue processing requests after the host it is residing on fails. A virtual IP address should be provisioned in the application tier so that it can be bound to a network interface on any host in the application tier. The WebLogic Administration Server is configured later to listen on this virtual IP address, as discussed later in this manual. This virtual IP address fails over along with the Administration Server from OIMHOST1 to OIMHOST2, or vice versa.

  • SOAHOSTxVHN.mycompany.com

    One virtual IP address is required for each SOA managed server. This enables the servers to participate in Server migration.

    Provision a virtual IP address in the application tier so that it can be bound to a network interface on any host in the application tier.

  • OIMHOSTxVHN.mycompany.com

    One virtual IP Address is required for each Oracle Identity Manager managed server. This enables the servers to participate in Server migration.

    Provision a virtual IP address in the application tier so that it can be bound to a network interface on any host in the application tier.

Configure the Administration Server and the managed servers to listen on different virtual IPs and physical IPs as illustrated in Figure 3-0.

Figure 3-1 IP Addresses and VIP Addresses–Distributed

Surrounding text describes Figure 3-1 .

Figure 3-2 IP Addresses and VIP Addresses–Consolidated

Surrounding text describes Figure 3-2 .

Table 3-2 provides descriptions of the various virtual hosts.

Table 3-2 VIP Addresses and Virtual Hosts

Virtual IP VIP Maps to... Description (Consolidated) Default Host (Consolidated) Default Host (Distributed)

VIP1

IADADMINVHN

IADADMINVHN is the virtual host name that is the listen address for the Administration Server and fails over with manual failover of the Administration Server. It is enabled on the node where the Administration Server process is running.

IAMHOST1

OAMHOST1

VIP2

IGDADMINVHN

IGDADMINVHN is the virtual host name that is the listen address for the Oracle Identity Manager Administration Server. It fails over with manual failover of the Administration Server. It is enabled on the node where the Oracle Identity Manager Administration Server process is running.

IAMHOST1

OIMHOST1

VIP3

SOAHOST1VHN

SOAHOST1VHN is the virtual host name that maps to the listen address for WLS_SOA1 and fails over with server migration of this managed server. It is enabled on the node where WLS_SOA1 process is running.

IAMHOST1

OIMHOST1

VIP4

OIMHOST1VHN

OIMHOST1VHN is the virtual host name that maps to the listen address for the WLS_OIM1 server and fails over with server migration of this server. It is enabled in the node where the WLS_OIM1 process us running.

IAMHOST1

OIMHOST1

VIP5

SOAHOST2VHN

SOAHOST2VHN is the virtual host name that maps to the listen address for WLS_SOA2 and fails over with server migration of this managed server. It is enabled on the node where WLS_SOA2 process is running.

IAMHOST2

OIMHOST2

VIP6

OIMHOST2VHN

OIMHOST2VHN is the virtual host name that maps to the listen address for the WLS_OIM2 server and fails over with server migration of this server. It is enabled in the node where the WLS_OIM2 process us running.

IAMHOST2

OIMHOST2

these virtual IP addresses are associated with a virtual host name. That way, should it be required, the underlying IP address can be changed.The examples below show the virtual host names required by this document. These are associated with a virtual IP address as described above.

3.6 Configuring Firewalls and Ports

Many Oracle Fusion Middleware components and services use ports. As an administrator, you must know the port numbers used by these services, and to ensure that the same port number is not used by two services on a host.

Most port numbers are assigned after installation. You can use different port numbers if you want to. The port numbers shown in Table 3-3 are examples that are used throughout this guide for consistency. If you use different port numbers, you must substitute those values for the values in the table wherever they are used.

Table 3-3 lists the ports used in the Oracle Identity and Access Management topology, including the ports that you must open on the firewalls in the topology.

Firewall notation:

  • FW0 refers to the outermost firewall.

  • FW1 refers to the firewall between the web tier and the application tier.

  • FW2 refers to the firewall between the application tier and the database tier.

Table 3-3 Ports Used in the Oracle Identity and Access Management Enterprise Deployment Topology

Type Firewall Port and Port Range Protocol / Application Inbound / Outbound Timeout

Browser request

FW0

80

HTTP / Load balancer

Both

Timeout depends on all HTML content and the type of process model used for Oracle Identity and Access Management.

Browser request

FW0

443

HTTPS / Load balancer

Both

Timeout depends on all HTML content and the type of process model used for Oracle Identity and Access Management.

Browser request

FW1

80

HTTPS / Load Balancer

Outbound (for intranet clients)

Timeout depends on all HTML content and the type of process model used for IAM.

Browser request

FW1

443

HTTPS / Load Balancer

Outbound (for intranet clients)

Timeout depends on all HTML content and the type of process model used for IAM.

Load balancer to Oracle HTTP Server

n/a

7777

HTTP

n/a

See Section 3.4, "Configuring the Hardware Load Balancers."

OHS registration with Administration Server

FW1

7001

HTTP/t3

Inbound

Set the timeout to a short period (5-10 seconds).

Webtier Access to Oracle Weblogic Administration Server (IAMAccessDomain)

FW1

7001

HTTP / Oracle HTTP Server and Administration Server

Inbound

N/A

Webtier Access to Oracle Weblogic Administration Server (IAMGovernanceDomain)

FW1

7101

HTTP / Oracle HTTP Server and Administration Server

Inbound

N/A

Enterprise Manager Agent - web tier to Enterprise Manager

FW1

5160

HTTP / Enterprise Manager Agent and Enterprise Manager

Both

N/A

Oracle HTTP Server to WLS_OAM

FW1

14100

HTTP / Oracle HTTP Server to WebLogic Server

Inbound

Timeout depends on the mod_weblogic parameters used.

Oracle HTTP Server WLS_OIM

FW1

14000

HTTP / Oracle HTTP Server to WebLogic Server

Inbound

Timeout depends on the mod_weblogic parameters used

Oracle HTTP Server WLS_SOA

FW1

8001

HTTP / Oracle HTTP Server to WebLogic Server

Both

Timeout depends on the mod_weblogic parameters used

Oracle HTTP Server management by Administration Server

FW1

OPMN remote port (6701) and OHS Administration Port (7779)

TCP and HTTP, respectively

Outbound

Set the timeout to a short period, such as 5-10 seconds.

Access Manager Server

FW1

5575

OAP

Both

N/A

Access Manager Coherence port

FW1

9095

TCMP

Both

N/A

OAAM Server port

FW1

14300

HTTP / Enterprise Manager

Both

N/A

OAAM Administration port

FW1

14200

HTTP / Enterprise Manager

Both

N/A

Oracle Coherence Port

FW1

8000 - 8088

TCMP

Both

N/A

WLS_OAAM to Administration Server

FW2

OPMN remote port

HTTP / Administration Server to OPMN

Inbound

N/A

Application Tier to Database Listener

FW2

1521

SQL*Net

Both

Timeout depends on all database content and on the type of process model used for Oracle Identity and Access Management.

Oracle Notification Server (ONS)

FW2

6200

ONS

Both

Required for Gridlink. An ONS server runs on each database server.

OUD Port

FW2

1389

LDAP

Inbound

Ideally, these connections should be configured not to time out.

OUD SSL Port

FW2

14636

LDAPS

Inbound

Ideally, these connections should be configured not to time out.

Load Balancer LDAP Port

FW2

386

LDAP

Inbound

Ideally, these connections should be configured not to time out.

Load Balancer LDAP SSL Port

FW2

636

LDAPS

Inbound

Ideally, these connections should be configured not to time out.

Node Manager

N/A

5556

TCP/IP

N/A

N/A

Oracle Unified Directory Replication

N/A

8989

TCP/IP

N/A

N/A

Note:

Additional ports might need to be opened across the firewalls to enable applications in external domains, such as SOA or WebCenter Portal domains, to authenticate against this Identity and Access Management domain.

3.7 Managing Access Manager Communication Protocol

This section discusses Oracle Access Protocol (OAP) and provides an overview of a user request.

This section contains the following topics:

3.7.1 Access Manager Protocols

Oracle Access Protocol (OAP) enables communication between Access System components (for example, Access Manager Server, WebGate) during user authentication and authorization. This protocol was formerly known as NetPoint Access Protocol (NAP) or COREid Access Protocol.

3.7.2 Overview of Integration Requests

Oracle Access Management Access Manager is responsible for creating sessions for users. When Access Manager is integrated with another Identity and Access Management component, such as Oracle Identity Manager, authentication is delegated to that component.

A typical request flow is as follows:

  1. The user tries to access a resource for the first time.

  2. WebGate intercepts the request and detects that the user is not authenticated.

  3. Access Manager credential collector is invoked and the user enters a user name and password in response to a prompt. Access Manager knows that password policy requires the password to be changed at first login, so the user's browser is redirected to Oracle Identity Manager.

  4. The user is prompted to change password and set up challenge questions.

  5. At this point, Oracle Identity Manager has authenticated the user using the newly entered password. Oracle Identity Manager creates a TAP request to say that Access Manager can create a session for the user. That is, the user will not be expected to log in again. This is achieved by adding a token to the user's browser that Access Manager can read.

    The TAP request to Access Manager will include such things as:

    • Where the Access Manager servers are located.

    • What web gate profile to use.

    • WebGate profile password.

    • Certificates, if Access Manager is working in simple or cert mode.

3.7.3 Overview of User Request

The request flow when a user requests access is as follows:

  1. The user requests access to a protected resource over HTTP or HTTPS.

  2. The WebGate intercepts the request.

  3. The WebGate forwards the request to the Access Manager Server over Oracle Access Protocol to determine if the resource is protected, how, and whether the user is authenticated (if not, there is a challenge).

  4. The Access Manager Server checks the directory server for credentials such as a user ID and password, sends the information back to WebGate over Oracle Access Protocol, and generates an encrypted cookie to authenticate the user.

  5. Following authentication, the WebGate prompts the Access Manager Server over Oracle Access Protocol and the Access Manager Server looks up the appropriate security policies, compares them to the user's identity, and determines the user's level of authorization.

    • If the access policy is valid, the user is allowed to access the desired content and/or applications.

    • If the policy is false, the user is denied access and redirected to another URL determined by the organization's administrator.

3.7.4 About the Multicast Requirement for Communication

Oracle recommends that the nodes in the topology communicate using unicast communication. Unlike multicast communication, unicast does not require cross-network configuration. Using unicast avoids network errors due to multicast address conflicts.

In unicast messaging mode, the default listening port of the server is used if no channel is configured. Cluster members communicate to the group leader when they need to send a broadcast message which is usually the heartbeat message. When the cluster members detect the failure of a group leader, the next oldest member becomes the group leader. The frequency of communication in unicast mode is similar to the frequency of sending messages on multicast port.

The following considerations apply when using unicast to handle cluster communications:

  • All members of a WebLogic cluster must use the same message type. Mixing multicast and unicast messaging is not allowed.

  • Individual cluster members cannot override the cluster messaging type.

  • The entire cluster must be shut down and restarted to change the message modes from unicast to multicast or from multicast to unicast.

  • JMS topics configured for multicasting can access WebLogic clusters configured for unicast because a JMS topic publishes messages on its own multicast address that is independent of the cluster address. However, the following considerations apply:

    • The router hardware configurations that allow unicast clusters may not allow JMS multicast subscribers to work.

    • JMS multicast subscribers need to be in a network hardware configuration that allows multicast accessibility. (That is, JMS subscribers must be in a multicast-enabled network to access multicast topics.

Note:

Although you can set up cluster communication using Unicast, Oracle Identity Manager depends upon Multicast when it is used for caching. For that reason, you must enable multicast between the machines.

3.7.5 Verifying Network Connectivity

After having defined the Network, ensure that all of the network names are resolvable from each of the compute Nodes/vServers.

You do this by performing the following command on each compute node/vServer

ping -I interface hostname