Domain 3: Design for Hybrid Networking Architectures (20%)

Domain 3 of the 1Z0-1124-25 Oracle Cloud Infrastructure 2025 Networking Professional exam covers the design, implementation, and troubleshooting of hybrid connectivity between on-premises data centers and OCI. At 20% of the exam weight, this domain accounts for approximately 10 questions. It requires deep understanding of DRG architecture, BGP routing mechanics, VPN and FastConnect configuration, and multi-cloud interconnect patterns.

1. Dynamic Routing Gateway (DRG) Deep Dive

The DRG is the central virtual router for all hybrid and multi-cloud connectivity in OCI. Every hybrid architecture flows through a DRG. (Managing DRGs)

DRG v2 Architecture

DRG v2 (available since May 17, 2021) replaced the legacy DRG with a programmable routing architecture. The key differences matter for the exam:

Exam trap: DRG upgrades are irreversible. There is no rollback. The upgrade takes up to 30 minutes per on-premises attachment, and each attachment experiences approximately 20 minutes of downtime as it transitions through a provisioning state. With redundant connections, traffic fails over during each sequential upgrade. (Managing DRGs)

DRG Attachment Types

A DRG v2 supports five attachment types:

Critical constraint: A VCN can attach to only ONE DRG. Multiple VCNs can attach to a single DRG, but the reverse is not true. (Managing DRGs)

DRG Route Tables

When a DRG is created or upgraded, two default auto-generated route tables are created automatically:

1. VCN attachment default table -- assigned to all VCN attachments
2. All other attachments default table -- assigned to VIRTUAL_CIRCUIT, IPSEC_TUNNEL, REMOTE_PEERING_CONNECTION, and LOOPBACK attachments

These default tables cannot be deleted. You can create additional custom route tables and assign them to specific attachments. The same route table can be shared across multiple attachments, or each attachment can have a dedicated table. (Managing DRGs)

Import Route Distributions

Two auto-generated import route distributions are created per DRG:

You can create additional custom import distributions. However, you cannot create custom export distributions -- only the auto-generated defaults exist for exports. Distribution statements are evaluated by priority (lowest number = highest priority). (Managing DRGs)

Route sources (provenance) are classified as: STATIC, VCN, IPSEC_TUNNEL, VIRTUAL_CIRCUIT, or REMOTE_PEERING_CONNECTION.

Route Conflict Resolution

When two routes with identical CIDRs exist in the same DRG route table, OCI resolves conflicts using this hierarchy:

Priority 1 -- Route source type: Static routes always win over dynamic routes.

Priority 2 -- AS path length: Shorter AS path wins. VCN and STATIC sources have empty AS paths (length 0). IPSEC_TUNNEL and VIRTUAL_CIRCUIT sources have populated AS paths.

Priority 3 -- Attachment type tiebreaker (when AS path length is equal):

Deprecated routes are marked with conflict status in route table listings. (Managing DRGs)

Hard Routing Restrictions

These three restrictions are enforced at the DRG level and cannot be overridden:

1. Routes from IPSec tunnel or virtual circuit attachments are never exported to other IPSec tunnel or virtual circuit attachments
2. Packets entering through an IPSec tunnel or virtual circuit cannot exit through another IPSec tunnel or virtual circuit
3. RPC route propagation is limited to a maximum depth of 4 DRGs

Exam trap: If a question describes a scenario where on-premises traffic needs to transit through OCI to reach another on-premises site, the answer is that this is not possible through DRG routing alone. Packets are dropped. You need a network virtual appliance (NVA) in a VCN to bridge on-premises-to-on-premises traffic. (Managing DRGs)

2. BGP in OCI

BGP is the routing protocol used for all dynamic hybrid connectivity in OCI -- both FastConnect and Site-to-Site VPN (when configured for BGP routing).

AS Path Prepending for Traffic Engineering

Oracle uses AS path prepending to establish default traffic preferences. When a customer advertises the same route over multiple connection types, Oracle prepends ASNs as follows:

This means Oracle always prefers FastConnect over VPN, and BGP-based VPN over static VPN, by default. (Managing DRGs)

Exam trap: Asymmetric routing is allowed and expected. A request might arrive via VPN, but Oracle's response will prefer FastConnect if available. To force symmetric routing, you must use BGP AS path prepending on your CPE to match Oracle's preference.

ECMP (Equal-Cost Multi-Path Routing)

ECMP is disabled by default and must be enabled per DRG route table. Key facts:

• Maximum width: 8 circuits or tunnels per route table
• Load balancing: 5-tuple hash (protocol, source IP, destination IP, source port, destination port)
• Constraint: ECMP works across paths of the same type only (all FastConnect OR all IPSec, not mixed)
• Active-active: Yes, provides active-active failover
• Route eligibility: Only routes with identical route preference qualify

(Managing DRGs)

Route Aggregation

Two methods reduce the number of routes advertised via BGP:

1. VCN CIDR aggregation: Set the vcnRouteType property on a VCN attachment to VCN_CIDRS instead of the default SUBNET_CIDRS. This advertises the VCN-level CIDR blocks rather than individual subnet CIDRs.
2. Static routes in DRG: Add summary static routes scoped to specific attachments.

(Managing DRGs)

3. OCI Site-to-Site VPN (IPSec)

Tunnel Architecture

Each IPSec connection consists of 2 redundant IPSec tunnels. Oracle recommends configuring the CPE to use both tunnels. A single CPE public IP supports up to 8 IPSec connections. OCI supports tunnel mode only (ESP). (Site-to-Site VPN Overview)

Routing Types

Each tunnel is independently configured with one of three routing types:

Default: Static routing unless explicitly configured for BGP. Oracle recommends BGP for production workloads.

Exam trap: If a tunnel uses BGP, the IPSec connection's static routes are ignored for that tunnel. If a tunnel uses static routing, the associated static routes are used. Oracle uses longest prefix match for route selection. (Site-to-Site VPN Overview)

Supported IPSec Parameters

IKE versions: Both IKEv1 and IKEv2 are supported.

Phase 1 (ISAKMP):

Phase 2 (IPSec):

(Supported IPSec Parameters)

Important: Oracle's default IKE parameter proposals exceed a single UDP packet size, causing IP fragmentation. Firewalls and security lists must allow IP fragments between the Oracle VPN public IP and the CPE.

Failover and Path Control

For on-premises to VCN direction: configure BGP local preference on the CPE to prefer one tunnel. For VCN to on-premises direction: advertise more specific routes on the preferred tunnel, or use AS path prepending on the non-preferred tunnel. Asymmetric routing is expected if you only configure one direction. (Site-to-Site VPN Overview)

Routing Type Transitions

Switching from BGP to static requires at least one static route to exist on the IPSec connection before the switch. Switch one tunnel at a time to avoid full connection downtime. During reprovisioning, the tunnel remains up but traffic is briefly disrupted. (Site-to-Site VPN Overview)

4. FastConnect

FastConnect provides dedicated, private connectivity between on-premises networks and OCI without traversing the public internet. (FastConnect Overview)

Connection Models

Note: Cross-connect groups (LAGs) are supported for both third-party provider and colocation models.

(FastConnect Overview)

Exam trap: Cross-connect groups (LAGs) are available for the colocation and third-party provider models only -- not the partner model. If a question asks about bandwidth expansion after initial deployment, the answer for colocation or third-party is LAG; for partner, you provision additional virtual circuits.

Virtual Circuit Types

Private virtual circuits: Route through a DRG attachment. Support multiple VCs for traffic segmentation. BGP exchanges private routes.

Public virtual circuits: Access Object Storage, OCI Console/APIs, and public load balancers without internet routing. Oracle verifies customer ownership of public prefixes (up to 3 business days). Treat the public peering interface as untrusted -- apply the same firewall rules you would for an internet connection. (FastConnect Overview)

BGP Session Models

• Layer 2 (some Oracle partners): BGP session runs directly between customer edge router and Oracle edge router. Customer provides BGP details during setup.
• Layer 3 (other partners, third-party, colocation): BGP session runs between customer edge and partner/provider edge. Partner manages the Oracle-facing BGP session.

BFD (Bidirectional Forwarding Detection) is supported and recommended for sub-second failure detection, which is faster and more reliable than BGP timer-based detection. (FastConnect Overview)

Redundancy Design

Oracle recommends redundant FastConnect connectivity using:

1. Multiple physical connections at the same FastConnect location
2. Diverse paths across different FastConnect locations in the same metro area (all metro locations connect to the same availability domains)
3. Diverse providers using different Oracle partners or third-party carriers
4. BFD for rapid failure detection

(FastConnect Overview)

FastConnect with Multiple DRGs

For third-party provider and colocation models, you can connect multiple VCNs via separate DRGs over a single physical FastConnect:

• One private virtual circuit per DRG
• Each virtual circuit requires a unique VLAN and unique BGP IP address pair
• All VCNs must be in the same region and same tenancy
• No overlapping CIDRs between VCNs or on-premises subnets

Alternative: Transit routing (hub-and-spoke) uses a single DRG with multiple VCN attachments. This approach works with all connection models and does not require separate virtual circuits per VCN. (FastConnect with Multiple DRGs)

Exam trap: Oracle Partner support for multiple DRGs varies by partner. Third-party and colocation always support it. If the question specifies a partner connection, be cautious about assuming multi-DRG capability.

5. IPSec over FastConnect

IPSec over FastConnect adds Layer 3 encryption to FastConnect's already-private connection. This is a newer feature that combines the bandwidth and reliability of FastConnect with IPSec tunnel encryption. (FastConnect Security)

Architecture

The key architectural component is the loopback attachment. Without it, traffic between a virtual circuit attachment and an IPSec tunnel attachment is not allowed (per the hard routing restrictions described in Section 1). The loopback attachment provides the Oracle-side tunnel private IP address to the DRG, enabling encrypted traffic to flow.

Traffic flow (inbound):

1. IPSec tunnel originates from CPE
2. Encrypted traffic arrives on the virtual circuit (VIRTUAL_CIRCUIT attachment)
3. Traffic passes to LOOPBACK attachment
4. Traffic terminates on IPSEC_TUNNEL attachment (decrypted)
5. Unencrypted traffic routes through VCN attachment to destination

Requirements:

• Upgraded DRG (v2) is mandatory
• CPE object must have IPSec over FastConnect enabled at creation time (cannot be added later)
• IPSEC_TUNNEL and VIRTUAL_CIRCUIT attachments must use different DRG route tables and import route distributions
• BGP routing is recommended for IPSec over FastConnect connections

(FastConnect Security)

TransportOnly Mode

For strict security postures, transportOnly mode forces all traffic on a virtual circuit to be encrypted. When enabled:

• The virtual circuit's route table only allows routes to associated loopback attachments
• No static routes are permitted on the virtual circuit attachment
• No other DRG attachments can import routes from the virtual circuit attachment
• All subsequent route distribution changes are validated against these constraints

Prerequisites before enabling: Remove all static rules from the default virtual circuit route table and remove all route distribution statements matching "Virtual Circuit" or "Match ALL." (FastConnect Security)

MACsec Encryption (Alternative)

MACsec (IEEE 802.1AE) provides Layer 2 encryption as an alternative to IPSec over FastConnect:

Exam trap: MACsec is not available on all existing cross-connects. Check the cross-connect details page for "MACsec Encryption: Capable" status. Incapable connections must be reprovisioned. Changing encryption settings triggers a BGP session restart. (FastConnect Security)

IPSec vs MACsec comparison:

6. Multi-Cloud Connectivity

Oracle Interconnect for Azure

This service provides a direct, private cross-cloud link between OCI and Microsoft Azure. It works by pairing an OCI FastConnect private virtual circuit with an Azure ExpressRoute circuit. Traffic never traverses the public internet. (Azure Interconnect)

Architecture components:

BGP configuration: Two redundant BGP sessions (primary + secondary). Each session requires a separate CIDR block with subnet mask /28 to /31. In each block, the second usable address is Oracle's BGP IP and the third is Azure's BGP IP. (Azure Interconnect)

Setup sequence: Configure security rules on both sides, create Azure ExpressRoute circuit (obtain service key), create OCI FastConnect virtual circuit as "FastConnect Partner" selecting "Microsoft Azure: ExpressRoute" and providing the service key, verify provisioning, configure route tables, test connectivity.

Supported regions (13 regions across 4 continents):

(Azure Interconnect)

Traffic restrictions:

• Supported: VCN to VNet (and VCN-peered VCNs to VNet)
• Not supported: On-premises to VCN to VNet transit, or On-premises to VNet to VCN transit

Exam trap: The Azure Interconnect provides built-in redundancy via the two BGP sessions. A single FastConnect circuit and single ExpressRoute circuit is sufficient -- you do not need to provision duplicate circuits for redundancy. However, the CIDR blocks for VCN and VNet must not overlap.

Termination sequence matters: Delete Azure ExpressRoute Connections first, then delete OCI FastConnect virtual circuit, verify Azure private peering is deleted, then delete Azure ExpressRoute circuit. Reversing this order causes orphaned resources. (Azure Interconnect)

Oracle Interconnect for Google Cloud

Oracle and Google Cloud provide direct private connectivity via Partner Cross-Cloud Interconnect for OCI. This service became generally available in 2024 across multiple commercial regions globally. (Google Cloud Cross-Cloud Interconnect)

Key specifications:

Available regions: Australia East (Sydney), Australia Southeast (Melbourne), Brazil East (Sao Paulo), Canada Southeast (Montreal), Germany Central (Frankfurt), India West (Mumbai), Japan East (Tokyo), Singapore, Spain Central (Madrid), UK South (London), US East (Ashburn).

Setup flow: Select paired location, order Partner Interconnect attachments in Google Cloud, create VLAN attachments (generates pairing key), request FastConnect virtual circuits from OCI, activate connections after OCI configuration, establish BGP sessions.

Multi-Cloud Architecture Patterns

7. Key Memorization Tables

Connection Type Comparison

DRG Route Table Quick Reference

Exam Traps Summary

1. On-premises to on-premises transit through DRG is blocked -- packets are dropped. Use an NVA in a VCN.
2. DRG upgrades are irreversible -- plan for maintenance window with ~30 minutes downtime.
3. Custom export distributions cannot be created -- only auto-generated defaults exist.
4. RPC propagation limit is 4 DRGs deep -- routes do not propagate further.
5. ECMP maximum is 8 paths and only works within the same attachment type (all FC or all IPSec).
6. CPE IPSec over FastConnect flag must be set at creation -- cannot be enabled later.
7. MACsec requires 10 Gbps minimum and is not available on partner connections.
8. Azure Interconnect does not support on-premises transit -- traffic is VCN-to-VNet only.
9. Public virtual circuit prefix verification takes up to 3 business days.
10. Asymmetric routing is default behavior when FastConnect and VPN coexist -- Oracle always prefers FastConnect.

References

• Managing Dynamic Routing Gateways (DRGs)
• FastConnect Overview
• FastConnect with Multiple DRGs and VCNs
• Site-to-Site VPN Overview
• Supported IPSec Parameters
• Oracle Interconnect for Azure
• FastConnect Security (IPSec over FastConnect and MACsec)
• Partner Cross-Cloud Interconnect for OCI (Google Cloud)