CCNA Networking Questions

The IP Hash load balancing policy uses a hash-based algorithm derived from the client's source and destination IP addresses to route incoming requests. This technical mechanism directly satisfies the requirement to ensure that requests from the same client always reach the same backend server, maintaining session persistence based entirely on network layer identifiers without needing application-level cookies.

Allocating the web subnet a 172.16.1.0/24 CIDR provides 256 addresses (254 usable), accommodating the required 100 hosts. The app subnet uses 172.16.2.0/24, yielding 254 usable IPs to satisfy the 200-host constraint. The database subnet uses 172.16.3.0/26, supplying 62 usable addresses for the 50 hosts. All three subnets fit strictly within the parent VCN CIDR of 172.16.0.0/16, remain entirely non-overlapping, and reserve the necessary Oracle Cloud Infrastructure network addresses per subnet.

Health check probes originate from the Load Balancer's subnet, so the backend instances' security lists or NSGs must permit inbound traffic from that source. Without an ingress rule allowing the probe traffic, health checks fail even though the load balancer itself is configured correctly.

Load balancer rule sets filter client traffic by source IP before it reaches backends, while security lists on the load balancer subnet restrict ingress. Either enforces the corporate IP range restriction at the network edge.

A Dynamic Routing Gateway (DRG) is required because local VCN peering only supports communication within the same region, whereas connecting VCN-1 in Ashburn to VCN-2 in Phoenix necessitates remote Vcn peering across different regions. The DRG acts as a router that provides a path for private traffic between disparate cloud regions, satisfying the geographical constraint of the design scenario by encapsulating and routing packets across the Oracle Cloud Infrastructure backbone.

OCI DNS Secondary DNS lets a private zone act as a secondary, pulling transfers from your on-premises primary, which satisfies the AXFR requirement. TSIG key authentication secures that transfer by validating the shared secret between servers, ensuring only your authorised primary can push zone data into OCI.

Establishing an OCI FastConnect direct peering connection fundamentally requires either a dedicated physical cross-connect directly terminated at an Oracle-designated Meet-Me Room or a virtual circuit provisioned via an approved FastConnect partner provider. This physical or partner-mediated circuit directly satisfies the architectural requirement for dedicated layer connectivity bypassing the public internet, thereby providing the mandatory transport medium for the peering session.

An Oracle Cloud Infrastructure (OCI) Service Gateway directly addresses the constraint of routing traffic to regional Oracle services—such as Object Storage—entirely within Oracle's internal backbone network rather than traversing the public internet. By establishing this private pathway, resources residing within a Virtual Cloud Network (VCN) without public IP addresses can securely consume public cloud endpoints while maintaining strict data sovereignty and compliance postures. This specific architectural mechanism ensures that traffic avoids public routing tables and internet gateways altogether, satisfying both security and network optimisation requirements.

Standard Oracle Cloud Infrastructure virtual network interfaces natively support an MTU of 9,000 bytes, enabling Jumbo Frames for high-throughput workloads. This directly satisfies the maximum packet size constraint specified in the VCN networking architecture, which allows virtual machines to transmit larger data payloads without fragmentation overhead. By accommodating 9,000-byte frames across the underlying physical network infrastructure, OCI significantly reduces CPU encapsulation overhead and improves network performance for bandwidth-intensive database clustering and storage replication tasks.

When a backend takes longer to respond than the listener's idle timeout, the load balancer closes the connection and returns 504. Raising the idle timeout or optimising backend response time resolves the intermittent timeouts users experience.

A public subnet within an Oracle Cloud Infrastructure Virtual Cloud Network is explicitly defined by having at least one route table rule that directs outbound traffic destined for 0.0.0.0/0 to an Internet Gateway, thereby satisfying the primary architectural requirement for public accessibility. Conversely, private subnets lack this specific routing configuration, preventing direct communication with the public internet and ensuring that instances residing within them remain isolated from external inbound connections while still permitting internal VCN communication.

OCI FastConnect satisfies the requirement to securely link an on-premises datacenter to an Oracle Cloud Infrastructure Virtual Cloud Network by establishing a dedicated, high-bandwidth private network connection. Bypassing the public internet entirely, this service utilises either a direct cross-connect via a FastConnect partner or a colocation provider to integrate your local network architecture directly with your cloud resources. This physical or virtual private circuit ensures reliable, predictable throughput with lower latency than standard public internet connections, perfectly fulfilling the high-performance networking constraint specified in the stem.

A Service Gateway only carries traffic whose route table points at it; without a route rule targeting the gateway for the Oracle Services Network service CIDR, database traffic still egresses via the internet gateway or NAT. Adding that rule forces private IP paths, satisfying the bypass requirement.

Private subnets have no implicit internet route, so a route rule targeting the NAT Gateway with destination 0.0.0.0/0 in the private subnet's route table is required. The NAT Gateway then performs source NAT for outbound traffic while blocking inbound connections.

Return traffic needs a route rule whose destination is the on-premises CIDR and whose target is the DRG. Without it, the VCN has no path back, so adding this rule to the subnet's route table satisfies the return-routing constraint.

A Service Gateway allows instances residing in a private subnet to securely route traffic to Oracle Cloud Infrastructure (OCI) public services, such as Logging Analytics, via Oracle's internal backbone network rather than traversing the public internet. This directly satisfies the strict security constraint that instances must not possess internet access while still enabling necessary data egress for telemetry and log management.

A Remote Peering Connection (RPC) must be created on the Dynamic Routing Gateway (DRG) in each region and then paired together, directly satisfying the multi-region connectivity requirement specified in the stem. This resource acts as the logical endpoint that bridges the two DRGs across separate cloud regions, enabling secure and private traffic routing between Virtual Cloud Networks (VCNs) without traversing the public internet.

The Dynamic Routing Gateway (DRG) acts as the essential transit hub that satisfies the requirement to route traffic between an Oracle Cloud Infrastructure private subnet and an on-premises datacenter over a FastConnect virtual circuit. Acting as a virtual router, the DRG establishes the necessary path for private IP traffic to traverse the boundary between the VCN and the customer-premises equipment, bridging the cloud network with the external corporate network infrastructure.

Navigating to the IPSec connection details page beneath the Dynamic Routing Gateway (DRG) reveals the assigned Oracle public IP addresses for both tunnels. This directly satisfies the on-premises firewall requirement by exposing the specific external tunnel endpoints needed to establish the peer-to-peer security associations and complete the IPSec configuration.

The Dynamic Routing Gateway (DRG) serves as the mandatory virtual router at the Oracle Cloud Infrastructure end of the connection, directly satisfying the architectural constraint for routing traffic between the Virtual Cloud Network (VCN) and the on-premises customer premises equipment. To support redundant tunnels, the DRG acts as the central termination point that aggregates multiple IPSec tunnel endpoints, allowing OCI to establish high-availability routing paths and dynamically handle failover events via Border Gateway Protocol (BGP) sessions.

Security lists function as virtual firewalls by enforcing ingress and egress rules at the subnet level, directly satisfying the constraint specified in the question stem. By applying stateful or stateless security rules to all virtual network interface cards associated with a subnet, they provide a centralised mechanism to control traffic flow. This architecture ensures that security policies are consistently applied to every resource within that specific subnet, effectively acting as the primary perimeter defence for network traffic entering or leaving the segment.

Misconfigured BGP peering IPs or ASNs prevent the TCP session from establishing, leaving BGP in Idle rather than Active or Established. Since the Provider model already delivers Layer 2 connectivity, the fault lies at Layer 3 peering configuration between the Oracle and on-premises routers, matching the stem's Idle status.

Routing traffic between Virtual Cloud Networks across different regions, such as Ashburn and Phoenix, requires a Dynamic Routing Gateway (DRG) because VCN local peering is strictly limited to a single region. The DRG acts as a virtual router that connects your VCN to remote peering connections or Oracle Cloud Infrastructure FastConnect circuits, enabling secure, low-latency communication across geographically separated cloud environments within the same tenancy.

Subnets can be added to an existing VCN at any time, since the VCN's CIDR blocks define the address space from which new subnets are carved. This is a supported post-creation action, unlike changing the VCN's CIDR blocks or its compartment.

Flow logs operate by capturing network traffic metadata directly at the virtual network interface card (VNIC) level within a Virtual Cloud Network. This mechanism satisfies the requirement to monitor traffic flowing through specific endpoints, providing visibility into allowed or rejected packets based on security list and network security group rules. By logging these interactions at the VNIC, administrators gain granular insights into connectivity patterns, which remains a fundamental capability distinct from identity-based auditing services like Microsoft Entra ID.

When utilising the Oracle provider model for FastConnect, provisioning is split between the Oracle Cloud Infrastructure Console and the telecommunications partner's management plane. Having generated the Oracle Industry Partner token (OCID) within the OCI console, you must share this unique identifier with your designated network service provider. This satisfies the architectural constraint of the provider-managed workflow, allowing the external partner to reference the exact OCI circuit configuration and complete the Layer 2 or Layer 3 provisioning from their side.

OCI Load Balancer provides native support for TCP layer 4 load balancing, which satisfies the requirement for handling non-HTTP traffic. By operating at the transport layer, the service performs packet forwarding based on source and destination IP addresses and ports without inspecting application-layer data. This mechanism ensures efficient routing for protocols such as database connections or custom binary streams, allowing administrators to balance traffic across backend sets while maintaining high availability for services that do not necessitate layer 7 application-aware processing.

A Dynamic Routing Gateway acts as the regional transit hub, terminating the FastConnect virtual circuit and routing traffic to attached VCNs. Critically, DRG route tables support inter-region routing via remote peering or DRG attachments, satisfying the requirement to reach multiple VCNs across different OCI regions through one dedicated connection.

Oracle Cloud Infrastructure provides an integrated DNS resolver that automatically manages internal hostname resolution within a Virtual Cloud Network. By assigning a unique hostname to each virtual network interface card, the platform enables instances to communicate using these labels rather than relying solely on private IP addresses. This mechanism satisfies the requirement for seamless intra-VCN connectivity, functioning independently of external identity providers like Microsoft Entra ID, as the OCI-native resolver maintains the authoritative records for all instances provisioned within the specified subnet.

Custom forwarders let the VCN Resolver send queries for specific internal domains to your own DNS servers while still resolving internet names, satisfying both requirements. Internet Resolver alone handles only public names; private views serve OCI-assigned hostnames.

Establishing an IPSec connection between the Customer Premises Equipment (CPE) and the Dynamic Routing Gateway (DRG) is essential for creating the encrypted tunnel required by the stem. This component satisfies the requirement for a secure, site-to-site communication path by encapsulating traffic between the on-premises network and the OCI VCN. Without this specific logical link, the infrastructure cannot facilitate the routing of packets across the public internet, thereby failing to establish the necessary connectivity between the two distinct datacenter environments.

A Service Gateway provides private connectivity to OCI public services, such as Object Storage, without traversing the public internet. By routing traffic through this gateway, database instances residing in a private subnet maintain their isolation while accessing backend storage endpoints over the Oracle network backbone. This configuration satisfies the constraint of ensuring secure, private communication for resources that lack public IP addresses, effectively bypassing the need for a NAT gateway or public internet exposure for these specific service-bound requests.