FastConnect is a network connectivity alternative to using the public internet for connecting your on-premise data center or network to Oracle Cloud Infrastructure.
You should use FastConnect if you require higher bandwidth options that:
You can create a FastConnect connection in the Networking section of the Oracle Cloud Infrastructure management console. Click “FastConnect,” and then “Create FastConnect Connection”. For more information, see FastConnect Overview in the documentation.
Yes. You can access Oracle Cloud Infrastructure public service endpoints such as Object Storage through FastConnect.
You can connect at your closest FastConnect locations at port speeds in 1-Gbps and 10-Gbps increments via a provider and 10-Gbps when colocating with Oracle.
Please see our Connectivity Models page.
For the direct connectivity models, both public and private peering are supported. For connection through a FastConnect partner: see FastConnect Private and Public Peering for details about peering types and support by each partner.
See our Network Provider and Exchange Partners page for the most up-to-date list.
Yes. If your existing network or data center is not colocated within a FastConnect location, you can connect to a FastConnect location through a connectivity provider (network service provider (NSP) or cloud exchange). For a list of FastConnect connectivity providers by location, see our Network Provider and Exchange Partners page.
No, there are no limits on data transfer in or out of Oracle Cloud when using FastConnect.
We have FastConnect service available in all Oracle Cloud Infrastructure regions. For up-to-date information on regional availability, see our Network Provider and Exchange Partners page.
For the list of supported cloud services over FastConnect, see FastConnect Supported Cloud Services.
An IPSec VPN establishes an encrypted network connection over the internet between your network or data center and your Oracle Cloud Infrastructure virtual cloud network (VCN). It's a suitable solution if you have low or modest bandwidth requirements and can tolerate the inherent variability in internet-based connections. FastConnect bypasses the internet. Instead, it uses dedicated, private network connections between your network or data center and your VCN.
Yes. You can provision FastConnect and an IPSec VPN simultaneously. Typically, you would set up FastConnect as the primary path and the IPSec VPN as a backup path via the internet. The FastConnect path will always be preferred when available, unless you add more specific static routes to the IPSec VPN connection.
No. You shouldn’t see any additional routes from the FastConnect partner.
Yes. You can advertise both private and public IPv4 prefixes over a FastConnect private virtual circuit. You can advertise only public IPv4 prefixes over a public virtual circuit. Oracle validates the public prefixes that you want to advertise before accepting them.
No. Oracle does not advertise your routes or prefixes outside of your tenancy.
No, only one DRG can be attached to a VCN. And only one VCN can be attached to a DRG. For more information about using DRGs, see Dynamic Routing Gateways (DRGs).
Yes. This is possible with local VCN peering.
Yes. This is possible with remote VCN peering.
Yes. This is possible with transit routing.
Yes. With FastConnect, you can connect to resources in all compartments in your tenancy.
No. FastConnect does not currently span tenancies. Your FastConnect virtual circuit can enable access only to resources in the tenancy where the virtual circuit was established.
No.
You can request a service limit increase. See Service Limits.
Oracle charges only for port hours consumed and not data transfer. If you connect to an FastConnect location through a connectivity provider, the provider bills you separately for the bandwidth you provision with them and any additional fees they have. For the billing model and pricing for FastConnect, see our FastConnect Pricing page. The charges you incur do not include any fees that the network provider or data center provider may charge you separately for connectivity.
There are no setup charges and you may cancel the service at any time. Services provided by our connectivity providers may have other terms and restrictions.
Port hours are billed after the connection between the FastConnect router and your router is established, or 30 days after you ordered the port, whichever comes first. Port charges will continue to be billed as long as the FastConnect port is provisioned for your use. If you no longer want to be charged for your port, delete your port from the Oracle Cloud Infrastructure console. What defines a "port"? That depends on your connectivity model:
No. There is no charge for data transfer between availability domains within a region.
There are no data transfer limits up to the amount of your provisioned port.
Oracle does not charge for inbound and outbound data transfer. In the colocation or direct cross-connect model, your metering starts when the cross-connect moves to the "Provisioned" state, or after 30 days (whichever is earlier). Metering stops when the cross-connect moves to the "Terminated" state. In the FastConnect provider model, metering starts when the virtual circuit moves to the "Provisioned" state.
You can connect to all availability domains in the region through a single FastConnect virtual circuit. You don't need any other medium of connectivity between the availability domains.
No. You must provision two FastConnect virtual circuits if you want to connect to two different regions.
We recommend having a minimum of two connections for redundancy. You can land the connections on different FastConnect edge devices.
If you have a single FastConnect connection (physical port or virtual circuit) to Oracle Cloud Infrastructure, you might experience a loss in connectivity when that path goes down. Therefore redundant physical and logical (virtual circuits) connections are recommended. If you like, you can use an IPSec VPN as a redundant connection.
If you are redundantly connected, a 99.9 percent SLA is guaranteed for the FastConnect service.
Oracle overrides the default route selection behavior to prefer FastConnect BGP routes over the IPSec VPN static routes if a static route overlaps with a route advertised by your on-premise network. If the static route is more specific than the BGP route, the static route over the IPSec VPN takes precedence for outbound traffic from Oracle.
If an IPSec VPN and a FastConnect virtual circuit terminate on the same DRG, Oracle always prefers FastConnect for egress (outbound) traffic, assuming that the IPSec VPN static route is not more specific than the FastConnect BGP route. If the FastConnect virtual circuit goes down, the DRG detects this failure and starts sending traffic over the IPSec VPN tunnel, provided a static route exists. If the FastConnect virtual circuit recovers, traffic switches back over to the FastConnect path.
The DRG detects the availability of the FastConnect virtual circuit and starts forwarding egress (outbound) traffic through the IPSec VPN accordingly. If the FastConnect virtual circuit and the IPSec VPN connection terminate on the same CPE device on your end (not recommended), then the CPE must support asymmetric routing.
One of the technical requirements for FastConnect is having an LACP timer. Oracle supports aggressive LACP timers. You can enable LACP timers by using link aggregation. LACP timers detect the physical failures faster than standard BGP timers. If LACP timers are not set up, the DRG relies on BGP timers to detect FastConnect virtual circuit availability.
Oracle provides three components to help you implement highly available connections:
For more information, please see FastConnect Redundancy Best Practices
There is no manual intervention needed to share FastConnect across compartments. The DRG is attached to the VCN, and all instances inside the VCN (whether they're in the same compartment or spread across different ones) can have their traffic routed through that DRG, over the FastConnect, and on to your network or data center.
You can establish connectivity using a software VPN, or through a FastConnect provider that has connectivity to the other CSP.
Yes. Oracle supports link aggregation (LAG), where you aggregate one or more Ethernet interfaces to form a logical point-to-point link. Specifically, Oracle supports the Link Aggregation Control Protocol (LACP).
Eight.
LAG is available for 10-Gbps ports.
This is between you and the provider. You can work with provider to have LAG configured for their connection.
No. LAG includes only ports on the same Oracle router.
You can request another port for your LAG, but if one is not available on the same chassis, you must order a new LAG and migrate your connections. For example, if you have 3x 10G links and would like to add a fourth, but no port is available on that chassis, you must order a new LAG of 4x 10G ports.
You can have multiple virtual circuits attached to your DRG at the same time. Create the new virtual circuits on your new bundle, and then move traffic from your on-premise network over. Remember to delete the old virtual circuits so Oracle stops billing you for them.
Yes, but just like a regular connection you won’t be able to delete it if you have virtual circuits using it. First you must delete the virtual circuits, and then you can delete the LAG.
Yes. You can have a single port in a LAG.
Yes. However, Oracle recommends that you set up two ports to different devices for redundancy.
When a FastConnect connection with existing virtual circuits is associated with a LAG, virtual circuits are migrated to the LAG. Please note that certain parameters associated with virtual circuits need to be unique like VLAN and BGP peer info, etc., and need to be moved to LAG.
LACP provides automatic determination, configuration, and monitoring of member links. If one of the physical links in the LAG goes down, traffic is dynamically and transparently reassigned to one of the other physical links. LACP lets devices send Link Aggregation Control Protocol Data Units (LACPDUs) to each other to establish a link aggregation connection.
LAG lets you protect against single-path failures between your data center and Oracle. It doesn't protect against device failure.
Yes. It's similar to having a virtual circuit on two different physical ports. This provides physical redundancy for FastConnect virtual circuits or BGP.
No. A virtual circuit can be attached only to a single DRG.
There's no limit, but you must use a unique VLAN and BGP information for each virtual circuit. You're not charged per virtual circuit.
For a private virtual circuit, you can specify a /30 or /31 network of your choice, and those IP addresses are assigned to the virtual circuit during the provisioning process. The IP addresses are used for BGP peer establishment. For a public virtual circuit, Oracle Cloud Infrastructure chooses the BGP IP addresses.
For a private virtual circuit, Oracle advertises the subnets in your VCN.
No.
Yes. You can use either a private ASN in the 64512-65535 range, or a public ASN that you own.
No it doesn't need to be reprovisioned. If you're connected through an Oracle partner, make sure to change the bandwidth setting on both the partner side and Oracle side. Depending on the partner, you can change it on the partner side and the change is automatically propagated to the Oracle side.
No. They are separate virtual circuits.
You can advertise public routes that are /31 and less specific. The prefixes must be registered to your organization. Oracle verifies your organization's ownership of each prefix before sending any traffic for it across the connection.
Oracle advertises the local, regional, public aggregate routes that are /24 and less specific, except the default route.
No.
No, not currently.
For a public virtual circuit, Oracle provides the public IP addresses. They're from the range 169.254.0.0/16.
Oracle's verification for a given public prefix that you submit can take up to three business days. Oracle begins advertising the Oracle Cloud Infrastructure public IP addresses across the connection only after successfully verifying at least one of your public prefixes.
FastConnect provides dedicated, private connectivity. Traffic flowing over the connection is not encrypted.
The BGP ASN is used to define networks that are under a single administrative domain. For a FastConnect private virtual circuit, you can use a public ASN that you own, or you can pick any private ASN number between 64512 and 65535. For a FastConnect public virtual circuit, you must use a public ASN that you own.
We honor AS_Path as a BGP attribute.
The interfaces on the FastConnect devices support a maximum Media MTU of 9000 (this includes the 4-byte FCS/CRC Ethernet trailer). It's imperative that the Media MTU between Oracle's devices and yours are identical to avoid the potential of jumbo frames being silently discarded at the MAC-layer without an ICMP Type 3 Code 4 (Fragmentation Needed and DF bit set) message being sent to the sender. For more information, see Hanging Connection.
No. The MTU does not change.
No, not currently.
Yes.
DRGs support dynamic routing over FastConnect and IPSec VPN.
Yes. IPv6 is supported.
No, not currently.
It depends on the way services are set up. For example, if you plan to provision one service on public peering and the other on private peering, you must have two FastConnect Classic circuits. If you instead plan to provision both services on public peering, one FastConnect Classic circuit is enough. However, if you plan to provision both services over private peering, whether you must have one or two FastConnect Classic circuits depends on the private gateway and IP Networks setup.
No. FastConnect provides connectivity from your on-premise or colocated data center to an Oracle data center, and not connectivity between two Oracle data centers. However, some services can communicate over the Oracle backbone network. Check with the ECA or Cloud Pursuit specialist to review your design further.
No. Your Private Gateway is attached to a single Compute Identity Domain and cannot span across two. You must provision two FastConnect Classic circuits.
Public peering has a limit of 200 public IP prefixes. Private peering has a limit of 2000 IP prefixes.
When you exceed the number of prefix advertisements, the BGP session for the connection is brought down for 60 minutes. After that, Oracle checks the prefix advertisements being received. If the limit is no longer being exceeded, the BGP session is re-established. If the limit is still being exceeded, the session is kept down for another 60 minutes. This process repeats until the prefix advertisements are back to within allowed limits.
Over public peering, all default routes and private IP advertisements are dropped. Over private peering, because of an Oracle internal limitation, you cannot advertise a default route yet. As a workaround until a fix is in place,, you can advertise a 0.0.0.0/2 route.
If the cloud services you plan to access are supported only over public peering, and if you do not own public IP prefixes, you can lease public IP space from your provider or a reseller and provide a letter of authorization.
No. Currently, Oracle Cloud Infrastructure and Oracle Cloud Infrastructure Classic FastConnect services are offered as two different independent services.
Please open a My Oracle Support service request and specify your new public IP prefixes along with your FastConnect Classic ID (which you can obtain from the Compute Classic UI).
There is no limit.
There is no limit. Your primary and secondary cross-connects must be UP before you can create any additional ones.
Only one. You can have multiple IP Networks attached to a single private gateway and communicate with them over your FastConnect Classic connection.
Plan to set up multiple nonoverlapping IP networks and a single private gateway. When you attach the IP networks to the private Gateway, FastConnect Classic will advertise the IP networks to your on-premise edge device.
You can set up a private connection if your VCN and IP networks meet the basic requirements. For more information, see Access to Oracle Cloud Infrastructure Classic. As an alternative, you can use an IPSec VPN.
Public peering between Oracle Cloud Infrastructure Classic and Oracle Cloud Infrastructure is now enabled in Oracle Cloud Infrastructure’s London and Ashburn regions.
Customers who have public peering virtual circuits to Oracle Cloud Infrastructure Classic may now access public services in Oracle Cloud Infrastructure and migrate their data to Oracle’s next-generation cloud platform. Traffic moving from Oracle Cloud Infrastructure Classic to Oracle Cloud Infrastructure will not traverse the public Internet and will remain on private, dedicated links between FastConnect routers.
Public resources in Oracle Cloud Infrastructure include object storage, public load balancers in customer VCNs, public IPS on Compute, or supported SaaS services.
There are standard costs for provisioning a public peering virtual circuit to Oracle Cloud Infrastructure Classic, but once that is in place, there are no additional costs for Public Peering with Oracle Cloud Infrastructure.
You file a ticket with My Oracle Support and Oracle provisions a connection between the IP network's private gateway and the VCN's attached dynamic routing gateway (DRG). The connection runs over Oracle's network and not the internet.