FastConnect Redundancy Best Practices
This topic covers best practices for redundancy 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 redundancy, Oracle provides:
- Multiple providers for each region
-
Two FastConnect locations 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 partner and Oracle (for a given region)
The redundancy best practices depend on which connectivity model you use. Also see How and Where to Connect.
If You Use an Oracle Partner
Connectivity model:
Oracle handles redundancy of the physical connections between the partner and Oracle, and the redundancy of routers in the FastConnect locations. You should handle redundancy of the physical connection between your existing network and the Oracle partner.
The remaining best practices depend on the partner you're using, and details of the BGP session from your edge:
- For some partners, the BGP session from your edge goes to Oracle. For redundancy best practices, see the next section.
- For other partners, the BGP session from your edge goes to the Oracle partner. For redundancy best practices, see Oracle Partner Scenario: Your BGP Session Is to the Oracle Partner.
For information about the two scenarios, see Basic Network Diagrams.
Oracle Partner Scenario: Your BGP Session Is to Oracle
At a minimum, each Oracle partner 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 partner's second physical connection might instead go to that 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 partner, 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.
If you also want provider diversity, repeat your entire setup with another provider in each region that you're using.
Oracle Partner Scenario: Your BGP Session Is to the Oracle Partner
In this scenario, the BGP session from your edge goes to the Oracle partner (as shown in the following diagram). Separate from your BGP session, the Oracle partner has its own BGP sessions with Oracle (between the partner's edge and Oracle's edge). The virtual circuit is a logical connection that goes from your edge to the Oracle edge.
The partner has two separate physical connections to Oracle. You create one virtual circuit with the partner. In this scenario, the virtual circuit is automatically designed to be redundant and diverse. The virtual circuit has two separate BGP sessions between the partner 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.
Separately, you must ensure that the connection between your edge and the partner 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 partner, 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.
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 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.
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 cross-connect group ) is created on a different router than your first connection in that FastConnect location (called MyConnection-1).
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.
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.
Site-to-Site VPN as Backup for FastConnect
Oracle recommends using Site-to-Site VPN as a backup for your FastConnect connection. If you do, ensure that the Site-to-Site VPN IPSec tunnels are configured to use BGP routing with a route-based VPN. Within your existing on-premises network, manipulate the routing to prefer routes learned through FastConnect over routes learned through Site-to-Site VPN. For example, use AS_Path Prepend to influence egress traffic from Oracle, and use local preference to influence egress traffic from your network.
If you are using VPN backup, review Oracle's BGP routing behavior in the table shown in Using AS_PATH to prefer routes from Oracle to your on-premises network.
The following diagram shows a setup with redundant FastConnect virtual circuits and redundant Site-to-Site VPN tunnels.
Related Resources
What's Next?
Choose the topic that suits your situation: