Oracle Cloud Infrastructure FastConnect provides an easy way to create a dedicated, private connection between your data center and Oracle Cloud Infrastructure. FastConnect provides higher-bandwidth options, and a more reliable and consistent networking experience compared to internet-based connections.
Uses for FastConnect
With FastConnect, you can choose to use private peering, public peering, or both.
- Private peering: To extend your existing infrastructure into a virtual cloud network (VCN) in Oracle Cloud Infrastructure (for example, to implement a hybrid cloud, or a lift and shift scenario). Communication across the connection is with IPv4 private addresses (typically RFC 1918).
- Public peering: To access public services in Oracle Cloud Infrastructure without using the internet. For example, Object Storage, the Oracle Cloud Infrastructure Console and APIs, or public load balancers in your VCN. Communication across the connection is with IPv4 public IP addresses. Without FastConnect, the traffic destined for public IP addresses would be routed over the internet. With FastConnect, that traffic goes over your private physical connection. For a list of the services available with public peering, see FastConnect Supported Cloud Services. For a list of the public IP address ranges (routes) that Oracle advertises, see FastConnect Public Peering Advertised Routes.
In general it's assumed you'll use private peering, and you might also use public peering. Most of this documentation is relevant to both, with specific details called out for private versus public.
If you choose to have multiple paths from your on-premises network to Oracle, see Routing Details for Connections to Your On-Premises Network.
IPv6 addressing is supported for all commercial and government regions. For more information, see IPv6 Addresses.
It is possible to connect two VCNs in different regions using FastConnect colocation, with inter-region traffic using that link rather than the Oracle backbone. A Layer 3 device is required to implement this, even for a layer 2 connection. Details of this use case are not available, but are similar to Connecting Oracle Cloud Infrastructure to Amazon VPC with Megaport Cloud Router or Connecting Oracle Cloud Infrastructure to Google Cloud Platform with Equinix Network Edge Cloud Router.
With FastConnect, there are different connectivity models to choose from.
- List of Oracle Cloud Infrastructure FastConnect partners
- Port speeds in 1 Gbps, 10 Gbps, or 100 Gbps increments
- Instructions for integrating: FastConnect: With an Oracle Partner
- Port speed of 1 Gbps, 10 Gbps, or 100 Gbps per cross-connect
- Instructions for integrating: FastConnect: With a Third-Party Provider
Colocation with Oracle in an Oracle Cloud Infrastructure FastConnect Location
- List of Oracle Cloud Infrastructure FastConnect locations
- Port speed of 1 Gbps, 10 Gbps, or 100 Gbps per cross-connect
- Instructions for integrating: FastConnect: Colocation with Oracle
The following table summarizes several important requirements for each connectivity model.
|Requirement||With Oracle Partner||With Third-Party Provider||Colocation with Oracle|
|Layer 3 support||Recommended||Recommended||Recommended|
|Obtain a Letter of Authority (LOA) from Oracle||N/A||Yes||Yes|
|Cross-connect||Yes (from the partner)||Yes||Yes|
|Redundant network connectivity||Recommended||Recommended||Recommended|
|Cloud connectivity solution architecture support||Recommended||Recommended||Recommended|
|Oracle Cloud Infrastructure Console user login (IAM policy unique setup)||Yes||Yes||Yes|
Here are some important concepts to understand (also see the following diagrams):
- The general concept of a connection between your existing network and Oracle Cloud Infrastructure over a private physical network instead of the internet.
- FastConnect location
- A specific Oracle data center where you can connect to Oracle Cloud Infrastructure.
- METRO AREA
- A geographical area (for example, Ashburn) with multiple FastConnect locations. All locations in a metro area connect to the same set of availability domains for resiliency if there is failure in a single location.
- ORACLE PARTNER
- A network service provider that has integrated with Oracle in a FastConnect location. See the list of the Oracle partners in How and Where to Connect. If your provider is in the list, see FastConnect: With an Oracle Partner.
- THIRD-PARTY PROVIDER
- A network service provider that is NOT on the list of Oracle partners in How and Where to Connect. If you have a third-party provider and want to use FastConnect, see FastConnect: With a Third-Party Provider.
- The situation where your equipment is deployed into a FastConnect location. If your network service provider is not on the list of Oracle partners in How and Where to Connect, you must colocate.
- In a colocation or third-party provider scenario, this is the physical cable connecting your existing network to Oracle in the FastConnect location.
- CROSS-CONNECT GROUP
- In a colocation or third-party provider scenario, this is a link aggregation group (LAG) that contains at least one cross-connect. You can add more cross-connects to a cross-connect group as your bandwidth needs increase. This is applicable only for colocation.
- VIRTUAL CLOUD NETWORK (VCN)
- Your virtual network in Oracle Cloud Infrastructure. You can use a VCN to extend your infrastructure into the cloud. For more information, see VCNs and Subnets.
- DYNAMIC ROUTING GATEWAY (DRG)
- A virtual edge router attached to your VCN. Necessary for private peering. The DRG is a single point of entry for private traffic coming in to your VCN, whether it's over FastConnect or a Site-to-Site VPN link. After creating the DRG, you must attach it to your VCN and add a route for the DRG in the VCN's route table to enable traffic flow. Instructions for everything are included in the sections that follow.
- VIRTUAL CIRCUIT
- An isolated network path that runs over one or more physical network connections to provide a single, logical connection between the edge of your existing network and Oracle Cloud Infrastructure. Private virtual circuits support private peering, and public virtual circuits support public peering (see Uses for FastConnect). Each virtual circuit is made up of information shared between you and Oracle (and also a partner if you're connecting through an Oracle partner). You could have multiple private virtual circuits, for example, to isolate traffic from different parts of your organization (one virtual circuit for 10.0.1.0/24; another for 172.16.0.0/16), or to provide redundancy.
- BGP SESSION
Border Gateway Protocol (BGP) exchanges routing and reachability information between autonomous systems (AS). A session between the two systems is established and routing information on both sides is advertised to the other side, while periodic messages are sent to verify that both sides are available to exchange traffic. If the BGP session is not established or goes down, traffic can't pass between the two systems even if the devices and physical connections are functioning correctly. When you choose to deactivate a virtual circuit, its associated BGP session is ended, and will have to be rebuilt when you re-activate the virtual circuit.
- BIDIRECTIONAL FORWARDING DETECTION
Bidirectional Forwarding Detection (BFD) is a method for detection of failures in the path between adjacent networks. It provides an additional mechanism that can be used to verify connectivity between a pair of devices, but does not exchange route information. BFD provides faster failover than is possible with BGP timers. Short BGP timers can also lead to false positives unlike fast BFD.
- ORACLE EDGE
- The Oracle edge for a given connection consists of two distinct constructs: a physical device and a logical device.
- PHYSICAL DEVICE
- This is the FastConnect device that terminates the physical connection, also called a cross connect or cross connect group.
- LOGICAL DEVICE
- This is the FastConnect device that terminates the logical connection, also called a virtual circuit. This device might be different than the device that terminates the physical connection.
FastConnect can be configured to use MACsec (IEEE standard 802.1AE) to protect network-to-network connections on Layer 2. When MACsec is enabled you choose an advanced encryption standard (AES) encryption algorithm, two security keys are exchanged and verified between two connected networks, and then a secure bi-directional link is established. The Oracle Cloud Infrastructure Vault service securely stores the actual encryption keys.
Using MACsec has the following requirements:
- Your customer premises equipment (CPE) device must also support MACsec.
- The FastConnect virtual circuit or LAG speed must be 10 Gbps or greater.
- Not all esisting cross-connect or cross-connect group can support MACsec. To upgrade an existing cross-connect or cross-connect group, the details page for the cross-connect or cross-connect group has a MACsec Encryption field that could be set to either Capable or Incapable. The connection must be capable of using MACsec. If the cross-connect or cross-connect group is Incapable of using MACsec, you will need to re-provision before configuring MACsec.
- Not all third-party providers can support MACsec on the type of circuit they provide. Please check with your provider to verify that the type of conectivity you purchase supports MACsec.
FastConnect with MACsec integrates with the Vault service. Here is an overview of the steps that are required to fully configure FastConnect with MACsec.
- Create a Vault.
- Create a master encryption key in Vault.
- Create two secrets to represent the Connectivity Association Key (CAK) and Connectivity association Key Name (CKN) in your Vault. The CAK and CKN must be hexadecimal strings with a length of 32–64 characters.
- Configure MACsec in a Third-party provider or colocation cross-connect using the CKN and CAK secrets created for the FastConnect circuit.
- Give your on-premises network administrator the original CAK and CKN keys to use when configuring the customer premises equipment device.
- Activate the cross-connects for the third-party provider or colocation virtual circuit.
If you decide to add MACsec encryption to an existing FastConnect cross-connect, remember that changing the encryption settings requires restarting the BGP session which briefly suspends BGP traffic.
When configuring MACsec on your CPE, refer to the below table for various required parameters.
|CAK||32-64 hexadecimal characters||Minimum of 32 hexadecimal characters (0-9, A-F).|
|Configure your CPE to match the cipher suite configured in OCI.|
|CKN||32-64 hexadecimal characters||Minimum of 32 hexadecimal characters (0-9, A-F).|
|Confidentiality Offset||0||The OCI side is always set to 0, meaning the whole frame will be encrypted. If required as part of your CPE configuration, configure to match the OCI side.|
Single physical interface
link aggregation group (LAG)
|MACsec for FastConnect supports configuration of MACsec on either a single FastConnect connection or a LAG. Likewise this needs to be configured on your CPE.|
|Key-server||1 or higher||Use any value higher than 0 on your CPE. The OCI FastConnect edge device is configured to always use 0.|
|MKA Include SCI||include SCI||Configure your CPE to include SCI (Secure Channel Identifier) tag. Include SCI is configured on the OCI side.|
|MKA Policy Option||must-secure||This specifies that all traffic sent on the MACsec-enabled network segment must be secured by MACsec prior to being sent. Match this configuration option on your CPE.|
|SAK Rekey time||3600 seconds (1 hour)||CPE configuration must match the OCI SAK rekey time of 1 hour.|
MACsec Hitless Key Rollover
When you're ready to rotate your keys, MACsec for FastConnect supports hitless key rollover. To ensure no loss in communication when rotating keys, always update both the CKN and CAK at the same time. Change the CKN and CAK pair on the OCI side of the FastConnect link first, and then update your CPE.
Perform the following tasks in the order described. Doing these steps out of order might result in a temporary disruption in communication.
- Open the navigation menu, click Identity & Security, and then click Vault.
- Choose a compartment you have permission to work in (on the left side of the page). The page updates to display only the resources in that compartment. If you're not sure which compartment to use, contact an administrator. For more information, see Access Control.
- Click the name of the Vault that includes your CKN and CAK secrets.
- Under Resources, click Secrets.
- Click the name of the secret which represents your CKN.
- Click Create Secret Version.
- Under Secret Contents, enter the new value for your CKN.
- Click Create Secret Version.
Repeat these steps to also change the value of your CAK secret.
When performing hitless key rollover, always update both the CKN and CAK.
- Click the name of the FastConnect which uses the Vault secrets modified in Task 1. You see the cross-connect representing your FastConnect.
- Click Edit.
- Under Connectivity Association Key Name (CKN) click the check box for Use current version in Vault: <number> where <number> matches the latest secret version of your CKN secret in the Vault.
- Under Connectivity Association Key (CAK) click the check box for Use current version in Vault: <number> where <number> matches the latest secret version of your CAK secret in the Vault.
- After both CKN and CAK versions are updated, click Save Changes.
- A new pop-up appears to confirm changes. Click Confirm.
After the cross-connect has been updated to use the new CKN and CAK values, you have a 1-hour rekey period to update the CKN and CAK on your CPE before the session drops.
After the cross-connect has been updated to use the new CKN and CAK values, you have a 1-hour rekey period to update the CKN and CAK on your CPE before the session drops. Refer to the appropriate documentation for your device.
Basic Network Diagrams
The diagrams in this section introduce the basic logical and physical connections involved in FastConnect. Details specific to private versus public peering are called out.
General Concepts of FastConnect
The following diagrams illustrate the two ways to connect to Oracle with FastConnect. In both cases, the connection goes between the edge of your existing network and Oracle.
The next two diagrams give more detail about the physical connections. They also show the metro area that contains the FastConnect location, and a VCN within an Oracle Cloud Infrastructure region.
The first diagram shows the colocation scenario, with your physical connection to Oracle within the FastConnect location (called a cross-connect). The physical device is the Oracle edge device that physically connects to your edge device or to partner/provider networks.
The next diagram shows a scenario with either an Oracle partner or third-party provider. It shows your physical connection to the provider, and the provider's physical connection to Oracle within the FastConnect location. In either case, this physical connection is a cross-connect.
Logical Connection: Private Virtual Circuit
The next two diagrams show a private virtual circuit, which is a single, logical connection between your edge and Oracle Cloud Infrastructure by way of your DRG. Traffic is destined for private IP addresses in your VCN.
Logical Connection: Public Virtual Circuit
A public virtual circuit gives your existing network access to Oracle services in Oracle Cloud Infrastructure. For example, Object Storage, the Oracle Cloud Infrastructure Console and APIs, and public load balancers in your VCN. All communication across a public virtual circuit uses public IP addresses. For a list of services available with FastConnect public peering, see FastConnect Supported Cloud Services. For a list of the public IP address ranges (routes) that Oracle advertises, see FastConnect Public Peering Advertised Routes. You can select the way this access is structured using Route Filtering.
The first diagram shows the colocation scenario with both a private virtual circuit and a public virtual circuit. Notice that the DRG is not involved with the public virtual circuit, only the private virtual circuit.
The next diagram shows the scenario with either an Oracle partner or third-party provider.
Here are a few basics to know about public virtual circuits:
- You choose which of your organization's public IP prefixes you want to use with the virtual circuit. All prefix sizes are allowed. Oracle verifies your organization's ownership of each prefix before sending any traffic for it across the connection. Oracle's verification for a given prefix can take up to three business days. You can get the status of the verification of each prefix in the Oracle Console or API. Oracle begins advertising the Oracle Cloud Infrastructure public IP addresses across the connection only after successfully verifying at least one of your public prefixes.
- Configure your firewall rules to allow traffic coming from the Oracle public IP addresses.
Your existing network can receive advertisements for Oracle's public IP addresses through multiple paths (for example: FastConnect and your internet service provider). Make sure to give FastConnect higher preference than your ISP. You must configure your edge appropriately so that traffic uses your desired path to receive the benefits of FastConnect. This is particularly important if you decide to also set up your existing network with private access to Oracle services. For important information about path preferences, see Routing Details for Connections to Your On-Premises Network.
- You can add or remove public IP prefixes at any time by editing the virtual circuit. If you add a prefix, Oracle first verifies your company's ownership before advertising it across the connection. If you remove a prefix, Oracle stops advertising the prefix within a few minutes of your editing the virtual circuit.
- You should consider FastConnect public peering as an untrusted interface, and put in place firewalls and other access controls just like you would for any network interface connected to the Internet. See Security considerations for FastConnect public peering for more information.
Oracle Partner or third-party provider Scenario: BGP Session to Either Oracle or the Oracle Partner
This section is applicable if you're using FastConnect through an Oracle partner or third party provider. A Border Gateway Protocol (BGP) session is established from your edge, but where it goes depends on which Oracle partner you use.
For simplicity, the following diagrams show only a private virtual circuit. However, the location of the BGP session is the same for a public virtual circuit.
With some Oracle partners, the BGP session goes from your edge to Oracle, as shown in the following diagram. When setting up the virtual circuit with Oracle, you are asked to provide basic BGP peering information (see General Requirements).
With other Oracle partners, your BGP session goes from your edge to the partner's, as shown in the following diagram. When setting up the virtual circuit with Oracle, you are NOT asked for any BGP session information. Instead, you share BGP information with your Oracle partner. Notice that there's a separate BGP session that the partner establishes with Oracle.
To use FastConnect if you do not own a Public ASN or Public IP Address
If you use a Public ASN or Public IP Address loaned or leased from a third-party source, your third-party source must provide a Letter of Authorization (LOA) on your behalf before Oracle can allow the completion of FastConnect configuration.
The following additional steps are required to obtain approval when configuring public peering virtual connections:
Obtain an LOA from the third-party source that authorizes the Customer to use the Public ASN and or Public IP address. The LOA must contain:
- Customer Name approved to the use the Public IP Address and Public ASN
- The range of the Public IP Addresses and or the Public ASN must be explicitly listed
- The third-party source who owns the Public IP Addresses and or the Public ASN
- Third-party source authorization authority signatory
- Contact email, phone number and address of third-party source
- Your enterprise's contact email and phone number
- Date of authorization and validity
- Using the Console, open a service request on the tenancy and region where you wish to use the third-party provided Public ASN and Public IP Address.
- Attach the LOA to the service request.
Once the service request is opened and the LOA is approved, Oracle will authorize the use of the Public ASN and or Public IP Address.
FastConnect with Access to Multiple VCNs
You can use a single FastConnect to access multiple VCNs. Different network scenarios are available depending on your needs and which FastConnect connectivity model you use. For more information, see these topics:
- Transit Routing inside a hub VCN: This scenario can be used with either FastConnect or Site-to-Site VPN. It involves a single DRG, and multiple VCNs in a hub-and-spoke layout.
- FastConnect with Multiple DRGs and VCNs: This scenario can be used only with FastConnect, and only if you're using a third-party provider or colocated with Oracle. It involves multiple DRGs and private virtual circuits.