Cato Networks Knowledge Base

Getting Started with Cato Cross Connect Sites

  • Updated

Overview of Cross Connect with Cato

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.

image1.png

Why Use Cross Connect?

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

  • Security – Cross Connect is considered more secure as it does not transmit data over the public internet.

  • Cost Consideration – Cross Connect may be a less expensive solution for high throughput sites. Many cloud providers provide fixed price options which allow for cost predictability.

  • Simplicity – Setting up Cross Connect involves limited configuration steps and may be set up relatively quickly.

  • Performance & Reliability – Cross Connects benefits better performance due to lack of encryption / decryption overhead, guaranteed bandwidth and close-to-zero latency due to its Layer 2 connectivity in a data center alongside the Cato PoP. (A private connection is more reliable than internet transport)

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 Site Architecture

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:

image2.png

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

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

  1. Identify the closest Cato PoP with Cross Connect service and the Cross Connect Provider Partner location for Cross Connect. (This may vary from customer to customer, more on this in the “Getting started with Cross Connect” section)

  2. Create the Cross Connect circuits on the Cloud Provider and select the relevant Cross Connect Provider partner location. (Such as Equinix)

  3. Configure IP and BGP settings for each Cross Connect circuit in the Cloud Provider platform.

  4. Create a Cross Connect site in the Cato Management Application and configure the IP and BGP settings from the previous step. Cato now provisions the Cross Connect site and will notify you upon completion.

  5. Connect your cloud environment VPC via a linked Gateway to the Cross Connect circuits in the cloud environment.

  6. Verify connectivity.

image3.png

Identifying PoP Locations for a Cross Connect Site

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.

PoP Locations

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:

  • Cloud Provider Environment (Azure, AWS, GCP or OCI)

  • Cloud Provider region (i.e., US-EAST-1)

  • Required Bandwidth

  • Cato PoP location

  • Circuit ID and Account ID

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

See the following articles for information about vendor specific sites:

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.

image16.png

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

image.png

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. 

image14.png

Sample of BGP status output:

image15.png

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:

BGPemail.png

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.

 

image18.png

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.

image.png

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.

BGPevent.png

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...

    AppAnalytics.png
  • 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.

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

    RealTime.png

Was this article helpful?

4 out of 4 found this helpful

Comments

0 comments

Please sign in to leave a comment.