Cato Networks Knowledge Base

Using BGP in the Cato Cloud

Introduction to BGP

Border Gateway Protocol (BGP) is a standardized exterior gateway protocol designed to exchange routing and reachability information among autonomous systems (AS) on the Internet.

Based on your configurations and by leveraging BGP routing information, Cato Cloud can make informed real-time routing decisions without you being required to manually configured multiple static paths and/or take any actions. This enables enhanced support for scenarios such as direct connect and/or active-active configuration in AWS, disaster recovery (DR) with virtual IPs, integration with autonomous systems (AS) within sites, and greater flexibility in gradual deployments.

How Does Cato Cloud Support BGP?

This section describes Cato Cloud’s BGP components (including global objects), and how Cato Cloud support of BGP is designed and performs.

Cato Cloud’s BGP Components

Cato Cloud BGP support is comprised of three main components: BGP neighbors, dynamic ranges and floating ranges.

Note

Note: All ranges defined in a site's Native Range are referred to as “static ranges” throughout this section.

BGP Neighbors

To establish BGP sessions with neighbors, connectivity is required. These are the options for where a BGP neighbor can reside, and their resulting interaction with your account in the Cato Cloud.

  • BGP between Cato Networks PoP and a BGP router within a tunnel - Cato Cloud advertises account ranges, including the default route (0/0), and receives static, Dynamic Ranges and Floating Ranges for a site. For example, BGP is the preferred mode for exchanging routes in an Amazon AWS IPSec connection.

  • BGP between the Cato Cloud and a BGP router residing on the LAN / Alt. WAN link - Cato Cloud can communicate with a BGP neighbor over established ranges in the socket: direct ranges, native ranges, or VLAN ranges. BGP sessions cannot be established over routed ranges.

Note

Notes:

  • This option doesn’t rely on the tunnel being established.

  • Cato Cloud assumes all BGP connections are “next-hop-self”: the neighbor is always the next hop selected by Cato Cloud, and Cato Cloud advertises its neighbor's IP as the next hop for all advertised routes.

  • When BGP is on the Alt. WAN, it usually receives other sites’ ranges (all other sites which are reachable via the Alt. WAN link). Cato Cloud filters these ranges before it considers dynamic and floating ranges.

  • When a Socket is disconnected from the Cato Cloud, all other site ranges are withdrawn. This allows continued reachability in a case where the BGP peer has a secondary path that can be alternatively used as a next hop if it temporarily disconnects from the Cato Cloud. (Supported from Socket version 17.0 and higher)

For more about configuring a BGP neighbor, see Defining BGP Neighbors.

Dynamic Ranges

Dynamic ranges are IP ranges that are dynamically learned by Cato Cloud from a BGP neighbor. Once accepted by Cato Cloud, they are propagated throughout an account will become reachable via that neighbor from anywhere in the network.

Note

Note:

Since dynamic ranges are dynamically learned from the BGP neighbor and cannot be configured as global objects in the Cato Management Application, they cannot be used explicitly in network and/or security rules, and therefore behave according the policy of the site they reside in.

Floating Ranges

Floating ranges are global IP ranges that are not connected to a specific site, but can be learned from any site with a BGP neighbor. For example, in a Disaster Recovery (DR) scenario, many applications (such as VMware NSX) can move servers from one location to the other while maintaining their IP addresses. In these cases, BGP helps to update the remaining network objects and advertises where these servers now reside.

Floating ranges can be explicitly defined in Cato Cloud as global objects. When the Floating Range global object is associated with a site, it does inherit the site’s security or networking policy (as such associations can change dynamically). However, you can leverage the global object definition to explicitly create network and/or security rules as per your organization policy requirements.

In order for a BGP dynamic range to inherit the security or network policy for a site, it must exactly match the floating range. For example, if the BGP dynamic range is 192.168.1.0/24 and the floating range is defined as 192.168.1.1/32, then there is no connection between them and the BGP dynamic range doesn't inherit the policies from the floating range.

Note

Note: Floating Ranges cannot overlap with static ranges.

How BGP in the Cato Cloud is Designed and Performs

Handling Routes

The BGP neighbor in the Cato Cloud is connected with a Cato PoP or with the site connection. The site connection can be a Cato Socket or an IPsec tunnel. When the Cato Cloud receives a new or updated BGP route, it always synchronizes with the global WAN network (site connections and PoPs).

When a BGP route is received, Cato Cloud associates it with the relevant object as follows:

  • IP ranges defined as floating ranges are associated with their defined objects and adhere to all networking and security policies assigned to the objects.

  • All other IP ranges are considered as dynamic ranges, and adhere to all networking and security policies assigned to the site.

Routes can be withdrawn through a BGP message or through a neighbor disconnect (CEASE or physical), and Cato Cloud immediately propagates the withdrawal.

How Routes are Prioritized

In contrast to regular static ranges, BGP allows multiple routes that may overlap or even be duplicated across parts of your network. So how does Cato Cloud decide through which path to route packets?

When multiple routes can be applied to a destination IP address, routing decisions will be performed according to the following priorities:

  1. More specific routes are selected over less specific routes (/24 over /22 and so on).

  2. Static Ranges are preferred over Floating Ranges, which in turn are preferred over Dynamic Ranges.

  3. Lower Neighbor Metric is preferred.

  4. Shortest AS-PATH is preferred.

  5. Lower Tunnel Metric is preferred.

  6. Lower BGP MED (Multi-Exit-Discriminator) from the route ID is preferred.

Since Cato Cloud performs Layer-7 Policy-Based Routing, the need to avoid asymmetric routes is decisive. For that reason, route priority is universal within the same account: in other words, a single origin will be selected from any location within the Cato Cloud network.

How Routes are Propagated

When routes are accepted by a Cato Cloud BGP neighbor, information associated with it (AS-path, BGP-communities) is preserved. When dynamic ranges are advertised to BGP neighbors, the AS-Path will be appended with Cato Cloud AS number (as usual with BGP).

Cato Cloud transparently propagates all Path Attributes marked with Transitive flag (RFC 4271), including communities.

Account ranges (static) are advertised with the Cato Socket Neighbor ASN as the originating ASN (Autonomous System Number - see below Assigning an ASN to a Neighbor).

Cato Cloud does not perform route summaries.

Note

Note: Some well known communities are not propagated by Cato Cloud to BGP neighbors on egress, such as no-export.

Assigning an ASN to a Neighbor

The Autonomous System Number (ASN) is a number between 64,512 – 65,534 (private ASN), which represents the routing entity establishing the communication. Cato Networks’ default ASN is 64,515.

Cato Cloud supports eBGP, so a BGP Neighbor must have a different ASN than the Cato Cloud side.

Note

Note: It is a best practice to globally use a single ASN to represent the Cato Cloud side of communication across all BGP sessions. If you are considering using different ASNs across different neighbors, please contact Cato Networks support.

How Loops are Prevented

When a route is received by Cato Cloud, the AS path is scanned for the Cato Cloud ASN of the neighbor. Any route containing this ASN will be discarded. Note that the neighbor only scans the current neighbor’s ASN.

Note

Note: Cato Cloud does not support Graceful Restart.

Security and Networking

Dynamic ranges are automatically associated with the site from which the route was received, and inherit all the site’s policy groups, network and security policies. Floating ranges are defined globally and security rules are applied to them directly, or by associating them with policy groups.

Before You Begin Using BGP

Which site Connection Types can I use?

  • Cato supports BGP for sites that use Sockets, vSockets, and IPsec sites (Cato-initiated IPsec IKEv1, IPSec IKEv2). In addition, there must be requires connectivity with your existing BGP routers.

How will the BGP neighbor establish the BGP session with Cato?

  • BGP sessions require established connectivity between a BGP neighbor and a site over local routes in sockets or over an IPSec tunnel.

  • For Cato Socket deployment, only direct, VLAN and native ranges can be used for establishing sessions; routed ranges cannot be used for BGP session establishment.

Setting BGP Sessions over Alternative WAN links

In Cato Cloud, Alternative WAN destinations include two (potentially VLAN-tagged) networks: public and private. A BGP neighbor must be within one of those two networks, and the BGP neighbor on the Cato Cloud side will be the corresponding Cato IP for that range.

When defining a BGP session over a public interface, you can also perform Source NAT on traffic going through that link. This means that for all outgoing traffic via that neighbor, the source address will be the Cato neighbor IP.

Known Limitations

  • The Cato Cloud only supports IPv4.

  • If multiple ASNs are configured for multiple neighbors, the ASNs will not be detected by the neighbor and looping may result.

  • The Cato Cloud allows propagation of routes containing the neighbor's ASN, relying on the neighbor to scan for loops.

  • Floating Ranges cannot overlap with a static range.

  • The Cato Cloud does not support Graceful Restart for route withdrawal.

  • BGP route changes (including route withdrawal) that are initiated by Cato, don't generate events.

  • The Cato Cloud does not perform route summarization.

  • By default, Cato limits the number of received prefixes from each BGP neighbor to 1024. To increase this limit, contact Support.

  • BGP isn't supported for accounts that use static range translation. If you require BGP for a translated Native Range for a Socket site, please contact Support.

Was this article helpful?

0 out of 0 found this helpful

Comments

0 comments

Please sign in to leave a comment.