Communication system and method implemented by the communication system, flow controller, switch

Abstract

This disclosure provides a communication system and a method, a traffic splitting controller, and a switch implemented by the communication system. The communication system includes a switch and a traffic splitting controller, the traffic splitting controller storing a fast path table, determining a subset of the fast path table, and sending an instruction to the switch to insert the subset into a connection table stored at the switch. The switch, when forwarding network traffic at least partially based on entries in the connection table, forwards the network traffic to a virtual machine (VM) host at least partially based on the subset, bypassing a gateway. The fast path table contains information about fast paths used by the switch to forward the network traffic such that the network traffic bypasses the gateway.

Description

[0001] This application is a divisional application of the invention patent application with application number 201980086852.8 (international application number PCT / CN2019 / 128975), application date December 27, 2019, and invention title "communication system and method implemented by communication system".

[0002] Cross-references to related applications

[0003] This disclosure claims priority to U.S. Application No. 16236335, filed December 28, 2018, entitled “Overlay Network Routing Using a Programmable Switch,” the entire contents of which are incorporated herein by reference. Technical Field

[0004] This disclosure relates to the field of communications, specifically to the use of programmable switches for overlay network routing. Background Technology

[0005] One of the primary services provided by cloud service providers is offering their users the provider's infrastructure (e.g., processor cores, storage space) for running virtual machines (VMs). Users can remotely access VM instances running on the infrastructure via a Virtual Private Cloud (VPC). Network traffic flows generated from Customer Premises Equipment (CPE) seeking access to a specific VM instance running in the VPC can be received at the Network Controller (NC). The NC forwards these traffic flows to a switch, which then forwards them to the appropriate gateway via routes advertised according to an Exterior Gateway Protocol (EGP) or Border Gateway Protocol (BGP). This gateway then forwards the traffic to the appropriate physical machine running the VM via its MAC address. In other words, the gateway handles all packets entering and leaving the overlay network.

[0006] However, users are increasingly demanding greater capacity and performance for remote VPC access. For example, bandwidth requirements have recently quadrupled and then more than doubled again. Furthermore, users need to increase port density. During frequent VM changes, processing all packets entering and leaving the overlay network at the gateway does not provide port density and / or bandwidth to the VPC (which requires some form of traffic segmentation), without experiencing increased latency and reduced per-connection consistency (PCC). The need for more routes has also increased—in some cases, users require 20,000 routes per VPC. For a customer switch hosting approximately 1,000 users, this means the switch would need to support up to 20 million routes. Currently, no such device exists.

[0007] Furthermore, multiple tenants can share the same physical infrastructure from the provider. Cloud service providers can implement Network Functions Virtualization (NFV) to allow tenants to form overlay networks in multi-tenant networks. Typically, NFV is deployed on x86 systems and forms the overlay network layer. Using x86 systems increases the flexibility of the network architecture and allows new features to be quickly applied to the infrastructure. However, x86 systems result in high management costs, high power consumption, limited performance, and poor scalability.

[0008] To isolate tenant traffic, providers can deploy Virtual Router Bootstrap and Forwarding (VRF) on individual VM hosts. Deploying a VRF involves generating routing tables for each VM host, allowing routers receiving packets destined for a specific VM host to route bootstrap packets using the routing table associated with that VM host. However, this increases the space required for routing tables and the number of open connections in the underlying network. Overlay solutions to handle all such traffic are then very expensive (e.g., routers capable of handling thousands and / or millions of connections can cost a million dollars or more each). Furthermore, routers handling these connections typically have statically allocated resources, such as memory space, which can lead to scalability bottlenecks as the number of tenants grows. Summary of the Invention

[0009] A system is provided, the communication system including a switch and a traffic splitter controller, wherein the traffic splitter controller includes: one or more processors; and a first memory storing first instructions, which, when executed, cause the traffic splitter controller to: store a fast path table and a slow path table; determine a subset of the fast path table for programming the switch; send instructions from the traffic splitter controller to the switch to insert the subset into a connection table stored at the switch; and wherein: the switch includes an application-specific integrated circuit (ASIC) configured to forward network traffic flows at least partially based on entries in the connection table, and the switch forwards network traffic flows to a virtual machine (VM) host, bypassing a gateway, at least partially based on the subset.

[0010] A method is also provided, the method comprising the steps of: storing a first table at a traffic splitter controller; storing a first routing instruction as a first entry in the first table, wherein the first routing instruction, when executed by a switch, causes the switch to forward a first network traffic flow associated with a first tenant between a client device and at least one of a virtual machine (VM) host and a first virtual private cloud (VPC); storing a second routing instruction as a second entry in the first table, the second routing instruction being associated with a second tenant, the second tenant being associated with at least one of a second VM and a second VPC; determining, at least in part, a subset of entries in the first table to be sent to the switch based on cache management instructions; and sending the subset from the traffic splitter controller to the switch.

[0011] A non-transitory computer-readable medium is also provided, the non-transitory computer-readable medium having a connection table and an instruction set, the instruction set, when executed, causing a dedicated circuit ASIC associated with a network switch to: store the connection table, the connection table including a hash subset of a complete table stored at a traffic splitter, the hash subset including a plurality of key-value pairs; receive at least one of an instruction to receive a first key-value pair from the traffic splitter and an instruction to insert the first key-value pair into the connection table or delete a second key-value pair from the connection table; insert the first key-value pair into the connection table; receive packets via a port associated with the network switch; and forward the packets at least in part based on the first key-value pair. Attached Figure Description

[0012] The accompanying drawings are described in detail. In the drawings, the leftmost number of the reference numerals indicates the drawing in which the reference numeral first appears. The same reference numerals in different drawings indicate similar or identical items.

[0013] Figure 1 A block diagram illustrating an example architecture for handling network traffic flows entering and leaving an overlay network via a gateway is provided.

[0014] Figure 2 A block diagram illustrating an overview of an example network architecture for handling network traffic flows to and from a virtual private cloud.

[0015] Figure 3 A block diagram of an example device for processing network traffic flows to and from a virtual private cloud is shown.

[0016] Figure 4A and Figure 4B The uplink and downlink operations of the switch and / or shunt controller are shown respectively.

[0017] Figure 5A block diagram of a virtual routing bootstrapping controller is shown, which stores exemplary fast path tables and / or slow path tables and pushes the associated rules to the switch.

[0018] Figure 6 A block diagram illustrating example cache lookup and packet forwarding using fast paths at a switch is shown.

[0019] Figure 7 A block diagram illustrating example cache lookup and packet forwarding using slow paths at a switch is shown.

[0020] Figure 8 A block diagram depicts an example off-line controller architecture including a VPC controller and / or a VRC, which is used to determine the route of a connection, maintain the connection state, advertise routes to the CPE, and / or control the switch. Detailed Implementation

[0021] This disclosure generally relates to technologies (e.g., machines, processes) for handling network traffic flows between a point of delivery (PoD) (e.g., provider infrastructure receiving ingress packets from a customer premises equipment (CPE) and / or sending egress packets to a CPE) and virtual machine (VM) instances running on VM hosts. The VM instances may run within a Virtual Private Cloud (VPC). The technologies discussed herein may include network architectures for handling this (and other) traffic, including a traffic offloading controller (OC) and / or a programmable switch application-specific integrated circuit (ASIC), hereinafter referred to as a CSW. In some examples, these components may offload packet forwarding and / or routing bootstrapping operations from a gateway.

[0022] In other technologies, the gateway handles all packets entering and leaving the overlay network. For example, in other technologies, peering traffic received by a switch can be routed to the gateway (e.g., as a next hop), allowing the gateway to perform routing and MAC address lookups to correctly route packets between the VPC and CPE. In some examples, the gateway may run on an x86 machine. However, in some examples, the techniques discussed herein may include bypassing the gateway using operational and hardware settings that reduce network latency, support fully bisected traffic, reduce energy consumption, reduce active management, and increase consistency across connections.

[0023] Based on some of the technologies discussed herein, an OC may include a VPC controller and / or a Virtual Router Bootstrap Controller (VRC). The VPC controller may (1) receive instructions from clients via a VPC console, which may include software-defined networking (SDN) instructions (e.g., virtual switch (Vswitch) subnet definitions, user-defined routes, user-defined Internet Protocol (IP) addresses); (2) receive and / or configure cross-region routes with other VPC controllers and / or gateways (e.g., in other regions and / or availability zones); (3) learn and / or publish Border Gateway Protocol (BGP) routes in cooperation with the VRC; and / or (4) configure routes to VM hosts and / or VM instances in cooperation with the VPC switch and / or gateway.

[0024] In some examples, the VPC controller can be configured to advertise BGP sessions directly from the VRC to the CPE and / or via the CSW to the CPE. In additional or alternative examples, the VPC controller can configure gateway-bypassing routes between the CSW and VM hosts and / or VM instances. Upon completion of routing, whether it is a BGP route or a route between the CSW and the VM host, the VPC controller can push the rules used for that route to the VRC.

[0025] In some examples, the operation of the VPC controller can be performed by the VRC, and vice versa. Additionally or alternatively, in some examples, the OC can be configured to automatically enforce user-specified network connectivity policies to automate multi-region, multi-VPC virtual networks, automatically detect address conflicts, and control user-related routing changes to ensure that network connectivity and user service flows are not affected or interrupted, even when the virtual network topology changes frequently (e.g., VMs are migrated to new virtual switches and / or subnets); and / or provide users with the ability to customize network connectivity policies (e.g., via a client-facing VPC console that interfaces with the VPC controller).

[0026] VRC can be configured to receive rules from the VPC controller. In some examples, VRC and / or the VPC controller can configure rules as entries in a key-value table and manage those entries, ensuring that each connection / route has one entry. VRC can maintain a key-value table ("Ingress Key-Value Table") that sets rules for ingress packets (i.e., incoming packets received from the CPE) and / or a key-value table ("Outgress Key-Value Table") that sets rules for egress packets (e.g., packets flowing to users, packets flowing between areas, packets flowing between provider infrastructures).

[0027] In some examples, the VRC can determine a subset of tables stored at the VRC for programming the CSW. For example, the VRC can determine a portion of the entry key-value table and a portion of the exit key-value table for programming the CSW. In some examples, programming the CSW with a portion of this table can include hashing that portion of the table to determine the hashed table pushed to the CSW. Tables received by the CSW from the VRC can be stored as "join tables" in the CSW's cache. The VRC can additionally or alternatively determine when to add and / or delete entries in the join tables stored at the CSW. The VRC can push instructions to add or remove entries from the CSW's control to remotely control the CSW's behavior, and to remotely program the CSW to bypass gateways in some cases, as described below. The VRC can additionally or alternatively resolve conflicts at the CSW (e.g., false positives due to matching table keys and / or hash conflicts, where two key / value pairs are actually unique but generate the same profile).

[0028] The CSW can receive rules from the VRC (e.g., in the form of a portion of a table stored at the VRC and / or a hashed portion), and can store the received rules in a connection table cached in the CSW. In some examples, the connection table may include hashed ingress key-value tables and / or egress key-value tables. In some examples, the CSW may include and / or replace the underlying switch, and may at least partially rely on being programmed by Objective-C to assist in bypassing the gateway.

[0029] To bypass the gateway, the techniques discussed herein may include offloading at least some packet processing from the gateway to the CSW and / or OC. For example, the CSW's ASIC may receive incoming packets and may route them via a slow or fast path, at least in part, based on the ASIC's programming, which may include a connection table. A fast path may bypass the gateway, while a slow path may forward packets to the gateway as the next hop. To determine which path to use for a packet, upon receiving a packet, the CSW may perform a lookup in the connection table to determine if the packet data associated with that packet generates a hit in at least one entry in the connection table. If a hit is generated, the CSW may route the packet via a fast path, which may include forwarding the packet directly to the VPC, bypassing the gateway (e.g., by rewriting and / or encapsulating the packet). In some examples, the VM host and / or VPC switch may be the next hop from the CSW in the fast path. In an example where the VPC switch receives packets forwarded from the CSW, the VPC switch may decapsulate the packets and forward the decapsulated packets to the VM host and / or VM instance.

[0030] On the other hand, when a packet does not generate a match with the join table (i.e., "missed," where a lookup in the join table returns no results), the CSW can forward the packet via the slow path. For example, a missed packet generated while the CSW is searching the join table could be the first packet received in a cloud overlay network where no session has yet been established (e.g., a Transmission Control Protocol (TCP) Synchronization (SYN) message). The CSW can route the packet via the slow path by forwarding it to a gateway. The gateway can then perform various session establishment functions, such as configuring routes (e.g., identifying the fastest path), MAC address lookups, etc., and, upon completing these functions, can forward the packet to the appropriate VPC.

[0031] In some examples, after processing packets and / or performing session establishment functions, the gateway can report session information such as routing configuration, MAC addresses, etc., to the OC (e.g., to the VPC controller and / or VRC). The OC can use the session information to generate key-value entries in the ingress and / or egress tables and can push instructions to the CSW to insert that entry into the connection table on the CSW. In some examples, the VRC can additionally or alternatively determine which entries to delete from the connection table (e.g., to free up space in the cache, as the CSW memory allocation may be limited, such as 3MB or less). The inserted entry can allow the CSW to route subsequent packets received for the new session via fast path routing (e.g., packets from the same source and / or destined for the same destination).

[0032] In this way, inbound packets corresponding to the same session may no longer reach the gateway, and the CSW can be fully responsible for forwarding packets directly to the VPC. For example, for packets that can be forwarded based on existing paths (reflected by rules in the connection table stored at the CSW and / or negotiated by the OC and / or the gateway), the CSW can forward the packets to the appropriate physical machine (e.g., using the MAC address, VxLAN network identifier (VNI), and VM host IP address). Thus, inbound packets no longer need to reach the VPC gateway, and the switch ASIC can be fully responsible for forwarding packets directly to the VPC. This technique reduces overall network latency while still supporting fully bifurcated traffic flows and increasing consistency across connections. Furthermore, this technique eliminates the need to deploy Virtual Router Bootstrap and Forwarding (VRF), as discussed in more detail below. Since VRF is a “heavyweight” protocol, avoiding its use reduces memory usage, computation time, and / or energy consumption on the provider network.

[0033] In some examples, the CSW can generate false positive hits. For instance, if a TCP SYN packet generates a hit, it shouldn't be a true case, as the TCP SYN packet should trigger the insertion of a new entry into the connection table. The CSW can forward this packet to the OC and / or request a deambiguation. The OC can resolve false positives by looking up the packet information in the full ingress / egress table and routing the packet; false positives can, in some cases, be generated by hash collisions. In some examples, the OC can include multiple pipelines and / or stages for rule processing, which can include generating key-value entries in the ingress / egress tables for a session and / or hashing those entries. In some examples, two different stages of the OC can use different hash functions and / or hash salts. Therefore, the OC can migrate conflicting entries to different pipelines / stages, thereby generating new hashes for the conflicting entries. The conflicting entries can be replaced with new hash entries (which are hashed using different salts and / or hash functions), and the VRC can push these new hash entries to the CSW.

[0034] In other technologies, provider networks can use VRFs (e.g., via the connection table scheme discussed herein) to isolate network traffic flows. For example, routers configured on x86 machines or on components of a Network Functions Virtualization (NFV) architecture can use a VRF scheme to route traffic flows, employing different routing tables for different clients and / or VM hosts. According to this scheme, a router can use the routing table corresponding to a particular client or VM host to route packets received from that client. However, as the number of clients increases, provider resource allocation becomes less flexible, and as routing tables proliferate, statically allocated resources (e.g., storage space) become a bottleneck. Furthermore, with the proliferation of underlying connections, routers capable of handling thousands or millions of routes become extremely expensive.

[0035] However, according to the techniques discussed herein, the CSW can be additionally or alternatively configured to isolate client traffic flows without using a VRF. For example, the CSW can route packets directly to the VPC switch and / or VM host (isolating client traffic flows from other clients) based at least in part on data associated with ingress packets, such as Virtual LAN (VLAN) tags, destination Internet Protocol (IP) addresses, etc. In some examples, the CSW can do this without using a VRF (and without configuring the router to transmit VRF). For example, the CSW can use the switch interface receiving the packet, the packet's VLAN tag, and / or the destination IP address (e.g., the VM IP address) to determine the VxLAN Network Identifier (VNI) corresponding to the appropriate VPC switch and / or VM host to route ingress traffic flows via a fast path. In this example, the CSW can encapsulate the VM host IP (e.g., a Virtual Tunnel Endpoint (VTEP) address, which may be a provider address for the destination VM and / or may be referenced by the client's destination IP address in the packet) based on the VPC VNI and send it to the VPC switch. For inbound traffic flows routed via slow path, the CSW can use the received packet, the VLAN tag associated with the packet, and / or the switch interface of the Classless Inter-Domain Routing (CIDR) block to which the packet is targeted (e.g., the destination subnet) to determine the global VNI in which the packet is encapsulated and / or the gateway IP to which the encapsulated packet should be forwarded. Routing inbound packets via slow or fast path may include decapsulating the packet from the VLAN and encapsulating the packet in a VxLAN.

[0036] For outbound traffic flows, the CSW can use the VNI associated with the packet received at the CSW to determine the interface, VLAN tag, and / or next hop that should be associated with the outbound packet. Routing outbound traffic flows may include decapsulating the outbound packet from the VxLAN and encapsulating it in a VLAN. Therefore, between the inbound and outbound traffic flow processing described herein, providers can choose not to deploy a VRF while still maintaining tenant isolation.

[0037] In an example of VRF implementation by the CSW and / or router, the VRC can advertise BGP routes and / or next hops to the VRF maintained by the CSW. This allows the VRC to advertise BGP routes to the CPE. For example, according to the first technique, a gateway (e.g., a VPC gateway) can run a BGP session with the switch to advertise VPC address prefixes to the switch, which then forwards the VPC address prefixes to the user's network via the CPE, and the gateway can also receive CPE prefixes from the CPE via the switch. The gateway can then configure path rules for the CPE prefixes and / or VPC address prefixes. Level 3 traffic flows destined for the VPC, received by the switch from the on-premises host, can tunnel in a Virtual Extensible Local Area Network (LAN) (VxLAN) tunnel. Since the tunnel is stateless, traffic flows from the VPC VM to the on-premises device on the return path can follow an optimized path orchestrated by the Virtual Networking Data Plane, bypassing the VPC gateway and being forwarded directly to the CSW. However, this does not provide BGP route bootstrapping to meet the requirements of some users because, in this first technique, both the control and data planes converge at the CSW.

[0038] However, based on at least one of the techniques discussed herein, the VRC can perform BGP route routing, thereby offloading BGP routes from the CSW and / or gateway to the VRC. The VRC can also reduce the number of hops in the data plane and the latency of each remaining hop, eliminate the load balancer preceding the VPC in some architectures, and improve the resilience of the architecture, allowing flows from the CSW to quickly failover between VPC gateways via controlled BGP peering. In some examples, the VRC can advertise BGP routes directly to the CPE, or the VRC can advertise BGP routes via the CSW.

[0039] Ingress packets may be alternatively and equally referred to as “uplink” packets, and the flow of ingress packets toward the core of the provider’s infrastructure (e.g., to a VM host) is referred to as “uplink”. Egress packets may be alternatively and equally referred to as “downlink” packets, and the flow of egress packets toward the Internet, other regions and / or CPEs is referred to as “downlink”.

[0040] Example Architecture

[0041] Figure 1 A block diagram of a first example network architecture 100 according to a first technology is shown, the first technology being used to process network traffic flows into and out of an overlay network such as VPC 102(1) via gateway 104. Figure 1The diagram shows a first gateway 104(1) up to the m-th gateway 104(M). In some examples, there may be multiple gateways for each VPC and / or multiple VPCs for each gateway. According to the first technique, gateway 104 can provide targets in the VPC routing table for Internet-routable services and can perform Network Address Translation (NAT) for VM instances that have been assigned public IPv4 addresses. In some examples, gateway 104 may be a Virtual Private Gateway (VGW) for dynamically routing Virtual Private Network (VPN) connections to other gateways and / or VPCs (potentially in different availability zones and / or regions), and / or the VGW can relay service flows in and out of VPCs. Gateway 104 may also peer with other gateways (e.g., gateways in different regions such as region 106(0)) via BGP sessions.

[0042] According to the first technique, network traffic flows received from CPE 108 can be received at the PoD and forwarded to router 110. The PoD topology is not shown in any of the accompanying figures because multiple topologies exist (e.g., leaf-backbone, core / aggregation / access), and each of these topologies can ultimately relay packets between the CPE and router 108 (and / or CSW shown in other figures). Router 110 (and / or CSW shown in other figures) can itself be part of the PoD topology (e.g., it can be a border backbone switch). However, in other examples, router 110 is the next hop to the border backbone switch. In any case, the PoD topology is not depicted due to potential variations within the PoD topology.

[0043] In some examples, packets (112) received at router 110 may tunnel through a VPN (e.g., 802.1Q tunneling (Q-in-Q)) and may include one or more VLAN tags in the frame. Router 110 may receive packet 112 and may decapsulate the Q-in-Q ingress packet 112 and encapsulate (114) the decapsulated packet into a VxLAN uplink packet 114. Router 108 may then forward the VxLAN uplink packet 114 to the appropriate gateway 104 (1) according to the VRF routing table. In some examples, to encapsulate and forward the VxLAN uplink packet 114 in a manner that implements routing isolation between tenants, according to the first technique, individual VNIs may be mapped to individual VRF instances, and each tenant may have its own VRF routing instance. Each VRF instance may be associated with a routing table, and the VRF may require a forwarding table specifying the next hop for each data packet, a list of devices that can be invoked to forward packets, and a set of rules and routing protocols for managing how packets are forwarded. These tables prevent traffic from being forwarded outside of specific VRF paths and also keep traffic that should remain outside of VRF paths external. This can create bottlenecks at memory-constrained devices when client / connection volumes surge, leading to high power consumption and computational cycles.

[0044] According to the first technology, gateway 104(1) can be the next hop for peering interconnection traffic received by the customer switch from CPE 106 destined for VPC 102(1) and / or VM host 118(1). Gateway 104 can receive VxLAN uplink packets 114, decapsulate them, and forward the decapsulated packets via data plane 118 to the correct VM host 116 after performing routing and / or MAC lookup. VM host 116 may include a physical machine running a hypervisor that can create, run, and / or manage one or more VM instances. For example, VM host may include one or more cores of a processor and / or associated memory, and VM instances may run on one or more cores of a processor, depending on the service level agreement (SLA) between the tenant and the provider.

[0045] In some examples, gateway 104 can run a BGP session 120 with router 110 and advertise the VPC address prefix to router 110, which can then forward the VPC address prefix 122 to CPE 108. Gateway 104(1) can also receive CPE prefixes from CPE via router 110.

[0046] Because VxLAN tunnels are stateless, traffic flows from the VPC VM to the CPE on the return path follow an optimized path orchestrated by the virtual networking data plane 118, which can bypass gateway 104(1) and be directly forwarded to the customer switch. This cannot provide BGP routing guidance services to meet the requirements of some users, since both the control and data planes converge at the customer switch.

[0047] However, processing all packets entering and leaving the overlay network at the gateway also introduces various problems. For example, the network cannot meet stringent performance guarantees unless over-provisioned, leading to waste (e.g., increased energy consumption, increased heat generation, unused processing cycles, reduced hardware lifespan); the overlay system's unique operational and management mechanisms lack visibility into the underlying transport topology, hindering troubleshooting using the necessary toolkits across the overlay and underlying networks; and faults within the underlying layer affecting the entire structure's bandwidth (e.g., when a link in an Ethernet bundle fails) are transparent to the overlay network unless a feedback mechanism propagates the state to edge devices to perform headend rerouting decisions, or somehow exposes some knowledge of the overlay traffic flow to the underlying layer, allowing the underlying transport to redirect critical flows away from the traffic flow congestion point caused by the fault. However, these are highly risky approaches that can erode the isolation of a tenant's traffic flows from other tenants. Furthermore, as the number of ports and connections required by each tenant increases, routing all packets through the gateway into and out of the overlay network cannot provide the latency and PCC requirements specified in the SLA, and / or there may not be (stable, non-β) hardware capable of handling the required number of connections, or the hardware cost may be too high.

[0048] The following figures and discussion describe techniques for overcoming these and other shortcomings and improving provider architecture and resource provisioning.

[0049] Example Architecture

[0050] Figure 2 A block diagram illustrating an overview of an example network architecture 200 for handling network traffic flows to and from provider core services such as VPC 202(1) as discussed herein is provided. The operation of the components of the architecture is discussed in more detail in the following figures. The example network architecture 200 may include an OC 204 and / or a switch ASIC 206 (“CSW 206”). In some examples, the OC 204 may include a VPC controller 208 and / or a VRC 210. In some examples, the VRC 210 may be remotely programmed and controlled by the CSW 206. In some examples, the OC 204 and CSW 206 may work together to bypass the gateway when handling tenant traffic flows and / or tenant network configurations (e.g., creating subnets, connecting subnets to the Internet, instantiating VM instances).

[0051] In additional or alternative examples, example network architecture 200 can isolate tenant service flows without using VRF. For example, (1) CSW 206 can locate the destination VPC (e.g., the VxLAN Network Identifier (VNI) corresponding to the VPC) based on the VLAN tag and / or destination IP (e.g., VM IP address) of the ingress packet, and / or (2) CSW 206 can locate the VM host IP address (e.g., VxLAN Virtual Tunnel Endpoint (VTEP) address) based at least in part on the destination IP (e.g., VM IP address) of the ingress packet. In some examples, CSW 206 can be encapsulated using the VPC VNI and / or VM host address.

[0052] VRC 210 may additionally or alternatively be configured to peer with CPE 212 and directly advertise Exterior Gateway Protocol (EGP), BGP, or Multiprotocol BGP (MP-BGP) route 214 to CPE 212. In other examples, CSW 206 may advertise BGP route 214 to CPE 212, route-directed BGP route advertisements from VRC 210 to CPE 212, and / or VRC 210 may advertise BGP routes to CPE 212 itself. In at least one example, and not limited thereto, VRC 210 may advertise MP-BGP routes to VPC controller 208 and / or CPE 212, and CSW 206 may forward such advertisements to CPE 212. In some examples, VRC 210 can establish and / or maintain BGP protocol sessions 214, and can learn appropriate routes by cooperating with VPC controller 208, since VPC controller 208 may include provider VPC information (e.g., network data associated with the physical machine running a particular VM instance, such as MAC address and / or VxLAN address) and / or customer-defined information (e.g., customer-defined subnets, customer-defined IP addresses associated with a particular VM instance).

[0053] In some cases, the VRC 210 can also receive user routing configurations from the CPE 212. For example, user routing configurations may specify new virtual switching instructions, new subnets, and / or new user-defined IP addresses associated with VM instances.

[0054] In some examples, CSW 206 may receive and decode uplink packets included in Internet Protocol (IP) (e.g., Q-in-Q, IPv4, IPv6) traffic flows 216 destined for an overlay network, and / or may encode downlink packets from the overlay network to CPE 212 into downlink IP traffic flows 216. For example, IP traffic flows 216 may include a 5-tuple that may include a source address, a destination address (e.g., a VLAN address), a source port, a destination port, and / or a protocol number. Upon receiving uplink packets constrained for the overlay network (e.g., at least some of those in IP traffic flows 216), CSW 206 may forward the packet directly to VPC 202 (1) via fast path 218, or forward the packet to gateway 222 (1) via slow path 220 (or, in some cases, the slow path may be directed to OC 204).

[0055] For example, forwarding uplink packets via Fast Path 218 may include decapsulating packets (e.g., decapsulating packets from VLANs) and / or encapsulating packets destined for VPC 202(1). Encapsulation frame formats may include Virtual Extensible LAN (VxLAN), Network Virtualization with Generic Routing Encapsulation (NVGRE), Transparent Interconnection of Massive Links (TRILL), Location / Identity Separation Protocol (LISP), etc. As discussed in more detail below, CSW 206 may use a connection table (e.g., pushed from VRC 210 to CSW 206) to maintain each connection state, and therefore may forward / encapsulate packets at least in part based on the connection table stored at CSW 206. Therefore, Fast Path 218 may be a VxLAN (and / or other encapsulation frame format) tunnel between CSW 206 and VPC 202(1).

[0056] In some examples, packets routed to VPC 202(1) (e.g., by encapsulating and forwarding packets) may be received by VPC router 224(1). In some examples, VPC router 224(1) may be a logical router that decapsulates packets received via a fast path and routes the packets to the appropriate VM host (e.g., one of 224(1)-(P)). In some cases, VPC router 224(1) may include a virtual switch, such as an application virtual switch (AVS), which may be part of a hypervisor. In additional or alternative examples, packets may be delivered directly to VM host 226. In any case, as used herein, “forwarding packets to VPC 202(1)” ultimately results in packets being delivered to the destination VM host and / or VM instance. In some examples, VPC 202 may include one or more VM hosts 226. VM host 226(P) may include one or more kernels and / or storage and / or hypervisors capable of creating, running, and / or managing (hosting) one or more VM instances. In some examples, there may be multiple VPCs in Availability Zone and / or Zone 228. For example, the m-th Zone 228(M) is depicted as including up to N VPCs 202(N). In some examples, Zone 228 may include one or more gateways 222, and gateways in different zones may peer each other via an External Boundary Protocol session. In some examples, a gateway 224(1) associated with Zone 228(1) may be a peer of a gateway 222(M) associated with Zone 228(M). In some examples, a data plane may be established between gateways in different zones. Alternatively or additionally, a single VRC 210 may be assigned to a subset of CPEs connected to VPCs within Zone 228, and Zone 228 may be associated with multiple VRCs. A single VRC 210 may peer with one or more VRCs in different zones. Furthermore, a hierarchical structure of VRCs (e.g., front-end VRC, back-end VRC, front-end VRC, back-end VRC, central VRC) may exist in a single zone.

[0057] In some examples, forwarding packets via slow path 220 may include forwarding the packet to gateway 222(1) when a rule for the packet is not available in the connection table at CSW 206 (e.g., the packet contains a TCP SYN message, the VRC has not yet pushed a new entry to CSW 206 for the connection associated with the packet, or the packet creates a hash collision, as discussed in more detail below). In this case, gateway 222(1) may perform route bootstrapping (e.g., identifying the fastest route to VPC 202(1), MAC address lookup, etc.) to establish a connection between CPE 212 and VPC 202(1) and / or VM host 226 associated with VPC 202(1). In some cases, CSW 206 may keep the packet encapsulated in a VLAN when forwarding packets via slow path 218, but other methods may also be considered.

[0058] In the example where packets are forwarded to gateway 222(1), gateway 222(1) may push connection state information to OC 204 and / or OC 204 may periodically pull new routing configurations from gateway 222(1) (230). For example, the routing configuration may specify MAC addresses, routes, etc., associated with the path between CPE 212 and VPC 202(1). In some examples, VPC controller 208 may receive this data and may send at least some of it to VRC 210 (230). VRC 210 may then generate a Virtual Route Bootstrap Object (VRO) based at least in part on this portion of the user routing configuration and may control (232) CSW 206 by pushing instructions to add and / or delete rules in the connection table at CSW 206 (based on the VRO) so that subsequent packets received from CSW 206 are forwarded via fast path 218. Thus, VRC 210 may control the operation of CSW 206.

[0059] Alternatively or additionally, VRC 210 may control entries in the connection table at least in part based on a cache management policy at VRC 210 (e.g., by sending instructions to add or delete entries). In some cases, the cache management policy may include: determining least recently used (LRU) connections and sending instructions to delete LRU entries corresponding to LRU connections (and similar techniques); determining most recently used (MRU) connections and sending instructions to add MRU entries corresponding to MRU connections (and similar techniques); and / or a machine learning model that takes MRU connections (e.g., information about CPE 212, VPC 202(1) and / or routing between them) as input and outputs one or more other connections associated with a probability of activation exceeding a threshold probability.

[0060] In other words, the machine learning model is configured to receive data about connections (e.g., notifications of new connections being opened or restarted and / or associated network information), and the model can determine a subset of connections that are likely to be initiated in the near future (e.g., in the next minute, in the next five minutes, in the next hour). For example, a user in a company office might be the first to access a VM instance, while other users might arrive at the office and log in subsequently. The machine learning model doesn't need to know these details; instead, it can learn, through unsupervised learning techniques, which can be used to learn about other connections that are likely to be opened based on the observation of one or more connections becoming active.

[0061] In some instances, the CSW 206 may include an edge switch, such as a switch at the user-facing edge of a provider network, although in other instances the CSW 206 may be located elsewhere. In some examples, while routers typically route bootstrap data at the network layer (Layer 3) and bridges, and switches route bootstrap data at the data link layer (Layer 2), the CSW 206 may be a switch configured to receive Layer 3 traffic flows and route those flows via VxLAN tunnels using routing details specified by a connection table stored on the CSW 206.

[0062] Example device

[0063] Figure 3 A block diagram illustrating an example device 300 and a switch 302 for handling network traffic flows to and from a Virtual Private Cloud (VPN). Example device 300 may be one or more devices comprising OC 204. For example, example device 300 may include VPC controller 304 and / or VRC 306, which may represent VPC controller 208 and VRC 210, respectively. In some cases, VPC controller 304 and VRC 306 may operate on the same machine or on different machines. In some cases, computing device 300 may include a server, such as a blade server. Computing device 300 may include an x86 or similar microprocessor configuration. For example, example device 300 may include processor 308, memory 310, input / output (I / O) device 312, and / or network interface 314 for establishing communication with other devices via network 316. Switch 302 may represent CSW 206 and may include ASIC 318, port 320, and memory 322.

[0064] Processor 308 may represent one or more processors, such as a single-processor system including one processor, or a multiprocessor system including multiple processors (e.g., two, four, eight, or other suitable numbers). Processor 308 may be any suitable processor capable of executing instructions. For example, in various implementations, processor 308 may be a general-purpose or embedded processor implementing any of a variety of instruction set architectures (ISAs) such as x86, ARM, PowerPC, SPARC, or MIPS ISA or any other suitable ISA. In a multiprocessor system, the individual processors 308 may, but are not required to, implement the same ISA. Processor 308 may include one or more central processing units (CPUs) and / or one or more graphics processing units (GPUs). In at least one example, processor 308 includes an x86 system.

[0065] Memory 310 and memory 322 may include a non-transitory computer-readable medium configured to store executable instructions / modules, data, and / or data items accessible by processor 308. In various implementations, the non-transitory computer-readable medium may be implemented using any suitable memory technology, such as static random access memory (SRAM), synchronous dynamic RAM (SDRAM), non-volatile / flash memory, or any other type of memory. In the illustrated example, program instructions and data implementing the desired operations such as those described above are shown stored in a non-transitory computer-readable medium. In other implementations, program instructions and / or data may be received, transmitted, or stored on a different type of computer-accessible medium, such as a non-transitory computer-readable medium, or on a similar medium separate from that non-transitory computer-readable medium. Generally, a non-transitory computer-readable medium may include a storage medium or memory medium coupled to computing device 300 and / or switch 302 and / or available via I / O device 312 and / or network interface 314 and / or port 320, such as flash memory (e.g., solid-state memory), magnetic or optical media (e.g., disk). Program instructions and data stored via a non-transitory computer-readable medium may be transmitted via a transmission medium or signal (e.g., an electrical, electromagnetic, or digital signal), which may be transmitted via a communication medium (e.g., a network and / or a wireless link), for example via network interface 314 and / or port 320.

[0066] I / O device 312 may include an I / O interface configured for I / O traffic flow between coprocessor 308, memory 310, network interface 314, and / or any other hardware and / or provider network infrastructure of example computing device 300. The I / O interface may perform protocols, timing, or other data transformations to convert data signals from one component (e.g., non-transitory computer-readable media) into a format suitable for use by another component (e.g., the processor). The I / O interface may include support for devices attached via various types of peripheral buses (e.g., Peripheral Component Interconnect (PCI) bus standards, Universal Serial Bus (USB) standards, or variations thereof). The functionality of the I / O interface may be divided into two or more separate components, such as a northbridge and a southbridge. Furthermore, some or all of the functions of the I / O interface (e.g., the interface to memory 310) may be directly incorporated into one or more other components of processor 308 and / or provider network infrastructure of example computing device 300. I / O device 312 may include external and / or internal speakers, displays, input devices, etc.

[0067] Network interface 314 can be configured to establish a communication link (e.g., network 316) between example computing device 300 and the provider's network infrastructure and / or other devices in the CPE. For example, network interface 314 can be configured to allow data exchange, for example, with switch 302. Network interface 314 can enable wireless communication via wireless general data networks such as Wi-Fi networks and / or communication networks such as cellular communication networks, satellite networks, etc. In additional or alternative examples, network interface 314 may include hardwired connections between nodes of the provider's network infrastructure.

[0068] Memory 310 may store VPC controller 304 and / or VRC 306, each of which can be executed by processor 308 to perform the functions discussed herein. In some cases, VPC controller 304 and / or VRC 306 may be executed on the same server as gateway 222.

[0069] In some examples, VPC controller 304 can allocate and / or track the physical machines (e.g., cores, blade servers, racks) to which VPCs and / or VM instances are allocated within the provider's network infrastructure. Tracking VPCs can include associating physical machine data with user data (e.g., IP addresses associated with users) and / or user-defined data (e.g., subnets, user-specified addresses). In some cases, VPC controller 304 can track all connections within a region and can peer with VPC controllers in other regions. VPC controller 304 may include routing configuration component 324, which tracks VPCs in a region and / or can configure routes to VPCs through the provider's infrastructure. VPC controller 304 can configure routes to the VPC based at least in part on: receiving MAC addresses and / or other identifiers associated with the VM instance / VPC from the gateway; receiving cross-region routes from VPC controllers in other regions; receiving user-defined network configuration instructions (such as definitions of virtual switches, subnets, and / or routes received from the VPC console) (e.g., the CPE may provide this information via an application programming interface (API) available to the CPE), and / or BGP routes advertised by VPC controller 306. In some cases, VPC controller 304 may track any of the above information as connectivity state data.

[0070] In some cases, VPC controller 304 may push at least a subset of routing data 326 to VPC 306. For example, routing data 326 may be a routing configuration that includes connection details, including appropriate details for routing packets from CPE to VPC and vice versa. In some examples, a hierarchical structure of VPCs may exist within the provider's network infrastructure (e.g., the front end, back end, or central part of the network). VPC controller 304 may determine a subset of routes 326 (from all routes associated with all active connections in the area) based at least in part on the VPCs and / or CPEs associated with VPC 306 (e.g., VPC 306 may control switches and / or routes associated with those CPEs and / or VPCs). VPC controller 304 may also determine which specific subset of VPCs and / or CPEs should be associated with VPC 306.

[0071] VRC 306 may include a Virtual Route Bootstrap Object (VRO) generator 328, a cache management component 330, and / or a BGP interface 332. In some cases, upon receiving route 326 from VPC controller 304, VRO generator 328 may generate a VRO that includes at least one of the following: an identifier of the virtual segment associated with the CPE (e.g., a three-dimensional address space including VPCs and subnets); an identifier of the virtual route routing type (e.g., virtual switches and / or subnets, dedicated endpoints of BGP sessions); attributes of the virtual segment (e.g., zone, VPC, virtual switch); virtual route data channel forwarding information (e.g., tunnel ID, gateway virtual IP address); network connectivity policy information (e.g., virtual segment range); release range (e.g., virtual routers (VRs), border routers (BRs), control cross points (CxPs), which may be bidirectional, with outbound reachable and inbound reachable); the status of network node routing for network traffic flows (e.g., indications of connectivity, routing, etc., which may include packet counts, successful delivery, faults, interruptions, etc.); and an indication of conflict or non-conflict (e.g., regarding VRC 306 in relation to VRC). Indications that identify conflicting routes in the associated layer (306); indications that one or more VRCs have accepted VROs; indications that VROs have been deployed at switch 302; and / or indications that network traffic flows have been successfully routed between the CPE and VPC.

[0072] VRO can be executed by processor 308 and / or may include logical data. For example, when a connection is active, the route used for that connection has been configured not to conflict with other routes (thus isolating tenants), etc., VRO can cause VRC 306 to send rules to switch 302. VRO can also determine when to cause switch 304 to delete rules from connection table 334, thereby stopping packets from being delivered along fast and / or slow paths (or not at all). For example, when VRO is executing, it can be determined based on data stored in VRO that a connection should be released, and VRO can cause an instruction to be sent to switch 302, which instructs switch 302 to delete the entry corresponding to that connection from connection table 334.

[0073] In other words, the VRC can configure packet forwarding policies for underlying data plane nodes such as switch 302 through the VROs associated with the connections managed by the VRC. Additionally or alternatively, the VRC 306 can control VPC routing by calculating relevant BGP and / or MP-BGP routes (e.g., via BGP interface 332) based at least in part on network connectivity policies. These can also be included in the VROs, as in some examples, switch 302 can forward BGP and / or MP-BGP advertisements to the CPE.

[0074] In some cases, VRC 306 may include a cache management component 330. The cache management component 330 may determine the rules to be sent to switch 304. In some cases, sending rules to switch 304 may include sending instructions to add entries to and / or delete entries from connection table 334. In some examples, the sending subset may be based at least in part on an indication received at VRC 306 and from switch 304 that no matching entry was found in connection table 334 for packets received at switch 304, and / or an indication that the packet matches an entry in connection table 334 when the packet includes a synchronization message (and / or other session establishment messages) (such as a Transmission Control Protocol (TCP) Synchronization (SYN) message).

[0075] In some examples, cache management component 330 may include cache management policy 336, model 338, and / or hash level 340. Cache management component 330 may determine a set of rules to be pushed to switch 302 based at least in part on the output of cache management policy 336 and / or model 338. For example, cache management policy 336 may include one or more cache replacement policies, such as, for example, determining LRU connections, MRU connections, time-aware least recently used (TLRU) connections, segmented LRU connections, low cross-reference recent set (LIRS) of connections, etc. Model 338 may include a machine learning model generated using unsupervised learning techniques (although supervised techniques may be used in other examples). Therefore, model 338 may include neural networks, such as boosted sets of random forests and / or decision trees; directed acyclic graphs (DAGs) (e.g., where nodes are organized as Bayesian networks); deep learning algorithms, such as artificial neural networks (ANNs) (e.g., recurrent neural networks (RNNs), residual neural networks (ResNet)), deep belief networks (DBNs), deep stacked networks (DSNs); in some cases, model 338 may receive one or more connections that become active as input, and based on these inputs, model 338 may output the identifiers of one or more other connections.

[0076] When cache management component 330 identifies a subset of connections, it can send rules and instructions associated with that subset of connections to switch 302 via network 316 to insert and / or delete entries in connection table 334. Note that the subset of rules sent from VRC 306 to switch 302 corresponds to the subset of active or potentially active connections among those associated with route 326 in the layer / region associated with VRC 306, as determined by VRC 306, which is a further subset of all active connections maintained by VPC controller 304.

[0077] In some examples, the cache management unit 330 can maintain route 326 as a fast table associated with fast paths and / or a slow table associated with slow paths. In some examples, for each connection managed by VRC 306, the cache management unit can store the following data separately in the fast path table and / or the slow path table:

[0078]

[0079] Table 1 Fast Path Table

[0080]

[0081] Table 2 Slow Path Table

[0082] In some examples, cache management unit 330 may hash the table to save memory and / or because memory 322 at switch 304 may be limited. In some examples, cache management unit 330 may use more than one hash level 340 to generate multiple summaries. VRC 306 may migrate entries that conflict with another entry in a single summary to a different hash level, thereby changing the first summary (rather than the underlying information) associated with the first entry. This migration of an entry may include generating a new summary that includes the entry using a different salt than the salt originally used to generate the first summary (e.g., a cryptographic nonce on which the hash function may be based).

[0083] In some examples, switch 302 may include an ASIC 318 dedicated to forwarding packets received at port 320. To determine where to forward packets received at port 320 (whether the packets are inbound or outbound), memory 322 may store a connection table 334 and may determine whether a received packet matches an entry in the connection table. In some cases, memory 322 may include a cache associated with the ASIC 318. Connection table 334 may include a summary generated by hashing entries from the fast and / or slow tables. In some examples, instructions received from VRC 306 to add and / or delete entries in connection table 334 may cause switch 302 to rehash one or more entries in connection table 334 to generate a new summary, although in some examples VRC 306 may hash and push the resulting summary to connection table 334 for use with entries. In some cases, connection table 334 may include 5-tuples associated with VPC VNI and / or destination IP addresses. The 5-tuple can be a hash key, and the VPC VNI and / or destination IP address can be hash values. In some examples, switch 302 can be an edge switch located at the user-facing edge of the provider network, although switch 302 can also be positioned otherwise.

[0084] Example Operation

[0085] Figure 4A and Figure 4B An operational diagram of CSW 400 and OC 402 is illustrated. In some cases, CSW 400 and OC 402 work together to route network traffic between CPE 404 and VM instance 406, bypassing gateway 408. In some cases, gateway 408 may be part of a hypervisor. As mentioned above, OC 402 may include VPC controller 410 and / or VRC 412, and these components may run on the same machine or different machines. Note that while the discussion below specifically refers to VM instance 406, it should be understood that packets may be routed to another component of the VM host or VPC associated with a user-defined subnet.

[0086] Figure 4A This document illustrates the uplink operation of the components discussed when an ingress packet destined for VPC 406 is received from CPE 404. In some cases, CSW 400 may receive the ingress packet from CPE 404 at its port, and in operation 414, CSW 400 may perform a lookup in the connection table to determine whether the ingress packet generates a match with at least one entry in the connection table. In some examples, CSW 400 may decapsulate the ingress packet before performing the lookup (e.g., from a VLAN), but in other examples, the ingress packet may remain encapsulated. CSW 400 may use at least a portion of the data contained within the packet (e.g., at least a portion of the routing data in the packet header / footer) to determine whether the ingress packet generates a match. For example, CSW 400 may determine whether the plaintext data matches an entry in the connection table, and / or CSW 400 may hash the data contained in the packet to see if the hashed data matches a hash key in the connection table. In some examples, the CSW 400 can determine whether an inbound packet matches the switch interface identifier, VLAN tag, and / or destination IP address (e.g., VMIP) in the fast path table and / or the switch interface identifier, LAN tag, and destination subnet (e.g., CIDR block) in the slow path table.

[0087] If CSW 400 determines that the ingress packet generation hit (416), CSW 400 can forward the ingress packet to VPC router 418, which may include encapsulating the ingress packet, and VPC router 418 can decapsulate the packet and forward it to the appropriate VM host running VM instance 406. This is the fast path. In some examples, VPC router 418 may be a virtual switch. In some examples, CSW 400 may use the VxLAN protocol (or any other Layer 3 protocol) that specifies the VPC VNI and / or VTEP address for the VM host to encapsulate the ingress packet. For example, CSW 400 may use the VLAN tag and destination IP address (e.g., VM IP address) to find the destination VPC that can be mapped to the VNI, and after identifying the destination VPC, CSW 400 may use the destination IP to find the VM host's IP address (e.g., VxLAN VTEP address). In some examples, individual VNIs / VPCs may be mapped to different destination VTEPs for different VM hosts within the same VPC. In some instances, individual VLAN tags may be mapped to different VNIs for different VPCs. Mapping individual VNIs / VPCs to different destination VTEPs for different VM hosts within the same VPC can increase network and server resource utilization, reduce power consumption, and / or free up CPU and memory, thereby increasing the available computing bandwidth that can be used by tenants.

[0088] In some cases, after determining that an ingress packet generation hit has occurred, CSW 400 can also determine whether the ingress packet includes a synchronization message attempting to establish a connection, such as a TCP SYN message. If not, CSW 400 can forward the ingress packet (416) to VPC router 418. However, if the ingress packet includes a TCP SYN message and matches an entry in the connection table, CSW 400 can send a notification and / or ingress packet to VRC 412 (operation 420) instead of forwarding the ingress packet to the appropriate VPC router 418.

[0089] If the ingress packet includes a synchronization message and matches an entry in the connection table, CSW 400 can send the notification and / or ingress packet to VRC 412, as hash collisions are likely to occur (e.g., where hashing two different sets of data results in the same summary). When CPE 404 initializes the connection, CPE 404 can send a synchronization message, so there should be no entry in the connection table since the connection has not yet been configured, and therefore VRC 412 must also push the rules to CSW 400.

[0090] Upon receiving a notification and / or ingress packet, VRC 412 can configure a route for the ingress packet (e.g., via communication with VPC controller 410 and / or gateway 408), forward the ingress packet via that route, generate new rules for the ingress packet, and / or push the new rules to CSW 400. To avoid hash collisions, VRC 412 can generate rules by hashing entries in the fast and / or slow tables using a different level and / or salt than the level and / or salt used by the entry that caused the hash collision. Information identifying the entry that caused the collision can be included in the notification sent from CSW 400 to VRC 412.

[0091] If CSW 400 determines that the ingress packet does not match any entry in the connection table (Operation 422, "Missed"), CSW 400 can forward the ingress packet to gateway 408, allowing gateway 408 to perform routing and / or MAC address lookup to correctly route the ingress packet. Gateway 408 can then forward the ingress packet to VM instance 406. This is the slow path.

[0092] In some examples, gateway 408 and VPC controller 410 can collaborate for route configuration (424) (e.g., when packets are forwarded to gateway 408 via a slow path and no route / connection is configured when a route collision occurs). For example, VPC controller 410 can receive cross-area routes, BGP advertisements (from VRC 412), user-defined network configurations (e.g., subnet definitions, user-defined IP addresses), and can receive MAC addresses associated with VM instances and can configure routes from CPE to VM instances.

[0093] Upon completion of the routing configuration, VPC controller 410 can store the routing configuration in association with CPE 404 and the new connection. VPC controller 410 can push (426) at least some of the routing configuration data to VRC 412, and VRC can then program CSW 400 (428) to add entries to the connection table associated with the new connection, enabling subsequent packets received from CPE 404 to be routed via fast paths. As mentioned above, VRC 412 can be one of multiple VRCs organized hierarchically, so VRC 412 can be responsible for handling a subset of all connections in the area, and thus can control one or more switches. Therefore, in some examples, VPC controller 410 can determine before sending routing configuration information to VRC 412 that VRC 412 is the appropriate VRC 412 for handling the connection (e.g., using load balancing techniques and / or because VRC 412 is associated with provider resources already allocated to CPE 404).

[0094] Figure 4BThis document illustrates the downlink operation of the components discussed herein when an egress packet destined for CPE 404 is received from VM instance 406. In some examples, egress packets received from VPC 406 at CSW 400 (e.g., via a fast path through VPC router 418, or a slow path through gateway 408) can be encapsulated in a VxLAN header. Upon receiving the egress packet, CSW 400 can perform a cache lookup 430 to determine if a match is generated in the egress table for the VNI associated with the egress. Alternatively or additionally, CSW 400 can decapsulate the egress packet upon receipt and / or upon generating a match in the egress table.

[0095] If cache lookup 430 does not generate a hit (missed 432), CSW 400 may discard the packet and / or CSW 400 may forward the packet and / or notification to the hypervisor and / or OC 402 associated with VM instance 406.

[0096] If cache lookup 430 results in a hit (434), CSW 400 can decapsulate the egress packet from the VxLAN header, and / or if VM instance 406 (or VPC router 418 or gateway 408) does not use VLAN protocol to encapsulate the egress packet, it can use VLAN or a similar protocol. For example, the VLAN header / tag can specify the switch interface, VLAN tag, and next-hop ID, allowing CSW 400 to properly forward the egress packet to CPE 404.

[0097] Example VRC and CSW operations

[0098] Figure 5 A block diagram of VRC 412 is illustrated. VRC 412 stores an exemplary fast path table 500 and / or slow path table 502 and pushes the associated rules to CSW 400. In some cases, VPC controller 410 may push a set of routing configurations (504) to VRC 412. In some cases, this set of routing configurations may be associated with a subset of connections in the region associated with VPC controller 410, and VRC 412 may be responsible for managing this subset of connections. In some cases, VRC 412 may store the routing configuration 504 as key-value pairs in a hash table. Tables 500 and / or 502 may include hash tables.

[0099] For example, key 506 in fast path table 500 can map a VLAN tag and / or destination address (e.g., VMIP) to value 508, which can be a VNI associated with the VPC. Alternatively, the destination address (e.g., VMIP) and / or VNI can be mapped to a VM host address, which can include a VTEP address such as a VxLAN tunnel endpoint address. In other words, a VPC can be mapped to different destination VTEPs for different VM hosts within the same VPC. In some cases, the VTEP can reside within the hypervisor containing the VM instances to which packets are addressed (and when the hypervisor is running multiple VMs, it can perform routing guidance between VMs).

[0100] In some examples, key 510 of slow path table 502 can map VLAN tags and / or CIDR block identifiers (such as subnet identifiers) to value 512, which can include global VNIs (such as a series and / or a set of VNIs) and / or gateway IP addresses (such as VTEP addresses that terminate at gateway 408).

[0101] Additionally or optionally, keys 506 and / or 510 may include switch interface identifiers that may identify the ingress / egress points of the provider network (e.g., backbone ports, IP interfaces to the IP network, racks, network controllers, leaf / backbone).

[0102] VRC 412 can push instructions to insert at least one of these entries from the fast path table 500 and / or the slow path table 502 into the connection table 334 at CSW 400, thereby programming CSW 400 (514) to forward packets via the route associated with the at least one entry. In some cases, VRC 412 can push entries as "rules," which may include any portion of a 5-tuple from the fast path table 500 and / or the slow path table 502. In some cases, the rules pushed to CSW 400 may be summaries generated by hashing the entries from the fast path table 500 and / or the slow path table 502.

[0103] As described above, VRC 412 can determine, at least in part, the subset of fast path table 500 and / or slow path table 502 to be sent to CSW 400 based on model 338 and / or cache management policy 336 stored at VRC 412.

[0104] Figure 6A block diagram illustrating example cache lookup 414 and packet forwarding at CSW 400 is provided. In some examples, when CSW 400 receives a user IP (uplink / ingress) traffic flow (which may include an interface identifier, VLAN tag, and / or VM IP address), CSW 400 may decapsulate (602) the traffic flow (e.g., from a VLAN) and / or use a fast path table (if available, such as when a connection has already been established for a CPE associated with the traffic flow) to identify the VNI and / or VM host IP address, and encapsulate (604) the traffic flow using the VNI and / or VM host IP address (e.g., in a VxLAN tunnel terminating at a hypervisor running on a VM host). CSW 400 can then forward the traffic flow to subsequent nodes in the network according to any technique, such as identifying the next-hop identifier 608 based at least in part on the IP address 610, which may include performing IP routing bootstrapping 606. In some examples, the key 610 / value 608 pair may be part of a join table 334. At this point, CSW 400 can forward traffic to the next node associated with the next-hop ID, and / or CSW 400 can additionally or alternatively identify a set of MAC addresses 610 associated with next-hop IDs 608 / 612. CSW 400 and / or the upstream node can update the MAC address 614 associated with this set of MAC addresses 608. These MAC addresses can be used by the node to forward traffic to the VM host.

[0105] Figure 7 A block diagram illustrating example cache lookup 430 and packet forwarding at CSW 400 is provided. In some examples, when CSW 400 receives a downlink traffic flow 700 destined for a CPE (e.g., from a VPC / VM host, encapsulated in a VxLAN), CSW 400 can determine the VNI associated with the downlink traffic flow. Based at least in part on this VNI, CSW 400 can determine the switch interface identifier, VLAN tag, and / or next-hop ID associated with the VNI. In some examples, the VNI can be mapped to the switch interface identifier, VLAN tag, and / or next-hop ID in the egress table stored in the connection table at CSW 400.

[0106] If CSW 400 determines that the VNI is not associated with data in the egress table, CSW 400 may drop the traffic flow and / or may notify the VRC, VPC, and / or VPC controller. If CSW 400 determines that the VNI is associated with data in the egress table, CSW 400 may decapsulate (702) the downstream traffic flow (e.g., by decapsulating the traffic flow from the VxLAN header) and / or encapsulate (704) the downstream traffic flow (e.g., using the VLAN protocol, switch interface identifier, VLAN tag, and / or next-hop ID). CSW 400 and / or upstream nodes may additionally or alternatively perform IP routing bootstrapping (706), which may include identifying a set of MAC addresses associated with the next-hop ID (710) (708) and updating the MAC address used to forward the traffic flow (712).

[0107] Example VPC controller and VRC

[0108] Figure 8 A block diagram of an example traffic offloading controller architecture 800 is shown, comprising a VPC controller 410 and / or a VRC 412 for determining routes for connections, maintaining connection states, advertising routes to CPEs 802(1)-(R), and / or controlling CSWs. In some examples, multiple VRCs 412(1)-(S) may exist. The VRCs 412(1)-(S) may be organized hierarchically, such that each VRC is associated with a different part of the provider network. For example, a subset of all active connections in the network may be assigned to a corresponding VRC, and / or the VRC may operate at different depths in the network (e.g., front-end, back-end, center, Layer 2, Layer 3). Note that from this point onward, VRCs are discussed collectively and / or individually as VRC 412. In other words, any one or more of the VRCs 412(1)-(S) may perform the actions discussed herein.

[0109] In some examples, by using VRC, CSW does not need to use VRF for segmentation, and CPE 800(R) can communicate directly with VRC412 (sending commands, instructions, packets, user-defined routes, etc.) via BGP and / or MP-BGP (e.g., BGP sessions 804(T) and 806(U) run by VRC agent 808(S)). In some examples, users can communicate with VRC 412 via APIs such as OpenAPI, Swift, etc.

[0110] In some cases, traffic flow between CPE 802(R) and VRC 412 can be relayed through CSW 400, but CSW 400 can also forward traffic flow from CPE 802(R) to VRC 412 (and vice versa), allowing users to communicate directly with VRC 412. Therefore, CSW 400 is not illustrated in this diagram. Deploying VRCs for a subset of active connections in the area can also replace and / or supplement the load balancer located before the VPC. In other potentially disadvantageous examples, gateway 408 can advertise BGP routes to the CPE. In some examples, gateway 408 can be entirely replaced by VPC controller 410, VRC 412, and / or CSW 400.

[0111] In some examples, a user can send user-defined rules / routing configurations (such as new subnets, new virtual switch commands, user-defined IP addresses associated with VMs) to VRC 412, and VRC 412 can send at least a portion of the user-defined rules / routing configurations to VPC controller 410. In some examples, VPC controller 410 may be centrally located in the provider network topology, but other technologies are also conceivable.

[0112] VRC 412 can advertise (808) BGP and / or MP-BGP routes to CPE 802(1)-(R) and VPC controller 410 and / or any other node. VPC controller 410 can ultimately be responsible for managing the VM hosts (e.g., physical machines and / or hypervisors) running VM instances on it, which can include migrating VM instances / hypervisors, instantiating VM instances, assigning resources (e.g., specific kernels / physical machines) to specific VPCs, tracking routing data (e.g., MAC addresses, IP addresses) associated with the resources assigned to the VPC, etc.

[0113] For example, regarding the nth VPC 810(N), the VPC controller 410 may allocate one or more physical machines (e.g., processor cores and / or memory) to the VPC 810(N), and the CPE 802(R) may request that the VM instance 812(P) be instantiated in association with a user-defined IP address and private subnet (e.g., in response to an instruction received from a user via the VPC console 814). The VPC controller 410 may receive user requests and user routing configurations for the VM instance to be instantiated from the VPC 412(S) and / or the VPC console 814, and may configure connectivity and routing details through the provider network to isolate the business flow between the VM 812(P) and the CPE 802(R) from other tenants. To achieve isolation and successful packet routing, VPC controller 410 may receive user-defined routes (816) from the VPC console (e.g., API interface) and / or from VRC 412, receive cross-region routes (818) from VPC controller 820 associated with different regions peered to VPC controller 410 (e.g., this may include negotiating routes with VPC controller 816 so that VPC 808(N) can span multiple regions without creating route conflicts), learn BGP routes received from VRC 412 (808), configure the final fast path route with VPC router 824 (822), and / or configure the final slow path route with gateway 408 (826).

[0114] In some cases, VPC router 824 may include a virtual switch located within the hypervisor, and VPC controller 410 may communicate with VPC router 824 to configure the final route (822) as a fast path connection to set VPC router 824 as an endpoint of a VxLAN tunnel from CSW 400. Setting VPC router 824 as an endpoint of a VxLAN tunnel may include mapping VPC 810(N) to a VNI and / or mapping VPC VNI, switch interface, VLAN tag, and / or VM IP address (one or more of which may be user-defined rather than provider-defined) to VPC router 824. VPC controller 410 may then push routing data associated with this fast path connection to VRC 412(S), which is responsible for the connection between CPE 802(R) and VM 812(P), for example, for entries stored in the fast table at VRC 412(S). Furthermore, the VRC412(S) can send instructions to the CSW 400 to insert entries into the connection table associated with the connection, at least in part, based on the cache management strategy and / or model output, as discussed further above.

[0115] In some examples, VPC controller 410 can configure the final route (824) to gateway 408 as a slow path connection by communicating with gateway 408 (which may be associated with a VM host running on VM 812(P)) to establish a connection between CSW 400 and gateway 408. VPC controller 410 can then push routing data associated with this slow path connection to VRC 412(S), which is responsible for the connection between CPE 802(R) and VM 812(P), for example, for entries stored in the slow table at VRC 412(S). Furthermore, VRC 412(S) can send instructions to CSW 400 to insert an entry into the connection table associated with this connection, at least in part based on a cache management policy and / or an output model, as discussed further above.

[0116] In some examples, the VRC 412 can automate user-specified network connectivity policies to automate multi-region, multi-VPC virtual networks, automatically detect address conflicts and control routing changes to ensure that network connectivity and user service flows are not affected or interrupted (even when the provider's network topology changes frequently, such as when VM instances are migrated to new virtual switches or subnets), and / or can provide users with the ability to customize network connectivity policies.

[0117] For example, based at least in part on user-specified network connectivity policies (e.g., "routing configuration"), the VRC 412 can compute relevant BGP routes and can configure packet forwarding policies to the underlying data plane nodes. In some cases, a single VRC 412 can operate in multiple network topology layers and / or different VRCs can be assigned to different network topology layers. For example, these layers may include: a VR layer, where the VRC can manage and control current VR / VPC connectivity and routing (e.g., VPC peering); a BR layer, where the VRC can manage and control current BR connectivity and routing (e.g., cross-region VPC peering); and / or a CxP layer, where the VRC can manage and control current CxP connectivity and routing (e.g., cross-region multi-BR VPC peering).

[0118] In some cases, VRC 412 may include VRO, which includes executable and / or logical components for implementing such management and control. For example, a VRO may include: an identifier of the virtual network segment associated with the CPE (e.g., a three-dimensional address space including VPCs and subnets); an identifier of the virtual route routing type (e.g., a virtual switch and / or subnet, a dedicated endpoint of a BGP session); attributes of the virtual network segment (e.g., area, VPC, virtual switch); virtual route data channel forwarding information (e.g., tunnel ID, gateway virtual IP address); network connectivity policy information (e.g., virtual network segment range); release range (e.g., virtual switch, VR, BR, CxP, which can be bidirectional, outbound reachable, inbound reachable); the status of network node routing for network traffic flows (e.g., indications of connectivity, routing, etc., which may include packet count, successful delivery, failure, interruption, etc.); an indication of conflict or non-conflict (e.g., an indication of conflicting routes in the layer associated with VRC 306, identified by VRC 306); an indication that one or more VRCs have accepted the VRO; an indication that a VRO has been deployed at switch 302; and / or an indication that network traffic flows have been successfully routed between the CPE and VPC.

[0119] In some examples, an active VRC (e.g., a VRC currently configuring its associated connectivity / VRO) can communicate with the VPC to establish management and control terms and / or routing configurations to generate a VRO. After successfully generating a VRO, the active VRC can exchange VROs (including the newly generated VRO) with VRCs in layers above and / or below it. VRCs in other layers can choose to accept or reject a VRO, at least in part, based on whether the VRO causes a conflict in the layer associated with another VRC. Upon accepting newly generated and exchanged VROs, the active VRC can implement network connectivity policies and routing control by manipulating the VRO. In some cases, VRC 412 can generate VROs for individual CPEs 802.

[0120] The generation and switching of VROs are described below to ensure at least uplink isolation. In some examples, VRO switching may include the first VRC at the lowest level (e.g., the Virtual Switching Layer) generating the initial VRO and checking for routing conflicts and accepting or rejecting the current virtual routing decision (e.g., made by VPC controller 410 and / or another VRC 412). If a VRC accepts the routing decision, it may instruct the VRO to be accepted at the layer associated with the first VRC, and the first VRC may pass the VRO to the VRC associated with the upper and / or lower layers, compared to the layer associated with the first VRC, and so on, until all relevant VRCs have accepted the VRO. For example, relevant VRCs may be VRCs that control network connectivity for the connection being routed, and / or VRCs associated with the highest layer and all VRCs of the layers below that, if a change is made at the BR layer (e.g., a user-defined new subnet), relevant VRCs may include VRCs associated with the BR layer and VRCs associated with the VR layer, but not VRCs associated with the CxP layer. In some cases, the user-specified range can determine the limits of VRC that VRO can achieve.

[0121] In some cases, if a VRO accepted at the highest tier of a user-defined range is detected as being down / down between VRCs, the VRC associated with at least one of the highest or lower tiers can check for a routing conflict. If the VRC detects a routing conflict, it can stop downlink processing by sending a command to CSW 400, and / or the VRC can send the identity of the conflicting route to the underlying data forwarding node via the VPC controller.

[0122] Example Terms

[0123] A. A system comprising a switch and a traffic splitter controller, wherein the traffic splitter controller includes: one or more processors; and a first memory storing a first instruction, which, when executed, causes the traffic splitter controller to: store a fast path table and a slow path table; determine a subset of the fast path table for programming the switch; send an instruction from the traffic splitter controller to the switch to insert the subset into a connection table stored at the switch; and wherein: the switch includes an application-specific integrated circuit (ASIC) configured to forward network traffic flows at least partially based on entries in the connection table, and the switch forwards network traffic flows to a virtual machine (VM) host, bypassing a gateway, at least partially based on the subset.

[0124] B. According to the system described in paragraph A, the first entry of the fast path table includes a key and a value, wherein: the key includes at least a Virtual Local Area Network (VLAN) tag and a destination Internet Protocol (IP) address, and the value includes at least a Virtual Private Cloud (VPC) Virtual Scalable Local Area Network (VxLAN) Network Identifier (VNI) and a Virtual Machine (VM) IP address.

[0125] C. The system according to paragraph A or B, wherein the subset includes the first entry, and the switch includes a second memory associated with the second memory storing the connection table and a second instruction, which, when executed, causes the ASIC to: receive packets destined for VMs in the VPC; determine that the packets are associated with a VLAN tag and a destination IP address; decapsulate the packets from VLAN encapsulation; and encapsulate and forward the packets at least in part based on the VNI and the VM IP address.

[0126] D. A system according to any one of paragraphs A through C, wherein the process of encapsulating and forwarding the packets based at least in part on the VNI and the VMIP address bypasses the gateway.

[0127] E. The system according to any one of paragraphs A through D, wherein the process of determining the subset is based at least in part on a machine learning model that determines that entries in the subset are associated with one or more connections that are most likely to remain active or become active over a period of time.

[0128] F. The system according to any one of paragraphs A through E, wherein the processing of determining the subset is based at least in part on cache replacement instructions.

[0129] G. The system according to any one of paragraphs A through F, wherein the cache replacement instruction includes instructions for determining the least recently used entry of the TLB.

[0130] H. The system according to any one of paragraphs A through G, wherein the first instruction further causes the routing controller to: receive from the switch a packet and an indication that the packet is not associated with an entry in the connection table; determine that the packet is associated with a first entry in the fast path table; and send from the routing controller to the switch an instruction to insert the first entry into the connection table.

[0131] I. The system according to any one of paragraphs A through H, wherein the instruction further causes the switch to delete the least recently used entry.

[0132] J. The system according to any one of paragraphs A to I, wherein the first instruction further causes the traffic splitter to: determine that the packet is associated with a second entry in the slow path table; and send the packet from the traffic splitter to at least one of the gateway and the VPC controller, wherein the gateway or the VPC controller configures a route for the packet.

[0133] K. The system according to any one of paragraphs A through J, wherein the first instruction further causes the routing controller to: determine that the packet is not associated with an entry in the fast path table or the slow path table; and send the packet from the routing controller to at least one of the gateway and the VPC controller, wherein the gateway or the VPC controller configures a route for the packet.

[0134] L. A method comprising: storing a first table at a traffic splitter controller; storing a first routing instruction as a first entry in the first table, wherein the first routing instruction, when executed by a switch, causes the switch to forward a first network traffic flow associated with a first tenant between a client device and at least one of a first virtual machine (VM) host and a first virtual private cloud (VPC); storing a second routing instruction as a second entry in the first table, the second routing instruction being associated with a second tenant, the second tenant being associated with at least one of a second VM and a second VPC; determining, at least in part, a subset of entries in the first table to be sent to the switch based on cache management instructions; and sending the subset from the traffic splitter controller to the switch.

[0135] M. According to the method described in paragraph L, the step of sending the subset further includes sending an instruction, which, when executed by the switch, causes the switch to forward network data received at the switch at least in part based on the subset.

[0136] N. The method according to paragraph L or M, the method further comprising: storing the second routing instruction as a second entry in a second table, wherein the second routing instruction, when executed by at least one of the traffic splitter or the switch, causes the traffic splitter or the switch to forward network traffic flows associated with the first tenant between the client equipment and the gateway associated with the first VPC; receiving at the traffic splitter a notification from the switch that a packet received at the switch does not match any entry in a connection table including the subset; and sending the packet from the traffic splitter to the gateway based at least in part on the second entry.

[0137] O. The method according to any one of paragraphs L to N, the method further comprising sending the first entry from the traffic splitter to the switch, at least in part based on receiving the notification.

[0138] P. The method according to any one of paragraphs L to O, the method further comprising: receiving, at the traffic splitter controller, routing information associated with a routing configuration determined by the gateway, the routing information being used to transmit the packet to at least one of the first VM host and the first VPC; and generating the first routing instruction based at least in part on the routing information.

[0139] Q. A non-transitory computer-readable medium having a connection table and an instruction set, which, when executed, causes a dedicated circuitry ASIC associated with a network switch to: store the connection table, the connection table comprising a hash subset of a complete table stored at a traffic splitter, the hash subset comprising a plurality of key-value pairs; receive a first key-value pair from the traffic splitter and at least one of an instruction to insert the first key-value pair into the connection table and an instruction to delete a second key-value pair from the connection table; insert the first key-value pair into the connection table; receive packets via a port associated with the network switch; and forward the packets at least in part based on the first key-value pair.

[0140] R. According to paragraph Q, a non-transitory computer-readable medium wherein: the network switch is deployed as part of the edge of a network architecture, the packets include Internet layer protocols, and the processing of forwarding the packets includes encapsulating the packets at least in part based on an overlay protocol, wherein the routing details of the overlay protocol are specified by the value of the key-value pair.

[0141] S. According to the non-transitory computer-readable medium described in paragraph Q or R, the instruction set further enables the ASIC to: receive a first packet, wherein the first packet is associated with a first tenant also associated with the packet; determine that routing information associated with the first packet does not match the key of an entry in the connection table; and send at least one of the first packet and a notification regarding the key mismatch between the first packet and the routing controller from the network switch; and wherein the first key-value pair is received at least in part in response to sending at least one of the first packet and the notification.

[0142] T. A non-transitory computer-readable medium according to any one of paragraphs Q to S, wherein the processing of forwarding the packet based at least in part on the first key-value pair includes bypassing a gateway and forwarding the packet to at least one of a virtual machine (VM) host and a virtual private cloud (VPC).

[0143] The modules described herein represent instructions that can be stored in any type of computer-readable medium and can be implemented in software and / or hardware. All the methods and processes described above can be implemented in software code modules and / or in computer-executable instructions executed by one or more computers or processors, hardware, or some combination thereof, and are fully automated via software code modules and / or in computer-executable instructions executed by one or more computers or processors, hardware, or some combination thereof. Alternatively, some or all of these methods can be implemented in dedicated computer hardware.

[0144] Unless otherwise expressly stated, conditional language, such as “can,” “able,” “may,” or “possibly,” should be understood in context as indicating that some examples include certain features, elements, and / or steps, while other examples do not. Therefore, such conditional language is generally not intended to imply that one or more examples require certain features, elements, and / or steps in any way, or that one or more examples must include logic for determining whether to include or perform certain features, elements, and / or steps in any particular example, with or without user input or prompts.

[0145] Unless otherwise explicitly stated, connective language such as the phrase “at least one of X, Y, or Z” should be understood to mean that the item, etc., can be X, Y, or Z, or any combination thereof, including multiple corresponding elements. Unless explicitly stated as singular, “one” means both singular and plural.

[0146] Any routine description, element, or block described herein and / or depicted in the accompanying drawings should be understood as potentially representing a module, segment, or portion of code comprising one or more computer-executable instructions for implementing a particular logical function or element in the routine. Alternative implementations are included within the scope of the examples described herein, wherein elements or functions may be removed or performed out of order as shown or discussed, including substantially synchronously, in reverse order, with additional operations, or with omitted operations, depending on the functionality involved as would be understood by one of skill in the art.

[0147] It should be emphasized that many variations and modifications can be made to the above examples, and these variations and modifications should be understood as other acceptable examples. All such modifications and variations are intended to be included within the scope of this disclosure.

Claims

1. A communication system, the communication system comprising a switch and a traffic splitter controller, The traffic splitter controller stores a fast path table, determines a subset of the fast path table, and sends an instruction to the switch to insert the subset into the connection table stored at the switch, wherein... The fast path table contains information about fast paths, which are used by the switch to forward network traffic flows and enable these flows to bypass the gateway. When the switch forwards network traffic flows based at least in part on entries in the connection table, it also forwards the network traffic flows to the virtual machine (VM) host by bypassing the gateway, based at least in part on the subset of entries.

2. The communication system according to claim 1, wherein, The first entry in the fast path table includes a key and a value, wherein: The key includes at least a Virtual Local Area Network (VLAN) tag and a destination Internet Protocol (IP) address, and The values ​​include at least the Virtual Private Cloud (VPC) Virtual Scalable Local Area Network (VxLAN) Network Identifier (VNI) and the IP address of the Virtual Machine (VM).

3. The communication system according to claim 2, wherein, The subset includes the first entry, and the switch stores the connection table, and the switch also: Receive packets destined for VMs located in a VPC; The packet is determined to be associated with a VLAN tag and a destination IP address; Decapsulate the packet from the VLAN encapsulation; and The packets are encapsulated and forwarded based at least in part on the IP addresses of the VNI and the VM.

4. The communication system according to claim 3, wherein, The process of encapsulating and forwarding the packets based at least in part on the IP addresses of the VNI and the VM bypasses the gateway.

5. The communication system according to claim 1, wherein, The process of determining the subset is based at least in part on a machine learning model that determines that entries in the subset are associated with one or more connections that are most likely to remain active or become active over a period of time.

6. The communication system according to claim 1, wherein, The processing of the subset is based at least in part on cache replacement instructions.

7. The communication system according to claim 6, wherein, The cache replacement instructions include instructions for determining the least recently used entry in the fast path table.

8. The communication system according to claim 1, wherein, The shunt controller also includes: Receive packets from the switch and an indication that the packets are not associated with an entry in the connection table; The group is determined to be associated with the first entry in the fast path table; as well as The flow controller sends an instruction to the switch to insert the first entry into the connection table.

9. The communication system according to claim 8, wherein, The instruction also causes the switch to delete the least recently used entry.

10. The communication system according to claim 8, wherein, The shunt controller also includes: A slow path table is stored, which contains information about slow paths used by the switch to forward the network service flow and to forward the network service flow to the gateway as the next hop. as well as The group is determined to be associated with the second entry in the slow path table; as well as The packet is sent from the traffic splitter to at least one of the gateway and the VPC controller, wherein the gateway or the VPC controller configures a route for the packet.

11. The communication system according to claim 8, wherein, The shunt controller also: A slow path table is stored, which contains information about slow paths used by the switch to forward the network service flow and to forward the network service flow to the gateway as the next hop. as well as Determine that the group is not associated with an entry in the fast path table or the slow path table; The packet is sent from the traffic splitter to at least one of the gateway and the VPC controller, wherein the gateway or the VPC controller configures a route for the packet.

12. The communication system according to claim 1, wherein, The shunt controller also includes: The first routing instruction is stored as the first entry in the fast path table, wherein when the first routing instruction is executed by the switch, the switch causes the switch to forward the first network service flow associated with the first tenant between the client equipment and at least one of the first virtual machine (VM) host and the first virtual private cloud (VPC). The storage includes a second routing instruction associated with a second tenant as a second entry in the fast path table, wherein the second tenant is associated with at least one of a second VM or a second VPC; The subset of the fast path table is determined at least in part based on cache management instructions; and The subset is sent from the traffic splitter to the switch.

13. The communication system according to claim 12, wherein, Sending the subset also includes: Send an instruction to cause the switch to forward the network traffic flows received at the switch based at least in part on the subset.

14. The communication system according to claim 12, wherein, The shunt controller also includes: A slow path table is stored, which contains information about slow paths used by the switch to forward the network service flow and to forward the network service flow to the gateway as the next hop. as well as The second routing instruction is stored as a second entry in the slow path table, wherein when the second routing instruction is executed by at least one of the traffic splitter or the switch, the traffic splitter or the switch causes the traffic splitter or the switch to forward the network service flow associated with the first tenant between the client equipment and the gateway associated with the first VPC; Receive from the switch a notification that a packet received at the switch does not match any entry in the connection table that includes the subset; and The packet is sent from the traffic splitter to the gateway based at least in part on the second entry.

15. The communication system according to claim 14, wherein, The shunt controller also includes: Based at least on receiving the notification, the first entry is sent from the traffic splitter to the switch.

16. The communication system according to claim 14, wherein, The shunt controller also includes: The routing controller receives routing information associated with a routing configuration determined by the gateway from the gateway, the routing information being used to deliver the packet to at least one of the first VM host and the first VPC; as well as The first routing instruction is generated based at least in part on the routing information.

17. A method implemented by a communication system having a switch and a traffic splitter, the method comprising the following steps: The fast path table is stored by the traffic splitter controller; A subset of the fast path table is determined by the traffic splitter controller; The traffic splitter sends an instruction to the switch to insert the subset into the connection table stored at the switch, wherein the fast path table contains information about fast paths used by the switch to forward network traffic flows and enable the network traffic flows to bypass the gateway. The switch forwards network traffic flows at least partially based on entries in the connection table, wherein the switch forwards the network traffic flows to the virtual machine (VM) host by bypassing the gateway at least partially based on a subset.

18. The method according to claim 17, wherein, The first entry in the fast path table includes a key and a value, wherein: The key includes at least a Virtual Local Area Network (VLAN) tag and a destination Internet Protocol (IP) address, and The values ​​include at least the Virtual Private Cloud (VPC) Virtual Scalable Local Area Network (VxLAN) Network Identifier (VNI) and the IP address of the Virtual Machine (VM).

19. The method according to claim 18, wherein, The subset includes the first entry, and the method further includes: The switch receives packets destined for VMs located in the VPC; The switch determines that the packet is associated with a VLAN tag and a destination IP address; The aforementioned switch decapsulates the packets from the VLAN encapsulation; and The switch encapsulates and forwards the packets based at least in part on the IP addresses of the VNI and the VM.

20. The method according to claim 19, wherein, The process of encapsulating and forwarding the packets based at least in part on the IP addresses of the VNI and the VM bypasses the gateway.

21. A shunt controller, wherein, The shunt controller: Store the fast path table. Determine a subset of the fast path table, and Send an instruction to the switch to insert the subset into the connection table stored at the switch. The fast path table contains information about fast paths, which are used by the switch to forward network service flows and enable these flows to bypass the gateway. The subset is used to forward network traffic flows to virtual machine (VM) hosts by bypassing the gateway, at least in part, based on the subset when the switch forwards network traffic flows at least in part based on entries in the connection table.

22. A switch, wherein, The switch: Receive instructions from the traffic splitter to insert a subset of the fast path table stored at the traffic splitter into the connection table stored at the switch. The fast path table contains information about fast paths, which are used by the switch to forward network service flows and enable these flows to bypass the gateway. The subset is used to forward the network service flow to the virtual machine (VM) host, at least partially based on the subset, when the switch forwards the network service flow at least partially based on the entries in the connection table.

Images