Introduction
Cloud networking is one of those areas that looks simple when you study individual components.
You create a VCN.
You create a subnet.
You attach a route table.
You configure a security list.
You launch a compute instance.
Done.
Except it rarely works that cleanly when you actually build it yourself.
Recently, I worked through a hands-on Oracle Cloud Infrastructure (OCI) networking lab, starting with a VCN and building the networking components required to launch and access a Compute instance.
The interesting part wasn’t simply creating the resources.
The real learning came when the instance was running but I couldn’t connect to it.
That forced me to stop looking at the problem as “SSH isn’t working” and instead trace the networking path from the source to the destination.
This blog documents that process.
1. Creating the VCN
The first step was creating a Virtual Cloud Network (VCN).
The VCN acts as the primary networking boundary for the resources that will be deployed.
For this lab, I created the VCN and then divided the network into four subnets.
OCI_Network.docx
The basic design was:
OCI Region
|
+-- VCN
|
+-- Public Subnet
|
+-- Private Subnet 1
|
+-- Private Subnet 2
|
+-- Private Subnet 3
The intention was to keep only the subnet that needed direct internet accessibility public while keeping the remaining workloads in private subnets.
This is a much better starting point than simply putting everything into a public subnet.
2. Creating the Subnets
The next step was creating the four subnets.
The first subnet was configured as a public subnet.
The other three were configured as private subnets.
OCI_Network.docx
The screenshots in the lab show the subnet creation process, including:
- Subnet name
- Compartment
- Regional/availability-domain configuration
- IPv4 CIDR block
- Route table
- Security list
- Public/private subnet selection
- DNS configuration
The important concept here is that creating a subnet isn’t just defining an IP range.
The subnet becomes part of a larger networking path involving:
Subnet
|
+-- Route Table
|
+-- Security List / NSG
|
+-- Gateway
|
+-- Workload
A mistake in any one of these components can result in connectivity problems.
3. One Public Subnet and Three Private Subnets
For this lab, I kept the design straightforward:
Internet
|
Internet Gateway
|
+--------------+
| Public |
| Subnet |
+--------------+
|
Bastion / Access
|
+--------------+--------------+
| | |
Private Subnet 1 Private Subnet 2 Private Subnet 3
The document specifically records that the remaining three subnets were created as private subnets.
OCI_Network.docx
This separation is important because not every workload needs to be directly exposed to the internet.
For example:
Public subnet
Could contain:
- Bastion host
- Public-facing application components
- Load balancer-related resources
Private subnets
Could contain:
- Database servers
- Application servers
- Internal services
- Backend workloads
The exact workload placement depends on the architecture, but the underlying principle is the same:
Don’t make a resource public simply because it needs outbound or administrative connectivity.
4. Creating Dedicated Route Tables
After creating the subnets, I moved to routing.
I created separate route tables corresponding to the subnets.
OCI_Network.docx
Conceptually:
Public Subnet
|
+---- Public Route Table
|
+---- Internet Gateway
Private Subnet 1
|
+---- Private Route Table
Private Subnet 2
|
+---- Private Route Table
Private Subnet 3
|
+---- Private Route Table
This is where the lab started becoming more interesting.
A route table determines where network traffic should go.
It doesn’t provide security by itself.
That distinction is important.
5. Routing vs Security
One of the biggest lessons from this exercise was that routing and security solve different problems.
A simple way to remember it:
Route table
Answers:
“Where should this packet go?”
Security list / NSG
Answers:
“Should this traffic be allowed?”
So if an instance is unreachable, checking only the security rules isn’t enough.
You need to ask:
Can the packet reach the subnet?
↓
Is there a route?
↓
Is the required gateway available?
↓
Is the destination reachable?
↓
Does the security configuration allow it?
That mindset became important later when troubleshooting my SSH connection.
6. Creating Security Lists
Next, I created security lists for the subnets.
OCI_Network.docx
The subnet configuration was then modified to use the appropriate security list and route table.
I also removed the old/default security-list association where required.
OCI_Network.docx
The reason for doing this explicitly is simple:
Default configurations can hide what’s actually happening.
When you’re learning or troubleshooting cloud networking, it’s much easier to understand the architecture when you know exactly which route table and security controls are associated with each subnet.
7. Internet Gateway
For the public subnet, I created an Internet Gateway.
The purpose is to provide connectivity between the VCN and the internet when the appropriate routing and security configuration is in place.
The lab also included adding the required route rules for internet access.
OCI_Network.docx
The simplified traffic flow becomes:
Internet
|
v
Internet Gateway
|
v
Public Route Table
|
v
Public Subnet
|
v
Compute Instance
But here’s an important point:
Having an Internet Gateway does not automatically make a workload reachable from the internet.
You still need the correct route and security configuration.
8. Service Gateway
I also created a Service Gateway as part of the networking setup.
OCI_Network.docx
A Service Gateway is useful when private resources need to access supported OCI services without requiring traffic to traverse the public internet.
Conceptually:
Private Subnet
|
v
Route Table
|
v
Service Gateway
|
v
OCI Services
This becomes particularly useful in architectures where backend workloads should remain private while still accessing OCI services.
9. Launching the Compute Instance
Once the networking foundation was ready, I moved on to launching a Compute instance.
The instance creation process included selecting:
- Compartment
- Availability domain
- Image
- Shape
- VCN
- Subnet
- SSH key
The first attempt didn’t go completely smoothly.
I encountered an error during the instance creation process and had to change the selected shape before proceeding.
OCI_Network.docx
After changing the shape, the instance creation proceeded successfully.
OCI_Network.docx
This was another useful reminder:
Cloud provisioning failures aren’t always networking failures.
When something fails during provisioning, first determine whether you’re dealing with:
- Capacity
- Shape availability
- Image compatibility
- Permissions
- Quotas
- Networking
- Configuration
Don’t immediately assume every failure is caused by the network.
10. Trying to Connect to the Instance
After the instance was running, I attempted to connect using the private key.
And this is where the actual troubleshooting started.
The instance was up.
The networking configuration appeared to be in place.
But the SSH connection wasn’t working.
OCI_Network.docx
This is the point where it’s tempting to start randomly modifying firewall and security rules.
I didn’t want to do that.
Instead, I started checking the configuration step by step.
11. Finding the Root Cause
Eventually, I found the problem.
The issue wasn’t that the instance was down.
The problem was the route-table association.
I had created a route table named:
public
instead of the intended:
public_subnet_RT
The subnet was therefore associated with the wrong route table.
OCI_Network.docx
This is a very simple mistake.
But the impact was significant.
The instance could be running perfectly while the network path required for connectivity was incorrect.
That is exactly why cloud troubleshooting requires understanding the architecture rather than just looking at the status of individual resources.
12. Correcting the Route Table
I corrected the subnet configuration and attached the correct route table.
The instance networking configuration then showed the expected route table association.
OCI_Network.docx
After that, I also reviewed the ingress and egress rules.
OCI_Network.docx
The important lesson here is:
Don’t change ten things at once.
If you modify the route table, security list, subnet, gateway and instance configuration simultaneously, you may eventually make it work—but you won’t know what actually fixed the problem.
A better troubleshooting approach is:
Identify the symptom
↓
Check the network path
↓
Validate routing
↓
Validate gateway
↓
Validate security
↓
Make one change
↓
Test again
13. Final SSH Connectivity
After correcting the configuration and reviewing the ingress/egress rules, the SSH connection succeeded.
The final screenshot shows the successful connection to the OCI Compute instance using the private key.
OCI_Network.docx
That was the actual “aha” moment of the exercise.
Not because SSH finally worked.
But because the troubleshooting process demonstrated something much more important:
A running cloud resource does not mean the network path to that resource is correct.
14. What I Learned from This Lab
There were several practical takeaways from this exercise.
1. Understand the packet path
When troubleshooting connectivity, don’t start by randomly changing security rules.
Trace:
Source
↓
Route Table
↓
Gateway
↓
Subnet
↓
Destination
↓
Security Controls
The exact path depends on the architecture, but the principle remains.
2. Routing and security are not the same thing
A security rule allowing SSH doesn’t guarantee SSH connectivity.
You can have:
SSH allowed
+
Instance running
+
Public IP assigned
and still fail to connect if the routing path is wrong.
That’s exactly the type of problem I encountered in this lab.
3. Naming matters more than it looks
My route-table naming mistake was small:
public
instead of:
public_subnet_RT
But the real issue wasn’t the name itself.
The issue was that I associated the wrong resource with the subnet.
In larger environments, consistent naming becomes even more important because you’re dealing with potentially hundreds or thousands of cloud resources.
4. Don’t blindly depend on default configurations
The exercise involved creating dedicated route tables and security lists and explicitly associating them with the relevant subnets.
OCI_Network.docx
That makes the architecture easier to understand and troubleshoot.
In production, however, the exact design should be driven by security and operational requirements rather than simply copying a lab pattern.
15. The Bigger Cloud Networking Lesson
The biggest takeaway for me wasn’t how to click through the OCI console.
It was this:
Cloud networking is about relationships.
A subnet doesn’t exist in isolation.
A route table doesn’t exist in isolation.
A security list doesn’t exist in isolation.
A gateway doesn’t exist in isolation.
They work together.
Think about it as:
INTERNET
|
|
+---------------+
| Internet GW |
+---------------+
|
v
+---------------+
| Route Table |
+---------------+
|
v
+---------------+
| Public Subnet |
+---------------+
|
v
+---------------+
| Compute |
| Instance |
+---------------+
|
Security Rules
If one relationship is wrong, connectivity can fail.
16. From “Is It Reachable?” to “Should It Be Reachable?”
There’s also a broader shift happening in cloud networking.
Traditional networking often starts with:
Can this workload communicate with that workload?
Modern cloud security increasingly asks:
Should this workload be allowed to communicate with that workload in the first place?
That’s where concepts such as Zero Trust become important.
The goal isn’t simply to make everything reachable.
The goal is to make the right things reachable, through the right paths, under the right security policies.
That’s a much better mindset for cloud infrastructure.
Conclusion
This OCI networking exercise started as a simple hands-on lab.
Create a VCN.
Create four subnets.
Configure route tables.
Configure security lists.
Create gateways.
Launch an instance.
Connect to it.
But the most valuable part happened when it didn’t work.
The incorrect route-table association forced me to troubleshoot the networking path instead of assuming the problem was SSH or security rules.
OCI_Network.docx
That’s the kind of learning that doesn’t come from simply reading documentation.
You build it.
You break it.
You troubleshoot it.
And then you understand it.
My practical checklist for OCI connectivity troubleshooting
☑ Is the instance running?
☑ Is the correct subnet associated?
☑ Is the correct route table attached?
☑ Is the required gateway configured?
☑ Are the route rules correct?
☑ Is the security list/NSG allowing the traffic?
☑ Are ingress rules correct?
☑ Are egress rules correct?
☑ Is the correct SSH key being used?
☑ Can I trace the traffic path end-to-end?
The biggest lesson:
Don’t troubleshoot cloud connectivity by guessing. Trace the path.
That approach is useful far beyond OCI—it applies to AWS, Azure, Kubernetes networking, database connectivity, and pretty much every distributed infrastructure environment.
#OracleCloud #OCI #CloudNetworking #CloudInfrastructure #Networking #CloudSecurity #ZeroTrust #DevOps #Infrastructure #Oracle #DatabaseAdministration #DBA #LearningByDoing
Comments
Post a Comment