Loopbacks, Virtual IPs and the E-Business Suite

[Editor Mar 27 , 2007Update:  Updated with more information about loopback requirements for internal and external applications.]

[Editor Mar 16 , 2007 Update:  Added loopback diagram and updated test section with additional comments.

An area that seems to be perennially troublesome for E-Business Suite architects and sysadmins is that of multiple domain names, virtual IPs and loopback issues.  Here's a quick primer on some of the key concepts that you should be familiar with.

What's a Virtual IP?

Let's say that you'd like to set up an E-Business Suite environment with two different domain names, following Metalink Note 287176.1 (for Release 11i) or Note 380489.1 (for Release 12):
  • partners.company.com for external users
  • employees.company.com for internal users
If you've got a generous networking budget, one approach would be to set up a physical architecture shown below.  This architecture uses two different physical load-balancers, one dedicated for external users (LBR1), and another dedicated for internal users (LBR2):

Physically Separate Load-Balancers:

Note that in the architecture above, the reverse proxy server acts as the "web-entry point" -- that is, the primary point from which all end-user traffic gets dispatched -- for external users.  That's the gold-plated approach. 

However, many customers have big, sophisticated load-balancers that can handle the combined traffic for both domains.  In these situations, the single physical device can be assigned two virtual domain names, each with their own virtual IP address, like this:

Virtual IPs for a Single Load-balancer:

In this architecture, the load-balancer has two virtual domain names, each of which serves as the "web-entry point" for the respective domains:
  • Traffic from User 1 for partners.company.com goes to the external pool of application servers, either Node 1 or 2
  • Traffic from User 4 for employees.company.com goes to the internal pool of application servers, either Node 3 or 4
Technical Requirements for E-Business Suite Environments

Virtual IPs and multiple domain names are supported for E-Business Suite, for both Release 11i and Release 12.  A number of basic requirements need to be met:
  1. Each virtual domain name must have its own virtual IP address, and your end-users should be able to access those IPs in your DNS. 
  2. E-Business Suite technology stack components need to be able to access the load-balancer's virtual IPs, too, due to loopback requirements (see below).
If your load-balancer is capable of it, you should enable additional features such as resource monitoring, fail-over, and immediate returns of failed traffic.  For more details about our recommendations for those features, see the Metalink Notes below.

What are Loopbacks?

For reasons too arcane to delve into here, some components in the E-Business Suite technology stack sometimes need to call other techstack components (or themselves) at various times.  They do so by sending those calls to the web-entry point -- the load-balancer or reverse proxy for their domain -- which forwards those calls to the requested technology stack component, as shown in the following diagram:

Revised Loopback Example:

Loopbacks in Internal and External Applications

Some E-Business Suite modules can be deployed for external use.  These include iSupplier Portal, Oracle Sourcing, iRecruitment, iStore, iSupport, and others listed in Appendix A of Metalink Note 287176.1.  These applications do not require loopbacks.

Applications that aren't on this list are intended for internal deployments.  These applications may require loopbacks.  In some internal architectures, the internal web-entry point is separated from the actual application tier server node by a firewall.  In the diagram above, E-Business Suite techstack components in the application server pool used by internal users will send their loopback requests to the HTTP LBR2 device.  It's not shown in the diagram, but one can envision an architecture where a firewall exists between HTTP LBR2 and Web Nodes 3 and 4.  If this firewall blocks outbound loopback traffic from the Web Nodes to the load-balancer, then the techstack services for internal applications that depend on those loopback connections will start to fail... sometimes in puzzling ways.

Firewall Rules & Production Rollouts

This is a major source of problems that I see reported when moving from testbeds to production rollouts.  Testbeds usually include only one or two machines and they're never separated by firewalls.  However, production systems are usually spread across multiple physical servers, each separated by firewalls. 

Making the situation even more entertaining, networking, security, and E-Business Suite administrators are often in different groups.  Invariably, one team forgets to fill in the other team on their networking requirements.  The E-Business Suite (which worked fine in the testbed environment) seems cranky and unstable in pre-production.  The production rollout gets hung up until the problem is diagnosed and appropriate firewall rules are tweaked.

Don't let that happen to you.  Identifying a loopback problem is really simple:  on each of your application servers in each of your domains, use either ping or telnet to hit each domain's web-entry point.  Likewise, from both an internal and external end-user desktop, ping the respective internal or external E-Business Suite domain name.  If you get a response in all cases, then your firewall rules are
configured correctly.  If not, then give your network and security
teams a call.

Update:  It's been pointed out that the ping test alone is a necessary but not sufficient test, since it doesn't prove whether a given port is accessible to the calling client or application tier service.  Additional tests such as using wget or telnet (the latter documented in the latest updates to Metalink Note 217368.1) may also required to demonstrate that a particular port is accessible through one or more firewalls.


[Unrelated postscript:  Possibly due to sunspots, the lunar cycle, or global warming, any emails you sent me on March 11 or March 12, 2007 may be delayed, possibly indefinitely.  If you sent me anything in that time, I'd recommend resending it.]



I have two application servers node 1 and node 2 one on site A and the other on SiteB.
The same configuration is for the databases.The site is attached to SAN storage that is replicated (synchronous) from production to DRP. In the event of a disaster, the volumes on the BCP site will be mounted to the BCP server and the database and application will be started.

I want to configure the application on a virtual host name / ip.
The app version in and database is on on RH Linux 5.10.

Is this configuration possible?
I have just started to play with Linux, could you please let me know if this configuration requires a Linux cluster? How to configure a virtual IP in Linux to support this setup?

Any help is appreciated.

Thanks and regards,


Posted by Nelton Kuruvilla on March 24, 2014 at 04:40 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed


« August 2016