Service chaining in multi-fabric cloud networks

Techniques for routing data packets through service chains within and between public cloud networks of multi-cloud fabrics. A router in a network, e.g., a public cloud network, receives data packets from nodes in the network through segments of the network. Based at least in part on (i) a source address of the data packet, (ii) a destination address of the data packet, and (iii) an identity of the segments of the network from which the data packets are received, the router determines a next node in the network to which the data packet is to be forwarded. The router may then forward the data packet through another segment of the network to the next node and then receive the data packet from the next node through the another segment.

TECHNICAL FIELD

The present disclosure relates generally to routing data packets through service chains within and between public cloud networks of multi-cloud fabrics.

BACKGROUND

With the continued increase in the proliferation and use of devices with Internet accessibility, the demand for Internet services and content has similarly continued to increase. The providers of the Internet services and content continue to scale the computing resources required to service the growing number of user requests without falling short of user-performance expectations. For instance, providers typically utilize large and complex datacenters to manage the network and content demands from users. The datacenters generally comprise server farms that host workloads that support the services and content, and further include network devices such as switches and routers to route traffic through the datacenters and enforce security policies.

Generally, these networks of datacenters are one of two types: private networks owned by entities such as enterprises or organizations (e.g., on-premises networks); and public cloud networks owned by cloud providers that offer computing resources for purchase by users. Often, enterprises will own, maintain, and operate on-premises networks of computing resources to provide Internet services and/or content for users or customers. However, as noted above, it can become difficult to satisfy the increasing demands for computing resources while maintaining acceptable performance for users. Accordingly, private entities often purchase or otherwise subscribe for use of computing resources and services from public cloud providers. For example, cloud providers can create virtual private clouds (also referred to herein as “private virtual networks”) on the public cloud and connect the virtual private cloud or network to the on-premises network in order to grow the available computing resources and capabilities of the enterprise. Thus, enterprises can interconnect their private or on-premises network of datacenters with a remote, cloud-based datacenter hosted on a public cloud, and thereby extend their private network.

However, because on-premises networks and public cloud networks are generally developed and maintained by different entities, there is a lack of uniformity in the policy management and configuration parameters between the datacenters in the on-premises networks and public cloud networks. This lack of uniformity can significantly limit an enterprise's ability to integrate their on-premises networks with public cloud networks by, for example, being unable to apply consistent policies, configuration parameters, routing models, and so forth. Various entities have developed software-defined network (SDN) and datacenter management solutions that translate the intents of enterprise or organizations from their on-premises networks into their virtual private cloud networks for applications or services that are deployed across multi-cloud fabrics or environments. Accordingly, these multi-cloud SDN solutions must continually adapt for changes occurring within the on-premises networks and public cloud networks, while maintaining the business and user intents of the enterprises or organizations that supplement their on-premises networks with computing resources from the public cloud networks.

For example, enterprises that manage on-premises networks of datacenters often isolate and segment their on-premises networks to improve scalability, resiliency, and security in their on-premises networks. To satisfy the entities' desire for isolation and segmentation, the endpoints in the on-premises networks can be grouped into endpoint groupings (EPGs) using, for example, isolated virtual networks that can be used to containerize the endpoints to allow for applying individualized routing models, policy models, etc., across the endpoints in the EPGs. Generally, each subnet in an EPG or other virtual grouping of endpoints is associated with a range of addresses that can be defined in routing tables used to control the routing for the subnet. Due to the large number of routing tables implemented to route traffic through the on-premises networks, the entities managing the on-premises networks utilize virtual routing and forwarding (VRF) technology such that multiple instances of a VRF routing table are able to exist in a router and work simultaneously. Accordingly, subnets of EPGs in the on-premises networks of entities are associated with respective VRF routing tables and routers are able to store and utilize multiple instances of VRF routing tables simultaneously.

Services may be spun up and inserted into and/or between cloud networks. Examples of such services include, for example, firewall, application load balancers (ALBs), mirroring/analytic services, etc. Often, such services are deployed as a service chain insertion into cloud networks. Such service chains should support multiple nodes in a chain in a flexible manner. The services should be placeable within the chain in any order and the traffic may or may not be destined to internet protocol (IP) addresses hosted by any of these services in the chain. High availability should be provided for each service node in the service chain. Thus, each service node of the service chain should include multiple instances of the service. It is desirable to have specific flows, e.g., source to destination combinations, in order to have granular control. It is also desirable to replicate service chains across regions in order to cater to traffic in any part of the public cloud in a cost-effective fashion. Furthermore, based on traffic, it is desirable to be able to elastically scale service nodes in order to be able to provide adequate services to traffic through the service node. Currently, cloud providers themselves do not offer sophisticated policy redirection or routing to allow these previously described functions. Routing is destination based only and the context of the leg of the service chain that has already been traversed is not available in data packets traversing the service chain.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

This disclosure describes a method for routing data packets through service chains within and between public cloud networks of multi-cloud fabrics. The method may include a router in a network, e.g., a public cloud network, receiving, through a first segment of the network, a data packet from a first node in the network. Based at least in part on (i) a source address of the data packet, (ii) a destination address of the data packet, and (iii) an identity of the first segment of the network, the router determines a second node of the network to which the data packet is to be forwarded. Based at least in part on the determining, the router may forward the data packet through a second segment of the network to the second node. The router may receive the data packet from the second node through the second segment. Based at least in part on (i) the source address of the data packet, (ii) the destination address of the data packet, and (iii) an identity of the second segment of the network, the router may determine a third node in the network to which the data packet is to be forwarded. Based at least in part on the determining, the router may forward the data packet through a third segment of the network to the third node.

Additionally, the network may comprise multiple sub-networks, e.g., the network may be in the form of a multi-cloud network including multiple public cloud networks and/or multiple regions or zones of a public cloud network. Thus, the router may be a first router and part of a first sub-network, and the method may further comprise the first router receiving, through the second segment, the data packet from the second node. Based at least in part on (i) the source address of the data packet, (ii) the destination address of the data packet, and (iii) the identity of the second segment of the network, the first router may determine a third node in the network to which the data packet is to be forwarded, the third node comprising a service. The first router may receive, from one or more routers in one or more sub-networks of the multiple sub-networks, an any IP address for other nodes in the one or more sub-networks that comprise the service. The router may select a fourth node in a second sub-network of the one or more sub-networks, where the fourth node comprises the service. The first router may forward the data packet through a third segment of the network to a second router in the second sub-network. The second router may forward the data packet through a fourth segment of the second sub-network to the fourth node. The second router may receive the data packet from the fourth node through the fourth segment. The second router may determine a next destination to which the data packet is to be forwarded. The second router may forward the data packet to the next destination.

EXAMPLE EMBODIMENTS

As noted above, enterprises and other organizations may own, maintain, and operate on-premises networks of computing resources for users or customers, and also for supporting internal computing requirements for running their organizations. However, due to the difficulties in satisfying the increasing demands for computing resources while maintaining acceptable performance for users, these enterprises may otherwise subscribe for use of computing resources and services from public cloud providers. For example, cloud providers can create virtual private clouds (also referred to herein as “private virtual networks”) on the public cloud and connect the virtual private cloud or network to the on-premises network in order to grow the available computing resources and capabilities of the enterprise. Thus, enterprises can interconnect their private or on-premises network of datacenters with a remote, cloud-based datacenter hosted on a public cloud, and thereby extend their private network.

However, the lack of uniformity between on-premises networks and public cloud networks across various dimensions, such as policy management, configuration parameters, etc., may significantly limit an enterprise's ability to integrate their on-premises networks with public cloud networks by, for example, being unable to apply consistent policies, configuration parameters, routing models, and so forth. Various SDN solutions have been developed to translate the intents of enterprises or organizations from their on-premises networks into their virtual private cloud networks for applications or services that are deployed across multi-cloud fabrics or environments. For example, Cisco's software-defined network and datacenter management solution, the Application-Centric Infrastructure (ACI), provides a comprehensive solution for automated network connectivity, consistent policy management, and simplified operations for multi-cloud environments. The Cisco Cloud ACI solution allows enterprises to extend their on-premises networks into various public clouds, such as Amazon Web Services (AWS), Google Cloud, Microsoft Azure, and so forth. The Cisco Cloud ACI solution provides an architectural approach for interconnecting and managing multiple regions and/or sites, such as by defining inter-cloud policies, providing a scalable architecture with full fault-domain isolation and change-domain isolation, and ensuring that issues cannot cascade and bring down the entire distributed environment.

Various difficulties arise for SDN solutions such as Cisco Cloud ACI when attempting to interconnect on-premises networks of datacenters with public cloud networks of datacenters. For example, cloud providers may impose different restrictions on networking configurations and policies, routing and policy models, and/or other restrictions for their public clouds. These restrictions may be different than the restrictions or permissions implemented by enterprises who have developed their on-premises networks of datacenters. However, to interconnect on-premises networks with public cloud networks, SDN solutions in the multi-cloud fabric space often have to reconcile those differences to seamlessly scale the on-premises networks across the public cloud networks.

As an example, VPCs (virtual private clouds in AWS) or VNets (virtual networks in Microsoft Azure) in a public cloud network generally need to connect to routers in order to route traffic between the endpoints in the VPCs or VNets of the public cloud network and endpoints or other devices in the on-premises network. SDN solutions attempt to automate this connectivity between the on-premises networks and public cloud networks, such as by using solutions offered by providers of the public cloud networks. As an example, AWS provides a Transit Gateway (TGW) for use in automating this connectivity. Generally, the TGW, or just gateway, comprises a distributed router that connects to multiple VPCs. Rather than establishing VPN connections from each VPC to the router, the gateway is able to connect multiple VPCs to a single gateway, and also their on-premises networks to the single gateway. Attaching VPNs to each VPC is a cumbersome and costly task, and the transit gateway provides a single connection from on-premises networks to reach multiple VPCs in the AWS public cloud with relatively high bandwidth compared to VPN connections

While these gateways are advantageous for various reasons, the different restrictions imposed for using these gateways surface issues for SDN controllers to solve when automating interconnectivity across a multi-cloud fabric. As an example, the gateways may require that each VPC connected to a particular gateway do not have overlapping subnets. Stated otherwise, all of the VPCs connected to a given gateway may be required to have unique address spaces or ranges (e.g., classless inter-domain routing (CIDR) blocks) that do not overlap. However, enterprises that manage on-premises networks often define address ranges, such as VRFs, that have overlapping address spaces (e.g., overlapping prefixes). In fact, that is one of the advantages of VRFs is to allow for overlapping subnets while providing segmentation and isolation for network paths.

One of the infrastructure blocks in a cloud networking/transit solution, e.g., Cisco Cloud ACI, is a cloud router that performs fine-grained routing between VPCs/VNets, or between VPCs/VNets and an on-premises network. The term VPC is used herein for describing examples but it should be understood that depending on the public cloud network, VNets may actually be used in place of VPCs and thus, the use of the term VPC is not meant to be limiting.

In configurations, a distributed cloud router may be provided for use as the networking block that connects source VPCs and destination VPCs of a data packet, as well as services provided within VPCs, e.g., a service chain between the source VPC and the destination VPC. The distributed cloud router may span multiple regions of public cloud networks and may be across multiple public cloud networks (e.g., AWS cloud networks and Microsoft Azure public cloud networks). Each instance of the cloud router may run or operate within one infra VPC within a region.

In configurations, data packet traffic (referred to herein as “traffic”) may be routed between VPCs through tunnels running between user VPCs (e.g., source VPCs and destination VPCs) and infra VPCs. Similarly, traffic between any two networks (cloud-to-cloud or cloud-to-on-premises) may also be routed via tunnels. Additionally, in configurations, traffic may be routed from one infra VPC to another infra VPC through tunnels. For example, internet protocol security (IPSec)/generic routing encapsulation (GRE) tunnels may span between two CSR instances across regions.

In configurations, different tunnels are provided within each CSR (cloud router) to represent different legs/combinations (e.g., segments) of the service chain. Thus, based on the ingress tunnel interface of the data packet in the CSR, the previous node traversed in the service chain may be inferred and therefore the data packet may be guided toward the next service node in the service chain. Thus, the same data packet may traverse through the same CSR multiple times. Each time the data packet may be forwarded to a different service node in the service chain without changing any part of the original data packet (e.g., source IP address and destination IP address).

For example, assume a service chain includes service node A and service node B (e.g., service A VPC and service B VPC) in the service chain. A tunnel is created in the CSR for each of the service nodes. For example, tunnel one may be between a source user VPC and the CSR (thus no previous service). Tunnel two may extend between service node A and the CSR, e.g., the previous service is service A. Tunnel three may extend between service node B and the CSR, e.g., the previous service is service B. In configurations, the determination as to the previous service is made when the data packet returns from the service towards the CSR. Tunnel four may extend between the CSR and a destination user VPC, e.g., no further services are to be performed before delivery to the destination VPC. Each of the tunnels may be in different VRFs so that a current leg may be identified as a segment (or VRF) in the CSR. This may help in customizing a forwarding look-up table, route table, for the same pair of source and destination IP addresses of data packets (e.g., source IP address and destination IP address combinations) that is hopping through the same CSR to get to different services without any changes to data packet address information. Alternatively, all tunnels in the CSR may belong to the same VRF, but policy-based routing (PBR) rules may be different based on (tunnel, source, destination), combinations.

Thus, a route table may be defined at the CSR that provides rules for data packets from first user VPC (source) and second user VPC (destination) combinations. For example, based on a first source VPC and destination VPC combination, the CSR knows to route data packets through a service chain that includes services A and B enroute to the destination VPC, while based on a second source VPC and destination VPC combination, the CSR knows to route data packets through a service chain that include services A, B, and C enroute to the destination VPC. Any number of services may be included in the service chain.

Thus, for example, based on the first source VPC and destination VPC combination, a data packet received by the CSR via tunnel one from the source VPC may be routed to the service A node using tunnel two. After the service A is performed, the data packet may be routed back to the CSR via tunnel two. Since the CSR receives the data packet via tunnel two, based on the route table, e.g., the source VPC and the destination VPC, the CSR routes the data packet on tunnel three to the service B node. After service B is performed, the data packet is routed back to the CSR via tunnel three. Based on the route table, the CSR knows to now route the data packet via tunnel four to the destination user VPC since no services are left to be performed.

In configurations, multiple regions of a public cloud network may each have the same service VPCs, which may also include multiple instances that provide the services. For example, a first public cloud network region and a second public cloud network region may each have a service A VPC. The service A VPC of both regions may carry the same anycast IP address. The CSR of the regions may advertise this anycast IP address to other CSRs and other regions through border gateway protocol (BGP). The anycast IP of the service node is the PBR rule destination. When multiple cloud router CSRs advertise the anycast IP in the regions of the public cloud network(s), in configurations the service VPC that is closest to the CSR receiving the broadcast may be chosen. Generally, if the service A VPC of the same region of the CSR receiving the broadcast is functioning, then that service A VPC is chosen, e.g., the locally attached VPC in the same zone/region of the receiving CSR. However, if the service VPC has failed or is overloaded, the anycast IP address of a service A VPC of an adjacent region (or adjacent zone) may automatically be chosen.

Thus, the data packet may be routed via a tunnel from a first CSR (the receiving CSR) to a second CSR (CSR of the adjacent region). The second CSR may then route the data packet along the appropriate tunnel in the corresponding region to the service A VPC. When the service is completed, the data packet may be routed back to the second CSR, which may forward the data packet back to the first CSR, which may then continue moving the data packet through the service chain and on to the destination user VPC. In configurations, the second CSR may complete the process of moving the data packet through the service chain within its region and on to the destination VPC.

Thus, since all CSRs in various regions and/or zones advertise the same anycast IP, for example, service A, even if a local instance of service A goes down, a CSR may forward a data packet to a remote instance of service A in another region/zone via the CSR in the region/zone.

In order to provide service node load balancing and redundancy, multiple instances of the services may be instantiated in the service nodes. For example, the service A VPC may include multiple instances that may provide service A. If one of the instances fails, the other instances may provide service A. Additionally, in order to provide load balancing within the service A VPC, the CSR may route the data packet to particular service A instance.

In configurations, auto scaling may be provided by adding a new instance in any of the service VPCs. A route (tunnel) for the new instance from the CSR in the infra VPC may be created. Also, the BGP weight may be controlled to prefer one instance or another instance in a remote location (e.g., different region) so that traffic may be load balanced accordingly. BGP weight may cater to the health or the load of a particular instance of a service node.

FIG. 1Aschematically illustrates a multi-cloud fabric100that includes two public cloud networks102aand102b(collectively referred to as public cloud networks102). The public cloud networks102a,102binclude two regions104a,104b, and104c,104d, respectively, (collectively referred to as regions104). The public cloud networks102may include more or fewer regions104. Each region104includes VPCs/VNets106that may be configured as user VPCs/VNets or service VPCs/VNets. For simplicity, the VPCs/VNets106are referred to collectively herein as VPCs106. The multi-cloud fabric100also includes an on-premises network108. In configurations, the public cloud networks102a,102b, the regions104a,104b,104c,104d, and/or on-premises network108may be considered sub-networks.

The multi-cloud fabric100also includes a multi-site controller110(e.g., a multi-site application policy infrastructure controller (APIC)) that communicates with cloud controllers112a,112bin the public cloud networks102a,102b(e.g., cloud APICs), as well as a controller in the on-premises network108. The multi-site controller112may work with the controllers to manage and implement policies and configurations on both the public cloud networks102a,102band the on-premises network108. The multi-site controller112can implement, such as by translating, a same policy model in the public cloud networks102a,102b, and the on-premises network108, which can be based on a particular SDN or datacenter solution such as Cisco's ACI. For example, the multi-site controller112can implement VRFs, end-points (EPs), end-point groups (EPGs) and associated policies in the public cloud networks106a,106b, as well as the on-premises network108.

In configurations, data packet traffic (referred to herein as “traffic”) may be routed between the VPCs106through tunnels114running between user VPCs106a-106h(e.g., source VPCs and destination VPCs) and infra VPCs116a-116d(collectively referred to as infra VPCs116) that include CSRs118a-118d(collectively referred to as CSRs118). Similarly, traffic may be routed between service VPCs106i-106pand infra VPCs116a-116dto provide service chains. Traffic between any two networks (cloud-to-cloud102a-102bor cloud-to-on-premises102a,102b-108) may also be routed via tunnels120a-120c. Additionally, in configurations, traffic may be routed from one infra VPC116(or infra VNET) to another infra VPC116(or infra VNET) via tunnels120a-120c. For example, internet protocol security (IPSec)/generic routing encapsulation (GRE) tunnels may span between two CSR instances118across regions104. The CSRs118a-118dinclude route tables122a-122d, respectively, as will be discussed further herein.

Thus, based on the ingress tunnel interface of a data packet in the CSR118a, the previous node (e.g., service VPC106i) traversed in the service chain may be inferred and therefore, the data packet may be guided toward the next service node (e.g., service VPC106j) in the service chain. Thus, the same data packet may traverse through the CSR118amultiple times. Each time the data packet may be forwarded to a different service node in the service chain without changing any part of the original data packet (e.g., source IP address and destination IP address).

For example, assume a service chain includes service VPC106i, which performs service A in the service chain, and service VPC106j, which performs service B in the service chain. Tunnels114a,114b,114i, and114jare created in the CSR118afor each of the VPCs106a,106b,106i, and106j. For example, tunnel114abetween the user VPC106a(which may be the source for a data packet) and the CSR118a(thus no previous service in the service chain). Tunnel114imay extend between service VPC106iand the CSR118a, e.g., the previous service is service A. Tunnel114jmay extend between service VPC106jand the CSR118a, e.g., the previous service is service B. Tunnel114bmay extend between the CSR118aand user VPC106b(which may be the destination for the data packet), e.g., no further services are to be performed before delivery to the destination VPC. Each of the tunnels114a,114b,114i, and114jmay be in different VRFs so that a current leg may be identified as a segment (or VRF) in the CSR118a. This may help in customizing a forwarding look-up table, e.g., route table122, for the same pair of source and destination IP addresses of data packets (e.g., source IP address and destination IP address combinations) that is hopping through the CSR118ato get to different services without any changes to data packet address information. Alternatively, all tunnels114in the CSR118amay belong to the same VRF, but policy-based routing (PBR) rules may be different based on (tunnel, source, destination) combinations. As is known, PBR is a technique used to make routing decisions based on policies set by the network administrator. In a particular, when a router receives a packet, the router normally decides where to forward the packet based on the destination address in the packet, which is then used to look up an entry in a routing table. However, in some cases, there may be a need to forward the packet based on other criteria. For example, a network administrator might want to forward a packet based on the source address, not the destination address. This permits routing of packets originating from different sources to different networks even when the destinations are the same and can be useful when interconnecting several private networks. PBR may also be based on the size of the packet, the protocol of the payload, or other information available in a packet header or payload.

Thus, a route table122amay be defined at the CSR118athat provides rules for data packets from first user VPC (source)106aIP address and second user VPC (destination)106bIP address combinations. For example, based on the source VPC106aand the destination VPC106bIP address combination, the CSR118aknows to route data packets from VPC106adestined for VPC106bthrough a service chain that includes service VPC106iand service VPC106jenroute to the destination VPC. While only two service VPCs106i,106jare illustrated, any number of service VPCs106may be included in the service chain.

Thus, for example, based on the source VPC106aand destination VPC106bcombination, a data packet received by the CSR118avia tunnel114afrom the source VPC106amay be routed to the service VPC106iusing tunnel114i. After the service A is performed, the data packet may be routed back to the CSR118avia tunnel114i. Since the CSR118areceives the data packet via tunnel114i, based on the route table122, e.g., the source VPC106aand the destination VPC106bcombination in the route table122, the CSR118aroutes the data packet on tunnel114jto the service VPC106j. After service B is performed, the data packet is routed back to the CSR118avia tunnel114j. Based on the route table122, the CSR118aknows to now route the data packet via tunnel four to the destination user VPC106bvia tunnel114bsince no services are left to be performed.

Referring toFIG. 1C, in configurations, multiple regions104a,104bof the public cloud network102aand/or multiple regions104c,104dof public cloud network102bmay each have some or all of the same service VPCs, e.g., services VPC106i,106jthat provide services A and B, respectively. Service VPCs106a,106jmay also include multiple instances that provide services A and B, respectively. In configurations, the service VPCs106iof the regions104a-104dmay carry the same anycast IP address A and the service VPCs106j, of the regions104a-104dmay carry the same anycast IP address B. The CSRs118of the regions may advertise the anycast IP addresses to other CSRs118and other regions104through BGP.

As an example, the anycast IP address A of the service VPC106imay be broadcast by the CRS118and is the PBR rule destination. When multiple CSRs118advertise the anycast IP address A in the regions104of the public cloud networks102a,102b, in configurations the service VPC106ithat is closest to the CSR, e.g., CSR118a, receiving the broadcast may be chosen. Generally, if the service VPC106iof the same region104aof the CSR118areceiving the broadcast is functioning, then that service VPC106iis chosen, e.g., the locally attached VPC106iin the same zone/region104aof the receiving CSR118a. However, if the service VPC106ihas failed or is overloaded, the anycast IP address A of a service VPC106iof an adjacent region (or adjacent zone), e.g., region104bmay automatically be chosen.

Thus, referring toFIG. 1C, the data packet may be routed via a tunnel120afrom CSR118a(the receiving CSR) to the CSR118bof the region104b(CSR of the adjacent region). The CSR118bmay then route the data packet along the appropriate tunnel, e.g., tunnel114i2in the corresponding region104bto the service VPC106i2. When the service A is completed, the data packet may be routed back to the CSR118b, which may forward the data packet back to the CSR118a. The CSR118amay then continue moving the data packet through the service chain, e.g., to service VPC106j1as previously described, and on to the destination user VPC106b. In configurations, the CSR118bmay complete the process of moving the data packet through the service chain within its region, e.g., service VPC106j2of region104b, as previously described, and then back to CSR118a, which forwards the data packet on to the destination VPC106bof region104a.

Thus, since all CSRs118in various regions104advertise the same anycast IP addresses, for example, IP service address A, even if a local instance of the service VPC106ithat provides service A goes down, a CSR may forward a data packet to a remote service VPC that provides service A in another region/zone via the CSR in that region/zone.

In order to provide service VPC106load balancing and redundancy, multiple instances of the services may be instantiated in the service VPCs106. For example, the service VPC106imay include multiple instances that may provide service A. If one of the instances fails, the other instances may provide service A. Additionally, in order to provide load balancing within the service VPC106i, the CSR118amay route the data packet to a particular service A instance in the VPC106i. The cloud controllers112may manage the load balancing among instances within service VPCs. In configurations, auto scaling may be provided by instantiating a new instance of service in any of the service VPCs106by the cloud controllers112. A route (tunnel) for the new instance from the CSR118in the corresponding infra VPC114may be created by the cloud controllers112. Also, a BGP weight may be controlled by the cloud controllers112to prefer one instance or another instance in a service VPC106so that traffic may be load balanced accordingly. For example, if a first instance in VPC106iin region104ais over-loaded, the BGP weight may be adjusted by the cloud controller112ain order to make BGP prefer a second instance that is not as loaded. BGP weight may cater to the health or the load of a particular instance within a service VPC106.

Additionally, the cloud controllers112may load balance among service VPCs106across regions104and/or networks102. For example, if the local service VPC106iin region104ais over-loaded, the BGP weight may be adjusted by the cloud controller112ain order to make BGP prefer a remote service VPC106iin another region, e.g., region104b, that is not as loaded.

FIG. 2illustrates a flow diagram of an example method200and illustrates aspects of the functions performed at least partly by one or more devices in the multi-cloud fabric100as described inFIGS. 1A-1C. The logical operations described herein with respect toFIG. 2may be implemented (1) as a sequence of computer-implemented acts or program modules running on a computing system, and/or (2) as interconnected machine logic circuits or circuit modules within the computing system.

FIG. 2illustrates a flow diagram of an example method200for routing data packets through service chains within public cloud networks of multi-cloud fabrics. In some examples, the method200may be performed by a system comprising one or more processors and one or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform the method200.

At202, a router in a network receives a data packet through a first segment of the network. At204, based at least in part on (i) a source address of the data packet, (ii) a destination address of the data packet, and (iii) an identity of the first segment of the network, the router determines a second node in the network to which the data packet is to be forwarded. At206, based at least in part on the determining, the router forwards the data packet through a second segment of the network to the second node.

At208, the router receives the data packet through the second segment from the second node. At210, based at least in part on (i) the source address of the data packet, (ii) the destination address of the data packet, and (iii) an identity of the second segment of the network, the router determines a third node in the network to which the data packet is to be forwarded. At212, based at least in part on the determining, the router forwards the data packet through a third segment of the network to the third node.

FIG. 3is a computing system diagram illustrating a configuration for a datacenter300that can be utilized to implement aspects of the technologies disclosed herein. The example datacenter300shown inFIG. 3includes several server computers302A-302F (which might be referred to herein singularly as “a server computer302” or in the plural as “the server computers302”) for providing computing resources. In some examples, the resources and/or server computers302may include, or correspond to, the VPCs106described herein.

The server computers302can be standard tower, rack-mount, or blade server computers configured appropriately for providing the computing resources described herein. As mentioned above, the computing resources provided by the cloud computing networks102aand102bcan be data processing resources such as VM instances or hardware computing systems, database clusters, computing clusters, storage clusters, data storage resources, database resources, networking resources, and others. Some of the servers302can also be configured to execute a resource manager capable of instantiating and/or managing the computing resources. In the case of VM instances, for example, the resource manager can be a hypervisor or another type of program configured to enable the execution of multiple VM instances on a single server computer302. Server computers302in the datacenter300can also be configured to provide network services and other types of services.

In the example datacenter300shown inFIG. 3, an appropriate LAN308is also utilized to interconnect the server computers302A-302F. It should be appreciated that the configuration and network topology described herein has been greatly simplified and that many more computing systems, software components, networks, and networking devices can be utilized to interconnect the various computing systems disclosed herein and to provide the functionality described above. Appropriate load balancing devices or other types of network infrastructure components can also be utilized for balancing a load between datacenters300, between each of the server computers302A-302F in each datacenter300, and, potentially, between computing resources in each of the server computers302. It should be appreciated that the configuration of the datacenter300described with reference toFIG. 3is merely illustrative and that other implementations can be utilized.

In some examples, the server computers302may each execute one or more virtual resources that support a service or application provisioned across a set or cluster of servers302. The virtual resources on each server computer302may support a single application or service, or multiple applications or services (for one or more users).

In some instances, the cloud computing networks102aand102bmay provide computing resources, like application containers, VM instances, and storage, on a permanent or an as-needed basis. Among other types of functionality, the computing resources provided by cloud computing networks may be utilized to implement the various services described above. The computing resources provided by the cloud computing networks can include various types of computing resources, such as data processing resources like application containers and VM instances, data storage resources, networking resources, data communication resources, network services, and the like.

The computing resources provided by the cloud computing networks may be enabled in one embodiment by one or more datacenters300(which might be referred to herein singularly as “a datacenter300” or in the plural as “the datacenters300”). The datacenters300are facilities utilized to house and operate computer systems and associated components. The datacenters300typically include redundant and backup power, communications, cooling, and security systems. The datacenters300can also be located in geographically disparate locations. One illustrative embodiment for a server computer302that can be utilized to implement the technologies disclosed herein will be described below with regard toFIG. 4.

FIG. 4shows an example computer architecture for a server computer302capable of executing program components for implementing the functionality described above. The computer architecture shown inFIG. 4illustrates a conventional server computer, workstation, desktop computer, laptop, tablet, network appliance, e-reader, smartphone, or other computing device, and can be utilized to execute any of the software components presented herein. The server computer302may, in some examples, correspond to physical devices or resources described herein.

The server computer302includes a baseboard402, or “motherboard,” which is a printed circuit board to which a multitude of components or devices can be connected by way of a system bus or other electrical communication paths. In one illustrative configuration, one or more central processing units (“CPUs”)404operate in conjunction with a chipset406. The CPUs404can be standard programmable processors that perform arithmetic and logical operations necessary for the operation of the server computer302.

The chipset406provides an interface between the CPUs404and the remainder of the components and devices on the baseboard402. The chipset406can provide an interface to a RAM408, used as the main memory in the server computer302. The chipset406can further provide an interface to a computer-readable storage medium such as a read-only memory (“ROM”)410or non-volatile RAM (“NVRAM”) for storing basic routines that help to startup the server computer302and to transfer information between the various components and devices. The ROM410or NVRAM can also store other software components necessary for the operation of the server computer302in accordance with the configurations described herein.

The server computer302can operate in a networked environment using logical connections to remote computing devices and computer systems through a network, such as the network308. The chipset406can include functionality for providing network connectivity through a NIC412, such as a gigabit Ethernet adapter. The NIC412is capable of connecting the server computer302to other computing devices over the network308. It should be appreciated that multiple NICs412can be present in the server computer302, connecting the computer to other types of networks and remote computer systems.

The server computer302can be connected to a storage device418that provides non-volatile storage for the computer. The storage device418can store an operating system420, programs422, and data, which have been described in greater detail herein. The storage device418can be connected to the server computer302through a storage controller414connected to the chipset406. The storage device418can consist of one or more physical storage units. The storage controller414can interface with the physical storage units through a serial attached SCSI (“SAS”) interface, a serial advanced technology attachment (“SATA”) interface, a fiber channel (“FC”) interface, or other type of interface for physically connecting and transferring data between computers and physical storage units.

In addition to the mass storage device418described above, the server computer302can have access to other computer-readable storage media to store and retrieve information, such as program modules, data structures, or other data. It should be appreciated by those skilled in the art that computer-readable storage media is any available media that provides for the non-transitory storage of data and that can be accessed by the server computer302. In some examples, the operations performed by the cloud computing network, and or any components included therein, may be supported by one or more devices similar to server computer302. Stated otherwise, some or all of the operations performed by the cloud computing networks102aand102b, and or any components included therein, may be performed by one or more server computers302operating in a cloud-based arrangement.

As mentioned briefly above, the storage device418can store an operating system420utilized to control the operation of the server computer302. According to one embodiment, the operating system comprises the LINUX operating system. According to another embodiment, the operating system comprises the WINDOWS® SERVER operating system from MICROSOFT Corporation of Redmond, Wash. According to further embodiments, the operating system can comprise the UNIX operating system or one of its variants. It should be appreciated that other operating systems can also be utilized. The storage device418can store other system or application programs and data utilized by the server computer302.

In one embodiment, the storage device418or other computer-readable storage media is encoded with computer-executable instructions which, when loaded into the server computer302, transform the computer from a general-purpose computing system into a special-purpose computer capable of implementing the embodiments described herein. These computer-executable instructions transform the server computer302by specifying how the CPUs404transition between states, as described above. According to one embodiment, the server computer302has access to computer-readable storage media storing computer-executable instructions which, when executed by the server computer302, perform the various processes described above with regard toFIGS. 1A, 1B, 1C, and 2. The server computer302can also include computer-readable storage media having instructions stored thereupon for performing any of the other computer-implemented operations described herein.

The server computer302can also include one or more input/output controllers416for receiving and processing input from a number of input devices, such as a keyboard, a mouse, a touchpad, a touch screen, an electronic stylus, or other type of input device. Similarly, an input/output controller416can provide output to a display, such as a computer monitor, a flat-panel display, a digital projector, a printer, or other type of output device. It will be appreciated that the server computer302might not include all of the components shown inFIG. 4, can include other components that are not explicitly shown inFIG. 4, or might utilize an architecture completely different than that shown inFIG. 4.

The server computer302may support a virtualization layer, such as one or more virtual resources executing on the server computer302. In some examples, the virtualization layer may be supported by a hypervisor that provides one or more virtual machines running on the server computer302to perform functions described herein. The virtualization layer may generally support a virtual resource that performs at least portions of the techniques described herein.