Oracle Cloud Infrastructure Documentation

FastConnect Resiliency Best Practices

This topic covers best practices for resiliency when implementing FastConnect.

For general information about FastConnect, see FastConnect.

Overview

In general, you should design your network to achieve high availability (HA). In addition, you should be prepared for these types of disruptions:

  • Regularly scheduled maintenance by your organization, your provider (if you're using one), or Oracle.
  • Unexpected failures on the part of your networking components, your provider, or Oracle. Failures are rare, but you should plan for them.

For resiliency, Oracle provides:

  • Multiple providers for each region
  • Two A specific data center where you can connect to Oracle Cloud Infrastructure by using FastConnect. for each of the following regions (all other regions have a single FastConnect location)

    • Germany Central (Frankfurt)
    • UK South (London)
    • US East (Ashburn)
    • US West (Phoenix)
  • Two routers in each FastConnect location
  • Multiple physical connections between each Oracle provider and Oracle (for a given region)

The resiliency best practices depend on which connectivity model you use. Also see How and Where to Connect.

If You Use an Oracle Provider

Connectivity model:

Oracle handles redundancy of the physical connections between the provider and Oracle, and the redundancy of routers in the FastConnect locations. You should then handle redundancy of the physical connection between your existing network and the Oracle provider.

The remaining best practices depend on the provider you're using, and details of the BGP session from your edge:

For information about the two scenarios, see Oracle Provider Scenario: BGP Session to Either Oracle or the Oracle Provider.

Oracle Provider Scenario: Your BGP Session Is to Oracle

At a minimum, each Oracle provider has two separate physical connections to Oracle. Set up one virtual circuit on one physical connection (as primary), and the other virtual circuit on another physical connection (as secondary). The following diagram illustrates two virtual circuits, each going to a different router in a single FastConnect location. If the region has a second location, your provider's second physical connection might instead go to that location.

This image shows a setup with an Oracle provider and multiple virtual circuits to different routers in a single FastConnect location.

If you're working in a region that has only a single FastConnect location, you might also want location diversity. To achieve that, repeat the preceding setup of two virtual circuits with the same Oracle provider, but in a second FastConnect location in a nearby region. Notice that you must have a duplicate setup of your Oracle cloud resources in that second region, as shown in the following diagram.

This image shows a setup with an Oracle provider and connections to two different Oracle regions.

If you also want provider diversity, repeat your entire setup with another provider in each region that you're using.

Oracle Provider Scenario: Your BGP Session Is to the Oracle Provider

In this scenario, the BGP session from your edge goes to the Oracle provider (as shown in the following diagram). Separate from your BGP session, the Oracle provider has its own BGP sessions with Oracle (between the provider's edge and Oracle's edge). The virtual circuit is a logical connection that goes from your edge to the Oracle edge.

The provider has two separate physical connections to Oracle. You create one virtual circuit with the provider. In this scenario, the virtual circuit is automatically designed to be redundant and diverse. The virtual circuit has two separate BGP sessions between the provider and Oracle, each on a different physical connection. The following diagram shows the two separate BGP sessions for the single virtual circuit as dotted lines.

This image shows a setup with an Oracle provider and multiple BGP sessions between the provider and Oracle for the single virtual circuit.

Separately, you must ensure that the connection between your edge and the provider is redundant and diverse.

If you're working in a region that has only a single FastConnect location, you might also want location diversity. To achieve that, repeat the preceding setup of a virtual circuit with the same Oracle provider, but in a second FastConnect location in a nearby region. Notice that you must also have a duplicate setup of your Oracle cloud resources in that second region, as shown in the following diagram.

This image shows a setup with an Oracle provider and connections to two different Oracle regions.

If You Use a Third-Party Provider or Colocate with Oracle

Connectivity models:

Oracle handles redundancy of the Oracle routers in the FastConnect locations. You should then handle redundancy of the physical connection between your existing network and Oracle.

To do this, create two physical connections to Oracle, one for each FastConnect location that serves the region. This means that in the Oracle Console, you set up two separate FastConnect connections. You then create two virtual circuits. Set up the first one on the first physical connection (the first FastConnect connection), and the second one on the second physical connection. The following diagram shows the general setup.

This image shows a colocation setup where you have two physical connections and virtual circuits to the FastConnect location.

You might prefer to connect to only a single FastConnect location because of cost concerns, or if the region has only a single FastConnect location. In that case, create two physical connections and ensure each goes to a different Oracle router in that FastConnect location. You can do this in the Oracle Console when you set up the second physical connection. You can specify the proximity of that connection to other FastConnect connections in that location. For example, the following image shows how to request that your second physical connection (which is a Used with Oracle Cloud Infrastructure FastConnect, specifically if you're using a third-party provider or colocated with Oracle in a FastConnect location. A cross-connect group is a link aggregation group (LAG) that contains at least one cross-connect.) is created on a different router than your first connection in that FastConnect location (called MyConnection-1).

This image shows the router proximity information in the Console.

You must scale the bandwidth of both physical connections evenly, and by using a cross-connect group (LAG) for each connection. Imagine that you have two individual 10-Gbps cross-connects in a single FastConnect location (each to a different Oracle router for redundancy and diversity). If you need to have 20-Gpbs bandwidth at a given time, you must ensure that each of your physical connections consists of a cross-connect group (LAG) to contain the cross-connect. Then you need to add another 10-Gbps cross-connect to each LAG, so that each redundant physical connection has two 10-Gbps cross-connects. FastConnect currently does not support equal-cost multi-path routing (ECMP).

If you're working in a region that has only a single FastConnect location, you might also want location diversity. To achieve that, repeat your setup in a second FastConnect location in a nearby region. Notice that you must also have a duplicate setup of your Oracle cloud resources in that second region, as shown in the following diagram.

This image shows a colocation setup to two different regions.

VPN Connect as Backup for FastConnect

Oracle recommends using VPN Connect as a backup for your FastConnect connection. If you do, ensure that the VPN Connect tunnels are configured to use BGP routing. Within your existing network, manipulate the routing to prefer routes learned through FastConnect over routes learned through VPN Connect. For example, use AS_Path Prepend to influence egress traffic from Oracle, and use local preference to influence egress traffic from your network.

The following diagram shows a setup with redundant FastConnect virtual circuits and redundant VPN Connect tunnels.

This image shows FastConnect with VPN Connect as backup.

What's Next?

Choose the topic that suits your situation: