| Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management (Oracle Fusion Applications Edition) 11g Release 7 (11.1.7) Part Number E21032-21 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management (Oracle Fusion Applications Edition) 11g Release 7 (11.1.7) Part Number E21032-21 |
|
|
PDF · Mobi · ePub |
This chapter describes the prerequisites for the Oracle Identity Management Infrastructure enterprise deployment topologies.
This chapter includes the following topics:
Section 3.1, "Overview of Preparing the Network for an Enterprise Deployment"
Section 3.3, "About Virtual Server Names Used by the Topologies"
Section 3.8, "Managing Oracle Access Manager Communication Protocol"
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.
As shown in the deployment topology figures, each deployment is 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, three 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 private zone–This is where the application servers reside. This zone cannot be accessed directly from the outside world. It can be accessed only by the web servers that reside in the public zone. This access is determined by the use of a firewall
The private zone is configured so that the servers in this zone can interact with the servers in the intranet.
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.
This section contains the following topics:
The load balancer is configured with a number of virtual host names, depending on the access required DNS is set up in such a way that these virtual host names are accessible in the areas where they are used. For example:
Public communication is configured using a virtual host which is resolvable both inside and outside of the organization.
Interprocess communication is configured using a virtual host which is only resolvable in the private zone.
The Identity Management enterprise topologies use the following virtual server names:
Some of the virtual server names are used by some topologies and not others.
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 Load Balancers"
The rest of this document assumes that the deployment is one of those shown in Section 2.1.1, "Reference Topologies Documented in the Guide."
This virtual server is enabled on LBR2. It acts as the access point for all policy-based LDAP traffic, which is stored in the Oracle Internet Directory servers in the Directory Tier. Traffic to both the SSL and non-SSL is configured. The clients access this service using the address POLICYSTORE.mycompany.com:636 for SSL and POLICYSTORE.mycompany.com:389 for non-SSL.
Note:
Oracle recommends that you configure the same port for SSL connections on the LDAP server and Oracle Internet Directory on the computers on which Oracle Internet Directory is installed.
This is a requirement for most Oracle 11g products that use Oracle Internet Directory through the load balancing router.
This virtual server directs traffic received on port 389 to each of the Oracle Internet Directory instances on port 3060.
This virtual server directs traffic received on port 636 to each of the Oracle Internet Directory instances on port 3131.
Monitor the heartbeat of the Oracle Internet Directory processes on LDAPHOST1 and LDAPHOST2. If an Oracle Internet Directory process stops on LDAPHOST1 or LDAPHOST2, or if either host LDAPHOST1 or LDAPHOST2 is down, the load balancer must continue to route the LDAP traffic to the surviving computer.
This virtual server is enabled on LBR2. It 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.
Monitor the heartbeat of the Oracle Virtual Directory processes on LDAPHOST1 and LDAPHOST2. If an Oracle Virtual Directory process stops on LDAPHOST1 or LDAPHOST2, or if either host LDAPHOST1 or LDAPHOST2 is down, the load balancer must continue to route the LDAP traffic to the surviving computer.
If your implementation uses a third-party directory as an identity store, you access that directory through Oracle Virtual Directory. The provisioning process initially uses Oracle Internet Directory as its identity store. After provisioning is completed, you change the Oracle Virtual Directory configuration to point to your actual identity store, the third party directory, as a post provisioning task. After that, you still access identity information through Oracle Virtual Directory using the endpoint IDSTORE.mycompany.com, but now it points to the third-party directory.
This virtual server directs traffic received on port 389 (LDAP_LBR_PORT) to each of the Oracle Virtual Directory instances on port 6501.
This virtual server directs traffic received on port 636 (LDAP_LBR_SSL_PORT) to each of the Oracle Virtual Directory instances on port 7501.
This virtual server is enabled on LBR1. It acts as the access point for all internal HTTP traffic that gets directed to the administration services. The incoming traffic from clients is non-SSL enabled. Thus, the clients access this service using the address ADMIN.mycompany.com:80 and in turn forward these to ports 7777 (OHS_PORT) on WEBHOST1 and WEBHOST2. The services accessed on this virtual host include the WebLogic Administration Server Console, Oracle Enterprise Manager Fusion Middleware Control, and Oracle Directory Services Manager.
Create rules in the firewall to block outside traffic from accessing the /console and /em URLs using this virtual host. Only traffic inside the DMZ should be able to access these URLs on the ADMIN.mycompany.com virtual host.
This virtual server is enabled on LBR1. 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 (OHS_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 is the virtual name which fronts all Identity Management components, including Oracle Identity Federation, Oracle Access Manager, and Oracle Identity Manager.
This virtual server is enabled on LBR1. It 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 ports 7777 (OHS_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 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.
Several 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 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.
There are two load balancer devices in the recommended topologies. 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.
The enterprise topologies use 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 host name: Clients access services using the virtual host name (instead of using actual host 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.
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.
Configuration of the virtual server(s) in the load balancer for the Directory Tier with a high value for the connection timeout for TCP connections. This value should be more than the maximum expected time over which no traffic is expected between Oracle Access Manager and the Directory Tier.
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.
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:
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 hosts WEBHOST1 and WEBHOST2 on port 7777 (OHS_PORT).
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.
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 host for SSO.mycompany.com:80.
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.
Configure SSL Termination, if applicable, for the virtual server.
Assign the Pool of servers created in Step 1 to the virtual server.
Tune the time out settings as listed in Table 3-3, "Ports Used in the Oracle Identity Management Enterprise Deployment Topologies". This includes time to detect whether a service is down.
For an Identity 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 |
|---|---|---|---|---|---|
|
|
|
HTTP |
No |
Yes |
Identity Management requires that the following be added to the HTTP header:
|
|
|
|
HTTPS |
Yes |
Yes |
Identity Management requires that the following be added to the HTTP header:
|
|
|
|
HTTP |
No |
No |
|
|
|
|
HTTP |
No |
No |
|
|
|
|
LDAP |
No |
No |
Only required if policy store is different from idstore. This is true if you use either Active Directory or Oracle Internet Directory with a split profile. |
|
|
|
LDAP |
No |
No |
|
|
|
|
LDAP |
No |
No |
If you have an Oracle Internet Directory-only topology and are not using Oracle Virtual Directory, the server pool must contain Oracle Internet Directory servers. |
|
|
|
LDAP |
No |
No |
If you have an Oracle Internet Directory-only topology and are not using Oracle Virtual Directory, the server pool must contain Oracle Internet Directory servers. |
Footnote 1 For information about configuring IS_SSL, see "About User Defined WebGate Parameters" in Oracle Fusion Middleware Administrator's Guide for Oracle Access Manager with Oracle Security Token Service.
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 of the node where the IP address is assigned, 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 Management:
ADMINVHN.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 IDMHOST1 to IDMHOST2, 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-1.
Table 3-2 provides descriptions of the various virtual hosts.
Table 3-2 Virtual Hosts
| Virtual IP | VIP Maps to... | Description |
|---|---|---|
|
VIP1 |
ADMINVHN |
ADMINVHN 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 (IDMHOST1 by default). |
|
VIP2 |
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 (IDMHOST1 by default). |
|
VIP3 |
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 (IDMHOST2 by default). |
|
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 (IDMHOST1 by default) |
|
VIP5 |
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 (IDMHOST2 by default) |
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 Management topologies, including the ports that you must open on the firewalls in the topologies.
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 Directory Tier.
Table 3-3 Ports Used in the Oracle Identity Management Enterprise Deployment Topologies
| 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 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 Management. |
|
Browser request |
FW1 |
80 |
HTTP / Load Balancer |
Outbound (for intranet clients) |
Timeout depends on all HTML content and the type of process model used for IDM. |
|
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 IDM. |
|
Load balancer to Oracle HTTP Server |
n/a |
7777 |
HTTP |
n/a |
|
|
OHS registration with Administration Server |
FW1 |
7001 |
HTTP/t3 |
Inbound |
Set the timeout to a short period (5-10 seconds). |
|
IDMDomain Oracle WebLogic Administration Server access from Web Tier |
FW1 |
7001 |
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_ODS |
FW1 |
7006 |
HTTP / Oracle HTTP Server to WebLogic Server |
Inbound |
Timeout depends on the |
|
Oracle HTTP Server to WLS_OAM |
FW1 |
14100 |
HTTP / Oracle HTTP Server to WebLogic Server |
Inbound |
Timeout depends on the |
|
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 Admin Port (7779) |
TCP and HTTP, respectively |
Outbound |
Set the timeout to a short period, such as 5-10 seconds. |
|
Oracle Access Manager Server 11g |
FW1 |
5575 |
OAP |
Both |
N/A |
|
Oracle Access Manager Coherence port |
FW1 |
9095 |
TCMP |
Both |
N/A |
|
Oracle Coherence Port |
FW1 |
8000 - 8088 |
TCMP |
Both |
N/A |
|
IDMDomain Oracle WebLogic Administration Server access from Directory Tier |
FW2 |
7001 |
HTTP / Oracle Internet Directory, Oracle Virtual Directory, and Administration Server |
Outbound |
N/A |
|
Enterprise Manager Agent - Directory Tier to Enterprise Manager |
FW2 |
5160 |
HTTP / Enterprise Manager Agent and Enterprise Manager |
Both |
N/A |
|
OPMN access in Directory Tier |
FW2 |
OPMN remote port |
HTTP / Administration Server to OPMN |
Inbound |
N/A |
|
Oracle Virtual Directory proxy port |
FW2 |
8899 |
HTTP / Administration Server to Oracle Virtual Directory |
Inbound |
N/A |
|
Database access |
FW2 |
1521 |
SQL*Net |
Both |
Timeout depends on all database content and on the type of process model used for Oracle Identity Management. |
|
Oracle Internet Directory access |
FW2 |
3060 |
LDAP |
Inbound |
Tune the directory server's parameters based on the load balancer, and not the other way around. Ideally, these connections should be configured not to time out. |
|
Oracle Internet Directory access |
FW2 |
3131 |
LDAP SSL |
Inbound |
Tune the directory server's parameters based on the load balancer, and not the other way around. Ideally, these connections should be configured not to time out. |
|
Oracle Virtual Directory access |
FW2 |
6501 |
LDAP |
Inbound |
Ideally, these connections should be configured not to time out. |
|
Oracle Virtual Directory access |
FW2 |
7501 |
LDAP SSL |
Inbound |
Ideally, these connections should be configured not to time out. |
|
Oracle Identity Federation |
FW2 |
7499 |
HTTP |
Both |
N/A |
|
Session replication within a WebLogic Server cluster |
N/A |
N/A |
N/A |
N/A |
By default, this communication uses the same port as the server's listen address. |
|
Node Manager |
N/A |
5556 |
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 Management domain.
The Identity Management Provisioning Wizard uses some ports that you cannot change. These are shown in Table 3-4. When scaling the topology, you can use different ports.
Table 3-4 Fixed Ports Used by the Provisioning Wizard
| Description | Name | Value |
|---|---|---|
|
Oracle Virtual Directory proxy port |
|
8899 |
|
|
6501 |
|
|
|
7501 |
|
|
Load Balancer Policy Store Port |
|
389 |
|
Load Balancer Policy Store SSL Port |
|
636 |
|
Oracle Access Manager proxy port |
|
5575 |
|
Oracle WebLogic Server administration port |
|
7001 |
This section discusses Oracle Access Protocol (OAP) and provides an overview of a user request.
This section contains the following topics:
Oracle Access Protocol (OAP) enables communication between Access System components (for example, OAM Server, WebGate) during user authentication and authorization. This protocol was formerly known as NetPoint Access Protocol (NAP) or COREid Access Protocol.
Oracle Access Manager is responsible for creating sessions for users. When Oracle Access Manager is integrated with another Identity Management component, such as Oracle Identity Manager, authentication is delegated to those components.
A typical request flow is as follows:
The user tries to access a resource for the first time.
WebGate intercepts the request and detects that the user is not authenticated.
Oracle Access Manager credential collector is invoked and the user enters a user name and password in response to a prompt. Oracle 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.
The user is prompted to change password and set up challenge questions.
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 Oracle 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 Oracle Access Manager can read.
The TAP request to Oracle Access Manager will include such things as:
Where the Oracle Access Manager servers are located.
What web gate profile to use.
WebGate profile password.
Certificates, if Oracle Access Manager is working in simple or cert mode.
The request flow when a user requests access is as follows:
The user requests access to a protected resource over HTTP or HTTPS.
The WebGate intercepts the request.
The WebGate forwards the request to the OAM 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).
The OAM 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.
Following authentication, the WebGate prompts the OAM Server over Oracle Access Protocol and the OAM 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.
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.)
|
 Copyright © 2004, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
