System and method for connecting virtual networks in branch sites to the cloud

Abstract

The present technology relates to controlling and managing resources in both a software-defined cloud interconnect (SDCI) provider and a cloud service provider via a single network controller, and further connecting virtual networks in branch sites to virtual networks in the cloud service provider. The network controller can perform the following operations: establishing a network gateway in the SDCI provider, establishing cross-connectivity between the network gateway in the SDCI provider and one or more clouds, grouping one or more virtual networks in the one or more clouds and one or more virtual networks in the branch sites into a tag, and establishing a connection between the one or more virtual networks in the one or more clouds and the one or more virtual networks in the branch sites using the tag.

Description

[0001] Cross Reference to Related Applications

[0002] This application claims the benefit of and priority to U.S. Non-Provisional Patent Application No. 17 / 377,315, filed July 15, 2021, which claims the benefit of and priority to U.S. Provisional Patent Application No. 63 / 172,211, filed April 8, 2021, the contents of which are incorporated by reference in their entirety. TECHNICAL FIELD

[0003] The subject matter of the present disclosure relates generally to the field of computer networking, and more specifically, to systems and methods for controlling and managing resources in both a software-defined cloud interconnect (SDCI) provider and a cloud service provider via a network controller and connecting virtual networks in branch sites to virtual networks in the cloud service provider. BACKGROUND

[0004] Enterprises have been adopting business critical business cloud applications and other cloud applications in the form of software as a service (SaaS) and infrastructure as a service (IaaS). As traditional wide area networks (WANs) could not cope with the explosive traffic accessing cloud-based applications, enterprises have turned to software-defined wide area networks (SD-WAN), a virtual WAN architecture that provides connectivity, management, and services between data centers and remote branches or cloud instances. However, as enterprises have widely adopted multi-cloud environments, managing and controlling various network providers and multiple connections between branch sites to the cloud has become complex and time-consuming. BRIEF DESCRIPTION OF DRAWINGS

[0005] Illustrative embodiments of the present application are described below with reference to the following drawings:

[0006] Figure 1 An example of a high-level network architecture is shown in accordance with some examples of the present disclosure.

[0007] Figure 2 An example of a network topology is shown in accordance with some examples of the present disclosure.

[0008] Figure 3 An example of a diagram showing the operation of a protocol for managing an overlay network is shown in accordance with some examples of the present disclosure.

[0009] Figure 4 An example diagram of an integrated workflow for establishing a site-to-site connection between a cloud and a branch site is shown in accordance with some examples of the present disclosure.

[0010] Figure 5 An example display of a dashboard for managing end-to-end connectivity is shown in accordance with some examples of the present disclosure.

[0011] Figure 6 An example display showing an interconnect global settings phase is shown in accordance with some examples of the present disclosure.

[0012] Figure 7 An example display showing a tag phase is shown in accordance with some examples of the present disclosure.

[0013] Figure 8 An example display showing a phase for creating and managing interconnect gateways is shown in accordance with some examples of the present disclosure.

[0014] Figure 9 An example display showing a phase for creating and configuring connectivity between an SDCI provider and a cloud service provider is shown in accordance with some examples of the present disclosure.

[0015] Figure 10 An example diagram showing a workflow for connecting an SDCI provider and a cloud service provider is shown in accordance with some examples of the present disclosure.

[0016] Figure 11 A flow diagram showing a method for controlling and managing resources in both an SDCI provider and a cloud service provider via a single network controller and further connecting virtual networks in branch sites to virtual networks in the cloud service provider is shown in accordance with some examples of the present disclosure.

[0017] Figure 12 An example computing system is shown, which can be, for example, any computing device capable of implementing the components of the system.

[0018] Figure 13 An example network device is shown. DETAILED DESCRIPTION

[0019] Various embodiments of the present disclosure are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustration purposes only. A person skilled in the relevant art will recognize that other components and configurations can be used without parting from the spirit and scope of the present disclosure. Accordingly, the following description and drawings are illustrative and should not be construed as limiting. Numerous specific details are described to provide a thorough understanding of the present disclosure. However, in certain instances, well-known or conventional details are not described in order to avoid obscuring the description. References to one or an embodiment in the present disclosure are references to at least one of the embodiments, and such references mean at least one of the embodiments.

[0020] References to “one embodiment,” “an embodiment,” “example embodiment,” “various embodiments,” etc., mean that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the disclosure. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are they necessarily all referring to a single, alternative embodiment plan mutually exclusive of other embodiments. Additionally, there are various features that can be exhibited by some embodiments and not by others.

[0021] In the context of the present disclosure and in the particular context of use of each term, the terms used in this specification generally have their ordinary meaning in the art. Alternative language and synonyms can be used for any one or more of the terms discussed herein, and no special significance is to be placed upon the use of particular terms in the present document unless and except when such terms are given specific meanings herein. In some instances, synonyms for certain terms are provided. Some synonyms may be rendered redundant and / or superfluous due to the statement of one or more synonyms. Use of examples, anywhere in the specification, including examples of any terms discussed herein, is illustrative only and in no way limits the scope and meaning of the disclosure or of any exemplified term. Likewise, the disclosure is not limited to the various embodiments given in this specification.

[0022] Without intended limitation of the scope of the disclosure, examples of instruments, apparatus, methods, and results related to embodiments according to the present disclosure are set forth below. Note that headings or subheadings can be used in the examples for the convenience of the reader, which in no way should limit the scope of the disclosure. Unless otherwise defined, technical and scientific terms used herein have the meaning commonly understood by one of ordinary skill in the art to which this disclosure belongs. In case of conflict, the document, including definitions, prevails.

[0023] Additional features and advantages of the disclosure will be set forth in the description that follows, and in part will be obvious from the description, or can be learned by practice of the principles hereof. The features and advantages of the disclosure will be realized and attained by the instrumentalities and combinations particularly pointed out in the appended claims. These and other features of the disclosure will become more fully apparent from the following description and appended claims, or can be learned by practice of the principles hereof as set forth in the description. It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure, as claimed.

[0024] As emerging technologies such as 5G and Internet of Things (IoT) are becoming more closely tied to the cloud, enterprises have an increasing need for the cloud to be combined with enterprise branch offices. To overcome the challenges of securely connecting to cloud deployments in SD-WAN, SDCI platforms have been developed to enable cloud interconnects to connect enterprise SD-WAN sites to the cloud. Software-defined cloud interconnect (SDCI) can provide optimized tools for directly and securely interconnecting clouds, networks, and Internet service providers. By using SDCI, users (e.g., enterprises) can control the routing, switching, and security of each connection without having to deploy separate network equipment for each tenant.

[0025] However, as enterprises widely adopt multi-cloud environments, managing and controlling various network providers and multiple connections between branch sites and the cloud becomes complex and time-consuming. In some cases, users must use multiple SDCI providers to access different portals to establish connectivity between cloud resources and the user’s on-premises (or branch) network. Therefore, there is a need for an orchestrator (e.g., network controller) that can dynamically control and manage resources in both SDCI providers and cloud service providers. There is also a strong need for an integrated workflow to configure connections between branch sites and the cloud.

[0026] The present technology includes systems, methods, and computer-readable media, etc. for addressing these issues and differences. In some examples, systems, methods, and computer-readable media are provided for using a network controller to dynamically control and manage resources in both SDCI providers and cloud service providers.

[0027] Overview

[0028] Aspects of the application are set out in the independent claims and preferred features are set out in the dependent claims. Features of one aspect can be applied to each aspect or applied to each aspect in combination with features of other aspects.

[0029] Systems, methods, and computer-readable media are provided for controlling and managing resources in both SDCI providers and cloud service providers via a network controller and connecting virtual networks in branch sites to virtual networks in cloud service providers.

[0030] According to at least one example of the technology, a network controller can establish a network gateway in an SDCI provider, establish cross-connectivity between the network gateway in the SDCI provider and one or more clouds, group one or more virtual networks in the one or more clouds and one or more virtual networks in a branch site into a tag, and establish a connection between the one or more virtual networks in the one or more clouds and the one or more virtual networks in the branch site using the tag. Further, the network controller can standardize parameters associated with the SDCI provider. These parameters that determine properties of the network gateway can include: a software image, a border gateway protocol (BGP), an autonomous system number (ASN), a size of a virtual network, and an interconnection transit color.

[0031] Further, the one or more virtual networks in the one or more clouds and the one or more virtual networks in the branch site can be grouped into the tag based on one or more characteristics associated with the one or more virtual networks in the one or more clouds and the one or more virtual networks in the branch site.

[0032] The connection between the one or more virtual networks in the one or more clouds and the one or more virtual networks in the branch site can be based on the cross-connectivity between the network gateway in the SDCI provider and the one or more clouds.

[0033] The connection between the one or more virtual networks in the one or more clouds and the one or more virtual networks in the branch site can be based on an automated BGP route configuration.

[0034] The cross-connectivity between the network gateway in the SDCI provider and the one or more clouds and the connection between the one or more virtual networks in the one or more clouds and the one or more virtual networks in the branch site can be via an application programming interface (API).

[0035] A system for establishing a site-to-site connection between a branch site and a cloud service provider can include one or more processors and at least one computer-readable storage medium storing instructions that, when executed by the one or more processors, cause the one or more processors to perform the following operations: establish a network gateway in an SDCI provider, establish cross-connectivity between the network gateway in the SDCI provider and one or more clouds, group one or more virtual networks in the one or more clouds and one or more virtual networks in a branch site into a tag, and establish a connection between the one or more virtual networks in the one or more clouds and the one or more virtual networks in the branch site using the tag.

[0036] A non-transitory computer-readable storage medium having instructions stored therein that, when executed by one or more processors, can cause the one or more processors to establish a network gateway in an SDCI provider, establish cross-connectivity between the network gateway in the SDCI provider and one or more clouds, group one or more virtual networks in the one or more clouds and one or more virtual networks in a branch site into a tag, and establish a connection between the one or more virtual networks in the one or more clouds and the one or more virtual networks in the branch site using the tag.

[0037] Description

[0038] Figure 1 An example of a network architecture 100 for implementing aspects of the present technology is shown. An example of an implementation of the network architecture 100 is an SD-WAN architecture. However, one of ordinary skill in the art will appreciate that there can be more or fewer components in similar or alternative configurations for the network architecture 100 and any system discussed in the present disclosure. For brevity and clarity, illustrations and examples are provided in the present disclosure. Other embodiments can include different numbers and / or types of elements, but one of ordinary skill in the art will recognize that such variations do not depart from the scope of the present disclosure.

[0039] In this example, the network architecture 100 can include an orchestration plane 102, a management plane 120, a control plane 130, and a data plane 140. The orchestration plane 102 can facilitate automatic on-boarding of edge network devices 142 (e.g., switches, routers, etc.) in an overlay network. The orchestration plane 102 can include one or more physical or virtual network orchestrator devices 104. The network orchestrator device(s) 104 can perform initial authentication of the edge network devices 142 and orchestrate connectivity between devices of the control plane 130 and the data plane 140. In some embodiments, the network orchestrator device(s) 104 can also enable communication of devices that are behind Network Address Translation (NAT). In some embodiments, the physical or virtual The SD-WAN vBond device can operate as the network orchestrator device(s) 104.

[0040] The management plane 120 can be responsible for central configuration and monitoring of the network. The management plane 120 can include one or more physical or virtual network management devices 122. In some embodiments, the network management device(s) 122 can provide centralized management of the network via a graphical user interface to enable users to monitor, configure, and maintain the edge network devices 142 and links (e.g., the Internet transport network 160, the MPLS network 162, the 4G / LTE network 164) in the underlay network and the overlay network. The network management device(s) 122 can support multi-tenancy and enable centralized management of logically isolated networks that are associated with different entities (e.g., enterprises, departments within an enterprise, groups within a department, etc.). Alternatively or additionally, the network management device(s) 122 can be a dedicated network management system for a single entity. In some embodiments, the physical or virtual network management device(s) 122 can be implemented as a software-defined wide-area network (SD-WAN) vManage device. The SD-WAN vManage device can operate as the network management device(s) 122.

[0041] The control plane 130 can build and maintain a network topology and decide where traffic flows. The control plane 130 can include one or more physical or virtual network controller devices 132. The network controller device(s) 132 can establish secure connections to each of the network devices 142 and distribute routing and policy information via a control plane protocol (e.g., an overlay management protocol (OMP) (discussed in further detail below), open shortest path first (OSPF), intermediate system to intermediate system (IS-IS), border gateway protocol (BGP), protocol independent multicast (PIM), Internet Group Management Protocol (IGMP), Internet Control Message Protocol (ICMP), Address Resolution Protocol (ARP), bidirectional forwarding detection (BFD), link aggregation control protocol (LACP), etc.). In some embodiments, the network controller device(s) 132 can operate as a route reflector. The network controller device(s) 132 can also orchestrate secure connectivity in the data plane 140 between two or more edge network devices 142. For example, in some embodiments, the network controller device(s) 132 can distribute encryption key information between the network devices 142. This can allow the network to support secure network protocols or applications (e.g., Internet Protocol Security (IPSec), Transport Layer Security (TLS), Secure Shell (SSH), etc.) without the need for Internet Key Exchange (IKE) and enable scalability of the network. In some embodiments, the physical or virtual network controller device(s) 132 can be implemented as a software-defined wide-area network (SD-WAN) vSmart controller. The SD-WAN vSmart controller can operate as the network controller device(s) 132.

[0042] The data plane 140 can be responsible for forwarding packets based on decisions from the control plane 130. The data plane 140 can include edge network devices 142, which can be physical or virtual network devices. The edge network devices 142 can operate at the edge of various network environments of an organization, such as in one or more data center or hosting centers 150, campus networks 152, branch office networks 154, home office networks 154, etc., or in the cloud (e.g., Infrastructure as a Service (IaaS), Platform as a Service (PaaS), SaaS, and other cloud service provider networks). The edge network devices 142 can provide secure data plane connectivity between sites over one or more WAN transport, such as via one or more Internet transport networks 160 (e.g., Digital Subscriber Line (DSL), cable, etc.), MPLS networks 162 (or other private packet-switched networks (e.g., Metro Ethernet, Frame Relay, Asynchronous Transfer Mode (ATM), etc.), mobile networks 164 (e.g., 3G, 4G / LTE, 5G, etc.), or other WAN technologies (e.g., Synchronous Optical Networking (SONET), Synchronous Digital Hierarchy (SDH), Dense Wavelength Division Multiplexing (DWDM), or other fiber technologies; leased lines (e.g., T1 / E1, T3 / E3, etc.); Public Switched Telephone Network (PSTN), or other private circuit-switched networks; Very Small Aperture Terminal (VSAT) or other satellite networks; etc.). The edge network devices 142 can be responsible for traffic forwarding, security, encryption, Quality of Service (QoS), and routing (e.g., BGP, OSPF, etc.), among other tasks. In some embodiments, the physical or virtual network devices of the edge network devices 142 can be implemented as SD-WAN vEdge routers. The SD-WAN vEdge routers can operate as the edge network devices 142.

[0043] Figure 2An example of a network topology 200 is shown for illustrating aspects of the network architecture 100. The network topology 200 can include a management network 202, a pair of network sites 204A and 204B (collectively, 204) (e.g., data center(s) 150, campus network(s) 152, branch office network(s) 154, home office network(s) 156, cloud service provider network(s), etc.), and a pair of Internet transport networks 160A and 160B (collectively, 160). The management network 202 can include network orchestrator device(s) 104, network management device(s) 122, and network controller device(s) 132. Although the management network 202 is shown as a single network in this example, one of ordinary skill in the art will appreciate that each element of the management network 202 can be distributed across any number of networks and / or co-located with the sites 204. In this example, each element of the management network 202 can be reached through transport network 160A or 160B. Further, in other examples, the network topology 200 can include different numbers of network sites, transport networks, devices, and / or networks / components shown. Figure 2

[0044] Each site can include one or more endpoints 206 connected to one or more site network devices 208. Endpoints 206 can include general-purpose computing devices (e.g., servers, workstations, desktop computers, etc.), mobile computing devices (e.g., laptops, tablets, mobile phones, etc.), wearable devices (e.g., watches, glasses or other head-mounted displays (HMDs), earpiece devices, etc.), and the like. Endpoints 206 can also include Internet of Things (IoT) devices or appliances, such as, for example, agricultural appliances (e.g., livestock tracking and management systems, watering devices, unmanned aerial vehicles (UAVs), etc.); networked automobiles and other vehicles; smart home sensors and devices (e.g., alarm systems, security cameras, lighting, appliances, media players, HVAC appliances, utility meters, windows, automatic doors, doorbells, locks, etc.); office appliances (e.g., desk phones, copiers, fax machines, etc.); medical devices (e.g., pacemakers, biosensors, medical appliances, etc.); industrial appliances (e.g., robots, factory machinery, construction appliances, industrial sensors, etc.); retail appliances (e.g., vending machines, point-of-sale (POS) devices, radio-frequency identification (RFID) tags, etc.); smart city devices (e.g., streetlights, parking meters, waste management sensors, etc.); transportation and logistics appliances (e.g., turnstiles, rental car trackers, navigation devices, inventory monitors, etc.); and the like.

[0045] ​Site network devices 208 can include physical or virtual switches, routers, and other network devices. Although in this example, site 204A is shown as including a pair of site network devices, and site 204B is shown as including a single site network device, site network devices 208 can include any number of network devices in any network topology, including multi-tier (e.g., core tier, distribution tier, and access tier), spine-leaf, mesh, tree, bus, hub and spoke, etc. For example, in some embodiments, one or more data center networks can implement Application Centric Infrastructure (ACI) architecture and / or one or more campus networks can implement Software-Defined Access (SD Access or SDA) architecture. Site network devices 208 can connect endpoints 206 to one or more edge network devices 142, and edge network devices 142 can be used to connect directly to transport networks 160.

[0046] In some embodiments, “colors” can be used to identify separate WAN transport networks, and different WAN transport networks can be assigned different colors (e.g., mpls, private1, commercial internet, metro ethernet, lte, etc.). In this example, network topology 200 can use a color referred to as “commercial internet” for internet transport network 160A, and a color referred to as “public internet” for internet transport network 160B.

[0047] In some embodiments, each edge network device 208 can form a Datagram Transport Layer Security (DTLS) or TLS control connection to network controller device(s) 132, and connect to any network controller device 132 through each transport network 160. In some embodiments, edge network devices 142 can also securely connect to edge network devices in other sites via IPSec tunnels. In some embodiments, the BFD protocol can be used in each of these tunnels to detect loss, latency, jitter, and path failure.

[0048] On edge network devices 142, colors can be used to help identify or distinguish individual WAN transport tunnels (e.g., the same color cannot be used twice on a single edge network device). The colors themselves also have significance. For example, metro-ethernet, mpls, and private 1, private 2, private 3, private 4, private 5, and private 6 colors can be considered private colors, which can be used for private networks or where there is no NAT addressing at the transport IP endpoint (e.g., because there can be no NAT between two endpoints of the same color). When edge network devices 142 use private colors, they can attempt to use local, private, underlay IP addresses to construct IPSec tunnels to other edge network devices. Public colors can include 3g, biz, internet, blue, bronze, custom 1, custom 2, custom 3, default, gold, green, lte, public internet, red, and silver. Public colors can be used by edge network devices 142 to construct tunnels to NATed IP addresses (if NAT is involved). If edge network devices 142 use private colors and need NAT to communicate with other private colors, an operator setting in the configuration can indicate whether edge network devices 142 are to use private IP addresses or public IP addresses. When one or both private colors use NAT, both private colors can establish sessions by using this setting.

[0049] Figure 3 An example of a diagram 300 showing the operation of an OMP, which can be used in some embodiments to manage the overlay layer of a network (e.g., network architecture 100), is shown. In this example, OMP messages 302A and 302B (collectively, 302) can be transmitted back and forth between network controller device 132 and edge network devices 142A and 142B, respectively, where control plane information (e.g., routing prefixes, next-hop routes, encryption keys, policy information, etc.) can be exchanged over respective secure DTLS or TLS connections 304A and 304B. Network controller device 132 can operate similarly to a route reflector. For example, network controller device 132 can receive routes from edge network devices 142, process and apply any policies to them, and advertise the routes to other edge network devices 142 in the overlay layer. If there are no defined policies, edge network devices 142 can work in a manner similar to a full mesh topology, in which each edge network device 142 can be directly connected to another edge network device 142 at another site, and receive complete routing information from each site.

[0050] OMP can advertise three types of routes:

[0051] • OMP routes correspond to prefixes learned from the local site or service side of edge network device 142. Prefixes can be initiated as static routes or connection routes, or they can be initiated from protocols such as OSPF or BGP and reassigned to OMPs so that they can be transmitted across the overlay layer. OMP routes can advertise attributes such as Transport Location (TLOC) information (which can be similar to a BGP next-hop IP address) and other attributes such as origin, initiator, preference, site identifier, label, and Virtual Private Network (VPN). If the TLOC pointed to by the OMP route is active, the OMP route can be installed in the forwarding table.

[0052] A TLOC route can correspond to a logical tunnel endpoint connected to an edge network device 142 in the transport network 160. In some embodiments, a TLOC route can be uniquely identified and represented by a triple (including IP address, link color, and encapsulation (e.g., Generic Routing Encapsulation (GRE), IPSec, etc.)). In addition to the system IP address, color, and encapsulation, a TLOC route can also convey attributes such as TLOC private and public IP addresses, carrier, preferences, site identifier, label, and weight. In some embodiments, a TLOC can be active on a specific edge network device 142 when an active BFD session is associated with it.

[0053] • Service routes, which can represent services (e.g., firewalls, distributed denial-of-service (DDoS) mitigators, load balancers, intrusion prevention systems (IPS), intrusion detection systems (IDS), WAN optimizers, etc.) that can connect to the local site of edge network device 142 and be accessible to other sites for service insertion. Additionally, these routes may include VPNs; VPN labels can be sent in update type to inform network controller device 132 which VPNs are being served at remote sites.

[0054] exist Figure 3 In the example, OMP is shown running on a DTLS / TLS tunnel 304 established between edge network device 142 and network controller device 132. Furthermore, Figure 300 illustrates an IPSec tunnel 306A established between TLOC 308A and TLOC 308C via WAN transport network 160A, and an IPSec tunnel 306B established between TLOC 308B and TLOC 308D via WAN transport network 160B. Once IPSec tunnels 306A and 306B are established, BFD can be enabled on each of them.

[0055] Figure 4 An example diagram illustrating an integrated workflow 400 for establishing site-to-cloud connectivity between a cloud and a branch site using a network controller is shown, in accordance with some examples of the present disclosure. In some examples, the integrated workflow 400 includes one or more cloud service providers 402A, 402B, and 402C (collectively, 402), an SDWAN gateway 406 at an SDCI provider 404, an access provider 408, a virtual network 412 (e.g., VRF) at a branch site 410, and an SDWAN controller 414, where connectivity between the cloud service providers 402, the SDWAN gateway 406, and the SDWAN controller 414 is established via an API 416.

[0056] In some cases, examples of virtual networks in the cloud service providers 402 can include, but are not limited to, a virtual private cloud (VPC) hosted by Amazon Cloud or Google Cloud, a virtual network (VNet) hosted by Azure, or any type of virtual network that can be offered by a cloud service provider.

[0057] Further, in some examples, examples of virtual networks at the branch site 410 can include, but are not limited to, a virtual routing and forwarding (VRF) or any other virtual routing domain / network.

[0058] The SDWAN controller 414 can dynamically control and manage resources of the cloud service providers 402 and the SDCI provider 404 in a single integrated workflow 400 to connect one or more virtual networks (e.g., VPCs or VNet) in the cloud service providers 402 with the virtual network 412 (e.g., VRF) at the branch site 410.

[0059] Further, the integrated workflow 400 can automatically perform BGP routing configuration to propagate routes or prefixes, allowing for communication between endpoints and / or devices in the branch site 410, the SDCI provider 404, and / or the one or more cloud service providers 402, and / or between endpoints and / or devices in one or more virtual networks or routing domains (e.g., VPCs, VNet, VRF, etc.) hosted by the branch site 410 and / or the one or more cloud service providers 402.

[0060] In some cases, the SDWAN controller 414 can control and manage one network path from the branch site 410 to an edge router instantiated in the SDCI provider 404, and further to a virtual network in the cloud service provider 402.

[0061] Figure 5An example display of a dashboard 500 for managing end-to-end connectivity according to embodiments is shown. In some embodiments, the dashboard 500 can be an initial page that provides an overview of the management of the network controller (e.g., SDWAN controller 414) in Figure 4 and the control system. For example, the dashboard 500 can provide an overview of the entire system, including all connections, gateways, SDCI providers, and cloud service providers.

[0062] In some examples, the cloud tab 502 provides a list of cloud service providers (e.g., cloud service providers 402) in Figure 4 . In addition, the interconnect tab 504 provides a list of available interconnect providers (e.g., SDCI providers 404) in Figure 4 . For a particular SDCI provider, the initial page of the dashboard 500 can provide details about the SDCI provider, such as region, account name, interconnect gateway name, devices, connections, last resource status, account ID, interconnect gateway ID, or last update time.

[0063] In some examples, the dashboard 500 also includes a setup phase 506, a discovery phase 508, a management phase 510, and an intent management phase 512. Details about each phase are discussed further below with respect to Figure 6 to Figure 9 .

[0064] In some cases, the setup phase 506 provides interconnect account details, such as an interconnect provider (e.g., SDCI providers 404) in Figure 4 , account name, description, username, and / or password. In some examples, the network controller (e.g., SDWAN controller 414) in Figure 4 can internally make API calls (i.e., calls to a server using an API) to the interconnect provider (e.g., SDCI providers 404) in Figure 4 to validate the credentials of the interconnect account details.

[0065] Each interconnect provider can have one or more different types of APIs. The network controller (e.g., SDWAN controller 414) in Figure 4 can aggregate data related to each type of API into a common type within solution, such that multiple APIs can be managed by a single network controller regardless of type.

[0066] In some embodiments, the setup phase 506 can provide various locations, regions, or partner ports available for each SDCI provider associated with the user’s account. The interconnect gateway (e.g., interconnect gateway 412) in Figure 4The SDWAN gateway (406) can be enabled to establish connections at these available locations.

[0067] Figure 6 An example display of an interconnect global setup phase 600 according to some examples of this disclosure is shown. In some examples, the interconnect global setup phase 600 includes deployment attributes for an interconnect provider 602, such as a software image 604, an instance size 606, an interconnect adapter color 608, and a BGP ASN 610. For example, the software image 604 includes features that can be provided by an interconnect provider (e.g., such as...). Figure 4 The list of available SDWAN images for SDWAN cloud service routers from SDCI provider 404 is shown. If custom settings are not selected, software image 604 can be used to retrieve the interconnect gateway (e.g., such as...). Figure 4 The SDWAN gateway 406 shown is the default option. Additionally, instance size 606 can include a list of virtual machine (VM) instance attributes, such as small, medium, and large. Users can select instance size 606 based on the amount of virtual central processing units (vCPUs), memory, and bandwidth. Furthermore, interconnect transition color 608 is the SDWAN tunnel color, which can be used with interconnect providers (e.g., such as...) Figure 4 The SDCI provider 404 (as shown) provides a site-to-site connection between two interconnect gateways. Bidirectional Forward Direction (BFD) sessions can be formed on a specific tunnel interface. Furthermore, BGP ASN 610 is configured on the interconnect gateway (e.g., as shown in the diagram). Figure 4 The Autonomous System number on the SDWAN gateway (406) shown is used as the default option when providing connectivity to the cloud.

[0068] Such global settings simplify future deployment and use with a specific interconnect provider when a gateway is instantiated. In some cases, global settings can be overwritten when individual gateways need to be tweaked. Furthermore, network controllers (e.g., Figure 4 The SDWAN controller (414) can apply common parameters to each SDCI provider associated with the same account.

[0069] Figure 4 The example shown is 700, illustrating the labeling phase based on some examples. In some cases, during the discovery phase (e.g., Figure 7 In the discovery phase 508), the cloud (e.g., Figure 5Parameters of resources on a cloud service provider (402) can be determined. These parameters may include, for example, cloud region, account name, host virtual network (e.g., VPC, etc.) name, host virtual network (e.g., VPC, etc.) label, interconnection status (e.g., enabled or disabled), account ID, and / or host virtual network (e.g., VPC) identifier (ID).

[0070] In some examples, one of the parameters that can be determined during the discovery phase is a concept called a "label." For example... Figure 4 As shown, the labeling phase 700 includes: label name 702, region 704, selected virtual network (e.g., VPC) 706, options for enabling interconnect connectivity 708, etc. Multiple virtual networks can be grouped into "labels". Labels allow for the interconnection of different virtual networks and the application of global policies; different virtual networks may have different requirements and / or constraints imposed by different cloud service providers. For example, multiple virtual networks (e.g., VPC, VNet, VRF) can be labeled into a logical group. When from a branch site (e.g., Figure 7 When the connection from the branch site (410) to the tag is enabled, this connection allows traffic to flow from the branch site to the tag, which includes multiple virtual networks. Specifically, tags across different regions can simplify the configuration of interconnections between virtual networks in the cloud and branch sites.

[0071] In some cases, virtual networks (e.g., VRFs) in a branch site can be grouped into "labels" in a similar manner. For example, multiple virtual networks (e.g., VRFs) in a branch site can be labeled into logical groups, allowing traffic to flow from the label in the branch site to the cloud service provider via a connection between the label in the branch site and the cloud service provider. In some examples, one or more labels corresponding to one or more virtual networks in a branch site can be mapped to and / or associated with one or more labels of one or more virtual networks on one or more cloud service providers. In some cases, one or more virtual networks in a branch site and one or more virtual networks on one or more cloud service providers can be grouped into the same label.

[0072] Figure 4 An example of stage 800 for creating and managing interconnected gateways, according to some examples of this disclosure, is shown. In some examples, the network controller (e.g., Figure 8 The virtual network 412 in the SDCI (e.g., ) can manage interconnect gateways, for example, in an SDCI provider (e.g., Figure 4 Routers enabled by the SDCI provider (404). For example, the network controller can be configured with the SDCI provider (e.g., [Provider Name]). Figure 4 Establish an interconnection gateway in the SDCI provider (404) (e.g.,Figure 4 SD-WAN gateway 406 in the SDCI provider 404) to establish cross-connectivity between the interconnection gateway and one or more clouds (e.g., virtual networks in the cloud service provider 402) in the SDCI provider. Figure 4

[0073] In some examples, creating and managing the interconnection gateway at stage 800 includes determining one or more parameters for a particular interconnection provider 802, including: a gateway name 804, a description 806, an account name 808, a location 810, a universally unique identifier (UUID) 812, and settings 814 (e.g., default or custom). In some examples, the UUID 812 can be a chassis ID that can be selected by a user.

[0074] Further, in some cases, once all parameters are determined, an API (e.g., API 416 in Figure 4 ) can be invoked to create and configure an SDCI gateway (e.g., SD-WAN gateway 406 in Figure 4 ) within the SDCI location (e.g., SDCI provider 404 in Figure 4 ). The pane 816 on the left side of stage 800 provides a graphical representation of creating and managing the interconnection gateway. For example, the pane 816 can visualize connectivity between the interconnection gateway and virtual networks in the cloud service provider, as well as connectivity between branch sites and the cloud service provider. In some examples, the pane 816 can automatically populate the visualization of connectivity between the interconnection gateway and virtual networks in the cloud service provider, as well as the visualization of connectivity between branch sites and the cloud service provider, based on configuration information.

[0075] Figure 4 An example display of stage 900 for creating and configuring connectivity between an SDCI provider and a cloud service provider is shown, in accordance with some examples of the present disclosure. In some examples, stage 900 for creating and configuring connectivity between an SDCI provider (e.g., SDCI provider 404 in Figure 9 ) and a cloud service provider (e.g., cloud service provider 402 in Figure 4 ) includes: a virtual interface (VIF) type 902, a location 904, a bandwidth 906, a direct connect gateway 908, settings 910, segments 912 (e.g., VPNs or VRFs), attachments 914, or virtual network (e.g., VPC) tags 916. Segments 912 refer to multiple segments from a branch site to a particular cloud resource. In some examples, an SD-WAN design can segment a routing table based on using VPNs or any other tunneling protocol. For example, segment 300 indicates that a user has set up VPN 300 on the SDWAN router at the branch site, which also refers to the size of traffic allowed to reach a particular cloud resource. ​

[0076] In some cases, each SDCI provider has an entry point into the cloud service provider, which has different speeds, functionality, etc., that can be used for a particular location or region.

[0077] In some examples, the connection pane 918 can automatically populate and visualize a logical representation of connections from branch sites to cloud service providers and a logical representation of cross-connectivity between network gateways in the SDCI provider and the cloud service provider. In some examples, the individual connections can be visualized separately for each gateway.

[0078] Figure 4 An example diagram of a workflow 1000 of a user / operator 1002 connecting SDCI providers 1006 and cloud service providers 1008 via an SDWAN controller 1004 (e.g., Cisco vManage) is shown in accordance with some examples of the present disclosure. Although Figure 10 The workflow 1000 in FIG. 10 involves a single connectivity with a single API call, multiple connectivity can also be managed and controlled in a similar manner as described in the workflow 1000.

[0079] Since a single network controller (e.g., the SDWAN controller 1004) can control and / or manage the entire system including resources in the SDCI providers, the cloud service providers, and the branch sites, the steps for configuring multiple connections within the system can be simplified. In some examples, at step 1016, the SDCI provider 1006 can create a site-to-site connection (e.g., a cross-connection). A layer 2 direct connection from an interconnect gateway (e.g., the connectivity gateway 1012) to a cloud ingress or another interconnect gateway can be referred to as a virtual cross-connection (VXC). Based on the creation of the VXC and VXC response, the underlay within the SDCI provider fabric can be established.

[0080] In some cases, a virtual interface can be used to connect the SDWAN router 1010 in the SDCI provider 1006 to the connectivity gateway 1012 in the cloud service provider 1008. Once the virtual network interface (VIF) has been attached to the connectivity gateway 1012 in the cloud service provider 1008, a BGP session can be established between the interconnect gateway in the SDCI provider 404 and the connectivity gateway 1012. This establishes the underlay connectivity from the interconnect gateway to the connectivity gateway 1012 in the cloud service provider 1008 via the SDCI fabric. The virtual network (e.g., VPC 1014 or VNet) in the cloud service provider 1008 is associated with the necessary cloud service provider gateway fabric (e.g., Transit Gateway / Virtual Private Gateway in AWS, Express Route Gateway / Virtual Network Gateway in Azure) based on the type of connection (private, public, or transit). Additionally, the interconnect gateway can be associated and connected to the connectivity gateway 1012 to which the VIF has been attached. The SDWAN controller 1004 can manage and configure the routing table and prefix advertisement to and from the virtual network (e.g., VPC 1014 or VNet) in the cloud service provider 1008.

[0081] In some examples, at step 1018, the SDWAN controller 1004 can create the cloud connectivity based on the response from the cloud service provider 1008 regarding the resources available for connection in the cloud service provider 1008.

[0082] In some cases, at step 1020, the SDWAN controller 1004 can configure a virtual network (e.g., VRF) on the SDWAN router 1010 in the SDCI provider 1006. Once all connections are established and the configuration is verified, the SDWAN controller 1004 can provide the status of each connection within the system.

[0083] Figure 10 A flow diagram illustrating a method 1100 for controlling and managing resources in both an SDCI provider and a cloud service provider and further connecting a virtual network in a branch site to a virtual network in a cloud service provider via a single network controller, in accordance with some examples of the present disclosure, is shown.

[0084] Although the example method 1100 depicts a particular order of operations, this order can be altered in ways that do not depart from the scope of the present disclosure. For example, some operations depicted can be performed in parallel or in a different order that does not materially affect the functioning of the method 1100. In other examples, different components of an example device or system implementing the method 1100 can perform functions substantially simultaneously or in a particular order.

[0085] In some examples, at step 1110, the network controller can establish a network gateway in the SDCI provider. For example, Figure 11 The SDWAN controller 414 in the SDCI provider 404 can establish a network gateway in the SDCI provider 404. Figure 4

[0086] In some cases, at step 1120, the network controller can establish cross-connectivity between the network gateway in the SDCI provider and one or more clouds. For example, the SDWAN controller 414 can establish cross-connectivity between the SDWAN gateway 406 in the SDCI provider 404 and one or more virtual networks (e.g., VPCs, Vnets, etc.) in the cloud service providers 402, as shown in Figure 4

[0087] Further, the connectivity between the network gateway in the SDCI provider and one or more clouds can be established via an API. For example, the connectivity between the SDWAN gateway 406 and one or more virtual networks (e.g., VPCs or Vnets) in the cloud service providers 402 can be established via the API 416, as shown in Figure 4

[0088] In some examples, at step 1130, the network controller can group one or more virtual networks in the one or more clouds and one or more virtual networks in the branch site into a tag. For example, the SDWAN controller 414 can group one or more virtual networks (e.g., VPCs or Vnets) in the cloud service providers 402 and one or more virtual networks 412 (e.g., VRFs) in the branch site 410 into a tag, as shown in Figure 4 In some cases, this grouping of tags can be based on one or more characteristics associated with the one or more virtual networks in the one or more clouds and the one or more virtual networks in the branch site. For example, the virtual networks can be grouped into a tag based on characteristics such as region, account, application, or proximity to a connectivity gateway.

[0089] In some embodiments, at step 1140, the network controller can use the tag to establish connectivity between the one or more virtual networks in the one or more clouds and the one or more virtual networks in the branch site. For example, the SDWAN controller 414 can establish connectivity between one or more virtual networks (e.g., VPCs or Vnets) in the cloud service providers 402 and virtual networks 412 (e.g., VRFs) in the branch site 410, as shown in Figure 4 ​​​The connections between the one or more virtual networks in the one or more clouds and the one or more virtual networks in the branch site are based on SDCI provider in some cases. For example, the connections between the one or more virtual networks (e.g., VPCs or Vnets) in the cloud service provider 402 and the virtual network 412 (e.g., VRF) in the branch site 410 can be based on cross-connectivity between the SDWAN gateway 406 in the SDCI provider 404 and the one or more virtual networks (e.g., VPCs or Vnets) in the cloud service provider 402, as Figure 4 illustrated.

[0090] Further, in some examples, the connectivity between the one or more virtual networks in the one or more clouds and the one or more virtual networks in the branch site is based on automated BGP routing configuration. For example, the connections between the one or more virtual networks (e.g., VPCs or Vnets) in the cloud service provider 402 and the virtual network 412 (e.g., VRF) in the branch site 410 can be based on automated BGP routing configuration.

[0091] In some examples, the connections between the one or more virtual networks in the one or more clouds and the one or more virtual networks in the branch site can be established via an API. For example, the connections between the one or more virtual networks (e.g., VPCs or Vnets) in the cloud service provider 402 and the virtual network 412 in the branch site 410 can be established via the API 416.

[0092] In some examples, the network controller can standardize one or more parameters associated with the SDCI provider. For example, Figure 4 The SDWAN controller 414 in the SDCI provider 404 can standardize one or more parameters associated with the SDCI provider 404. These parameters can determine the properties of the network gateway (e.g., the SDWAN gateway 406) in the SDCI provider 404. Some examples of the parameters can include: a software image, a BGP autonomous system number (ASN), a size of a virtual network, an interconnection transit color, etc. Figure 4

[0093] In some examples, during gateway creation, once global settings are defined, a user does not have to configure parameters for each individual interconnection gateway. For example, the network controller (e.g., the SDWAN controller 414 as Figure 4 illustrated) can automatically apply these settings during interconnection gateway instantiation.

[0094] ​In some cases, multiple SDCI providers can provide different methods to create connections. While some SDCI providers can specify primary and secondary connections in the same flow, in some examples according to the present disclosure, independent or redundant connections can be allowed through a workflow. When multiple connections are enabled between a given interconnection gateway and different cloud service providers, the process of BGP ASN assignment and IP pool addressing can be automated.

[0095] Figure 12 An example computing system 1200 is shown, including components in electrical communication with one another using a connection 1205 over which one or more aspects of the present disclosure can be implemented. Connection 1205 can be a physical connection via a bus, or a direct connection in a chipset architecture, for example. Connection 1205 can also be virtual, networking connection, or a logical connection.

[0096] In some embodiments, computing system 1200 is a distributed system in which the functions described in this disclosure can be distributed within a data center, multiple data centers, a peer network, etc. In some embodiments, one or more of the described system components represent a number of such components, each performing some or all of the functions attributed to the component. In some embodiments, components can be physical or virtual devices.

[0097] Example system 1200 includes at least one processing unit (CPU or processor) 1210 and connection 1205 that couples various system components including the system memory to the processor 1210. The computing system 1200 can include a cache of high-speed memory connected directly with the processor 1210, close to the processor 1210, or integrated within the processor 1210.

[0098] The processor 1210 can include any general purpose processor and a hardware service or software service (e.g., services 1232, 1234, and 1236 stored in storage device 1230) configured to control the processor 1210 as well as a specific purpose processor in which the software instructions are incorporated into the actual processor design. A processor 1210 can essentially be a completely self-contained computing system, containing multiple cores or processors, a bus, memory controller, and cache, etc. A multi-core processor can be symmetric or asymmetric.

[0099] To enable user interaction, the computing system 1200 includes an input device 1245, which can represent any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech and the like. The computing system 1200 can also include output devices 1235, which can be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems can enable a user to provide multiple types of input to communicate with the computing system 1200. The computing system 1200 can include communication interface 1240, which can generally govern and manage the customer's input and system output. There is no restriction on operating on any particular hardware arrangement and therefore the basic features here can easily be substituted for improved hardware or firmware arrangement as can be desired or

[0100] The storage device 1230 is a non-transitory memory and can be a hard disk or other types of computer readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, tapes etc. of random access memory (RAM), read only memory (ROM), and / or some combination of these.

[0101] The storage device 1230 can include software services, servers, services, and the like that, when code defining such software is executed by the processor 1210, cause the system to perform a function. In some embodiments, a hardware service that performs a particular function can include the software component stored in a computer-readable medium that, in operation, facilitates the hardware component in performing that function.

[0102] Figure 13 An example network device 1300 suitable for performing switching, routing, load balancing, and other networking operations is shown. The network device 1300 includes a central processing unit (CPU) 1304, interfaces 1302, and a bus 1310 (e.g., a PCI bus). When acting under the control of appropriate software or firmware, the CPU 1304 is responsible for executing software programs such as packet management, error detection, and / or routing functions of the network device 1300. The CPU 1304 can also be responsible for

[0103] Interfaces 1302 are typically provided as modular interface cards (sometimes called "line cards"), which can be inserted in a slot. Often, they control the sending and receiving of data packets on the network and sometimes support other peripherals used with the network device 1300. Among the types of interfaces that can be provided are Ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, and the like. In addition, various very high-speed interfaces can be provided such as fast token ring interfaces, wireless interfaces, Ethernet interfaces, Gigabit Ethernet interfaces, ATM interfaces, HSSI interfaces, POS interfaces, FDDl interfaces, WIFI interfaces, 3G / 4G / 5G cellular interfaces, CAN bus, LoRA, and the like. Generally, these interfaces can include ports appropriate for communication with the appropriate medium. In some

[0104] Although Figure 13 The illustrated system is one particular network device of the present technology, but it is by no means the only network device architecture on which the present technology can be implemented. For example, architectures often use a single processor with components offloaded to that processor for communication as well as routing computation, and the like. Moreover, other types of interfaces and media can be used with the network device 1300.

[0105] Regardless of the network device's configuration, it can employ one or more memories or memory modules (including memory 1306) configured to store program instructions and data for the general

[0106] The network device 1300 can also include a special-purpose integrated circuit (ASIC) that can be configured to perform routing and / or switching operations. The ASIC can communicate with other components of the network device 1300 via the bus 1310 to exchange data and signals and coordinate the various types of operations of the network device 1300, such as routing, switching, and / or data storage operations.

[0107] In summary, the present technology aims to control and manage resources in both a software-defined cloud interconnect (SDCI) provider and a cloud service provider via a single network controller, and further connect virtual networks in branch sites to virtual networks in the cloud service provider. The network controller can perform the following operations: establish a network gateway in the SDCI provider, establish cross-connectivity between the network gateway in the SDCI provider and one or more clouds, group one or more virtual networks in the one or more clouds and one or more virtual networks in the branch sites into a tag, and establish a connection between the one or more virtual networks in the one or more clouds and the one or more virtual networks in the branch sites using the tag.

[0108] For clarity, in some instances, the present technology can be presented as including separate functional blocks including devices, device components, steps, or routines in methods implemented in software or a combination of hardware and software.

[0109] Any of the steps, operations, functions, or processes described herein can be performed or implemented by hardware and software services or combinations of services, alone or in combination with other devices. In some embodiments, a service can be software that resides in a memory of a client device and / or one or more servers of a content management system and can perform one or more functions when a processor executes software associated with the service. In some embodiments, a service is a program or collection of programs that performs a particular function. In some embodiments, a service can be considered a server. The memory can be a non-transitory computer-readable medium.

[0110] In some embodiments, computer-readable storage devices, media, and memories can include cables or wireless signals that include bitstreams and the like. However, when referred to, non-transitory computer-readable storage media expressly excludes media such as energy, carrier signals, electromagnetic waves, and signals per se.

[0111] Methods according to the above-described examples can be implemented using computer-executable instructions, which are stored or otherwise available at the computer-readable media. Such instructions can include, for example, instructions and data which cause or otherwise configure a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Portions of computer resources used can be accessible via a network. The computer executable instructions can be, for example, binaries, intermediate format instructions such as assembly language, firmware, or microcode, or even source code. Examples of computer-readable media that can be used to store instructions, information used, and / or created during methods according to described examples include magnetic or optical disks, solid state memory devices, flash memory, USB devices provided with non-volatile memory, networked storage devices, and the like.

[0112] Devices implementing methods according to these disclosures can include hardware, firmware and / or software, and can take any of a variety of form factors. Typical examples of such form factors include servers, laptops, smart phones, small form factor personal computers, personal digital assistants, and other devices. Functionality described herein can also be implemented in peripherals or add-on

[0113] These instructions, media for conveying same, computing resources for executing same, and other structures for supporting such computing resources are means for providing the functionality described in these disclosures.

[0114] Although the use of various examples and other information to explain aspects within the scope of the appended claims is not intended in a limiting sense, but is intended to be illustrative of the various ways to make and use such aspects, those skilled in the art will be able to devise their own implementation details and alternatives to the examples without the exercise of inventive faculty. Further, while a particular feature or aspect can have been disclosed with respect to only one of various examples, such feature or aspect can be combined with one or more other features or aspects of the various examples as can be desired and advantageous. Additionally, while features can have been disclosed with respect to a particular example, such features can be combined with one or more other features of other examples as can be desired and advantageous. Also, to the extent that the terms "includes", "including", "has", "having" or variants thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term "comprising." Also, the terms "another", "one or more" and "at least one" with respect to a recited feature are intended to further encompass the feature recited in addition to other possible features.

[0115] Claim language reciting "at least one of a plurality" or "one or more of a plurality" of items, along with other terms such as "comprising", "including", "containing", "involving", "having", "featuring", "characterized by", "including", "comprised of", "specified by", and the like, are in fact synonymously interchangeable, and are intended, in the context of this disclosure, to refer to the components specified in the claim language. Likewise, the use of the term "means", "step for" and other means-plus-function language is intended in the context of the written description to refer to the structural elements of the described structure and to the functions of such structural elements, and not to functionally equivalent structures. The elements of the claims are not to be interpreted as mere means plus function, but as the structural elements for performing the recited functions.

Claims

1. A method for networking, comprising: The network controller establishes a network gateway within the software-defined cloud interconnect provider; Establish cross-connectivity between network gateways and one or more clouds in the software-defined cloud interconnect provider; Group one or more virtual networks in one or more clouds into tags that allow interconnection between different virtual networks and the application of global policies, with different requirements and / or constraints imposed by different cloud service providers; tag one or more virtual networks in branch sites into logical groups so that traffic flows from the tags in the branch sites to the cloud service providers; and map one or more tags corresponding to the virtual networks in the branch sites to one or more tags corresponding to the virtual networks in one or more clouds. as well as The tag is used to establish a connection between one or more virtual networks in one or more clouds and one or more virtual networks in the branch site.

2. The method according to claim 1, wherein, Based on one or more characteristics associated with one or more virtual networks in the one or more clouds and one or more virtual networks in the branch sites, the one or more virtual networks in the one or more clouds and one or more virtual networks in the branch sites are grouped into the tags.

3. The method according to claim 1 or 2, wherein, The connection between one or more virtual networks in the one or more clouds and one or more virtual networks in the branch site is based on the cross-connectivity between the network gateway in the software-defined cloud interconnect provider and the one or more clouds.

4. The method according to claim 1 or 2, wherein, The connection between one or more virtual networks in one or more clouds and one or more virtual networks in the branch sites is configured based on Automated Border Gateway Protocol routing.

5. The method according to claim 1 or 2, wherein, Cross-connectivity between the network gateway in the software-defined cloud interconnect provider and the one or more clouds, as well as connectivity between one or more virtual networks in the one or more clouds and one or more virtual networks in the branch site, is via an application programming interface.

6. The method according to claim 1 or 2, further comprising: Standardize one or more parameters associated with the software-defined cloud interconnect provider.

7. The method according to claim 6, wherein, The one or more parameters determine the attributes of the network gateway and are selected from a group consisting of software image, border gateway protocol autonomous system number, virtual network size, and interconnection transition color.

8. A system for networking, comprising: Memory configured to store instructions; A processor is configured to execute the instructions and cause the processor to perform the following operations: Establish network gateways within software-defined cloud interconnect providers; Establish cross-connectivity between network gateways and one or more clouds in the software-defined cloud interconnect provider; Group one or more virtual networks in one or more clouds into tags that allow interconnection between different virtual networks and the application of global policies, with different requirements and / or constraints imposed by different cloud service providers; tag one or more virtual networks in branch sites into logical groups so that traffic flows from the tags in the branch sites to the cloud service providers; and map one or more tags corresponding to the virtual networks in the branch sites to one or more tags corresponding to the virtual networks in one or more clouds. as well as The tag is used to establish a connection between one or more virtual networks in one or more clouds and one or more virtual networks in the branch site.

9. The system according to claim 8, wherein, One or more virtual networks in one or more clouds and one or more virtual networks in one or more branch sites are grouped into the tag based on one or more characteristics associated with the one or more virtual networks in one or more clouds and one or more virtual networks in one or more branch sites.

10. The system according to claim 8 or 9, wherein, The connection between one or more virtual networks in the one or more clouds and one or more virtual networks in the branch site is based on the cross-connectivity between the network gateway in the software-defined cloud interconnect provider and the one or more clouds.

11. The system according to claim 8 or 9, wherein, The connection between one or more virtual networks in one or more clouds and one or more virtual networks in the branch sites is configured based on Automated Border Gateway Protocol routing.

12. The system according to claim 8 or 9, wherein, Cross-connectivity between the network gateway in the software-defined cloud interconnect provider and the one or more clouds, as well as connectivity between one or more virtual networks in the one or more clouds and one or more virtual networks in the branch site, is via an application programming interface.

13. The system according to claim 8 or 9, further comprising: Standardize one or more parameters associated with the software-defined cloud interconnect provider.

14. The system according to claim 13, wherein, The one or more parameters determine the attributes of the network gateway and are selected from a group consisting of software image, border gateway protocol autonomous system number, virtual network size, and interconnection transition color.

15. A non-transitory computer-readable medium comprising instructions that, when executed by a computing system, cause the computing system to perform the following operations: Establish network gateways within software-defined cloud interconnect providers; Establish cross-connectivity between network gateways and one or more clouds in the software-defined cloud interconnect provider; Group one or more virtual networks in one or more clouds into tags that allow interconnection between different virtual networks and the application of global policies, with different requirements and / or constraints imposed by different cloud service providers; tag one or more virtual networks in branch sites into logical groups so that traffic flows from the tags in the branch sites to the cloud service providers; and map one or more tags corresponding to the virtual networks in the branch sites to one or more tags corresponding to the virtual networks in one or more clouds. as well as The tag is used to establish a connection between one or more virtual networks in one or more clouds and one or more virtual networks in the branch site.

16. The computer-readable medium of claim 15, wherein, One or more virtual networks in one or more clouds and one or more virtual networks in one or more branch sites are grouped into the tag based on one or more characteristics associated with the one or more virtual networks in one or more clouds and one or more virtual networks in one or more branch sites.

17. The computer-readable medium according to claim 15 or 16, wherein, The connection between one or more virtual networks in the one or more clouds and one or more virtual networks in the branch site is based on the cross-connectivity between the network gateway in the software-defined cloud interconnect provider and the one or more clouds.

18. The computer-readable medium according to claim 15 or 16, wherein, The connection between one or more virtual networks in one or more clouds and one or more virtual networks in the branch sites is configured based on Automated Border Gateway Protocol routing.

19. The computer-readable medium according to claim 15 or 16, wherein, Cross-connectivity between the network gateway in the software-defined cloud interconnect provider and the one or more clouds, as well as connectivity between one or more virtual networks in the one or more clouds and one or more virtual networks in the branch site, is via an application programming interface.

20. The computer-readable medium according to claim 15 or 16, wherein, The computer-readable medium further includes instructions that, when executed by the computing system, cause the computing system to perform the following operations: Standardize one or more parameters associated with the software-defined cloud interconnect provider.

21. An apparatus for networking, comprising: Modules used by network controllers to establish network gateways in software-defined cloud interconnect providers; Modules used to establish cross-connectivity between network gateways and one or more clouds in the software-defined cloud interconnect provider; Modules for performing the following operations: grouping one or more virtual networks in one or more clouds into tags that allow interconnection of different virtual networks and the application of global policies, with different requirements and / or constraints imposed by different cloud service providers; tagging one or more virtual networks in branch sites into logical groups, such that traffic flows from the tags in the branch sites to the cloud service providers; and mapping one or more tags corresponding to the virtual networks in the branch sites to one or more tags corresponding to the virtual networks in the one or more clouds; as well as Module for establishing connections between one or more virtual networks in one or more clouds and one or more virtual networks in the branch site using the tag.

22. The apparatus of claim 21, further comprising: A module for implementing the method according to any one of claims 2 to 7.

23. A computer program, computer program product, or computer-readable medium comprising instructions that, when executed by a computer, cause the computer to perform the steps of the method according to any one of claims 1 to 7.

Images