Oracle RAC Networking Explained: Public Network, Private Interconnect, VIP, SCAN, and Listeners
Network configuration is one of the most important aspects of an Oracle RAC environment. A well-designed network provides reliable client connectivity, fast inter-node communication, and seamless failover. Conversely, many RAC issues—such as node evictions, connection failures, and poor performance—can be traced back to network misconfigurations.
In this article, we’ll explore the networking components of Oracle RAC, explain how they interact, and review the tools and commands used to verify and troubleshoot them.
Why RAC Uses Multiple Networks
Unlike a single-instance database, Oracle RAC separates client traffic from cluster communication.
A typical RAC deployment uses:
- Public Network – Client connections.
- Private Interconnect – Communication between RAC nodes.
- Virtual IP (VIP) – Fast client failover.
- SCAN – Single client access point.
- Listeners – Accept and route client connections.
Each network has a specific role and should never be considered interchangeable.
Oracle RAC Network Architecture
A simplified two-node architecture:
Clients
|
+----------------+
| DNS / SCAN |
+-------+--------+
|
Public Network
|
+-----------------+-----------------+
| |
+----------+ +----------+
| Node 1 | | Node 2 |
+----------+ +----------+
| VIP | | VIP |
| Listener | | Listener |
+----------+ +----------+
| |
+---------------+-------------------+
|
Private Interconnect
|
+---------------+-------------------+
| |
Cache Fusion Cluster Heartbeat
Public Network
The public network is used by:
- Applications
- DBAs
- Oracle Enterprise Manager
- RMAN clients
- SQL*Plus
- JDBC
- ODP.NET
Every RAC node has its own public IP.
Example:
| Node | Public IP |
|---|---|
| racnode1 | 192.168.100.101 |
| racnode2 | 192.168.100.102 |
Verify:
ip addr
or
hostname -I
Private Interconnect
The private interconnect is reserved for cluster communication.
It carries:
- Cache Fusion traffic
- Global Cache Service (GCS)
- Global Enqueue Service (GES)
- Cluster heartbeat
- Cluster synchronization
Example:
| Node | Private IP |
|---|---|
| racnode1 | 10.10.10.1 |
| racnode2 | 10.10.10.2 |
Verify interface configuration:
oifcfg getif
Example:
eth0 192.168.100.0 global public eth1 10.10.10.0 global cluster_interconnect
Why the Private Interconnect Matters
Every time one RAC instance needs a data block that is currently in another instance’s cache, Oracle transfers that block through the private network.
Example:
Instance 1
Buffer Cache
|
Private Interconnect
|
Instance 2
Buffer Cache
The private interconnect should have:
- Low latency
- High bandwidth
- Redundancy
Oracle commonly recommends 10 GbE or faster for production RAC environments, especially where Cache Fusion traffic is significant.
Virtual IP (VIP)
Each RAC node has:
- One Public IP
- One VIP
Example:
| Node | Public | VIP |
|---|---|---|
| racnode1 | 192.168.100.101 | 192.168.100.111 |
| racnode2 | 192.168.100.102 | 192.168.100.112 |
Why use VIPs?
When a node fails:
Without VIP:
Client | Dead Node (wait TCP timeout)
Clients wait until the TCP timeout expires.
With VIP:
Client | VIP moves immediately | Connection fails quickly Reconnect
Applications receive an immediate network error and can reconnect much sooner.
SCAN (Single Client Access Name)
One of the major improvements introduced with Oracle RAC 11g is SCAN.
Before SCAN:
Application | Node1 Listener Node2 Listener Node3 Listener
Applications needed to know every node.
With SCAN:
Application | rac-scan.wadhahdaouehi.tn | SCAN Listener | Cluster
The application connects using a single hostname, while Oracle routes the session to an appropriate node.
Benefits include:
- Simpler client configuration.
- Easier cluster expansion.
- Improved connection load balancing.
SCAN Listeners
A RAC cluster typically uses three SCAN listeners.
Verify:
srvctl status scan_listener
Example:
SCAN Listener LISTENER_SCAN1 is enabled SCAN Listener LISTENER_SCAN2 is enabled SCAN Listener LISTENER_SCAN3 is enabled
Check configuration:
srvctl config scan_listener
Local Listener
Each RAC node also runs a local listener.
Verify:
srvctl status listener
Example:
Listener LISTENER is running on node racnode1 Listener LISTENER is running on node racnode2
Local listeners accept client connections and register local database services.
SCAN Resolution
Oracle recommends that the SCAN name resolve to three IP addresses.
Example:
nslookup rac-scan.wadhahdaouehi.tn
Expected:
192.168.100.120 192.168.100.121 192.168.100.122
These addresses should map to the SCAN listeners managed by Clusterware.
Verify Network Configuration
Display network resources:
srvctl config network
Check VIPs:
srvctl config vip
Check SCAN:
srvctl config scan
Display interfaces:
oifcfg iflist -p -n
These commands provide a quick overview of the RAC network configuration.
Verify Listener Status
Using lsnrctl:
lsnrctl status
Useful information includes:
- Listening endpoints.
- Registered services.
- Database instances.
- Connection statistics.
Test Client Connectivity
Connect using SCAN:
sqlplus system@rac-scan.wadhahdaouehi.tn:1521/orcl
Check the connected instance:
SELECT instance_name FROM v$instance;
Run the connection several times to observe how sessions are distributed across instances.
Load Balancing
Oracle RAC provides two forms of load balancing.
Client-side Load Balancing
The client chooses one of the available SCAN listeners.
Server-side Load Balancing
The listener directs the connection to the instance offering the best service based on current workload.
Using services instead of connecting directly to an instance improves both scalability and flexibility.
Common Network Problems
SCAN Does Not Resolve
Symptoms:
- Connection failures.
- ORA-12545.
- ORA-12154.
Verify:
nslookup rac-scan.wadhahdaouehi.tn
VIP Offline
Check:
srvctl status vip
Possible causes:
- Network configuration.
- Interface failure.
- Cluster resource issue.
Listener Not Running
Verify:
srvctl status listener
Start if necessary:
srvctl start listener
Always use srvctl rather than starting the listener manually in a RAC environment.
Slow Cache Fusion
Possible causes:
- High interconnect latency.
- Packet loss.
- Incorrect MTU settings.
- Network congestion.
Monitor the private interconnect before investigating database-level tuning.
Node Evictions
Many node evictions are related to:
- Private network interruptions.
- Storage delays.
- CPU starvation.
Check Clusterware logs before assuming a database problem.
Useful RAC Networking Commands
Check node names:
olsnodes -n
Display interface configuration:
oifcfg getif
Check VIP status:
srvctl status vip
Check SCAN listeners:
srvctl status scan_listener
Check local listeners:
srvctl status listener
View cluster resources:
crsctl stat res -t
These commands should become part of every RAC administrator’s troubleshooting toolkit.
Best Practices
- Separate public and private traffic.
- Use redundant network interfaces for the private interconnect.
- Configure SCAN through DNS in production environments.
- Always connect applications using services rather than specific instances.
- Manage listeners, VIPs, and SCAN resources with
srvctl. - Monitor interconnect latency and packet loss as part of routine health checks.
DBA Tip
One of the most common mistakes I see is troubleshooting a RAC networking issue from the database layer first.
If users report connection problems, begin with the network:
- Is the VIP online?
- Does the SCAN name resolve correctly?
- Are the SCAN listeners running?
- Are the local listeners registered?
- Is the private interconnect healthy?
Only after confirming these components should you investigate database sessions or SQL performance.
In RAC, many “database problems” start as network problems. A systematic check of the networking stack often leads to the root cause much faster.
Conclusion
Oracle RAC networking is more than assigning IP addresses. It combines public networking, private interconnects, VIPs, SCAN listeners, and local listeners into a resilient architecture that supports high availability, efficient workload distribution, and rapid failover.
A solid understanding of these components is essential for both successful deployments and effective troubleshooting.
Google+
Facebook
