How Many IPs Do You Need for a 2-Node Oracle RAC? (And Why Each One Matters)

• Pradip
• 24 Jul, 2025
• 0 Comments
• 6 Mins Read

How Many IPs Do You Need for a 2-Node Oracle RAC? (And Why Each One Matters)

If you’re planning to set up Oracle RAC for the first time or even revisiting the process after some time, one question you’ll inevitably run into is: How many IP addresses do I need, and why? As someone who has worked with Oracle RAC across different environments, I can tell you with certainty — this is where many get stuck early in the planning stage.

So let’s take a deep dive and understand exactly what IPs are required in a 2-node Oracle RAC setup, why each of them is important, what problems can occur if they are misconfigured, and how to avoid those pitfalls.

---

The Magic Number: 9 IP Addresses

Yes, that’s right. For a standard 2-node Oracle RAC (Real Application Cluster) configuration, you’ll need a total of 9 IP addresses. Let’s break this down before we dig into each component in detail:

1. 2 Public IPs (one per node)
2. 2 Private IPs (one per node for interconnect)
3. 2 VIPs (Virtual IPs for failover)
4. 3 SCAN IPs (Single Client Access Name, used for load balancing and connection management)

Let me explain each one and walk you through practical considerations for each.

each.

---

Oracle RAC 2-Node IP Topology Diagram

1. Public IPs (Node IPs)

These are the basic IPs of the two RAC nodes that communicate with the outside world. These are the IPs you will typically SSH into or use to check basic node availability.

• Node1: 192.168.1.101
• Node2: 192.168.1.102

Real-World Scenario:

I once worked with a team that reused IPs from a dev subnet for production, without proper DNS or static mapping. The result? RAC kept failing during install due to hostname mismatches. Always ensure these are static IPs and properly mapped in /etc/hosts or DNS.

---

2. Private IPs (Interconnect IPs)

These IPs are used by Oracle RAC for interconnect communication. That means cache fusion, heartbeat checks, and other internal cluster traffic.

• Node1 private IP: 192.168.2.101
• Node2 private IP: 192.168.2.102

These should be in a dedicated, isolated VLAN, ideally over a high-speed interface (1Gbps minimum, 10Gbps preferred).

Real-World Scenario:

In one customer setup, interconnect traffic was routed over the same interface as public traffic. During peak load, the interconnect was so congested that cluster nodes kept evicting each other, triggering false node failures.

Always isolate interconnect traffic physically or logically.

---

3. VIPs (Virtual IPs)

These are not tied to a specific physical interface or server. They are used to support transparent failover. If one node goes down, the VIP fails over to the surviving node.

• VIP1: 192.168.1.201 (Node1)
• VIP2: 192.168.1.202 (Node2)

Clients connect through these VIPs instead of the node’s public IP. Oracle ensures the VIP is always hosted on an available node.

What Happens if VIP Fails?

If the VIP is unreachable or not configured properly, connections might hang during failover instead of failing fast. This will frustrate your application teams.

I always use this command to check VIP status:

bash
srvctl config vip
srvctl status vip

If you ever find VIPs not online, restart the VIP resource:

bash
srvctl start vip -n <node_name>

---

4. SCAN IPs (Single Client Access Name)

This is a game-changer Oracle introduced in 11gR2. Instead of connecting to specific node IPs, clients connect to a single hostname, and Oracle RAC does the intelligent routing via SCAN.

You need 3 SCAN IPs, and they must resolve through DNS (not /etc/hosts).

• SCAN IP1: 192.168.1.210
• SCAN IP2: 192.168.1.211
• SCAN IP3: 192.168.1.212

All these should resolve to one SCAN hostname, for example: racscan.learnomate.local.

Use round-robin DNS configuration like this:

racscan.learnomate.local. IN A 192.168.1.210 racscan.learnomate.local. IN A 192.168.1.211 racscan.learnomate.local. IN A 192.168.1.212

What Happens If SCAN Is Not Working?

If SCAN is not resolving, your listener may not start properly, and connections will fail with:

makefile
ORA-12514: TNS:listener does not currently know of service requested

Also, if SCAN is not load balancing correctly, your sessions may end up concentrated on one node, affecting performance.

Use this to validate:

bash
nslookup racscan.learnomate.local
srvctl config scan
srvctl status scan_listener

Putting It All Together: Network Topology

Let’s visualize the IPs like this:

Make sure each interface is mapped to a dedicated NIC or bonded NICs for redundancy.

---

Common Mistakes You Should Avoid

1. Not using static IPs: RAC setup requires static IPs. Dynamic DHCP IPs will cause cluster instability.
2. SCAN not resolving via DNS: SCAN hostname must not be in /etc/hosts. Always use DNS with round-robin A-records.
3. Interconnects over same network: This is the most overlooked mistake. Use a physically separate interface or VLAN for private IPs.
4. Incorrect /etc/hosts entries: Don’t mix SCAN in hosts file. Only public and private IPs should be listed here.

---

Verifying RAC IP Configuration

Here’s how I usually verify IP configurations before install:

Check network interfaces:

bash
ip addr show

Validate hostname mappings:

bash
ping <hostname> nslookup <SCAN name>

Check clusterware resources:

bash
crsctl stat res -t

You should see VIP and SCAN listeners properly registered and running.

---

Performance Tips Related to IP and Network Config

1. Use Jumbo Frames for interconnects if your switches support it. Set MTU to 9000 bytes. This can improve cache fusion performance significantly.
2. NIC Bonding or teaming for public and private interfaces is highly recommended for HA.
3. Latency matters: Keep interconnect latency under 1ms. Use ping or orachk to evaluate.

Real-Life Lessons from the Field

Let me tell you about a time when everything seemed fine, but VIPs were incorrectly mapped to the wrong subnet. During failover testing, the VIP didn’t move to the surviving node. The client experienced 90 seconds of application downtime before timeout.

The solution was simple but painful to find: the secondary interface didn’t have access to the VIP subnet. Since then, I always use:

bash
ifconfig -a

And validate with:

bash
netstat -nr

Also, when troubleshooting SCAN issues, I’ve found that some DNS servers cache outdated records. Flushing the DNS cache on both server and client sides helped resolve weird connection delays.

---

Final Checklist Before Installation

Use this checklist before you run the Oracle Grid Infrastructure installer:

• Public IPs assigned and reachable
• Private IPs isolated and validated
• VIPs not in use and pingable post-install
• SCAN name resolves to 3 IPs via DNS
• All IPs are static
• NICs are correctly assigned
• DNS round-robin is working as expected
• Firewalls are disabled or properly configured
• Hostnames match in /etc/hosts and DNS
• Time sync (NTP or Chrony) is working

---

Closing Thoughts

Planning the IP addresses for Oracle RAC is not just a formality. It is the foundation for everything that happens afterward — node joining, failover, client connection, service registration, and more. You now know that a simple 2-node RAC setup needs 9 well-configured IP addresses, and you’ve also seen how each plays a vital role in the functioning of the cluster.

If you’re setting up RAC in your environment, take your time on this part. Don’t rush it. Validate everything twice. Trust me, you’ll thank yourself later when your cluster stays healthy and your clients connect smoothly every time.

If you’d like a template of /etc/hosts entries or a DNS configuration snippet, let me know. I’m happy to share what has worked for me across multiple environments.

---

Conclusion

Understanding the IP planning for a 2-node Oracle RAC setup is not just a theoretical need but a practical necessity if you aim to build a high-availability and performance-optimized environment. From Public and Private IPs to SCAN and VIPs, each component plays a vital role in keeping your cluster functional, fail-safe, and scalable.

If you’re someone who’s serious about mastering Oracle RAC and its real-world implementations, we at Learnomate Technologies provide in-depth, hands-on training led by industry experts with years of corporate experience. Our programs are designed with real-time labs, real-world issues, and interview-level scenarios, so you’re never stuck at theory.

For better insights, don’t forget to visit our YouTube channel: www.youtube.com/@learnomate. Want to explore more about different technologies? Check out our blog section: https://learnomate.org/blogs/. Explore our website to know more about our courses and training: www.learnomate.org. Connect with me personally on LinkedIn: Ankush Thavali

Whether you’re just starting out or are already working as a DBA, our content and training are designed to add value at every stage of your journey. Let’s upgrade your skills together, the Learnomate way.