Callback service for cloud exchange connected through network service provider

Abstract

An example method includes receiving, by a cloud exchange including processing circuitry, a request from a customer system to communicatively couple a virtual gateway on a network infrastructure of the cloud exchange to a network gateway that is communicatively coupled to a public network, the request including data indicating a public Internet Protocol (IP) address of the customer system, wherein the customer system is configured with a first connection that communicatively couples the customer system and the public network via a network service provider (NSP) that is separate from the cloud exchange; configuring, by the cloud exchange, a network route to the virtual gateway for the network gateway that is communicatively coupled to the public network; and providing, by the cloud exchange, routing information including the public IP address of the customer system to the network gateway to create a second connection that communicatively couples the customer system and the public network.

Description

[0001] This application claims the benefit of U.S. Patent Application No. 17 / 302,368, filed April 30, 2021, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure relates to computer networks, and more specifically, to callback services for computer networks. Background Technology

[0003] Many businesses rely on network communication capabilities over public networks such as the Internet. For example, companies may depend on network communications to provide information about products and services, receive orders for products or services, provide access to cloud services or other services, operate virtual private networks (VPNs) to connect different sites, provide customer service, and control various aspects of company operations. Network communication failures, even brief ones, can lead to lost revenue, customer dissatisfaction, and / or disruption to company operations. Summary of the Invention

[0004] In summary, this disclosure describes a technique for a cloud exchange-based callback service for services provided by a network service provider (ISP). In normal operation, an enterprise can communicate network services with a public network (such as the Internet) via an ISP. If the ISP becomes unable to communicate network services between the enterprise and the public network, the enterprise can utilize access to the public network via a cloud exchange-based service as a callback service. For example, the enterprise can issue application programming interface (API) calls to create a virtual gateway on the cloud exchange's network device, which is separate from the ISP and operated by a different entity. The API calls provide an interface for the enterprise to supply routing information, such as Autonomous System Numbers (ASNs), public IP addresses, and other routing information, to the cloud exchange provider for configuring the virtual gateway and advertising the cloud exchange's reachability to the enterprise. The virtual gateway can then establish a network connection to the public network for the enterprise's use.

[0005] The aspects described above, as well as others described herein, offer one or more technical advantages that enable at least one practical application. For example, in the event of network service outages associated with network service providers, virtual gateways can be established on demand, minimizing the impact of service disruptions on the enterprise. As another example, enterprises can benefit from available callback services without requiring dedicated secondary connections to the public network. This reduces operational costs associated with maintaining enterprise network services. Furthermore, traditional methods of modifying network infrastructure in cloud switches, whether virtual or physical, typically require prior notification and involvement from the cloud switch provider's administrator. Using the techniques described herein, virtual gateways can be rapidly established by customers on demand without the involvement of the cloud switch provider's administrator. As yet another example, because enterprise customers of cloud switches typically already have dedicated connectivity to the cloud switch infrastructure—and typically at the network edge—the callback services described herein allow enterprises to quickly leverage existing connectivity and customer relationships to obtain on-demand, resilient, and low-latency callback services.

[0006] In some examples, one method includes receiving, via a cloud switch including a processing circuitry system, a request from a customer system to communicatively couple a virtual gateway on the cloud switch's network infrastructure to a network gateway communicatively coupled to a public network. The request includes data indicating the customer system's public Internet Protocol (IP) address, wherein the customer system is configured with a first connection communicatively coupling the customer system and the public network via a separate Network Service Provider (NSP) from the cloud switch; configuring a network route from the network gateway to the virtual gateway, which is communicatively coupled to the public network, by the cloud switch; and providing routing information, including the customer system's public IP address, to the network gateway to create a second connection communicatively coupling the customer system and the public network.

[0007] In some examples, the cloud switch includes a memory; and a processing circuitry configured to: receive from a client system a request to communicatively couple a virtual gateway on the cloud switch's network infrastructure to a network gateway communicatively coupled to a public network, the request including data indicating the client system's public Internet Protocol (IP) address, wherein the client system is configured with a first connection communicatively coupling the client system and the public network via a separate Network Service Provider (NSP) from the cloud switch; configure network routing for the network gateway to the virtual gateway, which is communicatively coupled to the public network; and provide the network gateway with routing information including the client system's public IP address to create a second connection communicatively coupling the client system and the public network.

[0008] In some examples, the computer-readable storage medium includes machine-executable instructions that, when executed, cause a processing circuit system to: receive from a client system a request to communicatively couple a virtual gateway on the cloud switch's network infrastructure to a network gateway communicatively coupled to a public network, the request including data indicating the client system's public Internet Protocol (IP) address, wherein the client system is configured with a first connection communicatively coupling the client system and the public network via a separate Network Service Provider (NSP) from the cloud switch; configure a network route for the network gateway to the virtual gateway, which is communicatively coupled to the public network; and provide the network gateway with routing information including the client system's public IP address to create a second connection communicatively coupling the client system and the public network.

[0009] Details of one or more examples are set forth in the accompanying drawings and the following description. Other features, objects, and advantages will become apparent from the specification, drawings, and claims. Attached Figure Description

[0010] Figures 1A-1E This is a block diagram illustrating an example system that provides callback services to network service providers based on the techniques described herein.

[0011] Figure 2A and Figure 2B This is a sequence diagram illustrating an example operation for providing callback services to a network service provider according to the techniques described herein.

[0012] Figure 3 This is a block diagram illustrating a conceptual view of a network system with a metro-based cloud switch according to the technology described herein, which provides multiple cloud exchange points for providing callback services.

[0013] Figure 4 This is a block diagram illustrating an example data center providing an operating environment for providing callback services according to one or more aspects of the technology described in this disclosure.

[0014] Figure 5 This is a flowchart illustrating the operation of a method for providing callback services to a network service provider according to the techniques described herein.

[0015] Figure 6 A block diagram illustrating further details of an example of a computing device operating according to one or more techniques of this disclosure.

[0016] Figures 7A-7B A block diagram illustrating a conceptual view of an application programming interface contract based on one or more aspects of the technology described in this disclosure.

[0017] The same reference characters indicate similar elements throughout the accompanying drawings and text. Detailed Implementation

[0018] Figures 1A-1E This is a block diagram illustrating an example system that provides callback services to a network service provider according to the techniques described herein. In the examples discussed below, "colocated" and "non-colocated" customers will be referred to. A colocated customer is one who purchases, leases, or otherwise arranges to use network and / or computing infrastructure operated by a third-party provider, such as a data center provider. A non-colocated customer is one who does not currently use such network and / or computing infrastructure. Customers can be businesses, government agencies, individuals, or any other consumers of services provided by a network service provider.

[0019] The example systems discussed below may include a network service provider (NSP) 106, a cloud switch 120, a network gateway 112, and a cloud service provider 110. Examples of cloud service providers 110 include Google Cloud, Azure, Oracle Cloud, Amazon Web Services (AWS), IBM Cloud, Alibaba Cloud, and Salesforce. The cloud switch 120 provides a cloud exchange fabric 102 that couples co-located clients 108 to communicate with the cloud service provider. In some aspects, the cloud exchange fabric 102 may be the Equinix fabric provided by Equinix Inc. of Redwood, California.

[0020] NSP 106 can provide network services to customer 108. For example, NSP 106 may include network infrastructure (routers, switches, gateways, etc.) that provides customer 108 with connectivity to public network 116. Public network 116 may be a network that is publicly available with little or no restriction. For example, public network 116 may be a network that is part of the Internet. Network gateway 112 may also include network infrastructure to provide connectivity to public network 116. In some respects, gateway 116 may be part of the Equinix Connectivity Platform provided by Equinix Corporation.

[0021] Figures 1A-1C The diagram illustrates on-demand requests for callback services. Figure 1D and Figure 1E The diagram illustrates redundant connections that provide callback services. This will be discussed below. Figures 1A-1EIn this diagram, lines between components indicate that components are communicatively coupled to each other via a communication path. Solid lines indicate that the communication path is available, operational, and used by a designated customer. Dashed lines indicate that the communication path is available and operational, but not used by a designated customer. A line marked with an "X" indicates that the marked path has failed in some way and communication is no longer possible via the marked path.

[0022] Figure 1A This is a block diagram illustrating the initial communication link in system 100 that provides callback services to a non-co-located client 108. Figure 1A In the example shown, customer 108 is a non-co-located customer. Customer 108 accesses the public network 116 via communication link 111 and the backbone network 107 via NSP 106. In some respects, the public network 116 may be the Internet, and the backbone network 107 may be a backbone network that is part of the Internet. In this example, the backbone network 107 between NSP 106 and the public network 116 is operational and provides a communication path between the non-co-located customer 108 and the public Internet 116.

[0023] The communication link 115 between NSP 106 and cloud switch 102 is operable, but... Figure 1A In the example system state shown, customer 108 is not in use. Cloud switch configuration 102 may also have communication links with one or more cloud service providers.

[0024] The Virtual Gateway Application Programming Interface (API) 103 provides a software interface to the Cloud Switch Provider 120 system, which can be used to control the creation, modification, and deletion of virtual gateways on the Cloud Switch Provider 120 system. Figures 7A-7B Details of example API contracts that may be provided in some implementations are provided and will be discussed in more detail below.

[0025] Figure 1BThe diagram illustrates a communication link in system 100, where the backbone network 107 is no longer operational for non-co-located customers. As a result, non-co-located customer 108 can no longer access the public network 116 via the backbone network 107. The non-co-located customer 108 or the cloud switch provider 120 can detect that access to network 116 is no longer available. In some aspects, the non-co-located customer 108 can request the cloud switch provider 120 via API 103 to establish a network connection path to the public network 116. In other aspects, the non-co-located customer 108 can use the virtual gateway API 103 to schedule the cloud service provider 120 to monitor error traps from customer 108 indicating network connectivity problems between customer 108 and the public network 116. For example, the cloud provider 120 can monitor Simple Network Protocol (SNMP) traps associated with the network connection from customer 108 to the public network 116 via network service provider 106.

[0026] In response to a network service interruption detected by either customer 108 or cloud switch provider 120, cloud switch provider 120 may create a virtual gateway 104 for use by non-co-located customer 108. Various details of the virtual gateway 104 are described in U.S. Provisional Patent Application Serial No. 63 / 025,352, filed May 15, 2020, entitled “Bandwidth Aggregation Service Model Using Virtual Gateways in a Cloud Switch,” which is incorporated herein by reference. Cloud switch provider 120 may configure the virtual gateway 104 using configuration parameters provided by customer 108 via API 103 to route network traffic from non-co-located customer 108 to network gateway 112, which has a communication link to public network 116. Therefore, network traffic to or from public network 116 of non-co-located customer 108 is routed via NSP 106, cloud switch construct 102, virtual gateway 104, and network gateway 112. This communication path can be referred to as an "on-demand" communication path because it is created on demand based on the request of the non-co-located client 108 and may not exist when not needed (i.e., when the communication path via the backbone network 107 is operational).

[0027] Figure 1CThis is a block diagram of the communication links in system 100, where the backbone network 107 is no longer operational for co-located customers. In this example, customer 108 has previously arranged communication services provided by both NSP 106 and cloud switch provider 120. During normal operation, customer 108 can communicate with public network 116 via NSP 106 and backbone network 107. If backbone network 107 is no longer operational or available, customer 108 can request cloud switch provider 120 to establish a network connection path to public network 116. Cloud switch provider 120 can create virtual gateway 104 for use by co-located customer 108. Cloud switch provider 120 can configure virtual gateway 104 to route network traffic from non-co-located customer 108 to network gateway 112 via link 109 between customer 108 and cloud switch configuration 102. Therefore, in this example, network services of co-located customer 108 destined for or originating from public network 116 are routed through cloud switch configuration 102, virtual gateway 104, and network gateway 112. As... Figure 1B The example shown can be referred to as an “on-demand” communication path because it is created on demand based on the request of client 108 and may not exist when not needed (i.e., when the communication path via backbone network 107 is operational).

[0028] Figure 1D The diagram illustrates the status of system 100, where client 108 is configured with a redundant communication path to public network 116. Figure 1D The example shown will be used to describe the redundant communication paths for co-located and non-co-located clients 108. Non-co-located client 108 can utilize communication links 111 and 107 as the primary connection for communicating with the public network 116 via NSP 106. Furthermore, non-co-located client 108 can utilize communication links 111 and 115 as secondary connections to communicate with the public network 116 via cloud switch configuration 102, virtual gateway 104, and network gateway 112.

[0029] exist Figure 1D In the example shown, the primary connection of co-located client 108 is the same as that of non-co-located client 108. That is, the primary connection of either co-located or non-co-located client 108 can be via communication link 111 and communication link 107. Co-located client 108 can use direct connection 109 as a secondary connection to reach public network 116 via cloud switch configuration 102, virtual gateway 104, and network gateway 112.

[0030] Figure 1E The diagram illustrates an alternative state of system 100, where customer 108 is configured with a redundant communication path to public network 116. (As shown...) Figure 1D As shown, Figure 1EThe example shown will be used to describe the redundant communication paths for co-located and non-co-located clients 108. Figure 1E In the example shown, with Figure 1D Compared to the example shown, the primary and secondary communication links are switched. Therefore, the non-co-located client 108 can utilize communication links 111 and 115 as the primary connection for communicating with the public network 116 via cloud switch configuration 102, virtual gateway 104, and network gateway 112. The non-co-located client 108 can utilize communication links 111 and 107 as secondary connections for communicating with the public network 116.

[0031] The co-located customer 108 can use direct connection 109 as the primary connection, reaching the public network 116 via cloud switch 102, virtual gateway 104, and network gateway 112. Figure 1E In the example shown, the secondary connection of the co-located client 108 is the same as the secondary connection of the non-co-located client 108. That is, the secondary connection of the co-located client 108 can be via communication link 111 and communication link 107.

[0032] Figure 2A and Figure 2B This is a sequence diagram illustrating an example operation of providing a callback service to a network service provider according to the techniques described herein. During normal operation 202, customer 108 accesses public network 116 via NSP 106.

[0033] Figure 2A This is a sequence diagram illustrating an example operation of providing a callback service to a network service provider according to the techniques described herein. During normal operation 202, customer 108 sends a network traffic destined for public network 116 to NSP 106 (204). NSP 106 forwards the network traffic to public network 116 via, for example, a backhaul network (206). A router on public network 116 sends the network traffic destined for customer 108 to NSP 116 (208). NSP 116 then forwards the network traffic from public network 116 to customer 108 (210).

[0034] Customer 108 loses access to public network 116 at some point during normal operation (212). This loss of access to public network 116 can be detected by customer 108 or cloud switch 120. In some ways, devices on customer 108's network can determine that customer 108 is no longer able to access public network 116. Various techniques can be used to determine that customer 108 no longer has access to public network 116. For example, one or more network devices on customer 108's network can generate an SNMP trap indicating a loss of access to public network 116. Customer 108 can receive an indication of a network device hardware error. Customer 108 can determine that packet latency has increased, indicating a potential backbone network outage. Customer 108 can determine that no network traffic is communicating between NSP 106 and customer 108, indicating a potential NSP 116 outage preventing customer 108 from communicating with public network 116.

[0035] In some respects, cloud switch 120 can determine that a network outage affecting customer 108 has occurred. For example, cloud switch 120 can receive SNMP trap information from customer 108, indicating that customer 108 can no longer communicate with public network 116.

[0036] In response to determining that customer 108 no longer has access to public network 116, customer 108 and cloud switch 108 initiate callback operation 214. In some aspects, customer 108 sends a "Create Virtual Gateway" request (216) to cloud switch 120. This request may include parameters specifying configuration details of the virtual gateway 104 to be created by cloud switch 120.

[0037] Figure 7A The diagram illustrates a conceptual view of the example API contract data structure 702 used to create a virtual gateway that customer 108 can use to supply such parameters. Example API contract data structure 702 is... Figure 7A It is shown in two formats: YAML (Yin't Markup Language) and JavaScript Object Notation (JSON). Figure 7AIn the example shown, API contract data structure 702 includes a type parameter, a name parameter, a configuration parameter, and an account parameter. The type parameter defines the type of the object (“VG” in this example). The name parameter provides a name for the virtual gateway to be created (“Equinix Virtual Gateway” in this example). The configuration parameters include bandwidth and location. The bandwidth parameter specifies the maximum bandwidth (e.g., rate, etc.) because customer 108 expects the newly created virtual gateway 104 to be able to handle it (“50Gbps” in this example). The location parameter identifies the location of the cloud switch where the virtual gateway will be created. In this example, “metropolitan” indicates a cloud switch in a metropolitan area, and the “xx” value is a two-letter indicator of the metropolitan area (e.g., “SV” for Silicon Valley, “NY” for New York, “CH” for Chicago, etc.). The account parameters include an account number and an account name parameter. The account number parameter provides the account associated with customer 108, which cloud switch 120 can use for billing, tracking, etc. In some respects, the account name parameter can be used to map the routing instance (RI) configuration of the identified customer account. This mapping makes it easier for network administrators or network engineers to resolve issues associated with a customer's routing instance.

[0038] Back Figure 2A After successfully verifying the parameters in the "Create Virtual Gateway" request, the cloud switch 120 creates a virtual gateway 104 using those parameters. In some respects, the virtual gateway 104 can be created on a network device "proximity" to the client 108. That is, the virtual gateway 104 can be created on a network device on the cloud switch fabrication 102 that, from a network topology perspective, is close to the client 108. For example, the client 108 will have a network connection to a physical port on the network device on the cloud switch fabrication 102. This network device can be referred to as the "primary network device." In some respects, the cloud switch 120 will attempt to instantiate the virtual gateway 104 on the primary device. After successfully creating the virtual gateway 104, the cloud switch 120 sends a response to the client 108 indicating that the virtual gateway 104 has been created.

[0039] In some cases, virtual gateway 104 may already exist before it is determined that customer 108 cannot access public network 116. For example, customer 108 may be a co-located customer, and therefore a virtual gateway previously created for customer 108 may exist in cloud switch 120, which is being used to access one or more of the cloud service providers 110. In this case, customer 108 can use the previously created virtual gateway 104 to access public network 116. Additionally, in the case of a co-located customer 108, cloud switch 120 may create a second virtual gateway on a network device (“secondary network device”) having a port connected to one of the cloud service providers 110 used by customer 108. In some aspects, this second virtual gateway is for internal use by cloud switch 120 and may not be visible to customer 108. If the first virtual gateway fails, the second virtual gateway can be used as a failover device. In some aspects, the second virtual gateway may be created as part of a virtual gateway creation request. In some aspects, if the customer already has a virtual gateway in the same metropolitan area, the virtual gateway creation request may reuse a previously created gateway.

[0040] In some respects, when a customer creates and provisions a virtual gateway in a metropolitan area, the system creates RIs on all routing devices in that metropolitan area. By default, RIs can "automatically subscribe" to each other. RIs share the same Virtual Routing and Forwarding (VRF) and import / export policies associated with routing targets.

[0041] Callback operation 214 further includes client 108 issuing a request to cloud switch 120 to connect virtual gateway 104 to network gateway 112 (220). In some aspects, the request includes providing parameters of a gateway protocol (e.g., Border Gateway Protocol (BGP) information) that virtual gateway 104 can use to communicatively connect gateway 104 to public network 116.

[0042] Figure 7B The diagram illustrates a conceptual view of an example API contract data structure 704 used to connect a virtual gateway to a public network 116 that can provide such parameters to client 108. (Similar to...) Figure 7A Example API contract data structure 704 Figure 7B It is shown in two formats (YAML and JSON). Figure 7B In the example shown, API contract data structure 704 includes a type parameter, a name parameter, and a configuration parameter. The type parameter defines the type of the object ("VG_VC" in this example). The name parameter provides a name for the virtual gateway to be created ("VG-IGW-Connection" in this example).

[0043] Configuration parameters include bandwidth, access point, link protocol, routing protocol, and Network Address Translation (NAT) parameters. The bandwidth parameter specifies the maximum bandwidth (e.g., rate, etc.) that client 108 expects the connection to virtual gateway 104 to be able to handle (in this example, "50" Gbps).

[0044] The access point parameters include type and port fields. The type field indicates the connection type that gateway 104 uses to connect to public network 116. In this example, the type field is specified as "IGW," indicating that the virtual gateway will be connected to an internet gateway (e.g., network gateway 112). In some respects, other types may be as follows:

[0045] • COLO, which stands for Port – another port at another location (for the same or different clients).

[0046] • L2SP - Tier 2 service providers (AWS, Azure, GCP, Oracle Cloud, IBM, etc.)

[0047] • L3SP - Tier 3 service provider (SAP, SFDC, Oracle, etc.)

[0048] The port field defines a value that identifies a supplied port. In some respects, the port field is a Universally Unique Identifier (UUID). Customers can use the constructed API to retrieve all supplied ports using the GET primitive. Each port in the response has its own UUID and attributes in the response. Alternatively, customers can lease ports (one or more) from resellers such as AT&T and Telstra.

[0049] The link protocol parameters define the protocol to be used between virtual gateway 104 and network gateway 112. In some respects, the link protocol parameters have two fields: type and configuration. Figure 7A In the example shown, the Type field is “TYPE5VNI”, indicating the use of a Type-5 Ethernet Virtual Private Network with a Virtual Extensible LAN (EVPN-VxLAN) link between virtual gateway 104 and network gateway 112. The configuration field has a value of “999”, indicating the VxLAN identifier.

[0050] The routing protocol parameter has two fields: Type and Vendor Autonomous System Number (ASN), indicating the ASN of the client peer used to establish the BGP session. In this example, the Type is "IBGP," indicating that virtual gateway 104 wishes to use the Internal Border Gateway Protocol (IBGP) to advertise routing information about the virtual gateway. In this example, the ASN is "10101."

[0051] The NAT parameters have a type field and a configuration field. The type field indicates the mapping type of Internet Protocol (IP) addresses between virtual gateway 104 and network gateway 116. Figure 7B In the example shown, the type field has the value "STATIC_MAPPING," indicating a one-to-one mapping between private and public IP addresses displayed on public network 116. The presence of "ipv4" in the configuration field indicates that the network addresses in the configuration conform to IP version 4 addresses. Other values ​​specific to the "ipv4" parameter include the seqId, publicip, and privateip values. The seqId value is the sequence number of the static mapping. The sequence number can be assigned to each customer / account in a given metropolitan area and can be assigned incrementally. The publicip value is the IP address assigned to customer 108. The public IP address is the IP address advertised by network gateway 116. The privateip value is the private IP address of customer 108. The private IP address is the IP address used in the autonomous system. Network gateway 112 advertises the public IP address in the routing information defining the path to customer 108. Network gateway 112 forwards network traffic destined for customer 108 to virtual gateway 104, which then forwards the network traffic to customer 108. Therefore, in Figure 7B In the example shown, the public IP address is "5.5.5.0", while the private IP address is "10.1.1.2". Therefore, when other network devices wish to communicate with client 108 via public network 116, they can specify "5.5.5.0" as the destination IP for network packets. Network gateway 116 will be on the advertised path of "5.5.5.0", so network packets with a destination address of "5.5.5.0" are routed to network gateway 116. The network gateway forwards these packets to client 108 via virtual gateway 104 and cloud switch configuration 102.

[0052] Back Figure 2A In response to the connection request, cloud switch 120 establishes a network connection between client 108, virtual gateway 104, and network gateway 116, such as... Figure 1B and Figure 1C As shown. In some respects, cloud switch 120 establishes a virtual local area network (VLAN) between customer 108 and virtual gateway 104, and establishes VLAN (222) between virtual gateway 104 and network gateway 116.

[0053] As described above, the co-located customer 108 may have previously created a virtual gateway to route network traffic between customer 108 and one or more cloud service providers via cloud switch configuration 102 (Figure 1). Cloud switch 120 can create route delimiters and route targets for the connection between virtual gateway 104 and network gateway 116, as well as one or more route delimiters and route targets corresponding to the connection between virtual gateway 104 and one or more cloud service providers 110. The route delimiters and route targets facilitate the correct routing of network traffic from customer 108 to network gateway 116 and from customer 108 to cloud service provider 110. In some aspects, cloud switch 120 can configure Layer 3 (L3) routing interfaces (RIs) on virtual gateway 104 for VLANs between virtual gateway 104 and network gateway 116, and configure RIs for VLANs between virtual gateway 104 and cloud service provider 110. Each of the RIs will have its own set of routing tables to ensure that network traffic from the co-located customer 108 to the virtual gateway is properly routed.

[0054] In some respects, the virtual gateway may have bandwidth limits imposed by the cloud switch 120, where different bandwidth limits may be available at different costs. In the case of co-located customer 108, the bandwidth limit is shared between the connection to network gateway 116 and the network connection to cloud service provider 110.

[0055] Network gateway 112 can use the parameters provided in API contract 704 to establish a connection between client 108 and public network 116. For example, network gateway 112 can use a routing protocol such as BGP to advertise the existence of a route to client 108 to other network devices on public network 116 (224). At this point, client 108 has established a connection to public network 116 (226) via virtual gateway 104 (228). Cloud switch 120 can provide a response to request 220, which is that virtual gateway 104 is connected to client 108 and can be used to communicate network data to and from public network 116 (230).

[0056] Figure 2B This is a sequence diagram illustrating example operations for providing secondary network service connectivity using a virtual gateway, based on the technology described herein. Figure 2B The example operations shown are the same as Figure 2A The operations shown are similar or identical. Figure 2BIn this process, operations 204-210 can be performed as part of the main connection (232) between customer 108 and public network 116. Therefore, in main-purpose operation 232, customer 108 sends network traffic destined for public network 116 to NSP 106 (204). NSP 106 forwards the network traffic to public network 116 via, for example, a backhaul network (206). Routers on public network 116 send network traffic destined for customer 108 to NSP 116 (208). NSP 116 then forwards the network traffic from public network 116 to customer 108 (210).

[0057] Operations 216-230 can be performed as part of establishing a redundant connection 234. In this example, customer 108 can establish a redundant connection while the primary purpose operation 232 continues. In other words, redundant connection 234 provides a secondary connection that can be used in addition to, or in place of, the primary purpose connection 232. Operations 216-230 can be used in conjunction with the above-described operations... Figure 2A The description and such Figure 7A and Figure 7B The same API shown.

[0058] Figure 3This is a block diagram illustrating a conceptual view of a network system with a metropolitan area-based cloud switch according to the technology described herein, which provides multiple cloud switching points for providing callback services. These multiple cloud switching points can be used to at least partially implement a virtual gateway 104. Each of the cloud-based service switching points 328A-328C of the cloud-based service switch 300 (“Cloud Switch 300”) (hereinafter described as a “Cloud Switch Point” and collectively referred to as “Cloud Switch Point 328”) may represent different data centers (“Metropolitan Area Based”, e.g., in New York City, New York; Silicon Valley, California; Seattle-Tacoma, Washington; Minneapolis-St. Paul, Minnesota; London, UK; etc.) located geographically within the same metropolitan area to provide resilient and independent cloud-based service switching, through which cloud-based service customers (“Customers”) and cloud-based service providers (“Cloud Providers”) connect to receive and provide cloud services respectively. In various examples, the cloud switch 300 may include more or fewer cloud switch points 328. In some instances, the cloud switch 300 includes only one cloud switching point 328. As used herein, the references to "cloud switch" or "cloud-based service switch" may refer to the cloud switching point. The cloud switch 300 can be compared with... Figure 1A , Figure 1B , Figure 2A and Figure 2B The cloud switch 300 is identical to the cloud switch 120. The cloud switch provider can deploy instances of the cloud switch 300 in multiple different metropolitan areas, and each instance of the cloud switch 300 has one or more cloud exchange points 328.

[0059] Each cloud exchange point in cloud exchange point 328 includes network infrastructure and an operating environment through which one or more customers 308A-308C (collectively, "Customers 308") receive cloud services from multiple cloud service providers 310A-310N (collectively, "Cloud Service Providers 310"). Cloud Service Provider 310 may host one or more cloud services 114. As mentioned above, Cloud Service Provider 310 may be a public or private cloud service provider. In some aspects, Cloud Service Provider 310 may correspond to... Figure 1A , Figure 1B , Figure 2A and Figure 2B One of the 110 cloud service providers.

[0060] The Cloud Switch 300 provides secure, private, and virtual connections to multiple cloud service providers (CSPs) globally for switch customers, such as enterprises, network operators, network service providers, and SaaS customers. Multiple CSPs participate in the Cloud Switch by having at least one accessible port on it, through which customers can connect to one or more cloud services provided by each CSP. The Cloud Switch 300 allows any customer's private network to directly cross-connect to any other customer at a public point, thereby enabling direct exchange of network services between customer networks.

[0061] One or more customers in customer 308 may receive cloud-based services directly via a Layer 3 peering and physical connection to one of the cloud exchange points in cloud exchange point 328, or indirectly via one of NSPs 306A-306B (collectively, “NSP306”, or alternatively, “Carrier 306”). NSP 306 may provide... Figure 1A , Figure 1B , Figure 2A and Figure 2B One or more of NSP 106. Customer 308 may include customers associated with virtual gateway 104, as described above. Figure 3 In the example shown, customer 308C is a cloud customer (e.g., a co-located customer) and has used the techniques described herein to create a virtual gateway 104A to connect to the cloud service provider 310. The virtual gateway 104A can also be used to interconnect with the public network 116 via network gateway 112. Customer 308D is a non-co-located customer and uses NSP 306C as its primary access to the public network 116. NSP 306C can be... Figure 1A , Figure 1B , Figure 2A and Figure 2B One of the NSP 106. NSPs 306A and 306B provide “cloud transit” by maintaining a physical presence within one or more cloud exchange points 328 and aggregating Layer 3 access from one or more clients 308. NSPs 306A and 306B can peer directly to one or more cloud exchange points 328 at Layer 3, and in doing so, provide indirect Layer 3 connectivity and peering to one or more clients 308, thereby allowing clients 308 to obtain cloud services from cloud exchange 300. Figure 3In the example, each cloud exchange point in cloud exchange point 328 is assigned a different Autonomous System Number (ASN). For example, cloud exchange point 328A is assigned ASN 1, cloud exchange point 328B is assigned ASN 2, and so on. Therefore, each cloud exchange point 328 is the next hop in the path vector routing protocol (e.g., BGP) path from cloud service provider 310 to customer 308. As a result, although not a transit network with one or more WAN links and accompanying Internet access and transit policies, each cloud exchange point 328 can peer with multiple different autonomous systems via external BGP (eBGP) or other external gateway routing protocols to exchange, aggregate, and route service traffic from one or more cloud service providers 310 to the customer. In other words, cloud exchange point 328 can internalize the eBGP peering relationship that cloud service provider 310 and customer 308 will maintain on a pairwise basis. Conversely, customer 308 can configure a single eBGP peering relationship with cloud exchange point 328 and receive multiple cloud services from one or more cloud service providers 310 via cloud exchange. While this article primarily describes eBGP or other Layer 3 routing protocol peering between cloud exchange points and customer, NSP, or cloud service provider networks, cloud exchange points may obtain routes from these networks in other ways, such as through static configuration or via Routing Information Protocol (RIP), Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), or other routing distribution protocols.

[0062] As an example, customer 308C is illustrated as having contracted with the cloud switch provider of cloud switch 300 to directly access Layer 3 cloud services via cloud exchange point 328C. In this manner, for example, customer 308C receives redundant Layer 3 connectivity from cloud service provider 310A. Customer 308C also contracts with NSP 306B to access Layer 3 cloud services via NSP 306B's transit network. Customer 308B is illustrated as having contracted with multiple NSPs 306A and 306B to provide redundant cloud access to cloud exchange points 328A and 328B via their respective transit networks. Furthermore, customer 306B has created a virtual gateway 104A as a secondary connection to the public network 116 via cloud exchange point 328B and network gateway 112. Customer 308A is illustrated as having a contract with NSP 306A to access the cloud exchange 328A via NSP 306A's transit network. Customer 308D is illustrated as having a contract with NSP 306C to have access to the public network 116. Additionally, Customer 308D has a contract with the cloud switch provider to directly access cloud exchange 328B as a callback connection to the public network 116. Figure 3As shown, when customer 308D loses access to public network 116 via NSP 306C, customer 308D can create virtual gateway 104B as needed.

[0063] The aforementioned contract is instantiated in the network infrastructure of cloud exchange point 328 through L3 peering configuration within the switching equipment of NSP 306 and cloud exchange point 328 and L3 connections (e.g., Layer 3 virtual circuits) established within cloud exchange point 328 to interconnect cloud service provider network 310 to NSP 306 network and customer network 308, all of which have at least one port providing connectivity within one or more of cloud exchange points 328.

[0064] In some examples, the cloud switch 300 allows any network service provider (NSP) or "carrier" 306A-306B (collectively, "carrier 306") customer 308A, customer 308B, or other cloud customers including customer 308C, to directly connect to any other customer network and / or any CSP 310 via a virtual Layer 2 (L2) or Layer 3 (L3) connection, thereby allowing direct exchange of network services between the customer network and the CSP 310. The virtual L2 or L3 connection may be referred to as a "virtual circuit".

[0065] Operators 306 may each represent network service providers associated with the switching network, through which network users of Operator 306 can access cloud services provided by CSP 310 via cloud switch 300. Generally, customers of CSP 310 may include network operators, large enterprises, managed service providers (MSPs), and customers of Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (IaaS), Virtualization as a Service (VaaS), and Data Storage as a Service (dSaaS) for such cloud-based services provided by CSP 310 via cloud switch 300.

[0066] In this way, the cloud switch 300 simplifies the process of collaboration between CSP 310 and customers (via operator 306 or directly) in a transparent and neutral manner. An example application of the cloud switch 300 is co-location and interconnection of data centers, where CSP 310 and operator 306 and / or customer 308 may already have a network presence, such as representing any cloud exchange point 328 by having one or more accessible ports within the data center available for interconnection. This allows participating operators, customers, and communication service providers to have a wide range of interconnection options within the same facility. Operators / customers can thus have the option to create many-to-many interconnections with only a one-time connection to one or more cloud exchange points 328. In other words, the cloud switch 300 allows customers to interconnect to multiple CSPs and cloud services, rather than having to establish separate connections across transit networks to access different cloud service providers or different cloud services from one or more cloud service providers.

[0067] The cloud switch 300 includes a programmable network platform 320 for dynamically programming the cloud switch 300 to respond to and reliably fulfill service requests that encapsulate business requirements for services provided by the cloud switch 300 and / or cloud service providers 310 coupled to the cloud switch 300. The programmable network platform 320 may include a network service coordinator 332 that handles requests from tenants (e.g., cloud clients) to deploy virtual gateway 104. For example, the network service coordinator 332 may organize, direct, and integrate underlying services via VMs (or containers) and other software and network subsystems to manage various services (e.g., the instantiation of virtual gateway 104). As a result, the programmable network platform 320 can coordinate business-level services across heterogeneous cloud service providers 310 based on well-defined service policies, quality of service policies, service level agreements, and costs, and additionally, based on the service topology of business-level services.

[0068] The programmable network platform 320 enables cloud service providers managing the cloud switch 300 to dynamically configure and manage the cloud switch 300, for example, facilitating virtual connections for cloud-based service delivery from multiple cloud service providers 310 to one or more cloud customers 308. The cloud switch 300 allows customers 308 to bypass the public internet and connect directly to the cloud service provider 310 to improve performance, reduce costs, increase connection security and privacy, and leverage cloud computing for additional applications. In this way, for example, enterprises, network operators, and SaaS customers can integrate cloud services with their on-premises applications at least in some respects, as if these services were part of their own data center network or otherwise directly coupled to their own data center network.

[0069] In other examples, the programmable network platform 320 enables cloud service providers to configure cloud switch 300 with an L3 instance requested by customer 308, as described herein. For example, customer 308 may request an L3 instance to link multiple cloud service providers (e.g., for transferring customer data between two cloud service providers, or for obtaining a service mesh from multiple cloud service providers).

[0070] The programmable network platform 320 may represent an application running within one or more data centers of the cloud switch 300, or alternatively, an application running off-site in a cloud provider's back office or branch office. The programmable network platform 320 may be distributed wholly or partially across data centers, each associated with a different cloud switching point 328 to constitute the cloud switch 300. Although shown as managing a single cloud switch 300, the programmable network platform 320 can control the provisioning of services for multiple different cloud switches. Alternatively or additionally, multiple independent instances of the programmable network platform 320 can control the provisioning of services for corresponding multiple different cloud switches.

[0071] In the example shown, the programmable network platform 320 includes a service interface (or "service API") 314 that defines methods, fields, and / or other software primitives that applications 330 (such as a customer portal) can invoke through the programmable network platform 320. Service interface 314 allows operators 306, customers 308, cloud service providers 310, and / or cloud switch providers to programmably access the capabilities and assets of the cloud switch 300 using the technologies described herein.

[0072] For example, service interface 314 facilitates machine-to-machine communication to enable the dynamic provisioning of virtual circuits and virtual gateways 104 within the cloud switch for interconnecting customer and / or cloud service provider networks. In this way, programmable network platform 320 automates various aspects of cloud service provisioning. For instance, service interface 314 provides customers with an automated and seamless way to establish, offload, and manage interconnections between multiple different cloud providers participating in the cloud switch. As another example, service interface 314 may include a virtual gateway API 103 that provides customers with a way to establish virtual gateways on demand as callbacks or redundant connections to the public network 116.

[0073] Further examples of cloud-based service switches can be found in U.S. Patent Application No. 15 / 099,407, entitled "Cloud-based Service Switch," filed April 14, 2016; U.S. Patent Application No. 14 / 927,451, entitled "Interconnection Platform for Real-time Configuration and Management of Cloud-based Service Switch," filed October 29, 2015; and U.S. Patent Application No. 14 / 927,306, entitled "Coordination Engine for Real-time Configuration and Management of Interconnection within Cloud-based Service Switch," filed October 29, 2015, each of which is incorporated herein by reference in its entirety.

[0074] Figure 4 This block diagram illustrates an example data center providing an operational environment for providing callback services, based on one or more aspects of the technology described in this disclosure. In this example data center, cloud switch 300 allows one of the corresponding customer networks 402A-402C and NSP networks 404A-404C (collectively, “NSP” or “Carrier” network 404) of any NSP 306A-306C or other customer to be directly cross-connected to any other customer network via a Layer 2 (L2) or Layer 3 (L3) connection, thereby allowing the exchange of service traffic between the customer networks, CSP 310, and public network 116. Data center 401 may be entirely located within a centralized area, such as a warehouse or localized data center consortium, and provides power, cabling, security, and other services to NSPs, customers, and cloud service providers who locate their respective networks within data center 401 (e.g., for colocation) and / or connect to data center 401 via one or more external links.

[0075] The cloud switch 300 includes network infrastructure 422 and an operating environment, and the customer network 402 can receive services from one or more CSPs 310 via interconnection. Figure 4In the example, network infrastructure 422 represents the switching configuration of the interconnection facility of cloud switch 300 (e.g., cloud switch configuration 102 of Figure 1) and includes multiple ports that can be dynamically interconnected with virtual circuits via, for example, by invoking service interface 314 of programmable network platform 320. Each of the ports is associated with NSP 306, customer 308, CSP 310, and public network 116. This allows NSP customers to have the option to create many-to-many interconnections with only a one-time hook-up with the switching network and the underlying network infrastructure 422, which provides the interconnection platform for cloud switch 300. In other words, cloud switch 300 allows customers to interconnect with multiple CSPs 310 using network infrastructure 422 within data center 401, rather than having to establish separate connections across a switching network to access different CSPs 310.

[0076] In addition, such as Figure 4 As shown, customer 308C is interconnected to public network 116 via NSP 306D. In this example, NSP 306D is located outside data center 401, and customer 308C is a non-co-located customer. Furthermore, in this example, customer 308A is located within data center 401 and is therefore a co-located customer.

[0077] The interconnections described herein may refer to, for example, physical cross-connections, Ethernet connections, Layer 2 VPNs or Virtual Private Local Area Networks (e.g., E-LINE, E-LAN, E-TREE, or E-Access), Internet-based switch interconnections where the corresponding network devices (e.g., routers and / or switches) of interconnected customers directly peer and exchange service traffic via network infrastructure 422, Layer 3 routes, and cloud switches where customer routers peer with network infrastructure 422 (or the “Provider”) network devices, rather than directly with other customers. Cloud switch 300 may provide customers with interconnection services to network services provided by CSP 310. That is, the interconnection service of cloud switch 300 provides access to network services (e.g., VNFs) provided by CSP 310.

[0078] For Layer 3 or higher interconnections, customer 308 can receive services directly via a physical connection to one of the Layer 3 peering and hosting facility exchange points, or indirectly via one of the NSPs 306. NSPs 306A-306C provide "transfer" by maintaining a physical presence within data center 401 and aggregating Layer 3 access from one or more customers 308. NSPs 306A-306C can peer directly to data center 401 at Layer 3, and doing so provides indirect Layer 3 connectivity and peering to one or more customers 308, thereby allowing customer 308 to obtain services from cloud switch 300.

[0079] With the cloud switch 300 providing an internet switch, different Autonomous System Numbers (ASNs) can be assigned to the network infrastructure 422. Therefore, the network infrastructure 422 is the next hop in the path vector routing protocol (e.g., BGP) path from CSP 310 to customer 308 and / or NSP 306. As a result, although the cloud switch 300 is not a switching network with one or more WAN links and accompanying internet access and transit policies, the cloud switch 300 can peer with multiple different autonomous systems via external BGP (eBGP) or other external gateway routing protocols to exchange, aggregate, and route service traffic from one or more CSPs 310 to customer 308. In other words, the cloud switch 300 can internalize the eBGP peering relationship that CSP 310 and customer 308 will maintain on a pairwise basis. Conversely, customer 308 can be configured with a single eBGP peering relationship with the cloud switch 300 and receive multiple services from one or more CSPs 310 via the cloud switch. While this article primarily describes eBGP or other Layer 3 routing protocol peering between host hosting facilities and customer, NSP, or service provider networks, host hosting facilities may obtain routes from these networks in other ways, such as through static configuration or via Routing Information Protocol (RIP), Open Shortest Path First (OSPF), Intermediate System to Intermediate System (IS-IS), or other routing allocation protocols.

[0080] As an example of the aforementioned cloud switch deployment. Figure 4The client network 402A is illustrated as having a contract with the cloud switch provider of cloud switch 300 to directly access Layer 3 services via cloud switch 300, and also a contract with NSP 306B to access Layer 3 services via the transit network of NSP 306B. The client network 402A is also illustrated as having a contract with NSP 306B to access Layer 3 services via the transit network of NSP 306B. These contracts can be instantiated in the network infrastructure 422 of cloud switch 300 through L3 peering configurations within the switching equipment of NSP 306 and cloud switch 300, and L3 connections (e.g., Layer 3 virtual circuits) established within cloud switch 300, to interconnect CSP 310 to NSP 306 and client network 402, all of which have at least one port providing connectivity within cloud switch 300.

[0081] exist Figure 4 In the example shown, non-co-located customer 308C has arranged primary access to public network 116 via NSP 306D. Furthermore, customer 308C has arranged with the cloud switch provider of cloud switch 300 to utilize network infrastructure 422 as a callback service to connect to public network 116 if the connection via NSP 306D becomes unavailable. In this case, customer 308A can instantiate virtual gateway 104 using the virtual gateway APIs 103 as described above to interconnect with public network 116 using network infrastructure 422 and network gateway 112. Co-located customer 308A has used the techniques described herein to create virtual gateway 104B to connect to cloud service provider 310. Virtual gateway 104B can also be used by customer 308A to interconnect with public network 116 via network gateway 112.

[0082] about Figure 3 Exemplary network systems and Figure 4 Further details of the exemplary data center 401 can be found in U.S. Provisional Patent Application Serial No. 62 / 908,976 entitled “Verification of Virtualized Network Functions Using Distributed Identifiers”, filed October 1, 2019, which is incorporated herein by reference.

[0083] Figure 5This is an operational flowchart of a method for providing callback services to a network service provider according to the techniques described herein. The cloud switch may receive from a client system a request to communicatively couple a virtual gateway on the cloud switch's network infrastructure to a network gateway communicatively coupled to a public network. This request includes data indicating the client system's public Internet Protocol (IP) address, wherein the client system is configured with a first connection (505) communicatively coupling the client system and the public network via a separate network service provider (NSP) from the cloud switch. Next, the cloud switch may configure a network route to the virtual gateway for the network gateway, which is communicatively coupled to the public network (510). Furthermore, the cloud switch may provide the network gateway with routing information including the client system's public IP address to create a second connection communicatively coupling the client system and the public network (515).

[0084] Figure 6 A block diagram illustrating further details of an example of a computing device operating according to one or more techniques of this disclosure. Figure 6 The illustration may include specific examples of servers, network devices, or other computing devices 600, including one or more processors(s) 602 for executing any one or more of any systems, applications, or modules described herein. For example, one or more processors(s) 602 may execute virtual machines 626 and virtual gateways 628. Other examples of computing devices 600 may be used in other contexts. Although for illustrative purposes... Figure 6 The device is shown as a standalone computing device 600, but a computing device can be any component or system including one or more processors or other suitable computing environments for executing software instructions, and does not necessarily need to include, for example, a processor. Figure 6 One or more components are shown (e.g., communication unit 606; and in some examples, components such as storage devices (one or more) 608 may not be co-located with other components or be in the same chassis).

[0085] like Figure 6As illustrated in the specific examples, computing device 600 includes one or more processors 602, one or more input devices 604, one or more communication units 606, one or more output devices 612, one or more storage devices 608, a user interface (UI) device 610, and a communication unit 606. In one example, computing device 600 further includes one or more applications 622 executable by computing device 600, one or more programmable network platform applications 624, and an operating system 616. Each of components 602, 604, 606, 608, 610, and 612 is coupled (physically, communicatively, and / or operatively) for inter-component communication. In some examples, communication channel 614 may include a system bus, network connection, inter-process communication data structure, or any other method for communicating data. As an example, components 602, 604, 606, 608, 610, and 612 may be coupled via one or more communication channels 614.

[0086] In one example, processor 602 is configured to perform functionality and / or process instructions for execution within computing device 600. For example, processor 602 is capable of processing instructions stored in storage device 608. Examples of processor 602 may include any one or more of a microprocessor, controller, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or equivalent discrete or integrated logic circuit system.

[0087] One or more storage devices 608 may be configured to store information within computing device 600 during operation. In some examples, storage device 608 is described as a computer-readable storage medium. In some examples, storage device 608 is temporary memory, meaning that the primary purpose of storage device 608 is not long-term storage. In some examples, storage device 608 is described as volatile memory, meaning that storage device 608 does not maintain its stored contents when the computer is turned off. Examples of volatile memory include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), and other forms of volatile memory known in the art. In some examples, storage device 608 is used to store program instructions executed by processor 602. In one example, storage device 608 is used by software or applications running on computing device 600 to temporarily store information during program execution.

[0088] In some examples, storage device 608 also includes one or more computer-readable storage media. Storage device 608 may be configured to store a larger amount of information than volatile memory. Storage device 608 may also be configured as a long-term storage medium for information. In some examples, storage device 608 includes non-volatile storage elements. Examples of such non-volatile storage elements include magnetic hard disks, optical disks, floppy disks, flash memory, or various forms of electrically programmable memory (EPROM) or electrically erasable programmable memory (EEPROM).

[0089] In some examples, computing device 600 also includes one or more communication units 606. In one example, computing device 600 uses communication unit 606 to communicate with external devices via one or more networks, such as one or more wired / wireless / mobile networks. Communication unit 606 may include a network interface card, such as an Ethernet card, an optical transceiver, a radio frequency transceiver, or any other type of device capable of sending and receiving information. In some examples, computing device 600 uses communication unit 606 to communicate with external devices.

[0090] In one instance, computing device 600 also includes one or more user interface devices 610. In some examples, user interface devices 610 are configured to receive input from a user via haptic, audio, or video feedback. Examples of user interface devices (one or more) 610 include presence-sensitive displays, mice, keyboards, voice response systems, cameras, microphones, or any other type of device used to detect commands from the user. In some examples, presence-sensing displays include touch-sensitive screens.

[0091] The computing device 600 may also include one or more output devices 612. In some examples, the output device 612 is configured to provide output to a user using tactile, audio, or video stimuli. In one example, the output device 612 includes a presence-sensitive display, sound card, video graphics adapter card, or any other type of device for converting signals into a suitable form that is understandable to humans or machines. Additional examples of the output device 612 include a speaker, a cathode ray tube (CRT) monitor, a liquid crystal display (LCD), or any other type of device capable of generating understandable output to a user.

[0092] Computing device 600 may include operating system 616. In some examples, operating system 616 controls the operation of components of computing device 600. For example, in one example, operating system 616 facilitates communication between one or more applications 622, programmable network platform applications(one or more) 624, VM ​​626, and virtual gateway 628 and processor 602, communication unit 606, storage device 608, input device 604, user interface device 610, and output device 612.

[0093] Application 622, virtual machine 626, and virtual gateway 628 may also include program instructions and / or data executable by computing device 600. Example programmable network platform applications (one or more) 624 executable by computing device 600 may include callback service module 650. Callback service module 650 may display Virtual Gateway API 103 (… Figures 1A-1E ) and / or process requests received via Virtual Gateway API 103. Furthermore, Callback Service Module 650 may implement the techniques described herein to process requests received via Virtual Gateway API 103, thereby creating Virtual Gateway 626 and communicatively coupling Virtual Gateway 628 to Network Gateway 112 ( Figures 1B-1E ).

[0094] The techniques described herein can be implemented in hardware, software, firmware, or any combination thereof. Various features described as modules, units, or components can be implemented together in an integrated logic device or separately as discrete but interoperable logic devices or other hardware devices. In some cases, various features of an electronic circuit system can be implemented as one or more integrated circuit devices, such as integrated circuit chips or chipsets.

[0095] If implemented in hardware, this disclosure is applicable to apparatuses for processors or integrated circuit devices (such as integrated circuit chips or chipsets). Alternatively or additionally, if implemented in software or firmware, the technology can be implemented at least in part by a computer-readable data storage medium including instructions that, when executed, cause a processor to perform one or more of the methods described above. For example, the computer-readable data storage medium may store such instructions that are executed by a processor.

[0096] Computer-readable media may form part of a computer program product, which may include packaging materials. Computer-readable media may include computer data storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile random access memory (NVRAM), electrically erasable programmable read-only memory (EEPROM), flash memory, magnetic or optical data storage media, and the like. In some examples, the article of manufacture may include one or more computer-readable storage media.

[0097] In some examples, computer-readable storage media may include non-transitory media. The term "non-transitory" may indicate that the storage medium is not embodied in a carrier wave or a propagating signal. In some examples, non-transitory storage media may store data that may change over time (e.g., in RAM or cache).

[0098] The code or instructions may be software and / or firmware executed by a processing circuitry system, including one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other equivalent integrated or discrete logic circuitry systems. Therefore, the term "processor" as used herein may refer to any of the foregoing structures or any other structure suitable for implementations of the techniques described herein. Furthermore, in some aspects, the functionality described in this disclosure may be provided within software or hardware modules.

Claims

1. A computer networking method, comprising: A cloud switch, including a processing circuitry system, receives from a client system a request to communicatively couple a virtual gateway on the cloud switch's network infrastructure to a network gateway that is communicatively coupled to a public network. The request includes data indicating the public Internet Protocol (IP) address of the client system. The client system is configured with a first connection that communicatively couples the client system and the public network via a network service provider (NSP) separate from the cloud switch. The client system and the cloud switch are co-located. The cloud switch configures network routing from the network gateway to the virtual gateway, the network gateway being communicatively coupled to the public network; as well as The cloud switch provides the network gateway with routing information including the public Internet Protocol (IP) address of the client system to create a second connection, which communicatively couples the client system and the public network via the network gateway and the virtual gateway of the cloud switch.

2. The method according to claim 1, further comprising: The cloud switch creates the virtual gateway on the network infrastructure.

3. The method of claim 1, wherein the request to communicatively couple the virtual gateway to the network gateway indicates a failure of the first connection.

4. The method according to claim 1, further comprising: Before receiving the request to communicatively couple the virtual gateway on the network infrastructure of the cloud switch to the network gateway, a request to create the virtual gateway is received via the application programming interface (API) exposed by the cloud switch.

5. The method of claim 1, wherein the request to communicatively couple the virtual gateway to the network gateway includes an Autonomous System Number associated with the client system.

6. The method according to claim 1, further comprising: The cloud switch determines the network devices of the network infrastructure that communicatively couple the client system to the cloud switch; as well as Create the virtual gateway on the network device.

7. The method of claim 1, wherein receiving the request to communicatively couple the virtual gateway to the network gateway comprises: Receive the first request to create the virtual gateway; as well as Receive a second request to connect the virtual gateway to the network gateway, the second request including the public Internet Protocol (IP) address of the client system.

8. The method according to any one of claims 1 to 7, The virtual gateway is configured to communicatively couple the client system with the cloud service provider via a first virtual local area network (VLAN). Configuring the network route from the virtual gateway to the network gateway includes configuring the network route via a second virtual LAN (VLAN), and The method further includes: The virtual gateway receives network services, which include destination information. as well as The virtual gateway routes the network service to either the network gateway or the cloud service provider based on the destination information.

9. The method of claim 8, wherein the request to communicatively couple the virtual gateway to the network gateway includes specifying a bandwidth parameter for a maximum bandwidth for the virtual gateway, wherein the maximum bandwidth is shared by the first virtual LAN VLAN and the second virtual LAN VLAN.

10. The method according to any one of claims 1 to 7, wherein the first connection includes a primary connection to the client system, and wherein the second connection includes a secondary connection to the client system.

11. A cloud switch, comprising: Memory; as well as The processing circuit system is configured as follows: A request is received from a client system to communicatively couple a virtual gateway on the network infrastructure of the cloud switch to a network gateway that is communicatively coupled to a public network. The request includes data indicating the public Internet Protocol (IP) address of the client system, wherein the client system is configured with a first connection that communicatively couples the client system and the public network via a network service provider (NSP) separate from the cloud switch, and wherein the client system and the cloud switch are co-located. Configure network routing for the network gateway to the virtual gateway, which is communicatively coupled to the public network; as well as The network gateway is provided with routing information including the public Internet Protocol (IP) address of the client system to create a second connection, which communicatively couples the client system and the public network via the network gateway and the virtual gateway of the cloud switch.

12. The cloud switch of claim 11, wherein the processing circuitry is further configured to create the virtual gateway on the network infrastructure.

13. The cloud switch of claim 11, wherein the request to communicatively couple the virtual gateway to the network gateway indicates a failure of the first connection.

14. The cloud switch according to claim 11, wherein the processing circuit system is further configured to: Before receiving the request to communicatively couple the virtual gateway to the network gateway, a request to create the virtual gateway is received via an application programming interface (API) exposed by the cloud switch.

15. The cloud switch of claim 11, wherein the request to communicatively couple the virtual gateway to the network gateway includes an Autonomous System Number associated with the client system.

16. The cloud switch according to claim 11, wherein the processing circuitry is further configured to: The network devices of the network infrastructure that communicatively couple the client system to the cloud switch are identified; and Create the virtual gateway on the network device.

17. The cloud switch of claim 11, wherein receiving the request to communicatively couple the virtual gateway to the network gateway comprises: Receive the first request to create the virtual gateway; as well as Receive a second request to connect the virtual gateway to the network gateway, the second request including the public Internet Protocol (IP) address of the client system.

18. The cloud switch according to any one of claims 11 to 17, The virtual gateway is configured to communicatively couple the client system with the cloud service provider via a first virtual local area network (VLAN). Configuring the network route from the virtual gateway to the network gateway includes configuring the network route via a second virtual LAN (VLAN), and The virtual gateway is configured as follows: Receive network services, the network services having destination information; and Based on the destination information, the network service is routed to either the network gateway or the cloud service provider.

19. The cloud switch of claim 18, wherein the request to communicatively couple the virtual gateway to the network gateway includes specifying a bandwidth parameter for a maximum bandwidth for the virtual gateway, wherein the maximum bandwidth is shared by the first virtual LAN VLAN and the second virtual LAN VLAN.

20. A computer-readable storage medium comprising machine-executable instructions that, when executed, cause a processing circuit system to: A request is received from a client system to communicatively couple a virtual gateway on the network infrastructure of the cloud switch to a network gateway that is communicatively coupled to a public network. The request includes data indicating the public Internet Protocol (IP) address of the client system, wherein the client system is configured with a first connection that communicatively couples the client system and the public network via a network service provider (NSP) separate from the cloud switch, and wherein the client system and the cloud switch are co-located. Configure network routing for the network gateway to the virtual gateway, the network gateway being communicatively coupled to the public network; and The network gateway is provided with routing information including the public Internet Protocol (IP) address of the client system to create a second connection, which communicatively couples the client system and the public network via the network gateway and the virtual gateway of the cloud switch.

Images