Overview

FastConnect is a way to create a private connection between customer on-prem and Oracle Cloud Infrastructure. FastConnect supports bandwidths from 1Gbps to 10Gbps. There are three FastConnect options to choose from Oracle Provider, Third-Party Provider, and Colocation. The purpose of this blog is to help/guide you to choose the best option taking in consideration important points in the design. This blog focuses on design, for configuration and enablement, refer to the public documentation for FastConnect where you will find detail instructions for each option.

There are three main points you need to consider when deploying FastConnect:

1. What Oracle location you want to connect to
2. What services you want to connect to via FastConnect (virtual circuit)
3. What kind of FastConnect to use

1) FastConnect Locations

Oracle has various locations around the globe where Oracle Cloud Infrastructure is deployed called regions. You can find the complete list of regions on Oracle's public documentation. Each region has one or two physical entry locations called FastConnect Data Center (DC). The FastConnect DC is the entry point into the OCI region. The FastConnect DC is where the customer will establish connectivity to. Also, each FastConnect DC has redundant hardware. The diagram below depicts a traditional OCI Region with diverse FastConnect DCs and redundant hardware. Oracle recommends you using the diversity and redundancy built into the OCI region to build a resilient solution. For additional information about redundancy, review the Connectivity Redundancy Guide white paper.

2) Virtual Circuits

FastConnect refers to the physical connection between on-prem and Oracle Cloud Infrastructure (OCI). Within FastConnect you will create a virtual circuit to connect to services within OCI. There are two types of virtual circuits (VC):

Private Peering (Green Line): Create a private peering virtual circuit when you want to connect on-prem to your Virtual Cloud Network (VCN) within OCI. The virtual circuit is between the on-prem CPE and the Dynamic Routing Gateway (DRG) within the VCN. Private peering extends customer’s network to the cloud.

Public Peering (Blue Line): Create a public peering virtual circuit when you want to connect on-prem to Oracle Services Network (OSN) to access public services without using the Internet. The virtual circuit is between the on-prem CPE and the Oracle Edge device. Review the FastConnect Supported Cloud Services page to get an up to date list of services supported.

Private peering and public peering are available in all FastConnect options and work in the same way but there is a point to consider in the design that will be explained within each of the options.

3) FastConnect Options

Oracle offers three FastConnect options to choose from. Which is the best option for your requirements or needs? Well the answer is, it depends. Here are some different points to consider in your design:

• Where is the customer’s data center located?
• How many data centers the customer wants to connect to OCI
• What relation does the customer have with providers or carriers?
• Where can the provider deliver circuits or cross connects to
• How fast does the customer want FastConnect deployed?
• Cost
• Latency
• Bandwidth

These are key points to consider in the design and choosing the proper FastConnect option. For example, if the customer has a good relation with Provider A but Provider A is not an Oracle Provider, then the next option is to use Third-Party provider or Colocation option. If Provider A can deploy circuits to the FastConnect DC but can't deploy cross connect at the FastConnect DC then customer will have to look at a different provider. If the customer is not at the same address as the FastConnect DC then Colocation is not an option.

The Customer has to work with the provider to see what services they offer, what is the cost, how much bandwidth can be delivered, what latency is been offered, how long it will take to deliver, and what diversity/redundancy is available. The customer should probably look at different providers for cost comparison, diversity, and options.

When deploying FastConnect, the customer is responsible for contracting services from the provider for this connectivity. Oracle is just providing the entry point to the cloud. The customer is fully responsible for the financials and to get the service ordered, provisioned, and deployed to Oracle. Oracle can review the design and assist in the process.

The next three sections provide information about each of the FastConnect options. Also note the support demarcation point for each of the options noted in the diagrams in yellow. Customer is responsible for configuring the environment on-prem as well as in the OCI side from the Oracle Console.

3.1 ) FastConnect Oracle Provider

On this option the provider or carrier has already established connectivity with OCI at the FastConnect DCs. The provider has established a network-to-network interface (NNI) between the provider’s network and OCI. The NNI is a SHARED connection that can be used by multiple customers separated by virtual circuits. This NNI is represented on the diagram below by the green lines. Oracle maintains on its public documentation a list of providers per region.

As pictured above the provider already has physical connectivity into OCI. The next question is if on-prem is connected to the provider’s network represented by the blue line in the diagram above (WAN circuit). If yes, then the deployment of FastConnect could be done very quickly (couple hours) via the provider’s portal and the Oracle Console. The time to deliver depends of the provider as some has already automation built in while for others is a manual process. If there is no connectivity to the provider’s network, the customer needs to work with the provider to get a circuit(s) from on-prem to the provider’s network. This process can take from 30-90 days. Note that in this solution the green line is a shared resource but the blue line is a dedicated resource.

When deploying FastConnect Oracle Provider you also need to consider if the provider you are working with is a layer 2 or layer 3 provider. The difference between them is how BGP is established with OCI. With a layer 2 provider, the BGP peering relation is between the customer and OCI. The provider is not involved in any routing as it is providing a layer 2 circuit. With a layer 3 partner there are two BGP peering relations: 1) OCI with the provider and 2) the provider with the customer. See diagram below.

The next point to consider when deploying this option is the virtual circuits. With FastConnect Oracle Provider, the provider delivers a FastConnect for every virtual circuit. For example, if the customer requires public peering and private peering virtual circuits, the customer requires two FastConnects and each FastConnect has its associated cost from the provider.

When the provier established the NNI with Oracle, it has already deployed some type of redundant connections to OCI. Now you need to build the redundancy from the virtual circuit point of view. The physical layer might be redundant but if the solution has only a single virtual circuit (private or public) and the BGP session goes down because of a router failure or WAN circuit failure then the connectivity to OCI is down. Oracle recommends building redundancy/diversity in the solution by deploying a second FastConnect with the corresponding virtual circuit from a different on-prem location or to a second FastConnect DC in the region or to the same FastConnect DC but to a diverse FastConnect Edge as the primary circuit. Customer can also mix and match with other FastConnect options or VPN Connect for redundancy. Note that VPN connect does not allow direct connectivity to OSN.

If the bandwidth requirements for FastConnect are not high, this option might be the right choice as many providers offer small bandwidth tiers to select from which might save some money. The customer can upgrade the bandwidth from the partners portal very easily as the workloads increase. In the Oracle side the smallest bandwidth tier to select from is 1G.

3.2) FastConnect Third-Party Provider

On this option the customer typically works with a provider or carrier that has a good relation with or is the current MPLS or backbone network provider. The customer will place an order with  the provider to deliver a private dedicated circuit to connect on-prem to OCI. Oracle’s public documentation provides the addresses for the FastConnect DCs where the provider needs to deliver the circuit to.

Note: It is very important that the provider or carrier selected by the customer also has the capability to request a cross connect from the provider’s cage to the Oracle cage. The cross connect is NOT provided or requested by Oracle. In order for the provider to request the cross connect it needs a Letter of Authorization (LOA) from Oracle which the customer can obtain directly from the Oracle Console by configuring FastConnect using a Third-Party provider. The customer will share the LOA with the provider to complete this task.

This option could take from 30-90 days to deploy circuit(s) as it depends where on-prem is located, what provider is been used, and if the provider is on net or not. The diagram below shows the circuit represented in blue and the cross connect represented in green.

The circuit provisioned/delivered by the provider should be a layer 2 circuit. Once the circuit is handed to the customer, the customer will configure its on-prem CPE and establish a BGP session with OCI. The provider is not involved in any routing as it is providing a layer 2 circuit.

The next point to consider when deploying this option is the virtual circuit. As opposed to FastConnect Oracle Provider, on this option the circuit is dedicated to the customer end to end; the customer can create multiple virtual circuits (private or public) within the single FastConnect at no additional charge from the provider. The customer will assign a VLAN per virtual circuit and customer will run BGP with OCI on each virtual circuit. The diagram below depicts both virtual circuits and their termination point within OCI.

Now that FastConnect is deployed, the customer has a single physical circuit perhaps with multiple virtual circuits. In this scenario, FastConnect is the single point of failure in the solution. Oracle recommends building redundancy in the solution by deploying a second FastConnect with the corresponding virtual circuit(s) from a different on-prem location or to a second FastConnect DC in the region or even to the same DC but make sure the circuit terminates in a diverse FastConnect Edge as the primary circuit. The customer can also mix and match with other FastConnect options or VPN Connect for redundancy. Note that VPN connect does not allow direct connectivity to OSN.

3.3) FastConnect Colocation with Oracle

On this option the customer’s DC is located at the same physical DC as the FastConnect DC location. To deploy FastConnect, the customer requests a cross connect from the its cage to the Oracle cage. Oracle’s public documentation provides the addresses for the FastConnect DCs and the DC providers. The cross connect is not provided or requested by Oracle at the FastConnect DC. In order for the customer to request the cross connect it needs a Letter of Authorization (LOA) from Oracle which the customer can obtain from the Oracle Console by configuring FastConnect using Colocate with Oracle. The diagram below shows this option and has the cross connect represented by the green line.

Another use is where the customer's DC is not at the same physical location as Oracle FastConnect DC but it is in a different data center from the same data center provider in the same city. In this case the customer still can use FastConnect Colocation with Oracle as usually data center providers have interconnection or dark fiber between their DCs within the same city. As you can see in the diagram below the customer DC and the FastConnect DC are located at different physical addresses but it is from the same provider (Provider X) within the same city, in this scenario the cross connect option is still valid.

This option could take from 7-16 days to deploy, it depends on how fast can the data center provider deploy the cross connect.

The next point to consider when deploying this option is the virtual circuit. As opposed to FastConnect Oracle Provider, on this option the cross connect is dedicated to the customer and the customer can create multiple virtual circuits (private or public) within the single FastConnect at no additional charge from the DC provider. The customer will assign a VLAN per virtual circuit and customer will run BGP with OCI on each virtual circuit. The diagram below depicts both virtual circuits and their termination point within OCI.

Now that FastConnect is deployed, the customer has a single physical cross connect perhaps with multiple virtual circuits. In this scenario, FastConnect is the single point of failure in the solution. Oracle recommends building redundancy in the solution by deploying a second FastConnect with the corresponding virtual circuit(s) from a different on-prem location or to a second FastConnect DC in the region or even to the same DC but make sure the circuit terminates in a diverse FastConnect Edge as the primary circuit. Oracle also offers the option to bundle multiple cross connects in a group or Link Aggregation Group (LAG) for redundancy. The customer can also mix and match with other FastConnect options or VPN Connect for redundancy. Note that VPN connect does not allow direct connectivity to OSN.

Summary

The best FastConnect option to choose for your solution depends on several points that you need to consider during the design phase. Below is a simple comparison table between the tree options. Oracle recommends, you to work with the provider of your choice to look at what options are available from them to meet FastConnect connectivity options.

Additional Resources

Please visit Oracle public documentation for how to deploy each of the options

FastConnect Oracle Provider

FastConnect Oracle Third-Party Provider

FastConnect Colocation with Oracle

Also check the Connectivity Redundancy Guide white paper and IPSec VPN Best Practices white paper