Automatic policy configuration for packet streams

Abstract

Embodiments of this disclosure relate to automatic policy configuration for packet flows. Techniques for providing automatic policy configuration for packet flows are disclosed. For example, a computing device includes a virtual node and one or more virtual execution elements coupled to the virtual node. The computing device may also include one or more processors configured to: receive packets originating from application workloads hosted on one or more virtual execution elements and destined for a remote destination device; determine that the packets are part of a new packet flow; in response, configure a policy for the new packet flow for a forward packet flow by the kernel of the computing device without sending packets to the user space of the computing device; configure a policy for a reverse packet flow associated with the forward packet flow by the kernel; and send packets to the remote destination device according to the policy for the forward packet flow.

Description

[0001] Cross-references to related applications

[0002] This application claims the benefit of U.S. Patent Application No. 17 / 450,147, filed October 6, 2021, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to computer networks. Background Technology

[0004] A computer network is a collection of interconnected computing devices that can exchange data and share resources. In packet-based networks such as the Internet, computing devices transmit data by dividing it into variable-length chunks called packets, which are individually routed across the network from source devices to destination devices. The destination device extracts data from the packets and reassembles the data into its original form.

[0005] Certain computing devices called routers maintain routing information that represents the network topology. Routers exchange routing information to maintain an accurate representation of the available routes through the network. A "route" can generally be defined as a path between two locations on the network. When a router receives an incoming data packet, it examines the information within the packet (often called a "key") to select the appropriate next hop to which the packet will be forwarded, based on the routing information.

[0006] Computing devices can be configured to process packet flows. The terms "packet flow," "traffic flow," or simply "flow" refer to a group of packets originating from a specific source device or endpoint and destined for a specific destination device or endpoint. A single packet flow can be identified by information within the packet, such as a 5-tuple: <source address, destination address, source port, destination port, protocol> and region. This information typically identifies the packet flow to which the received packet belongs and the associated policy ("policy flow") used to forward the packet. Summary of the Invention

[0007] In general, this disclosure describes techniques for providing automatic policy configuration for packet flows. For example, a computing device can leverage its kernel to automatically configure policy flows without sending packets to the user space of the computing device. In some examples, the computing device can host an application workload that initiates packets to be forwarded to a remote destination device. When a virtual node running in the kernel of the computing device receives a packet from the application workload, the virtual node examines the packet's information (e.g., 5-tuple and region) to determine if the packet matches an existing packet flow. If the packet does not belong to an existing packet flow and the packet originates from a locally hosted application workload, the computing device can leverage its kernel to configure policies for forward packet flows and policies for reverse packet flows (e.g., packet flows in the reverse direction of the forward packet flow) without sending packets to user space. For example, the computing device can configure flow actions for policies for forward packet flows to forward packets originating from an application workload and destined for a remote destination device. The kernel can also perform a lookup of forwarding information using the packet's L3 address (e.g., destination IP address) to determine the next hop and configure the next hop of the forward packet flow as an entry within the flow information.

[0008] The kernel of a virtual router can also configure policies for reverse packet flows while processing packets flowing in the forward direction. The kernel of the computing device can map the identifier of the virtual network for the application workload (e.g., a Virtual Network Identifier (VNI), such as a VXLAN label or MPLS label) to a region associated with the application workload, and configure virtual nodes to determine that region based on the VNI or MPLS label included in packets received in the reverse direction (e.g., packets originating from a remote destination device and destined for the application workload). In this way, virtual nodes use the region determined based on the VNI or MPLS label included in packets received in the reverse direction to perform flow information lookups to determine policies for reverse packet flows. The kernel of the computing device can also configure the next hop for the reverse packet flow to the virtual execution element hosting the application workload.

[0009] The techniques described in this disclosure can provide one or more technical advantages for implementing at least one practical application. For example, by configuring packet flow policies using the kernel of a computing device without sending packets to the user space of the computing device, the computing device reduces the number of packets sent to the user space. This results in a reduction in the amount of computing device processing resources required to configure and apply packet flow policies, and can also increase the speed at which the computing device processes packets. This can also reduce instances of denial-of-service that could result from sending a large number of packets to the user space. This enables more efficient and scalable packet forwarding.

[0010] In one example, this disclosure describes a method comprising: receiving a packet by a virtual node implemented via a computing device, the packet originating from an application workload hosted on the computing device and destined for a remote destination device; determining by the virtual node that the packet is part of a new packet stream; in response to determining that the packet is part of a new packet stream, configuring a policy for a forward packet stream by the kernel of the computing device without sending the packet to the user space of the computing device; configuring a policy for a reverse packet stream associated with the forward packet stream by the kernel of the computing device; and sending the packet to the remote destination device by the computing device according to the policy for the forward packet stream.

[0011] In another example, this disclosure describes a computing device including: a virtual node; one or more virtual execution elements coupled to the virtual node; and one or more processors, wherein the one or more processors are configured to: receive packets originating from application workloads hosted on the one or more virtual execution elements and destined for a remote destination device; determine that the packet is part of a new packet stream; in response to determining that the packet is part of a new packet stream, configure a policy for a forward packet stream for the new packet stream by the kernel of the computing device without sending the packet to the user space of the computing device; configure a policy for a reverse packet stream associated with the forward packet stream by the kernel of the computing device; and send the packet to the remote destination device according to the policy for the forward packet stream.

[0012] In another example, this disclosure describes a non-transitory computer-readable medium including instructions that, when executed, cause one or more processors to: receive a packet originating from an application workload hosted on one or more virtual execution elements and destined for a remote destination device; determine that the packet is part of a new packet stream; in response to determining that the packet is part of a new packet stream, configure a policy for the new packet stream for a forward packet stream by the kernel of the computing device without sending the packet to the user space of the computing device; configure a policy for a reverse packet stream associated with the forward packet stream by the kernel of the computing device; and send the packet to the remote destination device according to the policy for the forward packet stream. Furthermore, the techniques described in this disclosure enable the creation of new packet streams when user space is unavailable (e.g., during an upgrade) and avoid the need to discard new stream packets during user space application unavailability.

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

[0014] Figure 1This is a block diagram illustrating an example network system for providing automatic policy configuration for packet flows according to the techniques described in this disclosure;

[0015] Figure 2 To show in more detail Figure 1 A block diagram of an example implementation of a data center;

[0016] Figure 3 This is a block diagram illustrating an example computing device according to the technology described in this disclosure; and

[0017] Figure 4 This is a flowchart illustrating an example operation of the technology according to this disclosure.

[0018] Throughout the accompanying drawings and description, the same reference numerals refer to the same elements. Detailed Implementation

[0019] Figure 1 This is a block diagram illustrating an example network system for providing automatic policy configuration for packet flows according to the techniques described in this disclosure. Figure 1 The network system 2 in the example includes data centers 10A-10X (collectively referred to as "data center 10") interconnected with each other and interconnected with a customer network associated with customer 11 via a service provider network 7. Typically, each data center 10 provides an operating environment for the applications and services of customer 11 coupled to the data center via the service provider network 7. Data center 10 may, for example, host infrastructure equipment such as networking and storage systems, redundant power supplies, and environmental controls. The service provider network 7 may be coupled to one or more networks managed by other providers and may therefore form part of a large-scale public network infrastructure (e.g., the Internet).

[0020] In some examples, each data center 10 can represent one of many geographically distributed network data centers. For example... Figure 1 As shown in the example, each data center 10 can be a facility providing network services to clients 11. Clients 11 can be collective categories, such as enterprises and governments, or individuals. For example, a network data center can host network services for several enterprises and end users. Other exemplary services may include data storage, virtual private networks, traffic engineering, file services, data mining, scientific or supercomputing, etc. In some embodiments, each data center 10 can be an individual network server, network peer, etc.

[0021] In this example, each data center 10 includes a set of storage systems and application servers 12A-12X (referred to herein as "computing device 12") interconnected via a high-speed switching infrastructure 14 provided by one or more tiers of physical network switches and routers. The computing device 12 serves as a computing node within the data center. In some examples, the terms "computing node" or "computing device" and "server" are used interchangeably herein to refer to computing device 12. Each computing device in computing device 12 can be configured with a virtual execution element by virtualizing the computing device's resources to provide isolation between one or more processes (applications) executing on the computing device. "Hypervisor-based," "hardware-level," or "platform" virtualization refers to the creation of virtual execution elements, each including a guest operating system for executing one or more processes. Generally, virtual execution elements provide a virtualized / guest operating system for executing applications in an isolated virtual environment. Because the virtual execution elements are virtualized from the physical hardware of the host computing device, the execution of applications is isolated from both the host hardware and other virtual execution elements. The term "virtual execution element" encompasses virtual machines ("VMs"), containers, and other virtualized computing resources that provide (at least partially) independent execution environments for applications. These virtual execution elements can be tenants running virtualized application workloads and may be referred to herein as virtualized application workloads (or simply application workloads). Each virtual network endpoint can communicate on its corresponding virtual network using one or more virtual network interfaces. Figure 1 In the example, computing devices 12A-12N can host virtual machines 15A-15N (collectively referred to as "VM 15") that provide an independent execution environment for application workloads.

[0022] A virtual network is a logical structure implemented on top of the physical network of data center 10A. Virtual networks can be implemented using various mechanisms. For example, each virtual network can be implemented as a Virtual Local Area Network (VLAN), a Virtual Private Network (VPN), etc. A virtual network can also be implemented using two networks—a physical underlying network consisting of IP structure 20 and switching structure 14, and a virtual overlay network. The role of the physical underlying network is to provide the "IP structure," which provides unicast IP connections from any physical device (computing device, router, storage device, etc.) to any other physical device. The underlying network can provide a unified, low-latency, non-blocking, high-bandwidth connection from any point in the network to any other point in the network.

[0023] Virtual networks can use data center 10A ( Figure 1Edge devices (e.g., routers, not shown) connect to and extend on top of physical multiprotocol label switching (MPLS) Layer 3 virtual private networks (L3VPNs) and Ethernet virtual private networks (EVPNs).

[0024] Virtual nodes running in the kernel or hypervisor of computing device 12 create virtual overlay networks on top of the physical underlying network using a dynamic mesh of "tunnels" between them. For example, these overlay tunnels could be MPLS tunnels over GRE / UDP, VXLAN tunnels, or NVGRE tunnels. The underlying physical routers and switches may not contain any per-tenant state of the virtual machines or other virtual execution elements, such as any media access control (MAC) addresses, IP addresses, or policies. For example, the forwarding tables of the underlying physical routers and switches may only contain the IP prefix or MAC address of the physical computing device 12 (an exception is the gateway router or switch connecting the virtual network to the physical network, which may contain tenant MAC or IP addresses).

[0025] Virtual nodes 13 of computing device 12 typically contain per-tenant state. For example, they may contain a separate forwarding table (routing instance) per virtual network. This forwarding table contains the IP prefixes (in the case of Layer 3 coverage) or MAC addresses (in the case of Layer 2 coverage) of virtual machines or other virtual execution elements (e.g., container pods). A single virtual node 13 does not need to contain all IP prefixes or all MAC addresses of all virtual machines in the entire data center. A given virtual node 13 only needs to contain a routing instance that exists locally on the computing device (i.e., it has at least one virtual execution element existing on computing device 12).

[0026] The switching architecture 14 is provided by a set of interconnected top-of-rack (TOR) switches 16A-16BN (collectively referred to as "TOR switches 16") coupled to a distribution layer of rack switches 18A-18M (collectively referred to as "rack switches 18"). Although not shown, each data center 10 may also include, for example, one or more non-edge switches, routers, hubs, gateways, security devices (such as firewalls, intrusion detection and / or intrusion prevention devices), servers, computer terminals, laptops, printers, databases, wireless mobile devices (such as cellular phones or personal digital assistants), wireless access points, bridges, cable modems, application accelerators, or other network devices.

[0027] In this example, TOR switch 16 and rack switch 18 provide redundant (multihomed) connectivity for computing device 12 to IP fabric 20 and service provider network 7. Rack switch 18 aggregates traffic flows and provides high-speed connectivity between TOR switches 16. TOR switch 16 may be a network device providing Layer 2 (e.g., MAC) and / or Layer 3 (e.g., IP) routing and / or switching capabilities. TOR switch 16 and rack switch 18 may each include one or more processors and memory, and are capable of executing one or more software processes. Rack switch 18 is coupled to IP fabric 20, which performs Layer 3 routing to route network traffic between data center 10 and customer 11 via service provider network 7.

[0028] Network system 2 implements an automation platform for automating the deployment, scaling, and operation of virtual execution elements across computing devices 12 to provide a virtualized infrastructure for the execution of application workloads and services. For example, data center 10 may include a software-defined networking (“SDN”) platform to control and manage network behavior. In some cases, the SDN platform includes a logically centralized, and in some cases physically distributed, SDN controller (e.g., controller 23) and a distributed forwarding plane in the form of virtual nodes (e.g., virtual node 13) that extend the network from physical routers and switches in the data center switching fabric to a virtual overlay network hosted in virtualized computing devices. According to one or more examples of this disclosure, controller 23 facilitates the operation of one or more virtual networks within each data center 10, such as data center 10A. In some examples, controller 23 may operate in response to configuration input received from orchestration engine 22, which in turn operates in response to configuration input received from network administrator 24. Additional information regarding controller 23 operating with other devices in data center 10A or other software-defined networks can be found in international application PCT / US2013 / 044378 entitled “PHYSICAL PATH DETERMINATION FOR VIRTUALNETWORK PACKET FLOWS” filed June 5, 2013, which is incorporated herein by reference as fully set forth herein.

[0029] In some examples, orchestration engine 22 manages the application-layer functions of data center 10, such as managing compute, storage, networking, and application resources running on computing devices 12. In the context of virtualized computing infrastructure, "orchestration" generally refers to the provisioning, scheduling, and management of virtual execution elements and / or applications and application services running on such virtual execution elements by a host server available to the orchestration platform. For example, orchestration engine 22 can attach virtual machines to a tenant's virtual network and typically manage the startup, migration, and decomposition of VMs as needed. In other examples, container orchestration allows for container coordination and refers to, for example, a container orchestration platform deploying, managing, scaling, and configuring containers to host servers. Example instances of orchestration platforms include Kubernetes, Docker Swarm, Mesos / Marathon, OpenShift, OpenStack, VMware, and Amazon ECS.

[0030] Orchestrator 22 and controller 23 together implement the controller of network system 2. Orchestrator 22 and controller 23 can execute on separate computing devices or on the same computing device. Each of orchestrator 22 and controller 23 can be a distributed application executing on one or more computing devices.

[0031] In some examples, controller 23 is a lower-level controller whose task is to manage the network and networking services of data center 10A, particularly virtual services such as the virtual firewall of computing device 12. Controller 23 utilizes a set of communication protocols to configure the network. For example, communication protocols may include messaging protocols such as Extensible Communication and Presentation Protocol (XMPP). For example, controller 23 fulfills high-level requests from orchestration engine 22 by configuring physical switches, such as TOR switch 16, rack switch 18, and switching fabric 14; physical routers; physical service nodes, such as firewalls and load balancers; and virtual services, such as virtual firewalls in VMs. Controller 23 maintains routing, networking, and configuration information in a state database. Controller 23 transmits appropriate subsets of routing and configuration information from the state database to virtual network (VN) agents on each computing device in computing devices 12A-12N. For example, controller 23 may transmit MPLS labels or virtual network identifiers (such as VXLAN labels) between computing device 12 and other devices in data center 10A.

[0032] Virtual node 13 can be configured to process packets as packet flows. The term "packet flow," "service flow," or simply "flow" refers to a group of packets that originate from a specific source device or endpoint and are sent to a specific destination device or endpoint. A single packet flow can be identified by information within the packet, such as a 5-tuple: <source address, destination address, source port, destination port, protocol> and region. This information typically identifies the packet flow to which the received packet belongs and the associated policy ("policy flow") used to forward the packet.

[0033] Typically, computing devices reactively create policies for packet flows. For example, when a virtual node running in the computing device's kernel receives a packet, the virtual router examines information in the packet (e.g., 5-tuples and regions) to determine if the packet matches an existing packet flow in its flow information (e.g., flow tables). If the packet does not belong to an existing packet flow, it is sent to the computing device's user space to configure a policy for the new packet flow. For example, the computing device's user space performs a lookup in a policy database to determine how to configure the policy for the packet flow and how to install flow information for the new packet flow. In some examples, user space may also send the packet to a network filter (Netfilter) provided by the Linux kernel to determine the reverse packet flow for that packet, allowing the computing device's user space to configure the reverse packet flow. While reactively creating policy flows may limit unnecessary policy flows from being programmed for all packet flows (e.g., all combinations of 5-tuples and regions), it can consume significant processing resources due to the large number of packets sent to user space (and Netfilter), and may further lead to denial-of-service (DoS) attacks.

[0034] According to the techniques described in this disclosure, a virtual router implemented by a computing device can, for example, use the kernel of the computing device to provide automatic policy configuration for packet flows without sending packets to user space. For example, computing device 12A can host VM 15A, which provides an execution environment for application workloads. The application workload can initiate packets, such as packet 26, to be sent via service provider network 7 to a remote destination device (e.g., customer 11 or a remote computing device hosted in one of data centers 10B-10X). A virtual node 13A running in the kernel of computing device 12A can receive packet 26 from the application workload and examine information in packet 26 (e.g., 5-tuples and regions) to identify whether packet 26 belongs to an existing packet flow. For example, virtual node 13A can perform a lookup of flow information (e.g., from a flow table) to determine whether keying information within packet 26 matches an entry in the flow information. If the keying information within packet 26 does not match an entry in the flow information (and therefore does not belong to an existing packet flow), computing device 12A can configure a policy for forward packet flows via its kernel instead of sending packet 26 to the user space of the computing device. Computing device 12A can determine that packet 26 does not need to be sent to user space because packet 26 originates from application workloads hosted locally by computing device 12A and is therefore a trusted source. For example, computing device 12A can determine the source address and / or source port of packet 26, identifying the network address (e.g., IP address) and / or port of VM 15A.

[0035] The kernel of computing device 12A can configure flow actions for policies used to forward packets originating from application workloads. The kernel can also perform lookups for forwarding information using the L3 address of packet 26 (e.g., destination IP address), such as using exact match or longest prefix match (LPM), to determine the next hop and configure the next hop of the forward packet flow as an entry within the flow information.

[0036] In some examples, where the strategy for the forward packet flow includes source network address translation (NAT) to translate private addresses into public addresses for packets originating from the application workload (e.g., VM 15A), the kernel of compute device 12A can use the same IP address and / or port mapping as the next hop of the forward packet flow because the uniqueness of the regional portion of the flow key can be used to determine where (e.g., which application workload interface) the packets of the reverse packet flow should be sent to. In some examples, the kernel of compute device 12A can be configured with other strategies.

[0037] The kernel of the virtual router 13A can also be configured with policies for reverse packet flows when processing packets 26 flowing in the forward direction. Forward and reverse packet flows are related to each other because the source address and source port of the forward packet flow are the same as the destination address and destination port of the reverse packet flow, and the destination address and destination port of the forward packet flow are the same as the source address and source port of the reverse packet flow.

[0038] As described above, virtual node 13A can forward packet 26 to the remote destination device using a VXLAN tunnel or an MPLS tunnel over GRE / UDP. In some examples where virtual node 13A forwards packet 26 using a VXLAN tunnel, the ingress interface of virtual node 13A can encapsulate packet 26 with a Virtual Network Identifier (VNI) (such as a VXLAN label identifying the virtual network of the application workload). In some examples where virtual node 13A forwards packet 26 using an MPLS tunnel over GRE / UDP, the ingress interface of virtual node 13A can encapsulate packet 26 with an MPLS label identifying the virtual network of the application workload.

[0039] Because virtual node 13A can map VNI or MPLS labels to application workloads, the kernel of compute device 12A can further map VNI or MPLS labels to regions associated with virtual interfaces of the virtual network to reach the application workloads, and configure virtual node 13A to perform flow information lookups using regions determined by VNI or MPLS labels included in packets received in the reverse direction (e.g., packets originating from client 11 or a remote server hosted in one of data centers 10B-10X and destined for application workloads locally hosted by server 12A). The kernel of compute device 12A can also configure the reverse packet flow to the next hop of VM 15A hosting the application workloads based on information in packet 26, such as source address and source port.

[0040] When virtual node 13A receives a packet (e.g., packet 28) in the reverse direction, virtual router 13A examines the information in packet 28 (e.g., the 5-tuple and the region) to identify whether packet 28 belongs to an existing packet flow. Virtual node 13A determines the region based on the VNI or MPLS label included in packet 28 and uses the region and other information in packet 28 as keying information to perform a flow information lookup to determine the policy for the reverse packet flow. Virtual node 13A then forwards packet 28 to VM 15A according to the policy for the reverse packet flow.

[0041] Figure 2 To show in more detail Figure 1 A block diagram of an example implementation of a data center 10A. Figure 2In the example, virtual nodes 13A-13X (collectively referred to as "virtual node 13") dynamically create and manage one or more virtual networks 34 that can be used for communication between application instances. In one example, virtual node 13 executes the virtual network as an overlay network, which provides the ability to decouple the application's virtual address from the physical address (e.g., IP address) of one of the computing devices 12A-12X (collectively referred to as "computing device 12") on which the application is executing. Each virtual network can use its own addressing and security scheme and can be considered orthogonal to the physical network and its addressing scheme. Various techniques can be used to transmit packets within and across virtual networks 34 over the physical network.

[0042] Each virtual node 13 can execute within a super manager, host operating system, or other components of each computing device 12. Each computing device 12 can represent an x86 or other general-purpose or special-purpose server capable of executing virtual machines 15. Figure 2 In the example, virtual node 13A executes within super manager 31, which is also commonly referred to as virtual machine manager (VMM), providing a virtualization platform that allows multiple operating systems to run concurrently on one computing device of computing device 12. Figure 2 In the example, virtual node 13A manages virtual networks 34 (e.g., VN0-VN2), each virtual network providing a network environment for the execution of one or more virtual machines (VMs) 15 on a virtualization platform provided by the super manager 31. Each VM 15 is associated with one of the virtual networks VN0-VN2 and may represent a tenant VM running client applications, such as web servers, database servers, enterprise applications, or hosting virtualization services used to create service chains. In some cases, any one or more computing devices 12 or another computing device may directly host client applications, i.e., not as a virtual machine. In some cases, some VMs 15 may represent containers, i.e., another form of virtualized execution environment. That is, both virtual machines and containers are examples of virtualized execution environments used to execute application workloads.

[0043] Typically, each VM 15 can be any type of software application and can be assigned a virtual address for use within a corresponding virtual network 34, where each virtual network can be a different virtual subnet provided by virtual node 13A. VM 15 can be assigned its own virtual Layer 3 (L3) IP address, for example, for sending and receiving communication, but may not know the IP address of the physical computing device 12A on which the virtual machine executes. In this way, the "virtual address" is the address of the application, which is different from the underlying physical computer system (e.g., ...). Figure 1 or Figure 2The logical address of computing device 12A in the example.

[0044] In one implementation, each computing device in computing device 12 includes a corresponding VN agent among virtual network (VN) agents 35A-35X (collectively, "VN agents 35") that control the virtual network 34 and coordinate the routing of data packets within computing device 12. Typically, each VN agent 35 communicates with controller 23, which generates commands to control the routing of packets through data center 10A. VN agents 35 can act as proxies for control plane messages between virtual machine 15 and controller 23. For example, VM 15 can request to send a message via VN agent 35A using its virtual address, and VN agent 35A can then forward that message and request a response to the virtual address of VM 15 that initiated the first message. In some cases, VM 15 can invoke procedures or function calls presented by the application programming interface of VN agent 35A, and VN agent 35A can also handle message encapsulation, including addressing.

[0045] In one example, network packets (e.g., Layer 3 (L3) IP packets or Layer 2 (L2) Ethernet packets generated or consumed by an instance of an application running on virtual machine 15 within a virtual network domain) can be encapsulated within another packet (e.g., another IP or Ethernet packet) transmitted over the physical network. Packets transmitted in the virtual network may be referred to herein as “internal packets,” while physical network packets may be referred to herein as “external packets” or “tunnel packets.” Encapsulation and / or decapsulation of virtual network packets within physical network packets can be performed within virtual node 13, for example, within the HyperManager or within the host operating system running on each computing device 12. As another example, encapsulation and decapsulation can be performed at the edge of switching fabric 14 at a first-hop TOR switch 16, a hop from which the application instance initiating the packet is removed. This function is referred to herein as tunnel transport and can be used within data center 10A to create one or more tunnels for interconnecting computing devices 12. Besides IP-in-IP, other example tunnel transport protocols that can be used include IP over GRE, VXLAN, MPLS over GRE, MPLS over UDP, etc.

[0046] As described above, controller 23 provides a logically centralized controller for facilitating the operation of one or more virtual networks within data center 10A. For example, controller 23 may maintain a routing information base, such as one or more routing tables storing routing information for the physical network and one or more networks within data center 10A. Similarly, switches 16, 18, and virtual node 13 maintain routing information, such as one or more routes and / or forwarding tables. In an example implementation, the virtual router 13A of super manager 31 implements a network forwarding table (NFT) 32 for each virtual network 34. Generally, each NFT 32 stores forwarding information for the corresponding virtual network 34 and identifies where data packets will be forwarded and whether the packets will be encapsulated in a tunneling transport protocol, such as using a tunnel header, which may include one or more headers from different layers of the virtual network protocol stack. Each NFT 32 also stores flow information that identifies the action of a packet flow and where the packet flow will be forwarded.

[0047] According to the techniques described in this disclosure, a computing device can, for example, use the kernel of the computing device to provide automatic policy configuration for packet streams without sending packets to user space. For example, computing device 12A can host VM0 15, which provides an execution environment for application workloads. The application workload can initiate packets to be sent to a remote destination device (e.g., client 11 or hosted on...). Figure 1 Packet 26 is a remote computing device in one of the data centers 10B-10X. A virtual node 13A running in the kernel of computing device 12A can receive packet 26 from the application workload and examine information in packet 26 (e.g., 5-tuples and regions) to identify whether packet 26 belongs to an existing packet flow. For example, virtual node 13A can perform a lookup of flow information (e.g., from the flow table) to determine whether the keying information in packet 26 matches an entry in the flow information of NFT0 32. If the keying information in packet 26 does not match an entry in the flow information (and therefore does not belong to an existing packet flow), computing device 12A can configure a policy for forward packet flows via the kernel of computing device 12A and install the flow information of the new packet flow in NFT0 32 without sending packet 26 to the user space of computing device 12A.

[0048] The kernel of compute device 12A can configure flow actions for policies used to forward packets originating from application workloads running on VM015. The kernel can also perform lookups for forwarding information in NFT032 using the L3 address of packet 26 (e.g., the destination IP address), such as using exact match or longest prefix match (LPM), to determine the next hop and configure the next hop of the forward packet flow as an entry within the flow information. In some examples, the kernel of compute device 12A can configure other policies to be applied to the forward packet flow, such as NAT, firewall, or other policies.

[0049] The kernel of virtual router 13A can also configure policies for reverse packet flows when processing packets 26 flowing in the forward direction, and store the policies for reverse packet flows in NFT0 32. As described above, virtual node 13A can forward packets 26 to remote destination devices using VXLAN tunnels or MPLS tunnels over GRE / UDP. In some examples where virtual node 13A uses VXLAN tunnels to forward packets 26, the ingress interface of virtual node 13A can encapsulate packets 26 with a Virtual Network Identifier (VNI) (such as a VXLAN label identifying the virtual network VN0 34 that identifies the application workload running on VM0 15). NFT0 32 can include a mapping between the VNI and the virtual network VN0 of the application workload. In these examples, the kernel of compute device 12A can further map the VNI to area 36. The kernel of compute device 12A configures virtual node 13A to perform an NFT0 32 lookup using the VNI included in packets received in the reverse direction (e.g., packet 28) to determine a region, which is then used as keying information to perform a lookup of flow information to determine a strategy for the reverse packet flow. The kernel of compute device 12A can also configure the reverse packet flow to the next hop of VM0 15, which hosts the application workload.

[0050] In this manner, when virtual node 13A receives a VXLAN packet (e.g., packet 28) in the reverse direction that includes a VNI mapped to area 36, ​​virtual router 13A examines the information in packet 28 (e.g., the 5-tuple and area) to identify whether packet 28 belongs to an existing packet flow. Virtual node 13A determines the area based on the VNI included in packet 28 and uses the area and other information in packet 28 as keying information to perform a flow information lookup in NFT0 32 to determine a policy for the reverse packet flow. Virtual node 13A then forwards packet 28 to VM0 15 according to the policy for the reverse packet flow.

[0051] In some examples where virtual node 13A uses MPLS tunneling over GRE / UDP to forward packet 26, the ingress interface of virtual node 13A can encapsulate packet 26 with an MPLS label identifying the virtual network VNO 34 of the application workload running on VM0 15. NFT0 32 can include a mapping between the MPLS label and the virtual network VN0 of the application workload. In these examples, the kernel of compute device 12A can further map the MPLS label to region 36. The kernel of compute device 12A configures virtual node 13A to perform a lookup of NFT0 32 using the MPLS label included in packets received in the reverse direction (e.g., packet 28) to determine a region, which is then used as keying information to perform a lookup of flow information to determine a policy for the reverse packet flow. The kernel of compute device 12A can also configure the reverse packet flow to the next hop of VM0 15 hosting the application workload.

[0052] In this manner, when virtual node 13A receives an MPLS packet (e.g., packet 28) in the reverse direction that includes an MPLS mapped to area 36, ​​virtual router 13A examines the information in packet 28 (e.g., the 5-tuple and area) to identify whether packet 28 belongs to an existing packet flow. Virtual node 13A determines the area based on the VNI included in packet 28 and uses the area and other information in packet 28 as keying information to perform a flow information lookup in NFT0 32 to determine a policy for the reverse packet flow. Virtual node 13A then forwards packet 28 to VM0 15 according to the policy for the reverse packet flow.

[0053] Figure 3 This is a block diagram illustrating an example computing device according to the technology described in this disclosure. The computing device 300 may represent... Figures 1 to 2 Example instance of any computing device 12.

[0054] In this example, computing device 300 includes a system bus 342 that couples hardware components of the computing device 100 hardware environment. The system bus 342 couples a memory 344, network interface cards (NICs) 306A-306B (collectively referred to as "NIC 306"), a storage disk 307, and a multi-core computing environment 302 having multiple processing cores 308A-308J (collectively referred to as "processing cores 308"). The network interface card 306 includes an interface configured to switch packets using links of the underlying physical network. The multi-core computing environment 302 may include any number of processors and any number of hardware cores. Each processing core 308 includes an independent execution unit for executing instructions conforming to the core's instruction set architecture. Each processing core 308 may be implemented as a separate integrated circuit (IC) or may be combined within one or more multi-core processors, each multi-core processor being implemented using a single IC (i.e., a chip multiprocessor).

[0055] Disk 307 represents a computer-readable storage medium, which includes volatile and / or non-volatile removable and / or non-removable media implemented in any method or technique for storing information such as processor-readable instructions, data structures, program modules, or other data. Computer-readable storage media include, but are not limited to, random access memory (RAM), read-only memory (ROM), EEPROM, flash memory, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by core 308.

[0056] Main memory 344 includes one or more computer-readable storage media, which may include: random access memory (RAM), such as various forms of dynamic RAM (DRAM) (e.g., DDR2 / DDR3 SDRAM) or static RAM (SRAM); flash memory; or any other form of fixed or removable storage medium that can be used to carry or store desired program code and program data in the form of instructions or data structures and can be accessed by a computer. Main memory 344 provides a physical address space consisting of addressable memory locations.

[0057] In some examples, memory 344 may present a non-uniform memory access (NUMA) architecture to the multi-core computing environment 302. That is, core 308 may not have equal memory access times to the various storage media that make up memory 344. In some cases, core 308 may be configured to use the portion of memory 344 that provides the lowest memory latency for the core to reduce overall memory latency.

[0058] In some cases, the physical address space of a computer-readable storage medium can be shared among one or more cores 308 (i.e., shared memory). For example, cores 308A and 308B can be connected via a memory bus (not shown) to one or more DRAM packages, modules, and / or chips (also not shown) that present a physical address space accessible by cores 308A and 308B. While this physical address space can provide the lowest memory access time for cores 308A and 308B to any portion of memory 344, cores 308A and 308B can directly access at least some of the remaining portions of memory 344. One or more cores 308 may also include L1 / L2 / L3 caches or combinations thereof. The respective caches of cores 308 provide the lowest latency memory access for any storage medium of cores 308.

[0059] Memory 344, network interface cards (NICs) 306A-306B (collectively referred to as "NIC 306"), storage disk 307, and multi-core computing environment 302 provide an operating environment for executing the software stack of virtual node 320 and one or more virtual machines 310A-310K (collectively referred to as "virtual machine 310"). Virtual node 320 can represent Figures 1 to 2 Any example instance of virtual node 13. Virtual machine 310 can represent Figures 1 to 2 An example instance of any virtual machine 15. The computing device 300 is divided by main memory 344 and, in the case of virtual memory, by disk 307 into a user space 311 allocated for running user processes and a protected kernel space 312 that is generally inaccessible to user processes. Operating system kernel ( Figure 3 (Not shown) can execute in kernel space and can include, for example, Linux, the Berkeley Software Distribution (BSD), another Unix variant kernel, or a Windows server operating system kernel provided by Microsoft Corp. The computing device 300 can, in certain circumstances, execute a super manager to manage the virtual machine 310 (in... Figure 3 (Not shown in the image). Example Super Manager 31 in Figure 2 As shown in the diagram. Example super managers include Kernel-based Virtual Machines (KVM) for Linux kernels, Xen, ESXi provided by VMware, Windows Hyper-V provided by Microsoft, and other open-source and proprietary super managers. In some examples, dedicated hardware programmed with routing information such as FIB 324 can execute virtual node 320.

[0060] Eth0 314A and Eth1 314B represent devices conforming to the software device model and provide device driver software routines for processing packets to be received / transmitted by the corresponding NIC 306. Packets received by NIC 306 from the underlying physical network structure of the virtual network may include an external header that allows the physical network structure to tunnel payloads or "internal packets" to a physical network address of one of the NICs 306. The external header may include not only the physical network address but also a virtual network identifier (such as a VXLAN label or MPLS label) that identifies a virtual network within the virtual network and its corresponding routing instance 322. Internal packets include an internal header with a destination network address conforming to the virtual network addressing space of the virtual network identified by the virtual network identifier. For example, virtual node forwarding plane 328 may receive packets with an external header from NIC 306A via Eth1 314A that includes a VXLAN associated with routing instance 322A in virtual node forwarding plane 328. The packet may have an internal header with a destination network address, which is the destination address of VM 310A, which is then branched into routing instance 322A via branch interface 346A.

[0061] In this example, virtual node 320 includes a kernel space module 312: virtual node forwarding plane 328; and a user space module 311: VN proxy 335. Virtual node forwarding plane 328 performs the "forwarding plane" or packet forwarding functions of virtual node 320, and VN proxy 335 performs the "control plane" functions of virtual node 320. VN proxy 335 can represent... Figure 2 Any example instance of VN agent 35.

[0062] The virtual node forwarding plane 328 includes multiple routing instances 322A-322C (collectively referred to as "routing instances 322") corresponding to the virtual network. Each routing instance 322 includes a corresponding one from a forwarding information base (FIB) 324A-324C (collectively referred to as "FIB 324") and flow tables 326A-326C (collectively referred to as "flow tables 326"). Although shown as a separate data structure, flow tables 326 may, in some cases, be logical tables implemented as a single table or other associated data structures, where entries in the corresponding flow table 326 may be identified by a virtual network identifier (e.g., a VRF identifier, such as a VXLAN label or MPLS label). FIB 324 includes a lookup table that maps destination addresses to destination next hops. Destination addresses may include Layer 3 network prefixes or Layer 2 MAC addresses. Flow tables 326 enable the application of forwarding policies to flows. Each flow table 326 includes flow table entries, each flow table entry matching one or more flows that can traverse the virtual node forwarding plane 328 and including forwarding policies for applying to the matching flows. For example, virtual node forwarding plane 328 attempts to match a packet processed by routing instance 322A with a flow table entry in flow table 326A. If a matching flow table entry exists for a given packet, virtual node forwarding plane 328 applies the flow action specified in the policy to the packet. This can be referred to as "fast path" packet processing. If no matching flow table entry exists for the packet, the packet may represent the initial packet for a new packet flow. In these examples, virtual node forwarding plane 328 may typically request VN agent 335 to install a flow table entry for the new packet flow in the flow table. This can be referred to as "slow path" packet processing for the initial packet of a packet flow, and... Figure 3 The path is represented by the slow path 340.

[0063] In these examples, VN agent 335 may be a user-space process 311 executed by computing device 300. VN agent 335 includes configuration data 334, virtual routing and forwarding instance configuration 336 (“VRF 336”), and policy table 338 (“Policy 338”). VN agent 335 communicates with one or more controllers (e.g., Figures 1-2The controller 23) exchanges control information. This control information may include virtual network routing, low-level configuration states (such as routing instances), and forwarding policies for installation to configuration data 334, VRF 336, and policy 338. The VN agent 335 may also report analysis status, forwarding status to the FIB 324 of the virtual node forwarding plane 328, and discovery of the VM 310 and its attributes. As described above, the VN agent 335 further applies slow path packet processing to the first (initial) packet of each new flow traversing the virtual node forwarding plane 328 and installs the corresponding flow entry into the flow table 326 of the new flow for fast path processing by the virtual router forwarding plane 328 for subsequent packets of the flow.

[0064] According to the techniques described in this disclosure, a computing device can, for example, use a kernel space 312 module to provide automatic policy configuration for packet streams without sending packets to a user space 311 module.

[0065] exist Figure 3 In the example, the kernel space 312 module includes a data path 313 module, which is used to configure the policy for new flows without requesting the VN agent 335 of the user space 311 module to install flow table entries for the new packet flow in the flow table. The data path 313 module can be a software module (e.g., eBPF) that runs in kernel space 312 and is invoked when a packet is received from the interface virtual node 320.

[0066] As an example, compute device 300 hosts VM 310A, which provides an execution environment for application workloads. Application workloads can initiate requests to be sent to a remote destination device (e.g., client 11 or...). Figure 1 Packets, such as packet 316, are received by a virtual node 320 running in kernel space 312 from an application workload. The virtual node 320 examines information within packet 316 (e.g., 5-tuples and regions) to identify whether packet 316 belongs to an existing packet flow. For example, the virtual node 320 may perform a lookup in flow table 326A to determine if the keying information within packet 316 matches an entry in flow table 326A. If the keying information within packet 316 does not match an entry in flow table 326A (and is therefore part of a new packet flow), the computing device 300 may configure a policy for forward packet flows via the data path 313 module in kernel space 312 and install a flow table entry for the new packet flow in flow table 326A without sending packet 326 to user space 311.

[0067] The data path 313 module in kernel space 312 can configure flow actions for policies used in forwarding packet flows to forward packets originating from application workloads running on VM 310A. The data path 313 module in kernel space 312 can also perform lookups for forwarding information in FIB 324A using the L3 address of packet 316 (e.g., destination IP address), for example, using exact match or longest prefix match (LPM) to determine the next hop, and configure the next hop for forwarding packet flows within flow table 326A. In some examples, the data path 313 module in kernel space 312 can configure additional policies to be applied to forwarding packet flows, such as NAT, firewall, or other policies.

[0068] The data path 313 module of kernel space 312 can also configure a policy for reverse packet flows when processing packets 316 flowing in the forward direction, and store the reverse packet flow policy in flow table 326A. As described above, computing device 300 can forward packets 316 to remote destination devices using VXLAN tunnels or MPLS tunnels over GRE / UDP. In some examples where computing device 300 uses VXLAN tunnels to forward packets 316, the ingress interface (e.g., a network interface card in network interface card 306) can encapsulate packets 316 with a Virtual Network Identifier (VNI) (such as a VXLAN label identifying the virtual network of the application workload running on VM 310A). FIB 324A can include a mapping between the VNI and the virtual network of the application workload running on VM 310A. In these examples, the data path 313 module of kernel space 312 can further map the VNI to region 319. The data path 313 module in kernel space 312 configures virtual node 320 to perform a lookup of flow table 326A using VNIs included in packets received in the reverse direction (e.g., packet 318) to determine a region, which is then used as keying information to perform a lookup of flow table 326A to determine a strategy for the reverse packet flow. The data path 313 module in kernel space 312 can also configure the reverse packet flow to the next hop of VM 310A, which hosts application workloads.

[0069] In this way, when the virtual node forwarding plane 328 receives a packet (e.g., packet 318) including an external header (which includes a VNI mapped to region 319) from the underlying physical network structure of the virtual network (e.g., via Eth 314 from NIC 306), the virtual node 320 can determine the region based on the VNI included in packet 318, and use the region and other information in packet 318 as keying information to perform a flow table 326A lookup to determine the policy flow for the reverse packet, and forward packet 318 to VM 310A according to the policy for the reverse packet flow.

[0070] In some examples where computing device 300 can use an MPLS tunnel over GRE / UDP to forward packet 316 to a remote destination device, the ingress interface (e.g., a network interface card in network interface card 306) can encapsulate packet 316 with an MPLS label identifying the virtual network of the application workload running on VM 310A. FIB 324A may include a mapping between the MPLS label and the virtual network of the application workload running on VM 310A. In these examples, the data path 313 module of kernel space 312 can further map MPLS to region 319. The data path 313 module of kernel space 312 configures virtual node 320 to perform a lookup of flow table 326A using the MPLS label included in packets received in the reverse direction (e.g., packet 318) to determine a region, which is then used as keying information to perform a lookup of flow table 326A to determine a policy for the reverse packet flow. The data path 313 module of kernel space 312 can also configure the reverse packet flow to the next hop of VM 310A hosting the application workload.

[0071] In this way, when the virtual node forwarding plane 328 receives a packet (e.g., packet 318) including an external header (which includes an MPLS label mapped to area 319) from the underlying physical network structure of the virtual network (e.g., via Eth 314 from NIC 306), the virtual node 320 can determine the area based on the MPLS label included in packet 318, and use the area and other information in packet 318 as keying information to perform a lookup in flow table 326A to determine the policy for reverse packet flow, and forward packet 318 to VM 310A according to the policy for reverse packet flow.

[0072] In some examples, computing device 300 can control the resources allocated for configuring automatic policies to execute packet flows. For example, kernel space 312 can create entries for a hash map, such as a Least Recently Used (LRU) hash map 339, which tracks the least recently used flow entries configured by the data path 313 module. Computing device 300 can be configured to store hash entries for each use of a policy created using the techniques described in this disclosure. For example, when a packet flow is created, the data path 313 module (or another module) of kernel space 312 can create an entry in the hash. For the least recently used flow entry, kernel space 312 can remove the least recently used flow entry using LRU hash map 339. In some examples, user space 311 can check for inactive entries (e.g., inactive for a period of time) and remove the entry from LRU hash map 339.

[0073] In some examples, computing device 300 may also limit the number of flow entries configured from the automatic policy configuration of packet flows. In these examples, each virtual interface (e.g., tap interface 346) may be configured with a maximum number of flows to be automatically configured by the data path 313 module in kernel space 312. In these examples, when the maximum number of flows for a virtual interface is exceeded, computing device 300 may revert to sending packets for new packet flows to the user space 311 module to request VN agent 335 to install flow table entries for the new packet flows in the flow table. In this way, computing device 300 can prevent a single virtual interface from unfairly allocating an unfair proportion of available resources.

[0074] Figure 4 This is a flowchart illustrating example operations according to the technology disclosed herein. For convenience, refer to... Figure 3 describe Figure 4 ,but Figure 4 It can represent Figures 1 to 2 Any computing device 12.

[0075] exist Figure 4 In the example, a virtual node 320 implemented by computing device 300 receives a packet originating from an application workload locally hosted on the computing device and destined for a remote destination device (402). For example, computing device 300 hosts virtual execution elements that provide an execution environment for the application workload (e.g., Figure 3 (VM 310A). The application workload can initiate packets, such as packet 316, to be sent to a remote destination device. The virtual node 320 running in kernel space 312 can receive packet 316 from the application workload and examine information in packet 316 (e.g., 5-tuples and regions) to determine whether packet 316 belongs to an existing packet flow. For example, virtual node 320 can perform a lookup in flow table 326A to determine whether the keying information in packet 316 matches an entry in flow table 326A. If the keying information in packet 316 does not match an entry in flow table 326A, virtual node 320 determines that the packet is part of a new packet flow (404).

[0076] In response to determining that a packet is part of a new packet flow, computing device 300 can configure a policy for the new packet flow for a forward packet flow through kernel space 312 of the computing device without sending packet 326 to user space 311 (406). For example, data path 313 module of kernel space 312 can configure a policy for the forward packet flow and install a flow table entry for the new packet flow in flow table 326A. Data path 313 module of kernel space 312 can also perform a lookup of forwarding information in FIB 324A using the L3 address of packet 316 (e.g., destination IP address), for example, using exact match or longest prefix match (LPM), to determine the next hop and configure the next hop for the forward packet flow in flow table 326A.

[0077] The computing device 300 can also configure (408) a policy for reverse packet flows associated with forward packet flows via its kernel space 312. For example, the data path 313 module of kernel space 312 can further map identifiers of virtual networks associated with application workloads to regions (e.g., region 319). The identifier of a virtual network may include a Virtual Network Identifier (VNI), such as a VXLAN label or MPLS label identifying the virtual network of the application workload. The data path 313 module of kernel space 312 configures virtual node 320 to perform a lookup in flow table 326A to determine a region using the VNI or MPLS label included in packets received in the reverse direction (e.g., packet 318), which is then used as keying information to perform a lookup in flow table 326A to determine a policy for the reverse packet flows. The data path 313 module of kernel space 312 can also configure the next hop for the reverse packet flows toward VM 310A hosting the application workload.

[0078] In response to the configuration of policies for forward packet flows and reverse packet flows, computing device 300 sends packets (410) to a remote destination device according to the policy for forward packet flows. For example, the ingress interface of computing device 300 may encapsulate an external header including an identifier of the virtual network of the application workload mapped to area 319 (e.g., a VXLAN label for a VXLAN packet or an MPLS label for an MPLS packet), such that the remote destination device may also encapsulate the external header including the identifier of the virtual network of the application workload into packets originating from the remote destination device and destined for the application workload.

[0079] When the virtual node 320 of the computing device 300 receives a packet (e.g., packet 318) originating from a remote destination device and destined for an application workload (412), the virtual node 320 can determine a region based on the VNI or MPLS tag included in packet 318, and use the region and other information in packet 318 as keying information (414). The virtual node 320 of the computing device 300 uses the region to perform a lookup in flow table 326A to determine a strategy for a reverse packet flow associated with the forward packet flow (416), and sends packet 318 to VM 310A according to the strategy for the reverse packet flow (418).

[0080] In some examples, computing device 300 can control the resources allocated to the automatic policy configuration for executing packet flows. As described above, kernel space 312 can create entries for LRU hash map 339, which tracks the least recently used flow entries configured by the data path 313 module. For the least recently used flow entry, kernel space 312 can remove the least recently used flow entry using LRU hash map 339. In some examples, user space 311 can check for inactive entries (e.g., inactive for a period of time) and remove the entry from LRU hash map 339.

[0081] The techniques described in this disclosure can be implemented, at least in part, in hardware, software, firmware, or any combination thereof. For example, aspects of the described techniques can be implemented within one or more processors, including one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or any other equivalent integrated or discrete logic circuit system, and any combination of such components. The terms "processor" or "processing circuit system" can generally refer to any of the aforementioned logic circuit systems, either alone or in combination with other logic circuit systems or any other equivalent circuit system. Control units, including hardware, can also perform one or more of the techniques disclosed herein.

[0082] Such hardware, software, and firmware can be implemented within the same device or in separate devices to support the various operations and functions described in this disclosure. Furthermore, any described unit, module, or component can be implemented together or separately as discrete but interoperable logic devices. Describing different features as modules or units is intended to highlight different functional aspects and does not necessarily mean that such modules or units must be implemented by separate hardware or software components. Rather, the functionality associated with one or more modules or units can be performed by separate hardware or software components, or integrated within common or separate hardware or software components.

[0083] The techniques described in this disclosure can also be implemented or encoded in a computer-readable medium, such as a computer-readable storage medium, containing instructions. Instructions embedded or encoded in a computer-readable storage medium can cause a programmable processor or other processor to perform the method, for example, when the instructions are executed. Computer-readable storage media may include random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, hard disk, CD-ROM, floppy disk, magnetic tape, magnetic media, optical media, or other computer-readable media.

[0084] Various examples have been described. These and other examples are within the scope of the appended claims.

Claims

1. A method for policy configuration, comprising: Packets are received by a virtual node implemented via a computing device, the packets originating from application workloads hosted on the computing device and destined for a remote destination device; The virtual node determines that the packet is part of a new packet stream; In response to determining that the packet is part of a new packet stream, the kernel of the computing device configures a policy for the new packet stream for a forward packet stream without sending the packet to the user space of the computing device, wherein the policy for the forward packet stream is configured by the kernel outside the user space; The kernel of the computing device configures a strategy for the reverse packet flow associated with the forward packet flow; as well as The computing device sends the packets to the remote destination device according to the strategy used for the forward packet flow.

2. The method of claim 1, wherein configuring the strategy for the forward packet flow comprises: The next hop for the forward packet flow is configured based on a lookup of the destination address of the packet within the forwarding information of the computing device.

3. The method of claim 1, wherein configuring the strategy for the reverse packet flow comprises: Map the regions associated with the application workload to the identifiers of the application workload's virtual network, and Sending the packet to the remote destination device according to the policy for the forward packet flow includes: inserting the identifier of the virtual network of the application workload into the packet before sending the packet to the remote destination device.

4. The method of claim 3, wherein the packets originating from the application workload hosted on the computing device and destined for the remote destination device include forward packets, the method further comprising: The virtual node implemented through the computing device receives reverse packets originating from the remote destination device and destined for the application workload hosted on the computing device, wherein the reverse packets specify the identifier of the virtual network of the application workload; The virtual node determines the region associated with the application workload based on the identifier of the virtual network of the application workload specified by the reverse packet; The virtual node uses the region to perform a flow table lookup to determine the strategy for the reverse packet flow; as well as The virtual node sends the reverse packet to the application workload according to the strategy used for the reverse packet flow.

5. The method of claim 3, wherein the identifier of the virtual network includes at least one of the following: a Virtual Scalable Local Area Network (VXLAN) label or a Multiprotocol Label Switching (MPLS) label.

6. The method according to any one of claims 1 to 5, further comprising: For the strategies used for the forward packet flow and the strategies used for the reverse packet flow, the corresponding hash entries are stored in a flow entry hash map to track the least recently used strategies; The strategy used for the forward packet flow or the strategy used for the reverse packet flow is determined to be the least recently used strategy; as well as In response to determining that the policy used for the forward packet flow or the policy used for the reverse packet flow is the least recently used policy, the least recently used policy is removed using the kernel of the computing device or the user space.

7. The method according to any one of claims 1 to 5, further comprising: The maximum number of streams to be created by the computing device as a virtual interface to the application workload; The virtual node receives subsequent packets, which originate from the application workload hosted on the computing device and are destined for a second remote destination device. It was determined that the maximum number of flows to be created for the virtual interface leading to the application workload was exceeded; as well as The kernel of the computing device is used to send the subsequent packets to the user space of the computing device to configure a strategy for the forward packet flow for the subsequent packets.

8. A computing device, comprising: Virtual nodes; One or more virtual execution elements, said one or more virtual execution elements being coupled to the virtual node; as well as One or more processors, wherein the one or more processors are configured to: Receive packets originating from application workloads hosted on the one or more virtual execution elements and destined for remote destination devices; It is determined that the packet is part of a new packet stream; In response to determining that the packet is part of a new packet stream, the kernel of the computing device configures a policy for the new packet stream for a forward packet stream without sending the packet to the user space of the computing device, wherein the policy for the forward packet stream is configured by the kernel outside the user space; The kernel configuration of the computing device is used for a strategy of the reverse packet stream associated with the forward packet stream; as well as The packets are sent to the remote destination device according to the policy used for the forward packet flow.

9. The computing device of claim 8, wherein, in order to configure the forward packet flow, the one or more processors are configured to: The next hop for the forward packet flow is configured based on a lookup of the destination address of the packet within the forwarding information of the computing device.

10. The computing device according to claim 8, In order to configure the reverse packet flow for the packet, the one or more processors are configured to: map the region associated with the application workload to the identifier of the virtual network of the application workload, and In order to send the packet to the remote destination device according to the policy for the forward packet flow, the one or more processors are configured to insert the identifier of the virtual network of the application workload into the packet before sending the packet to the remote destination device.

11. The computing device of claim 10, wherein the packets originating from the application workload hosted on the computing device and destined for the remote destination device include forward packets, and the one or more processors are configured to: Receive reverse packets originating from the remote destination device and destined for the application workload hosted on the computing device, wherein the reverse packets specify the identifier of the virtual network of the application workload; The region associated with the application workload is determined based on the identifier of the virtual network of the application workload specified by the reverse packet; The region is used to perform a lookup of the flow table to determine the strategy for the reverse grouping flow; as well as The reverse packets are sent to the application workload according to the strategy used for the reverse packet flow.

12. The computing device of claim 10, wherein the identifier of the virtual network includes at least one of the following: a Virtual Scalable Local Area Network (VXLAN) label or a Multiprotocol Label Switching (MPLS) label.

13. The computing device according to any one of claims 8 to 12, wherein the one or more processors are further configured to: For the strategies used for the forward packet flow and the strategies used for the reverse packet flow, the corresponding hash entries are stored in a flow entry hash map to track the least recently used strategies; The strategy used for the forward packet flow or the strategy used for the reverse packet flow is determined to be the least recently used strategy; as well as In response to determining that the policy used for the forward packet flow or the policy used for the reverse packet flow is the least recently used policy, the least recently used policy is removed using the kernel of the computing device or the user space.

14. The computing device according to any one of claims 8 to 12, wherein the one or more processors are further configured to: Configure the maximum number of streams to be created for the virtual interfaces leading to the application workload; Receive subsequent packets, which originate from the application workload hosted on the computing device and are destined for a second remote destination device; It was determined that the maximum number of flows to be created for the virtual interface leading to the application workload had been exceeded; as well as The kernel of the computing device is used to send the subsequent packets to the user space of the computing device to configure a strategy for the forward packet flow for the subsequent packets.

15. A non-transitory computer-readable medium comprising instructions that, when executed, cause one or more processors to: Receive packets originating from application workloads hosted on one or more virtual execution elements and destined for remote destination devices; It is determined that the packet is part of a new packet stream; In response to determining that the packet is part of a new packet stream, the kernel of the computing device configures a policy for the new packet stream for a forward packet stream without sending the packet to the user space of the computing device, wherein the policy for the forward packet stream is configured by the kernel outside the user space; The kernel configuration of the computing device is used for a strategy of the reverse packet stream associated with the forward packet stream; as well as The packets are sent to the remote destination device according to the policy used for the forward packet flow.

16. The non-transitory computer-readable medium of claim 15, wherein the instructions further cause the one or more processors to: The next hop for the forward packet flow is configured based on a lookup of the destination address of the packet within the forwarding information of the computing device.

17. The non-transitory computer-readable medium of claim 15, wherein the instructions further cause the one or more processors to: Map the regions associated with the application workload to the identifiers of the application workload's virtual network.

18. The non-transitory computer-readable medium of claim 15, wherein the packets originating from the application workload hosted on the computing device and destined for the remote destination device comprise forward packets, wherein the instructions further cause the one or more processors to: Receive reverse packets originating from the remote destination device and destined for the application workload hosted on the computing device, wherein the reverse packets specify an identifier of the virtual network of the application workload; The region associated with the application workload is determined based on the identifier of the virtual network of the application workload specified by the reverse packet; The region is used to perform a lookup of the flow table to determine the strategy for the reverse grouping flow; as well as The reverse packets are sent to the application workload according to the strategy used for the reverse packet flow.

19. The non-transitory computer-readable medium of claim 18, wherein the identifier of the virtual network includes at least one of the following: a Virtual Extensible Local Area Network (VXLAN) label or a Multiprotocol Label Switching (MPLS) label.

20. The non-transitory computer-readable medium according to any one of claims 15 to 19, wherein the instructions further cause the one or more processors to: For the strategies used for the forward packet flow and the strategies used for the reverse packet flow, the corresponding hash entries are stored in a flow entry hash map to track the least recently used strategies; The strategy used for the forward packet flow or the strategy used for the reverse packet flow is determined to be the least recently used strategy; as well as In response to determining that the policy used for the forward packet flow or the policy used for the reverse packet flow is the least recently used policy, the least recently used policy is removed using the kernel of the computing device or the user space.

Images