Cross Connect for Oracle Public Cloud

This guide explains how to connect Oracle Cloud Infrastructure (OCI) to the Cato Cloud via Cross Connect.

For more information about Cross Connect sites, see Getting Started with Cato Cross Connect Sites.


Note: This is an Early Availability (EA) feature that is only available for limited release. For more information, contact your Cato Networks representative or send an email to

Overview of Cross Connect for OCI

Cato supports Active-Passive model only for Cross Connect site with 2 circuits. BGP is used to exchange the routing information between Cato PoPs and OCI edge routers and also to determine the active acting circuit for the site.

Best Practice: Cato recommends connecting two circuits in OCI for resiliency and redundancy scenarios. Single circuit configurations are also supported.

Preparing to Create a Cross Connect Site

When you create an OCI Cross Connect site it's necessary to configure settings for your OCI tenant and the Cato Management Application.

This article assumes that you are creating an HA Active-Passive Cross Connect site. If you are creating a single circuit Cross Connect site, please create only one primary Direct Connect Circuit. (Only recommended for testing purposes)

High Level Overview or Configuring a Cross Connect Site


This is a high-level overview of the process to configure Cross Connect for a OCI Cato site:

  1. Create two Virtual Circuits in OCI.

  2. Send the OCID Unique Keys for the created circuits to Cato for provisioning. 

  3. In the Cato Management Application create a new site and choose site type as Cross Connect.

    1. Configure /30 IP subnets for the primary and secondary circuits for the site.

    2. Configure the Bandwidth per circuit.

  4. Configure BGP between Cato and OCI:

    1. In Oracle - Once provisioned, configure the Virtual Circuits peering using the same IP subnets that you added to the Cato Management Application.

    2. In the Cato Management Application - Configure BGP peer settings for the primary and secondary circuits. (Cato automatically prefers the primary peer’s metrics)

  5. Connect your Oracle Dynamic Routing Gateway (DRG) to the primary and secondary circuits.

  6. Test connectivity with your new site.

Below is a low-level example topology of a Google cloud environment connected to Cato via Cross Connect.


Configuring the Settings in the OCI Account

This section describes how to configure the settings for an OCI data center so it can connect to the Cross Connect site in your Cato account.

To configure the OCI tenant settings for the Cross Connect site:

  1. In OCI, create a new Virtual Circuit under Networking > Customer Connectivity > FastConnect > Create FastConnect.

  2. In Connection Type, select FastConnect Partner and click Next

    Cato uses OCI’s supported providers for connectivity. (ie. Equinix)

  3. Define the Virtual Circuit settings:

    1. Select the relevant Compartment for this tenant.

    2. Select Virtual Circuit Type as the Private Virtual Circuit.

    3. Each Virtual Circuit requires a Dynamic Routing Gateway to connect to.

      The Dynamic Routing Gateway (DRG) is responsible for connecting your OCI VCN to the Cross Connect site. In a redundant pair environment, both Virtual Circuits use the same DRG.

      If you do not already have a here pre-existing DRG for your connection, please read more here in Oracle’s official documentation.

    4. In Provisioned Bandwidth select the bandwidth for this connection.

    5. Customer BGP IPV4 Address – Configure a /30 IP address that will be used as the peering IP for Cato.

    6. Oracle BGP IPV4 Address – Configure an IP address in the same /30 block as above to be used as Oracle’s peering IP.

    7. Customer BGP ASN - This is the ASN which will be used to represent the Cato side in the OCI configuration. You can use any private ASN for the Cato side (the peer ASN).

    8. MD5 – Required authentication value for an additional layer of security.

    9. MTU – Select 1500. Cato does not support jumbo frames

    10. Click Create.

  4. Once the Virtual Circuits are deployed successfully, a OCID Key for each circuit is automatically generated. Send the the Service Key to your Cato representative.

    Currently, it is not possible to configure the circuits peering until they are completely provisioned by the Service Provider. (I.e. Equinix).

    To complete the provisioning process the Cross Connect datacenter provider requires the unique OCID Key generated by OCI for each circuit.


    Note: The provisioning process with service provider may take up to 24 hours to be reflected in the OCI portal

  5. Once provisioned, the circuits will appear as Provisioned in the Lifecycle State column.


Creating the Cross Connect Site

In the Cato Management Application, create a new site for the Cross Connect provider.

This article assumes that you are creating an HA Active-Passive Cross Connect site. If you are creating a single circuit Cross Connect site, please create only one primary Direct Connect Circuit. (Only recommended for testing purposes)

For the Cross Connect site, we recommend that you create the site at the same time that you send the initial request for provisioning. This lets you set up the Cato configuration for this site more quickly.

To create the Cross Connect site:

  1. In the Cato Management Application, under Network > Sites, click New to create a new site.

  2. Select the Connection Type as Cross Connect and define the settings for the site.

  3. Click Apply, and then click Save.

  4. Select the new site and go to Site Configuration > Cross Connect and configure the Subnet and peering private IPs similarly to the previous steps in OCI for each Cross Connectcircuit.

    The Cato IP is the Customer BGP IPv4 IP Address which was automatically generated in OCI and Site IP is the Oracle BGP IPv4 IP Address.


Defining the BGP Settings for the Site

This section explains how to define the BGP session on top of the existing private peering connection.

The cross-connect site is shown in the Connected state when at least one BGP peer is reachable, regardless of the provisioning status with your cloud provider.

BGP establishment is the sole indicator of site connectivity. BGP also allows for determining routing exchange and tunnel failover.

To configure the BGP settings for the Cross Connect site:

  1. Configure the same settings in the BGP tab as in the Cross Connect site configuration. For each circuit, go to Site Configuration > BGP and click New.

  2. Under ASN Settings configure the Cato ASN as the value of your choice (make sure it matches the Peer ASN previously configured on the OCI Virtual Circuit configuration page)

  3. Configure the Peer ASN as 31898. This is a reserved ASN notation used by OCI for Virtual Circuits.

  4. Under IP settings configure the Peer IP. This is the same IP as configured in the Cross Connect settings as Site. (This IP represents the cloud provider peer IP.)

    The Cato IP is automatically selected based on the Cross Connect settings.

  5. Define the BGP routing policy - It is possible to manipulate the routes advertisement policy for each peer.

    We recommend that there are equal policies on both peers in a Cross Connectsite to avoid routing discrepancies.

  6. Define if BGP should advertise Cato as a Default Route, advertise All routes from the Cato Cloud to your cloud provider and if BGP should accept Dynamic routes received from the peer.

  7. Configure the Additional Settings for the BGP routes:

    1. MD5 – An additional layer of security. This field is mandatory for Cross Connect.

    2. Metric – Peer priority may be changed.

      The expected configuration profile is to set a better metric for the primary peer than the secondary peer.

    3. Hold time and Keepalive interval values.

    4. Track > Email Notification – Optional alerts for BGP connectivity changes.

  8. Click Apply, and then click Save.

    The Cross Connect site is configured. Verify that the site is working correctly, see below Monitoring and Testing Connectivity for the Cross Connect Site.

Sample BGP Policy for Cross Connect Site

See the following example of two peers in the supported Active-Passive configuration with Cato. (Primary peer metric is 90, secondary peer metric is 100)


Monitoring and Testing Connectivity for the Cross Connect Site

Now that the site setup is complete, let's review how the connection can be tested and monitored.

Cato provides multiple tools to help you monitor your Cross Connect site and troubleshoot any potential issues, including:

Test Connectivity Tool

You can test the point-to-point Cross Connect IP reachability of each circuit by using the Test Connectivity tool.

The Test Connectivity tool in Site Configuration > Cross Connect sends ICMP probes from the Cato PoP IP to the site remote IP of either the primary or secondary connection.

These are the results of the ICMP probes:

  • Success - Test executed successfully

  • Error - Test was not executed. (Test timed out by the Cato PoP or unable to be executed)

  • Failed - Test performed successfully with no response from the remote peer IP.

LAN Monitoring

You can use the LAN Monitoring feature to:

  • Perform continuous ICMP probing from the Cato PoP to the primary circuit remote IP.

    Note: LAN Monitoring only monitors the primary circuit for the Cross Connect site.

  • Hosts liveliness state changes for instances within the Cloud Provider network.

It is possible to set custom thresholds and ICMP Intervals and define email notifications to a mailing list upon meeting these thresholds.


This is an example of an email notification for LAN Monitoring:


BGP Status

In Site Configuration > BGP, the Show BGP Status confirms connectivity of each circuit.

The status outputs granular information on the subnets learned, advertised and additional data on the BGP peers.


Sample of BGP status output:


BGP Email Notifications

For each peer, we recommend configuring BGP neighbor status change notifications. Email Notifications are sent directly to an admin mailing list upon a BGP peer connection state change.

Configure email notifications in Site Configuration > BGP > BGP Neighbor > Additional Settings > Track.

Select the Frequency of alerting and Mailing List.

Cato allows for the following Frequency configuration:

  • Immediate - an email is sent to the recipients for every occurrence.

  • Hourly - an email is sent to the recipients with the first occurrence, and the next email follows after 1 hour (including all additional occurrences).

  • Daily - an email is sent to the recipients with the first occurrence, and the next email follows after 24 hours (including all additional occurrences).

  • Weekly - an email is sent to the recipients with the first occurrence, and the next email follows after 1 week (including all additional occurrences).

Sample BGP email notification:


Routing Table

The Monitoring > Routing Table screen shows all routes of your account including dynamic routes.

The routing table can be used to determine which tunnel, primary or secondary, is responsible for adverting these routes based on the Next Hop, PoP and Tunnel Metric.

Routes originating from BGP appear as a Dynamic routing type. Routes from the Passive circuit’s peer appear as greyed out. The point-to-point subnets of both circuits appear as a Static routing type on the routing table.

For example, the following dynamic route is advertised from the New York PoP and has a metric of 5 (highest) which is the primary and currently active tunnel.

The same route is advertised by the secondary tunnel on Ashburn PoP as well with a lower metric of 10.

In case the secondary tunnel on Ashburn PoP would become the active tunnel, the routing table would adjust accordingly for this route.



The BGP peers are Static and have their own routing table entry. This peers server as the Next Hop for the Dynamic BGP routes advertised behind them. Similarly as other routes, Metric information can be discerned to understand which peer is currently active with a higher metric and through which Cato PoP location.



In the Site Monitoring > Events screen, Cato aggregates all logged events related to the site.

Key events can be used to analyze a timeline of events such as. You can filter the relevant Events using the following event sub-types:

  • BGP Session – Notify of BGP session establishment or disconnection. An identified reason for disconnection can be inspected in the expanded event log. (Under the ‘+’ icon)

  • BGP Routing – BGP route changes such as addition or removal of new routes from the BGP peer.

  • LAN Monitoring – These events are logged as part of the LAN Monitoring setup you configured. If LAN Monitoring is not set these events would not be logged.


Site Network Analytics

Site analytics lets you monitor the site’s traffic and throughput and includes these dashboards:

  • Network Analytics – Analyze connectivity state changes, number of Flows, Hosts and Throughput.

    It is important to remember the Cross Connect site connectivity is based on the BGP peers. If both BGP peers are unreachable, the site is considered Disconnected.

  • Events - Site events feed.

  • Application Analytics - This dashboard dissects hosts throughput and application usage. It is possible to add filters such as IP/host, Application, Category, etc...

  • Priority Analyzer - This dashboard allows analyzing QoS distribution over time. (Read more on Priority Analyzer)

  • Known Hosts – A real-time dashboard for hosts behind the site. IP, OS type and Host Activity are among the data points available per host.

  • Real Time - This dashboard allows for real-time monitoring of active hosts, throughput, top applications, active QoS and more.


Cross Connect Limitations with OCI

The following is a highlight list of limitations to consider before setting up an OCI Cross Connect site:

  • When advertising routes, OCI does not have an option to exclude/include routes from the VCN. The whole VCN is advertised.

  • OCI allows advertising up to 2,000 prefixes.

  • OCI does not offer a way to validate propagated routes from Cato on the Oracle portal. For this, the Cato Management Application’s BGP status feature may be used.

  • A virtual circuit can be assigned only 1 Dynamic Routing gateway.

  • OCI billing model is based on fixed BW port hours and not data transfer consumption. (Billing begins once a virtual circuit is either provisioned or after 30 days, the earlier of which to be applied.

  • If the prefix limit is met, OCI tears down the BGP connection for 60 minutes and re-attempts to establish connection until limit capacity is restored.

You may read more on OCI’s official FastConnect documentation.

Was this article helpful?


Add your comment