Methods and apparatus for application aware hub clustering techniques for a hyper scale SD-WAN

Abstract

Some embodiments provide a method for a software-defined wide area network (SD-WAN) connecting first and second sites, with the first site including an edge node and the second site including multiple forwarding hub nodes. At the edge node of the first site, the method receives a packet of a particular flow including a flow attribute. The method uses the flow attribute to identify a hub-selection rule from multiple hub-selection rules, each hub-selection rule identifying at least one forwarding hub node at the second site for receiving one or more flows from the first site, and at least one hub-selection rule identifying at least one forwarding hub node that is not identified by another hub-selection rule. The method uses the identified hub-selection rule to identify a forwarding hub node for the particular flow. The method then sends the packet from the edge node at the first site to the identified forwarding hub node at the second site.

Description

BACKGROUND

Today, single clusters of forwarding hub nodes in software-defined wide area networks (SD-WANs) are tied to fixed scale-out ratios. For example, an N node cluster would have a scale out factor of 1:N as a fixed ratio. If the first assigned cluster node is overloaded, the next node (i.e., second node) in the cluster takes over, and so on until the span reaches all available N nodes. The clustering services today are oblivious to application requirements and bind a rigid scheme for providing clustering services to multiple peering edge nodes (e.g., in a hub and spoke topology). In this manner, a high priority real time application traffic flow is treated the same way as that of a low priority (e.g., bulk) traffic flow with respect to the scale out ratio within the cluster. This can subsequently lead to sub-optimal performance for provisioning and load balancing traffic within the cluster, and, in some cases, under-utilization of cluster resources.

BRIEF SUMMARY

Some embodiments provide a software-defined wide area network (SD-WAN) that includes a first branch location (first branch) and a datacenter location (datacenter). The datacenter includes multiple forwarding hub nodes, while the branch site includes at least one edge forwarding node. The edge node of the branch site receives a packet of a particular flow, the packet having a flow attribute. The edge node uses the flow attribute of the packet to identify a hub-selection rule from multiple hub-selection rules, each of which identifies a set of one or more forwarding hub nodes of the datacenter for receiving one or more flows from the branch site. At least one hub-selection rule identifies at least one forwarding hub node that is unique to the hub-selection rule (i.e., not identified by another hub-selection rule). The edge node uses the identified hub-selection rule to identify a forwarding hub node for the particular flow, and sends the packet from the branch site to the identified forwarding hub node of the datacenter.

In some embodiments, the forwarding hub nodes serve as gateways of the SD-WAN that provide access from the first branch site to other branch sites or third-party datacenters. The third party datacenters, in some embodiments, include software as a service (SaaS) datacenters (e.g., datacenters for video conferencing SaaS providers, for middlebox (e.g., firewall) service providers, for storage service providers, etc.). In some embodiments, the branch sites and third party datacenters are topologically arranged around the datacenter in a hub and spoke topology such that traffic between two sites passes through the forwarding hub nodes at the datacenter (i.e., regardless of the geographic location of the sites).

Conjunctively, or alternatively, the forwarding hub nodes in some embodiments provide branch sites with access to compute, storage, and service resources of the datacenter. Examples of such resources include compute machines (e.g., virtual machines and/or containers providing server operations), storage machines (e.g., database servers), and middlebox service operations (e.g., firewall services, load balancing services, encryption services, etc.). In some embodiments, the connections between the first branch site and the datacenter hub nodes are secure encrypted connections that encrypt packets exchanged between the edge node of the first branch site and the datacenter hub nodes. Examples of secure encrypted connections used in some embodiments include VPN (virtual private network) connections, or secure IPsec (Internet Protocol security) connections.

In some embodiments, the branch edge node identifies a hub-selection rule for a received packet by matching flow attributes of the packet with match criteria of a hub-selection rule, which associates the match criteria with one or more identifiers of one or more forwarding hub nodes of the datacenter. The match criteria of the hub-selection rules are defined in terms of flow attributes, according to some embodiments. The flow attributes that are used for the match operation in some embodiments include the received packet's flow identifier (e.g., the received packets five tuple identifier, i.e., source and destination Internet Protocol (IP) addresses/port numbers and protocol).

Conjunctively, or alternatively, the flow identifier used for the match operation in some embodiments includes flow attributes other than layers 2-4 (L2-L4) header values, such as layer 7 (L7) attributes. Examples of L7 attributes include AppID (e.g., traffic type identifier), user identifier, group identifier (e.g., an activity directory (AD) identifier), threat level, and application name/version. To obtain the L7 attributes, some embodiments perform deep packet inspection (DPI) on the packet.

By using L7 attributes to define the match criteria of hub-selection rules, some embodiments allow flows to be forwarded to different forwarding hub nodes based on different contextual attributes associated with the flows (i.e., allocating different forwarding hub nodes for different categories of flows). For instance, in some embodiments, the hub-selection rules associate different sets of flows that contain different types of traffic (as identified by different AppIDs) with different sets of forwarding hub nodes. Allocating the forwarding hub nodes based on L7 attributes, in some embodiments, allows for certain categories of traffic to be prioritized over other categories of traffic. For example, a first category of flows that contains a first type of traffic determined to be a high priority type of traffic (e.g., VoIP) may be allocated more forwarding hub nodes than a second category of flows that contains a second type of traffic determined to be a low priority type of traffic.

As mentioned above, the match criteria of one or more hub-selection rules can be defined in terms of other L7 contextual attributes, such as user identifier, group identifier, threat level, and application name/version. For example, in some embodiments, the hub-selection rules associate sets of flows having user identifiers that correspond to executive staff or financial staff with a first set of forwarding hub nodes, while associating sets of flows having user identifiers other than those that correspond to executive staff or financial state with a second set of forwarding hub nodes.

The hub-selection rules, in some embodiments, each identify a different group of forwarding hub nodes available for selection (e.g., available for processing flows in the same category as the matching packet). Accordingly, in some embodiments, when a matching hub-selection rule is found, the edge node selects a forwarding hub node from the group of forwarding hub nodes identified by the hub-selection rule. In some embodiments, the edge node relies on load balancing criteria (e.g., weight values) along with load balancing policies (e.g., round robin, etc.) to select a forwarding hub node from the group.

In some embodiments, a controller for the SD-WAN provides the hub-selection rules to the branch edge node. The controller receives network traffic statistics from the forwarding hub nodes, aggregates the received statistics by flow category, and analyzes the statistics to identify flow categories that need additional, or fewer, forwarding hub nodes in their respective forwarding hub node groups. In some embodiments, the controller determines that additional or fewer forwarding hub nodes are needed for processing a particular category of flows when a volume of traffic associated with the particular category of flows is found to exceed a maximum threshold value for traffic or fall below a minimum threshold value for traffic. When the controller determines that additional forwarding hub nodes are needed for a particular flow category, the controller directs a manager (e.g., a server) of the datacenter to generate the additional forwarding hub nodes, according to some embodiments. Conversely, when the controller determines in some embodiments that fewer forwarding hub nodes are needed for a particular flow category, the controller may reallocate the excess forwarding hub nodes to other flow categories.

When the controller directs the manager of the datacenter to generate additional forwarding hub nodes, in some embodiments, the controller sends an updated list of forwarding hub node groups to the branch edge node. In some embodiments, the updated list is provided via updated hub-selection rules (e.g., with updates to the forwarding hub node groups specified for each hub-selection rule). The forwarding hub node groups specified for each hub-selection rule, in some embodiments, are identified by group identifiers. Thus, the controller in some embodiments simply provides updated group identifiers to the edge nodes. Conversely, or alternatively, the controller in some embodiments provides the updated group identifiers as updated hub-selection rules that reference the updated group identifiers.

The preceding Summary is intended to serve as a brief introduction to some embodiments of the invention. It is not meant to be an introduction or overview of all inventive subject matter disclosed in this document. The Detailed Description that follows and the Drawings that are referred to in the Detailed Description will further describe the embodiments described in the Summary as well as other embodiments. Accordingly, to understand all the embodiments described by this document, a full review of the Summary, the Detailed Description, the Drawings, and the Claims is needed. Moreover, the claimed subject matters are not to be limited by the illustrative details in the Summary, the Detailed Description, and the Drawings.

BRIEF DESCRIPTION OF FIGURES

The novel features of the invention are set forth in the appended claims. However, for purposes of explanation, several embodiments of the invention are set forth in the following figures.

FIG. 1 conceptually illustrates an example of an SD-WAN that includes multiple branch sites that connect to hubs of a datacenter, according to some embodiments.

FIG. 2 conceptually illustrates another example of an SD-WAN that includes a controller cluster for configuring the components of the SD-WAN, according to some embodiments.

FIG. 3 conceptually illustrates example components of an edge node of a branch site, according to some embodiments.

FIG. 4 illustrates a process for an edge node for selecting a hub to which to forward a packet, according to some embodiments.

FIG. 5 illustrates a process for a controller that manages the configuration of edge nodes and hubs of an SD-WAN, according to some embodiments.

FIG. 6 conceptually illustrates a computer system with which some embodiments of the invention are implemented.

DETAILED DESCRIPTION

In the following detailed description of the invention, numerous details, examples, and embodiments of the invention are set forth and described. However, it will be clear and apparent to one skilled in the art that the invention is not limited to the embodiments set forth and that the invention may be practiced without some of the specific details and examples discussed.

Some embodiments provide a software-defined wide area network (SD-WAN) that includes one or more branch sites (branch locations) and a datacenter (datacenter location). The datacenter includes multiple forwarding hub nodes (referred to as “hubs” below), while each of the branch sites includes at least one edge node. In some embodiments, edge nodes are deployed at each of the branch sites in high-availability pairs such that each branch site includes an active edge node and a standby edge node in case of failure. The edge nodes of the branch sites receive packets of flows, the packets having flow attributes. The edge nodes use the flow attributes of the packets to identify hub-selection rules from multiple hub-selection rules, each of which identifies a set of one or more hubs of the datacenter for receiving one or more flows from the branch sites and includes match criteria defined in terms of flow attributes. In some embodiments, at least one hub-selection rule identifies at least one hub that is unique to the hub-selection rule (i.e., not identified by another hub-selection rule). The edge nodes use the identified hub-selection rules to identify hubs for the flows, and send the packets from the branch sites to the identified hubs of the datacenter (i.e., according to the identified hub-selection rules).

FIG. 1 conceptually illustrates an SD-WAN network (also referred to as a virtual network below) for connecting multiple branch sites to each other and to resources of a centralized datacenter. In this example, the SD-WAN 100 is created for connecting the branch sites 130-136 to each other and to resources 160 of the datacenter 105 (datacenter), as well as the SaaS datacenter 140, via the sets of hubs 112-116 (also referred to herein as forwarding hub nodes) of the hub cluster 110. The SD-WAN 100 is established by a controller cluster (not shown), the sets of hubs 112-116, and four edge nodes 120-126, one in each of the branch sites 130-136.

The edge nodes in some embodiments are edge machines (e.g., virtual machines (VMs), containers, programs executing on computers, etc.) and/or standalone appliances that operate at multi-computer locations of the particular entity (e.g., at an office or datacenter of the entity) to connect the computers at their respective locations to the hubs and other edge nodes (if so configured). In some embodiments, the edge nodes are clusters of edge nodes at each of the branch sites. In other embodiments, the edge nodes are deployed to each of the branch sites as high-availability pairs such that one edge node in the pair is the active edge node and the other edge node in the pair is the standby edge node that can take over as the active edge node in case of failover. Also, in this example, the sets of hubs 112-116 are deployed as machines (e.g., VMs or containers) in the same public datacenter 105. In other embodiments, the hubs may be deployed in different public datacenters.

An example of an entity for which such a virtual network can be established includes a business entity (e.g., a corporation), a non-profit entity (e.g., a hospital, a research organization, etc.), and an education entity (e.g., a university, a college, etc.), or any other type of entity. Examples of public cloud providers include Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, etc., while examples of entities include a company (e.g., corporation, partnership, etc.), an organization (e.g., a school, a non-profit, a government entity, etc.), etc. In other embodiments, the hubs can also be deployed in private cloud datacenters of a virtual WAN provider that hosts hubs to establish SD-WANs for different entities.

In the example of FIG. 1, the hubs are multi-tenant forwarding elements that can be used to establish secure connection links (e.g., tunnels) with edge nodes at the particular entity's multi-computer sites, such as branch sites (branch offices), datacenters (e.g., third party datacenters), etc. For example, the sets of hubs 112-116 in the cluster 110 provide access from each of the branch sites 130-136 to each of the other branch sites 130-136, as well as to the SaaS datacenter 140, via the connection links 150, which terminate at the cluster 110 as shown. These multi-computer sites are often at different physical locations (e.g., different buildings, different cities, different states, etc.), according to some embodiments. In some embodiments the forwarding hub nodes can be deployed as physical nodes or virtual nodes. Additionally, the forwarding hub nodes can be deployed on the premises of a datacenter premises in some embodiments, while in other embodiments, the forwarding hub nodes can be deployed on a cloud (e.g., as a set of virtual edges configured as a cluster).

Additionally, the example of FIG. 1, the sets of hubs 112-116 also provide access to resources 160 (e.g., machines) of the datacenter 105. More specifically, the set of hubs 116 provides access to the resources 160. The resources in some embodiments include a set of one or more servers (e.g., web servers, database servers) within a microservices container (e.g., a pod). Conjunctively, or alternatively, some embodiments include multiple such microservices containers, each accessible through a different set of one or more hubs of the datacenter. The resources, as well as the hubs, are within the datacenter premises, according to some embodiments.

The edge nodes 120-126 are forwarding elements that exchange packets with one or more hubs and/or other edge nodes through one or more secure connection links, according to some embodiments. In this example, all secure connection links of the edge nodes are with the sets of hubs 112-116. FIG. 1 also illustrates that through the set of hubs 112, the SD-WAN 100 allows the edge nodes to connect to the SaaS datacenter 140. While not shown, some embodiments include multiple different SaaS datacenters, which may each be accessible via different sets of hubs, according to some embodiments. In some embodiments, the SaaS datacenters include datacenters for video conferencing SaaS providers, for middlebox (e.g., firewall) service providers, for storage service providers, etc. As shown, the branch sites 130-136 and SaaS datacenter 140 are topologically arranged around the datacenter 105 in a hub and spoke topology. Thus, traffic between any two sites must pass through the sets of hubs 112-116 at the datacenter 105 regardless of the geographic location of the sites.

The sets of hubs 112-116 in some embodiments provide the branch sites 130-136 with access to compute, storage, and service resources of the datacenter, such as the resources 160. Examples of such resources include compute machines (e.g., virtual machines and/or containers providing server operations), storage machines (e.g., database servers), and middlebox service operations (e.g., firewall services, load balancing services, encryption services, etc.). In some embodiments, the connections between the branch sites and the datacenter hubs are secure encrypted connections that encrypt packets exchanged between the edge nodes of the branch sites and the datacenter hubs. Examples of secure encrypted connections used in some embodiments include VPN (virtual private network) connections, or secure IPsec (Internet Protocol security) connections.

In some embodiments, multiple secure connection links (e.g., multiple secure tunnels) can be established between an edge node and a hub. When multiple such links are defined between an edge node and a hub, each secure connection link, in some embodiments, is associated with a different physical network link between the edge node and an external network. For instance, to access external networks in some embodiments, an edge node has one or more commercial broadband Internet links (e.g., a cable mode and a fiber optic link) to access the Internet, a wireless cellular link (e.g., a 5G LTE network), etc.

In some embodiments, each secure connection link between a hub and an edge node is formed as a VPN tunnel between the hub and the edge node. As illustrated in FIG. 1, the set of hubs 112 also connects the edge nodes to the SaaS datacenter 140. In some embodiments, these connections are through secure VPN tunnels. The collection of the edge nodes, hubs, and secure connections between the edge nodes, hubs, and SaaS datacenters forms the SD-WAN 100 for the particular entity.

As the sets of hubs 112-116 are multi-tenant hubs, they are used to define other virtual networks for other entities (e.g., other companies, organizations, etc.), according to some embodiments. Some such embodiments store tenant identifiers in tunnel headers that encapsulate packets that are to traverse the tunnels that are defined between a hub and branch sites, or other datacenters, to differentiate packet flows that it receives from edge nodes of one entity from packet flows that it receives along other tunnels of other entities. In other embodiments, the hubs are single tenant and are specifically deployed to be used by just one entity.

As mentioned above, the edge nodes of some embodiments forward packets to the hubs based on hub-selection rules that each identify a set of one or more hubs (e.g., the sets of hubs 112-116) of the datacenter for receiving one or more flows from the branch sites. In some embodiments, the edge nodes use flow attributes of received packets to identify hub-selection rules. The edge nodes identify hub-selection rules for received packets by matching flow attributes of the received packets with the match criteria of the hub-selection, which associate the match criteria with one or more identifiers of one or more forwarding hub nodes of the datacenter, according to some embodiments. For example, FIG. 1 depicts two flows 170 and 175 that both originate at the edge node 120 of the branch site 130. The first flow 170 is forwarded to the set of hubs 112, which provide access to the SaaS datacenter 140, while the second flow 175 is forwarded to the set of hubs 116 which provide access to the set of resource machines 160 of the datacenter 105.

The match criteria of the hub-selection rules in some embodiments are defined in terms of flow attributes. The flow attributes that are used for the match operation in some embodiments include the received packet's flow identifier (e.g., the received packets five tuple identifier, i.e., source and destination Internet Protocol (IP) addresses/port numbers and protocol). Conjunctively, or alternatively, the flow identifier used for the match operation in some embodiments includes flow attributes other than layers 2-4 (L2-L4) header values, such as layer 7 (L7) attributes. Examples of L7 attributes include AppID (e.g., traffic type identifier), user identifier, group identifier (e.g., an activity directory (AD) identifier), threat level, and application name/version. To obtain the L7 attributes, some embodiments perform deep packet inspection (DPI) on the packet. Alternatively, some embodiments may utilize a context engine to collect L7 attributes, as will be further described below.

By using L7 attributes to define the match criteria of hub-selection rules, some embodiments allow flows to be forwarded to different hubs based on different contextual attributes associated with the flows (i.e., allocating different hubs for different categories of flows). For instance, in some embodiments, the hub-selection rules associate different sets of flows that contain different types of traffic (i.e., as identified by different AppIDs) with different sets of hubs. Allocating the hubs based on L7 attributes, in some embodiments, allows for certain categories of traffic to be prioritized over other categories of traffic. For example, a first category of flows that contains a first type of traffic determined to be a high priority type of traffic (e.g., VoIP) may be allocated more hubs than a second category of flows that contains a second type of traffic determined to be a low priority type of traffic. Some embodiments also add attributes to traffic flows to signify that the traffic is of a higher priority for influencing hub-selection rules. For example, some embodiments include the location (e.g., latitude/longitude, geographic location) of the edge node as an additional attribute for influencing hub-selection rules.

As mentioned above, the match criteria of one or more hub-selection rules can be defined in terms of other L7 contextual attributes, such as user identifier, group identifier, threat level, and application name/version. For example, in some embodiments, the hub-selection rules associate sets of flows having user identifiers that correspond to executive staff or financial staff with a first set of forwarding hub nodes, while associating sets of flows having user identifiers other than those that correspond to executive staff or financial state with a second set of hubs. Doing so, in some embodiments, results in decreased congestion, and allows for easier prioritization of network traffic by allocating hubs based on attributes of flows such that certain flow categories requiring a greater number of hubs or resources can be provided with such.

In some embodiments, different hub-selection rules identify different groups of hubs that are available for selection for flows that match the rules. Accordingly, in some embodiments, when a matching hub-selection rule is identified for a received packet's flow, the edge node selects a hub from the group of hubs identified by the matched hub-selection rule. In some embodiments, the edge node performs a load balancing operation that based on a set of load balancing criteria (e.g., weight values) distributes the flows that match a hub-selection rule amongst the hubs specified by the rule.

For instance, the load balancing operation in some embodiments uses the weight values to distribute the flows that match a hub-selection rule amongst this rule's specified hubs in a round robin fashion (e.g., for three weight values of 2, 3, 3 for three hub, the load balancing operation would distribute the first two matching flows to the first hub, the next three matching flows to the second hub, the next three matching flows to the third hub, and then repeats by going back to the first hub for the next two flows).

The load-balancing weight values in some embodiments are adjusted dynamically based on packet processing statistics collected from the edge nodes and/or hubs in some embodiments. These statistics are collected and distributed in some embodiments by the controller cluster (not shown) of the SD-WAN. The controller cluster in some embodiments also distributes the hub-selection. The controller cluster and its operation will be described in further detail below.

FIG. 2 illustrates an SD-WAN network 200 for connecting multiple branch sites 230-236 to each other and to resources of a centralized datacenter 205. In this example, the SD-WAN 200 is established by the controller cluster 260 in the private datacenter 265, the hub clusters 212-216, and four edge nodes 220-226, one in each of the branch sites 230-236.

The controller cluster 260 severs as a central point for managing (e.g., defining and modifying) configuration data that is provided to the edge nodes and/or hubs to configure some or all of the operations. In some embodiments, the controller cluster has a set of manager servers that define and modify the configuration data, and a set of controller servers that distribute the configuration data to the edge nodes and/or hubs. In other embodiments, the controller cluster only has one set of servers that define, modify, and distribute the configuration data. The controller cluster, in some embodiments, directs edge nodes to use certain hubs for different categories of flows, as will be described in further detail below.

Although FIG. 2 illustrates the controller cluster 260 residing in one private datacenter 265, the controller cluster in some embodiments resides in one or more public cloud datacenters and/or private cloud datacenters. Also, some embodiments deploy one or more hubs in one or more private datacenters (e.g., datacenters of the entity that deploys the hubs and provides the controller cluster for configuring the hubs to implement the virtual network(s)).

FIG. 2 further illustrates a set of hub groups 212-216 in the datacenter 205. Each hub group 212-216, in some embodiments, is designated for processing a different category of flows based on configuration by the controller cluster 260. For example, the hub group 212 is designated as the hub group for receiving flows associated with the SaaS datacenter 240 as illustrated. In some embodiments, flow categories having a higher priority are allocated more hubs than flow categories having a lower priority. For example, each of the hub groups 212-216 includes a different number of hubs, with the hub group 216, having the highest number of hubs. In some embodiments, the number of hubs allocated for each flow category is based on input from a user (e.g., network administrator).

As mentioned above, in some embodiments, the controller cluster 260 (controller) for the SD-WAN provides hub-selection rules to the edge nodes 220-226 at the branch sites 230-236 for selecting hubs and/or hub groups to which to send packets of flows. The hubs of the hub groups, in some embodiments, are configured to provide network traffic statistics to the controller cluster collected from flows received by the hubs. In some embodiments, the configuration for the hubs specifies to provide the statistics periodically.

The controller cluster 260 receives network traffic statistics from the hubs of the hub groups 212-216, aggregates the received statistics by flow category (e.g., by AppID, user identifier, etc.), and analyzes the statistics to identify flow categories that require additional, or fewer, hubs in their respective hub groups. For example, in some embodiments, the controller cluster 260 determines that additional hubs are needed for processing a particular category of flows when a volume of traffic associated with the particular category of flows is found to exceed a maximum threshold value for traffic, or fall below a minimum threshold value for traffic. The maximum and minimum threshold values, in some embodiments, are defined by a user (e.g., network administrator).

When the controller cluster 260 determines that additional hubs are needed for a particular flow category, the controller directs a manager (not shown) of the datacenter to generate the additional hubs, according to some embodiments. Conversely, when the controller determines in some embodiments that fewer hubs are needed for a particular flow category, the controller may remove the excess hubs from the hub group designated for the particular flow category. In some embodiments, the controller may reallocate the excess hubs for other flow categories.

When the controller directs the manager of the datacenter to generate additional hubs, in some embodiments, the controller cluster 260 sends an updated list of hub groups to the edge nodes 220-226. In some embodiments, the updated list is provided via updated hub-selection rules (e.g., with updates to the hub groups specified for each hub-selection rule). The hub groups specified for each hub-selection rule, in some embodiments, are identified using group identifiers. Thus, the controller cluster in some embodiments simply provides updated group identifiers to the edge nodes. Conversely, or alternatively, the controller cluster in some embodiments provides the updated group identifiers as updated hub-selection rules that reference the updated group identifiers. The addition and removal of hubs will be further discussed below by reference to FIG. 5.

FIG. 3 conceptually illustrates example of an edge node 300 of some embodiments of the invention. As shown, the edge node 300 includes a packet processor 302, a load balancing hub selector 310, a flow classifier 320, and a connection tracker 350. In some embodiments, the components of the edge node operate on a single machine, while in other embodiments (e.g., when the edge node is a cluster of edge nodes) they operate on separate machines.

The packet processor 302 is the forwarding engine of the edge forwarding node of some embodiments. For a received packet of a flow, the packet processor 302 in some embodiments first determines whether the connection tracker 350 includes any records relating to the flow. The connection tracker stores records 360 for flows that have been previously processed by the edge node. In the example illustrated in FIG. 3, the stored records 360 of the connection tracker 350 include flow identifiers (e.g., five tuple identifiers), matched hub-selection rule for the flows, and the IP addresses of the selected hubs for the flows. While each of the flow IDs are illustrated as having one selected hub per flow, other embodiments may include a list of two or more hubs that have been selected for different packets of the same flow. In other words, in some embodiments, hubs are selected on a per flow basis, while in other embodiments, hubs are selected on a per packet basis. For example, in some embodiments, the records of the connection tracker 350 are updated as additional packets of the same flow are processed and forwarded by the edge node. The updated records in some embodiments include statistics regarding the number of packets in a flow forwarded to each hubs.

When the packet processor 302 determines that the connection tracker has a record that matches the received packet's flow (e.g., determines that the packet's five-tuple identifier matches the five-tuple identifier of a record in the connection tracker), the packet processor selects a hub for the packet by selecting a hub specified in the matching connection-tracking record. On the other hand, when the packet processor 302 determines that the connection tracker does not store any record relating to the received packet's flow, the packet processor 302 in some embodiments uses the flow classifier 320 to identify a hub-selection rule that specifies one or more hubs to use for the received packet's flow.

The flow classifier 320, in some embodiments, matches attributes of flows with match criteria of hub-selection rules 340 stored in the storage 330. As illustrated, the hub-selection rules 340 include a match criteria and a corresponding list of available hubs. Match attributes in some embodiments are defined in terms of (1) five-tuple header values (i.e., source IP address, source port address, destination IP address, destination port address, and protocol) of the packet flows, and/or (2) contextual attributes associated with the packet flows. In this example, the match criteria are defined in terms of both five-tuple identifiers and traffic types. In some embodiments, some or all of the five-tuple header values can be specified as wildcard values.

Also, in this example, each rule specifies its list of hubs by specifying a hub group identifier (GID), with each hub group's GID being an index into another data store that specifies the identifiers (e.g., IP addresses) of the hubs in that group. For example, rule 1 of the hub-selection rules 340 (1) matches flows that header values that match 5-tuple ID1 and carrying audio streaming content, and (2) specifies the corresponding hub group GID 5. Thus, flows with matching five-tuple identifiers and having an AppID identifying audio-streaming as the traffic type of the flow are to be forwarded to the hubs of hub group 5. Conjunctively, or alternatively, some embodiments list available hubs in each hub group by listing their individual network addresses (i.e., IP addresses) in the hub-selection rule, instead of providing the group D. Similarly, the match criteria of some embodiments may use a different contextual attribute for match criteria other than traffic type, or a combination of two or more contextual attributes.

In some embodiments, to select a hub from the available hubs indicated by the matched hub-selection rule, the packet processor 302 uses the load balancing hub selector 310. The load balancing hub selector 310, in some embodiments, performs load balancing operations to identify and select hubs to which to forward packets. In some embodiments, the load balancing hub selector 310 uses the load balancing criteria stored in storage 315 to perform its load balancing and hub-selection operations.

The edge node performs its load balancing operations in order to distribute the flows that match a hub-selection rule amongst the hubs specified by the rule. For instance, the load balancing operation in some embodiments uses the weight values to distribute the flows that match a hub-selection rule amongst this rule's specified hubs in a round robin fashion (e.g., for three weight values of 2, 3, 3 for three hub, the load balancing operation would distribute the first two matching flows to the first hub, the next three matching flows to the second hub, the next three matching flows to the third hub, and then repeats by going back to the first hub for the next two flows). The weight values in some embodiments are periodically adjusted based on statistics regarding the packets processed by the hubs.

FIG. 4 illustrates a process 400 for an edge node that receives a packet of a particular flow. As shown, the process 400 starts at 410 by receiving a packet that has a flow identifier associated with a particular packet flow. In some embodiments, the received packet may be the first packet of the flow, while in other embodiments, the packet may be a subsequent packet of the flow.

After receiving the packet at 410, the process 400 determines, at 420, whether a record associated with the particular flow is stored in a connection tracker. As described above for FIG. 3, the connection tracker (e.g., connection tracker 350), in some embodiments, stores records for flows that have been processed by the edge node. These stored records include the flow's identifier, an identified hub-selection rule for the flow, and one or more hubs to which packets of a flow have been forwarded, according to some embodiments, as described above. When a record associated with the particular flow is identified in the connection tracker, the process transitions to 430, where it identifies the hub previously selected for the flow from the connection-tracker record. The process then transitions to 480 to forward the packet to the selected hub.

Otherwise, when no records associated with the particular flow are stored in the connection tracker, the process transitions to 440 to identify contextual attributes of the packet flow. In some embodiments, the contextual attributes include AppID (e.g., traffic type identifier), user identifier, group identifier (e.g., an activity directory (AD) identifier), threat level, and application name/version. To identify the contextual attributes of received packets, some embodiments perform deep packet inspection (DPI) on the received packets. Alternatively, some embodiments utilize context engine that collects contextual attributes on the edge node through one or more guest introspection (GI) agents executing on the edge node. In some such embodiments, the context engine provides the collected contextual attributes to, e.g., a flow classifier such as flow classifier 320 of FIG. 3.

After identifying the contextual attributes of the received packet, the process 400 matches, at 450, the identified contextual attributes of the flow with match criteria of a hub-selection rule. As described above, the match criteria in some embodiments is defined in terms of flow attributes (e.g., contextual attributes). For instance, in the example of the edge node 300, the flow classifier 320 accesses the hub-selection rules from the storage 330 to match the identified contextual attributes with the match criteria listed for the hub-selection rules 340. In some embodiments, the hub-selection rules are received from a controller of the SD-WAN (e.g., the controller cluster 260) and each associate the match criteria with one or more identifiers of one or more hubs, or hub groups, of the datacenter as described above. The match criteria of the hub-selection rules, in some embodiments, are defined in terms of flow attributes.

Next, at 460, the process selects a hub from a hub group identified as available by the matching hub-selection rule. Some embodiments utilize group identifiers associated with the hub groups to identify available hub groups for each of the hub-selection rules, such as in the example embodiment of FIG. 3. In some embodiments, the controller (e.g., controller cluster 260) may provide, to the edge nodes (e.g., edge nodes 220-226), a mapping of the group identifiers to their respective hub groups for the edge nodes to use to identify particular hubs of the hub groups to which to send packets.

In some embodiments, such as FIG. 3, the load balancing hub selector of the edge node (e.g., the load balancing hub selector 310) is responsible for selecting the hub. For instance, as described above, the load balancing operation in some embodiments uses periodically adjusted weight values to distribute the flows that match a hub-selection rule amongst this rule's specified hubs in a round robin fashion.

In some embodiments, for packets belonging to flows having corresponding records stored by the connection tracker, the same hub may be selected for the current packet of the flow. However, as will be described in further detail below, the available hubs in each hub group are dynamically assigned, and thus may change between the processing of different packets of a flow. Accordingly, in some embodiments, a hub selected for one packet of a flow may no longer be available for selection for a subsequent packet of the flow. In some such embodiments, the load balancing hub selector may select a next available hub from the available hubs identified by the matched hub selection rule for the flow.

After selecting a hub, the process proceeds to 470 to create a record in the connection-tracking storage 360 to identify the hub selected for the flow. For example, in some embodiments, the created connection-tracking record includes the flow's identifier, the matched hub-selection rule, and the hub(s) selected for the flow. Each time the process 400 matches a packet with a connection-tracking record, the process in some embodiments updates the connection tracker with other information regarding the particular flow. For example, in some embodiments, the process updates the existing record to reflect the hub selected for the received packet (i.e., if the selected hub is a hub other than those already reflected in the record).

After creating the connection-tracking record, the process forwards (at 480) the packet to the selected hub. As described above, the edge nodes in some embodiments forward packets to selected hubs using direct tunnels established between the edge nodes and the hubs and/or hub groups. In some embodiments, multiple secure connection links (e.g., multiple secure tunnels) can be established between an edge node and a hub. When multiple such links are defined between an edge node and a hub, each secure connection link, in some embodiments, is associated with a different physical network link between the edge node and an external network. For instance, to access external networks in some embodiments, an edge node has one or more commercial broadband Internet links (e.g., a cable mode and a fiber optic link) to access the Internet, a wireless cellular link (e.g., a 5G LTE network), etc. In some embodiments, each secure connection link between a hub and an edge node is formed as a VPN tunnel between the hub and the edge node. The process 400 then ends.

FIG. 5 illustrates a process 500 for a controller of an SD-WAN (e.g., controller cluster 260 of the SD-WAN 200). The process 500 starts, at 505, by receiving network traffic statistics from the hubs/hub groups of the datacenter (e.g., hub groups 212-216 of the datacenter 205). As described above, the hubs/hub groups are configured to provide network traffic statistics to the controller/controller cluster, according to some embodiments.

At 510, the process aggregates the received network traffic statistics by flow category. In some embodiments, the flows are categorized by traffic type (e.g., as identified by the AppID of packets). In some such embodiments, each traffic type has a designated priority level (e.g., high priority, low priority, etc.) that corresponds to the number of hubs that may be allocated for receiving flows of the traffic type. For example, in some embodiments, a first type of traffic designated as high priority may be allocated 70% of the hubs of the datacenter while a second type of traffic designated as low priority may be allocated the other 30% of the hubs of the datacenter. The number of hubs allocated for a particular traffic type is defined by a user (e.g., network administrator), according to some embodiments.

Once the received network traffic statistics have been aggregated, the process 500 selects, at 515, a flow category for analysis. Examples of flow categories can include categories based on AppID (e.g., traffic type), user identifiers (e.g., administrators, low-level employees, etc.), threat level (e.g., high, low, neutral, etc.), etc. In some embodiments, the flow categories are each assigned a priority level as described above. For example, some embodiments in which flows are categorized by traffic type may assign a high priority level to, e.g., VoIP traffic, while assigning a lower priority level to, e.g., peer-to-peer e-mail traffic.

Next, the process 500 determines, at 520, whether the amount of traffic associated with the selected flow category has exceeded a maximum threshold value specified for the flow category for a minimum duration of time (e.g., hours, days, weeks, etc.). The maximum threshold value and the minimum duration of time, in some embodiments, are each specified by a user (e.g., network administrator). In some embodiments, the maximum threshold value and the minimum duration of time specified may vary between each of the flow categories, while in other embodiments, they are consistent for each flow category.

When the process determines that the amount of traffic has not exceeded the maximum threshold value for the minimum specified duration of time, the process transitions to 525 to determine whether the amount of traffic has fallen below a minimum threshold for a minimum duration of time. In some embodiments, the minimum duration of time specified for the maximum threshold value and the minimum duration of time specified for the minimum threshold value are equal, while in other embodiments the specified minimum durations of time are different.

When the process determines, at 525, that the amount of traffic associated with the flow has fallen below the minimum threshold value for the minimum duration of time, the process transitions to 530 to remove the excess hubs from the group of hubs designated for the selected flow category. In some embodiments, removing the excess hubs includes reallocating the excess hubs for other flow categories (e.g., other flow categories that may require additional hubs). Otherwise, the process transitions to 540 to determine if there are additional flow categories to analyze.

Alternatively, when the process determines at 520 that the amount of traffic associated with the selected flow category has exceeded the maximum threshold value for the minimum duration of time, the process transitions to 535 to direct a manager of the datacenter (e.g., VeloCloud Orchestrator) to generate additional hubs to be added to the hub group allocated for servicing the selected flow category. In some embodiments, when a particular category of flows is found to have excess hubs as described above, those excess hubs may be allocated to a flow category determined to require additional hubs in conjunction with the newly generated hubs, or as an alternative to generating the new hubs.

Next, at 540, the process determines whether there are additional flow categories to analyze. When the process determines that there are additional flow categories, to analyze, the process transitions back to 515 to select a flow category for analysis. Otherwise, the process transitions to 545 to send updated hub-selection rules to the edge nodes of the branch sites, the updated hub-selection rules identifying any changes (e.g., additions, removals) to the hub groups. The process 500 then ends.

Many of the above-described features and applications are implemented as software processes that are specified as a set of instructions recorded on a computer readable storage medium (also referred to as computer readable medium). When these instructions are executed by one or more processing unit(s) (e.g., one or more processors, cores of processors, or other processing units), they cause the processing unit(s) to perform the actions indicated in the instructions. Examples of computer readable media include, but are not limited to, CD-ROMs, flash drives, RAM chips, hard drives, EPROMs, etc. The computer readable media does not include carrier waves and electronic signals passing wirelessly or over wired connections.

In this specification, the term “software” is meant to include firmware residing in read-only memory or applications stored in magnetic storage, which can be read into memory for processing by a processor. Also, in some embodiments, multiple software inventions can be implemented as sub-parts of a larger program while remaining distinct software inventions. In some embodiments, multiple software inventions can also be implemented as separate programs. Finally, any combination of separate programs that together implement a software invention described here is within the scope of the invention. In some embodiments, the software programs, when installed to operate on one or more electronic systems, define one or more specific machine implementations that execute and perform the operations of the software programs.

FIG. 6 conceptually illustrates a computer system 600 with which some embodiments of the invention are implemented. The computer system 600 can be used to implement any of the above-described hosts, controllers, hub and edge forwarding elements. As such, it can be used to execute any of the above described processes. This computer system includes various types of non-transitory machine readable media and interfaces for various other types of machine readable media. Computer system 600 includes a bus 605, processing unit(s) 610, a system memory 625, a read-only memory 630, a permanent storage device 635, input devices 640, and output devices 645.

The bus 605 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of the computer system 600. For instance, the bus 605 communicatively connects the processing unit(s) 610 with the read-only memory 630, the system memory 625, and the permanent storage device 635.

From these various memory units, the processing unit(s) 610 retrieve instructions to execute and data to process in order to execute the processes of the invention. The processing unit(s) may be a single processor or a multi-core processor in different embodiments. The read-only-memory (ROM) 630 stores static data and instructions that are needed by the processing unit(s) 610 and other modules of the computer system. The permanent storage device 635, on the other hand, is a read-and-write memory device. This device is a non-volatile memory unit that stores instructions and data even when the computer system 600 is off. Some embodiments of the invention use a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) as the permanent storage device 635.

Other embodiments use a removable storage device (such as a floppy disk, flash drive, etc.) as the permanent storage device. Like the permanent storage device 635, the system memory 625 is a read-and-write memory device. However, unlike storage device 635, the system memory is a volatile read-and-write memory, such as random access memory. The system memory stores some of the instructions and data that the processor needs at runtime. In some embodiments, the invention's processes are stored in the system memory 625, the permanent storage device 635, and/or the read-only memory 630. From these various memory units, the processing unit(s) 610 retrieve instructions to execute and data to process in order to execute the processes of some embodiments.

The bus 605 also connects to the input and output devices 640 and 645. The input devices enable the user to communicate information and select commands to the computer system. The input devices 640 include alphanumeric keyboards and pointing devices (also called “cursor control devices”). The output devices 645 display images generated by the computer system. The output devices include printers and display devices, such as cathode ray tubes (CRT) or liquid crystal displays (LCD). Some embodiments include devices such as touchscreens that function as both input and output devices.

Finally, as shown in FIG. 6, bus 605 also couples computer system 600 to a network 665 through a network adapter (not shown). In this manner, the computer can be a part of a network of computers (such as a local area network (“LAN”), a wide area network (“WAN”), or an Intranet), or a network of networks (such as the Internet). Any or all components of computer system 600 may be used in conjunction with the invention.

Some embodiments include electronic components, such as microprocessors, storage and memory that store computer program instructions in a machine-readable or computer-readable medium (alternatively referred to as computer-readable storage media, machine-readable media, or machine-readable storage media). Some examples of such computer-readable media include RAM, ROM, read-only compact discs (CD-ROM), recordable compact discs (CD-R), rewritable compact discs (CD-RW), read-only digital versatile discs (e.g., DVD-ROM, dual-layer DVD-ROM), a variety of recordable/rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.), magnetic and/or solid state hard drives, read-only and recordable Blu-Ray® discs, ultra-density optical discs, any other optical or magnetic media, and floppy disks. The computer-readable media may store a computer program that is executable by at least one processing unit and includes sets of instructions for performing various operations. Examples of computer programs or computer code include machine code, such as is produced by a compiler, and files including higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter.

While the above discussion primarily refers to microprocessor or multi-core processors that execute software, some embodiments are performed by one or more integrated circuits, such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). In some embodiments, such integrated circuits execute instructions that are stored on the circuit itself.

As used in this specification, the terms “computer”, “server”, “processor”, and “memory” all refer to electronic or other technological devices. These terms exclude people or groups of people. For the purposes of the specification, the terms “display” or “displaying” mean displaying on an electronic device. As used in this specification, the terms “computer readable medium,” “computer readable media,” and “machine readable medium” are entirely restricted to tangible, physical objects that store information in a form that is readable by a computer. These terms exclude any wireless signals, wired download signals, and any other ephemeral or transitory signals.

While the invention has been described with reference to numerous specific details, one of ordinary skill in the art will recognize that the invention can be embodied in other specific forms without departing from the spirit of the invention. For instance, several of the above-described embodiments deploy hubs in public cloud datacenters. However, in other embodiments, the hubs are deployed in a third party's private cloud datacenters (e.g., datacenters that the third party uses to deploy cloud hubs for different entities in order to deploy virtual networks for these entities). Thus, one of ordinary skill in the art would understand that the invention is not to be limited by the foregoing illustrative details, but rather is to be defined by the appended claims.

Claims

1. For a software-defined wide area network (SD-WAN) connecting first, second and third sites, the first and second sites being branch sites and respectively comprising first and second forwarding edges and the third site being a datacenter and comprising a plurality of forwarding hubs, a method comprising: at the forwarding edge of the first branch site, receiving a packet of a particular flow, the packet originating from the first branch site and addressed to a destination at the second branch site, the flow associated with a flow attribute;using the flow attribute to identify a hub-selection rule from a plurality of hub selection rules, each hub-selection rule identifying at least one particular forwarding hub at the datacenter third site for receiving one or more flows from the first branch site, and directing the received flow to the particular forwarding hub to forward to the second branch site, the datacenter third site comprising a plurality of server machines accessible to the first and second sites through the hubs, the plurality of hub-selection rules comprising at least one hub-selection rule identifying at least one forwarding hub that is not identified by another hub-selection rule;using the identified hub-selection rule to identify a forwarding hub for the particular flow; andsending the packet from the forwarding edge at the first branch site to the identified forwarding hub at the datacenter third site.

2. The method of claim 1, wherein the flow attribute comprises a five tuple identifier of the packet.

3. The method of claim 1, wherein the flow attribute comprises attributes other than layers 2-4 header values.

4. The method of claim 3 further comprising performing deep packet inspection (DPI) on the packet to identify the flow attribute, wherein the flow attribute comprises a layer 7 (L7) attribute of the packet.

5. The method of claim 4, wherein the L7 attribute identifies a traffic type of the particular flow.

6. The method of claim 1, wherein each hub-selection rule in the plurality of hub-selection rules specifies a different set of forwarding hubs for receiving flows of a particular flow category.

7. The method of claim 1, wherein each hub-selection rule in the plurality of hub-selection rules comprises match criteria defined in terms of flow attributes.

8. The method of claim 7, wherein using the flow attribute to identify a hub-selection rule comprises comparing the flow attribute to match criteria of the plurality of hub selection rules to identify a matching hub-selection rule.

9. The method of claim 1, wherein at least two hub-selection rules identify a same group of forwarding hubs for receiving flows of first and second categories from the first site.

10. The method of claim 1, wherein each forwarding hub in the plurality of forwarding hubs is associated with a different network address, wherein sending the packet from the forwarding edge at the first site to the identified hub at the datacenter third site comprises sending the packet from the forwarding edge at the first site to a network address associated with the identified hub at the datacenter third site.

11. The method of claim 1, wherein the plurality of forwarding hubs act as gateways for accessing the resources at other branch sites or at a third party datacenter, including the second site.

12. The method of claim 11, wherein the plurality of forwarding hubs also provide access to resources of the datacenter.

13. The method of claim 11, wherein the plurality of branch sites are arranged topologically around the datacenter in a hub and spoke topology.

14. The method of claim 1, wherein the plurality of hub selection rules are received from a controller of the SD-WAN.

15. The method of claim 14 further comprising receiving an updated set of hub selection rules from the controller, wherein the updated set of hub selection rules comprise at least one hub selection rule identifying at least one additional forwarding hub for receiving a particular category of flows from the first site.

16. The method of claim 15, wherein the controller generates the updated set of hub selection rules based on an analysis of network traffic statistics from the plurality of forwarding hubs.

17. The method of claim 16, wherein the controller analyzes the network traffic statistics to identify groups of forwarding hubs that need additional or fewer forwarding hubs for receiving flows from the first site.

18. The method of claim 1, wherein sending the packet to the identified forwarding hub comprising sending the packet via any one of fiber, cable, 5G, and Digital Subscriber Line (DSL).

19. The method of claim 11, wherein the plurality of branch sites connect to the plurality of forwarding hubs at the datacenter through one of a virtual private network (VPN) domain and an IPSec domain, wherein packets are encrypted at forwarding edges of the plurality of branch sites and decrypted by the plurality of forwarding hubs.

20. The method of claim 1, wherein at least one hub-selection rule identifies a first forwarding hub group for first and second different sets of flow, the method further comprising receiving a new hub-selection rule identifying a second forwarding hub group to which to send the second set of flows.

21. The method of claim 1, wherein the forwarding edge of the first site is a first forwarding edge of a high-availability pair of forwarding edges of the first site, wherein the first forwarding edge is an active edge of the first site and a second forwarding edge of the high-availability pair of forwarding edges is a standby forwarding edge of the first site.