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.
This section describes Cato Cloud’s BGP components (including global objects), and how Cato Cloud support of BGP is designed and performs.
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.
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 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 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.
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.
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:
-
More specific routes are selected over less specific routes (/24 over /22 and so on).
-
Static Ranges are preferred over Floating Ranges, which in turn are preferred over Dynamic Ranges.
-
Lower Neighbor Metric is preferred.
-
Shortest AS-PATH is preferred.
-
Lower Tunnel Metric is preferred.
-
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.
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.
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.
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.
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.
-
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.
Comments
0 comments
Please sign in to leave a comment.