fast & free: OCI Networking

FREE: exam, practice questions and FAST: study material with equivalent AWS, Azure and Google Cloud Services.

Whatis? — **Practice Questions** — Friend Link

1. Implementing and Managing Virtual Cloud Networks

The Virtual Cloud Network (VCN) is the foundational networking component in OCI. It is a customizable, private network that isolates your cloud resources from the rest of the world.

Multi-Cloud Comparison

Networking is a fundamental concept in computing, so the core principles are very similar across all major clouds. This makes the multi-cloud comparison relatively straightforward, but it is critical to keep in mind how each provider implements its security and routing services.

Analogies with AWS: The VCN is the direct equivalent of an AWS VPC (Virtual Private Cloud). Both are the isolated, private networks where you launch your cloud resources.

Analogies with GCP: In GCP, the equivalent is a VPC Network. Both OCI’s VCN and GCP’s VPC Network are global resources, though subnets are regional.

Analogies with Azure: The VCN is analogous to a Virtual Network (VNet) in Azure.

2. Describing Public and Private Subnets

A subnet is a range of IP addresses within a VCN. Subnets are further categorized as either public or private. Public subnets have a route to an Internet Gateway, allowing instances within them to have public IP addresses and communicate directly with the internet. Private subnets do not have a route to an Internet Gateway. Instances in private subnets cannot receive inbound public traffic, making them more secure for internal applications and databases. To access the internet from a private subnet, you must use a NAT Gateway.

Multi-Cloud Comparison

The concept of public and private subnets is foundational to cloud networking, but the implementation details can differ.

Analogies with AWS: The concept of public and private subnets is identical. You create an Internet Gateway and attach it to your VPC, and then you use a route table on a public subnet to direct traffic to it.

Analogies with GCP: GCP is a little different. Its VPC networks are global, and by default, all subnets have a route to the internet. You do not explicitly attach an Internet Gateway. To create a private subnet, you must use a firewall rule to block all egress traffic.

Analogies with Azure: The concept of public and private subnets is identical, and is managed through the use of gateways and route tables, similar to AWS and OCI.

3. Describing Public and Private IP Addresses and Virtual NICs

Private IP addresses are internal, non-routable IP addresses assigned to instances for communication within the VCN. A Public IP address is a routable IP assigned to an instance that allows it to communicate with the internet. A Virtual NIC (VNIC) is a virtual network interface card that enables an instance to connect to a VCN subnet.

“Routable” means an IP address can be found and reached across the entire global internet via routers.

Each instance has a primary VNIC, and can have multiple secondary VNICs attached. Every VNIC is assigned a primary private IP address from the address space (CIDR block) of its subnet. This IP is used for all communication within the VCN. A VNIC can also be assigned multiple secondary private IPs. A Public is mapped to a specific private IP (either primary or secondary) on a VNIC. The OCI gateway performs the Network Address Translation (NAT) between the public address and the private address it’s mapped to.

• VNICs per VM: A VM can support between 2 and 32 VNICs.
• Private IPs per VNIC: Each VNIC can support between 2 and 256 private IPs.

256 Private IPs for VNIC: what for?

This is amazing!

This architecture, built on multiple VNICs and Secondary Private IPs, is leveraged by Oracle Container Engine for Kubernetes (OKE) through the OCI VCN-Native Pod Networking CNI plugin. This CNI is not just an integration; it's a direct performance injection.

The plugin performs a critical, one-to-one mapping: it assigns every Kubernetes Pod a unique, routable Secondary Private IP directly from your Virtual Cloud Network (VCN).

This ability to integrate OCI's native networking capabilities right down to the container level means:

• Automation: You can apply core VCN features like Network Security Groups (NSGs) and VCN Flow Logs to individual Pod IPs, enabling granular, highly secure network policies managed entirely through Infrastructure as Code.
• Performance: You eliminate the need for an inefficient network overlay or complex NAT, ensuring every container communicates at the highest possible native VCN speed with minimal latency.

Do you want to understand the magin of K8s architecture? try: Cloud Native: The Architectural Brilliance of Container Interfaces

Multi-Cloud Comparison

Analogies with AWS: A Public IP is similar to an AWS Elastic IP, a Private IP is a standard private IP, and a VNIC is an Elastic Network Interface (ENI).

Analogies with GCP: A Public IP is similar to an External IP address, a Private IP is an Internal IP address, and a VNIC is a Network Interface.

Analogies with Azure: A Public IP is similar to an Azure Public IP, a Private IP is a private IP, and a VNIC is a Network Interface Card (NIC).

4. Configuring Virtual Cloud Network Routing and Gateways

Route tables are virtual tables that contain rules to route traffic from a subnet to a destination. Gateways are entry and exit points for traffic in and out of the VCN.

• An Internet Gateway provides a path for public subnets to connect to the internet.
• A NAT Gateway enables instances in a private subnet to make outbound connections to the internet without exposing the instances to inbound public traffic.
• A Service Gateway provides a secure, private way for instances to access public OCI services (like Object Storage) without using an Internet Gateway or NAT Gateway.

Multi-Cloud Comparison

Analogies with AWS: An Internet Gateway and NAT Gateway are identical concepts. OCI’s Service Gateway is similar to an AWS Gateway Endpoint for services like S3.

Analogies with GCP: An Internet Gateway is analogous to a default internet route. A NAT Gateway is similar to Cloud NAT. A Service Gateway is similar to Private Service Connect.

Analogies with Azure: An Internet Gateway is a default route to the internet. A NAT Gateway is a similar service. A Service Gateway is analogous to VNet Service Endpoints or Private Link.

5. Configuring Security Lists and Network Security Groups

Security Lists (SLs) and Network Security Groups (NSGs) are both virtual firewalls that control traffic at the packet level. Security Lists can be configured as either stateful or stateless, but are stateful by default and apply at the subnet level. Network Security Groups (NSGs) are stateful by default and apply at the VNIC level. They provide a more granular, fine-grained control over network traffic for individual instances. Using NSGs is the recommended best practice for most applications.

Multi-Cloud Comparison

Analogies with AWS: OCI’s Security Lists are comparable to AWS Network ACLs, while OCI’s NSGs are similar to AWS Security Groups. The key difference is that NSGs are stateful while Security Lists are stateless.

Analogies with GCP: This functionality is achieved with GCP’s Firewall Rules, which are also stateful and can be applied to individual VMs using network tags.

Analogies with Azure: The functionality is almost identical to Azure’s Network Security Groups (NSGs), which are also stateful and can be applied to subnets or individual network interfaces.

6. Implementing and Managing VCN Connectivity

OCI provides several options to connect your VCN to other VCNs, whether in the same region or different regions, as well as to your on-premises network. The central component for managing all of these connections is the Dynamic Routing Gateway (DRG). The DRG acts as a virtual router that serves as a single, central hub for all network connections in a hub-and-spoke topology. Think of the DRG as a “network jolly” — a universal connector that simplifies complex network connections. Instead of configuring point-to-point connections between every VCN and on-premises network, all connections terminate at a single DRG. It can route traffic between a VCN, on-premises networks via VPN or FastConnect, and even other VCNs. This simplifies complex network topologies and provides a single point of control.

Use Cases for the DRG:

• Hub-and-Spoke Topology: A common use case is connecting multiple VCNs (the spokes) to a central on-premises network (the hub). The DRG acts as the central router, allowing all the VCNs to communicate with the on-premises network without needing individual connections.
• Inter-VCN Communication: The DRG is essential for allowing private communication between VCNs, especially for applications that span multiple VCNs across different regions. It can be used to set up remote VCN peering, enabling traffic to flow securely and privately without going over the public internet.

Multi-Cloud Comparison

The concept of connecting networks is the same everywhere, but the DRG is a critical, single component to keep in mind for managing connectivity in OCI.

Analogies with AWS: The AWS Transit Gateway is the direct equivalent of the DRG. Both are designed to simplify complex networking by acting as a central hub for VCN/VPC connections, which is different from a simple VNet peering or VPN gateway.

Analogies with GCP: GCP uses Cloud Routers to manage routing for connections between VPC Networks and to on-premises. GCP VPC are global so they don’t need connections between regional VPCs.

Analogies with Azure: Azure uses a VPN Gateway or ExpressRoute Gateway to manage connections.

7. Evaluating VCN Connectivity Options

When connecting a VCN to an on-premises network, you have two primary options: Site-to-Site VPN and FastConnect.

• A Site-to-Site VPN creates an encrypted connection over the public internet, providing a secure, but not guaranteed, connection.
• FastConnect provides a private, dedicated physical network connection, bypassing the public internet entirely. It offers higher bandwidth, lower latency, and more consistent performance.

Multi-Cloud Comparison

Analogies with AWS: A Site-to-Site VPN is an identical service. FastConnect is analogous to AWS Direct Connect.

Analogies with GCP: A Site-to-Site VPN is analogous to Cloud VPN. FastConnect is analogous to Cloud Interconnect.

Analogies with Azure: A Site-to-Site VPN is an identical service. FastConnect is analogous to Azure ExpressRoute.

8. Configuring Site-to-Site VPN

A Site-to-Site VPN connects your on-premises network to your VCN using an encrypted tunnel over the internet. To configure this, you need a Customer-Premises Equipment (CPE) on your end and a Dynamic Routing Gateway (DRG) and a VPN Connect in OCI.

Multi-Cloud Comparison

Analogies with AWS: The configuration is similar, involving a VPN Gateway and a Customer Gateway.

Analogies with GCP: The configuration involves a VPN Gateway and a peer VPN Gateway on your on-premises network.

Analogies with Azure: The configuration is similar, involving an Azure VPN Gateway and a Local Network Gateway on your on-premises network.

9. Describing FastConnect

FastConnect is a dedicated, private connection between your data center and OCI. This service uses a private circuit from a third-party provider to connect directly to OCI’s network, which is ideal for mission-critical applications or workloads that require high bandwidth and low, predictable latency.

Multi-Cloud Comparison

Analogies with AWS: FastConnect is analogous to AWS Direct Connect.

Analogies with GCP: FastConnect is analogous to Cloud Interconnect.

Analogies with Azure: FastConnect is analogous to Azure ExpressRoute.

10. Configuring Local and Remote Peering

Important! Asked often in the exam!

Local Peering Gateways (LPGs) are used to connect two VCNs that are located within the same OCI region. This allows resources in both VCNs to communicate privately using private IP addresses. Each VCN requires an LPG, and you establish a peering relationship between them. This is typically used to connect VCNs in the same region that belong to different departments or organizations.

Remote Peering Connections (RPCs) are used to connect two VCNs that are located in different OCI regions. Similar to an LPG, this allows resources in geographically separated VCNs to communicate privately. However, the connection is established over the OCI backbone network, ensuring a secure and low-latency link without needing to use the public internet.

The key takeaway is simple:

• LPG = Peering in the same region.
• RPC = Peering in different regions.

Both of these peering methods are managed by a Dynamic Routing Gateway (DRG), which is attached to each VCN and handles the routing of traffic between them.

Multi-Cloud Comparison

Analogies with AWS: Local VCN Peering is similar to AWS VPC Peering, while Remote VCN Peering is similar to Inter-Region VPC Peering.

Analogies with GCP: Both local and remote peering are handled by VPC Network Peering.

Analogies with Azure: Both local and remote peering are handled by VNet Peering.

11. Implementing Transit Routing Scenarios

Transit routing allows a single VCN (the hub) to connect to multiple other VCNs or on-premises networks (the spokes). In OCI, this is achieved by attaching all the spoke VCNs and on-premises connections to a central DRG. The DRG handles the routing between all these connected networks, creating a scalable “hub-and-spoke” architecture.

IMPORTANT: The reason the Dynamic Routing Gateway (DRG) requires a specific VCN is a key architectural difference between OCI and AWS. In OCI, the VCN is the core networking fabric. The DRG is not a standalone service like the AWS Transit Gateway; instead, it is a virtual router that ATTACHES to a VCN, which serves as its central hub. This design keeps the VCN at the center of the network, with the DRG acting as a tool to extend the VCN’s connectivity to other networks.

Multi-Cloud Comparison

Analogies with AWS: This is analogous to using an AWS Transit Gateway to connect multiple VPCs and on-premises networks.

Analogies with GCP: This is analogous to using a Cloud Router and a hub-and-spoke topology.

Analogies with Azure: This is analogous to Azure Virtual WAN or using a central VNet with VNet Peering.

12. Configuring DNS and Traffic Management

OCI’s DNS service allows you to manage and resolve domain names for your applications and resources. This is a crucial service for ensuring your applications are reachable.

Multi-Cloud Comparison

Analogies with AWS: The OCI DNS service is comparable to AWS Route 53.

Analogies with GCP: The OCI DNS service is comparable to GCP Cloud DNS.

Analogies with Azure: The OCI DNS service is comparable to Azure DNS.

13. Describing Public and Private DNS Zones

Public DNS zones manage DNS records for domains that are accessible from the public internet. Private DNS zones manage DNS records that are only resolvable within a specific VCN or set of VCNs. This allows you to use a consistent naming convention for internal resources without exposing them to the public internet.

Multi-Cloud Comparison

Analogies with AWS: This is the same concept as Public and Private Hosted Zones in AWS Route 53.

Analogies with GCP: This is the same concept as Public and Private Managed Zones in GCP Cloud DNS.

Analogies with Azure: This is the same concept as Public and Private DNS Zones in Azure DNS.

14. Configuring Traffic Management Steering Policies

Traffic Management Steering Policies in OCI allow you to create rules that control how DNS queries are resolved and where traffic is directed. This is a powerful feature for improving application performance and availability. For example, you can route users to the closest data center based on their geographic location or fail over to a backup endpoint if the primary one is unhealthy.

Multi-Cloud Comparison

Analogies with AWS: This is analogous to using Route 53 Traffic Flow policies.

Analogies with GCP: This is analogous to Cloud DNS traffic steering policies.

Analogies with Azure: This is analogous to Azure Traffic Manager profiles.

15. Explaining Load Balancer Concepts

A Load Balancer is a service that distributes incoming network traffic across multiple backend servers to ensure no single server is overwhelmed. This increases the availability and reliability of your applications and allows you to scale horizontally. Load balancers operate at different layers of the network model: Layer 7 (Application) load balancers handle HTTP/HTTPS traffic, and Layer 4 (Network) load balancers handle TCP/UDP traffic.

16. Describing and Configuring Load Balancer and Network Load Balancer

OCI provides two distinct load balancing services. The Load Balancer is a Layer 7 load balancer that handles application-level traffic (HTTP/HTTPS) and provides advanced features like SSL termination. The Network Load Balancer is a Layer 4 load balancer that handles TCP/UDP traffic with high performance and low latency. The NLB is non-proxying, preserving the original source IP address.

Multi-Cloud Comparison

Analogies with AWS: This is a direct parallel to AWS’s Application Load Balancer (ALB) and Network Load Balancer (NLB).

Analogies with GCP: The functionality is integrated into GCP’s Cloud Load Balancing service, which can be configured for both L4 and L7 traffic.

Analogies with Azure: This is a direct parallel to Azure’s Application Gateway (L7) and Azure Load Balancer (L4).

17. Implementing Web Application Acceleration

Web Application Acceleration (WAA) is a service that can speed up traffic on your layer 7 HTTP load balancers by applying a combination of caching and compression. A web application acceleration policy includes the caching or caching and compression and is assigned to a load balancer as an acceleration resource of the policy. The Web Application Acceleration service is available to regular OCI customers for free, but it is not available for Free Tier users.

Multi-Cloud Comparison

Analogies with AWS: The caching and performance features of WAA are similar to AWS CloudFront and its distribution capabilities.

Analogies with GCP: This is analogous to the caching features of GCP’s Cloud CDN (Content Delivery Network).

Analogies with Azure: This is analogous to Azure’s CDN (Content Delivery Network) services.

18. Implementing Network Command Center Services

The Network Command Center is a suite of advanced networking services in OCI that help you manage, analyze, and troubleshoot your network environment. These services provide deep visibility and are essential for maintaining the health of a complex network. The key services are covered in the following sections.

19. Analyzing Inter-Region Latency

This is a built-in OCI tool that allows you to measure and analyze the network latency between different OCI regions. This is invaluable for planning multi-region architectures, such as for disaster recovery or global applications, where network performance is critical.

Multi-Cloud Comparison

Analogies with AWS: There is no direct native tool for this in the AWS console, though third-party services provide similar functionality.

Analogies with GCP: GCP’s Cloud Speed Test and components of its Network Intelligence Center offer similar functionality.

Analogies with Azure: Azure Speed Test provides similar metrics, and Network Watcher can be used for more detailed analysis.

20. Implementing Network Visualizer

The Network Visualizer is a tool that provides a graphical representation of your VCN topology. You can use it to visualize your VCNs, subnets, instances, and the connections between them, making it easy to understand and troubleshoot your network configuration.

Multi-Cloud Comparison

Analogies with AWS: There is no direct native tool for this in the AWS console, though third-party services provide similar functionality.

Analogies with GCP: GCP’s Network Intelligence Center provides a similar network topology visualization.

Analogies with Azure: Azure’s Network Watcher has a Network Topology feature that is directly analogous.

21. Troubleshooting using Network Path Analyzer

Network Path Analyzer is a diagnostic tool that helps you trace the path of network traffic between two endpoints. It analyzes your VCN’s configuration (route tables, security lists, NSGs) and identifies any misconfigurations that might be blocking traffic, saving you significant time when troubleshooting connectivity issues.

OCI has a service that is very similar to AWS Systems Manager Session Manager. The OCI service is called the Bastion service. It provides secure, limited-time access to target resources like compute instances that do not have public IP addresses. This eliminates the need for you to manage a jump server or bastion host yourself. Instead of connecting to your instances directly using SSH, you create a Bastion session. The service then creates a secure tunnel, and you can connect to your private instance using your standard SSH client. This provides an auditable, secure, and ephemeral way to access your instances, much like Session Manager.

Multi-Cloud Comparison

Analogies with AWS: This is analogous to AWS’s VPC Reachability Analyzer.

Analogies with GCP: This is analogous to GCP’s Network Intelligence Center Connectivity Tests.

Analogies with Azure: This is analogous to Azure’s Network Watcher Connection Troubleshoot.

22. Implementing Capture Filters and Virtual Test Access Points

Virtual Test Access Points (VTAPs) are a feature that allows you to mirror the traffic from a VNIC and send it to a network analysis tool, such as an intrusion detection system (IDS) or a packet analyzer. Capture Filters are used with VTAPs to specify exactly what traffic you want to mirror based on criteria like source/destination IP, port, and protocol, helping to reduce the amount of data you need to analyze.

Multi-Cloud Comparison

Analogies with AWS: This is analogous to AWS’s VPC Traffic Mirroring.

Analogies with GCP: This is analogous to GCP’s Packet Mirroring and VPC Flow Logs.

Analogies with Azure: This is analogous to Azure’s Virtual Network TAP.