06 Networking ‐ Connectivity - KleberVales/OCI-Architect-Associate GitHub Wiki

1. VCN Connectivity Options

1.1 VCN-to-VCN Connectivity

1.2 VCN-to-On-Premises Connectivity

2. Local VCN Peering

2.1 What Is Peering?

2.2 Local vs. Remote VCN Peering

2.3 Gateways as Virtual Routers

2.4 Two Ways to Configure Local VCN Peering

part 2

2.5 Prerequisites for Local VCN Peering

2.6 Approach 1: Local VCN Peering Using Local Peering Gateways

3. Remote VCN Peering

3.1 What Is Remote VCN Peering?

3.2 Components Required for Remote VCN Peering

3.3 Remote VCN Peering Architecture

3.4 Role of the Remote Peering Connection

3.5 Remote Peering Connections and Regions

3.6 DRG Types and Tenancy Support

4. BGP Basics

4.1 What Is Border Gateway Protocol?

4.2 Autonomous Systems and BGP Peers

4.3 How BGP Works

5. Dynamic Routing Gateway

5.1 What Is a Dynamic Routing Gateway?

5.2 DRG Attachments

5.3 Routing in a DRG

5.4 Automatically Created Route Tables

5.5 Automatically Created Route Distributions

5.6 Mapping Import Route Distributions to Route Tables

5.7 Example: VCN Attachment and Remote Peering Connection

part 2

5.8 Routing Between DRG Attachments

5.9 Types of Routes in a DRG

5.10 Route Tables and Attachments

part 3

5.11 Dynamic Route Import Distribution

5.12 Dynamic Route Export Distribution

5.13 ECMP – Equal Cost Multipath Routing

5.14 Route Conflicts and Priority

5.15 Default DRG Routing Behavior: Example

6. Site-to-Site VPN

7. Fast Connect Overview - Part 1

8. Fast Connect With an Oracle Partner

9. Fast Connect With a Third-Party Provider

10. Fast Connect Colocation with Oracle

11. FastConnect Redundancy Best Practices

12. Transit Routing Scenarios

.
.
.
.
.

1. VCN Connectivity Options

VCN Connectivity Options in Oracle Cloud Infrastructure provide multiple ways to connect your Virtual Cloud Network to other VCNs or to on-premises networks. When connecting VCNs within the same region, you use local peering, which can be configured using either Local Peering Gateways (LPG) or Dynamic Routing Gateway (DRG). When connecting VCNs in different regions, you use remote peering, which is configured using Dynamic Routing Gateway (DRG). For connecting your VCN to an on-premises network, there are three options: public internet (via Internet Gateway or NAT Gateway), site-to-site VPN (encrypted connection over the internet), and FastConnect (dedicated, high-bandwidth, low-latency connectivity). Each option has different characteristics, use cases, and trade-offs in terms of security, performance, and cost.

1.1 VCN-to-VCN Connectivity

You can connect a VCN to another VCN in two scenarios:

Scenario	Connection Type	Description
Same Region	Local Peering	Connects two VCNs within the same region.
Different Regions	Remote Peering	Connects two VCNs in different regions.

Local Peering

Local peering connects VCNs within the same region.

Configuration Options:

Local Peering Gateway (LPG): Create an LPG for each VCN and connect them.
Dynamic Routing Gateway (DRG): Connect both VCNs to a single DRG to establish local peering.

Remote Peering

Remote peering connects VCNs in different regions.

Configuration:

Uses Dynamic Routing Gateway (DRG) to facilitate communication between VCNs in different regions.

Note: After configuring peering, you must also add appropriate route rules in the route tables to enable traffic flow.

1.2 VCN-to-On-Premises Connectivity

There are three options for connecting your VCN to an on-premises network:

Option	Description	Security	Throughput	Cost
Public Internet	Uses Internet Gateway or NAT Gateway	Unencrypted (application-level encryption possible)	No guarantee	Standard internet costs
Site-to-Site VPN	Encrypted IPsec VPN tunnel over the internet	Encrypted	No guarantee	Free (OCI managed)
FastConnect	Dedicated private connection	Secure	Up to 100 Gbps	Port charges (hourly)

Detailed Comparison of On-Premises Connectivity Options

Option 1: Public Internet

How it works: Traffic traverses over the public internet using Internet Gateway or NAT Gateway.
Use Case: Suitable for proof of concept (POC) and SaaS applications.
Security: Traffic is unencrypted by default; application-level encryption may be applied.
Throughput: No guarantee.
Cost: Standard internet costs apply.

Option 2: Site-to-Site VPN

How it works: Creates an encrypted IPsec VPN tunnel over the internet.
Use Case: Suitable for proof of concept and scenarios requiring secure connectivity.
Security: Encrypted — secure connectivity over the internet.
Throughput: No guarantee (traffic traverses over internet).
Cost: Free — managed by Oracle Cloud Infrastructure.

Option 3: FastConnect

How it works: Provides a dedicated private connection between your on-premises network and OCI.
Use Case: Suitable for business-critical applications and latency-sensitive applications.
Security: Secure — dedicated connection.
Throughput: High bandwidth — up to 100 Gbps.
Latency: Low latency — consistent performance.
Cost: Port charges on an hourly basis; no egress data transfer charges.
Compliance: Meets both compliance and security requirements.

1.3 Choosing the Right Connectivity Option

Requirement	Recommended Option
Connect VCNs in the same region	Local Peering (LPG or DRG)
Connect VCNs in different regions	Remote Peering (DRG)
Quick POC with minimal setup	Public Internet
Secure connection over internet	Site-to-Site VPN
High bandwidth, low latency, dedicated	FastConnect
Business-critical, latency-sensitive apps	FastConnect
SaaS applications	Public Internet

2. Local VCN Peering

Local VCN peering privately connects two VCNs in the same region. Instead of communicating over the public internet using public IP addresses, peered instances communicate through private IP addresses. There are two ways to configure local VCN peering: using a local peering gateway (LPG) or using an upgraded dynamic routing gateway (DRG). The LPG approach provides extremely high bandwidth and super low latency, while the upgraded DRG approach provides flexibility in routing and can support up to 300 VCN attachments. A VCN can have up to 10 local peering gateways and can be attached to one dynamic routing gateway. Overall, local VCN peering enables private, efficient connectivity between VCNs within the same region.

2.1 What Is Peering?

Peering means connecting two virtual cloud networks so they can communicate with each other. For example, imagine VCN A and VCN B. If they need to talk to each other, there are two main options:

Use the public internet
Instances inside the subnets use public IP addresses to communicate.
Use private direct access
Communication happens through private IP addresses.

In this lesson, the focus is on the second option: private communication. When peering is configured, instances communicate using private IP addresses rather than public IP addresses.

2.2 Local vs. Remote VCN Peering

There are two types of VCN peering:

Local VCN peering
Remote VCN peering

This lesson focuses on local VCN peering. “Local” means the two VCNs are in the same region. “Peering” means the two VCNs are connected privately.

2.3 Gateways as Virtual Routers

When discussing VCN connectivity, you will encounter different types of gateways. These include:

Internet gateway
Service gateway
NAT gateway
Local peering gateway (LPG)
Dynamic routing gateway (DRG)

The LPG and DRG are virtual routers. Important limits to remember:

A VCN can have up to 10 local peering gateways.
A VCN can be attached to one dynamic routing gateway.
A dynamic routing gateway can have up to 300 VCN attachments.

2.4 Two Ways to Configure Local VCN Peering

Option 1: Local VCN Peering Using LPG

The first method uses a local peering gateway (LPG). This approach connects two VCNs within the same region privately.

Key benefit:

Provides extremely high bandwidth and super low latency.

Option 2: Local VCN Peering Using Upgraded DRG

The second method uses an upgraded dynamic routing gateway (DRG). Previously, there was DRG version 1. Now there is DRG version 2. Before DRG version 2 existed, local VCN peering within the same region was done using an LPG.

Key benefit:

Provides flexibility in routing.
A DRG can be attached to up to 300 VCNs.

2.5 Why Are There Two Types?

The two types exist because of the evolution from DRG version 1 to the upgraded DRG version 2. The LPG approach is the older method for same-region VCN peering and offers high bandwidth with low latency. The upgraded DRG approach offers greater routing flexibility and can support many VCN attachments.

Local VCN Peering - part 2

Local VCN peering connects two VCNs in the same region so their resources can communicate privately. To configure it using local peering gateways, you need non-overlapping CIDRs, one LPG on each VCN, a connection between the two LPGs, route rules on both sides, and supporting security rules. To configure it using an upgraded dynamic routing gateway, you still need non-overlapping CIDRs, but instead of two LPGs, you create one DRG and attach it to both VCNs. In both approaches, route tables must point traffic to the correct gateway, and security rules must allow the desired traffic. Finally, if VCNs are peered, one VCN cannot use the other VCN’s internet gateway for outbound internet traffic, although it can receive traffic in the reverse direction.

1. Scope of This Lesson

In Part 1, we introduced local VCN peering. In Part 2, we focus on how to configure local VCN peering in two ways:

Using local peering gateways (LPGs)
Using an upgraded dynamic routing gateway (DRG)

In both cases, the two VCNs are in the same region.

2.5 Prerequisites for Local VCN Peering

Before configuring local VCN peering, ensure the following:

The two VCNs are in the same region.
Their CIDR blocks do not overlap.
- Example: VCN 1 uses 10.0.0.0/16
- Example: VCN 2 uses 192.168.0.0/16
You configure the required gateway resources.
You add supporting route rules on both sides.
You add supporting security rules to control traffic between instances.

2.6 Approach 1: Local VCN Peering Using Local Peering Gateways

Architecture

VCN 1 and VCN 2 are in the same region.
VCN 1 has its own local peering gateway.
VCN 2 has its own local peering gateway.
A connection is created between the two local peering gateways.

Configuration Steps

Create VCN 1 and VCN 2 with non-overlapping CIDRs.
Create Local Peering Gateway 1 on VCN 1.
Create Local Peering Gateway 2 on VCN 2.
Connect Local Peering Gateway 1 to Local Peering Gateway 2.
Configure route tables on both sides.
Configure security rules on both sides.

Route Table Example

For a subnet in VCN 1:

Destination: VCN 2 CIDR, such as 192.168.0.0/16
Target: Local Peering Gateway 1

For a subnet in VCN 2:

Destination: VCN 1 CIDR, such as 10.0.0.0/16
Target: Local Peering Gateway 2

Key Point

With the LPG approach, you need two local peering gateways—one on each VCN—and a connection between them.

4. Approach 2: Local VCN Peering Using an Upgraded Dynamic Routing Gateway

Architecture

VCN 1 and VCN 2 are in the same region.
Their CIDRs must still be non-overlapping.
Instead of two LPGs, you create one dynamic routing gateway.
The single DRG is attached to both VCN 1 and VCN 2.

Configuration Steps

Create VCN 1 and VCN 2 with non-overlapping CIDRs.
Create a single dynamic routing gateway.
Attach the DRG to both VCN 1 and VCN 2.
Configure route tables.
Configure security rules.

Route Table Example

For a subnet in VCN 1:

Destination: VCN 2 CIDR, such as 192.168.0.0/16
Target: Dynamic Routing Gateway

For a subnet in VCN 2:

Destination: VCN 1 CIDR, such as 10.0.0.0/16
Target: Dynamic Routing Gateway

Key Point

With the upgraded DRG approach, you need only one DRG, and it is attached to both VCNs.

5. Peering, Internet Gateways, and Traffic Direction

If two VCNs are not peered, they need an internet gateway and public IP addresses for their instances to communicate.

If two VCNs are peered locally using an LPG, and one VCN has an internet gateway, there is an important limitation:

Instances in the other peered VCN cannot use that internet gateway to send traffic to the internet.
However, they can receive traffic in the reverse direction.

In other words, a peered VCN’s internet gateway cannot be used by the other VCN for outbound internet access.

6. Comparison of the Two Approaches

Feature	LPG Approach	Upgraded DRG Approach
Gateways required	Two local peering gateways	One dynamic routing gateway
Connection	Connection between the two LPGs	DRG attached to both VCNs
Route target	LPG on each side	DRG
Security rules	Required	Required
Route rules	Required on both sides	Required on both sides
Main idea	Peer two VCNs using LPGs	Peer two VCNs using a single DRG

3. Remote VCN Peering

Remote VCN peering connects two VCNs located in different regions so that their resources can communicate privately using private IP addresses without sending traffic over the internet. To set it up, you need two VCNs with non-overlapping CIDRs, a dynamic routing gateway attached to each VCN, a remote peering connection on each DRG, and a connection between the two RPCs. You must also configure route tables and security lists. Remote peering connections are typically used across different regions but can technically be used within the same region. Finally, legacy DRGs only support remote peering within the same tenancy, while upgraded DRGs support both same-tenancy and cross-tenancy connections.

3.1 What Is Remote VCN Peering?

In the previous lesson, local VCN peering connected two VCNs in the same region. Remote VCN peering connects two VCNs in different regions.

For example:

Region A contains VCN-1.
Region B contains VCN-2.
Connecting VCN-1 and VCN-2 across these regions is remote VCN peering.

When remote VCN peering is configured, instances in VCN-1 can communicate with instances in VCN-2 using private IP addresses. The communication happens privately, and the traffic is not routed over the internet.

The VCNs can be in the same tenancy or in different tenancies. The same is true for local VCN peering.

3.2 Components Required for Remote VCN Peering

To configure remote VCN peering, you need:

Two VCNs with non-overlapping CIDRs in different regions.
A dynamic routing gateway (DRG) created and attached to each VCN.
A remote peering connection (RPC) created on each DRG.
A connection between the two RPCs.
Supporting route tables and security lists.

In short:

Two VCNs
Two DRGs
Two RPCs
One connection between the RPCs
Route and security configuration

3.3 Remote VCN Peering Architecture

A typical architecture looks like this:

Region 1 contains VCN-1.
Region 2 contains VCN-2.
VCN-1 is attached to DRG-1.
VCN-2 is attached to DRG-2.
DRG-1 has RPC-1.
DRG-2 has RPC-2.
A connection is established between RPC-1 and RPC-2.

This allows resources in the two VCNs to communicate using private IP addresses across regions.

3.4 Role of the Remote Peering Connection

A remote peering connection (RPC) acts as a connection point between two VCNs in different regions. After creating and attaching the DRGs to their respective VCNs, you create an RPC on each side. Then you connect the two RPCs together.

As with local peering, a key prerequisite is that the VCNs must have non-overlapping CIDRs.

3.5 Remote Peering Connections and Regions

Remote peering connections are typically meant for VCNs located in different regions. However, technically, they can also be used for VCNs in the same region.

3.6 DRG Types and Tenancy Support

There are two ways to use remote peering connections depending on the DRG type:

Legacy dynamic routing gateways:
Cannot connect DRGs in different tenancies. They support same tenancy only.
Upgraded dynamic routing gateways:
Can connect DRGs in both same tenancies and different tenancies.

4. BGP Basics

Border Gateway Protocol (BGP) is the routing protocol of the internet. It determines the best network routes for data traveling across multiple networks. An autonomous system is a network controlled by a single administrative entity, and each autonomous system has an autonomous system number. BGP peers sit at the edge of autonomous systems and exchange routing information with neighboring peers. BGP performs route discovery and path selection, choosing the best path based on available routes—such as selecting the path with fewer hops in the example from AS 1 to AS 3. In OCI, BGP is especially important because Site-to-Site VPN can use BGP, static routing, or both, while FastConnect always uses BGP for route advertisements. Therefore, BGP knowledge is essential for configuring OCI connectivity to on-premises networks.

4.1 What Is Border Gateway Protocol?

BGP stands for Border Gateway Protocol. It is the routing protocol used on the internet. Its main job is to determine the best network routes for data transmission.

When data travels from a source to a destination, it often passes through multiple networks. BGP looks at the available paths and selects the best route for the traffic.

A simple analogy: when you travel from one place to another, a maps application shows you an optimized route. Similarly, BGP selects the best possible route for network traffic.

4.2 Autonomous Systems and BGP Peers

An autonomous system (AS) can be thought of as a smaller network under the control of a single administrative entity. It is essentially a collection of connected IP networks managed by one organization.

Each autonomous system has an autonomous system number (ASN). For example, you may have AS 1 and AS 2.

A BGP peer is a device on the edge or boundary of an autonomous system. BGP peers exchange routing information with neighboring BGP peers. This exchange helps BGP discover routes and choose the best path.

4.3 How BGP Works

BGP performs two major functions:

Route discovery – It learns about available network paths.
Path selection – It chooses the best route for traffic.

When data moves from source to destination, it may travel through several networks. BGP evaluates the possible paths and determines the best network route.

5. Dynamic Routing Gateway

A Dynamic Routing Gateway (DRG) is a virtual router that can be attached to VCNs, remote peering connections, IPsec tunnels, virtual circuits, and loopback attachments. Routing in a DRG is controlled by DRG route tables and DRG route distributions. When a DRG is created, two route tables are automatically created: one for RPC, virtual circuit, and IPsec attachments, and one for VCN attachments. Two import route distributions and one export route distribution are also automatically created. The route table for RPC, virtual circuit, and IPsec attachments uses the import route distribution for VCN routes, while the route table for VCN attachments uses the import route distribution for all routes. In a simple example with a VCN attachment and a remote peering connection, the first route table learns only the VCN route, while the second route table learns both the VCN route and the remote peering connection route. This lesson marks the first part of the DRG discussion, with more details to follow in the next part.

5.1 What Is a Dynamic Routing Gateway?

A Dynamic Routing Gateway (DRG) is a virtual router. It acts as a connectivity hub that can have multiple attachments to different networks and services.

5.2 DRG Attachments

A DRG can be attached to several types of resources, including:

VCN attachments – connections to Virtual Cloud Networks.
Remote peering connections – used for remote VCN peering.
IPsec tunnels – part of a Site-to-Site VPN connection.
Virtual circuits – part of a FastConnect connection.
Loopback attachments – used when you want to forward traffic from a virtual circuit attachment to an IPsec tunnel attachment within the same DRG.

5.3 Routing in a DRG

Routing in a DRG is controlled by two main entities:

DRG route tables
DRG route distribution

5.4 Automatically Created Route Tables

When you create a DRG, two route tables are automatically created:

Autogenerated DRG route table for RPC, virtual circuit, and IPsec attachments
Autogenerated DRG route table for VCN attachments

So one route table is for VCN attachments, and the other is for all other attachments.

5.5 Automatically Created Route Distributions

There are two types of DRG route distribution:

Import route distribution
Export route distribution

When you create a DRG, the following are automatically created:

Two import route distributions
One export route distribution

The two import route distributions are:

Import route distribution for all routes
Import route distribution for VCN routes

The single export route distribution is known as the default export route distribution for DRG.

5.6 Mapping Import Route Distributions to Route Tables

The automatically created route tables use specific import route distributions:

Route Table	Import Route Distribution Used
Route table for RPC, virtual circuit, and IPsec attachments	Import route distribution for VCN routes
Route table for VCN attachments	Import route distribution for all routes

This mapping is important for understanding which routes appear in each route table.

5.7 Example: VCN Attachment and Remote Peering Connection

Consider a simple setup with:

One VCN
One remote peering connection
One DRG

The VCN is attached to the DRG as a VCN attachment.
The remote peering connection is attached as an RPC attachment.

Now consider the two route tables:

Route Table for RPC, Virtual Circuit, and IPsec Attachments

This route table uses the import route distribution for VCN routes.
Therefore, it imports routes for only the VCN.
So this route table will contain a dynamic route for the VCN.

Route Table for VCN Attachments

This route table uses the import route distribution for all routes.
Therefore, it imports routes for both the VCN and the remote peering connection.
So this route table will contain:

One route for the VCN
One route for the remote peering connection

Dynamic Routing Gateway part 2

In this lesson, we continued our discussion of the Dynamic Routing Gateway by focusing on how traffic is routed between DRG attachments. Routing policies are defined using DRG route tables and DRG route distributions. A DRG can have static routes, which are created manually, and dynamic routes, which are imported automatically through import route distributions. Each DRG attachment is associated with a route table, and that route table determines the next hop for packets entering the DRG. By default, two DRG route tables are created: one for VCN attachments and one for all other attachment types. However, you can also create dedicated route tables for individual attachments or share a route table across multiple attachments. Finally, it is important to distinguish between a VCN route table, which routes packets entering the VCN, and a DRG route table, which routes packets entering the DRG. Understanding this difference is essential for correctly configuring routing in Oracle Cloud Infrastructure.

5.8 Routing Between DRG Attachments

A Dynamic Routing Gateway (DRG) can have different types of attachments, such as:

Virtual Cloud Network (VCN) attachments
IPsec attachments
Virtual circuit attachments
Remote peering connection attachments
Loopback attachments

The main question is: How do we route traffic between these attachments?

The answer is by using:

DRG route tables
DRG route distributions

Together, these two entities define routing policies. A routing policy determines what happens to traffic after it enters the DRG. For example, if traffic enters through a VCN attachment, the DRG route table assigned to that attachment decides the next hop.

5.9 Types of Routes in a DRG

There are two types of routes inside a DRG:

Static routes
These are created manually.
Dynamic routes
These are imported automatically into the DRG route tables using import route distributions.

In the previous lesson, we discussed import route distributions and how they relate to DRG route tables. The key point is that dynamic routes are learned automatically, while static routes require manual configuration.

5.10 Route Tables and Attachments

Each DRG attachment has an associated route table. For example:

A VCN attachment has an associated route table.
A remote peering connection attachment has an associated route table.

The purpose of these route tables is to route packets entering the DRG to the next hop.

If a packet enters the DRG through a VCN attachment, the DRG route table assigned to that attachment determines where the packet goes next.

By default, two DRG route tables are automatically created:

One for VCN attachments
One for all other attachment types

However, you can also:

Create a dedicated route table for each attachment.
Use the same route table for multiple DRG attachments.

Dynamic Routing Gateway part 3

In this lesson, we covered dynamic route import and export distribution in a Dynamic Routing Gateway. Import distribution controls how route advertisements from attachments are inserted into DRG route tables using statements and match criteria, with lower statement numbers having higher priority. Export distribution controls how routes are advertised from route tables to attachments, with the exception that routes imported from an IPsec tunnel are never exported to other IPsec tunnel or virtual circuit attachments. ECMP is off by default, can be enabled on a route table, and supports load balancing over multiple FastConnect virtual circuits or IPsec tunnels using BGP. Route conflicts are resolved with static routes taking highest priority, followed by VCN, virtual circuit, IPsec tunnel, and remote peering connection. Finally, in the default DRG behavior, the VCN attachment route table learns all routes from all attachment types, while the route table for other attachments learns only VCN routes.

5.11 Dynamic Route Import Distribution

A dynamic route import distribution controls how route advertisements coming in through DRG attachments are inserted into the DRG route table.

It contains a list of statements with match criteria. For example, if a statement uses the match criteria all traffic, then all route advertisements coming through the attachments are inserted into the respective DRG route table.

The flow works like this:

Write a statement with a match criteria.
The statement matches an attachment.
Routes associated with that attached object are dynamically imported into the DRG route table assigned to the distribution.

Each DRG route table has a dynamic route import distribution assigned to it. When writing statements, you assign a number to each statement. The lowest number has the highest priority.

5.12 Dynamic Route Export Distribution

A dynamic route export distribution is the reverse of import distribution. It specifies how routes are advertised to attachments from their assigned route tables.

In other words, it controls how routes from a DRG route table are exported or advertised to DRG attachments.

There is an important exception:

Routes imported from an IPsec tunnel are never exported to other IPsec tunnel or virtual circuit attachments.

By default, one route export distribution is created when you create a DRG.

5.13 ECMP – Equal Cost Multipath Routing

ECMP stands for Equal Cost Multipath Routing.

By default, ECMP is off.
It is enabled on a DRG route table.
When enabled, ECMP facilitates load balancing of network traffic.
It can load balance traffic over multiple FastConnect virtual circuits or multiple IPsec tunnels using Border Gateway Protocol (BGP).

5.14 Route Conflicts and Priority

When multiple routes exist, conflicts may occur. The following rules apply:

Static routes always have higher preference than dynamic routes.
If there is a conflict between dynamic routes, it is resolved by the route’s autonomous system (AS) path.
- For VCN and static routes, the AS path is normally empty.
- For IPsec tunnel and virtual circuit, the AS path is populated.

The priority order for route conflicts is:

Static
VCN
Virtual circuit
IPsec tunnel
Remote peering connection (RPC)

5.15 Default DRG Routing Behavior: Example

Consider a DRG with two attachments:

A VCN attachment
A remote peering connection (RPC) attachment

When you create a DRG, two route tables are automatically created:

Autogenerated DRG route table for VCN attachments
Autogenerated DRG route table for all other attachments (in this case, the RPC)

Before Attachment

Initially, before attaching the VCN and RPC:

There are no static routes.
There are no dynamic routes.

After Attaching VCN and RPC

After attaching the VCN and RPC:

If you do not add any rules manually, there are still no static routes.
For dynamic routes:
- The VCN route table will have entries for VCN and entries for remote peering connection.
- The other attachments route table will have only VCN routes.

If the VCN has two subnets, there will be two VCN entries.

Key Default Behavior

By default, the VCN route table learns all routes from all attachment types.
By default, the DRG route table for other attachments learns only VCN routes.

Dynamic Routing Gateway part 4

A Dynamic Routing Gateway is a virtual router that connects on-premises networks and VCNs in Oracle Cloud Infrastructure. It supports many attachment types, including VCNs, remote peering connections, IPsec tunnels, virtual circuits, cross-tenancy attachments, and loopback attachments. Each attachment has an associated route table, and by default a DRG creates two route tables: one for VCN attachments and one for all other attachments. DRG route tables can contain static routes and dynamic routes imported through route distributions. DRGs provide simplified configuration, high availability, increased scale—up to 300 VCNs per DRG—and support for transit routing, hub-and-spoke topologies, and complex routing with network virtual appliances. When a packet enters a DRG, the routing engine performs a route lookup in the route table associated with the ingress attachment and forwards the packet based on the next-hop parameters. This lesson revisits the core DRG concepts and prepares for the upcoming demonstration.

1. What Is a Dynamic Routing Gateway?

A Dynamic Routing Gateway (DRG) is a virtual router that facilitates communication between an on-premises network and Virtual Cloud Networks (VCNs). It acts as a central routing hub in Oracle Cloud Infrastructure.

2. DRG Attachments

A DRG can have several types of attachments, including:

VCN attachments – connections to Virtual Cloud Networks.
Remote peering connection (RPC) attachments – used for remote VCN peering.
IPsec tunnel attachments – part of Site-to-Site VPN.
Virtual circuit attachments – part of FastConnect.
Cross-tenancy attachments – attachments involving different tenancies.
Loopback attachments – used for specific routing scenarios within the same DRG.

Every attachment has its own associated route table.

3. DRG Route Tables and Route Distributions

When you create a DRG, two default route tables are automatically created:

One for VCN attachments
One for all other attachments

Although these two default route tables are created, you can also create a custom DRG route table and associate it with a specific network resource attached to the DRG.

Inside a DRG route table, you can have:

Static routes – manually created.
Dynamic routes – imported automatically through import route distributions.

Communication between DRG attachments is controlled by these routing tables and the associated import policies.

4. Equal Cost Multipath Routing (ECMP)

ECMP, or Equal Cost Multipath Routing, can be used with DRGs. It supports load balancing of traffic across multiple paths, such as multiple FastConnect virtual circuits or IPsec tunnels.

5. Common DRG Use Cases

DRGs provide several important benefits:

Simplified Configuration

A single DRG can have multiple VCNs attached to it. These VCNs can belong to the same tenancy or different tenancies. For local VCN peering in the same region, one DRG can replace the need for multiple local peering gateways.

High Availability

Using a DRG, you can use OCI FastConnect in one region to communicate with resources in a VCN in another region.

Increased Scale

A single DRG can have up to 300 VCNs attached to it.

Transit Routing

DRGs support transit routing scenarios, including hub-and-spoke architectures.

Complex Routing

A DRG allows you to specify a unique route table for each attached network. This supports complex routing requirements and topologies such as hub-and-spoke. It also allows you to use a network virtual appliance (NVA) in a hub VCN to filter or inspect traffic between an on-premises network and a spoke VCN.

6. How the DRG Routing Engine Works

The DRG routing engine processes packets as follows:

A packet arrives into the DRG from one of its attachments.
A route lookup is performed on the route table associated with the ingress attachment.
- For example, if the packet arrives through a VCN attachment, the lookup is performed in the route table associated with that VCN attachment.
The packet is forwarded based on the next-hop parameters in the route table.

This process determines how traffic moves between DRG attachments.

6. Site-to-Site VPN

Site-to-Site VPN, also known as VPN Connect or IPsec VPN, provides an encrypted IPsec connection between an on-premises environment and an OCI VCN. The connection uses the public internet but keeps traffic encrypted. IPsec has two modes: transport mode, which encrypts only the payload, and tunnel mode, which encrypts and authenticates the entire packet; Oracle supports tunnel mode. Site-to-Site VPN is cost effective, quick to set up, encrypted, and provides two redundant tunnels per connection. Routing can be static, dynamic using BGP, or policy-based, and it is configured per tunnel, with Oracle recommending the same routing type for both tunnels. The main components include the on-premises CPE, the OCI VCN, a DRG, the CPE object, and the IPsec connection. Each IPsec connection has two tunnels, each with a public IP and shared secret. If the CPE is behind a NAT device, the CPE IKE identifier must be changed to the CPE private IP address, and Oracle supports both IKEv1 and IKEv2.

6.1 What Is Site-to-Site VPN?

Site-to-Site VPN provides an IPsec connection between an on-premises environment and a Virtual Cloud Network (VCN) in Oracle Cloud Infrastructure (OCI).

Older names for this service include:

VPN Connect
IPsec VPN

In a Site-to-Site VPN setup:

The on-premises side has a Customer Premises Equipment (CPE) device.
The OCI side has a Dynamic Routing Gateway (DRG).
An IPsec connection is established between them.

The communication travels over the public internet, but the traffic is encrypted. IP packets are encrypted before transmission and decrypted when they arrive.

6.2 IPsec Modes: Transport Mode vs. Tunnel Mode

To understand IPsec modes, first distinguish between:

Header – like an envelope or box; contains packet information such as origin IP and destination IP.
Payload – the actual data or content.

Transport Mode

The header stays intact.
IPsec encrypts only the payload.

Tunnel Mode

IPsec encrypts and authenticates the entire packet.
This includes both the header and the payload.

Important: Oracle supports tunnel mode.

6.3 Advantages of Site-to-Site VPN

Site-to-Site VPN offers several benefits:

Cost effective
Communication uses the public internet, so dedicated leased lines are not required.
Quick to set up
It is useful for proof-of-concept (POC) scenarios because it can be configured quickly.
Encrypted communication
Traffic is encrypted as it traverses the public internet.
Redundancy
Each Site-to-Site VPN connection has two tunnels—tunnel one and tunnel two—for redundancy.

6.4 Routing Types

When configuring a Site-to-Site VPN connection, you can choose different routing types:

Static routing
Dynamic routing using BGP
Policy-based routing

Routing is configured per tunnel. Since there are two tunnels, Oracle recommends configuring the same routing type for both tunnels.

6.5 Components of Site-to-Site VPN

A typical Site-to-Site VPN setup includes:

On-premises environment
OCI region
Virtual Cloud Network (VCN)
Dynamic Routing Gateway (DRG) attached to the VCN
Customer Premises Equipment (CPE) on the on-premises side
Internet as the transport medium
Site-to-Site VPN connection with two tunnels

6.6 Customer Premises Equipment (CPE) and CPE Object

The Customer Premises Equipment (CPE) can be:

Software-based
Hardware-based

The CPE lies on the on-premises side. However, when creating a Site-to-Site VPN connection in OCI, you must provide a virtual representation of the CPE on the OCI side. This virtual representation is called the CPE object.

The CPE has a public IP address. This public IP address can have up to eight IPsec connections.

6.7 IPsec Connection

An IPsec connection connects the CPE object to the Dynamic Routing Gateway on the OCI side. It represents the Site-to-Site VPN connection.

Each IPsec connection has two tunnels for redundancy. Each tunnel includes configuration information such as:

A public IP address
A shared secret

This configuration information is required when configuring the CPE on the on-premises side.

6.8 NAT and IKE Considerations

Sometimes the CPE device may lie behind a NAT device on the on-premises side.

By default, Oracle uses the CPE’s public IP address. However, if the CPE is behind a NAT device, you need to change the CPE Internet Key Exchange (IKE) identifier and point it to the CPE’s private IP address.

Oracle supports both:

IKE version 1
IKE version 2

Site-to-Site VPN - part 2

Site-to-Site VPN provides an encrypted IPsec connection between an on-premises environment and a VCN in Oracle Cloud Infrastructure. It uses the internet for transport but keeps traffic secure through encryption. Each IPsec connection creates two redundant tunnels for high availability, and Oracle supports both IKE version 1 and version 2. Common use cases include proof-of-concept deployments, connecting branch locations and data centers, securely connecting existing infrastructure, connecting multiple clouds, and providing redundancy for FastConnect. The main components are the CPE on-premises, the CPE object in OCI, the Dynamic Routing Gateway attached to the VCN, and the IPsec connection that links the CPE object to the DRG. Each tunnel has a public IP address and a pre-shared key, and a single CPE public IP can support up to eight IPsec connections. Routing can be static, dynamic using BGP, or policy-based. Oracle supports tunnel mode, which encrypts and authenticates the entire packet. If the CPE is behind NAT, the IKE identifier must be changed to the CPE private IP address.

1. Overview of Site-to-Site VPN

A Site-to-Site VPN connection provides a site-to-site IPsec connection between an on-premises environment and a Virtual Cloud Network (VCN) in Oracle Cloud Infrastructure.

The IPsec protocol encrypts traffic before packets are transferred and decrypts them when they arrive. The communication happens over the internet, but it is encrypted.

2. Key Features

Site-to-Site VPN offers the following features:

Encrypted and secure connection between your network and Oracle Cloud Infrastructure.
High availability because each IPsec connection creates two tunnels using two redundant Oracle routers.
Support for both Internet Key Exchange (IKE) version 1 and version 2.
Communication over the internet, with encryption protecting the traffic.

6.9 Common Use Cases

Site-to-Site VPN can be used for:

Proof of concept (POC) — no contract or commitment is required, and setup is fast because no dedicated lines are needed.
Connecting headquarters, branch locations, and private data centers to Oracle Cloud Infrastructure so all sites can access applications.
Securely connecting existing infrastructure to the cloud.
Connecting multiple clouds.
Providing a redundant connection when using Oracle FastConnect.

6.10 Main Components

Customer Premises Equipment (CPE)

The CPE is deployed in your on-premises environment. It can be:

Hardware-based
Software-based

Verified equipment vendors include Cisco, Fortinet, Check Point, Juniper, and Libreswan.

CPE Object

When creating an IPsec connection, you need a CPE object. This object is the virtual representation of your on-premises router. To create a CPE object, you provide:

A name
A public IP address

A single CPE object public IP can have up to eight IPsec connections.

Dynamic Routing Gateway (DRG)

On the OCI side, the Dynamic Routing Gateway is attached to the VCN. It acts like a VPN headend at the OCI end.

IPsec Connection

An IPsec connection connects the CPE object to the Dynamic Routing Gateway. When the connection is created, it results in the creation of two IPsec tunnels: tunnel 1 and tunnel 2.

Each tunnel has:

A public IP address
A pre-shared key

These details are needed when configuring the CPE on the on-premises side.

6.11 Routing Options

Site-to-Site VPN supports:

Static routing
Dynamic routing using BGP
Policy-based routing

Routing is configured per tunnel. Since each connection has two tunnels, Oracle recommends using the same routing type for both.

6.12 IPsec Modes

There are two IPsec modes:

Tunnel mode — encrypts and authenticates the entire packet, including both the header and payload. Oracle supports tunnel mode.
Transport mode — encrypts only the payload, while the header stays intact.

7. NAT and IKE Considerations

By default, the Internet Key Exchange (IKE) identifier is the public IP address of the CPE. If the CPE is behind a NAT device, you must configure a new IKE identifier using the private IP address of the CPE.

Oracle supports both IKE version 1 and version 2.

7. Fast Connect

Oracle FastConnect is a dedicated, private connection between an on-premises environment and Oracle Cloud Infrastructure, offering higher bandwidth, greater reliability, and more consistent network performance. Key concepts include FastConnect locations, metro areas, Oracle partners, third-party providers, co-location, cross-connects, cross-connect groups, dynamic routing gateways, virtual circuits, BGP sessions, BFD, Oracle edge devices, and letters of authorization. FastConnect has both a physical side, represented by the cross-connect, and a logical side, represented by the virtual circuit. Virtual circuits can be public, for connecting to public OCI services, or private, for connecting to a VCN, with a DRG required for private peering. BGP sessions exchange routing information between autonomous systems, while BFD verifies connectivity and detects failures without exchanging routing information. The Oracle edge includes a physical device that terminates the cross-connect and a logical device that terminates the virtual circuit. Finally, an LOA is not needed for Oracle partners but is used for third-party providers and co-location to authorize the provisioning of the physical connection in a FastConnect location.

7.1 What Is FastConnect?

FastConnect is a dedicated and private connection between your on-premises environment and Oracle Cloud Infrastructure (OCI).

Because it is dedicated and private, it provides:

Higher bandwidth options
More reliable connectivity
More consistent network experience

7.2 Key FastConnect Concepts

FastConnect

FastConnect is a private, physical connectivity between OCI and your on-premises network.

FastConnect Location

A FastConnect location is an Oracle data center where you can connect to Oracle Cloud Infrastructure.

Metro Area

A metro area is a geographical area with multiple FastConnect locations.

Oracle Partner vs. Third-Party Provider

Both are network service providers.

Oracle partner: A network service provider that has integrated with Oracle in a FastConnect location.
Third-party provider: A network service provider that is not on the list of Oracle partners.

This distinction is important for understanding the different connectivity models.

Co-Location

Co-location means your equipment is also deployed in a FastConnect location. In a FastConnect location, there is usually an Oracle cage with Oracle edge servers. In co-location, you also have a cage with your edge servers.

Cross-Connect

Cross-connect is the physical connection in FastConnect. It is a physical cable connecting your network to Oracle in a FastConnect location.

Cross-Connect Group

A cross-connect group is a collection of cross-connects. You may use it when your bandwidth needs increase.

Dynamic Routing Gateway (DRG)

A VCN can have a Dynamic Routing Gateway attached to it. A DRG is necessary for private peering. For public peering, the DRG does not come into action.

Virtual Circuit

A virtual circuit is the logical connection in FastConnect. It represents an isolated network path that runs over the physical network.

There are two types of virtual circuits:

Public virtual circuit: Used for a dedicated connection between an on-premises network and public OCI services.
Private virtual circuit: Used for private communication between an on-premises environment and a Virtual Cloud Network.

BGP Session

A BGP session is the exchange of routing information between two autonomous systems.

BFD

BFD stands for Bi-directional Forwarding Detection. It verifies connectivity between devices and detects failures between adjacent networks. It does not exchange routing information.

Oracle Edge

In a FastConnect location, there is an Oracle cage containing an Oracle edge. The Oracle edge has both a physical device and a logical device:

Physical device: Terminates the physical connection, which is the cross-connect.
Logical device: Terminates the logical connection, which is the virtual circuit.

Letter of Authorization (LOA)

LOA stands for Letter of Authorization. It is a letter that provides authorization to another party within a FastConnect location data center to help provision the physical connection.

Oracle partner: LOA is not applicable because the partner already has an established physical connection with Oracle in a FastConnect location.
Third-party provider: LOA is applicable. Oracle gives you the LOA, and you hand it to the third-party provider so they can lay the physical connection in the FastConnect location.
Co-location: LOA is applicable. Since there is no third-party provider, you provide the LOA to the FastConnect location data center technician to help complete provisioning of the physical connection.

7.3 Physical vs. Logical Connection

FastConnect has two aspects:

Aspect	Meaning
Physical connection	Cross-connect
Logical connection	Virtual circuit

The virtual circuit runs over the physical network as an isolated network path.

Fast Connect - part 2

OCI FastConnect offers three connectivity models: with an Oracle partner, with a third-party provider, and co-location with Oracle. In the OCI Console, you choose between Oracle Partner and FastConnect Direct, where FastConnect Direct covers third-party provider and co-location options. With an Oracle partner, the partner already has an established connection to the FastConnect location, so no Letter of Authorization is needed; you simply work with the partner to provision the physical connection from your data center to the partner edge. With a third-party provider, you choose a network carrier that is not an Oracle partner, and the carrier is responsible for the physical connection between your on-premises environment and the Oracle FastConnect edge. This model requires an LOA from Oracle, which you forward to the third-party provider so they can perform the cross-connect. In co-location with Oracle, you already have a cage and edge devices in the FastConnect location. Oracle provides an LOA that you give to the data center provider, and a direct fiber cross-connect is established between your cage and the Oracle cage. In short, LOA is not needed for Oracle partners but is required for third-party providers and co-location.

7.4 Overview of the Three Connectivity Models

There are three connectivity models for OCI FastConnect:

FastConnect with an Oracle partner
FastConnect with a third-party provider
FastConnect co-location with Oracle

When you create a FastConnect connection in the OCI Console, you will see two main options:

Oracle Partner
FastConnect Direct

The FastConnect Direct option includes:

Third-party provider
Co-location with Oracle

7.5 FastConnect with an Oracle Partner

Architecture

Customer data center with Customer Premises Equipment (CPE)
FastConnect location containing the Oracle cage and Oracle FastConnect edge
OCI

How It Works

An Oracle partner is a network service provider that has already established a connection with the FastConnect location. Because this connection already exists, there is no need for a Letter of Authorization (LOA).

You work with the Oracle partner to provision a physical connection from your data center to the partner edge inside the FastConnect location. You can think of this as connecting through the partner network.

Key Point

LOA is not applicable.
The partner already has connectivity to Oracle.

7.6 FastConnect with a Third-Party Provider

Architecture

Customer data center
FastConnect location with Oracle cage and Oracle edge
OCI

How It Works

A third-party provider is a network service provider that is not on the list of Oracle partners. You choose a network carrier of your choice.

The network carrier is responsible for providing the physical connection between your on-premises environment and the Oracle FastConnect edge devices.

Role of LOA

In this model, an LOA is required:

Oracle provides you with the LOA.
You forward the LOA to the third-party provider.
The third-party provider performs the cross-connect.

You are ordering a private or dedicated circuit from a network carrier that is not an Oracle partner.

Key Point

LOA is applicable.
The third-party provider handles the physical connection using the LOA.

7.7 FastConnect Co-Location with Oracle

Architecture

Customer data center
FastConnect location
Customer cage with edge devices
Oracle cage with physical and logical devices
OCI

How It Works

In co-location, you already have a presence at an Oracle FastConnect location. Your cage and edge servers are already deployed there.

To establish the connection:

Oracle gives you an LOA.
You provide the LOA to the data center provider.
A direct cross-connect is established.

The physical connection is a direct fiber cross-connect between your cage and the Oracle cage.

Key Point

LOA is applicable.
You provide the LOA to the data center provider, not a third-party network carrier.

Fast Connect - part 3

Oracle FastConnect is a dedicated, private connection between an on-premises network and OCI, offering high bandwidth, low latency, no egress data transfer charges, and private communication that does not traverse the internet. There are three connectivity models: FastConnect with an Oracle partner, which is the least expensive and most flexible; FastConnect Direct co-location, which is ideal if you already have a presence in a FastConnect location; and FastConnect Direct with a third-party provider, which is suitable if you already work with a network carrier or your data center is not served by an Oracle partner. On the logical side, FastConnect supports two types of peering: private peering, which extends your on-premises infrastructure into a VCN and requires a Dynamic Routing Gateway, and public peering, which connects to OCI public services without using the internet. Key concepts include FastConnect locations, metro areas, Oracle partners, third-party providers, co-location, cross-connects, virtual circuits, physical and logical devices, and letters of authorization. The LOA is issued by Oracle and is required for third-party providers and co-location, but not for Oracle partners. This overview consolidates the essential FastConnect concepts and connectivity models covered in the lessons.

1. What Is FastConnect?

FastConnect is a dedicated and private connection between an on-premises network and Oracle Cloud Infrastructure (OCI).

Key benefits:

High bandwidth options
Suitable for latency-sensitive applications
No egress data transfer charges
Communication is private and does not traverse the internet
It is a dedicated physical connection

7.8 FastConnect Connectivity Models

There are three connectivity models for FastConnect:

Option 1: FastConnect with an Oracle Partner

The Oracle partner has a pre-established physical connectivity with OCI.
You form a relationship with the partner and establish a connection from your on-premises network to the partner edge inside the Oracle FastConnect location.
Least expensive and most flexible model among the three.

Option 2: FastConnect Direct Co-Location

The customer already has a presence in the FastConnect location.
You establish a connection between your cage and the Oracle cage.
A good model if you already have presence in the FastConnect location.

Option 3: FastConnect Direct with a Third-Party Provider

You work with a network carrier of your choice to get a physical connection from your data center to the FastConnect location.
A good model if:
- You are already working with a network carrier.
- Your data center is not served by any of Oracle's FastConnect partners.

7.9 Types of Peering

On the logical side of FastConnect (virtual circuits), there are two types of peering:

Private Peering

Extends your on-premises infrastructure into a VCN.
Requires a Dynamic Routing Gateway (DRG) .

Public Peering

Connects your on-premises network to OCI public services without using the internet.
The DRG does not come into action for public peering.

7.10 Choosing the Right Connectivity Model

Model	Best For
Oracle Partner	Cost-effectiveness and flexibility; partner already connected to Oracle.
Co-Location	Customers who already have a presence in a FastConnect location.
Third-Party Provider	Customers already working with a network carrier or whose data center is not served by an Oracle partner.

8. Fast Connect With an Oracle Partner

FastConnect with an Oracle partner uses the partner’s pre-established redundant cross-connects to the FastConnect edge devices, so no Letter of Authorization is needed. You work with the partner to provision physical connectivity from your data center to the partner edge. The configuration process involves ordering the connection from the partner, setting up a Dynamic Routing Gateway if you are using a private virtual circuit or private peering, creating one or more virtual circuits, providing each virtual circuit’s OCID to the partner, configuring your edge for BGP peering, and verifying that light levels are good and interfaces are up. The BGP session can terminate either at Oracle or at the partner edge, and validation steps differ accordingly: if the session goes to Oracle, ping the Oracle BGP IP and confirm the session; if it goes to the partner, ping the partner edge, confirm the BGP session to the partner, then ping the Oracle BGP IP. Finally, test the connection to confirm successful connectivity.

8.1 Architecture Overview

In this connectivity model:

The OCI region contains a VCN with a private subnet and a public subnet.
The FastConnect location contains an Oracle cage with an edge device.
The customer data centers contain Customer Premises Equipment (CPE).

In the case of an Oracle partner, the partner has already established redundant cross-connects with the FastConnect edge devices. Because of this, no Letter of Authorization (LOA) is needed.

You work with the partner to provision the physical connectivity from your data center to the partner edge device.

8.2 Configuration Steps

Step 1: Order the Connection from the Oracle Partner

Order the connection from the Oracle partner. The time required may vary depending on the partner.

Step 2: Set Up a Dynamic Routing Gateway (If Needed)

If you plan to use a private virtual circuit or private peering, you also need to set up a Dynamic Routing Gateway (DRG) .

Step 3: Create Virtual Circuits

You can create one or more virtual circuits for your FastConnect connection. When a virtual circuit is created, an OCID is generated.

Step 4: Provide OCIDs to the Partner

Contact the partner and give them the OCID for each virtual circuit you created. The partner will then configure each virtual circuit on their end to complete the connectivity.

Step 5: Configure Your Edge

You need to configure your edge or Customer Premises Equipment to use the BGP peering information.

There are two possible scenarios:

The BGP session can go to Oracle.
The BGP session can go to the Oracle partner edge.

Depending on which scenario applies, configure your edge accordingly.

Step 6: Verify Physical Connections

Confirm that for each physical network connection to the partner:

The light levels are good.
The interfaces are up.

8.3 BGP Session Validation

The validation steps depend on where the BGP session terminates.

If the BGP Session Goes to Oracle

Ping the Oracle BGP IP address.
Confirm that the BGP session is established.

If the BGP Session Goes to the Oracle Partner

Ping the Oracle partner’s edge.
Confirm that the BGP session to the Oracle partner is established.
Then ping the Oracle BGP IP address.

Final Step

After the BGP session is validated, test the connection.

9. Fast Connect With a Third-Party Provider

FastConnect with a third-party provider uses a network carrier that is not an Oracle partner to establish the physical connection between your on-premises environment and the Oracle FastConnect edge devices. In this model, the third-party provider is responsible for the physical connection from your data center to the provider and for setting up the physical fiber cross-connect in the FastConnect location on your behalf. Oracle provides a Letter of Authorization, which you forward to the third-party provider so they can provision the circuit. This model is suitable if you already have a relationship with a third-party provider or if Oracle partners do not serve your data center. The configuration process involves setting up a Dynamic Routing Gateway if using a private virtual circuit, creating a cross-connect group and cross-connect, receiving and forwarding the LOA, having the third-party provider request cabling, verifying light levels and interface status, activating each cross-connect, creating virtual circuits, configuring edge routers for BGP, pinging the Oracle BGP address to confirm the BGP session, and testing the connection. This model provides flexibility for customers who are not served by Oracle partners or who prefer to work with their existing network carrier.

9.1 Architecture Overview

In this connectivity model:

The OCI region contains the VCN.
The FastConnect location contains the Oracle cage and FastConnect edge devices.
A third-party provider (network carrier) is responsible for the physical connection between the on-premises environment and the Oracle FastConnect edge devices.

The third-party provider is not an Oracle partner.

9.2 Physical Connections

There are two physical connections in this model:

Connection from the customer data center to the provider
This connects your on-premises environment to the third-party provider.
Physical fiber connection (cross-connect) in the FastConnect data center
The third-party provider sets up this cross-connect in the FastConnect location on your behalf.

9.3 When to Use This Model

This connectivity model is suitable when:

You already have an existing relationship with a third-party provider.
Oracle partners are not currently serving your data center.

9.4 Role of the Letter of Authorization (LOA)

In this model, Oracle provides you with a Letter of Authorization (LOA) . You must provide this LOA to the third-party provider. The third-party provider then uses it to provision the circuit for you.

9.5 Configuration Steps

Step 1: Set Up a Dynamic Routing Gateway (If Needed)

If you are working with a private virtual circuit, create and set up a Dynamic Routing Gateway (DRG) .

Step 2: Set Up Cross-Connect Group and Cross-Connect

Set up your cross-connect group and cross-connect.

Step 3: Receive and Forward the LOA

After setting up the cross-connect group and cross-connect, you will receive an LOA from Oracle. Forward this LOA to the third-party provider.

Step 4: Third-Party Provider Requests Cabling

The third-party provider requests cabling at the FastConnect location.

Step 5: Verify Physical Connections

After the third-party provider completes the physical cross-connect setup:

Confirm that the light levels for each physical connection are good.
Confirm that the interfaces are up for each cross-connect.

Step 6: Activate Each Cross-Connect

When the physical fiber cables in the FastConnect location are set up and ready, activate each cross-connect. This activation informs Oracle that the physical fiber cable is ready.

Step 7: Set Up Virtual Circuits

Create one or more virtual circuits for your connection.

Step 8: Configure Edge Routers

Configure your edge routers to use the BGP information. Then ping the Oracle BGP address and confirm that the BGP session to Oracle is established.

Step 9: Test the Connection

After confirming the BGP session, test the connection.

10. Fast Connect Colocation with Oracle

FastConnect co-location with Oracle is a connectivity model where the customer already has a presence in the FastConnect data center location, with their own cage and Customer Premises Equipment deployed there. This model is suitable when you already have equipment in an Oracle FastConnect location. To establish the connection, you create a direct cross-connect between your edge and the FastConnect edge device in the Oracle cage. Oracle provides a Letter of Authorization, which you hand over to the data center provider to configure the direct cross-connect. The configuration process involves setting up a Dynamic Routing Gateway if using private peering or a private virtual circuit, creating a cross-connect group and cross-connect, submitting the LOA and requesting cabling, verifying light levels and interface status, activating each cross-connect, creating virtual circuits, configuring edge routers for BGP, pinging the Oracle BGP address to confirm the BGP session, and testing the connection. This model offers a direct, high-bandwidth, private connection for customers who already have infrastructure in an Oracle FastConnect location.

10.1 What Is FastConnect Co-Location with Oracle?

FastConnect co-location with Oracle means that the customer already has a presence in the FastConnect data center location.

In this model:

The FastConnect data center location contains an Oracle cage with FastConnect edge devices.
The customer also has a cage in the same data center location.
The customer's Customer Premises Equipment (CPE) is already deployed in the customer cage.

All you need to do is create a cross-connect between your edge (customer premises equipment) and the FastConnect edge (Oracle edge).

10.2 Architecture Overview

The architecture includes:

OCI region containing the VCN.
FastConnect location containing:
- Oracle cage with FastConnect edge devices.
- Customer cage with Customer Premises Equipment.
Customer data center (separate from the FastConnect location).

In co-location, you establish a redundant physical connection (cross-connect) between the customer equipment and the FastConnect edge device deployed in the Oracle cage.

10.3 When to Use This Model

This connectivity model is suitable if:

You already have a presence at an Oracle FastConnect location.
Your customer cage and equipment are already deployed in the FastConnect data center.

10.4 Role of the Letter of Authorization (LOA)

To establish the connection:

Oracle provides you with a Letter of Authorization (LOA) .
You hand over the LOA to the data center provider.
The data center provider configures the direct cross-connect.

10.5 Configuration Steps

Step 1: Set Up a Dynamic Routing Gateway (If Needed)

If you plan to use private peering or a private virtual circuit, set up a Dynamic Routing Gateway (DRG) .

Step 2: Set Up Cross-Connect Group and Cross-Connect

Set up your cross-connect group and cross-connect. The connection can consist of a cross-connect group or just a single cross-connect.

Step 3: Submit LOA and Request Cabling

At the FastConnect location, submit the Letter of Authorization and request cabling for each cross-connect.

Step 4: Verify Physical Connections

Check the light levels for each cross-connect and confirm that they are good. Also confirm that the interfaces are up.

Step 5: Activate Each Cross-Connect

When the physical fiber cables in the FastConnect location are set up and ready to use, activate each cross-connect.

Step 6: Create Virtual Circuits

Create one or more virtual circuits for your connection.

Step 7: Configure Edge Routers

Configure each of your edge routers to use the BGP information for the virtual circuit.

Step 8: Verify BGP Session

Ping the Oracle BGP address and confirm that the BGP session is established.

Step 9: Test the Connection

After confirming the BGP session, test the connection.

11. FastConnect Redundancy Best Practices

FastConnect redundancy best practices focus on eliminating single points of failure. Oracle provides multiple partners per region, multiple physical connections between each partner and Oracle, at least one FastConnect location per region, and a minimum of two FastConnect routers per location. For Oracle partner connections, Oracle handles redundancy between the partner and Oracle and router redundancy in FastConnect locations, while the customer must ensure redundancy between their network and the partner network. Layer 2 partner connections use direct BGP between the customer edge and Oracle, with each virtual circuit on a different physical router, while Layer 3 connections use a single automatically redundant virtual circuit with BGP between the customer edge and the Oracle Partner. For third-party provider and co-location models, Oracle handles router redundancy, but the customer is responsible for redundant physical connections, typically using two virtual circuits on two physical connections. Finally, Site-to-Site VPN can back up FastConnect, with at least one IPsec tunnel and optional ECMP across multiple tunnels for extra bandwidth; FastConnect is preferred over VPN when the same route and routing attributes are advertised.

11.1 Oracle-Provided Redundancy

Oracle provides multiple partners for each region. Between each Oracle partner and Oracle, there are multiple physical connections. There is at least one FastConnect location for each region, and some regions have more than one.

In a FastConnect location, there is a minimum of two FastConnect routers.

11.2 Physical Overview of a FastConnect Location

A FastConnect location contains edge devices. For example, if there are two FastConnect locations, each may have two edge devices.

If you configure a cross-connect, it is represented by a physical path. If you want redundancy:

A second cross-connect should ideally go to a different FastConnect location.
If a second location is not available, connect to a different FastConnect edge device within the same location.

This ensures the connection remains available even if one location or device fails.

11.3 Oracle Partner Redundancy

What Oracle Handles

For an Oracle partner, Oracle handles:

Redundancy of the physical connection between the partner and Oracle.
Redundancy of routers in FastConnect locations.

What the Customer Handles

The customer must ensure that the physical connection between their existing network and the Oracle Partner Network is redundant.

Layer 2 vs. Layer 3 Connections

Partner connections come in two types:

Layer 2 Connection

The FastConnect BGP session is directly between the customer edge and Oracle.
At a minimum, each partner has two separate physical connections to Oracle.
Each virtual circuit should go to a different physical router in the FastConnect location.

Layer 3 Connection

There is only a single virtual circuit, and it is automatically redundant and diverse.
The FastConnect BGP session is between the customer edge and the Oracle Partner.
Separate redundant BGP sessions already exist between Oracle and the Oracle Partner.
The customer must ensure that the connection between the customer edge and the provider is redundant and diverse.

11.4 Third-Party Provider and Co-Location Redundancy

For a third-party provider or co-location with Oracle:

Oracle handles the redundancy of the routers in FastConnect locations.
The customer is responsible for making the physical connection between their network and Oracle redundant.

In FastConnect Direct (co-location or third-party provider):

There are typically two virtual circuits.
Each virtual circuit runs on a different physical connection to a different edge device.

11.5 Site-to-Site VPN as a Backup

You can configure Site-to-Site VPN as a backup for FastConnect:

FastConnect private peering is the primary connection.
IPsec VPN tunnels serve as backup.
Configure at least one available tunnel.
You can use ECMP across multiple tunnels for additional VPN bandwidth.

When the same route and routing attributes are advertised over both connections, FastConnect is preferred over VPN.

12. Transit Routing Scenarios

Transit routing enables an on-premises network to communicate with multiple VCNs through a single connection to a hub VCN, avoiding the cost and overhead of multiple Site-to-Site VPN or FastConnect connections. The hub-and-spoke topology uses a centralized hub VCN that connects to the on-premises network via Site-to-Site VPN or FastConnect, while spoke VCNs connect to the hub via local peering gateways. All hub and spoke VCNs must be in the same region, though they can be in different tenancies. To implement transit routing, you must configure route tables for each subnet, the DRG, and each local peering gateway. In the example, six route tables are required: one for Subnet 1, one for Subnet 2, one for the DRG, one for Subnet H, and one for each LPG in the hub VCN. The route table for subnets in spoke VCNs points to the LPG as the next hop for on-premises and hub traffic. The route table for the DRG points to the LPGs for spoke VCN traffic. The route table for Subnet H points to the DRG for on-premises traffic and to the LPGs for spoke VCN traffic. The route tables for the LPGs in the hub VCN point to the DRG for on-premises traffic. In the console, you can associate a VCN route table with a DRG through the VCN attachment's advanced options, and you can associate a route table with a local peering gateway through its advanced options. The route table rules for LPGs must use a DRG as the target. This configuration enables private, efficient communication between the on-premises network and all spoke VCNs through the hub VCN.

12.1 What Is Transit Routing and Why Do We Need It?

Consider an organization with three departments: A, B, and C. Each department has its own VCN: VCN A, VCN B, and VCN C. The organization also has an on-premises network that needs access to all three VCNs.

Without transit routing, you would need to set up a separate Site-to-Site VPN or FastConnect connection for each VCN. This approach:

Increases cost.
Creates administration overhead for maintaining multiple connections.

Transit routing solves this problem by allowing the on-premises network to communicate with multiple VCNs through a single connection to a central hub VCN.

12.2 Hub-and-Spoke Topology

In transit routing, you use a hub-and-spoke topology:

Hub VCN: A centralized VCN that connects to the on-premises network.
Spoke VCNs: Other VCNs that connect to the hub VCN via local peering.

Architecture

The on-premises environment contains a Customer Premises Equipment (CPE).
The hub VCN connects to the on-premises network using either Site-to-Site VPN or FastConnect.
Each spoke VCN connects to the hub VCN using a local peering gateway (LPG) .

Traffic Flow

Traffic between the on-premises network and the peered spoke VCNs transits through the hub VCN.

Conditions

All hub and spoke VCNs must be in the same region.
They can be in different tenancies.

12.3 Example Architecture

Consider the following setup:

On-premises network: CIDR 172.16.0.0/12
Hub VCN: CIDR 10.0.0.0/16
- Contains a DRG
- Contains a CPE
- Contains Subnet H
- Has LPG Hub 1 and LPG Hub 2
Spoke VCN 1: CIDR 192.168.0.0/24
- Contains Subnet 1
- Has LPG 1
Spoke VCN 2: CIDR 192.168.1.0/24
- Contains Subnet 2
- Has LPG 2

12.4 Route Table Configuration

To enable transit routing, you must configure route tables for six entities:

Route Table for Subnet 1 (Spoke VCN 1)

Destination	Next Hop
`172.16.0.0/12`	LPG 1
`10.0.0.0/16`	LPG 1

Route Table for Subnet 2 (Spoke VCN 2)

Destination	Next Hop
`172.16.0.0/12`	LPG 2
`10.0.0.0/16`	LPG 2

Route Table for DRG (Attached to Hub VCN)

Destination	Next Hop
`192.168.0.0/24`	LPG Hub 1
`192.168.1.0/24`	LPG Hub 2

Note: Do not modify the DRG's own route table. Instead, create a route table in the VCN and attach it to the DRG.

Route Table for Subnet H (Hub VCN)

Destination	Next Hop
`172.16.0.0/12`	DRG
`192.168.0.0/24`	LPG Hub 1
`192.168.1.0/24`	LPG Hub 2

Route Table for LPG Hub 1

Destination	Next Hop
`172.16.0.0/12`	DRG

Route Table for LPG Hub 2

Destination	Next Hop
`172.16.0.0/12`	DRG

12.5 Associating Route Tables in the Console

Associating a VCN Route Table with a DRG

Navigate to the DRG.
Go to the VCN attachment.
Click Edit.
Click Show Advanced Options.
Select the VCN route table to attach.
Click Save.

Note: Use this advanced feature only when setting up transit routing. Once a route table is attached, you can change it but cannot set it to none.

Associating a Route Table with a Local Peering Gateway

Navigate to the VCN.
Click Local Peering Gateway.
Provide a name.
Click Show Advanced Options.
Select the route table to associate.

Important: The route table rules must use a dynamic routing gateway as the target (or a private IP). If you select a route table without a DRG target, you will receive an error.