CN116982294A

CN116982294A - Management network and method of operation

Info

Publication number: CN116982294A
Application number: CN202180094919.XA
Authority: CN
Inventors: X·S·伟; P·瓦纳拉特; S·郑; C·向
Original assignee: Avidros Systems
Current assignee: Avidros Systems
Priority date: 2020-12-31
Filing date: 2021-12-29
Publication date: 2023-10-31

Abstract

Computerized methods for communication between components of one or more public cloud networks using private Internet Protocol (IP) addressing. The method generally includes determining whether outbound traffic corresponds to a first type of outbound traffic forwarded from a gateway-supported cloud instance. In response to determining that the first type of outbound traffic is being forwarded from the cloud instance, the first type of outbound traffic is directed via a data interface of the gateway. Further, the method generally includes determining whether the outbound traffic corresponds to a second type of outbound traffic initiated by logic within the gateway. Responsive to determining that logic within the gateway is initiating outbound traffic of a second type, the outbound traffic of the second type is directed via a management interface of the gateway.

Description

Management network and method of operation

Cross Reference to Related Applications

The present application claims priority from U.S. application Ser. No. 17/396,630, filed 8/6 of 2021, which claims priority from U.S. provisional patent application Ser. No. 63/133,102, filed 31 of 12/2020, the entire contents of which are incorporated herein by reference.

Technical Field

Embodiments of the present disclosure relate to the field of networking. More particularly, one embodiment of the present disclosure relates to a managed network architecture that supports communication between network devices through the use of private IP addresses.

Background

Over the past few years, cloud computing provided infrastructure as a service (IaaS), a cloud-based architecture, in which resources were provided as part of a public cloud network and tenants were made available as services to access the resources. One of the services allows a tenant to operate a software component (e.g., a virtual machine instance, such as a virtual server) residing in a public cloud network. Thus, such migration of software functionality has led to an increasing use of virtual private cloud networks (VPCs), i.e. on-demand configurable pools of shared resources allocated within cloud computing platforms, and provides a degree of isolation between different organizations or other entities (hereinafter "users") that use these resources. However, such increased use of public cloud network resources has resulted in greater demands on cloud network management.

Recently, some software platforms have developed and deployed the ability to monitor and manage multi-cloud networking independently of a selected one or more public cloud providers. Some of which provide automated operational visibility of cloud resources. For example, a software platform basically includes a controller and a set of gateways, all deployed in one or more public cloud networks. For the software platform, the controller and gateway manage their communications based on managing message exchanges on the network, where the management messages may include gateway keep-alive messages, tunnel status messages, and configuration change messages. Such management networks (sometimes referred to as out-of-band (OOB) networks) are necessary for distributed systems in which controllers and gateways may be deployed in different areas or even in different public cloud networks.

Currently, conventional OOB networks are deployed as part of a public addressable network (internet), such that both the controller and gateway are assigned public Internet Protocol (IP) addresses and communicate with each other over the internet. However, this type of OOB network has a number of drawbacks when used for cloud resource management. For example, network resources deployed as part of a local network (on-premises network) typically default to communicating via a private IP address at the time of operation according to agreed upon operational rules. However, as the local network migrates toward the cloud deployment, many of these cloud-based resources communicate at the time of operation through public IP addresses, and thus the cloud-based virtual private network does not conform to pre-established operational rules. As a result, clients now require OOB networks to support communications using private IP addressing, both for compliance and for security reasons, because networks with resources (e.g., controllers and/or gateways) accessible through public IP addresses are more vulnerable to network attacks (e.g., denial of service "DOS" attacks, etc.).

Drawings

Embodiments of the invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements and in which:

FIG. 1 is a first exemplary embodiment of a public cloud computing platform including a management network.

Fig. 2 is an illustrative embodiment of a method of operation for deploying the management network of fig. 1.

Fig. 3 is an exemplary embodiment of a window or dialog box for creating the native cloud gateway of fig. 1.

Fig. 4 is an exemplary illustration of a logical representation of one of the branch gateways deployed within the branch VPC of fig. 1.

FIG. 5 is an exemplary embodiment of the public cloud computing platform of FIG. 1, including a peer-to-peer management network.

FIG. 6 is a third exemplary embodiment of the public cloud computing platform of FIG. 1, which is based on having a management networkIs a public cloud computing platform of (a).

Fig. 7 is an exemplary embodiment of a management network used to support a multi-cloud network.

Detailed Description

Embodiments of a system and method for establishing a management network within a public cloud network are shown, wherein the management network supports exchange of management information through private Internet Protocol (IP) addressing rather than publicly routable IP addressing. Here, one embodiment of the present disclosure generally includes a network architecture that supports operability of a private management network using a native network architecture of a cloud provider. More specifically, for example, in In A Web Services (AWS) public cloud network, AWS transit gateways are used to support communications between network resources, such as communications between a controller and one or more gateways or between at least two gateways. Alternatively, for example, in +.>Is->In public cloud network, ++>The native transit gateway may serve as a "backbone" of the private management network (i.e., a means for distributing management information throughout the management network). These two public cloud network deployments will be described below.

In particular, according to one embodiment of the present disclosure, a native cloud gateway (e.g., an AWS transit gateway,Native transit gateway, etc.) may be configured to support communications with "branch gateways," i.e., gateways deployed as edge devices of a virtual private cloud network (hereinafter "branch VPCs") that primarily include these gateways. Based on such a network architecture, the branch gateway is communicatively coupled to the controller via the native cloud gateway, and thus, both the branch gateway and the controller are configured to communicate management information with each other via the native cloud gateway. Here, the native cloud gateway may be configured to support private IP-based communications between different branch gateways, and the controller may be configured to allow management information to be transferred from the controller to a particular branch gateway and/or one or more instances of communication with the branch gateway (e.g., cloud instances associated with one or more particular subnets). Examples of management information may include, but are not limited to, or only limited to, gateway keep-alive messages, tunnel status messages, and/or configuration change messages.

Additionally or alternatively, some gateways in communication with the native cloud gateway may include a "transit gateway," a gateway deployed within a transit VPC. According to one embodiment of the present disclosure, a transit gateway may be communicatively coupled to a corresponding branch gateway to provide a data path between a network device operating within a local network and one or more cloud instances in communication with one of a plurality of branch gateways. In addition, each transit gateway as well as the tributary gateway may be accessed according to a unique class-free inter-domain routing (CIDR) private IP address to propagate messages over the management network.

According to another embodiment of the present disclosure, in a multi-cloud environment, gateways deployed in different public cloud networks may be configured with private network connections to controllers. This may be achieved by communication over a local network. For example, the VPC connection may be implemented through a private loop or the public internet; however, VPCs associated with different public cloud networks are interconnected with the controller through the local network to allow for private IP addressing schemes.

I.Terminology

In the following description, certain terminology is used to describe features of the invention. In some cases, the term "logic" or "component" represents hardware, software, or a combination thereof configured to perform one or more functions. As hardware, logic (or components) may include circuit modules having data processing or storage functions. Examples of such circuit modules may include, but are not limited to or limited to, a processor, such as a microprocessor, one or more processor cores, a programmable gate array, a microcontroller, an application specific integrated circuit, a wireless receiver, a transmitter, and/or transceiver, or combinational logic.

As an alternative to, or in combination with, the hardware circuit modules described above, the logic (or components) may be software in the form of one or more software modules that may be configured to operate as their corresponding circuit modules. For example, a software module may be an instance of software that operates as a processor, i.e., a virtual processor whose underlying operations are based on a physical processor, such as, for exampleEC2 instances within the AWS infrastructure. Further, a software module may include an executable application, daemon application, application Programming Interface (API), subroutine, function, procedure, applet, servlet, routine, source code, shared library/dynamic load library or even one or more instructions.

The software module(s) may be software instances stored in any type of suitable non-transitory storage medium or transitory storage medium (e.g., electrical, optical, acoustical or other form of propagated signals such as carrier waves, infrared signals, or digital signals). Examples of non-transitory storage media may include, but are not limited to or only limited to, programmable circuitry; a semiconductor memory; as software, logic (or components) may operate as firmware stored in the persistent storage.

The term "gateway" may be interpreted as virtual or physical logic. For example, as an illustrative example, a gateway may correspond to virtual logic in the form of a software component, such as a routing component assigned a private IP address within a private IP address range associated with a virtual private cloud network (VPC) that includes the gateway. The software components may operate in conjunction with underlying operations of the processor (e.g., access to content in the data store, such as routing tables or other information processing activities) and are maintained in a non-transitory storage medium. The gateway allows Cloud Service Providers (CSPs) and enterprises to enable cloud network traffic routing between data centers and virtual and physical networks. Alternatively, in some embodiments, the gateway may correspond to physical logic, such as an electronic device communicatively coupled to the network and assigned an IP address.

Thus, a plurality of gateways may be deployed in the VPC, and these gateways may be configured to control traffic flow from the software instance of the VPC to one or more remote sites, which may be configured to process data received from the software instance. Although of similar architecture, gateways may also be differentially identified based on their location/operability within a public cloud network platform. The "branch" gateway is configured to interact with cloud software instances, while the "transit" gateway is configured to further facilitate propagation of data traffic (e.g., one or more messages) directed to the branch gateway within the branch VPC or to computing devices within the local network.

Furthermore, according to one embodiment, the term "transit VPC" may refer to a VPC configured to connect multiple VPCs, wherein the VPCs may be logically isolated and/or virtually located on a data center that may not be geographically co-located. The transit VPC acts as a global network transit center that operates as a point of attachment for a branch VPC to a branch VPC communication (e.g., propagation of network traffic having a source IP address in a first branch VPC and having a destination IP address in a second branch VPC) or a branch VPC to a data center communication (e.g., propagation of network traffic having a source IP address in a first branch VPC and having a destination IP address at a data center). In addition, the transit VPC may also route network traffic to other transit VPCs (e.g., propagation of network traffic having a source IP address in a first branch VPC connected to the first transit VPC and a destination IP address in a second branch VPC connected to the second transit VPC), and may then continue to propagate network traffic.

Furthermore, the term "instance subnetwork" may refer to a subnetwork of cloud software instances associated with a branch VPC. Here, information from or directed to a particular software cloud instance forming a particular instance network is forwarded to a selected branch gateway. A "VPC routing table" is a data set used to associate a tributary gateway within each VPC with one or more different instance subnets.

An "internet protocol security (IPSec) tunnel" constitutes a secure peer-to-peer communication link established between gateways adjacent to a VPC or between a gateway of a VPC and a router of a local network. The peer-to-peer communication link is protected by a secure network protocol suite known as "internet protocol security" (IPSec). For a full mesh network deployment where the branch VPC has "M" gateways and the neighboring (transit) VPC has "N" gateways, mxN IPSec tunnels are created between the branch VPC and the transit VPC to form the full mesh network. These IPSec tunnels may be represented in the gateway by Virtual Tunnel Interfaces (VTIs) and tunnel states may be represented by VTI states.

The term "computerized" generally means that any corresponding operations are performed by hardware in combination with software. The term "message" generally refers to information transmitted in a prescribed format and according to an appropriate delivery protocol. Thus, each message may be in the form of one or more packets, frames, or any other bit sequence having a prescribed format.

The term "communication link" may be construed as a physical or logical communication path between virtual or physical logic. For example, as a physical communication path, wired and/or wireless interconnects in the form of electrical wiring, optical fibers, cables, bus traces, or wireless channels using infrared, radio Frequency (RF) may be used. The logical communication path may be established to support transmission of one or more messages between the components and formed based on the exchange of messages.

Finally, the terms "or" and/or "as used herein should be interpreted as inclusive or meaning any one or any combination. For example, "A, B or C" or "A, B and/or C" refer to any one of the following: "A; b, a step of preparing a composite material; c, performing operation; a and B; a and C; b and C; A. b and C). An exception to this definition will occur only when a combination of elements, functions, steps or acts are in some way inherently mutually exclusive.

While this invention is susceptible of embodiment in many different forms, this disclosure is to be taken in an illustrative of the principles of the invention and not in limitation to the specific embodiments shown and described.

General System architecture-first embodiment

Referring to fig. 1, a first exemplary embodiment of a public cloud computing platform 100 is shown. Here, public cloud computing platform 100 primarily includes public cloud network 110, which includes data network 112 and management network 114. In general, and represented by dashed communication links, data network 112 is configured to support one or more virtual private cloud networks (VPCs) 120 ₁ To 120 to _N (N.gtoreq.1) and the local network 190. The management network 114 is configured to support management information exchange between components deployed throughout the cloud network 110. It is noted that aspects of public cloud computing platform 100, such as VPC, are logical representations of software that is executing and providing additional functionality to public cloud network 110.

In particular, according to this embodiment of the present disclosure, the data network 112 is configured to enable the data to be stored in the data network by the VPC 120 ₁ To 120 to _N One (e.g., VPC 120) ₁ ) Any cloud instance 132 supported is data transferred between one or more computing devices 180 deployed within the local network 190. These data transfers are by routing data messages at least through a first virtual private cloud network (hereinafter "branch VPC") 120 within the public cloud computing platform 100 ₁ And a second virtual public cloud network (hereinafter referred to as a "transit VPC") 140. As shown, a plurality (i.e., two or more) of branch VPCs 120 are shown in FIG. 1 ₁ To 120 to ₂ And one or more transit VPCs 140, it is contemplated that multiple transit VPCs may be deployed as follows: first transit VPC 140 ₁ Configured to support multiple branch VPCs deployed within a first geographic region (e.g., branch VPC 120 ₁ To 120 to ₂ ) While another transit VPC 140 ₂ May be configured to support different branch VPCs within a second geographic region different from the first geographic region.

As shown, branch VPC 120 ₁ Is configured to support communication with one or more real example networks 130. Each of these real-instance networks includes one or more cloud instances, where each real-instance network is communicatively coupled to exchange data traffic with a selected gateway of a set (e.g., two or more) of gateways maintained in a particular branch VPC. As an illustrative example, include cloud instance 132 ₁ To 132 ₂ Is communicatively coupled to each instance subnetwork 130 maintained at the branch VPC 120 ₁ A set of gateways 122 in (a) ₁ To 122 ₂ Selected gateway 122 of (a) ₁ Exchanging data traffic. Here, these gateways 122 ₁ To 122 ₂ Referred to as a "breakout gateway" 122 ₁ To 122 ₂ 。

As further shown in fig. 1, controller 150 is configured as a component of cloud network 110 to collect information from different components within cloud network 110 and generate routing table 160, routing table 160 establishing and maintaining information related to communication links associated with these components. According to one embodiment of the present disclosure, as shown, the controller 150 may be configured to generate and populate a VPC routing table 162 associated with VPCs deployed within the cloud network 110.

For example, as an illustrative example, the controller 150 may be configured to target the branch VPCs 120 supported by the controller 150 ₁ To 120 to ₂ Each branch gateway 122 within ₁ To 122 ₄ The VPC routing table 162 is generated and populated. Here, each of these VPC routing tables 162 includes a respective branch gateway 122 therewith ₁ … or 122 ₄ Associated routing information and associated with a particular branch gateway 122 ₁ … or 122 ₄ And branch gateway 122 ₁ … or 122 ₄ Routing information associated with communication links between any cloud instances 132 associated with a particular instance of the network being supported. The routing information may include, but is not limited to, or is limited to, with the breakout gateway 122 ₁ To 122 ₄ And/or with a breakout gateway 122 ₁ To 122 ₄ The private IP address associated with the cloud instance of the communication.

Further, other VPC routing tables 162 may be configured to include information associated with any transit VPCs (e.g., transit VPC 140) deployed in support of controller 150 ₁ ) Each gateway 142 within ₁ To 142 ₂ Associated routing information. Here, these gateways 142 ₁ To 142 ₂ May be referred to as a "transit gateway" 142 ₁ To 142 ₂ . To and transit gateway 142 ₁ To 142 ₂ The routing information of the associated VPC routing table 162 may include, but is not limited to, or is limited to, the transit gateway 142 ₁ To 142 ₂ An associated private IP address.

In addition to the VPC routing table 162, the controller 150 may be adapted to configure a gateway routing table 164 for each gateway within the VPC of the cloud network 110 for data transmission. More specifically, according to one embodiment of the present disclosure, the controller 150 may be configured to initially target the branch VPC(s) 120 residing therein ₁ To 120 to ₂ Branch gateway 122 within ₁ To 122 ₄ And a transit gateway 142 residing within transit VPC 140 ₁ To 142 ₂ The gateway routing table 164 is programmed. The gateway 122/142 relies on the gateway routing table 164 to determine which tunnels to use to route to a destination (e.g., local networkThe computing devices 180 within the network 190 or virtual tunnel interfaces of the target cloud instance) propagate data traffic (e.g., messages). For this embodiment of the present disclosure, gateway routing table 164 includes information associated with auxiliary (e.g., generic routing encapsulation "GRE") tunnels between the IPSec tunnel and gateways within the same VPC (for use in the event of failure of all IPSec tunnels).

In summary, routing table 160 is programmed to support communication links between different sources and destinations, such as cloud instance 132 and local computing device 180 within a particular instance network.

Here, controller 150 is communicatively coupled to local network 190 via a communication link 195, such as an internet protocol security (IPSec) tunnel. If controller 150 is to be deployed using its private IP address, internet protocol security (IPSec) tunnel 195 allows network administrator 192 associated with local network 190 to gain access to controller 150 and control/manage/monitor operability of cloud network 110 via computing device 180.

Still referring to fig. 1, as described above, the architecture of the data network 112 may be based at least in part on deployment at the branch VPC 120 ₁ A set of branch gateways 122 within ₁ To 122 _P (P.gtoreq.2) and a set of transit gateways 142 deployed within transit VPCs 140 ₁ To 142 _R (R.gtoreq.2) peer-to-peer interconnection between the two. For ease of illustration, in FIG. 1, the set of branch gateways 122 ₁ To 122 _P Represented as first branch gateway 122 ₁ And a second branch gateway 122 ₂ But in branch VPC 120 ₁ Three or more finger gateways may be deployed. Likewise, the group transit gateway 142 ₁ To 142 _R By a first transit gateway 142 ₁ And a second transit gateway 142 ₂ Three or more transit gateways are represented, but may be deployed within the transit VPC 140.

As further shown in fig. 1, a finger gateway 122 ₁ To 122 ₂ Is configured for communication with the transit gateway 142 via a peer-to-peer communication link 155 ₁ To 142 ₂ And transmitting the data service. In particular, as shown, each finger gateway 122 ₁ 、122 ₂ Via four active peer-to-peer communication links 155 ₁ To 155 ₄ Communicatively coupled to at least transit gateway 142 ₁ 、142 ₂ . Peer-to-peer communication link 155 ₁ To 155 ₄ An encrypted secure tunnel, such as a tunnel operating in accordance with a secure network protocol, may be constructed. One example of a secure network protocol may include, but is not limited to, or is limited to, internet protocol security (IPSec). Thus, a VPC-to-VPC tunnel may be referred to as an "IPSec tunnel.

As further shown in fig. 1, the management network 114 is based at least in part on a native cloud gateway 170 (e.g., an AWS transit gateway "TGW" as shown,Native transit gateway, etc.) configured to support branch VPCs 120 within a specified region ₁ To 120 to ₂ And at least one transit VPC 140. Based on this management network architecture, branch VPC 120 ₁ To 120 to ₂ Is communicatively coupled to the controller 150 via the native cloud gateway 170, and thus, the branch VPC 120 ₁ To 120 to ₂ And controller 150 are both configured to route management information addressed with private IP addresses to each other via native cloud gateway 170. Likewise, the management network 114 may be configured to support communication from the controller 150 to one of the branch gateways (e.g., the branch gateway 122) ₁ ) One or more cloud instances 132 (e.g., cloud instances 132 associated with real-instance network 130) in communication ₁ To 132 ₂ ) And transmitting management information.

In other words, by operating as part of management network 114, native cloud gateway 170 may operate according to a hub and branch deployment to maintain one or more branch VPCs (e.g., branch VPC 120 ₁ To 120 to ₂ ) Communication of management information between one or more transit VPCs (e.g., transit VPC 140) and a shared service VPC 165 that includes controller 150. As shown, according to one embodiment of the present disclosure, the native cloud gateway 170 may be configured as a component based on the cloud network 110 (i.e., the branch gateway 122 ₁ To 122 ₄ Gateway 142 for transfer ₁ To 142 ₂ And a controller 150 A) generates one or more routing tables 172. The native cloud gateway 170 relies on the routing table 172 to support communication over the management network 114 using the private IP address when transmitting one or more messages over the management network 114.

More specifically, through the use of routing table 172, native cloud gateway 170 is able to support different tributary VPCs (such as tributary VPCs 120 within the same geographic region ₁ And branch VPC 120 ₂ ) Communication between them, such as transmission of management information. Further, the native cloud gateway 170 can support communications with a remotely located branch VPC in a different geographic region based at least in part on communications with another native cloud gateway (not shown) maintaining private IP addressing associated with the branch gateway within the remotely located branch VPC. Furthermore, the native cloud gateway 170 may rely on these routing tables 172 to support access to any transit gateway 142 ₁ To 142 ₂ Management information of the management information.

Thus, deployed at branch VPC 120 ₁ To 120 to ₂ Each branch gateway 122 within ₁ To 122 ₄ Deployed in transit VPC 140 ₁ Each transit gateway 142 within ₁ To 142 ₂ May be accessed within the routing table according to a unique classless inter-domain routing (CIDR) private IP address to propagate messages on the management network 114.

III operational flow-construction of management network

Referring now to FIG. 2, an illustrative embodiment of a method of operation for deploying management network 114 is shown, wherein references to components of cloud network 110 are shown in FIG. 1. Here, an initial boot of the controller 150 is performed (block 200), i.e., an instance of software that operates as part of the cloud network 110. More specifically, a communication link 195 is established between a Virtual Private Network (VPN) endpoint, which is a native construct provided as part of cloud network 110 and included as part of shared resource VPC 165, and local network 190. If a network administrator of local network 190 may require secure HTTP (HTTPs) communication to access controller 150 and controller 150 is to be booted with its private IP address, a communication link 195 (e.g., an IPSec Virtual Private Network (VPN) connection) is required so that computing device 180 operating as part of local network 190 can access controller 150 via its private IP address.

After initial boot operation and establishment of communication link 195, controller 150 is started on a private subnet in a Virtual Private Cloud (VPC) called shared services VPC 165 (block 210). In other words, the controller 150, which is an example of software, is activated and is accessible via a private IP address to help formulate the management network 114 of fig. 1.

The slave controller 150 creates and initiates the native cloud gateway 170 (block 220). Such creation of the native cloud gateway 170 may be performed by a controller that generates the displayable elements 300 (such as the window or dialog 300 shown in fig. 3). Displayable element 300 includes a plurality of entry fields 310, including: a first entry field 320 that allows a network administrator to identify a particular cloud network (e.g., AWS); and a second entry field 330 that allows a network administrator to identify a particular region within a cloud network (AWS) into which the native cloud gateway 170 is to be created and launched. The displayable element 300 also includes a third entry field 340 that provides a selection of an identifier (e.g., name) assigned to the native cloud gateway 170. During creation, controller 150 also populates the routing tables used by native cloud gateway 170. Account name 350 may additionally be provided for assignment to native cloud gateway 170 in order to support operability of certain VPCs associated with account owners and to determine cost allocations associated with the infrastructure provided by the cloud network provider.

Returning to fig. 1-2, after creating and starting up the native cloud gateway 170, a communication link forming the management network 114 may be established. In particular, the sharing service VPC 165 including the controller 150 is logically coupled to the native cloud gateway 170 via a first communication link (e.g., the first logical interconnect 290 shown in fig. 1) (block 230). Through logical concatenation and storage in routing table 172, native cloud gateway 170 may see the CIDR private IP address of controller 150. Also, based on the use of the console of the controller 150 or via an Application Programming Interface (API), one or more transit VPCs (e.g., transit VPCs 140) may be logically coupled to the native cloud gateway 170 via a second communication link (e.g., second logical interconnect 292 shown in fig. 1) (block 240), whichAs a result, the native cloud gateway 170 may see each transit gateway 142 within the transit VPC (e.g., transit VPC 140) ₁ To 142 ₂ Is a CIDR private IP address. Here, the logical coupling to the transit VPCs may only point to one or more transit VPCs configured to receive management information from the controller 150 via the native cloud gateway 170.

Finally, if a logical interconnect 290 is established between the native cloud gateway 170 and the shared services VPC 165 including the controller 150, a branch VPC (e.g., branch VPC 120 ₁ To 120 to ₂ ) Is logically coupled to the native cloud gateway 170 via respective communication links, such as the third logical interconnect 294 and the fourth logical interconnect 296 of fig. 1. As a result, the native cloud gateway 170 can see the branch VPC 120 ₁ To 120 to ₂ Each branch gateway 122 within ₁ To 122 ₄ And CIDR private IP addresses for other components of cloud network 110, thereby enabling communication over management network 114 (block 250). A branch gateway (e.g., branch gateway 122) is described below and illustrated in fig. 4 ₁ ) Further discussion of operation in logical coupling to the native cloud gateway 170.

After the management network 114 is established, the data network 112 is established. In particular, each transit gateway (e.g., transit gateway 142) on the private subnetwork in transit VPC 140 is started from the console of controller 150 or via an API ₁ To 142 ₂ ) (block 260). Thereafter, each transit gateway 142 is pointed at ₁ To 142 ₂ May be uploaded from controller 150 through management network 114 via native cloud gateway 170 (e.g., via logical interconnections 290 and 292 of fig. 1).

Once the transit gateway 142 is initiated from the console of the controller 150 or via an API ₁ To 142 ₂ The and branch VPC 120 may be started ₁ To 120 to ₂ Each associated finger gateway 122 ₁ To 122 ₄ (block 270). Thereafter, each finger gateway 122 ₁ To 122 ₄ May be logically coupled to the transit gateway 142 ₁ To 142 ₂ (block 280). For example, a first breakout gateway 122 ₁ May be via a communication link 155 ₁ To 155 ₂ Logically coupled to the first transit gateway 142 ₁ While the second branch gateway 122 ₂ May be via a communication link 155 ₃ To 155 ₄ Logically coupled to the second transit gateway 142 ₂ . Likewise, the third branch gateway 122 ₃ May be via a communication link 155 ₅ To 155 ₆ Logically coupled to the first transit gateway 142 ₁ While the fourth finger gateway 122 ₄ May be via a communication link 155 ₇ To 155 ₈ Logically coupled to the second transit gateway 142 ₂ . In general, branch VPC 120 ₁ To 120 to _N Communication links 155 with one or more transit VPCs (e.g., transit VPC 140) ₁ To 155 ₈ A data network 112 is formed.

Referring now to FIG. 4, the branch VPC 120 deployed in FIG. 1 is shown ₁ Branch gateway 122 within ₁ An exemplary illustration of a logical representation of one. Conventionally, the finger gateway 122 ₁ A single interface 400 is configured that is associated with the assigned public IP address to which the data transfer and management information is directed. According to one embodiment of the present disclosure, the breakout gateway 122 ₁ Two forward interfaces (front-facing interfaces) are configured, namely: a data interface (ETH 0) 400 adapted to communicate over a communication link (e.g., link 155 ₁ ) The slave/relay VPC 140 transceives data transmissions; and a management interface (MGMT) 410 adapted to transceive management information from/to controller 150 via native cloud gateway 170.

More specifically, management interface 410 interfaces with a dedicated management subnet 420 (e.g., providing for a branch gateway 122 ₁ A private IP address or private IP address range) of access to the management subnet 420 is associated with a particular (management) routing table 425 associated with the management subnet 420. Here, according to one embodiment, management routing table 425 forms branch gateway 122 ₁ Is part of the VPC routing table 162 (see fig. 1). As a result, when hint logic is coupled to native cloud gateway 170, branch gateway 122 ₁ Management subnet 420 along with management routing table 425 are provided to controller 150 via native cloud gateway 170 via management interface 410.

Except for logical coupling to the native cloud gateway 170, as further shown in fig. 4, the finger gateway 122 ₁ One or more transit gateways (e.g., transit gateway 142) configured to logically couple to transit VPC 140 ₁ ). In particular, the data interface 400 and a subnet 430 dedicated to the data interface 400 (e.g., providing the distribution gateway 122 via the data interface 400) ₁ A public IP address or public IP address range) of access to the data subnet 430, and a routing table 435 belonging to the data subnet 430. The data routing table 435 may include an IP address associated with a communication link established via the data interface 400 (e.g., with the communication link 155 ₁ To 155 ₂ Associated addressing information) and, according to one embodiment, data routing table 435 may constitute a finger gateway 122 ₁ Is part of the VPC routing table 162 (see fig. 1).

As a result of this configuration, from and to the finger gateway 122 ₁ One of the associated cloud instances (e.g., cloud instance 132 operating as an EC2 instance ₁ ) Is routed as a message through data interface 400 by finger gateway 122 ₁ The generated management information 460 (e.g., hello messages, keep alive messages, etc.) is routed through the management interface 410. Thus, for outbound traffic, if the traffic is from the tributary gateway 120 ₁ Any cloud instance supported (e.g., cloud instance 132 ₁ ) Forwarded, then branch gateway 122 ₁ Routing control logic 440 (e.g., virtual processor, routing control instance, etc.) within selects data interface 400, if the traffic is by branch gateway 122 ₁ Originating, branch gateway 122 ₁ Routing control logic 440 within selects management interface 410. Likewise, the management interface 410 is utilized to communicate from the controller 150 of fig. 1 (via the native cloud gateway 170), while the data interface 400 is utilized to communicate from the transit VPC 140 of fig. 1.

General architecture-second embodiment

Referring now to fig. 5, an exemplary embodiment of the public cloud computing platform 100 of fig. 1 deploying a peer-to-peer management network 500 is shown. Here, public cloud computing platform 100 mainly includes one or more branch VPCs 120 ₁ To 120 to _N At least one ofPersonal transit VPC 140, shared services VPC 165, secure network (Firenet) VPC 510 as described in U.S. patent application No. 17/216,596 entitled "Systems and Method For Firewall Deployment in a Cloud Computing Environment (system and method for firewall deployment in cloud computing environments)", and native cloud gateway 170. The native cloud gateway 170 establishes: (i) With each branch VPC 120 ₁ To 120 to _N Is a communication link 520 of (1) ₁ To 520 _N (ii) a communication link 522 with the transit VPC 140, (iii) a communication link 524 with the shared services VPC 165, and (iv) a communication link 526 with the secured network VPC 510.

Here, as described above, a communication link 530 is established between a Virtual Private Network (VPN) endpoint 535 and a local network 190 (operation 1), the endpoint 535 being a native construct provided as part of the cloud network 110 and included as part of the shared resource VPC 165. To provide secure communications, an IPSec Virtual Private Network (VPN) connection may be established such that computing device 540 operating as part of local network 190 can access controller 150 via its private IP address.

After the communication link 530 is established, the controller 150 is started on the private subnet in the shared service VPC 165 (operation 2). In other words, the controller 150, which is an instance of software, is activated and is accessible via a private IP address to assist in formulating the peer-to-peer management network 500. Thereafter, the controller 150 may be configured to create a data link 550/552 to establish a peer-to-peer connection between the controller 150 and the transit VPC 140/the secured network VPC 510, respectively (operation 3). Thereafter, each transit gateway 142 is started on the private subnetwork ₁ To 142 ₂ And they can now work (operation 4).

Although cloud network 110 may rely on private IP addresses to enable connections between components, the connections to branch gateway 122 are maintained and utilized through connections via native cloud gateway 170 ₁ To 122 ₂ And transit gateway 142 ₁ To 142 ₂ Internet access to each of the plurality of devices.

V. general architecture-third embodiment

Referring now to FIG. 6, there is shown asBased onAn example embodiment of a peer-to-peer management network 610 deployed as part of a public cloud computing platform 600. Here, public cloud computing platform 600 mainly includes shared services VPC 165, which includes controller 150, controller 150 configured to support a split VPC 120 ₁ To 120 to _N Peer-to-peer communication link 620 for each of ₁ To 620 _N Rather than relying on the native cloud gateway 170. Here, the controller 150 is directed to reside in the branch VPC 120 ₁ To 120 to _N Each branch gateway 122 within and maintains and manages a private IP address data store 630 for each transit gateway 142 residing within at least one transit VPC 140.

Here, as described above, communication link 640 is established between Virtual Private Network (VPN) endpoint 645 and local network 190 (operation 1), which endpoint 645 is a native construct provided as part of public cloud computing platform 600 and included as part of shared resource VPC 165. As described above, to provide secure communications, an IPSec Virtual Private Network (VPN) connection may be established such that computing device 650 operating as part of local network 190 can access controller 150 via its private IP address. Further, the VPC may be respectively branched at one or more selected branches (e.g., VPC branch 120 ₁ ) Communication links 646 and 648 are established between virtual VPN endpoints 647 and 649 and transit VPC 140.

After communication link 640 (and/or links 646/648) is established, controller 150 is started on the private subnet in shared service VPC 165 (operation 2). As previously described, the controller 150, which is an example of software, is activated and is accessible via a private IP address to assist in formulating the peer-to-peer management network 610. Thereafter, the controller 150 may be configured to create a communication link 620 ₁ To 620 _N To provide a control signal at the controller 150 and branch VPC 120 ₁ To 120 to _N A peer-to-peer connection is established between and a communication link 660 is established between at least the controller 150 and the transit VPC 140 (operation 3). Thereafter, the branch gateway 122 and the transit gateway 142 are started in the private subnetwork ₁ To 142 ₂ And they can now work. Based on the transit gateway 142 ₁ To 142 ₂ Is established as a mesh network with each branch gateway 122 communicatively coupled to each transit gateway 142 ₁ To 142 ₂ (operation 4).

VI general architecture-fourth embodiment (Multi cloud)

Referring now to fig. 7, an exemplary embodiment of a management network 700 supporting a multi-cloud network 710 utilized by an enterprise is shown. Here, the multi-cloud network 710 includes a first public cloud computing platform 720 (e.g., AWS public cloud) served by a first cloud provider and a second public cloud computing platform 730 (e.g., gu Geyun platform "GPC") served by a second cloud provider. Here, formulation of the management network associated with the first public cloud computing platform 720 is similar to that described above. One distinction associated with a multi-cloud management network focuses on the connection between the controller 150 of the shared services VPC 165 operating as part of the first public cloud computing platform 720 and the gateway associated with the second public cloud computing platform 730.

According to one embodiment of the present disclosure, a connection is established via local networks 740 and 750, wherein a communication link 760 is established between a VPN endpoint 745 and local network 740, the endpoint 745 being a native fabric provided as part of the first public cloud computing platform 720 and included as part of the shared resource VPC 165. Likewise, a communication link 770 is established between a VPN endpoint 775 and a local network 750, the endpoint 775 being a native fabric provided as part of a second public cloud computing platform (GPC). Based on the connection established between local networks 740 and 750, controller 150 may be able to support private IP address management across multiple (and different) cloud platforms, as represented by communication link 780.

Embodiments of the invention may be embodied in other specific forms without departing from the spirit of the disclosure. The described embodiments are to be considered in all respects only as illustrative and not restrictive.

Claims

1. A gateway deployed as logic within a non-transitory storage medium and communicatively coupled to a processor deployed as a cloud instance, the gateway comprising:

a management interface;

a data interface; and

routing control logic that, when executed, is configured to: (i) When the outbound traffic of the first type is forwarded from the cloud instance supported by the gateway, guiding the outbound traffic of the first type through the data interface; and (ii) directing the second type of outbound traffic via the management interface when logic within the gateway initiates the second type of outbound traffic.

2. The gateway of claim 1, wherein the management interface and the data interface are two forward interfaces configured to send and receive messages over one or more communication links.

3. The gateway of claim 1, wherein the management interface is configured to receive a second type of outbound traffic corresponding to management information from, or send the management information to, a native cloud gateway that operates as a hub of a management network that distributes the management information with private addressing.

4. A gateway as claimed in claim 3, wherein the private addressing allows the management information to be exchanged over a private Internet Protocol (IP) address assigned to each gateway and a cloud instance operating as part of a public cloud network comprising the gateway.

5. The gateway of claim 3, communicatively coupled to a controller via the native cloud gateway to receive management information including routing information maintained within a management routing table that identifies allowed routes via the management interface.

6. The gateway of claim 1, wherein the second type of outbound traffic corresponds to management information including hello messages or keep alive messages.

7. The gateway of claim 3, wherein the data interface is configured to receive a first type of outbound traffic corresponding to one or more data messages from a transit gateway or send the first type of outbound traffic corresponding to data messages to a cloud instance based on different private addresses associated with private addressing assigned to the gateway, transit gateway, and cloud instance.

8. A cloud computing platform that supports communication between components within a virtual private cloud network using private addresses, comprising:

one or more processors; and

software that, when executed by the one or more processors, comprises

(i) A controller, and

(ii) A plurality of branch virtual private cloud networks communicatively coupled to the controller, each branch virtual private cloud network including one or more branch gateways, wherein a first branch gateway of a first branch virtual private cloud network of the plurality of branch virtual private networks is configured to: (i) Routing management information via one or more native cloud gateways, the management information addressed with a private Internet Protocol (IP) address associated with a second branch gateway of a second branch virtual private cloud network; and (ii) receive management information from the controller for routing the management information to one or more cloud instances each addressed by a different private IP address.

9. The cloud computing platform of claim 8, operating as a multi-cloud computing platform, wherein a first branched virtual private cloud network is deployed within a first public cloud network and a second virtual private cloud network is deployed within a second public cloud network different from the first public cloud network.

10. The cloud computing platform of claim 9, wherein the one or more native cloud gateways comprise a native cloud gateway for a first public cloud network communicatively coupled to a native cloud gateway for a second public cloud network.

11. The cloud computing platform of claim 8, wherein the first breakout gateway comprises: (i) A data interface for the first type of outbound traffic when forwarded from the cloud instance supported by the first breakout gateway; and (ii) a management interface for the second type of outbound traffic when logic within the first branch gateway initiates the second type of outbound traffic.

12. The cloud computing platform of claim 11, wherein the management interface and the data interface are two forward interfaces of a first breakout gateway configured to send and receive messages over one or more communication links.

13. The cloud computing platform of claim 11, wherein the management interface of a first breakout gateway is configured to: (i) Receiving outbound traffic of a second type corresponding to the management information from a native cloud gateway of the one or more native cloud gateways, or (ii) sending the management information to a native cloud gateway of the one or more native cloud gateways, the native cloud gateway operating as a hub of a management network that distributes the management information using private IP addressing.

14. The cloud computing platform of claim 13, wherein the private IP addressing allows the management information to be exchanged using a private IP address assigned to each of the one or more branch gateways, and each of the one or more cloud instances operates at least as part of a first public cloud network comprising a first branch gateway.

15. The cloud computing platform of claim 13, wherein a first branch gateway is communicatively coupled to the controller via a native cloud gateway to receive management information including routing information maintained in a management routing table that identifies allowed routes via the management interface.

16. The cloud computing platform of claim 11, wherein the second type of outbound traffic corresponds to management information including hello messages or keep alive messages.

17. The cloud computing platform of claim 11, wherein the data interface of the first branch gateway is configured to receive or send a first type of outbound traffic corresponding to one or more data messages to a first transit gateway communicatively coupled to a second transit gateway configured to communicate with a second branch gateway of a second branch virtual private cloud network based on different private IP addresses associated with private IP addresses assigned to the first branch gateway, the first transit gateway, the second transit gateway, and the cloud instances.

18. A computerized method of routing management information via a gateway using private addresses, the method comprising:

determining whether outbound traffic corresponds to a first type of outbound traffic forwarded from a cloud instance supported by the gateway;

directing the first type of outbound traffic via the data interface of the gateway in response to determining that the first type of outbound traffic is being forwarded from the Yun Shili;

Determining whether outbound traffic corresponds to a second type of outbound traffic initiated by logic within the gateway; and

responsive to determining that logic within the gateway is initiating outbound traffic of a second type, the outbound traffic of the second type is directed via a management interface of the gateway.

19. The computerized method of claim 18, wherein the management interface and the data interface of the gateway are two forward interfaces configured to send and receive messages over one or more communication links.

20. The computerized method of claim 18, wherein directing the second type of outbound traffic via the management interface comprises sending the second type of outbound traffic corresponding to a native cloud gateway operating as a hub of a management network of a public cloud network and distributing the second type of outbound traffic with private addressing.

21. The computerized method of claim 20, wherein the private addressing allows for exchanging outbound traffic of a second type through a private Internet Protocol (IP) address assigned to a second gateway operating as part of a public cloud network comprising the gateway.

22. The computerized method of claim 21, wherein the second type of outbound traffic comprises a hello message or a keep alive message.