A Cross Connect is a site type option that can be used for cloud environment integration with Cato among other options such as an IPSec or vSocket site type. 

Cross Connect is a dedicated connection between two peers, such as a cloud provider and a customer's on-premises infrastructure. This private connection type allows for lower latency and higher bandwidth than public internet use.

In cloud computing, a Cross Connect allows a cloud provider to connect directly to another cloud provider's network using a data center cloud exchange via a service provider partner. (Such as Equinix’s Cloud Exchange Fabric)

This can provide customers with more flexibility in how they use and manage their cloud resources in a multi-Cloud environment and improve performance for workloads that need to communicate in between them.

With Cato, Cross Connect data traverses Layer2 virtual circuits, resulting in high performance and low latency due to no encryption overhead. It is cost-efficient for sites with high throughput and relatively easy to operate.

A Cross Connect site allows connecting different cloud providers, such as Azure or AWS, directly to the Cato Cloud environment of your account.

There are several reasons why a Cross Connect site may be the preferred option for your site deployment:

Moreover, a Cross Connect site may vary in global availability, QoS (Quality of Service) management and site analytics. (Each cloud provider provides different monitoring interfaces in their platform)

Cross Connect is a physical layer 2 connection to your cloud environment via one of Cato’s supported partner data center locations, such as Equinix.

The Cross Connect Provider partner data center is the physical location where the Cato PoP is hosted alongside a Cloud Provider connector, such as AWS.

Cross Connect can be deployed as a single link or as High-Availability. (HA mode) In HA mode, Cato provides PoP-level resiliency for the redundant Cross Connect links. The two links work in an Active/Passive manner with the Active link connected to one Cato PoP and the Passive link connected to a different Cato PoP.

Cross Connect relies on BGP to mandate the primary location with preferred metrics and the secondary location with less-preferred metrics by prepending the AS-PATH attribute behind-the-scenes.

BGP MD5 authentication is a mandatory configuration for a Cross Connect site.

BGP is also used to manage connectivity to the Cato PoPs and exchange routing information between the Cato PoPs and the cloud environment to determine the active circuit for the site in case of a failover.

BGP neighbors status is the indicator for site connectivity. As long as at least one BGP peer is reporting connectivity the site is considered connected. 

The following table describes the site connectivity status based on each BGP neighbor scenario:

Note: BFD support with Cato will be implemented in the future.

In high level, connecting two cloud environments looks as follows:

Before you start working on your Cross Connect deployment, it is important to verify which Cato PoP locations support Cross Connect site types. Click here to see the updated list of PoPs available for Cross Connect use.

Make sure to identify the nearest Cross Connect location that can be used to connect to the Cross Connect Provider. For example, to connect AWS VPC resources in US-EAST-1, the closest Cato PoPs are NY and Ashburn.

Each cloud provider has documentation on their available locations with Cross Connect and the Cross Connect Partner Provider:

Once you are ready to get started, reach out to your Cato representative for addition/update of a Cross Connect site with the following criteria for each circuit:

Note: 500 Mbps is the minimal bandwidth for a Cross Connect site. For exceptions, please contact your authorized Cato representative.

See the following articles for information about vendor specific sites:

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:

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 172.29.0.0/24 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.

Events

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.